HOVD 2018 - Kedvenc fordított programozási nyelv

HUP

assembly (bármely architektúra, bármely dialektus)
3% (21 szavazat)
c
23% (149 szavazat)
c#
11% (73 szavazat)
c++
18% (117 szavazat)
go
8% (49 szavazat)
haskell, ocaml, f#, scala (statikusan tipusos funkcionalis nyelvek)
4% (26 szavazat)
java
19% (124 szavazat)
kotlin
3% (19 szavazat)
objective-c, swift
2% (12 szavazat)
pascal
8% (54 szavazat)
Összes szavazat: 644

( fdavid | 2018. 12. 29., szo – 09:38 )

D - https://dlang.org/

Kinomban megint a c++-ra szavaztam, pedig nem igazan szeretem, csak meg mindig az egyik legjobban hazsnalahto nyelv beagyazott kornyezetben.

( saxus | 2018. 12. 31., h – 07:28 )

Kiváncsi vagyok, hogy azok, akik C-re szavaztak, azoknak vajon mekkora része fejleszt is aktívan és mekkora része hajbi féle megmondóember. :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azt még érteném, ha erre mindegyik választási lehetőségnél kíváncsi lennél. Így viszont csak arra tudok gondolni, hogy a C jobb helyezést ért el, mint a Te kedvenced, és ezt nem vagy képes megemészteni.

A C# esetén Oregon már önként jelezte ezzel kapcsolatos álláspontját. Úgyhogy beszállók én is: Mivel az elmúlt évben kb. 500 sornyi C kódot írtam, mert inkább a Python-t választottam általában, így ebben az évben nem is adtam le szavazott ebben a kérdésben. Csak benéztem a topikba, hogy megnézzem a szavazás állását. Ja, és ugyan nem ide tartozik, de nem vagyok fejlesztő. Tehát a definíciód szerint hajbi féle megmondóember vagyok. :-)

