HOVD 2013 - Kedvenc programnyelv

HUP

c
13% (95 szavazat)
c#
6% (41 szavazat)
c++
11% (84 szavazat)
haskell, erlang, caml, ... (funkcionális nyelvek)
4% (26 szavazat)
java
17% (122 szavazat)
javascript
3% (24 szavazat)
perl
8% (58 szavazat)
php
19% (138 szavazat)
python
17% (121 szavazat)
ruby
3% (23 szavazat)
Összes szavazat: 732

( utf-8 | 2013. 12. 15., v – 14:51 )

Negyedszáz szavazat, és még nincs JS. Lehet, hogy mégis van az emberiségnek jövője? :) //Igen, tudom, hogy még az elején vagyunk, de azért hadd örüljek kicsit.
---------------------------
���������������������������

Annyira nem rossz ám az a nyelv... Most épp JS-sel dolgozom, szinte kizárólag. A nyelvvel magával nincs gondom, főleg, ha meg van támogatva jó libekkel (pl. underscore) és valami jó mvc-frameworkkel (pl.: backbone). Ám látszik, hogy nem nagy alkalmazások írására találták ki, nehéz nagy projektet szervezetten fejleszteni benne. Viszont az AMD - szerintem - nemhogy kiküszöböli ezt a hibát, hanem több, mint jól megoldja, és még productionben is lehet okosan használni (pl. requirejs-sel).

Hogy ezt miért írtam le ilyen polit is megszégyenítő részletességgel? Nem tudom, talán még mindig magamat is győzködöm, hogy nem olyan rossz ez a nyelv :-)

"Ám látszik, hogy nem nagy alkalmazások írására találták ki, nehéz nagy projektet szervezetten fejleszteni benne."

A variable scope se igazán segít.

http://stackoverflow.com/questions/500431/javascript-variable-scope

Én is pont ezzel dologozok. Játszogatni, scriptelgetni a JS ideális, komolyabb, karbantartandó kódot inkább másban írnék.

> A variable scope se igazán segít.
Engem nem igazán zavar, sőt, még akár tisztíthatja is a kódot; a scope miatt inkább érdemes előre összegyűjteni a függvényben használt változókat, mint ahogy nagyonrégen C-ben is tették. Sőt. JSLint szól is érte. Linter nélkül pedig amúgy sem áll neki az ember JS-ezni, ugyeeee?????

Ajánlották már, de azt mondták sírni fogok :) Szóval egyelőre még halogatom.

"még akár tisztíthatja is a kódot"

Én nagyon hozzá vagyok szokva a block-scopehoz, lehet ez idővel változni fog, de egyelőre azt látom érthetőbbnek, karbantarthatóbbnak. Mondjuk már kezdem kicsit megszokni a JS félét is.

Az AngularJs-t próbáltad? Én tegnap próbálgattam szárnyaimat vele, tetszetős kis darabka. DI-it is megoldja valamilyen szinten, van ui binding, nagyon egyszerű, szép formában. Arra nem mondanám, hogy nem lehet darabolni a kódot.
Bár ugye, ha tényleg nagy alkalmazást fejlesztesz, és mobilra is, akkor a code split hiánya miatt nem a legoptimálisabb megoldás sajnos.

Ruby és JS között vaciláltam.

A JS-t nem tartom univerzális nyelvnek, de mint beágyazott nyelv (qml, html, gnome) szerintem jól használható, működik ahogy elvárható. Ha egy komplett alkalmazást kéne írni benne, akkor azt hiszem kihullna a hajam.

A nodejs-re csak hunyorítva nézek, bár használok nodejs programot shellből és meglepően jól működik, lehet lesz még ebből barátság.

Erre azt tudom mondani, hogy akkor nezz meg egy nagy JS frameworkot.
Persze olyat, ami meg nem elhagyott projekt.. :)
Dokumentacio, kovetkezetesseg, strukturaltsag a kulcsa mindennek.

Pl en pont most neztem meg az AngularJs-t: kesz MVC megvalositas, auto bi-directional ui bind, dependenci injection.

Es mindez olyan egyszeruen kivitelezve, hogy csak neztem... osszehasonlitva a GWT-s megoldasokkal.. szinte hihetetlen, hogy ilyen egyszeruen is mukodhet valami :)

Én egyelőre azt érzem, hogy mivel nem tudom, hogy minek milyen a típusa, így sokkal több effort, ha bele akarok nyúlni egy JS kódba. Ugyanis nem látom, hogy egy függvény ott most egy boolean-t vár, egy objectet, egy stringet stb. Át kell néznem a hívott függvényt is, hogy mit is fog csinálni, mi lesz a sorsa a paraméternek.

