HOVD 2014 - Kedvenc fordított programozási nyelv

HUP

assembly (bármely architektúra, bármely dialektus)
3% (18 szavazat)
c
24% (153 szavazat)
c#
10% (68 szavazat)
c++
22% (145 szavazat)
go
2% (16 szavazat)
java
26% (172 szavazat)
objective-c
1% (7 szavazat)
pascal
7% (47 szavazat)
scala
3% (19 szavazat)
swift
1% (5 szavazat)
Összes szavazat: 650

( trey | 2014. 12. 15., h – 08:52 )


trey@alderaan:/tmp/pascal$ vi hovd.pas 
trey@alderaan:/tmp/pascal$ fpc hovd.pas 
Free Pascal Compiler version 2.6.4+dfsg-3 [2014/07/13] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and others
Target OS: Linux for i386
Compiling hovd.pas
Linking hovd
/usr/bin/ld.bfd: warning: link.res contains output sections; did you forget -T?
7 lines compiled, 0.1 sec 
trey@alderaan:/tmp/pascal$ ./hovd 
Pascal @ HOVD ROXX!!!

--
trey @ gépház

Talán az, hogy pontosan azt nyújtja, ami miatt kezdőknek kifejezetten hasznos: szigorú nyelvi szabályok - és azok betartatása. Mindezt talán kicsit túl strict módon teszi - pont ezért lenne nagyon jó kezdőknél. Aztán hogy valaki megszereti és nem megy tovább, az speciel szerintem nem baj. De másoknak mások a preferenciáik.

Igen, emlékszem rá. Amikor megvettem az első PII 266MHz "Klamath" processzoromat egyes Pascal programok elszálltak Runtime Error 200 (Division by zero) hibaüzenettel. Ez a Borland sara volt. A CRT unit-ot eltolta. Volt hozzá patch.

Álljon itt mementóként:

http://mtech.dk/thomsen/program/pasbug.php

--
trey @ gépház

Hát a fordítóig biztosan eljut, lévén a fordító azt kapja meg, amit te írsz. Az pedig, hogy a túlcsordulást egy gyári modulban a fordító akkor nem jelezte - ezt nem tudhatjuk, (esetleg az is lehet, hogy aki az adott modult írta, az ugyanúgy magasról tett róla, mint pl. az Y2K problémát leprogramozó sok millió programozó). Ím a teszt:

$ cat tcs.c
#include < stdio.h >
main()
char c = 0;
while ( c <=256 )
printf( "%d\n", c++ );
return 0;

Ezt lefordítottam *alapértelmezett* fordítóparaméterekkel 3 teljesen különböző C-fordítóval:
- PCC 1.0.0
- GCC 4.8.3
- LLVM/Clang 3.4.1
A három fordító közül egyedül a Clang dobott 2 db warning-ot. Az egyik a main visszatérési értékére vonatkozott, a másik pedig arra, hogy a while feltételem a változó tipusa miatt mindig igaz lesz. De persze még ő is lefordította. És persze mind a három ugyanazt a végtelen ciklust generálta. No akkor ehhez vegyük hozzá, hogy a GCC és a Clang kb 30 évvel újabb fordítók (a PCC ugye kakukktojás, mert az kb a Turbo Pascallal egyidős, vagy csak kicsit öregebb) - és simán lehet, hogy az adott modul mondjuk assembly-ben volt lekódolva, ahol azért annyira nem egyértelmű az ilyen probléma lekezelésének módja *szerintem*.

Megpróbálom felidézni, de nem garantálom, hogy sikerül, mert vagy 20 éve volt.

Nem a felhasználó által írt kód(ok)ban volt a hiba, hanem magában a fordítóprogram egyik standard libjében (gyorsabb gépeken túlcsordult egy 16 bites integer számláló). Ez is csak a Borland / Turbo Pascal-t érintette, vagyis nem a Pascal-nak volt hibája, csak kizárólag a Borland cég által fejlesztett Turbo Pascal-nak.

De feljebb linkeltem a probléma pontos leírását...

--
trey @ gépház

Nekem előjött, de nem csak azért, mert nekem TP-ban kellett programokat írnom. Hanem azért is, mert szerettem játszani az Imperium Galactica-val :)

Az IG futott szépen a régi gépemen, majd megvettem a PII-es gépet és elhalt Runtime 200-zal. CPU killer-rel kellett lassítanom a processzort, hogy menjen. Közben a Borland is kiadott valami patch-et, amivel a már lefordított exe-t lehetett patchelni, hogy ne szálljon el. Persze később lett az IG-hez hivatalos patch is.

