HOVD 2017 - Kedvenc fordított programozási nyelv

 ( trey | 2018. január 10., szerda - 10:19 )
assembly (bármely architektúra, bármely dialektus)
3% (21 szavazat)
c
22% (141 szavazat)
c#
12% (75 szavazat)
c++
19% (123 szavazat)
go
7% (44 szavazat)
haskell, ocaml, f#, scala (statikusan tipusos funkcionalis nyelvek)
4% (28 szavazat)
java
22% (140 szavazat)
kotlin
2% (12 szavazat)
objective-c, swift
2% (14 szavazat)
pascal
8% (51 szavazat)
Összes szavazat: 649

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

Visual Basic?

Mint fordított programozási nyelv?

Igen. Ámde ha ez elsőre nem világos, esetleg szoftvermulti barátod keresője tudott volna segíteni.

"Though VB programs can be compiled into native code executables from version 5 on, they still require the presence of around 1 MB of runtime libraries. Core runtime libraries are included by default in Windows 2000 and later (...)" - Wikipedia

Ha esetleg mégis arra gondoltál, hogy (5-ös verzió előtt) nem fordul le natívra, akkor pedig kezdhetted volna a C# és a Java nyelvekkel, amikből ha akarsz se tudsz natívat fordítani. Persze azok nyilván túl mainstream-ek, meghát megjelentek a szavazásban, akkor biztos fordított nyelvek.

Egyszóval, köszönöm, hogy utánanéztél, mielőtt elkezdtél kötekedni. Ja nem.

Egyrészt a szavazásban nincs arról szó, hogy natívra fordítják vagy nem natívra, hanem a fordításon van a hangsúly.
Másrészt mind a C#-ot, mind a Java-t (vagy ExcelsiorJET-tel, GCJ-vel /ezt már nem fejlesztik/) lehet natívra fordítani.

Idézet:
Egyrészt a szavazásban nincs arról szó, hogy natívra fordítják

Ezt én is észrevettem, csak próbáltam találgatni, hogy Manfréd Mérnök Úr mire gondolt, mikor kérdőre vont, hogy a Visual Basic hogy lenne fordított nyelv. Hiszen a VB-t már kereken 20 éve lehet natívra fordítani, fordítani (P-kódra) meg már kezdetektől fogva.

Speciel arról én se tudtam, hogy a C#-ot is lehet, de ahogy elnézem a dokumentációt, nagyjából 2-3 éve jelent meg ez a feature. Annak már kevésbé örülök, hogy kezdetektől fogva nem natívra fordították. Rengeteg munka- és megawattórát lehetett volna megspórolni. A kevesebb erőforrással rendelkező, régebbi gépek sokkal jobban megbírkóztak volna a feladattal. Az ExcelsiorJET-et meg nem tudom elképzelni, hol használják production-ben. Esetleg tudsz erről valamit?

Rengeteg munka- és megawattórát lehetett volna megspórolni.

Rengeteg helyen bizonyították az ilyen programok, hogy ez nem egészen így van. Nem használnak több memóriát, közel natív sebességgel futnak, sőt sok esetben le is gyűrik a natív megoldásokat, ...
Nézd meg pl. ezt a web framework benchmarkot, az első 4 helyen Java/Scala megoldások vannak, de az első 10-ből is csak 2 natív van (C++, C).

Ez nyilvánvalóan erősen alkalmazásfüggő, sok esetben meg sok(száz)szor annyi memória és futási idő kell nekik.

+1

A linkeden látható 6 tesztből egyre ("JSON Serialization") igaz amit írtál, a maradékból 4-szer egyértelmű natív fölény van, némi Java-val meghintve.
Ennyit a "sok esetben le is gyűrik a natív megoldásokat"-ról...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Azt hiszem a lényeg nem ment át, nem azt mondtam, hogy minden esetben vagy a legtöbb esetben, még azt sem, hogy több esetben, mint nem gyűrik le a natívokat.
Azt mondtam, hogy sok esetben.

Az összes tesztre igaz, hogy "sok esetben le is gyűrik a natív megoldásokat".
Az összes tesztnél találhatsz sok olyan nem natívot, ami sok natívnál jobban szerepel.

Ezzel csak azt akartam mondani, hogy a natív önmagában nem gyorsabb a nem natívnál. Rengeteg mindentől függ, hogy melyik a gyorsabb: pl. kik írják, mennyien írják, mennyi idő alatt, mennyire stabil, ...

Fingreszelés.
C, oszt kész.

No, ez már szentigaz, bár én az assemblynek adtam a voksot, mert kedvencem az marad, de az igazi a C, oszt jónapot.

> Sol omnibus lucet.

> nagyjából 2-3 éve jelent meg ez a feature

De miért kell fogalom nélkül hozzászólni mindenhez? A .NET 1.1-ben (2003-ban jelent meg!!!) már biztosan benne volt ez a feature, de jól rémlik, az 1.0-ban is.

https://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).aspx

Attól még, hogy van lehetőség a kesselésre, nem lesz natív az alkalmazásod, csak egy bájtkód.

Nem beszélve arról, hogy a nagy nativitás ellenére is sokkal nagyobb bloat volt minden .NET, mint a natív C++ alkalmazások.

"A native image is a file containing compiled processor-specific machine code."

továbbra is fogalom nélkül, úgy látom

Uhum, és azt is nézted, hogy hány liblofaszt húz be maga mellé egy C++-os app, vagy erről már csendesen (fogalmatlanul) hallgatsz?

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

Azt is néztem.

Annyit húz be, amennyire szüksége van, míg a .NET bloat-od elindulásához fenn kell lennie az összes lehetséges liblófasznak, többszáz megabájtnak, gigabájtnak. Ezzel akarsz szembeállítani natív alkalmazásokat, amik általában, a libjeikkel együtt 10-20 MB-ból elvannak binárisméretre és 40-50 MB memóriát használva? Hol élsz te?

Jaj megabájtok! Fogalom nélkül! Hujujujuj.

Tudod, az a helyzet, hogy a hozzád hasonló fogalmatlan faszjancsikon kívül senkit nem érdekel, hogy egy hello world szintű üres form hány mega ramot használ vagy, hogy hány mega lib van a gépen, hanem az az érdekes, hogy az alkalmazás teljesíti-e az elvárt követelményeket.

Mert az a nagy büdös helyzet, hogy a csudanatív szarjaid is amint elkezdi behúzni az összes libet, ami neki kell, máris nem lesz annyira rózsás memóriahasználatot és lemeztárhelyet tekintve. És egyébként is, a legtöbb ramot valószínűleg úgy is az adat fogja kitenni, amin dolgozol. Ha van egy serviced, ami 2-3 GB adaton dolgozik, akkor pont le fogod szarni, hogy egyébként 20 vagy 40 MB mellette a behúzott libek mértéke. Általában.

A 40-50-et meg javaslom nézd meg jobban. És javaslom, hogy nézz utána, hogy mi az a working set meg mi a private memory.

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

Javanal van fejlemény, ha esetleg lemaradtál volna róla, igaz, egyelőre csak Linuxra: AOT compiling.
Linux shared object lesz a class fileokból.
http://openjdk.java.net/jeps/295

Az Oracle, bármennyire is nem látszik és nem népszerű, eléggé sokat tesz bele abba, hogy a Java compiler infrastruktúra alakuljon: GraalVM, Truffle, AOT. Dolgoznak rendesen.
http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index-2301583.html

AOT, igen, hallottam róla, de egyelőre elég kísérleti jellegű, talán a 10-be már stabilabb kerül.