Persze lehet, hogy csak nem vagyok még hozzászokva, de szerintem ez így kényelmetlenebb.

Kb. ugyanez a bajom Java-ban is, ha valaki pure Map-et használ, főleg, ha át is adogatja osztályokon keresztül. Át kell néznem adott mélységig a kódot/JavaDocot ahhoz, hogy rájöjjek, hogy pl egy Map esetén a key és a value az most micsoda. a .put(key, value)-val nem vagyok kisegítve. Persze, ha lenne egy specifikus osztályom, ami vagy örökölne, vagy wrappelné a Map-et, akkor már egyértelműen lehetne jelezni a .put(String key, String value) esetén, hogy .put(String id, String lastname), ami rögtön egyértelmű.

"Erre ott a dokumentacio."

Na de látod, erről beszélek. Sokkal több effort karbantarthatóra hozni / karbantartani a JS kódot. Minek írnék plusz JSDoc-ot, ha egyértelműen lehetne jelezni a kódban, hogy most mit is akarok? A kód a legjobb dokumentáció, az legalább biztosan változik a kóddal együtt :)

"Ha bongeszore akarsz fejleszteni, akkor a JS-en kivul nem sok lehetoseg van."

Sajnálom is nagyon :(

JSDoc, JavaDoc persze, hogy kell, de én elég sokszor érzem, hogy a checkstyle ugyan kierőszakolja, de semmi értelme, mert a függvény neve és szignatúrája elég jól definiálja, hogy mit is csinál.

Hogy szem előtt van-e, az szintén más kérdés. Szem előtt van egy osztály privát függvénye is, amit hívni szeretnél, de JS esetén nem elég ránézni a függvény szignatúrájára, értelmezned is kell a függvényt. Míg pl. Javaban el tudod fogadni azt, hogy a függvény azt csinálja, ami a neve és azzal, amik a paraméterei.

Hasraütéses példa:

JS:
function getPhoneNumber(person){};

Java:
PhoneNumber getPhoneNumber(Person person);

JS esetén nem tudom mit ad vissza, ha nem olvasom el a JSDocot, vagy a függvény törzsét. Sőt, azt se feltétlen tudom, hogy a person az mi, de ezt mondjuk még meg lehet indokolni.

Java esetén már a függvény deklarációjából tudom, hogy ez egy PhoneNumber-t fog visszaadni, és ezt egy Person-ból veszi. JavaDoc tök felesleges.

A fenti példa szerint a JS-t több effort karbantartani. JSDocot kell írni és karbantartani, és/vagy át kell nézni a függvénytörzset.

Szerintem nem ez a problémája. Demonstrálom: 


class Person
{
	private final String firstName;
	private final String lastName;

	public Person(String firstName, String lastName)
	{
		this.firstName=firstName;
		this.lastName=lastName;
	}
}

Map<String, Person> people=new HashMap<>();

peolpe.put("Smith",new Person("John","Smith"));
people.put("Miles",new Person("Richard","Miles"));

//10000 sorral és három package-dzsel arrébb

people.get("John");	//null

Vagyis abból még nem feltétlenül derül ki, hogy mi a key, ha ismert a típusa. A javadoc-ból meg csak annyi derül ki, hogy a get paramétere a key.

Na most ide én is feliratkozok, mert szerintem nem erre gondolt :-) Én azt olvasom ki a hozzászólásából, hogy az a gondja, hogy a kulcs szemantikai "típusát" kell mindig kikeresni a dokumentációból (a példájában ez egy id, bár arra megoldásként mondjuk használjon saját id osztályt). A te példád ellenben azt fájlalja, hogy a tárolt kulcsok közül jót kérdezz le; ezen pedig konstansok (static finalok) vagy enumok segítenének.

Namost ilyenek viszont minden nyelvben előfordulnak. Ezért születnek a CodeComplete és CleanCode könyvek :-)

De arra gondoltam, hogy Javaban (typesafe nyelvekben) sem derül ki a típus alapjan sok esetben, hogy egy egy fgv paraméter épp micsoda.
Hozzá kell nézni a javadocot vagy legalább a szignatúrát, hogy legalább a paraméter nevét megtudd (utóbbit IDE-k alapból megteszik, de ezt az előnyt JS-ben is el lehet valahogy érni)