Ebből sejthető volt, hogy a IG-t is Pascal-ban írták. Legalábbis a hiba kísértetiesen hasonlított rá. :)

--
trey @ gépház

http://mtech.dk/thomsen/program/pasbug.php

"The Runtime Error 200 (Division by zero) bug is not part of the Pentium Errors®. It's a mistake Borland made. The initialization part of the CRT unit has a calibration loop for the procedure DELAY. The resulting value of a counter depends on the speed of the cpu. This counter has an overflow on high speed cpu's, including Pentium II 266 Mhz and faster."

Másik link:

http://www.jazz2online.com/articles/17/jj1-on-your-fast-computer/

"MoSlo is a program which is supposed to slow down your computer to a given speed in a percentage amount. So for example, you would type: MOSLO /42 jazz.exe. When I tried MoSlo, it turned out that Jazz 1 ran WAY too slow at 42%, but I got the error message at 43%. I couldn’t play like that! So I search some more."

Nem hinném, hogy az említett 43%-nál valami optimalizálás következne be.

Vagy?

--
trey @ gépház

Jellemzően nem a '0' szokott bent maradni, hanem az osztó változónak lesz valahogy nulla az értéke. Tipikus eset, amikor a felhasználó által beírt elemeket átlagolni kell: le kell kezelni a kivételt, de ez nem biztos, hogy egy igazán hosszú kódban mindenhol reflexből eszedbe jut írás közben.

Én igazából erre gondoltam. A CRT unitos bugról tudok, de miért kell egy programnak meghalnia, ha nullával osztanak benne? Ha valós, akkor lesz belőle inf, 'oszt kész :)

Hasonló hajtépős hülyeséggel C#-ban találkoztam nemrég: unhandled exception-el meghalt a program, mert nem tudta a stringet számmá konvertálni... De annyi volt a baja, hogy tizedespontot kapott, míg a területi beállítások szerint neki tizedesvessző kellett volna. Na ezzel nem tudott mit kezdeni :D

Gondolom van benne még ezer ilyen, nem az én kódom volt, de azért nem kicsit lepődtem meg rajt.

Ennek az oka az IEEE-754 szabványban keresendő. A szabvány kétféle 0-t ismer, -0 és +0. Különleges értékek a -Inf, +Inf és a NaN. A szabály szerint a / -0 = -Inf, ha a pozitív, +Inf, ha a negatív. Hasonlóan, a / +0 = +Inf, ha a pozitív, és -Inf, ha negatív. Ha a +0 vagy -0, akkor az a / +0 és a / -0 kifejezések értéke NaN.

Viszont az egész számok esetén a / 0 az bizony kivételt generál itt is:
http://docs.oracle.com/javase/7/docs/api/java/lang/ArithmeticException…

A C szabvány szerint a 0-val osztás nem definiált művelet. Ezért sem jó nyelv alkalmazásfejlesztésre a C.

"de miért kell egy programnak meghalnia, ha nullával osztanak benne?"

A nullaval osztas cpu exceptiont dob, a hibakezelo hiaba probalna megismetelni a muveletet, ugyanott tartana, ha meg a kovetkezo utasitason folytatná, akkor kb. a 'ki tudja mi tortenik esetbe' futottunk bele, ami a szoftvertol fuggoen akar katasztrofahoz is vezethet.
peldanak tegyuk fel, terveznek egy hidat, ami aztan osszedol, mert a /0 hiba elmaszatolasa miatt hibas volt a statikai szamitas.

Nekem nincs calc.exe-m. Ami van, az nem dob fel ablakot:

$ dc
1 0 /
dc: divide by zero
$ bc
1 / 0
dc: divide by zero
0
$ e 1 / 0
inf
$ expr 1 / 0
expr: division by zero
$ echo $(( 1 / 0 ))
arithmetic expression: division by zero: " 1 / 0 "
$ nawk 'BEGIN { print 1 / 0 }' /dev/null
awk: division by zero
source line number 1
$ mawk 'BEGIN { print 1 / 0 }' /dev/null
inf
$ gawk 'BEGIN { print 1 / 0 }' /dev/null
gawk: cmd. line:1: fatal: division by zero attempted
$ perl -e ' print 1 / 0;' /dev/null
Illegal division by zero at -e line 1.
$