Sajnos a verbose dolgok megszüntetésén viszont nem nagy ütemben dolgoznak. Ha a Kotlin dolgainak a nagy részét átvennék (Scala-ról nem is beszélve), akkor elég sokat javulna a Java. Közben meg a 10-esbe tervezett JEP 286: Local-Variable Type Inference esetén a var-t bevezetik, de a sokkal fontosabb val-t pedig nem. Tán azért, mert úgy látják, hogy a final-t elég ritkán használják a fejlesztők. Nooormáális?? Persze, hogy alig használják, hiszen még a leginkább immutable dolgokat használó fejlesztőknek is nehézkes mindig kiírni, ráadásul egy plusz verbose tag, ami nehezíti az olvasást.

Ha nálunk valaki nem írja ki a finalt, akkor először magamban csendesen anyázok, aztán rájövök, hogy én is voltam kezdő. Utána odamegyek az illetőhöz, és megbeszéljük/refaktoráljuk a kódot, hogy ott legyen a final.

Nem fejleszek javában, de kíváncsi vagyok, alap mindenhez final-t írni? Miért jó ez?

Alapvetően azért, hogy könnyebben érthető legyen a kód. Ha egy adott "változó" mindig ugyanazt "jelenti" pl. egy függvényen belül, akkor könnyebb megérteni.

Az alábbi példában elég zavaró, hogy felülírásra kerülnek a bejövő paraméterek:

public static Double addSquares(Double a, Double b) {
  a = a * a;
  b = b * b;
  return a + b;
}

vs.

public static Double addSquares(final Double a, final Double b) {
  final Double a2 = a * a;
  final Double b2 = b * b;
  return a2 + b2;
}

ohhohó :) Az osztály elején amikor kiírjuk hogy "private final String cucc;" akkor java-ban így tudni fogjuk, hogy a konstruktorban kap egy értéket ez a változó, és onnantól az lesz az értéke, nem fogja mindenféle metódus változtatni, aztán így lesz szép immutable az egész osztály, és ez egy kívánatos dolog.

A metódus környékéről viszont irtani szoktam a final-t, az ott nekem már egy fölösleges szemét. Az osztály elején az egy információ számomra, hogy egy változó final, mert lehet, hogy olyan hosszú az osztály, hogy az első 1 másodpercben nem látom át. Viszont egy pár soros metódusban már nem akarok fölösleges szavakat, és ott a final általában fölösleges. Néhány sorból ki lehet szúrni, hogy ott egy output paraméter, ami ugyancsak kerülendő, szóval refaktorolni kell. Ha pedig a néhány sornál hosszabb a metódus, akkor az egy másik baj, amit ugyancsak orvosolni kell.

Viszont egy pár soros metódusban már nem akarok fölösleges szavakat, és ott a final általában fölösleges.

Látod, pont erről írtam korábban! Még akik kívánatosnak tartják az immutable változókat, még azoknak is egy nyűg, illetve fölösleges és olvasást gátló szó a final.

Kétszer használtad a fölösleges szót, pedig az egyik értelemben valóban fölösleges, másikban nem.
1. Egyrészt nem fölösleges, mert a megadásával tudjuk biztosítani, hogy ne lehessen felülírni az adott változót.
2. Másrészt fölösleges, mert az elhagyásával is meg lehetne oldani a felülírás mentességet, ha bevezetnék a val kulcsszót.

a = a * a;

vs.

final Double a2 = a * a;

vs.

val a2 = a * a;

Dehát ebben a példában nem az a baj, hogy a2-vel mi történik, hanem hogy a-t felülírjuk, és ezért a-t bevéded egy final kulcsszóval. Erre mondtam, hogy szerintem ez fölösleges, mert egy pársoros metódus átlátható kéne hogy legyen annyira, hogy bárki szabad szemmel kiszúrja az output paramétert. Szerintem itt nem kéne rontani az olvashatóságot final vagy val szövegekkel.

Nade ahány cég/fejlesztő, annyiféle szokás. Itt nálunk próbálom a sajátomat erőltetni :)

Ez az 'a2' milyen típusú?

Ugyanaz, mint az 'a' (pl. Double).

És ezt a fordítónak kellene majd kitalálnia, ugye? De ha már kitalálja, akkor ugyanúgy kitalálhatná akkor is, ha final a2 = a * a; lenne ott. Semmi szükség új kulcsszóra, ami nyilván visszafelé nem kompatibilis, ráadásul ezesetben nem is kulcsszó, csak kulcsszótöredék, ami gusztustalan.

Most erről beszélünk: JEP 286: Local-Variable Type Inference.

A val kulcsszót nem én találtam ki, ez az előzetes tervben merült fel:

    var x = expr only (like C#)
    var, plus val for immutable locals (like Scala, Kotlin)
    var, plus let for immutable locals (like Swift)
    auto x = expr (like C++)
    const x = expr (already a reserved word)
    final x = expr (already a reserved word)
    let x = expr
    def x = expr (like Groovy)
    x := expr (like Go)

A type inference-t, módosítható változóval bevezetik a 10-esben (var kulcsszóval), de a nem módosítható változósat (val, final, let, ...) nem. Tőlem lehetne a final is, de nem lesz egyik sem.

Tehát ilyen biztosan lesz:

var a2 = a * a

ráadásul ezesetben nem is kulcsszó, csak kulcsszótöredék, ami gusztustalan.

Ízlés kérdése. A Java-ban már most is van pár ilyen:
char, const, enum, int, (a var is az lesz)

Én szeretem a rövid kulcsszavakat, pl.: var, val, def, fun, ...

Eddig az történt, hogy kiírtam a jobb oldali részt, aztán egy billentyű-kombináció az IDE-ben, és ki van töltve a bal oldali rész. Ezután is az lesz, csak az IDE nem azt írja oda, hogy Double valami hanem val valami. Mi lehet az előnye ennek a val-nak, mit nem vettem észre?

Szerintem, ha IDE-vel töltöd, akkor ezután is ugyanazt fogja odaírni.

Mi lehet az előnye ennek a val-nak, mit nem vettem észre?

Ami a kevésbé verbose dolgoknak az előnye: jobban olvasható, könnyebben érthető, könnyebben módosítható.

Pl.1 Ez a stackoverflow-s példa erre változhat:

for (var row : table.entrySet()) {
    var rowKey = entry.getKey();
    var rowValue = entry.getValue();
    for (var col : rowValue.entrySet()) {
        var colKey = col.getKey();
        var colValue = col.getValue();
        doSomethingWith<SomeObject<SomeObject, T>>(rowKey, colKey, colValue);
    }
}

Pl.2 a korábbi addSquare-es példában, ha változik a paraméter típusa, akkor az új a2, b2-nek nem kell átírni a típusát, mert azt kitalálja.

Köszönöm szépen :)

Azért azt mindannyian tudjuk, hogy ezt Javaban már rég nem így kell megcsinálni, hanem valahogy így:

table.values().stream().forEach(map -> map.values().stream().forEach(this::doSomething)). // vigyázat, a .stream().forEach() és a .forEach() nem ugyanaz!

Legalábbis ha csak az értéken végzett művelet érdekel.

Mindenesetre már a felvezető komment alapján is baromság ez: ha egy (int, int) -> leképezésünk van, akkor talán létre kéne hozni egy immutable, egészeket tartalmazó párost, ami a kulcs, és egyszintű mapben tárolni a dolgokat.

És ekkor sokkal egyszerűbb is a dolgunk, ha meg akarjuk kapni a "koordinátákat":

table.entrySet().stream().forEach(entry -> doSomething(entry.getKey().x, entry.getKey().y, entry.getValue()));

Ezekben a kódokban sehol sincs leírva típus.

Persze ez az egész Mapben tárolt Mapben tárolt Mapben tárolt.... kód azért van, mert az emberek nem akarnak bevezetni absztrakciókat (mint például leképezések kulcsainak önálló value classokat), és csak már méglévő osztályokban képesek gondolkodni.

