HOVD 2018 - Kedvenc fordított programozási nyelv

 ( trey | 2019. január 24., csütörtök - 15:58 )
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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

D - https://dlang.org/

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

Vagy akkor már C ++ nélkül.

Ahhoz nagyon nagyon sokat kell fizetnie a megrendelonek. Foglamazhatnek ugy is, hogy van az a penz, de onkent ....

Soha nem ertem meg azt az attitudot, hogy van egy platformra c++, de nem hasznaljak, mert inkabb c.

(az alanyok tudnanak c++-ul)

Könnyen lehet, hogy az adott platformra a C++ fordító minősége csapnivaló.

+1, vagy beágyazott környezetben azzal tervez, hogy ha másik platformra kell portolni, ott is működjön. Olyanon is ahol csapnivaló a C++ minősége.

Egy ok, hogy rendszerközeli könyvtárakhoz jobb a C. Pl. C++ ABI-k gyakran nem kompatibilisek, szóval ha egy ilyen lib C++, akkor bármilyen programot ami használja ugyanazzal a fordítóval kell fordítani.

Meg lehetnek más okok is...

Az hagyján, sok esetben szándékosan van ez, cél a nem kompatibilitás: https://en.wikipedia.org/wiki/Name_mangling#Standardised_name_mangling_in_C++

Pontosan.

Másik kedvencem, amikor az exception nem megy át a másik fordítási egységbe, mert különböző clang/gcc verzióval van fordítva.

Az ilyenek miatt írják a hordozható libeket C-ben.

Minden elismerésem C-nek, én is nagyon szeretem, de azért van extern "C".
Én azért használok gyakran C-t, mert a low-end mikrokontrollereken nem ajánlott C++ (nem véletlenül íródik például STM32 HAL is C-ben és CubeMX is azt generálja).

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™

+1

Tőlem meglepő módon a C#-ra szavaztam, amit részben köszönhetnek a VS-nek is. (Persze valós dolgot vélhetőleg soha sem fogok vele megoldani.) Mentségükre legyen mondva nagy előnyük volt, mert az úton már jártak előttük.

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.

Van, aki meg azt nem érti, hogy minek más programnyelv, ha van 'C'.

> Sol omnibus lucet.

Pointerek tul sok gondot okozhatnak, de meg reference counting sincs.

Objektumok csak akkor vannak, ha nagyon akarom.

Rengeteg mas nyelvre nem jellemzo szabvanyban nem definialt, forditoprogram irojara bizott dontes (pl. i == i++).

Es meg lehetne sorolni reggelig.

Személy szerint azt gondolom, hogy a pointerek a nyelv egyik legnagyobb erőssége. (asmül: lea) Ha pedig az objectumot nagyon akarod, hát akard és lesz.

Amit 'C'-ben nem tudsz megoldani, azt más nyelven sem tudod. Szerintem...

> Sol omnibus lucet.

Nem az a kkerdes, hogy meg lehet-e oldani valamit egy nyelvben, hanem az, hogy mennyire elegans a megoldas.

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™

Néha igény lehet a mikrooptimalizáció, de általában nincs fókuszban.

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

Mármint miben erősség? Secholek és over/underflowok létrehozásában?

----------------
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.

Oké, ez valóban olyan esetnek tűnik, gondolom olyan latency-ket / real time folyamatokat is figyelembe kell venni ami általában nem jellemző.

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

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.

Elegge aktivan, halistennek. Es emellett meg kedvenc is :]

Én csak hobbiból, de lényegében más "nyelvet" nem ismerek pár régi assemblyt leszámítva (6502,68k).

68k, régi szép idők! (-::

Kaptam egyszer egy cuccot (68k), egy könyvet hozzá, és mindehhez gémkapcsozva egy feladatot. Internet még nem volt (1992--). Kamacsatkába ment földrengést vizsgálni (-::

> Sol omnibus lucet.

Aktívan fejlesztek, 10-30000 (új) sor/év elég?

Nem azt mondtam, hogy senki nem fejleszt benne. Hanem azt, hogy kiváncsi lennék, hogy a rá szavazókból mennyien.

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

Hát én nem csak rá szavaztam, de fejlesztek is benne ;)

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

90-es évek óta Delphibe ragadt fejlesztésekre. Jellemzően helyi jogba ágyazott könyvelőprogramokra, amiket nem fenyeget a globális konkurencia.

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.

Én már rég nem használom, de rá szavaztam érzelmi okokból :)