Volt két inf két nem túl elterjedten használt szoftvertől, a többi közli, hogy nem ad eredményt. (A teszt kedvéért nem telepítek grafikus calc-ot.)

Leginkább az, hogy a Delphinél kihalt alóla a platform (ismét).

Az MS átnyergelt a .NET-re, Borland óriási késéssel hozta az x64-es compilert (leginkább ezért nem volt Total Commander x64-re sokáig), balfasz módon elhanyagolt cross-platform compiler (Kylixre emlékszik még valaki?) és azt hitték, hogy majd az MS saját felségterületén fognak versenyezni (Delphi.NET, persze jobban elmaradva, mint a mono). Plusz, nem tudott felülni a webes vasútra. Plusz, még lassan is fejlődött.

Amúgy meg leginkább azért mellőzött, mert Windowson ott a .NET, a C#, WPF, WCL, ASP.NET, EF, stb. esetleg WinForms (ami egyébként nem keveset köszönhet a Delphi VCL-nek), ami szimplán többet tud, gyorsabban fejlődik, rugalmasabb és ugyanarra a feladatra van.

Linuxon meg... nos, ott szimplán leginkább megrekedt az alkalmazásfejlesztés a C-nél meg a C++-nál meg a 80-as éveknél.

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

"még itt sem sikerült azért elszakadni a C-től."
Már ne is haragudj, de ez olyan, mintha azt mondanád, hogy máig nem sikerült elszakadni a gépi kódtól.

A C egy viszonylag alacsony szintű nyelv, a Vala meg egy eléggé magas szintű nyelv. Aki Valában programoz, az lehet, hogy egyáltalán nem tud C-ben programozni, gyakorlatilag semmi köze a két nyelvnek egymáshoz.
Ráadásul meg lehetne írni a fordítót, hogy egyből gépi kódra fordítson, csak gondolom egyszerűbb C-re fordíttatni, mert a C fordítók elég sok platformra tudnak fordítani és nagyon jól tudnak optimalizálni is.

"Linuxon meg... nos, ott szimplán leginkább megrekedt az alkalmazásfejlesztés a C-nél meg a C++-nál meg a 80-as éveknél."

Ezt azert te sem gondolod komolyan. Erzem benne persze a valamelyest szandekos provokaciot, amivel osszemosod mondjuk a Qt technologiai fejlettseget egy 80-as evekbeli nyelvvel, de azert te magad is tudod, hogy mi a kulonbseg. A C++ olyan amilyen, de egy Qt-s fejlesztest nagy butasag 80-as evek belinek nevezni, es nem dominalnak a C++ problemai. De azert nem illik megfeldkezni a Java-rol meg a Mono-rol sem. Nem latom a hatalmas technologiai ugrast a Windows platformon a Linuxon elerheto eszkozokhoz kepest.

Ha Linux-os DESKTOP alkalmazásra gondolsz, akkor igazad van, tényleg C, C++, Python, Vala, Mono a leginkább használtak.
Azért nem kevés Java-s fejlesztés is van. pl. Eclipse, SQL Developer, JEdit, ...
Nem desktop alkalmazásnál meg rengeteg, gondolhatunk a vékony klienses alkalmazásokra.
Illetve ahol leginkább jellemző az az Android.

Igazad van, 70-es évek. Csak egy szót mondok: #include.

Komolyra fordítva: igen, tudom mi a különbség. Ettől függetlenül a Linuxosok körében nem ritkán jelentkező C[++] über alles hozzáállás nem kevés év(tized)del vetette vissza az IT fejlődését.

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

Most egyet kell hogy értsek veled. Sokban változott a látásmódom a dolgokról mióta project szinten fejlesztettem c++-al, amit olyan stílusban kellett csinálni, ami abszolút alkalmatlan erre a környezetre.

c++ debug, boáf... Tényleg minden képtelenségen keresztülszopatott minket.

Persze mindent egyből tökéletesre kell megcsinálni mindenkinek, és akkor nincs gond :)

Plusz mondjuk vegyünk ilyeneket hozzá a sztorihoz, mint Debugger Canvas*, Edit&Continue, Java HotSwap, stb. és akkor valaki merjen még nekem makefilet meg #include-t emlegetni...

* Továbbra is javaslok egy lószerszám intrúdolást annak, aki úgy godnolta, hogy nem muszáj portolni újabb VS-ekre.

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