En ruhellem ezt a metoduson beluli finalozast, nincs gyakorlati haszna (a metodusnak rovidnek, valtozonevnek beszedesnek kell lennie, ha a fejlesztok ezt nem tartjak be, final-al is kovetnek el sokkal nagyobb bunoket), de legalabb megnoveli az ertelmezendo kodot.

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

Nincs gyakorlati haszna?
Ha egy változó final vagy effectively final, akkor felhasználhatod lambdában, amúgy nem.
"Starting in Java SE 8, a local class can access local variables and parameters of the enclosing block that are final or effectively final. A variable or parameter whose value is never changed after it is initialized is effectively final."
És a legjobb módja kikényszeríteni az effective final-t az, ha finalként deklarálsz valamit.
Persze, ha nem élsz lambdákkal, akkor mindegy is, de az meg még nagyobb bűn.

Nyilvan nem azokra az esetekre gondoltam, amikor a szintaxis megkoveteli.

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

Ezt mondjuk pont, hogy nem a szintaxis, hanem a szemantika követeli meg (ezért jó az effective final). Mivel a lambda kifejezést bármikor bárki meghívhatja (gondolj pl. egy Promise-ra), az a stacken lévő változóra nem hivatkozhat, marad a heap és a konstans érték.

> Tán azért, mert úgy látják, hogy a final-t elég ritkán használják a fejlesztők.

mondjuk az elmúlt egy évben, bármelyik videót néztem, ahol Project Amberről adtak elő, mindig volt valaki, aki megkérdezte, hogy „Hogyan lesz olvasható a kód, ha nem kell kiírni a típusokat?”.
Ezek után lehet, tényleg nagy törés lenne Java körökben, ha hirtelen a final a default működés.

Ez nálunk is vita tárgya, és sokszor ízlés kérdése. Sajnos azonban attól sem lesz olvashatóbb a kód, ha kétszer kell kiírni a típust, pl:

ThisIsAVeryLongClassName var = new ThisIsAVeryLongClassName(blablabla);

Ez a Java 7 előtt még viccesebb volt generic osztályoknál.

szerintem sem, sőt.

csak arra próbáltam reagálni, hogy amíg nekem/nekünk esetleg lassú, és szenvedés, a tempó, amiben a Java (mint nyelv) fejlődik, addig egyeseknek (valszeg a törzsközönségnek) már ez is túl gyors, és követhetetlen.

Ilyen kódot általában nem kell írni, szerintem az alábbiak miatt:
- Egy kódban általában egy osztály vagy egyféle dolgot csinál (SRP), ekkor nincs szükség hosszú nevekre.
- Ha egy osztály neve hosszú, az azt jelenti, hogy nagyon sok konkrét dolgot csinál. Ami eleve nem jó dolog, de előfordul.
- Viszont a változó típusa az absztrakt interfész szokott lenni, pont azért, hogy betartsuk a separation of mechanism and policy elvet. Azaz nem írok olyat, hogy ArrayList<Foo> foos = new ArrayList<Foo>();
- Ha ez az osztály egy függőség, akkor DI-vel injektáltatom a konstruktorban, nem pedig magam hozom létre. És amit injektálok, ott nem érdekel a konkrét típus, csak az interfész (policy).
- Ahol magam hozom létre, ott is kiajánlani a hívó felé interfészt ajánlok ki (policyt) és nem konkrét megvalósítást (mechanizmust), ezért sem kell kiírnom kétszer ezt.
- Az az eset, ahol ilyen konkrétumot kell mindenképpen leírni, azok a factory-k/DI providerek. Az meg a kódnak eléggé kicsi része.

Azaz nem írok olyat, hogy ArrayList<foo> foos = new ArrayList<foo>();

Csak sokszor azt is nehéz eldönteni, hogy melyik interfész vagy abstract class kell (elvileg a least power szabályt kell szem előtt tartani).

ArrayList esetén a következőkből kell választani (próbáltam emelkedő (erő) sorrendbe rakni):
Iterable, Collection, List, AbstractList, AbstractCollection, ArrayList

Ebből az AbstractList és AbstractCollection kiesik mint visszatérési típus IMHO, mert ezek az osztályok implementorok/producerek számára szólnak, nem userek/consumerek számára.
Ugyanígy az ArrayList is konkrétum.

Az Iterable, Collection és List között meg van döntési kritérium, hogy melyik legyen: valójában mit modellezünk, mit akarnak csinálni, mit csinálhatnak a consumerek ezzel a típussal:
- List,hogy ha szükség van arra, hogy tetszőleges elemét elérjék indexcímzéssel.
- Collection, hogy ha indexcímzésre nincs szükség/nincs értelme, de attól még módosíthatóságra (add/remove), vagy méretlekérdezésre szükséget kell biztosítani
- Iterable, amikor egy olyan elemhalmazra van szükség, ahol csak egyszerre egy elemmel akarunk műveletet végezni, de magán a gyűjteményen műveletet nem akarunk végrehajtani, csak az elemeire vagyunk kíváncsiak.

Persze ezek egyben jelzik is a hívó félnek, hogy mit kezdhet azzal az adatstruktúrával, amit megkapott. Jó API-t persze tervezni rendkívül nehéz.

Ebből az AbstractList és AbstractCollection kiesik mint visszatérési típus IMHO

A példádban pont nem API-ról volt szó és arra reagáltam, tehát erről:

ArrayList<foo> foos = new ArrayList<foo>();

Attól függően, hogy mit akarsz a foos-sal kezdeni az adott függvényen belül, aszerint kell választanod.
Pl., ha előre egy adott maximális kapacitással akarod létrehozni, de a végén le akarod csonkolni a tényleges méretre (trimToSize), akkor nincs más választásod, mint az ArrayList.

Hogyne lenne más választásom? Csinálok egy tetszőleges méretű listát tetszőleges típussal, majd amikor készen vagyok, egy defenzív másolatot belőle, ami már olyan méretű, amilyet szeretnék.
És ez utóbbinak már nem kell ArrayListnek lennie, bármilyen List implementáció jó lehet.
Lehet CopyOnWriteArrayList is, ha arra lenne szükség. Vagy LinkedList. Bármi.
Ha pedig tényleg tömbökkel akarok dolgozni, és kell a teljesítmény, akkor System.arraycopy.

Azt hiszem nagyon nem értjük egymást! ;-)

public List<foo> fillFoo() {
  ??? foos = new ArrayList<foo>(maxCapacity);
  // foos feltöltése N elemmel
  foos.trimToSize();
  return foos;
}

Én arről beszélek, hogy ezt a kódot akarod megírni és a ??? helyére szeretnél típust írni. Te mit írnál oda?

A függvényeden belül, a bal oldalon levő típus nem szolgál semmi másra, csak arra, hogy a függvényeden belül korlátozd az elérhető funkciókat. Szerintem egyáltalán nem olyan ördögi dolog, ha ott ArrayList van (vagy a jövőben csak var). Ha nem ArrayList-et írsz oda, akkor a trimToSize metódust nem tudod használni, mivel lekorlátoztad az elérhető funkciókat az interfésszel vagy abstract cass-szal.

Esetleg ??? = List<foo>, de ahol a trimToSize()-t hívod, ott downcastolsz. Persze sok értelme nincs egy ekkora metódusnál, viszont úgy meg tudod tartani a változó típusát általánosnak. Arra viszont jó lehet, ha valamiért pluszban oda kell figyelni a leszármaztatással bevezetett metódusok használatára. (Ha minden jól van megtervezve, akkor erre kevés esélyt látok, de ugyebár nem mindig minden jól van megtervezve. :) )

