HOVD 2014 - Kedvenc fordított programozási nyelv

 ( trey | 2014. december 15., hétfő - 7:13 )
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

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

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

Emlékeim szerint pont a Pascal minden évben komoly viharokat kavart, de idén ez *eddig* kimaradt.

Kicsit löktem rajta. Méltatlanul mellőzött. Tegnap belenéztem a Second Reality forrásába és ott is találkoztam Pascal-lal (persze főként beágyazott assembly-vel)...

Mi a gond egyébként vele? A klattyintgatós RAD emberek nem bírják?

--
trey @ gépház

> A klattyintgatós RAD emberek nem bírják?

???

Mond neked valamit az a programnyelv, hogy Delphi? :)

http://www.embarcadero.com/products/rad-studio

Nyilvánvalóan mond. Anno Turbo Pascal-ban kezdtem, majd később Visual Pascal-ban Borland Delphi-ben is kellett beadandókat csinálnom.

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

Ez a gond vele? Szerintem pont ez az előnye. Na, jó. Értem. :)

--
trey @ gépház

De azért egy nullával osztásra runtime errort dobni?? Ez sok év C után fáj :) Jó, tudom, ez fordítóspecifikus, de a Turbo Pascal ilyen galád volt :)

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

CRT unitot mindenki írt magának beágyazott assemblyben :)

Ezt mondjuk pont nem értem, nem teljesen mindegy, hogy milyen errort kapsz?
Nem osztunk nullával oszt kész...

Úgy érted, hogy rá kellett volna szólni a gyors processzorokra, hogy lassítsanak és emiatt ne okozzanak túlcsordulást a TP CRT unit-jának egyik számlálójában?

--
trey @ gépház

Nem, úgy értem hogy nem kellene előfordulnia olyannak, hogy eljut a fordítóig egy kód amiben véletlenül maradt egy n/0...

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

Á, így már világos, nekem ez sose jött elő hál'Istennek :)

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

Nem a gyorsabb gépekkel volt elsősorban probléma. Valami időzítéshez kellett a számolás, viszont a lefordított kód olyan volt, hogy a számláló ciklust valamelyik (talán az AMD) ügyesebb processzor optimalizálta, tehát le se futott, így került az osztóba nulla.

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

Clippernek is volt hasonlo problemaja az amd k6 procikkal.

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.

Hm, amióta utoljára láttam matematikát, megváltozott a nullával való osztás? Az nem végtelen volt legutoljára, hanem nem-értelmezett. Mondhatjuk esetleg NaN-nak, de inf-nek ... Szóval tippem szerint ezért nem szeretik a programok. Persze az, hogy nem kezelték le, no az hiba :-)

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

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.

Lasd a kommentemet lejjebb.

Az a hajtepos hulyeseg a koder igenytelensege, hogy nem kezelte le az excepiont. Egyebkent ha meg vesszot vart a program es pontot irtal, akkor ne csodalkozz, hogy exceptiont dob. ;) Utobbi mar user error.

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

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

Én nem szeretném, ha a calc.exe csak azért leállna, mert 0-val osztottam.
Írjon ki egy üzenetet egy csinos kis ablakban, és kérdezzen meg, mi mást szeretnék még kiszámolni.

Fuszenecker Róbert

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

Az aritmetikai kivételeket normálisan is le lehet kezelni.
Ha ezt egyesek nem teszik, az az ő dolguk.

Fuszenecker Róbert

"Ariane 5 nem kedveli ezt."

--
NetBSD - Simplicity is prerequisite for reliability

:D

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

LOL!

Tul nagy raketat tettek ala! Szoval hardware hiba.

--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.

Anno amikor megismerkedtem vele, akkor szerettem. Most is kellemes visszagondolnom rá.

A bajom vele az volt, hogy túl sok felesleges dolgot kellett megadni, begépelni.
pl.: BEGIN-END, pontosvesszők

Kezdőknek szerintem is egy jó nyelv.

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™

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

Biztosan lehet találni kivételt is (JavaFX talán valamennyire követi az MVVM-et), de alapvetően egyetértek.

Fuszenecker_Róbert

Nem túl jellemző szvsz. Ha még valamit használnak desktop alkalmazás fejlesztésre a C/C++-on kívül az leginkább valami scriptnyelv (ott is mostanság talán pythno, ami terjed.)

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

Az egyik leginkább használt nyelv Gnome-os fejlesztéseknél az a Vala.

És a Vala compiler mit is csinál a Vala kóddal? :D

Lefordítja.
Nem igazán értem a smiley-t. Gondolom arra gondolsz, hogy nem közvetlenül gépi kódot fordít, hanem köztes kódot, ami C, és azt fordítja le gépi kódra. Ettől még fordított nyelv és nem script nyelv.

> Ettől még fordított nyelv és nem script nyelv.

Nem erre gondoltam, hanem arra, hogy még itt sem sikerült azért elszakadni a C-től. Akárhogy is, a linuxos userland nagy része C, ahogy saxus mondta.