Most lehet hogy félreértem, de nem a vizualizációval van a gond. Sőt azzal épp hogy pozitív tapasztalataim vannak, igaz a canvas plugint nem ismertem, és nem tudom c++ esetében használható-e, de majd mindenképp ránézek.

A gond azzal van, hogy az esetek 90%-ában hogyha valaki eltúr valamit a memóriában, akkor elveszik a stack trace. Ezért felező kereséssel lehet csak megkeresni, hogy pontosan melyik sorban történik a hiba.
Még tovább növeli a káosz fakort ha c# c++ vegyes project-ről van szó. Akkor a fenti eset 100%.

Neked is ajánlom a Lazarust. Multiplatform, Windowson és Linuxon egyaránt lefordul (na persze ha épp OS-specifikus unitot használsz, akkor kevésbé), a múltkor egy (kétségtelen viszonylag egyszerű) Delphiben megírt projektet tettem át rá, pár sor átírásával úgy megy, mint régen a Delphi kód. Természetesen fpc-n alapul, a VCL-t pedig portolták.

Az a baj, hogy saxus a "kihal a platform" alatt pont a Win32-ről és a Linux desktopról beszélt. :)

_Most_ még nyilván ezekre kell fejleszteni, de új projektet már hülyeség olyan ökoszisztémában kezdeni, ami utána nehezen portolható másra.

.NET-ben pl. ha egyszer megírod az üzleti logikát, onnantól hogy ezt milyen felületre vezeted ki (Win32, web, telefonok, stb.) már majdnem mindegy, csak a UI-t kell újraírni.

A Xamarin szó valóban nem szerepelt eddig a szálban, de egy VS (+ Xamarin kombó) bőven teljesíti azt, amiről eddig beszéltünk.

Azonos kódbázissal .NET-ben lehet deployolni desktop Windows, Linux*, OS X*, Windows Phone, Xbox, webböngésző, SOAP, REST, Android, iOS, MS Office (plugin), SharePoint, Windows RT környezetekre. És tuti van még ugyanennyi, ami eszembe sem jut.

Lehet jönni a Lazarusszal, hogy milyen multiplatform, de attól még csak desktopra jó kb., amin viszont éppen lábbal tapos a webkettes brave new world. Nem azt mondom, hogy ez jó, hanem azt mondom, ez a valóság.

--
* többé-kevésbé

Nem is a Xamarin sztringet kerestem, hanem UI újraírásról beszéltél. Sejtettem hogy nem újraírásra gondolsz hanem inkább megírásra talán, csak elég nehéz néha dekódolni a hozzászólásaidat.

Ez a .NET-ben webböngészö, SOAP és REST környezetekre deployolás is elég érdekesen hangzik. Ezt így viccnek szántad, vagy komolyan gondoltad? Ha komolyan, akkor tudsz példát mutatni a REST vagy SOAP környezetre deployolásra .NET-ben?

Talán pont fordítva?

A .NET-ben fejlesztett üzleti logika kimenete lehet a fent felsorolt sok dolog, például a webböngésző (ASP.NET), egy SOAP üzenet (WCF), vagy egy REST API (ASP.NET WebApi)

Mindezt, hangsúlyozom, csak a megjelenítési réteg újra elkészítésével. A mögöttes kód, ami normális esetben a kód igen nagy százaléka, maradhat többé-kevésbé változatlan.

1. Megírod a kódod lényegi részét, csinálsz belőle egy class library-t, mondjuk
2. Ezt a class library-t minimális módosítással bármilyen megjelenítési forma mögé berakhatod. WinForms, ASP.NET, WCF, stb.
3. ???
4. PROFIT

Volt már olyan projektben, hogy egy .NET-es WinForms MDI alkalmazást átdobtunk ASP.NET és WCF alá, mert úgy kevesebbet kellett szívni vele. Írtam róla a hupon, de most nem találom.

Kíváncsi vagyok, (hogy hűek legyünk a szál eredeti témájához), hogy a Delhpi kódot mekkora részben lehet újrahasznosítani egy Win32-->web átállás során. ;)

" Illetve olyat sem, hogy mindig, minden körülmények között érvényesülne, amit mondtam." vs ".NET-ben pl. ha egyszer megírod az üzleti logikát, onnantól hogy ezt milyen felületre vezeted ki (Win32, web, telefonok, stb.) már majdnem mindegy, csak a UI-t kell újraírni."