A Java terjengős. Ezt aláírom. Viszont pont a nyelv kötöttsége miatt van egy hatalmas előnye: jól ileszkedik nagyvállalati környezetbe. Pl CI/CD pipelineok, automatizált kódminőség ellenőrzés, új kollégák bevonása a fejlesztésbe. Stb. Lehet, hogy fapadosnak hat egy Scala, Groovy, Ruby, Perl stb mellett, de pont ez a lényeg! Emiatt rövidebb a nyelv megtanulási ideje, egyértelműbb, hogy mit is csinál a program. Egy operator overload, laza szintaxis stb kockázatos, veszélyeket rejt. A funkciónális programozás ezt megfejeli az átláthatatlansággal. Sok izgalmas feature van ezekben a nyelvekben, de kockázat is. Javaban egy fejlesztő szép kis szemétdombot hátra hagyhat. Scala-ban 100x akkorát tized akkora erőfeszítéssel. Nem beszélve arról, hogy pl a Scala sokkal kevésbé támogatott az automatizált eszközök által.
Egyszerűen nagyvállalati környezetben nem annyi, hogy megírtad, kipróbáltad és azt mondod, hogy működik, telepítsétek a prodra.
A kedvenc példám a scala gányolásra maga az SBT... Nekem 2 év elég volt belőle. Jól megmutatja, hogy mi a baj a funkciónális programozási nyelvekkel: gyorsan, könnyen, átgondoltat. Ebből az sbt a harmadikat nem tudta meglépni. És ezt bármelyik funkciónális nyelvben el lehet követni. Könnyen lehet, hogy az egyik fejlesztő nagyon benne van és varázslat amit művel a másik fejlesztőnek, aki csak két éve használja a nyelvet. Aztán jön egy junior is a csapatba...
Egyszerű, kisebb dolgokra én is szívesen használom pl a groovy-t. De elsődleges production kódra csak komoly játékszabályok lefektetésével alkalmasak ezek a lazább nyelvek.
Gondolj bele, amikor kapsz egy hibabejelentést fél napos SLA-val, közben akik azt a részt írták, pont szabadságon vannak. Vért lehet izzadni egy funkciónális nyelvnél ha egy licit is gányoltak. Nem mondom, Java esetén is meg lehet izzadni, de az OOP és a szigorúan típusos nyelv kötöttségei miatt sok minden sokkal egyértelműbb már első ránézésre.
Tudom, hogy lesznek jó néhányan, akik nem értenek egyet, úgyhogy: Kezdődjék a vita, a flamewar, kaszaboljuk egymást halomra stb! :D

Teljesen egyetértek veled. Ennyi.

+1

De a funkcionalis nyelvek fanjai valoban nem fognak vele egyeterteni.

De szerintem nehez vitatkozni az alabbi allitassal:

P(nehezen karbantarthato funkcionalis kod) > P(nehezen karbantarthato OOP kod)

(P(A) itt "A" esemeny valoszinusege)

szerintem leginkább azért, mert a OOPhez vagyunk szokva.

egy rendesen tesztelt, funkcprog kódnak szerintem könnyebben karbantarthatónak kellene lennie, nem? mármint nem láttam még ilyet én se, de a minden immutable, nincsen mellékhatás, etc miatt könnyebb tesztelni egy ilyet, s könnyebb benne hibát is keresni - naív szemmel. De tényleg nem láttam még énse ilyet :'(

"mármint nem láttam még ilyet én se"

na, igen, valahol itt lehet az a bizonyos eb elhantolva :)

Nepszerutlen velemenyem kovetkezik: az immutability is tulertekelt.

Ironikus, hogy pont a tesztelest hoztad peldanak, azaz, hogy konnyebb lenne tesztelni: pont a unit tesztelesnel a legerdekesebb, hogy atalakitgatsz egy objectet, nem "immutable", igy sokmindent meg tudsz rajta vizsgalni.

> pont a unit tesztelesnel a legerdekesebb, hogy atalakitgatsz egy objectet, nem "immutable", igy sokmindent meg tudsz rajta vizsgalni.

ezt nem teljesen követem.
mennyivel jobb ha a paraméterként adott objektum valamilyét állítom/tesztelem, mintha a visszaadott (másolat+változtatás) objektumon csinálom ugyanezt?

"valamilyét"

Au

Nagyjabol ilyenekre gondolok, hogy nehany (akar private) settert meg state modosito methodot meghivsz aztan a kritikus fuggvenyt, ami a furcsa state-egyuttes miatt (amivel valoszinutlen edge case-t emulaltal) kimutatja, hogy tovabbra sem tortenik furcsasag az adott objecttel dolgozva, vagy eppen de. Pont olyan hibatipust/hibaelnyelest/logbejegyzest kapsz, amilyet varsz. (Log entry inkabb integration testes pelda mondjuk, nem unit testes, ellenben a unit testnek feladata is irrealis edge case-t hazudnia).

> Au
jogos.

A maradék részét nem tudom, miért ne tudnád immutable dolgokkal megcsinálni.
A tesztben létrehozol egy új objektumot (vs. setterek), meghívod a tesztelt unitodat, majd annak a visszatérési értékén (vagy dobott kivétele, bár mintha a funkcprogban ez is egy objektum lenne, nem?) leteszteled, hogy azt kapod-e, amit akartál. (igen, a log itt tényleg mellékhatás, talán belefér)

De tényleg nem dolgoztam még ilyen szigorúan vett projekten. Egyszer kipróbálnám.

Pont ez a bajom a funkc proggal, hogy az intuitiv egysoros teljesen ertheto mellekhatas lehetoseget tulsagosan ki akarja venni a kezedbol, es csavart megoldasra cserelni.

Meg megrendelotipusbol is sok olyat el tudok kepzelni, akinel nagy ontokonloves lenne funkc prog modon nekiesni. Pl kepzeld mikor rosszul volt a "specifikacioban" (tegnapi csetben), a 1 to many relation mert valojaban az many to many.

FP esetén is lehet clean módon programozni és lehet teljesen érthetetlen, egy betűs változókkal, mindent egy sorba erőltetve. Hasonlóan lehet mindkét módon OOP-ben is.

Clean FP-t kellene hasonlíti clean OOP-hoz.

Meg megrendelotipusbol is sok olyat el tudok kepzelni, akinel nagy ontokonloves lenne funkc prog modon nekiesni.

Pontosan az FP az, ahol szét van választva az adat és a viselkedés; valamint kis, egymástól független építőkockákból van felépítve az alkalmazás; így sokkal egyszerűbb a változtatások lekövetése.

Ajánlom figyelmedbe pl. az The Art of Simplicity előadást, hogy különbséget tudj tenni az egyszerű (simple), az okos (clever), a bonyolult (complex) és a megszokott (familiar) között.

Nepszerutlen velemenyem kovetkezik: az immutability is tulertekelt.

Ezt honnan veszed? Szinte mindenhol mutable dolgokat használnak a (OO) fejlesztők. Éppen fordítva van, nagyon alulértékelt.

Az immutable nem azt jelenti, hogy nincs változás, hanem azt, hogy nem egy meglévőt változtatsz meg, hanem létrehozol egy "újat".

Lehet egy Number osztályod mutable és immutable is. Mutable esetben:

Number two = new Number(2);
two.add(3);

Így adsz a kettőhöz hármat, a two eleinte kettőt tartalmazza, majd az összeadás után ötöt.

Immutable esetben:

Number two = new Number(2);
Number five = two.add(3);

Az add függvény nem helyben változtatja meg a Number értékét, hanem visszaad egy új Numbert, így a two amíg világ a világ mindig kettőt tartalmaz, a five meg ötöt.
Hasonlóan, mint a String, BigInteger, BigDecimal, ... osztályok Javaban.

"Lehet egy Number osztályod mutable és immutable is. Mutable esetben:

Number two = new Number(2);
two.add(3);"

Ezt ugye nem gondolod komolyan?

Mármint mit?
Szerinted egy átlagos OOP projektben mennyi mutable osztály van (pl. amiben setX metódusok vannak)?
Ha egy sincs, akkor tényleg hülyeséget írtam. Ha rengeteg, akkor nem értelek.
Szerintem az immutable osztályokat nagyítóval kell keresni.