Az miért baj, ha van egy közbenső nyelv, ami mit ad isten nem P-kód (mint volt anno a korai rendszerekben), vagy nem Java bytekód, hanem C? Speciel ha jól tudom, az eredeti AT&T C++ fordító is C-re fordított.

Egy szóval nem említettem, hogy baj lenne.

De újra,
> Akárhogy is, a linuxos userland nagy része C, ahogy saxus mondta.

Hogy ez pozitív vagy negatív dolog, mindenki döntse el maga.

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

Nem a tudás/nem tudás a kérdése, hanem az, hogy a C alkalmazásfejlesztésre nem a legalkalmasabb nyelv.

Mégis ezercsillió dolgot erőltetnek C-ben.

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

Mert a C a hordozhato assembly gyakorlatilag, a kozos nevezo.

Tudom, hogy ez szokott lenni az egyik kamuindok. Gyakorlatban azért nem annyira érvényesül ez a hordozhatóság, főleg POSIX-W32 között.

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

Úgy látom ezt kár erőltetnünk ;)

Ettol meg nem mondom, hogy a C jo nyelv :)

Amig a kernel hivasok C calling convention szerint mukodnek es nincs kernel szinten sem mondjuk runtime bounds checking stb, addig ez marad is igy.

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

> Nem latom a hatalmas technologiai ugrast a Windows platformon a Linuxon elerheto eszkozokhoz kepest.

Nem a _technológiai_ előnyt kell keresni. :)

A windows-os/.NET-es ökoszisztémában sikerült rájönni arra, hogy a programozó idejét vesztegetni baromi drága mulatság.

A JVM ökoszisztéma nagyjából ugyanaz, mint a .NET-es ökoszisztéma. Tehát ebben sincs nagy különbség a Linux és Windows között.

A Java pont nem a linux holdudvarába tartozik, nézz körbe, mik mennek ott a különböző JVM-ek körül. Illetve mindegy is, a mainstream Linux userland elhanyagolható része épül Javára.

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

Nem, csak .NET-hez. (És sajna csak VS2010-el).

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

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.

Tudom, de nem kezdenék benne projektet. Főleg azért, mert a VCL-t a WPF mellett meglehetősen elavultnak tartom, plusz azért a C# is jóval előrébb jár már, mint a Delphi anno.

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

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.

Sajnos azért nem olyan egyszerü .NET-es üzleti logikát mobilokon használni. WP-n lehet, de az egyelöre elhanyagolható része a mobilpiacnak.

Na, látod, ebben tévedsz. :)

szerk: mármint nem a WP market share-ben

Mindjárt gondoltam, hogy tévedek, de hogy használsz fel egy .NET libraryt Androidon illetve iOS-en? Xamarinnal pl lehet mindkettőre fordítani .NET kódot, csak ebben a szálban nem pont erről volt szó.

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.

Összevissza beszélsz :)

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

Tehat szerinted csak Win32 es webes projektek leteznek. Megneznem mondjuk, hogy mikent portolsz egy DX11-es .NET-es alkalmazast Androidra. Mondjuk egy kepmanipulalo libraryt, ami GPU-gyorsitottan vegzi a kepek feldolgozasat. Ez is uzleti logika, nem csak az adatfeldolgozas.

> Tehat szerinted csak Win32 es webes projektek leteznek.

Nem állítottam ilyet. Illetve olyat sem, hogy mindig, minden körülmények között érvényesülne, amit mondtam.

Én nem dolgozom DX11-gyel, nem érint.

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

Mondjuk egy olyan nyelvet hozni a portolhatóság magasiskolájának, ahol még egyes alapvető típusok méretei sincsenek kőbe vésve, hanem utólagosan aliasokkal próbálják befoltozni a hiányosságot, elég vicc.

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

What? Hát magasiskolának éppen én sem nevezném. Az viszont igaz, hogy sajnos a C még mindig a hordozhatóbbak között van.

XBox játékból "SOAP webservicet" csinálni /o\
Légyszi mond, hogy csak trollkodsz...

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

Hát, Unity3d elég jól elboldogul a .NET-es assemblykkel :)

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

Egy darab engine, ami inkább a kivétel, sem mint főszabály. gelei pedig főszabályt említett, miszerint a .NET-es üzleti logika gond nélkül portolható Androidra bármikor.

Egy darab engine, de a helyedben megnézném, hogy hány helyen használják...

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

Tudom én, hogy hány helyen használják. De ettől még nem maga a .NET fw az, ami ennyire csodás, hanem az a munka, amit a Unity hozzátett. Ugyanígy a Xamarinék érdeme, hogy megy a kód iOS alatt (éljen az LLVM), nem pedig a .NET fw érdeme.

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

Szerencsére.

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™

+1

Főleg, hogy már a .NET-be is bele lehet majd nézni. Persze úgysem fog senki, mert a manyeyeballs a microsoftos nyílt szoftverekre sem igaz.