go-ban eleg kenyelmes a multithread, ugy tudom.

Masik: dockert peldaul goban irtak.

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.

Ha nincs orokles, milyen konstrukcio van a plymorphizumusra?

Java interface-ekhez hasonló interface fogalom van a Go-ban is.

Egy öröklődéstől már senki nem esik hanyat az OOP világában, miután egy jó ideje minden értelmes fejlesztő felfogta, hogy nem kell túlhasználni azt, mert annak is vannak hátrányai.

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

+1

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

Ez erdekes volt, koszi.

FreePascal/Lazarus:
- Munkaidőterminál szoftvere
- Parkolóautomata szoftvere
- Beágyazott fejlesztések (ajtóvezérlő, GPS tracker, stb.)
- Crossplatform GUI-s alkalmazások
- Mindenféle custom céges cucc

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.

legjobb vs. kedvenc?

Persze, mert erős a tippem, hogy sokan úgy szavaznak rá, hogy igazából egy sor kódot nem írtak az életükben csak "jaj, há.' a Linuxot is abban írták, akkor biztos tuti jó!".

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

Nem tűnt fel, hogy leszedik a C-ről a keresztvizet. (Nem a C-re szavaztam)

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

Attól függetlenül, hogy nem arra a nyelvre szavaztam, érdekelne, hogy neked mi a bajod azzal a nyelvvel.

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

Azzal a nyelvvel tobb baj van, mint a C-vel, ha mar itt tartunk.

Egy barom tervezte logika helyett "azert, mert azt mondtam es nekem igy tetszik" hozzaallassal.

Mesélj még kérlek. lehetőleg konkrétumokkal.

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

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.

Vegul is semmi; a Tchibot is sokan isszak, sot a Family "teteluk" egyszeruen zsenialis!!!

Aki meg kedveli a Tchibot, arrol mit kellene gondolnom?

A Pascal egy tök jó nyelv.

Köszönjük.

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

C#-ot probaltad?

Amennyire ismerem elvi okokból nem. :)

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

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

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

Mert valaki be akarta suvasztani, aztán mindkettő leginkább az Applehoz köthető manapság. Viszont a kettő együtt is még mindig a legutolsó helyen áll, szóval sok vizet nem oszt-szoroz.

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

Off:

„Sok vizet nem zavar”, vagy csak „nem oszt, nem szoroz”.

Elszállt felette az idõ vasfoga, na.

nektek vaj van a fuletek mogott

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%20arguments/Task.kt

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)

niltok :)

R.

Az nem igazán fordított.

Akkor Я.

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

Na de ez tükrözött, nem fordított.

Tessék, itt egy fordított: ᴚ

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

Az is fordított, csak a papír síkjában lévő tengely körül forgatták el.

é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."

Ez max kutatásra jó, szinte semmilyen valódi R kód nem fog futni rajta....

Aktuális kedvenc: Nim.

Még (sokkal) több jól megírt lib kellene hozzá, meg nagyobb community, de nagyon szimpatikus nyelv, már játszogattam vele. Még fogok is. :)
______________
"If you immediately know the candlelight is fire, the meal was cooked a long time ago."

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

SELECT 'BASZD MEG';

Szerintem meg lehetne versenyt rendezni ebből.
Egy adott feladatot ki tudja hex editorral binárisban úgy megírni, hogy decompile-olva a legszebb/legolvashatóbb forráskódot adja. Szerintem ez az igazi fordított programozás. :D
--
"Sose a gép a hülye."

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

> Jobb ellenőrzések, egyszerűbb kommentek, kód közben deklarálható változók

Ezeket én is szeretem, de a jobb C fordítók tudják anélkül is, hogy CPP-nek kellene lenni a fájlnak.

Az egyszerűbb komment részt mondjuk nem értem.

Gondolom a // hasznalata /**/ helyett.

Már hogy a viharba ne lenne annyira éles a határ? Egyik egy OOP nyelv másik egy imperatív, struktúrált nyelv.

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

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™