Teljesen irreleváns, hogy mi a kedvencem (C#-ot jelöltem, sejtettem, hogy itt nem lesz egy közönségkedvenc nyelv és egyébként én is tudnék szidni benne dolgokat neked, ha kell), már csak azért is, mert a fenti listából vagy 5-ben is hajlandó lennék dolgozni. (Sőt, lepődj meg, olyan nyelvekben is dolgozok, amit rühellek.)

Minden más választási lehetőségnél azért nem érdekes számomra, hogy ki mennyit fejleszt, mert se C#, se Java, se Pascal kapcsán nem hangzik el olyan mondat, hogy mindent abban kellene megírni és akkor minden csodás és überoptimális lenne.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

„sejtettem, hogy itt nem lesz egy közönségkedvenc nyelv”

Én úgy látom, hogy az eddig szavazatok alapján elég szép eredményt ért el a C# is. Különösen akkor, ha azt is figyelembe vesszük, hogy egy elég fiatal nyelv.

„nem hangzik el olyan mondat, hogy mindent abban kellene megírni”

Én ilyet nem látok a szavazás kiírásában. Sőt a C is a Te hozzászólásodban került először szóba. Másrészt – most nem fogom megkeresni – nekem úgy rémlik, hogy a HUP-on régebben volt néhány olyan vélemény, hogy a Java a jövő C-je. Attól, hogy valaki valamit kijelent a HUP-on (vagy bármelyik más fórumon), még nem kell frusztráltnak lenni.

Egyébként pedig ez a szavazás arról szól, hogy aki akar, szavaz arra, ami neki szimpatikus. Arról nem szól, hogy rendszeresen programozni kellene azon a nyelven. Ugyan már írtam, hogy ebben a kérdéskörben nem szavaztam, de: Néhány éve ránéztem a Haskellre, és nagyon szimpatikus volt. De akkor nem volt rá elég időm, hogy mélyebben megismerkedjek vele. Illetve az is világos volt számomra, hogy a hétköznapi életben sokra nem mennék vele, mert ritkán találkozók olyan feladattal, ahol jó választás lenne. De tulajdonképpen ez a kedvenc nyelvem. Annak ellenére, hogy csak érdeklődés szintjén foglalkoztam vele. Ha mindenképpen szavazni akartam volna, akkor ezt jelöltem volna be.

Egy másik példa az adatbázis-kezelő szavazás. Most 362 szavazatnál tartanak. Meg lennék lepődve, ha a HUP-on ennyien foglalkoznának aktívan, rendszeresen adatbázis kezeléssel. Persze ha az is számít, hogy a kedvenc webes keretrendszer mit használ a háttérben, akkor még kevés is a szavazat.

Akár foglalkozhat is ennyi ember rendszeresen adatbázis kezeléssel. De akkor honnan nézve kedvenc. Egy nagy multi alkalmazottjaként? Akkor Oracle enterprise és kevés problémád lesz, ha pedig lesz ott egy jó support. Ha neked kell a számlát fizetni utána akkor már más szempontok is felmerülnek.

En azt nem ertem egyik evben sem, hogy megis mi oka van barkinek is jobban szeretni a C-t a C++-nal, plane ennyi embernek. Tenyleg van, aki jobban szereti a *allocot, mint a lehetoseget arra, hogy legyen *alloc/free MELLETT new/delete?

(Amugy jol tudom, hogy ha nem hasznalsz Exceptionoket, meg egy furcsa modon a template-eket, akkor a vegeredmeny performance szempontjabol is ugyanolyan optimalis, ha a C koddal azonos C++ kodot forditasz es futtatsz?)

Masik erdekesseg: C programozo ismeroseim atlagosak, de a C++ programozo szemelyes ismeroseimet a legjobb programozoknak tartom.

Hát ezzel nem teljesen értek egyet. Az egy dolog, hogy egy bitrotátció nem elegáns, és egy másik dolog, hogy mennyire hasznos. Tényleg mennyire elegáns ez egy magas szintű, úgynevezett "elegáns" nyelven? Az nem ér, hogy van az adott nyelvnek 'C' vagy assembly leágazása, konkrétan az adott nyelv megoldása az érdekes!

Vegyük már észre, hogy a konkrét architektúrához való hozzáférés lehetősége az SZABADSÁGFOK, a magas szintű nyelvek viszont bezárnak egy skatulyába. Nyilván erőforrás megtakarítás a hordózhatóság, ezzel egyet is értek, ugyanakkor a gagyisodás egyik szerencsétlen komponense. [Ez most majdnem hajbazeri volt (-::]

> Sol omnibus lucet.

Amiket itt emlegetsz az az embedded, realtime, esetleg gaming világban érvényes, az általános üzleti alkalmazások világának szótáraiból hiányoznak ezek a dolgok. (architektúra, cpu-optimális kód, bitrotáció, assembly..)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Légy erős, az általános üzleti alklmazások világa szótárának értelmező részében ott lapul a bitrotáció (is). Én tényleg nem akarom bántani a hardozhatóságra esküdő szakikat, mert ez is egy út, nem rosszabb, nem jobb, de azt látni kell, hogy máshová visz és itt is, ott is lehet zseniálisat alkotni.

Valójában a lényeg a kockás papíron dől el, ha érted mire gondolok (az én mottóm ez: ha az időviszonyokat tisztáztad, onnantól favágás).

> Sol omnibus lucet.

Mondjuk azt azért ennyire markánsan nem jelenteném ki, hogy a CPU optimalalizáció egy általános célú üzleti alkalmazásban nem tud néha igény lenni. Akár még olyan appnál, amit kifejezetten arra terveznek, hogy skálázódjon a cloudban, ha kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Aki nem tud pointerek használni, ne használja. Azt azért nem árt tudni, hogy amikor egy tömbelemre hivatkozol bármely nyelven, akkor az azért egy pointer művelet. Nem gondolnám, hogy megköti a programozó kezét, hogy 'C'-ben ez sokféleképpen és rekurzívan (pointerre mutató pointer) hivatkozható.

Tulajdonképpen az a kérdés, hogy egy adott nyelv megengedi-e egy változó címének betöltését egy másik változóba. Mert itt kezdődik a programozói szabadság. Szerintem...

> Sol omnibus lucet.

Tisztában vagyok azzal, hogy a referenciák csak egy absztrakció a pointerek felett. Ezt inkább azoknak mond akik miatt a halom CVE és segfault hiba van, mert azt hitték, hogy olyan egyszerű és triviális a memóriával bánni.

Egyébként meg akarom elrontani az örömünnepet, de amit te akarsz azt referenciákkal is meg lehet oldani magas szintű nyelvekben, nem kell ahhoz pointer.

Egyébként meg nem annyira baj az, hogy ha egy picit meg van kötve a fejlesztők keze, mert a tapasztalat igencsak azt mutatja, hogy nem szabad őket teljesen felügyelet nélkül hagyni, mert hamar elkezd elbúrjánzani a spagetti meg a sechole és a segfault melegágy (ld. CVE-k és fagyó programok száma).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kérdés hogy mennyire lesz elegáns, újrafelhasználható, refaktorálható, tesztelhető, dokumentálható a kód. Egy jókora üzleti alkalmazáscsokrot a büdös életbe nem iratnék C-ben senkivel, mert ha máshogy nem, hát gazdaságilag totálkár lesz az egész (értsd Java/Kotlin/C# vagy bármi értelmesebb high level nyelv nélkül csiga lesz a folyamat, és fejlesztőt is nehezebben találsz hozzá).

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Egy komplett tőzsdei alkalmazás írtam 'C'-ben. Vizualizáció, tőzsdei adok-veszek, predikció, szimuláció, stb, stb, minden ami ehhez kell. Nem is lehetett volna másban megírni 3rd party okok miatt, ezt most had ne részletezzem.

A szűretlen tőzsdei kommunikáció annyira low-level, hogy azt elképzelni sem tudod, ha nem írtál még ilyet (byte/bit szinten van megadva hogy mi micsoda).

> Sol omnibus lucet.

C++-ban ott van a rengeteg feature, ami felesleges, viszont a programozók nagyrésze rosszul használja/nem érti. A legtöbb cégnél bevezetnek egy részhalmazt, amit lehet használni (állítólag). Vagy ott vannak az operátor overloadok, ami miatt aztán végképp el lehet tévedni, hogy mi mit is jelent. (Persze ugyanezt az érzést tudják a C makrók is hozni :-)

Vagy ott van a rengeteg inkompatibilis library: STL, boost, stb, amik között nagyon nehéz az együttműködést megteremteni, és jókis dependency version helleket lehet csinálni. Más által írt projektet lefordítani sem triviális, ha éppen nem ugyanazon a verziójú oprendszeren vagyunk.

Ezek lehetnek szempontok, hogy miért nem szereti valaki a C++-t. Disclaimer: sosem C++-oztam komolyan, mert ami összetettebb, azt Java-ban írom, ami meg hardverközelibb azt C-ben Java alá, vagy önállóan. Ezért sosem vettem a fáradtságot, hogy jobban beleássam magam mit tud a C++, csak messziről nézve ezt látom.

( fdavid | 2018. 12. 31., h – 09:44 )

Erdekes lenne tudni, hogy a got es a pascalt milyen feladatokra hasznaljatok.

Pascalra szavaztam. Személy szerint semmire, nem is vagyok fejlesztő, ha kódolni kellene valamit akkor JAVA-ban állnék neki.

Első prognyelvem az volt, általános iskolában hétvégéket végigkódoltam benne. Csomó apró progit írtam, párhuzamos porton mindenféle hw-t illesztettem hozzá. Egyszerűen szeretem.

@@
"You can hide a semi truck in 300 lines of C."

Még ifjúkoromban kaptam egy TP6 könyvet. Akkor már kb 1 éve volt PC-m. Addig csak C64-en basic és assembly volt amiben játszottam. A TurboPascal maga volt a "húB+ de király" aztán a Delphi, az már csili-vili volt. A többi nyelv ha jól emlékszem közelében sem járt.
Vagyis első igazi "nagyszámítógépes" nyelv volt és kedvenc maradt. Ma már nem használom, nincs mire.

Ha az ember azt gondolná, hogy a fordított OOP nyelveknél a C++ és a Java homok egyenest ellentétei egymásnak, akkor a Go megmutatja, hogy vannak még egészen más utak. OOP nyelv öröklődés meg konstruktor nélkül. Néha a Go puritánsága már-már az elmebetegség határát súrolja: nincs enum, nincs konstans pointer. De alapvetően szerethető, sok feladatra igen hatékony nyelv, amiben nehéz hibázni. Mármint ha lefordul a kód, mert minden apró szösszenetet a fejedhez vág a fordító.

Cloud native (pl. RESTful) alkalmazások írására nem is tudok jobb nyelvet elképzelni pl. gorilla/mux alapokon (Python Flask megfelelője). Statikus fordításnál simán lehet scratch (OS alap nélküli) konténert gyártani belőle, ami aligha mondható el mondjuk a Pythonról.

kvazi mas szintaxis ugyanazzal a szemantikai tartalommal, ami nagyon keves helyen hozzatesz az elodeihez (lehet kulonallo fuggvenyeket irni[1] vs Java/C#, tobb visszateresi erteket meghatarozni[2], channels[3]), de leginkabb csak elvesz abbol, amink eddig volt.

Nem feltetlenul rossz ez minden esetben, parametrikus polimorfizmus (generics) es subtyping/orokles egy helyen letezese eseten peldaul foglalkozni kell ko- es kontravarianciaval ami szerintem legtobbszor nem eri meg, de hogy ne legyen se orokles, se generics...

Masreszt nincs try-catch sem, amit en egy eleg implicit dolognak tartok, es ha valamikor, akkor exceptionok eseten amik le tudjak allitani az egesz process-t nem gondolom hogy jo dolog lenne ez az implicit jelleg [4], de hogy a fenti hianyossagok miatt nem lehet pl. Either-t irni a problema megoldasara, es ugyanazt az "if err != nil {return err}" boilerplate-t negyezerszer meg kell ismetelni, es ha nem lenne eleg, rad van eroszakolva, hogy ez minimum 3 sorban tortenjen mindenhol...

Gondolom lehetne meg sorolni.

A go egy osszerakott nyelv. Alig vannak peldaul Javascriptes vilagra jellemzo, khmmm, mondjuk ugy, sajatossagok, nem kapok tole sikitofraszt, tudok vele elni.

Masrest viszont, nem tekint hasznalojara felnott, felelos szakmai donteseket hozni kepes emberkent, ehelyett raeroszakolja a lowest common denominator kollegak szamara nem banto massziv boilerplate kodok irasat ahelyett, hogy evtizedek ota ismert es kiismert absztrakciokat engedjen letrehozni, amik ezt a sok zajt eltuntetnek.

Sok mindenre jo, vegulis, turing-complete, es nincs vele nagy bajom, mert legalabb ossze van rakva. De nem latom be, hogy lenne celja amellett, hogy el tudj menni a foterre, behuzni 100 embert, aztan abbol 14 ir majd valamilyen kodot 4 nap mulva, a tobbit meg el lehet engedni. Tehat a szakma kommoditizaciojan kivul. [5]

Szerintem a Go amugy tisztelt es nagytudasu veteranok 1984-be (1 evvel C++ elott) valo visszateres iranti vagyanak, azzal a korszakkal szembeni nosztalgianak a gyumolcse, mikozben azelott is leteztek nagyon jo alternativai mondjuk a C-s [6] vagy kesobb Javas vonalnak, hat meg azota. Egy a C++-nal joval emeszthetobb C2.0 ami a C++ miatt akkor nem szulethetett meg. 34 evnyi visszalepes, es onnan masik iranyba leagazas anelkul, hogy az azota tortenteken felul barmit is innovaljon, sot, inkabb az azota tortenteket is ignoralja. A management meg kajalja, mert a szakmai munkaero kommoditizaciojaban sok jot talalnak (hosszutavon alacsonyabb berek, de pl. konnyebb embert talalni is).

[1] - go terminologiaban: nem csak olyan func letezik aminek van receiver-je
[2] - nem biztos hogy helye van a listan, konnyen lehet, hogy tuples jobb lenne itt, foleg ha first class nyelvi elem, de libkent is
[3] - szinten kerdeses, mennyire jogos ez, Marlow "Parallel and Concurrent Programming in Haskell" concurrent reszenek elso ket oldala meghaladja a channel-eket. Eleg fajdalmas is vegighallgatni n-edszer, amikor valaki elkezdi visszabofogni a channels hype-ot, ami a legtobb Go-val ismerkedo embernel megtortenik a folyamat soran
[4] - a checked exceptions viszont nem megoldas, mert egyreszt hasznalhatatlanna teszi a Java8-at, masreszt, nem kenyszeriti ki a Runtime Exception-ok kezeleset
[5] - ja meg hogy Rob Pike valahol kielhesse a "Communicating Sequential Processes" bubujat, de goto [3]...
[6] - akkori hardver megkotesei nem erv, tekintve hogy ez egy 21. szazadi nyelv kritikaja, szoval bar jogos, irrelevans

( meditor | 2018. 12. 31., h – 10:31 )

Azt nem értem, hogy a 'C'-röl mindig leszeditek a keresztvizet és mégis az kapta eddig a legtöbb voksot. Érzek valami kis disszonanciát a 2 tény között.

> Sol omnibus lucet.

( uid_17784 | 2019. 01. 01., k – 21:12 )

Pascal, mint kedvenc programozasi nyelv.
Akik erre szavaztak, azoknak gratulalok!

Nem tudom kire gondolsz, amikor lebarmolod az illetot; kicsit durva a fogalmazas.

A Pascal alatt ugye senki sem a Turbot vagy a Deplhi szart erti, mert akkor barom az, aki belistazta a szavazasra...

Szoval nem a nyelvvel van a baj, hanem azzal, aki Tchibot iszik, es meg meg is jeloli egy ilyen szavazason, hogy o azt kedveli.

( uid_4263 v | 2019. 01. 02., sze – 15:35 )

Egyelőre a java, jövőre remélhetőleg a kotlin :) lenyomtam egy kurzust és tetszett, de azért nem értem még a magabiztosságot.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Próbáltam 2006 környékén, elvégeztem egy egyetemi tárgyat ami róla szólt, azóta se kép se hang. :) De biztos jó. Én a JVM irányába mozdultam el munkaügyben, így sosem jön szembe.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

( segabor | 2019. 01. 03., cs – 13:23 )

Obj-C és Swift vajon miért került ugyanabba a kalapba, mikor két teljesen más nyelvről van szó?

--
Kinek nem inge, ne vegye gatyára

Pedig a Swift egy eleg komoly nyelv lett, orom hasznalni! Meg megnezem majd a Kotlint is, gyakorlatilag ua. szintaxis, szoval ha az is oke, akkor le vagyok fedve full-stack.

(Remelem a full-stacket nem csak frontendesekre hasznaljak... az, hogy a UI miben van, teljesen mindegy, es azok kozul is a web az egyik legrosszabb valasztas :( legalabbis technologiai oldalrol)

Szerk: es van benne named argument \o/

https://try.kotlinlang.org/#/Kotlin%20Koans/Introduction/Named%20argume…

Hany helyet kene a listaban elfoglalnia annak a 8 szavazatnak, egy nem eleg? Igy is ez a legjobb jelolt egyelore a kilovetesre HOVD 2019 soran, ha lesz erdekesebb opcio.

Ha meg erdekel, kulon-kulon mennyit ernenek el ezek a nyelvek: 0-tol 8-ig valamennyit, ezzel a valasszal en meg lennek elegedve, eleg pontos ez igy. Nyilvan 60 szavazat eseten maskepp gondolnam.

Kompromisszumokat kell kotni, eleg csak ranezni a funkcionalis nyelvek kategoriajara, ami egy komplett paradigmat kepvisel, nagyon kulonbozo nyelvekkel (pl. scala c-like syntax, f#-nal nincs higher kinded types, haskell lazy by default, stb).

(Attol meg jogos, hogy ket elegge mas nyelvrol van szo, csak az onmagaban meg nem eleg indok arra, hogy egy kozos vonas menten ne keruljenek egy kalap ala)

és melyik a preferált fordítód hozzá? :D

"all submitted complaints will be forwarded to /dev/null for further investigation"
"ez ilyen hippi kommunás felfogás, ahogy Stallman sámán módjára dobol a nagy hasán, hogy GNU, free software, free as free beer."

( carlcolt | 2019. 01. 04., p – 11:39 )

Nekem nem kedvenc forditott, hanem kedvenc ORDITOTT nyelvem van: SQL

SELECT 'BASZD MEG';

( mrev | 2019. 01. 04., p – 13:38 )

A C és a C++ között nem annyira éles a határ. Sokan a C++-t egy jobb C-nek tekintik. Én például a C programokat azonnal átírom C++-ra, ha a kezembe kerülnek. (Jobb ellenőrzések, egyszerűbb kommentek, kód közben deklarálható változók, stb.) Ugyanakkor a C++ modernebb dolgait kerülöm. Szerintem a C++ el lett baszva, feleslegesen túl van bonyolítva, az STL-lel csak a baj van. A Stroustrup féle 5 kilós könyv már mutatja, hogy itt valami nincs rendben. Egy normális nyelv leírására elég kéne legyen egy 50 oldalas füzet.
--
ulysses.co.hu

De ha C++ forrásfájlba nem írod le pl. a class szót? Meg egyáltalán csak olyan forrást írsz, mint amit C-ben?

Emlékszem, kicsit több, mint 20 éve pl. volt egy kollégám, aki C++ fordítóval fordította a C forráskódját, és csak olyasmiket használt, mint pl. inline

Igen, 20 éve már a C szabvány is tudja, meg gondolom manapság már ki se kell írni, mert ügyesen kitalálják optimalizálás közben a fordítók. Ez csak egy példa volt.

Az ő kódja C fordítóval nem fordult le, csak C++ fordítóval, viszont nem volt benne semmi OOP.

Kiírom a class-t, mert használok osztályokat. De például STL helyett printf-fel írom a debug üzeneteimet.

Egyszerűbb kommentek: A C hivatalosan nem tudja a // kommentet, meg még egy sor hasonló egyszerű dolgot. Némelyik fordító tudja, némelyik nem.

H. Schieldtnek volt egy könyve a C++-ról kb. 30 éve. Akkor (a nyelv kialakuásának hajnalán) azt írta, hogy a C++-ban az a nagyszerű, hogy egy programozó sokkal nagyobb programot tud uralni, mint C-ben.

Aztán 20 éve viszont azt olvastam, hogy nagy projeketeket nem mernek C++-ban írni, mert a nyelv bonyolultsága miatt instabilitástól tartanak. A programozók már nem tudják, hogy valójában hogyan működik a C++ futtatórendszere. Például pontosan mit csinál egy new. Hogyan indul egy thread.

Szóval C++ osztályokat használok, C++-szal fordítom a síma C-t is, de mégis a C-re szavaztam, mert C++ modern rétegeit nem szeretem.

--
ulysses.co.hu

Egyébként ezzel nagyjából leírtad azt is, hogy miért fejlesztenek sokan Java-ban, C#-ban, pythonban vagy más magas szintű nyelvben. C++ annyira általános akart lenni és mellette nem nyújtott elég támogatást egy csomó mindenben, közben a többi nyelv meg elhúzott mellette.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Van még egy hozzáfűzni valóm: Schieldt azt tartotta fontosnak, hogy egy programozó minél nagyobb programot tudjon uralni. Ezt én is fontosnak tartom, mivelhogy kevesen dologozunk sok programon, és a programjainkat sok éven át fenn kell tartanunk. Ez azonban nem a mai trend. A mostani IT vállalkozások inkább azt szeretik, ha a programozóik csereszabatosak, senki se legyen nélkülözhetetlen, könnyen ki lehessen rúgni bárkit. És ki is rúgnak bárkit, mivel ez az egyetlen teszt a csereszabatosság ellenőrzésére. Egyedüli vigasz, hogy a projekt managerek és IT igazgatók még csereszabatosabbak ...
--
ulysses.co.hu

Én írtam kvázi C kódot C#-ban.
Siverlight, örökölt projekt: rakat ojjektum egymásban ami mindenféle csiivili izéket csinált volna ha az ember rátenyerel pl. a nyíl gombra.
Kiderült, hogy a sok esemény indítás és elkapás nagyon drága, képregény lett a smooth élmény helyett.
Én legeneráltam az ojjektumokat, a címeiket beraktam egy fix két dimenziós tömbbe, és amikor az egyik csinálni akart valamit, akkor nem a windowsos esemény sort használta, hanem a szomszédjának a címén közvetlen hívott meg egy függvényt.
Nem elegáns, de szépen működött.
Kicsit büszke vagyok rá, de őszintén remélem, hogy aki utánam megkapta a projektet nem tudja a címemet. (Bár nagyon szépen kommenteltem, szóval 8 általánossal és egy év programozási tapasztalattal nem kéne hogy gondot okozzon.)
De tény, hogy a C# szellemiségével teljesen szembe megy. De ilyen azélet, néha a szembe szélbe kell.. izé.. kiengedni a fáradt gőzt. :-)

Utánanéztem, hogy mi ez, - botcsinálta programozó vagyok, sajnos nem vagyok ideológiailag elég képzett, - és valami hasonló volt benne, de leginkább az volt a lényeg, hogy az elemek (egy naptár napjai) mind tárolták a 4 szomszédos elem címét.
Korábban arra gondoltak, hogy nyíl billentyűre dob egy eventet a nap, és az azonosítókból majd kiderül, hogy melyik másik napnak kell magára vennie az input fókuszt. A böngészőn belül ez baromi lassú volt. Némi performancia analízis megmutatta, hogy ez zsákutca. Ezért úgy csináltam, hogy kidobtam a kódbázis 75% -át, mert nem volt rá szükség, és gomb lenyomásra mindegyik közvetlen címezte a mellett lévőt, hogy vedd magadra a fókuszt.

A régi kódbázis annak rendje és módja szerint nevesített entitásokkal működött, legalább egy GetValami() kellett hogy kapj egy objektumot, máshol nem volt ilyen, hogy közvetlenül címezve használtak volna valamit.

C, C++ esetén tok normális a pointerek használata, C# -ban annyira már nem szokás, persze projektje válogatja. :-)

Ja, tehát retard módon tervezték meg a szoftvert. Ez nem a pointerek hiányának oka. (Egyébként C#-ban van referencia meg pointer is, szóval...)

" C# -ban annyira már nem szokás"

Ez meg végképp WTF. Mi az, hogy nem szokás? Egy objektumra mutató változó, property, stb. mégis mi? Egy referencia. Avagy durván fogalmazva, típusbiztos, objektumbiztos pointer. Az meg azért elég sűrűn használt dolog.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( novalis65 | 2019. 01. 04., p – 15:00 )

Hobbi programozóként a Go-ra szavaztam. Egyszerű, gyorsan tanulható, nagy cég áll mögötte, hamarosan jön a 2.0 verzió. Vannak benne pointerek (ha valakinek az kell), de nincs pointer aritmetika. Nincsenek osztályok, de van interface, struct, öröklés megoldható. Van Garbage Collection, így azok kedvence lehet, akik nem szeretnek a manuális memória kezeléssel foglalkozni. Függvényeknek lehet több visszatérési értéke. Nyilván van több hátránya is a C, C++-szal szemben,de persze előnyei is.
Másik kedvenc a D, amit itt nem is látok. Tudom, hogy nem terjedt el széles körben, mert nagyrészt C-t, C++-t, Javat meg C#-t használnak üzleti, stb. fejlesztésre. De azért meglepő, hogy nincs is rajt a listán. Van hozzá három fordító is: dmd (referencia compiler), gdc, ldc.
Nem látom a Rust-ot sem. Igaz, viszonylag új nyelv, de rendszerprogramozóknak jó választás lehet. Nem "garbage collected", de az ownership alapú biztonságos programozás jól jöhet.
Szintén nem szerepel a Fortran. Bár régi nyelv, azért még sok helyen használják, főleg az idősebb szakik. Tudományos számításokban még mindig etalon, bár sok alkalmazási területen felváltotta a C/C++, Python, Julia. Gondolom, a fiatalok már nem nagyon tanulják. Most jött ki belőle új szabvány.
Megemlítem még a Crystal-t, ami a Ruby-szerű, egyszerű szintaxisa miatt tetszik. Windows-változata tudtom szerint még nincs, de ez engem nem is zavar :)

Szintén nem szerepel a Fortran.

Nekem már nem csak a napom, de az egész hetem el van rontva, amikor fortan kódhoz kell nyúlni. Gondolom azért nem szerepel, mert a címben kedvenc programozási nyelvekről van szó. :)

Van az a mondás, hogy egy jó programozó bármely nyelven tud fortran kódot írni.

Ez nem nagyon régi Fortran-kódokra vonatkozik? Azért 77-től kezdődően lehetett benne civilizált (struktúrált) kódot írni, nem feltétlenül kellett keresztbe-kasul ugrálni goto-kkal.

Amúgy most láttam egy kifejezetten érdekes programot: az eredeti AT&T Unix források között van egy structure nevű program, ami fog egy Fortran 66 kódot, megcsinálja magának a flowchart-ját, és kifejezi FOR-ral és IF...THEN...ELSE..-szel. Sajnos a kimenet RATFOR, viszont az ötlet, meg az, hogy ez működhet, igazán figyelemreméltó.

Fortran szabványosítása szép utat járt be. Az első szabványos verziókhoz képest az átláthatóság is sokat javult:

Fortran 66
Fortran 77 - sok kóddal találkozhatunk még ma is
Fortran 90 - amiben megjelent olyan is, mint struktúra
Fortran 95
Fortran 2003
Fortran 2008
Fortran 2018 - nem állt le a nyelv fejlesztése

Bővebben: ISO/IEC 1539-1:2018

Valóban. Sajnos a 90-nel (eredetileg 8X) addig szarakodtak (a compilereket szállító cégek nem akartak semmi újat, a felhasználók meg egy modern nyelvet akartak), hogy a user base nagy részét elvesztették, amikor a CERN az LEP-hez (az LHC előtti gyorsító) a kiértékelés nyelvének a C++-t választotta (és a fizikus közösség nagy részét magukkal húzták), a CERNLIB-et (szép nagy numerikus algoritmusgyűjteménnyel) dobták.
Ráadásul talán még most is hiányzik belőle egy csomó hasznos dolog, pl. a template function (pedig a numerikus kódokban aztán igazán sokszor előfordult, hogy ott volt ugyanaz a szubrutin, REAL, REAL*8, COMPLEX és COMPLEX*16 változatban).
Az sem a Fortrannak dolgozik, hogy ma már elég kevés cég él numerikus számításokra szánt gépekből és azokhoz szánt compilerekből, amúgy meg a C++ felhaszálói bázisa nagyobb, arra több időt fordítanak. Eddig 1-2 próbát tettem ugyanazt megírni C++-ban és Fortranban, és a C++ változat többnyire egy hangyányival gyorsabb lett.

( uid_17784 | 2019. 01. 04., p – 15:06 )

Azt tudja valaki, hogy a "forditott" miert kerult be a megnevezesbe?

Pl. az assembler miota fordit, es Python miota nem programozasi nyelv?

ez egyébként tavaly is vita volt, s szerintem ott arra jutott a közösség, hogy az asm igenis fordít :)

de röviden: kellett valami megkülönböztetés, s ha jól sejtem, az lett, hogy van-e bármilyen köztes teendő a kód megírása és a futtatása között, vagy csak odaadom egy interpreternek a kódot, s fut. (nyilván a legelterjedtebb változatban.)

Es igen, a Python mindket listan szerepelne; mert igy van ertelme a szavazasnak.

Van, aki szkriptelesre hasznalja,

van, aki nagy rendszereket fejleszt vele,

meg vannak, akik mindket helyen hasznaljak (szkriptek irasara is, meg programok irasara is).

Szerintem ertheto ez a megkozelites, a jelenlegi kategorizalasnak nem latom ertelmet.

szerintem inkabb (elsosorban) statikus programmozasi nyelvek es (elsosorban) dinamikus programmozasi nyelvek kategoriaja kene hogy legyen a ket megelvo helyett.

Azt irom "elsosorban", tekintve, hogy olyan dolgok, mint C#-ban a dynamic vagy tobb dinamikus nyelvben a gradual/optional typing kisse elmosta a hatarokat, szoval anelkul lehetne szorszalat hasogatni.

Miert? Van Haskell-nek REPL-je es lehet is stack-et hasznalva script fajlokat irni, valamint libek mint a Shelly, turtle vagy masok, Scala-ra is igaz ez, ott a REPL, de a worksheets es az ammonite is, sot, ha jol tudom Javanak is van REPL-je mar. Igazabol mindket kategoriaban megfernenek. A statikus/dinamikus kulonbseg azert a hatarok nemi elmosasodasa utan is joval ertelmezhetobb.

A masik ok, hogy a programnyelvek szempontjabol erdekesebb lehet tipusossag alapjan kulonbseget tenni, mint aszerint, hogy hasznaljak, foleg amikor a hatarok ennyire el vannak mosodva.

C# dynamicot azért ne dimmenzionáljuk túl. Tény, hogy ott van a nyelvben, de attól még static typing van a C#-ban. Az inkább csak egy "hack" a rengeteg reflection elkerülése végett és szvsz, ha nem kellett volna COM Interop, bele se került volna a nyelvbe.

Nagy ritkán persze hasznos.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

dotnet run

Odaadtam neki a kodot, aztan nincs mas teendom, fut.

Akkor most a C# szkriptnyelv?

Nyilvan nem, de szkriptelni lehet mar egy ideje C#-pal is, es ezek szerint ott lenne abban a szavazasi kategoriaban is; tolem biztosan kapna 1 szavazatot, mert eleg kenyelmes, hogy a szkriptelesre meg prograqmozasra is ugyanazt a nyelvet tudom hasznalni.

( krumplicska | 2019. 01. 05., szo – 16:37 )

kötősuli? egy sima, egy fordított?

( kleinie | 2019. 01. 17., cs – 07:12 )

Nem vagyok programozó. Sőt, pár sornál hosszabb programot sem írtam még. Sok nyelv tanulásának álltam már neki, de valahogy mindig arra jutottam, ha egyszer programot írnék, azt valamilyen Lisp dialektusban tenném.
Szerk.: Valaki lentebb említette a Julia-t, elsőre tetszik.