Most is bele lehet egy jelentős részébe. Ld. .NET Reflector.

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

"(és akkor még nem is beszéltünk a Visual Basic-ről)"

Amire te gondolsz az a VB.NET. Annak meg koze nincs a regi VB-hez.

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

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™

"Mert ugye libet kell fejleszteni, nem programot."

YAGNI

A kettő nem zárja ki egymást. Libet is lehet YAGNI elven fejleszteni.

Csak amig 1 elemu a lib addig felesleges lib-nek hivni. Nyilvan ha adott komponensbol osszejon egy csokorra valo akkor erdemes kiszervezni lib-be, de addig nem biztos.

Lazarus :)

A Piszkál egy vicc nyelv. Én örülök, hogy végre az Algol és fattyai nyelvek kipusztultak. Viccet félretéve, örülök, hogy ma már inkább Pythont okítanak az ifjúságnak és nem Piszkált.

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

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

No igen, az ERP rendszerünk, amit használunk asztali kliense pl. Delphi. :) Megjegyzem, ez a rendszer lefedi a magyar IT nagykereskedés jelentős részét.

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

Érdekes hozzászólás, de nem túl informatív.

Kifejtenéd, hogy mi nem jó a Pascal-ban, és ezzel szemben miért jobb a Python?
Attól most tekintsünk el, hogy az egyik majdnem interpretált - (relatív) lassú, a másik pedig gépi kódra fordul - (relatív) gyors.

Én például szeretek ilyeneket írkálni:

import os, sys

any(map(lambda x: not os.path.isdir(x), sys.path))

vagyis van-e a path-ban ami nem könyvtár?

Ezt Pascalban hogyan?

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

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™

Lemaradtal a lenyegrol: closure es lambda fuggveny Pascalbol hianyzik (illetve asszem a Delphi tud lambdat, de csak annyira, mint a C, vagyis closure ott sincs).

Ertem én, nem viccből vagyok a LinQ partjan, de attol meg nem egy olyan példát kellene hozni, amire mas nyelvben nincs szükség :)

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

Ejnye, Guido most csunyan nez rad. Ez nem pitonikus! A piton nem funkcionalis programozasi nyelv! A map/filter/reduce blacklisted builtin function a pylint szerint (W0141).
A kod helyesen:

any([not os.path.isdir(x) for x in sys.path])

Guido-nak semmi köze a pylint-hez, ellenben a map/filter/reduce a Python részei.
https://docs.python.org/3.4/howto/functional.html
--
♙♘♗♖♕♔

http://python-history.blogspot.co.uk/2009/04/origins-of-pythons-functional-features.html

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

Benne hagyta a Python3-ban őket? Benne.
--
♙♘♗♖♕♔

Ez igy ebben a formaban nem igaz:
http://stackoverflow.com/questions/13638898/how-to-use-filter-map-and-reduce-in-python-3-3-0

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.
--
♙♘♗♖♕♔

Köszi szépen. Azt tudtam, hogy így egyszerűbb. Nekem valamiért az van a fejemben, hogy a map gyorsabb mint a sima for->lista, de őszintén szólva sosem próbáltam ki.

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.

A referencia megvalósítás (CPython) interpretált, nem a nyelv! Lásd PyPy, IronPython, Jython.
--
♙♘♗♖♕♔

az 5. hely nem is olyan rossz ilyen vetélytársak mellett

--
[ Falu.me | Tárhely | A Linux és én ]

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

Nagy +1

Miert kerult ki a D? Na mindegy.

Szoval D.

Megtennéd, hogy összefoglalod, miért ezt a nyelvet választottad?
Mindig is érdekelt a D nyelv, de valahogy mindig úgy gondoltam, hogy még túlságosan gyermekcipőben jár komoly projektekhez.

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.

Nekem az avaj.

Egészen addig nem értettem hogy miért fordított programnyelv, amíg meg nem láttam a listában a scriptnyelvet...
--
The Community ENTerprise Operating System

A Clojure inkább a másik programozási nyelv csoportba tartozik szerintem. (Python, Ruby, stb.)

Mármint eltekintve attól, hogy Java bytecode-ra fordul, és a JVM hajtja végre? Hát öh... :D

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?

Persze, de ennyi erővel a .NET-es nyelvek is szkriptnyelvek. :)

C# --csc--> MSIL --JIT--> futó program

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! :)

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

"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."
hint: Qt

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

A még újabb technológiák alatt mire gondolsz?
Csak érdekesség képpen kérdezem.
Tapasztalatokat is írj, ha van időd, mert ezek engem is érdekelnek.

Ismerem, szeretem. De azért sok olyan van benne, ami macera tud lenni. Bár a C++11 sokat javít rajta IMHO.

Meg mondjuk egy DBus interface meghívása sokkal egyszerűbb Python alól.

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™

+1 mindkét bekezdésre

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™

Property?!

Uhhhh

És azzal meg mi bajod?

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

:)

(semmi...)

Öööö, 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. ;)