Aha, persze.
Vannak olyan alkalmazások, aminek a logikája portolható. Btw a C libraryk is ilyenek. Szóval a C a legnagyobb király mindközül? Annál portolhatóbb környezetet (szabvány C-re gondolj csak) nehezen találni.
Az egyik legjobban portolt lib például a zlib. Vagy a freetype. C rocks!

Jelzem, hogy szerény véleményem szerint a C sok mindenre alkalmatlan, de az egyik legnagyobb előnyének a hordozhatóságát gondolom. Elkezdhetném kb. ugyanazt a listát felsorolni, mint fentebb.

Illetve nyilván nem működik minden output minden projekttípusra. Ha írsz egy Xbox játékot, azt Windows-ra portolni könnyebb, mint SOAP webservice-t csinálni belőle, de ez nem a .NET hibája, ezzel gondolom egyetértesz. Vagy ha P/Invoke-kal belenyúlsz natív DLL-ekbe. Vagy sorolhatnám a végtelenségig.

Most nem vagyok benne biztos, hogy elolvastad-e az egész mondatot egyben. Arra tippelek, hogy nem.

Pont arról beszélek, hogy a kivételek (mint a fentebb említett DX11-et használó megoldás) ellenére a .NET nagyon is hordozható. Attól, hogy vannak olyan esetek, ahol nem lehet _mindenből_mindent_ csinálni az alapelv megmarad.

Na mindegy, hagyom elmenni.

Tulajdonképpen egyébként miért vitáztok itt ezen?
Ki a fenének lenne szüksége egy csilli villi 3D-s játékot futtatni egy gyufásdobozon? Vagy a hűtőszekrény termosztát szoftverét videókártyára optimalizálni?
Nem véletlenül vannak erre is arra is külön platformok, külön eszközök amiket használnak az illetékesek. Egy nagyon egyszerű kérdés volt feltéve, neked melyik a kedvenced nem az hogy te mennyire tudod meggyőzni a másikat hogy a te kedvenced az svájci bicska és bizony az abban iOS-re fejlesztett játékok nemhogy PC-n de még asztali telefonon és péklapáton is elfutnak...

Amiről te beszélsz, az egy klasszikus kliens/szerver alkalmazásmodell, HTTP-n keresztül. Viszont meg kéne érteni, hogy a világ nem csak HTTP-ből áll. Üzleti logika nem csak abból áll, hogy kiszámolok egy adatot és HTTP-n továbbítom egy harmadik félnek.
Például egy LP solvert vagy mondjuk játék engine-t hogyan deployolsz Androidra vagy iOS-re, amit .NET-ben megírtál Xamarin nélkül (ami nem a .NET projekt része)?

Jóhát, aki szeret többször annyit szopni ugyanazért és kézzel elvégezni azt amit amúgy a gép is tud*, annak csak gratulálni tudok.

*Külön élvezet, mikor ezt valaki azzal ideologizálja meg, hogy "jaj, legalább bele tudok nézni", miközben a valós komplexitása ugyanaz vagy nagyobb, mint az általa "zárt, áttekinthetetlen" rendszernek.

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

Ezt már egy szálban végigvettük, hogy Linuxon is ugyanolyan magas szintű nyelveket használnak, mint Windowson.
Nincs semmi különbség.
Ráadásul a C++ is elég komolyan van használva még mindig Windows-on is.
Avagy azt gondoljátok, hogy hobbiból fejleszti a Microsoft a Visual Studio C++-t?
(és akkor még nem is beszéltünk a Visual Basic-ről)

Ha szerintetek nincs így, akkor mutassatok már egy statisztikát, hogy mely nyelveket a programok hány százalékában használnak az egyes OS-eken.

Jóhát, aki szeret többször annyit szopni ugyanazért*

*Olykor azért kiderül, hogy az az ,,ugyanazért'' nem is egészen ugyanazért.

Alapvetően igazad van.
Az igazsághoz hozzá tartozik, hogy jómagam főleg beágyazott és jel- vagy adatfeldolgozó, vagy nem-IP hálózati programokat fejlesztek. Illetve legtöbbször nem is programokat, hanem libeket. Mert ugye libet kell fejleszteni, nem programot. [:)] UI-t csak nagyon ritkán csinálok.
Igaz, épp tegnapelőtt szitkozódtam egy C-ben megvalósított UI fölött, hogy milyen jó volna valamilyen generátormakró (mint régen a komolyabb assemblerekben).
(Web minket egyáltalán nem érint, meg a telefonos OS-ek sem.)