Egy _szám_ értéke ugyan hogyan változhatna meg?

Az nem egy _szám_, hanem egy objektum. Így:

public class Number {
  private int value;
  public Number(int initValue) {
    value = initValue;
  }
  public void add(int otherValue) {
    value = value + otherValue;
  }
}

Ez az általános használata az OOP-nek és az egységbezárt (encapsulation) állapot kezelésnek.

Az osztály neve Number, feltételezhetően egy számot hivatott modellezni. Számok értéke nem változik, ezért ez egy rettenetesen rosszul modellezett osztály. Tipukus vért izzadóan erőltett OOP vs. funkcionális összehasonlítás, ahol az OOP állapotot szándékosan rosszul modellezik.

:-)

Az autók színe sem változik, a bankszámla értéke sem változik, hacsak nem változtatjuk meg.
Nem adunk hozzá kettőt, nem festjük át pirosra, nem utalunk róla bizonyos összeget.
Ha Number helyett BankAccount a név, akkor már jó az OOP modellezés?

Na, és akkor jön ugye a mutability kérdés: attól, hogy az autó színét megváltoztatjuk, még ugyanaz az autó maradhat, mert az autó identitását nem a színe adja bizonyos modellekben.

Ugyebár erre lehet azt mondani, hogy a valóságban sem lesz új bankszámlám attól, hogy tranzakció történik vele - ezért lehetne mutable a BankAccount. Viszont lehet ezt mélyebben is modellenzi, és azt mondani, hogy nem, a bankszámlád száma és egyéb, bankszámlát leíró adat nem változik, de új egyenleg tartozik hozzá, amely egyenleg immutable.

A jó kérdés ugyebár az, hogy
1. Ha vannak egy objektumnak olyan propertyjei, amelyek nem részei az objektum identitásának, akkor valójában ehhez az objektumhoz tartoznak-e, vagy valamely asszociációt reprezentáló objektumhoz?
2. Lehetnek-e egy objektumnak olyan propertyjei, amelyek nem részei az objektum identitásának?
3. Ha egy objektum minden mezője része az identitásnak, akkor ezeknek az állapotát nem lehetmegváltoztatni - hiszen akkor az már egy másik objektum, csak egy factory tudja azt megváltoztatni - pontosabban létrehozni egy adott állapotú objektumot. Hiszen nincs értelme egy immutable objektumon, ami nem factory, olyan műveletet végezni, ami egy másik, hasonló objektumot állít elő.

Lehet erről sokat vitatkozni, mint jó meg rossz OOP modellezés, meg a valóság modellezése, de sose feledjük: a modellezés eredményeként létrejövő reprezentációk közötti relációk nem ugyanazok, mint a reprezentált valamik közötti reláció.
Jó példa erre: válófélben lévő házaspár, Alice és Bob. Őket a válóperben két ügyvéd reprezentálja. De attól, hogy Alice és Bob között házastársi reláció van, attól még Alice és Bob reprezentálói között ez a reláció nem áll fenn!

Az OOP inkább a reprezentált dolgok közötti struktúra (relációk) leírására jó (ki kivel van, ki kit tartalmaz, ki milyen viselkedést egészít ki vagy specializál, ki milyen felületet láttat a külvilág felé stb), az FP meg a dolgokon végigfolyó folyamatok reprezentálására (mi és hogyan történjen az egyes adatelemekkel). Teljesen ortogonális koncepciók, nem is értelmes semmiféle FP vs OOP vita. Immutability-mutability vita lehet, de ezt ne keverjük az FP vs OOP-vel.

Az FP-t lehet az imperatív programozással szembeállítani, de az OOP ezektől totálisan ortogonális koncepció.

Egyetértek, itt egyáltalán nem OOP vs FP problémáról van szó, hanem mutable OOP vs immutable OOP problémáról.

Az OOP-sek próbálják a modellezéseikre ráfogni, hogy a valóságban is ilyen, pedig nem. A modellezés épp azért modellezés, mert valamilyen szempontok szerint modellezi az adott dolgot, az nem ugyanaz, mint az adott dolog (a valóságban). Minden valóságbeli dolgot lehet mutable és immutable dolgon is modellezni objektummal, ehhez az FP-nek semmi köze sincs.

További részleteket lásd itt: Immutable vs mutable.

A többiben általánosságban egyetértek (főleg, hogy a modellel mindig a valóságnak csak egy "számunkra érdekes" részhalmazát reprezentáljuk), de az identitással (pontosabban a szóhasználattal) kapcsolatban kiegészíteném. A property-k sosem részei egy objektum identitásának. (Ellenkező esetben nem lehetne - pontosabban nem tudnád megkülönböztetni őket - két különböző Number objektumod, amelyek mindegyike a 2 számot reprezentálja. Ugyanez matektól elszakadva Personnel leegyszerűsítve: két Bob, aki ugyanakkor született, ugyanaz az anyjuk neve, de különböző személyek.)

Az más kérdés, hogy a legtöbb modell tartalmaz valami egyértelmű megfeleltetést az objektum identitása és a property-k egy részhalmazának értékkészlete (azok Descartes-szorzata) között. Amikor két (külön identitással rendelkező) objektum ez utóbbi tulajdonsága megegyezik, akkor tekinthetjük őket (feladattól függően!) logikailag egyenlőnek. (v.ö. Java esetében "==" vs. equals(), compareTo())

Szerintem itt nem a konkrét Number osztályról volt szó, csak egy képzeletbeli példa volt a különbségek érzékeltetésére.

A funkciónális programozás ezt megfejeli az átláthatatlansággal.
az OOP ... sok minden sokkal egyértelműbb már első ránézésre

:-D

Tudom, hogy lesznek jó néhányan, akik nem értenek egyet

Így igaz!

+1

Manapság a clr-hez hexában kell a kódot írni, vagy még mindig egy fordító hozza létre? Régen írtam vb kódot, lehet változott azóta.


"I'd rather be hated for who I am, than loved for who I am not."

A 9% pascal meglepett.
Milyen pascal fordítóprogram van? És mire lehet használni?

Lazarus: http://lazarus-ide.org
Szinte bármit meg lehet csinálni benne, bármilyen platformra.

[ Falu.me, Tárhely, Domain, VPS ]

Anno mikor még programozgattam, és delphi után megnéztem, fapadosnak tűnt, és sok minden hiányzott belőle. Azóta jobb?
--
"Sose a gép a hülye."

multiplatformos. Ez a legnagyobb erénye és erőssége, amit tényleg nem lehet elvitatni. De mint minden pascalban eszetlen nagy összevisszaság van benne.

--
GPLv3-as hozzászólás.

Gondolom Charlie meg a haverjai tamogattak a szavazatukkal. O takolja a freepascal forditojat (valami kihalt architekturara biztosan, de talan a sima fordito reszet is).

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Az FPC Motorola 68k backendről és a hozzá tartozó OS-ek támogatásáról nagyrészt én tehetek. Arról viszont nem, hogy rajtam kívül mások is a Pascalra szavaztak, de köszi a bizalmat. (Konkrétan nulla embert irányitottam ide egyáltalán bármire is szavazni.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Én pl. azért szavaztam rá, mert az a kedvencem. Ez volt a "feladat", nem? :)

Nem az volt a kérdés, hogy az általam ismert programozási nyelvek közül szerintem melyik a legjobb, a leghatékonyabb stb. (milyen célra? az sem mindegy...)

Volt az életemben egy hosszú időszak, amikor nagyon sok programot írtam Pascal nyelven (főleg TP-t, kisebb részben Delphit és egyebeket használtam), többször próbáltam mások javaslatára mást is, de nekem, aki soha nem voltam profi programozó, és már nem is leszek, azok kevésbé tetszettek, mindig maradt az elsődleges a Pascal. Ma is Pascalt veszek elő, ha nagyon ritkán kell valamit írnom.
Oktatásra pl. nagyon jónak tartom, de ez nem a mai lehetőség teljes ismeretében mondott vélemény :)