De, nagyjából a fentire gondoltam, de mindkettőtöknek igaza van :) ("az a gondja, hogy a kulcs szemantikai "típusát" kell mindig kikeresni a dokumentációból")

A fenti példából kiindulva, ha származtatunk a Map-ből (vagy wrappeljük a Map-et, jelen esetben mindegy), akkor írhatjuk azt, hogy:


class Persons extends Map<String, Person>
{
...
@Override
public Person put(String lastName, Person person)
{
...
}
}

Ennél a függvényből egyértelműen látszik, hogy mi is a key, főleg megfelelő IDE esetén.


Map<String, Person> people=new HashMap<>();

peolpe.put("Smith",new Person("John","Smith"));
people.put("Miles",new Person("Richard","Miles"));

Itt az IDE azt dobja fel, mint hint, de a forrásból is így látszik:


people.put(String key, Person person);

ehelyett lehet azt, hogy:


People people=new People();

peolpe.put("Smith",new Person("John","Smith"));
people.put("Miles",new Person("Richard","Miles"));

Ebben az esetben az IDE azt dobja fel, mint hint (de a forrásban is egyértelműbb a helyzet így), hogy:


people.put(String lastName, Person person);

Remélem így már érthetőbb, hogy mire gondoltam :)

Egyébként ez a "trükk" pont szerepel is a CleanCode könyvben :) Mondjuk már azelőtt rájöttem, hogy ilyesmi jó megoldás lenne, mielőtt olvastam, de hát ezt az élet hozza, ha az embernek sok Map.put(String key, String value) közt kell eligazodnia :)

Ez a trükk nyelvi szinten van támogatva néhány nyelvben typedef kulcsszóval. (Én kifejezetten nem szerettem a legutóbbi projektet, ahol egy agyontypedefelt cuccal kellett dolgozni, értelmetlen volt.)

De ha Javánál maradunk, akkor utána is kéne nézni, hogy ez az apró "trükk" milyen side effecteket tud okozni a classLoadereknél, milyen memóriaoverheadje van, stb.

"...utána is kéne nézni, hogy ez az apró "trükk" milyen side effecteket tud okozni a classLoadereknél, milyen memóriaoverheadje van, stb."

Abban az esetben, ha teljesítmény-kritikus alkalmazást írsz. Általában viszont a forrás érthetősége fontosabb annál, minthogy 5%-kal több memóriát fogyasztassz az ilyen "trükkök" miatt. Vagy ahogy a fontossági sorrend is tartja:

1. működjön
2. legyen olvasható
3. legyen optimalizált

a kód.

Az 1. pont triviális, a 2-3. pont sorrendjén lehet vitatkozni, de általánosságban elmondható, hogy a kód inkább evolválódik, mintsem sok-sok évig változatlan marad (újabb és újabb requirementek általi refaktorálások tömkelege, a'la agile vs. waterfall), így az optimalizálásba ölt idő elvesztegetett, ha teszem azt, 5 hónap múlva úgyis át kell írni az adott kódrészletet. És ha már hozzá kell nyúlni, akkor az érthetőség a fontosabb.

Szóval igen, beágyazott rendszeren nem csinálunk ilyeneket, ahol egyszer megírod és fut évekig, míg egy üzleti alkalmazásnál, ahol havonta változnak a feltételek a piaci igényeknek megfelelően, ez (a kód érthetősége) fontos.

( Luther | 2013. 12. 15., v – 16:39 )

Ebben a kategóriában a legnehezebb a választás…
Van eset, mikor ez a jobb, van mikor az és van amikor nem te döntesz, mert nincs választásod, mert az adott terület nem támogat egyebet.
Szóval szívem szerint többet is megjelölnék…
--------------
„If there were no hell, we would be like the animals. No hell, no dignity.”

Szerintem ez a szavazás arról szól, hogy melyik a kedvenced, nem pedig arról, hogy melyiket érdemes használnod. Tehát ha adott egy feladat, amelyre elvileg bármely nyelv választható (nem köti meg semmi és senki a kezed), akkor melyiket választanád? Remélem, sikerült segítenem a választásban :)

( wachag | 2013. 12. 17., k – 08:37 )