Igazad van, UI-t írni még GTK-val vagy QT-vel is szopás. Sőt, C-ben a normális sztringkezeléshez is minimum glib kell. De! Szerintem a probléma gyökere, hogy ma túl sok mindenhez használunk grafikus UI-t ahhoz képest, mint ahol az valóban indokolt lenne. Számomra az a jó program, ami socket-ből olvas és socketbe ír. Vagy ha nagyon kell, fájlból fájlba. Na jó, tudom, a világ nem csak ebből áll. Valakinek a fészbúkot meg a webshopokat is meg kell csinálni.

Gazdasági szempontból persze sokszor megalapozott a JAVA, a .NET és társai. Hiszen mint ahogy valaki már korábban írta, gyorsabb a fejlesztés, és alacsonyabban képzett munkaerő is adekvát kódot ír bennük.

Mindenesetre hálás vagyok, hogy az én munkám egy picit más. Nekünk nagyon jó, hogy van egy ilyen BSD és egy ilyen Linux. Bár az utóbbi időben már a Linux-szal sem vagyok egészen kibékülve. Egyre jobban szeretem a BSD-t.

Elnézést kérek, ha valakinek a lelkébe gázoltam. Csak arra szerettem volna emlékeztetni, hogy a világ nem csak a desktop-ból áll.

"Számomra az a jó program, ami socket-ből olvas és socketbe ír. Vagy ha nagyon kell, fájlból fájlba."

A legszebb az, hogy erre minden picit is modernebb nyelv ad egy szép absztrakciót Stream néven, aztán édes mindegy, hogy az most Memory- File- Compressed- vagy NetworkStream.

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

Én meg nem örülök: inkább a BEGIN - END legyen a nyelv része, mint a szóköz (főleg azért, mert én tabulátor hívő vagyok). És van egy rossz hírem, nem pusztultak ki, hanem erősen háttérbe szorultak. (Időnként nagyon jópofa állásajánlatokat látok Fortran és Cobol programozóknak.)

Kerülőutak helyett szimplán lekérdezzük csak a könyvtárakat: http://www.freepascal.org/docs-html/rtl/sysutils/getdirs.html

Vagy újabb Delphi/BDS-ekben: http://docwiki.embarcadero.com/Libraries/XE2/en/System.IOUtils.TDirecto…

Sőt, Delphi.NET-ben ez is megy: http://msdn.microsoft.com/en-us/library/6ff71z1w%28v=vs.110%29.aspx ;)

Jó, oké, leülök, este van. Hogy nem egy könyvtár alkönyvtárait akarod. Mondjuk elnézve a sys.path leírását ez tipikusan python specifikus dolog, Delphiben, pl. erre ebben a formában pl. pont a büdös életben nem volt szükségem.

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

http://python-history.blogspot.co.uk/2009/04/origins-of-pythons-functio…

Idezet a mestertol: "Curiously, the map, filter, and reduce functions that originally motivated the introduction of lambda and other functional features have to a large extent been superseded by list comprehensions and generator expressions."

Ez igy ebben a formaban nem igaz:
http://stackoverflow.com/questions/13638898/how-to-use-filter-map-and-r…

De a lenyeg:
1. a nyelv megalkotoja es fo diktatora sosem gondolta funkcionalis nyelvnek a Pythont, sot, kifejezetten es hatarozottan ellenzi az ilyen iranyu valtoztatasokat
2. abban teljesen igaza van, hogy a list comprehensionok olvashatobbak, jobban illeszkednek a nyelv tobbi reszehez, mint az "al-funkcionalis" eszkozok
3. az igazi programozo barmilyen nyelven tud Fortranban programozni, kerdes, megeri-e (lasd: immutable es perzisztens adatstrukturak teljes hianya, GIL es egyszalu futtatas, statement/expression kezeles, stb...)

Ha annyira ellenezné, mint ahogy állítod, akkor kidobhatta volna őket a Python3-ból. A hivatalos Python dokumentáció szerint viszont:
"Lisp, C++, and Python are multi-paradigm; you can write programs or libraries that are largely procedural, object-oriented, or functional in all of these languages."

A pylint pedig továbbra sem része a Python-nak.
--
♙♘♗♖♕♔

Szinte pont az az előny mondjuk a Pythonban a Pascalhoz képest, ami egyben a hátránya is.