free pascal él és virul. én mondjuk nem használom, sőt pascalt sem, de ettől még van.

főoldaluk: "It can target many processor architectures: Intel x86 (including 8086), AMD64/x86-64, PowerPC, PowerPC64, SPARC, ARM, AArch64, MIPS and the JVM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/iPhoneSimulator/Darwin, DOS (16 and 32 bit), Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, Nintendo Wii, Android, AIX and AROS. Additionally, support for the Motorola 68k architecture is available in the development versions."


"I'd rather be hated for who I am, than loved for who I am not."

Ok, csak mennyire lehet élőnek nevezni azt a nyelvet/hozzá tartozó környezetet, amire mindenki azt mondja, hogy "mondjuk én nem használom".

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

azt látom az oldalukon, hogy új verziók érkeznek, bug tracker aktív, nem három éves az utolsó bejegyzés. ebből tippelem, van aki használja. én nem használom, csak kérdezték milyen fordító van, hát ez.

de extrémebb példa, és erre már nem mondanám, hogy élő, pedig a githubon láthatóan vannak commitok:
https://harbour.github.io/
sőt most látom, még egy magyar is ott figyel.


"I'd rather be hated for who I am, than loved for who I am not."

"http://wiki.freepascal.org/Operating_Systems_written_in_FPC"

Első kettő egy archiv Google Code oldalra mutat. Toro-nál január óta semmi aktivitás, kb. 2 ember csinálta. Negyedik szintén one-man projektnek tűnik.

"http://wiki.freepascal.org/FPC_Applications/Projects_Gallery"
"http://wiki.freepascal.org/Projects_using_Lazarus"

Ez azért nem annyira meggyőző felhozatal.

"http://delphi.wikia.com/wiki/Good_Quality_Applications_Built_With_Delphi"

Ok, Delphis programot én is láttam eleget az elmúlt hat évben, vagy helyből ott van a Total Commander, mint talán a legismertebb Delphis szoftver, de most a Lazarus/FP a kérdés.

Egyébként ne értsetek félre, a Delphi-t régen szerettem, arra a célra, amire kitalálták szerintem egy jó eszköz volt. Ugyanígy régen a TP-t is. De nem látom, hogy ma van különösebb élet körülötte, leszámítva néhány tizenpár éve kezdett ERP és hasonló esetén.

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

A nyelv és a hozzá tartozó környezet szerepelt az előző hozzászólásban.
A nyelv a Pascal, majd a későbbi "kiterjesztése" az Object Pascal. A (fejlesztői) környezet pl. a Lazarus vagy a Delphi. A FreePascal egy compiler :)

Ok, és a FreePascal meg a Lazarus a Delphi VCL-t használja vagy sajátot implementáltak? :)

Mindegy, kérdezem máshogy: éles, munkahelyi környezetben hoznál-e olyan felelős döntést, hogy te a cég/projekt jövőjét Lazarusra és FreePascal-ra alapoznád most így 2018 előszobájában? Ha igen, melyek azok a featurek, amelyek miatt megéri ezt használni, beleértve a járulékos költségeket is, mint Pascalhoz értő és/vagy tanulni vágyó munkavállalók felhajtása.

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

Tudja a fene :) Nem vagyok olyan helyzetben, hogy ilyen döntést kelljen hoznom, de nem is lennék tag/dolgozó egy olyan cégben, ahol engem bíznának meg ilyennel :)
Amúgy igen, elképzelhetőnek tartom, hogy valaki meghozzon egy ilyen döntést, sok-sok éve egy "kis" cég Object Pascalra alapozta a jövőjét, pedig akkor is volt más lehetőség bőven, majd egy idő után váltottak C++-ra. Ez a kis cég az Apple volt :)

"Ok, és a FreePascal meg a Lazarus a Delphi VCL-t használja vagy sajátot implementáltak?"

https://www.freepascal.org/fcl/fcl.var

http://wiki.freepascal.org/FCL

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."

ilyet kérdezni lol... most hogy mindenki ontja a javascript "kódereket"...

--
GPLv3-as hozzászólás.

Kicsit régi a weboldal, frissíteni kéne. Egyrészt a 68k backend már a 3.0 stable branchben is benne van, másrészt van SPARC64 és AVR támogatás is azóta. :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

"És mire lehet használni?"

https://github.com/BBasile/Coedit

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."

Én a kétezres évek legelején kezdtem meg egyetemi tanulmányaimat (win2000 meg mindenféle UNIX/Linuxok voltak akkoriban a sulis gépeken). Minket akkor Turbo Pascallal vezettek be az imperatív programozási paradigma rejtelmeibe :) Aztán természeteseen jött a C is meg a többiek. Mostanság mivel kezdik a programozást fősikolákon/egyetemeken?

Mert én bevallom férfiasan, hogy nekem nagyon jólesett az integrált fejlesztői környezet nyújtotta kényelem és nem tudom hogy megtanultam volna-e valaha programozni ha egyből C-vel kellett volna kezdenem, ahol gdb a debugger :) Így is majdnem ugyanakkora volt a sokk mikor Pascalról áttértem C-re, mint amikor 0-ról Pascalra :)

> Mostanság mivel kezdik a programozást fősikolákon/egyetemeken?
Code::Blocks, C (bme). Lásd: infoc.eet.bme.hu
szerintem nem volt gáz, bár én általános iskolában Pascaloztam egy keveset.

Valamikor 2003 kornyeken elhunyt az a tanar, aki a Pascal nagy szoszoloja volt (o irta az egyetemi Pascal konyvet is). Ezzel kiesett az egyik fontos eloado, es a fo ok, hogy ezzel kezdodjon a tanterv.
Igy lett a Pascal, C, aztan egy feleven belul C++ es Java helyett C, C++ es Java a tantervben (1-1 kulon kurzus), a hozzajuk tartozo laborokkal egyutt. Kesobb bekerultek plusz gyakorlatok is, a bsc-vel meg megint valtozott valami.

Egyebkent kezdo nyelvnek ma mar inkabb a Pythont ajanlanam.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

BME fizikus szak: C-vel kezdenek C++-szal folytatják.

> Sol omnibus lucet.

Attól, hogy ma már bottal sem szívesen piszkálnám meg, van olyan érzelmi kötődésem hozzá ("kedvenc") a "régi szép időkből", hogy erre szavazzak. Pitonra meg ciszre úgyis szavaznak mások elegen.

_______Peter
I am a stone. I do not move.

Akkor mostmar nincs begin csak end. ;-)

lacsap

--
L

Azért "érdekes" egy kalap alatt látni, mint "fordított nyelv", a natív és a bytecode-ra fordított nyelveket.

Mert te hogy csinalnad?

Az is furcsa, hogy a Python, Perl, PHP, sőt egyre inkább a Javascript is külön van, pedig a felhasználási területük nem a tipikus scriptek világa.
El kell fogadni, hogy 10 résztvevő vehet csak részt, és lehetőleg egy kategóriába egymással versengő elemek kerüljenek.

miért?

Miuátn a bytecode-s nyelvek nagyja is jellemzően natív lesz a végén, sok különbség nincs. Persze, akkor már érdekes kérdés a PHP és a JS jitterek, amelyek szintén natívra fordítanak.

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

A Java bytekódot a VM hajtja végre. A procinak ehhez semmi köze.
Anno basic-ek is bytekódra fordítottak és az interpreter azt hajtotta végre. Végül persze minden programot processzor hajt cégre, de - számomra és még sokan mások számára - teljesen más, hogy gépikódra fordítunk valamit - ez a klasszikus fordítós nyelv - vagy egy bájtkódra, amit még értelmezni kell.