Elfelejtettem a
-ruby
+verilog, VHDL, egyéb hardverleíró nyelvek
javaslatot beküldeni :-(.

( enpassant v | 2013. 12. 17., k – 09:59 )

Ha valakit érdekelnek a nyelvek nemzetközi népszerűségi listája, akkor ezeken a helyeken nézelődhet:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://redmonk.com/sogrady/2013/07/25/language-rankings-6-13/
http://langpop.com/
http://lang-index.sourceforge.net/

Sokan szidják itt a Javascript-et (nem teljesen méltatlanul :), azért érdemes megnézni a Redmonk-nál, ami a Github és Stackoverflow alapján mér, ott holtversenyben első, de a többi helyen is szépen szerepel, tehát elég népszerű.

Amiről még mindenképp érdemes szólni, hogy az egyik legjobb nyelv, ha nem a legjobb, a Scala, még nem valami népszerű, de szépen jön fel, már ott lohol a nagyok nyomában ;)

"alig használják"
Ez azt hiszem nem a nyelv hibája, hanem azoké, akik nem használják. :)

"annyira sokféle akar lenni, hogy érzésem szerint nem nagyon fogja kielégíteni egyik irányzat (funkcionális, OOP stb.) követőit sem."
"fogja" => már most kielégíti. Ez az egyik legjobb OO nyelv, minden objektum benne, nem nagyon találsz olyat, ami megsérti az OO elveit, szemben a Java, C++, ... nyelvekkel.
Szerintem a tisztán funkcionális nyelvekkel szemben sincs sok szégyenkezni valója.

"sokféle akar lenni"
Éppen ellenkezőleg, az egyik legegyszerűbb akar lenni. Nagyon kicsi a nyelv magja (kernel), csak annyira rugalmas, hogy ezáltal nagyon könnyen kiterjeszthető. Pl.: vegyük az operátorokat, amik más nyelveknek részei; a Scala-ban nincsenek operátorok, amik annak tűnnek azok szimpla metódusok. Ezáltal sokkal több "operátor" van benne, mert bárki írhat magának újakat.

A fent linkeltek közül, amelyik mutatja a változást (http://lang-index.sourceforge.net/), aszerint jelentősen növekedett.

Rank Name Share Last month's Last year's
share share
26 Scala 0.589% 0.372% 0.233%

Kíváncsi vagyok milyen kimutatás szerint nem változott semmit sem a népszerűsége. Tudnál linket adni?

A munkaero-piacon sem szarnyal. Ruby is eleg xarul all, pedig kb 2005-2010 kozott agyon volt hype-olva, Scala-t meg ennyire sem nyomatjak. Nemreg David Pollack (Lift web) is alaposan lehuzta...

Ha komoly (>30.000LOC), penzes projekten hasznalsz Scala-t, szerintem itt tobben is orulnenk, ha megosztanad a tapasztalatod! ;^)

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Kissé sajnálom, hogy Paul Phillips (paulp/extempore) abbahagyja a Scala fejlesztést. Szerencse, hogy mások azért hasonló tempóban folytatják (Jason Zaugg (retronym) szintén hihetetlen), és végülis a mulatságos emailek is jönnek Som Snytt-től (som-snytt).
Sok -számomra- érdekes projekt épül Scala nyelvre, így ha tehetem maradok annál. (A Scala.js pedig nagy lépés lehet a Java platformon túl.)

( Boobek | 2013. 12. 28., szo – 12:38 )

És a JavaScript megelőzte a Rubyt.

( meditor | 2014. 01. 09., cs – 09:17 )

Egy kicsit nem értem, hogy miért nem programoz mindenki 'C'-ben.

> Sol omnibus lucet.

Mert drága. Ilyen bugok kibogarászásáért nem szívesen fizet a megrendelő (márpedig előbb-utóbb ő fizeti ki):
* számábrázolás: 128+128 = 0, bizonyos esetekben, és nem szól a "runtime", hogy túlcsordult :-)
* tömbök: a[1025] = 27, külünüsen érdekes, ha az "a" csak 1024 elemű, és a legnagyobb baj, hogy nem biztos, hogy szól emiatt (jobb esetben Segmentation fault, core dump)
* kasztingolás: ((struct something*)p)->anything, és a baj az, hogy lehet, hogy működni fog, valami eredményt ad vissza, amit elmentünk az adatbázisba, csak éppen nem tudjuk, hogy miért kaptunk idióta eredményt
* szringek: toupper, tolower, ami egészen addig működik, amíg nem találkozik egy UTF-8 karakterrel (hasonló hibát riportáltam a Xamarinnak pár napja)

Ezekkel persze együtt lehet élni, ügyes programozó meg tudja oldani a fenti problémákat, de egy csapatban esetleg több, különböző képességű/hátterű fejlesztő dolgozik, és nem mindenki látja át a teljes projektet.

Fuszenecker_Róbert