Pascalnak roppant nagy előnye a kötött változóstruktúra, rákényszeríti a programozót, hogy tervezze meg a dolgait. Pythonban pedig roppant nagy előny a mindenféle dinamikusan létrejövő és eltűnő változó (gyakorlatilag objektum), a dict és list típusok azzal, hogy mindenféle egyéb típust magukban tudnak foglalni, ezeket Pascalban nagyon körülményesen tudod összehozni. Cserébe, lévén interpretált és nincs változódeklaráció sem, sokkal nagyobb munka a tesztelése.

( aborg | 2014. 12. 15., h – 10:15 )

Kár, hogy végül a Haskell végül nem került be. Mostanra érzem úgy, hogy sikerült olyan mértékben elsajátítanom, hogy meglássam a szépségét, eleganciáját. (Persze a Scala-val sincs gond, egyelőre inkább azt használnám éles projekten.)

( fdavid | 2014. 12. 15., h – 11:23 )

Miert kerult ki a D? Na mindegy.

Szoval D.

Nekem azert a kedvencem a D, mert ugyanolyan modern nyelv, mint a C# vagy a Java, de alapvetoen arra keszitettek, hogy valoban celplatformra forditsak. (Tud egyebkent szkriptkent is futni.) Tehat vegre egy modern nyelv, amihez nem kell managed kornyezet.

Mivel beagyazott fejlesztesen dolgozom korabban nagy remenyeket fuztem ahhoz, hogy vegre levaltja a C-t es a C++-t, de sajnos nincs mogotte tokeeros nagyvallalat es igy nagyon lassan terjed.

Azért a legtöbb modern programozásra használt ,,scriptnyelv'' esetében sem az AST-t járják be, hanem fordítanak egy köztes kódra, majd azt vagy gépi kódra, vagy azt interpretálják.
(Python3, Ruby, Perl, PHP) Hogy mégis inkább script nyelveknek tartjuk ezeket, szerintem a kései -amikor épp szükség van rá (JIT)- fordítás miatt van. Ebből a szempontból úgy vélem a Clojure esetében is ez a tipikus (és amennyire tudom ez sem jelez komolyabb -nem szintaktikai- hibákat fordításkor, dinamikusan típusos, de ez nem annyira az asztalom, inkább az erősen statikusan típusos nyelvekhez vagyok szokva).
Te hogy definiálnád a fordítottat? Maradna még valami a másik csoportban?

Szerintem valamit nagyon félreértettél a hozzászólásomban. Esetleg nagy-nagy rajongója vagy a LINQPadnek. :)
Arra próbáltam utalni, hogy akkor lenne igazad, ha a csc JIT-ként működne az MSIL előtt, de nem így szokott. Egyébként a MS .NET esetében nincs is JIT. MSIL után is AOT van (első indításkor bekerül a code cache-be). Mono esetén lehet, hogy van JIT, ebben nem vagyok biztos.

A PHP nagyon rossz példa. A HHVM csak egyfajta félkész PHP-runtime, a hivatalos PHP runtime még AST-t sem épít. Javaslat van rá, hogy így legyen, de még nincs így:
https://wiki.php.net/rfc/ast_based_parsing_compilation_process
https://wiki.php.net/rfc/abstract_syntax_tree

A PHP 7-ben majd így lesz.

" Maradna még valami a másik csoportban?"
Naná, a mau! :)

( wachag | 2014. 12. 24., sze – 10:21 )

Mivel számomra úgy tűnik, egészen jól eljutott oda a tudomány, hogy a különféle nyelvek jól együtt tudnak működni, egyre kevésbé van "kedvenc" nyelvem. Akár fordított, akár szkript.

Minden feladatra a számomra megfelelőt választom:
- GUI összerakására Java vagy C# vagy Python (bár az awt rettenet, C# meg még kevésbé hordozható). A platform adja a választást.
- Gyors lefutást igénylő/hardverközeli dolgokra C vagy C++. Itt a felhasznált programkönyvtárak adják a választást.
- Matematikai dolgokra Octave/Matlab vagy Python (scipy/numpy). Itt az adja a választást, hogy kell-e egyéb funkciókat támogatni. Dolgok kipróbálására, tesztelésre Matlab vagy Octave.
- Szövegfeldolgozás: Python vagy Perl. Itt a nyelvi ismereteim alapján inkább Python.
- Webes fejlesztés (ezt kerülöm, nem szeretem, egyszer-kétszer kontárkodtam bele :-)): Python/Java/C#. Attól függően, mire kell. Egyszerű dolgokra (nálam csak az van ebből) Python+django.