A Pascal kódot is hivatalosan VM (pontosan processor) hajt végre, amely processor több elemből is állhat és lehet interpretált működése is. Ez van a szabványban:
"3.5 Processor
A system or mechanism that accepts a program as input, prepares it for execution, and executes the
process so defined with data to produce results.
NOTE A processor may consist of an interpreter, a compiler and run-time system, or another mechanism,
together with an associated host computing machine and operating system, or another mechanism for
achieving the same effect. A compiler in itself, for example, does not constitute a processor."

Elég idétlennek tartom ezt a fordított vs. szkriptnyelv felbontást. (Noha lehet, hogy sok évvel ezelőtt magam is javasoltam ezt.) Elsősorban azért, mert az, hogy egy nyelv fordított vagy interpretált (vagy akármi a kettő között) az az implementáció függvénye, nem pedig a nyelv saját tulajdonsága. Okosabb lenne egy "kedvenc programozási nyelv" és "kedvenc low-level programozási nyelv", vagy ha illeszteni akarom a címeket a jelenlegi jelöltekhez, akkor egy "kedves (elsősorban) statikusan típusos programozási nyelv" és "kedvenc (elsősorban) dinamikusan típusos programozási nyelv".

Egyetértek, a következő kategóriák jobbak lennének:
Kedvenc programozási nyelv:

c++
c#
go
haskell, ocaml, f#, scala (statikusan tipusos funkcionalis nyelvek)
java
objective-c, swift
python
php
perl
typescript, coffeescript (javascript jellegu nyelvek)

Kedvenc low-level programozási nyelv:

assembly
c
pascal
javascript
lua
*nix shell (bash, csh stb.)
powershell
r
ruby
kotlin

A pascal, a ruby és a kotlin kicsit kilóg innen, de a népszerűség alapján kerülne inkább át, nem az alacsony szintű volta miatt.

> Kedvenc low-level programozási nyelv:
> javascript

Haha, troll :)

Én speciel kedvelem (valamelyest) a Javascriptet és ott van a másik csoportban is (valamelyest :-)
Nem trollkodásnak szántam.

Az alacsony szintűekhez inkább olyanokat tennék, mint az

assembly
c
c++
rust
forth
...

Esetleg talán azzal lehetne definiálni az "alacsony szintet", hogy nincs garbage collector, a "magas szintet" pedig garantált memory safety-vel. Mondjuk ezzel a definicióval a Go a két kategória közé esne, a Rust pedig (legalábbis a marketing alapján) mindkettőbe beleférhetne.

Ne felejtsük ki a D-t sem :)
Elég jónak tűnik, ötvözi a C, C++, C#, Java, Python, Ruby, Pascal feature-it
Van benne pointer, interface, delegate, class, struct, mixin, enum, template, modulok, stb.
Ugyanakkor nem kell szarakodni header fájlokkal. Modulokat importál, mint a Python.
Rendszer programozásra is alkalmas, mint a C, Rust, Go, de nagyon sok magas színtű beépített
függvénnyel is rendelkezik.

Evekig probaltam bekuzdeni a szavazasba, de nem sikerult. Pedig szerintem a legjobb nyelv, de sajnos nem elterjedt, mert nincs mogotte nagy ceg nagy marketinggel.

És most már része a gcc-nek.

https://phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."

Pluszegy a D-nek. Máig emlékszem, mennyire megdobta a produktivitásomat, amikor C++-ról váltottam.

Alacsony szint: assembly, forth, C. Az összes többit már a lustaság szponzorálja.

> Sol omnibus lucet.

Fortran?

2014-ben én javasoltam a Kedvenc programnyelv kategória szétválasztását, de már akkor is megjegyeztem, hogy nem biztos, hogy ez a legjobb felosztás. Viszont így többé-kevésbé objektíven el lehet dönteni, hogy egy programnyelv melyik kategóriába tartozik. A high/low level felosztással az a baj, hogy sokkal nehezebb egy egyszerű, objektív szabályrendszert alkotni, amivel egy nyelv egyértelműen bekategorizálható. A típusosság szerint felosztás nekem is jobban tetszik, de az elsősorban szócska nélkül, vagyis lehetne Kedvenc statikusan típusos programnyelv és Kedvenc dinamikusan típusos programnyelv kategória.

Persze utóbbi esetében pl. az assembly vagy a bash melyik kategóriába esne?

De b+ hogy a picsaba' vezet a C? Foleg hogy a C++ is a szavazas resze, ami tenyleg majdnem mindent tud, amit a C, csak eppen kenyelmes is benne gondolkodni.

Kérdezd a hajbazer féle "programnyelvet még nem láttam, de az eszet tudom osztani, hogy mi a tuti!" megmondóembereket.

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

Úgy, hogy járnak még ide programozók, akik a bloat framework-ökben való kényelmeskedés és produktivitáse-pénisz növelgetés helyett valamire való, erőforráshatékony, értékteremtő mérnöki munkát végeznek. Maximum ők csak szavaznak és nem kommentelnek ide, mint a .NET-ben lustálkodó megmondóemberünk.

LoL

szerk.: btw, az editedben gyönyörűen személyeskedsz. Képzeld ide a te érvelési hibád linket

Egyrészt, csak utaltam az illető kilétére. Másrészt, nem én kezdtem. Harmadrészt, nem látlak nyálat verni Saxus Mérnök Úr személyeskedő kommentjei alatt.

Az eredeti LoL az eredeti kommentedre (az utolsó mondat nélkül) szólt. Azt továbbra is tartom.

A szerkesztés csak a te szerkesztésedre, és célzott rugdosásodra reagálás.

Ok, világos.

Ezt meg ertenem is, ha nem lenne a listaban C++, vagy C/C++ lenne a radiogomb. Elegge inszignifkans egy kivetelektol es template-ektol mentes optimalisan forditott C++ kod futasi sebessegenek es memoriaigenyenek kulonbsege egy C kodehoz kepest.

Tehat a kerdesem: ki az, aki jobban szeret programozni C-ben, mint C++-ban? Es miert? Technikai erv nem nagyon van a C mellett, es az esetek 99.999%-aban a C kod lefordul C++-ban (hasonloan optimalis futas- es memoriaigenyu vegeredmennyel) akedvenc C libjeivel egyutt igeny szerint.

(Igen, meg azt is ertem, hogy miert szereti jobban valaki a malloc/realloc + free-t a new/delete helyett)

Talan egyetlen ervet tudok, de az sem technikai: csapatmunkaban C++-ban tobbfelekeppen el lehet vesziteni a fonalat. Meg nagyobb eselye van a fejlesztonek nemegyeterteni a felulrol jovo kodolasi konvencioval, leven tobbmindent tud tobbfelekeppen a nyelv. De tenyleg eleg egy ilyen erv, hogy a C a C++ elott _vezessen_? :O

Letisztult, egyszerű, könnyebben haladó szintre vihető, sokkal több mindenre lefordul és változatlanságával kiállta az idők próbáját, pl. nem lett szétgányolva holmi idealizmusokkal, mint amilyen a C++11.

Luke Skywalkert ideznem:

"Hihetetlen. Minden egyes szavad tevedes."

Mert C-bol nincs C89, C90, C99, de meg a C++11-gyel egyidos C11 is? De, van. Abbol se "volt eleg" egy szabvany.

Es az ido probajat kiallo ANSI C kod C++11-ben is lefordul, de meg C++14-ben, sot, C++17-ben is.

Embedded vilagban is legtobbszor g++/clang++ elerheto. Mas architekturakon is. Azt irod "sokkal tobb mindenre", en ezt atirnam: "van egy nagyon elenyeszu szamu eszkoz, amin fut C kod es nem fut C++"

"Letisztult"

Mint egy C++ kod amit nem egy faszkalap irt. Vagy a C++-ban forditott C kod. Meg C kodot is tud faszkalap irni, pl aki begotozik a vezerlesi szerkezet kozepere.