"A C hivatalosan nem tudja a // kommentet"
De, tudja, 20 éve (C99 szabvány). Ne tessék leragadni az ANSI C-nél. Tessék megnézni, mit tud 2019-ben a C, ne maradj le 1989-nél.

Gondoltam, hogy lesz, aki ideírja ezt. Nagy vívmány. De ne tessék leragadni a C99-nél, a mostani C-t a C++ fordítja.
--
ulysses.co.hu

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

> A C hivatalosan nem tudja a // kommentet

>> De, tudja, 20 éve (C99 szabvány)
> Gondoltam, hogy lesz, aki ideírja ezt.

Jól értelmezem, tudva és akarva állítottál valótlant? :-O

- - -
TransferWise

Nem jól értelmezed.

A C stílusú komment ez: /* */.
A C++ stílusú komment ez: //.

Az, hogy az újabb C is elfogadja a // kommentet, csak erősíti, az állításomat, ami arról szól, hogy a C++ az egyúttal egy jobb C.

--
ulysses.co.hu

Tehát nem C++ kódot írt. Ez most olyan, hogy ha nagyon akarok, írok BASIC stílusban kódot C#-ban is, csak minek.

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

Nem hát.

Innen indultunk:

Idézet:
A C és a C++ között nem annyira éles a határ. Sokan a C++-t egy jobb C-nek tekintik.

É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. :-)

Most ha jól értem, lényegében alkalmaztad a flyweight design patternt, ami egy valod OO pattern.

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

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™

> A böngészőn belül ez baromi lassú volt

Böngészőben csharp? Silverlight? Vagy hogyhívják? Vagy kliens-szerver alkalmazás volt megverve még üzengetősdivel is?

"Siverlight, örökölt projekt:"

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

Benéztem, köszi

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.

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

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

A folosleges gepelest ekerulendo: nem, nem is szkriptnyelv; ott sem jo az elnevezes, mert ott meg a "szkriptelesre hasznalt" hianyzik a megnevezesbol.

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.)

Ertem, de szerintem teljesen rossz a megkozelitesuk.

Ket dolgot kell megkulonboztetni:

1. programirasra/fejlesztesre hasznalt "kedvenc" programozasi nyelv

2. szkriptelesre hasznalt "kedvenc" programozasi nyelv

kb. ennyi, de nem vagyunk egyformak.

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.

Én már szkriptelésre is Java-t használok :-). Jó, néha írok bash-t is, de olyankor mindig úgy érzem, mintha sajtreszelővel maszturbálnék. Régebben írtam 1-2 python szkriptet is, de azóta rájöttem, hogy ami már python, az már inkább Java.

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.

A HUP-on vagyunk, szoval ennyire nem kell melyen elmerulni a programozasi nyelvekben.

Szoval szerintem ennel ertelmesebb szetvalasztas a HUP-ra nincs:

1. programirasra/fejlesztesre hasznalt "kedvenc" programozasi nyelv

2. szkriptelesre hasznalt "kedvenc" programozasi nyelv

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™

csak a felesleges szorszalhasogatast megelozendo, amugy egyetertunk abban, hogy nem egy hangsulyos feature.

amugy ha jol tudom a CLR-be kerult be, azert hogy lehessen rajta dinamikus nyelveket futtatni, mint az ironPython, es igy lett tamogatva a C# altal is.

Igen, csak C#-ban leginkább két okból kerül elő a gyakorlatban: COM Interop vagy "túl fájdalmas lenne itt ennyit reflectionozni".

----------------
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.

A dotnet run egy shortcut arra, hogy lefordítsa a kódot IL-re és rögtön futtassa is. Ettől nem lesz interpretált.

Szelektiv olvasas?
Biztos atsiklottal felette: "szkriptelesre hasznalt".

Ha van ra idod, akkor menj vegeig a szalon, es vilagos lesz a problemam a szavazassal (a kategorianevekkel).

ehh, a cobol megint kimaradt.. :D

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

lacsaP vagy 2aduloM

Jaj, ezt valaki tavaly is elsutotte asszem :P

++C

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.

Másodikra már nem annyira. A szintaxissal annyira el tudják barmolni a nyelveket.

Lehetne még pár népszerű programozási nyelvet felsorolni a kérdőíven.
Segítségképpen: https://www.codewars.com/