Ha egy program többféle funkcionalitást lát el, akkor nálam több nyelven íródik. Egy aktuális példa: szimuláció+eredmény kiértékelés+GUI. A szimulációnak nagyon gyorsnak kell lennie: C vagy C++. A felhasznált keretrendszer C-ben íródott, tehát C. Az eredmények kiértékelése nem bonyolult, alap mátrixműveletek, de csak kis mátrixokon, tehát Matlab overkill lenne: Python+Numpy,Scipy. GUI-hoz pedig akkor már szintén Python. És mivel elég sok "speciális" megjelenítés kell: gráfok, grafikonok, így PyQt4.

Persze van egy nagy ára a dolognak: egyik nyelvben sem vagyok profi. Mindet csak egy bizonyos mélységéig ismerem. Viszont nagyon gyorsan tudok fejleszteni, egész jól érthető kódot.

GUI-nál nem kell figyelnem a C++ hülyeségeire (ki kit szabadít fel, szálak, template, kivétel), koncentrálhatok a funkcionalitásra.

Szimulációnál nem kell wrappereket írnom a C-s libek köré, nem kell figyelnem a Python többszálú hülyeségeire, nem kell annyira figyelnem a teljesítményre.

Matematikai műveleteknél nem kell figyelnem, hogy felszabadul-e egy mátrix által foglalt terület, vagy sem.

És mivel egyik nyelvet sem használom nagyon bonyolult trükközésekre ("nem erőszakolom meg", pl. nem akarok C-ben OOP-t), még a kód is egész jól olvasható.

Nekem tetszik a QT smart pointer megvalósítása, de sajnos a 10-15 éves, már régen nyugdíjazandó C++ kódokban nem használják. És a meglevő 3rd party C/C++ libraryk/API-k sem.

2012 óta én is C#-ot/WPF-et használok, ha lehet.
Újabban nyitottam a még újabb technológiák felé.
Bizonyos dolgokhoz már én is öreg vagyok: amit a gép meg tud csináűlni, csinálja meg (automatikus erőforráskezelés).

Fuszenecker_Róbert

( uid_17784 | 2014. 12. 26., p – 18:29 )

Maradjunk annyiban, hogy a Pascal egy szar.

Nem arra lett kitalalva, hogy programozok hasznaljak (munkara), tanulni meg ott van a Python; meg munkara (is).

Maradjunk annyiban, hogy jóval alkalmasabb volt a maga korában a Pascal és a Delphi arra, amire kitalálták, használták, mint amire egy halom programnyelvet próbálnak használni most.

Na meg vicces, hogy két olyan nyelvet hasonlítasz össze, ami között van vagy 20 év különbség.

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

Azert, mert egy lelkes fiatal beleszeretett, es elinditotta az emelkedon, meg nem lesz jo.

Aki hasznalta sokaig, aztan (vegre) belekostolt masba, az tudja is, hogy szar, aki meg megragadt nala, az meg ugy hiszi, hogy nem.

Azt meg nem tudom ertelmezni, hogy mennyivel kevesbe lesz szar, ha azt nezzuk, hogy mikor lett feltalalva? Nekem ez nem tud vicces lenni; nem is viccolghatok (karacsony van).

Tudom, hogy eljárt felette az idő sok szempontból (most éppen aktuálisan a Delphi felett) és, hogy sok esetben van jobb, szebb, csilivilibb megoldás, viszont ez egy cseppet sem von le az értékéből: a maga korában a maga helyén tette a dolgát. Jól.

(Ha viccelgetni akarnék, akkor felemlegetném a Java-ban a propertyket. Hja, hogy még mindig nincs, sry...)

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

Öööö, előrebocsájtom, imádom N. Wirth gondolatmeneteit, tán még Hoare-nél is jobban.

A Pascal-ba nem beleszeretett vmi fiatal, hanem a _strukturált programozás_ oktatására fejlesztette Wirth. Akkor, amikor a technológia alkalmatlan volt az (néha bloatware) object, aspect és kitudja milyen orientált (akkor még nem is létező), ámde külső memmanagement igényes nyelvek fordítására és futtatására... Akkoriban az erőforrásokkal való gazdálkodásnak még volt hagyománya. Mostanság csak kevesek "mérik" ki, hogy pl. egy hashmap-en hogyan kifizetődőbb végigszaladni adott körülmények között a rendelkezésre álló 23 módszer közül... Mer' vontatott enterprise alkalmazás az van sok... :(

Stb. ;)