"Egyszeru"

Nem (oke, ugyanugy a C++ sem)

"konnyebben halado szintre viheto"

Nem konnyebb megtanulni egy malloc + sizeof-ot, mint a "new" kulcsszot, meg ha mas technikai elonyei lehetnek is az elobbinek.

Nem maradt semmi, amit nem cafoltam meg.

Meg egy aprosag: a Windows XP idejerol szarmazo kedvenc GUI-s programjaid nagy reszet C++-ban irtak.

A C++ bloat.

lock

:D

Komolyra fogva, az én egyik tippem az autóipar és a mikrokontroller-programozás elterjedtsége, ahol bizony a meglévő kódbázis, illetve egyéb lib-ek eddig is C-ben voltak, így miért ne lennének ezután is abban. Ha pedig a UNIX-os világ lib-jeit nézed, ott is inkább írnak meg egy libcurl-t, egy git-et, egy wget-et C-ben, mint állnak neki C++-ban.

Mert a C lib C++-ban is hasznalhato. Forditva ez nem igaz. C libet nemhogy C++, meg akar egy Swift vagy akar egy PHP program (pl php-redis) is tud behivni.

Ertem miert ir valaki C libet. Azt nem ertem, ez az ember, aki meghozza azt az egyebkent jo dontest, hogy azt a libet C-ben fogja megirni, miert szereti jobban a C-t, mint a nem szignifikansan lassabb es minden szempontbol okosabb C++-t?

Es nem, maga a C++ nyelv nem bloat. Van sok lib hozza, ami bloat. En mar a smart pointereket se szeretem. De maga a nyelv nagyon nem bloat. Csak egyvalaminek nezz utana kerlek: zero overhead policy (kivetelkezelesnel es bizonyos template-eknel nem mukodik, de azokat nem kotelezo hasznalni megintcsak, mikor C++ kodot irsz)

Ha ennyire anti-bloat lecsupaszítod a C++-od, mi értelme ragaszkodni hozzá? Nem pont ez lehet a mérleg nyelve a C vs C++ -nál? Ha tisztességesen ki akarod használni a C++ adta lehetőségeket, bloat-ot írsz. Ha library-ket akarsz használni C++ -ban, még nagyobb bloat-ot írsz. Ha C-ben állsz neki, ott viszont se a lib nem lesz bloat és neked is nagyon erőlködnöd kell, hogy bloat-ot írj.

Azert C-ben sem kell erolkodnod, hogy bloatot irj, sot...

Akar exponencialisan lassabb libet talalhatsz C-re ha azt rosszul irtak meg, es tetszoleges optimalisabban megirt szkriptneylven osszerakott kod gyorsabb lesz n=100000 esetnel mar.

De kezdem erteni a szavazatokat. Nem csak a nyelvrol, hanem a kore epult libekrol/infrastrukturarol is szol.

A GNOME is bloat szerinted igaz? C-ben irtak
A Windows Intezo a Windows 98-on/XP-n nem volt bloat, igaz? C++-ban irtak

Remélem, azt azért vágod, hogy nem azt állítottam, hogy amit C-ben írnak az nem lehet bloat.

Vagom.

Mar semmi mast nem varok, csak annyit, hogy beismerd a "zero overhead policy" elolvasasa utan, hogy a C++ mint nyelv sem bloat. Utana a tobbi resz mar agree to disagree reszemrol. Megertettem miert szereted jobban a C-t.

Nem bloat.

Koszonom :)

Autóiparról annyit, hogy külön szabványokat kezdtek el csinálni (ld. MISRA, aminek létének okáról szintén mélyen kussoltál, mikor megemlítettem), hogy az istenverte fos C legalább egy picit alkalmas legyen az autóipari felhasználásra.

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

Kemény érvek ám ezek!

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

Ha mar a zero overhead policy-nak utananez, es elismeri, hogy maga a C++ nyelv alapvetoen nem bloat, es maris elegedett vagyok. :)

De ha mar erre jarok, meg is kerdezem: te szereted a C++-t? Tudom hogy C#-ot igen, C-t nagyon nem, szkriptnyelveket nem, gyengen tipusos nyelveket nagyon nem, de a C++-rol nem ismerem a velemenyedet, es kivancsi vagyok

MUHAHAHA. Új lehetsz itt errefele ;)

Komolyra fordítva: Azért a C#-al is megvannak a magam fenntartásai, bár legalább halad valamerre. (Non-nullable reference pl. nagyon hiányzik, vagy az async API szimplán fosul lett kitalálva szerintem)

C++-al sokáig úgy voltam, hogy jó, jó, de kevés feladatot tudok, amire azt választanám. Egyrészt, mert általános célú alkalmazásfejlesztésre a C#-ot vagy a Java-t sokkal alkalmasabbnak találom, főleg, ha nem vagy performance keretek közé szorítva, de még ott is sokat ki lehet belőle hozni. C++11 e terén ugyan sokat lépett előre, de ettől még fenntartom, hogy ráférne a nyelvre egy alapos tisztogatás a régi dolgok között. Picit úgy vagyok vele, hogy annyira mindent akart, hogy a kevesebb több lett volna.

Mondjuk ha kellene írni valamit C-ben, akkor valószínűleg én is inkább a C++-t választanám.

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

Akkor melyik most a kedvenc nyelved (van ilyen)?

C#-ban amugy nekem az az erdekes, hogy a nyelv nagyon tetszik, viszont amiket hasznalnak folotte legsurubben (.NET, Unity), az nagyon nem.

C++-nal viszont van egy olyan erzesem, hogy annak ellenere, hogy C-vel visszafele kompatibilis, meglepoen jo lett, a keves dolog egyike az IT-ban, ami 20+ eve jelen van es nem egy szemetdomb az egesz. De van olyan nemkezdo C++ csapat, akikkel mar a konvencios doksijuk miatt is keptelen lennek egyutt dolgozni (es ez nem jeleni azt, hogy rosszul csinaljak).

Nem mondom, hogy egy tapasztalt C++ fejlesztő ne tudna hatékonyan dolgozni vele, főleg, hogy látom, hogy jó dolgokat tettek bele az utóbbi időben. Viszont az nekem inkább reakciónak tűnik a többi nyelv fejlődése mellett.

A nem egy szemétdomb az egész részével meg a header rendszerrel kezdve már helyből vitatkoznék. 2017-ben vicc. :)

De összességében továbbra is ez a véleményem: magasabb küszöb miatt nehezebb embert találni hozzá és nem látok olyan kimagasló előnyt, ami miatt megéri a plusz befektetett energia más nyelvekhez képest.

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

Ertelek.

A .h resszel hatarozottan egyet is ertek. A tobbivel sem nagyon tudok vitatkozni, inkabb csak maskepp sulyoznam fontossagukat.

uoɥʇʎd

pǝsǝɹǝʞ uɐqɔıpoʇ zssoɹ

----------------
ʎןןuɟɥsıʍ ʞuıɥʇ - "oʇzsǝןſǝɟıqqoɥ" ,ןןoɹʇ 68ןʌן

A "forditott"-tal szoviccel, mint rajta kivul masik 3 nagyon eredeti user.

egyébként csak ezért át kellene nevezni jövőre ezt a kategóriát, mert kezd eléggé unalmas lenni.

Jó ideje PowerBuilder fejlesztőt nem találunk se égen, se földön. Nem tudom, hogy miért kedvence nálunk valakinek a PowerBuilder, ha a TOP10-be még csak nem is javasolták sohasem, de hát az a szerencse, hogy ennyi nyelven lehet fejleszteni! Éljen a sokszínűség!

--
trey @ gépház

Babel tornya is igy kezdodott, aztan Istenre fogtak...

Fasznak nem eleg a vilagnak a latin ABC? Mit kulonckodik Japan, Kina, Oroszorszag, etc.