Milyen a kapcsolatod a funkcionális programozási nyelvekkel / paradigmával?

Programozás

Nem ismerem őket.
38% (137 szavazat)
Ismerem, de nem tetszik.
11% (41 szavazat)
Tetszik az elgondolás, de nem használom.
18% (65 szavazat)
Tetszik, és használom is (hobbi).
10% (38 szavazat)
Tetszik, és használom is (munka).
8% (28 szavazat)
Hozzászólásban leírom / Csak az eredmény érdekel.
15% (56 szavazat)
Összes szavazat: 365

( Hevi v | 2014. 03. 20., cs – 16:25 )

"Ismerem, de nem tetszik"-et jelöltem.

Hozzám közelebb áll az OOP, már csak az általam megoldani kívánt problémák fajtája miatt is. A többire meg valami egyszerűbb script.

( uzsolt v | 2014. 03. 20., cs – 16:36 )

Régóta tervbe van véve alapszinten való megtanulásuk (vagyis valamelyiknek). Ezért a "Tetszik az elgondolás, de nem használom"-ot jelöltem.

( kisszol | 2014. 03. 20., cs – 16:37 )

Elnézést a szentségtörő kérdésért.
Hol lehet az ilyen nyelveket JÓL használni?
(EMACS programozásán kívül :-)

Mióta Erlangban programozok (hobbi + meló egyaránt), nincs gusztusom hozzányúlni a régi C++ kódjaimhoz (nem azért mert annyira rosszak lennének :)
Meg úgy általában más programnyelvhez sem...

Akit egyszer megront a funkcionális/deklaratív gondolkodás, az örökre meg van rontva. Nem is beszélve arról, hogy minden for ciklust ösztön szerűen átírna tail-rekurzív hívássá :D

Anno Haskell-eztem én is minimális szinten (guard-ok, stb :)
A higher order functionök igen hasznos dolgok :)

A rekurzió használatában igazad van, némiképp Erlang specifikus az a megközelítés, hogy mindent így oldjunk meg. Itt nincs ugyanis többszöri értékadás a "változóknak". Ha I=5, akkor az mindig is annyi lesz, I++ meg I=6 nincs, ha már egyszer az I változó értéket kapott.


factorial(0) -> 1;
factorial(N) when N > 0 -> N * factorial(N - 1).

Jó az, annyi a lényege, hogy hiába hívsz meg 10000 mélységig egy függvényt rekurzívan önmagából, csak egy függvény-nyi stacket foglal az 10000 hívás összesen. Szervereket (értsd: loop-ban futó request/response kommunikációt folytató kiszolgáló kódokat) igen hatékonyan meg lehet írni így rekurzívan, és nem kell aggódni, hogy betelik a stack 3 hónap futás után :)

( gelei v | 2014. 03. 20., cs – 17:53 )

(x) Egyéb: nem ismerem, és amíg egy meggyőző business reason-t nem hallok, addig nem is akarom megismerni. (Max felületesen, érdekességként.)

Amúgy valahol igazad van, nyilván nem ennyire fekete fehér a dolog.

Inkább arra gondolok, hogy egy paradigmát úgy megtanulni, hogy abban _tényleg_jó_ legyél, akár több év is lehet. Ismerkedés szintjén oké, hiszen ez sem rosszabb hobbi, mint a bélyeggyűjtés, de mondjuk munka+család mellett a nulláról profi szintre hozni magad nem biztos, hogy megéri. Akár anyagi szempontból, akár csak a szabadidő miatt.

( gee v | 2014. 03. 20., cs – 18:02 )

Egyéb:
hallottam már róla, jobbára értem is, hogy miről szól, viszont ugyanúgy nem használom, ahogy más programnyelveket se.

Szóval ismerem, se nem tetszik, se nem taszít, és nem használom.

( enpassant v | 2014. 03. 20., cs – 18:20 )

"Ismerem, de nem tetszik."
Aki ezt jelölte be, annak szerintem mélyebben kellene vele foglalkoznia.

"Nem ismerem őket."
Aki meg ezt, az sürgősen álljon neki, mert nagyon hasznos.

See "The Blub Paradox", Paul Graham esszéi.
"Hiába magyarázod a kútban élő békának, hogy az égbolt nem csak abból a szeletből áll, amit ő lát. Nem fogja elhinni, amíg ki nem merészkedik a kényelmes otthonából és körül nem néz."

Nagyon sokat tud javítani, fejleszteni a programozási stíluson, tudáson az, ha valaki megismerkedik valamilyen funkcionális programozási nyelvvel. Még akkor is, ha soha nem fogja utána sem "komoly" dologra használni. Tágul a látókör, bővül a programozási arzenál - mindenképpen jobb programozóvá tesz.
Most jelent meg a Java 8. Ilyenek jöttek vele, hogy lambda, stream, closure. Igaz bénán, korlátozottan. Találd ki honnan vannak ezek? ~50 éve léteznek és használják őket egy másik világban.

Ki a tökömet érdekel a Java 8? Egy elmaradott szar. Más nyelvek már évek óta bevettek ilyen dolgokat (clojuret még a nyomi PHP is, pl.)

A másik világról meg annyit, hogy azért nem lenne rossz, ha néha-néha észre vennék ezt a világot is és találkoznának az evilági igényekkel is. Pl. vajon teljesen véletlen az, hogy szinte az összes Lisp fanboi ismerősöm egy Alert dialognyi GUI-t nem kódolt még az életében?

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

"Ki a tökömet érdekel a Java 8? Egy elmaradott szar"

Képzeld, az autót meg, amiben ülsz, assembly és C kód tartja az úton, mikor nem veszed észre időben a gyalogost, és rátaposol a fékre kanyarban, jeges szakaszon. Pedig abban sincs clojure, sőt, még egy árva objektum sem. Akkor most szar? Vagy írják inkább .NET-ben, mert abban vannak? Na olyan kocsiba ülj Te ;) Ha nem jössz rá, miért írom ezt, akkor nincs miről beszélnünk.

"Pl. vajon teljesen véletlen az, hogy szinte az összes Lisp fanboi ismerősöm egy Alert dialognyi GUI-t nem kódolt még az életében?"

És? Szerinted csak a GUI programozás meg az alkalmazásfejlesztés "programozás"? Ha nem lenne Erlang, akkor pl. lehet hogy a telekommunikáció ma nem lenne ennyire megbízható, de nézz csak utána, ki fejlesztette azt a nyelvet és miért.

A funkcionális nyelvekben a szemantikai korrektség bizonyítása, ált. egyszerűbb és kézenfekvőbb, adott esetben megfelelő típuskényszerek ellenőrzésével automatizálható.

Ha szemantikai követelmények ki lennének kényszerítve (persze minden módszertanba kerülhet hiba) akkor utána csak a realtime követelmények teljesítésésén kellene majréznom(tényleg erre van valamilyen formális proof rendszer?), és azon már nem hogy valaki kifelejt mondjuk egy banális mph -> kmph átváltást a kódban.

Formális módszer tudtommal nincs erre.
Amit használnak - bár elavult, de működik -, az a "keveset programozok, sokat ellenőrzök, és amit lekódoltam, azt is átnézik többen és szigorúan tartjuk magunkat a coding standardhez, mert ha a költői vénám szárnypróbálgatása (na majd meglátjátok, hogy milyen elegáns megoldást írtam 5 pointerrel meg 6 adatszerkezettel erre a megoldásra!) meg a kialvatlanul, másnaposan megírt és nem tesztelt kód miatt valaki meghal, az a lelkemen szárad." hozzáállás.

Elvileg volt egy probalkozas, hume programozasi nyelvvel:
https://en.wikipedia.org/wiki/Hume_%28programming_language%29

Towards Formally Verifiable WCET Analysis for a Functional
Programming Language
http://drops.dagstuhl.de/opus/volltexte/2006/677/pdf/WCET_Hammond.677.p…

De ezeket a kovetelmenyeket a hw minden reszenek is teljesiteni kell:
http://www.erts2014.org/Site/0R4UXE94/Fichier/erts2014_4A1.pdf

Total offtopic, meg nem is lenyeges, de mivel mar tobbszor elhangzott:

"closure".

Van "clojure" (ejtsd. closure :) ) is es a temahoz is kapcsolodik, gondolom ezert a felrecsuszas. (Egy nagyon fasza "modern lisp" a java virtualis gepre, konnyu atjarassal a normal java okoszisztemaba. (Sot, mar a .net virtualis gepere is.))

De,tudtam, hogy valaki ide fog trollkodni a beágyazott szirszarokkal oda, ahol nem a jardverkozeli, hanem a magasz szintu programozásról van szo. Avagy, InvalidContextException.

Vedd mar eszre, hogy nem errol szol a SW fejlesztés 90%-a. Masreszt meg van 1-2 ismerősöm, akik ezen a téren dolgoznak, tudnának mesélni, három gy milyen ámokfutásokat képesek muvelni a villlanyvadaszok, fizikusok a te kis c/asm világosban.

Es fyi: attol, h .netbn, phpban es néhanapján javában kodolok, kepes vagyok realizálni, h az hol es hogyan fog futni. (Ellentétben sok magadfajta beágyazott rendszerekkel trollkodval, akik nem realizálják, h mi van körülöttük)

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

Szerintem nem "magas szintű" programozásról volt szó, hanem egy paradigmáról, amit lehet alkalmazni nagyon sok helyen.

Amúgy igen, a villamosmérnökök/fizikusok nem programozóként gondolkodnak. Ha úgy lenne, lehet hogy többször lenne Csernobil, tudod :)

Napokig mesélhetnék, hogy milyen "ámokfutásokat" művelnek, legalábbis OO szemmel, de hidd el, hogy beágyazott fejlesztő szemmel meg az a legalábbis vért kívánó vétek, hogy valaki mindenre osztályokat hoz létre és másra bízza a memóriakezelést. Meg hogy minden objektum. Meg hogy... De biztos érted, mire gondolok.

"Beágyazott szirszarok"?
Ajjajajj. Te is olyan vagy, aki azt hiszi, hogy a beágyazott rendszer az a hobbiprojektek platformja, és minden "komoly" dolgot Javaban írnak? Barátom, ha kéne csinálni egy felmérést, hogy mennyit tesznek hozzá a jelenlegi világhoz a "beágyazott szirszarok" és mennyit a "magasszintű nyelvek", lehet hogy szégyellnéd magad.
Ezzel persze nem azt mondom, hogy az egyik vagy a másik jobb, csak nem értem, miért kell nyelveket/paradigmákat leszarozni, csak azért, mert te nem használod... A "van egy ismerősöm, aki azt mesélte" jellegű dolgok meg szerintem kb annyira valid-ok, mint a jetiről készült fotók...

Csöpög belőled a megvetés minden iránt, amit nem ismersz, nem tudsz, vagy nem akarsz tudni. Ezen változtass, aztán gyere vissza beszélgetni :)

Na akkor még egyszer: ahol OOP meg funkcprogról van szó, ott beágyazott rendszereket emlegetni maximum nettó trollkodás.

De mindig van egy C/ASM fanboi, akinek muszáj beletrollkodnia. (Mellesleg, ha annyira hú de jó lenne a C beágyazott rendszerek fejlesztésére, akkor nem lenne szükség ilyenekre, mint MISRA-C. De persze én nem érthetek hozzá.)

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

na akkor mégegyszer:

ad1) topicban funkcionális programozásról van szó, OOP-ről max mi kezdtünk el vitázni

ad2) ha nem vetted volna észre, példaként hoztam fel arra a beágyazott világot, hogy vannak bizony olyan területek, ahol olyan (extrém) dolgoknak is van létjogosultsága, amire bárki más, aki nincs az adott területen, csak bólintana

ad3) szerintem nem tiszta számodra, hogy mi a különbség a felhasználási platform(web, embedded, cluster, desktop, akármi) illetve a programozási paradigma között, ha szerinted az oop/fp és pl. az embedded üti egymást.

ad4) ha szerinted a MISRA-C nem számít C-nek, akkor olvass utána jobban, hogy mi is az, miért hozták létre és milyen kapcsolatban áll a C-vel.

"ad4) ha szerinted a MISRA-C nem számít C-nek, akkor olvass utána jobban, hogy mi is az, miért hozták létre és milyen kapcsolatban áll a C-vel."

Mondjuk az, hogy alapból a C alkalmatlan safety critical rendszerek fejlesztésére?

"ad1) topicban funkcionális programozásról van szó, OOP-ről max mi kezdtünk el vitázni"

Na akkor fussunk neki még egyszer: a topic arról szólt, hogy szerintem általános célra jobb az OO valamennyi funkcprogos kiegészítéssel (és egész véletlenül efelé tendál valahogy az összes OO nyelv). A "Java 8 egy elmaradott szar"-ra (értsd: olyan featurek jönnek most benne, amit más nyelvek már sok-sok éve tudnak) te meg idetrollkodsz a beágyazott rendszerekkel és a C-vel, mint a programozás másik Szent Gráljával.

"ad2) ha nem vetted volna észre, példaként hoztam fel arra a beágyazott világot, hogy vannak bizony olyan területek, ahol olyan (extrém) dolgoknak is van létjogosultsága, amire bárki más, aki nincs az adott területen, csak bólintana"

Igen, és? Alkalmazásfejlesztésről volt szó ebben a threadban, nem beágyazott rendszerekről. (Az, hogy már ezer+1 nyelv bebizonyította, hogy alkalmazásfejlesztésre messze nem a legjobb a C, ne zavarjon.)

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

"Mondjuk az, hogy alapból a C alkalmatlan safety critical rendszerek fejlesztésére?"

Én ezt nem értem, explain plz, vagy linket. Kösz!

"Alkalmazásfejlesztésről volt szó ebben a threadban, nem beágyazott rendszerekről"

A beágyazott rendszerek nem alkalmazások? devnullba fejlesztik őket?!

"A beágyazott rendszerek nem alkalmazások? devnullba fejlesztik őket?!"

Azért van egy kis különbség egy átlag desktop/szerver/whatever alkalmazás között, mint amit valami minimál erőforrásal rendelkező beágyazott rendszerre teszel rá.

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

ha nem oo-ban van írva, lehetőleg BigData-enabled módon, akkor egyértelműen egy rakás szar!
de ha Java 8-ban van írva, akkor is egy rakás szar, mert a Java 8 egy rakás szar!
és ha C-ben van írva, akkor aztán végképp egy rakás szar, amit csak azért nem írtak át, mert Kernighan személyesen járt közben a Pápánál, hogy ne obszolitálják. De amúgy tényleg egy rakás szar. Mert Csak!
XD

Az igazan komoly szoftverek kizarolag Malbolge-ban vannak irva, HorrorData-enabled es HorrorCode-enabled modon. Az enesanal azota patakokat sirnak a backdoor fejlesztese soran, amelyet hutesre es energiatermelesre (vizeromu) hasznalnak fel.

"Malbolge was so difficult to understand when it arrived that it took two years for the first Malbolge program to appear. That program was not written by a human being: it was generated by a beam search algorithm designed by Andrew Cooke and implemented in Lisp.[1]"

https://en.wikipedia.org/wiki/Malbolge

YE

java != jvm implementacio

"To enable Java in resource constraint embedded systems, several projects implement the Java virtual machine (JVM) in hardware. These Java processors are faster than an interpreting JVM, but use fewer resources than a JIT compiler. Furthermore, the direct implementation of the JVM enables WCET analysis at bytecode level."
[..]
"With the introduction of the safety-critical Java specification the interest in Java processors might increase. Java processors execute bytecode, which itself is easier to analyze. Certification of safety-critical applications will benefit from the direct execution of Java bytecode as the additional translation steps to C and machine code are avoided."

http://www.jopdesign.com/publications.html
http://www.jopdesign.com/doc/chap_javahw.pdf
http://www.jopdesign.com/doc/lerosjvm.pdf
http://www.jopdesign.com/doc/scjreprap.pdf

Gyakorlatban azonban ez nem ilyen szep:
- A hardvert is validalni kell ami osszetett eszkoz eseten nem egyszeru
- Az osszes implementacio amivel talalkoztam csak a Java bytecode-ot tudja futtatni, de tovabbra is igenyel nativ kodot a virtualis gep tobbi reszenek (heap/stack management, loading, I/O, stb.) megvalositasahoz. Ezek merete altalaban meghaladja a valos alkalmazas meretet, es ezeket is validalni kell. (Avagy hatalmasnak kell lennie a projektnek ahhoz, hogy megerje.)
- A forditot is validalni kell
- Az atlag Java programozo ettol meg nem lesz alkalmas ilyen alkalmazasok fejlesztesere (ahogy a C programozok nagyresze sem)
- Hard real-time alkalmazasokat (de javits ki ha tevedek) a GC miatt nem lehet fejleszteni Java-ban. Safety critical rendszereknel gyakori kovetelmeny, hogy inicializalas utan nem lehet tobb memoriat allokalni.

Érintőlegesen régebben foglalkoztam Realtime Java-val és Safety Critical Java-val. Meg tudom erősíteni, amit írsz, ezeknek a változatoknak egészen minimális közük van a standard Java-hoz. A szintaxis ugyan közös, de totál más gondolkodásmódban kell fejleszteni. GC alapból nincs, mindent előre kell foglani, emiatt a standard class library és a rendelkezésre álló API-k is teljesen másmilyenek.
---
Régóta vágyok én, az androidok mezonkincsére már!

1) A hardvert is validalni kell ami osszetett eszkoz eseten nem egyszeru

Pont ezert nem mindegy, mekkora, es milyen komplexitasu, amit validalsz.
http://community.arm.com/groups/tools/blog/2013/12/03/how-fpga-boards-h…

2) Az osszes implementacio amivel talalkoztam csak a Java bytecode-ot tudja futtatni, de tovabbra is igenyel nativ kodot a virtualis gep tobbi reszenek (heap/stack management, loading, I/O, stb.) megvalositasahoz. Ezek merete altalaban meghaladja a valos alkalmazas meretet, es ezeket is validalni kell. (Avagy hatalmasnak kell lennie a projektnek ahhoz, hogy megerje.)

A "nativ" kod a bytecode. A cpu mikrokodban implementalja a bytecode core reszet, sot komplexebb bytecode utasitasok akar bytecode implementacioval is rendelkezhetnek.

http://www.jopdesign.com/doc/ejip.pdf

3) A forditot is validalni kell

Ez mar megtortent, anno a javacard kutatas+fejlesztes kapcsan. pl.: VerifyCard EU project
Martin Strecker: Formal Verification of a Java Compiler in
Isabelle

4) Az atlag Java programozo ettol meg nem lesz alkalmas ilyen alkalmazasok fejlesztesere (ahogy a C programozok nagyresze sem)

Senki nem ugy szuletett, hogy alkalmas ra. A lehetoseg mindenki elott adott, hogy megtanulja.

- Hard real-time alkalmazasokat (de javits ki ha tevedek) a GC miatt nem lehet fejleszteni Java-ban. Safety critical rendszereknel gyakori kovetelmeny, hogy inicializalas utan nem lehet tobb memoriat allokalni.

A publikaciok kozott van hard real-time gc is, hw megvalositassal.

Nehany megoldas jop-vel:
http://www.jopdesign.com/app.jsp
http://www.jopdesign.com/doc/jop_app.pdf

Safety critical rendszereknel mas a fokusz, es sokkal komolyabbak a kovetelmenyek. Es ha mar FP, akkor itt is Ocaml-t hasznaltak.

pl.:

"The Esterel Technologies company markets SCADE SUITE
6TM 1 (Berry 2003; Camus and Dion 2003), a model-based development environment dedicated to safety-critical embedded software. The code generator (KCG 2 ) of this suite that translates models into embedded C code is DO-178B compliant and allows to shorten the certification process of avionics projects which make use of it."
[..]
The new KCG, developed with OCaml, is certified with respect
to the IEC 61508 and EN 50128 norms. It is used in several civil avionics DO-178B projects (such as the A380 Airbus plane, for instance) and will be qualified simultaneously to the project qualifications (with the DO-178B, the tools are not qualified by themselves, but by their usage in a project). The project has been accomplished with the expected delays and costs. The software consists in 65k
lines of OCaml code, including a lexer and a parser, plus 4k lines of C code for the runtime library. The development team was composed of 6 software engineers and 8 test engineers during almost 2 years."

http://users.eecs.northwestern.edu/~clk800/rand-test-study/_eruoctdseti…

1) Egy egyszeru 32b-es processzort valamivel egyszerubb validalni mint egy hardveres Java implementaciot. ;)
2) Hogy jon ide a halozati stack? Maga a JVM tartalmaz olyan reszeket amiket harverben megvalositani nem celszeru. Erre jo pelda maga a JOP.
3) Nem teljes Java
4) Ennyi erovel C-ben is lehet dolgozni
5) A JOP real-time gc-ja leginkabb soft real-time.
6) Ideznek a sajat forrasodbol: "In the field of safety-critical avionics software, the mainstream programming languages are exclusively C and ADA. [...] The restrictions needed to develop safety-critical Java/C++ software removes all the features that differentiate OOP languages than C/ADA." Ez a valosag. A tobbi az majd talan valamikor...

Tudod, bár már majdnem úgy döntöttem, hogy többet nem adok neked ma enni, de azért még hagy szabadjon megjegyeznem, hogy általában a programozási nyelv nem cél, hanem egy szerszám, ami egy jó szakember kezében nagyon sok mindenre jó.
Sőt, ahhoz, hogy egy jó szakember egy jó, használható, stabil és helyesen működő, jól dokumentált alkalmazást - legyen bár az webapp, vagy épp egy repülőgépet egyenesben tartó kód - fejlesszen, nem feltétlenül a progamozási nyelvnek kell tele lennie feature-ökkel.
Mert lehet, hogy te valamit elavult szarnak mondasz, mert nincs benne ez meg az, de egy másik valaki, aki ért is hozzá és szeretné az adott problémát megoldani, leül elé és két nap alatt jobbá teszi a világot, amíg te azon pattogsz hogy mi miért szar.
Szóval lehet, hogy az egyikben nincs clojure, a másikban meg még objektum meg gc sem, de hidd el, nem a szerszám típusa határozza meg, hogy jó kezekben mi minden jót lehet vele alkotni.

Hellóbelló. A topic nem arról szólt, hogy >>szerinted<< mi van, hanem arról, hogy kinek milyen tapasztalata van FP nyelvekkel.
Másik, én nem mondtam egy szóval sem, hogy akár a C, akár a beágyazott rendszerek bármiféle szent grál, ezt te valamiért eléggé félreérted.
A threadben meg NEM alkalmazásfejlesztésről volt szó, hanem arról, hogy kinek milyen tapasztalatai vannak az FP nyelvekkel, ahogy már a topicindító is, illetve most én is legalább 2x leírtam. Mostmár tiszta? :)
Csak te beszélsz itt szent grálokról meg alkalmazásfejlesztésről.

"hogy valaki mindenre osztályokat hoz létre és másra bízza a memóriakezelést. "

Beagyazott rendszereket fejlesztek. OOP-ban.
Ismerni kene a C++ zero overhead elvet.
Ami beagyazott programozasban bosszanto, az a sok szar fordito. Pl. TI C6000. Ez neha belekop a levesbe.

Es igen, igaza van az illetonek a szar minosegu beagyazott kodok kapcsan.

A legtobb C programozonak fogalmas sincs interface-ekrol, nem ismerik az alapveto programozasi elveket.
Ujrafelhasznalhato kodot keptelenek irni. Amit irnak az esztetikai atombomba.
Raadasul nem tudjak, hogy a kodnak melyik reszet kell optimalizalni.

"Ujrafelhasznalhato kodot keptelenek irni."

Na igen, pont erről mesélt ismerős: villamosmérnök irányából érkező emberek, sw fejlesztés kimaradt az életükből, számukra a kopipaszta is teljesen elfogadható megoldás, mert "úgy is apró "dobozokra" van lebontva a dolog". (Értem én, hogy irányítástechnikán ezt tanítják, de...). Na meg, hogy a probléma komplexitását rossz oldalról közelítik meg.

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

Viszont a szakmai sovinizmust hanyagolni kéne. Pár év tapasztalat után ez nevetséges.

Amúgy villamosmérnök vagyok. Több, nagyon jó OOP látásmóddal rendelkező kollegám is villamosmérnök.
Az egyik legjobbnak meg nincs is diplomája.

Fizikusból nem láttam még jó OOP arcot, de biztosan van az is.

Értem én, de olyan villamosmérnököt, aki villamosmérnökként dolgozik, olyanból még nem láttam olyat, aki jó sw fejlesztő is lenne. Nem tartom lehetetlennek, de az sw fejlesztés nem olyan témakör, amit 1-2 év alatt szedne magára az ember. (Kezdve azzal, hogy nem csak az OO látásmód kérdéses itt, hanem kezdve egy egész sor szoftverfejelsztési módszertani kérdéssel).

Fizikusokhoz nem tudok hozzászólni, abból csak 1-2 fizikushallgatóval találkoztam eddig, az alapján nem akarom leírni őket :)

Egyébként nem szakmai sovinizmus, hanem mások a prioritásai egy villamosmérnöknek és egy szoftverfejlesztőnek. Ennyi.

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

"[...] is képesek hasonlóan minőségi kódot alkotni."

Ne is mond, nemrég interjúztattam. Az első 3 jelentkezőt zsinórban kivágtam, mert a következőt nem tudták megoldani:

// Mit ír ki?

$a = 0; $b = null; $c = "0";

var_dump($a == $b);
var_dump($b == $c);
var_dump($a == $c);

Nem az volt a gond, hogy nem ismerték a PHP type juggling bugyrait. Még csak az sem, hogy egyvalaki nem tudta, hogy a var_dump mit csinál. Hanem, hogy zsinorban mind a 3 jelentkező értékadásnak nézte. (Valószínűleg ott nem csak az operátorokkal, hanem más fogalmakkal is bajok vannak...)

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

Off: csak kíváncsiságból...
Az első kettő null vagy false lesz?
A harmadik meg talán true.

Úgy egyébként durva... szerinted az első három fog munkát találni előbb-utóbb? Mert akkor lehet, hogy én is újra keresni kezdek valamit. (igaz, ma kiakasztottam a pénztárost a boltban, mert szerintem 380+200+200+500+80 az kevesebb, mint 1000... Ő meg pár másodpercre még el is hitte. :D)

true, false, true.

null == (int)0 a C-s örökség miatt, ahol a null nem egy kitüntetett valami (mint pl. az SQL-ben), hanem csak simán egy nulla.

(int)0 == (string)"0", mert a type juggling miatt (int)0-ra castolja a stringet

null != (string)"0", mivel a "0" string nem semmi. Viszont az igazán ciki az az, hogy a következő kifejezés meg már true: "" == null. (Meg a "" == 0 is.)

Káosz? Az, hát.

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

Ez nem beugratós kérdés, ez logikai bukfenc. Asszociativitás címszó alatt szokták oktatni ezt a jelenséget, aminek nem felel meg a PHP == operátora. Beugratós feladat? Nem, ez nem beugratós. Ez a tervezés hiánya és az, hogy hogyan szopassuk meg a kódert.

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

saxus-s(z)al értek egyet. Mármint oké, hogy ez beugratós kérdés(nek is elmegy), de ez a logikátlanság elég durva (hiszen ha tudod, hogy a==b, b==c, akkor következtethetsz arra, hogy a==c - php esetén nem).

Egyébként igen, én is inkább a === operátort használom (amikor néha php-t előveszek), mert már valami hasonló hibát én is szívtam meg - nem értettem, mi a franc baj van, miért nem megy. Hát valami ilyesmi volt.

Azert azt vegyuk mar eszre, hogy az egyenloseg tranztiv tulajdonsaga alapvetoen fennall a php-ban is, azonos tipusokon belul. A programozo felelossege, hogy ha kiskutyat, kismacskat, meg nyakorvet hasonlit ossze, akkor a rendszer megprobalja megtippelni helyette, hogy akkor hogyan is kellene ezt vegrehajtani. PHP-ban ez eleg bizarr modon sikerult. Nem mernek nagy osszegben fogadni, hogy pl. Java-ban ne lehetne ilyen peldat felirni (short, int, char kornyeken, ahol mindenfele C-hez hasonlo tipuskonverzio tortenik).

Valszeg azért ezek sarkalatos példák, azért nem olyan rossz a helyzet mindennapi használatban, illetve egy "átlag php kóder" (könyörgöm, ne kövezzetek, tudom, hogy aki ért hozzá annak a kezei alatt a php-vel is gyönyörű dolgok születhetnek, amúgy meg anno én is sokat fejlesztettem benne) nem fog belefutni, vagy nagyon kis eséllyel a mindennapi munka során.
Viszont saxusnak igaza van, hogy mostanában mindenütt kritikán aluli a felhozatal. Nem tudom, mi van, a mai fiatalok már programozni is lusták, akinek meg van/volt esze, már rég min. Bécsben dolgozik...

Használható, nekünk is van ~600KLOC-nyi PHP kódunk üzemben, de ilyen kis nüanszok annyit képesek megszopatni az embert, hogy bőven visszahozta volna azt az időt, amit ha valami statikus típusú nyelvben kezdtük volna el, pl. C# vagy Java. Már csak pl. ott, hogy lett volna refactoring.

Mikor megláttam ezt, egyből az volt az első gondolatom, hogy erre át kellene írni az egészet: http://hacklang.org/

(Ami azt illeti, erős a gyanúm, hogy nyáron, ha lesz rá időm, ki fogom értékelni, hogy mennyi esélye lenne átportolni a projektet.) Most, hogy időm 90%-át C# mellett töltöm, kínszenvedés PHP-zni.

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

És a .NET 3.5-be honnan került bele? Csak nem Haskell?
Erik Meijer

Meijer's research has included the areas of functional programming (particularly Haskell[3]) compiler implementation, parsing, programming language design, XML, and foreign function interfaces.

His work at Microsoft included C#, Visual Basic, LINQ, Volta, and the Reactive programming framework (Reactive Extensions) for .NET.

Simon Peyton Jones

[...] Since 1998 he has worked as a researcher at Microsoft Research in Cambridge, England.[...]

He is a major contributor to the design of the Haskell programming language,[6] and a contributor of the Glasgow Haskell Compiler (GHC).[7] He is also co-creator of the C-- programming language, designed for intermediate program representation between the language-specific front-end of a compiler and a general-purpose back-end code generator and optimiser. C-- is used in GHC.

Ez nem funkcionalis programozas, hanem egy theorem provernek a hasznalata. Ezzel csinaltak a helyessegbizonyitast. Az egy dolog, hogy a Coq az egy funkcionalis nyelven van implementalva, de ez nem jelent semmit. Barmilyen mas ekvivalens theorem proverrel mukodik a dolog.
Van Javaban irt theorem prover is, a Jape.
Van C++-ban irt theorem prover is, a z3, a Microsoft Research csinalja.

- sajnos én már nagyon sokat elfelejtettem, de amikor használtam (suli), akkor nagyon tetszett. Egy pár dolgot kikerestem róla:
* Könyebb megtanulni, mert kevesebb alap koncepciót kell megérteni (nincsenek hozzárendelések, ugrások, ciklusok)
* magasabb produktivitás: ugyanazt a feladatot funkcionális nyelven kb faktor 5-10-el rövidebben meg lehet írni mint egy procedurális nyelven.
* a matematika eleganciája átültethetö a programszintaxba:
[n | n<-a, n<=10] megfelel a {n | n ∈ a ∧ n ≤ 10} kifejezésnek
* a "miként" helyett a "mi" áll a programozás központjában
* könyebb a programok helyességét bizonyítani
* volt korrepetítorom (millió thx Csaba!) szerint banki és tözsdei szoftvereknél nagy pénzeket lehet kaszálni, ha jól nyomod a funkcionális nyelveket. Nála láttam a "Stunts" (http://hackage.haskell.org/package/stunts, http://www.youtube.com/watch?v=XoE5CKLLnaM) játékot újraprogramozva Haskell-ben...eldobtam az agyam.

* ami nem annyira egyszerü, az GUI-k készítése, de lehet hogy már itt is történt elörelépés. F#-t akarom már mióta megnézni Visual Studio-ban

- http://learnyouahaskell.com ne ijesszen el a gyerekrajzos illusztráció. Szerintem jó anyag

--------
HOWTO: Zentyal+Zarafa+Setup+Outlook+Thunderbird+mobilephone sync

nem veszem kötekedésnek. jelenleg nem használom, amit sajnálok, hogy az akkori tudásom kútba veszett (bevallom: nekem nagyon nehezemre esett átállítani az agyam procedurálisról funkcionálisra) - és mivel azóta nem gyakoroltam, szerintem egy sort nem tudnék korrektül leírni.
akkor nem volt idöm és felhasználási területem hozzá, most meg néha jól jönne...

--------
HOWTO: Zentyal+Zarafa+Setup+Outlook+Thunderbird+mobilephone sync

Én csak olyat láttam, hogy leváltották és a váltással a szolgáltatások színvonala mintegy 4-5 évvel visszaesett. :(
Amikor indult a Magic, jónak tűnt, csak "kissé" lassú volt az akkori vasakon. Én valahol az 5.5-5.6-os verzió környékén szálltam ki belőle, utána nem tudom, merre ment a fejlesztése, mi lett belőle. Az uniPaas-t egyszer reklámozni kezdték a prog.hu-n, akkor belenéztem a demoba, de valahogy... hát nem állt kézre, na... :)

- mellékhatások, megosztott állapot nélküli (pure) funkciók -> masszív parallelizmus
- streams, lazy eval -> "végtelen" adatmennyiségekkel dolgozó funkciók

- rekurzió, tail call optimization -> egyes adatszerkezetek, problémák elegáns (rövid, egyszerű) megvalósítása, megoldása

- makrók -> DSL, "a problémát igazítom a programozási nyelvhez" vs "a programozási nyelvet igazítom a problémához"

Mi is tanultunk az egyetemen funkcionális programozást, illetve elkezdtem a coursea-n egy scala tanfolyamot, de nekem nem igazán jött be.
Értem én, hogy mire lenne jó, de én nem matematikus vagyok, hanem mérnök :) Nem kapok sírógörcsöt, ha változót lehet használni, meg ha a
nagyon "elegánsan" lehet valamit leírni, ami kb. addig elegáns, amíg bele nem kell nyúlni, mint ahogy a lent említett kolléga említette.
Ráadásul az OO kódok tervezésére már vannak teljesen kiváló módszerek (hogyan írjunk jól nagy programot, amit karban tudunk tartani),
amiket a funkcionális programozásnál nem láttam, ezért azt inkább a procedurális programozás alternatívájaként éltem meg. Ezzel együtt
használunk funkcionális nyelveket (pl. SQL) és OO nyelvbe beszivárgó elemeket, de az a véleményem, hogy ezen a szinten meg is kellene
maradni.

bbking és ssikiss leírt egy csomó előnyt, én még ezeket tenném hozzá:

Nagyon jól lehet modulárisan használni, a komponenseket nagyon jól lehet kombinálni.
Könnyű unittesteket készíteni hozzájuk, mivel nincsenek állapotok, amikre nehéz felkészülni.
Egyszerű, jól érthető párhuzamos kódokat lehet írni (ez is az állapotmentességből adódik).
Egyszerűbb a refaktorálás.

Én is inkább a multiparadigm nyelvekben hiszek, mint a tisztán funkcionális vagy a tisztán imperatív, OOP nyelvekben, ezért a Scala-t ajánlom a funkcionális programozás megismeréséhez és ahhoz a következő anyagokat:

Egy nagyon érdekes bemutatása a Scalanak (Venkat Subramaniam)
Majdnem ugyanez, csak kevésbé érdekesen, de jobb képminőségban (Venkat Subramaniam)
Tőle van egy nagyon jó Scala könyv is
Egy könyv, ahol a funkcionális programozás áll a középpontban: Functional Programming in Scala

( szemet | 2014. 03. 20., cs – 18:36 )

Eddig "Tetszik, és használom is (hobbi)" voltam, de pont most a munkahelyemen egy "proof of concept" típusú dolgot fejlesztek Haskellben - igazság szerint én nem bánnám ha úgy is maradna, vannak rá érveim is - de azért sajnos még elég ritka nyelv ahhoz, hogy szervezetben valakit kiverjen a hideg veríték ennek a lehetőségnek a felvetésétől. ;)

De majd elválik. Ha rám parancsolnak, hogy írjam át mondjuk C-be (hát mire való a fordítóprogram?;) azért nem leszek túl vidám...

( Gregor | 2014. 03. 20., cs – 19:47 )

Tetszik, mert szép dolgokat mondanak róla, és már egy ideje tervezem a megtanulását.

( saxus | 2014. 03. 20., cs – 20:09 )

Örülök azoknak a dolgoknak, amelyek beszivárognak az OOP nyelvekbe, de egyébként nem kívánok tisztán funkcprogos nyelvekkel dolgozni.

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

Az egész Scala/Java8/stb. dolgokkal egyébként az a szép, hogy anno ugyanezek miatt egy csomóan itt végigfikkantották a C#-ot, pedig egy valag dolgot ezer éve tud már a C# is. Néhány dolgot sokkal jobban. (Java 8 ahogy néztem kb. egy Pre .NET3 szint, Scalat meg annyira nem ismerem.)

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

( carlcolt | 2014. 03. 20., cs – 23:19 )

Nekem ez olyan mint az SQL-en kívüli világ DB-knél. A világ programozóinak nagy része az OOP-t és a procedurális programozást érti, ha elkezdesz valamit csinálni, vagy valakivel valamit csináltatni, csak akkor tudod pótolni később az idő- és emberhiányodat, ha aránylag könnyen találsz olyan fejlesztőt, aki érti hogy hogy kell folytatni (márpedig az átlagember számára a legolvashatóbb procedurális kód is kínai).

Másik megközelítésből, ami lazán kapcsolódik azért: egy procedurális vagy egy OOP kód sokkal de sokkal olvashatóbb és könnyebben módosítható mint egy funkcionális. Mit csinálsz, ha neki kell állnod debuggolni, és tele kell nyomnod a kódot egy rövid időre echoAndExit()-ekkel és logLine()-okkal? Vagy hogy tartósabbat mondjak, optimalizálnod és cache-elned kell. Mit kell csinálnod, ha egy funkcionális programozó olyan kódjába futsz, ahol büszke arra, hogy 2 sorban leírta azt, amit procedurálisban 10 lenne, és abba kell beleírnod két furcsa elágazást meg műveletet, amit procedurális nyelven nyilvánvaló, hogy hova kell írnod, de funkcionális nyelvben kb az egészet szét kell hozzá bontani (de előbb meg is kell érteni, ami nagyjából annyit takar, hogy az agyad lebontja valami algoritmikusra és végigjátszik egy folyamatot, jéé, hisz ez pont a procedurális programozás).

Csak hogy egy OOP-beli példát is mondjak. Van egy osztály amiből öröklődik 20 másik, van egy kiirFormazva() nevű függvény, és a 18 (előtte napi tudásunk szerint 20) származtatott osztálynak megfelel a kiirFormazva() függvény ősosztálybeli változata, de a 2 másikban totál újra kell írni. Ez egyik napról a másikra derül ki, és sok másik helyen használod ezen osztályokat és a kiirFormazva() metódusukat. Hogy tervezel meg egy funkcionális programot úgy, hogy hozzá se kelljen nyúlni ilyenkor semmi máshoz, csak a két származtatott osztály kiirFormazva() metódusához (vagy azzal ekvivalens munkát igénylő dologhoz)? Ha hozzányúlsz, hány embert ismersz, aki érteni fogja mit csináltál ott? OOP-nél midnenki aki velem dolgozik, érti hogy ott mi történt.

Ennek ellenére vannak területek, ahol jó (pl. mesterséges intelligencia, absztraktabb számítástudományi és matematikai feladatok (kutatás, ahogy fentebb is írták, "ami jó, az megy majd az OOP és scriptnyelvekbe is")), de ahol sűrűn változó inputok és outputok vannak (==versenyszférában GUI-k), ott mentsen meg tőle az Isten.

Még az egészhez annyit teszek hozzá, hogy sokakkal ellentétben mindigis csapatjátékos voltam kódolásban, minden bonyolultabb sorba kommenteket írok évek után is. Ha regexpről vagy 2 egyszerűbb kifejezésnél bonyolultabb elágazásról vagy ciklusról van szó, példákat írok kommentbe mi megy át és mi nem megy át ott, stb. Sőt, az igazat megvallva remélem, hogy van a pokolban egy speciális bugyor azoknak, akik bonyolult regexpeket írnak a kódjukba komment nélkül.

"SQL"

FYI: az SQL is egy funkcionális nyelv.

"és tele kell nyomnod a kódot egy rövid időre echoAndExit()-ekkel és logLine()-okkal?"

Tarkónlövöm a kódgányolót. Miez? PHP1.0? Debugger vajon mire van?

A másik példa meg bullshit. Ha OOP nyelven OOP megoldást használsz egy OOP kóder érteni fogja. Ha egy funkcprogos nyelvben funkcprogos megoldást használsz a funkcprogos kóder érteni fogja.

Egyébként meg azért meg lehetne nézni, hogy mennyi nyelvbe szivárog be egy-egy funkcprogos elem. C89 óta azért lefolyt néhány vödörnyi víz a Dunán.

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

1. Az SQL arra volt pelda, hogy hiaba nem az a legjobb valasztas neha db-re, sokszor erdemesebb azt valasztani, mert arra talalsz szakembert.
2. Igen? Leptess mar vegig egy debuggert egy 130x lefuto ciklusban ami lemegy onnan meg 10 fuggveny melysegig. Meg egy olyan bug eseten hogy hasnalsz debuggert temp logolas helyett, ami csak live-ban jon elo es ott is ritkan? Lojj nyugodtan tarkon, de szerintem sokszor rohadtul nem a debugger a legkenyelmesebb megoldas.
3. Az SQL-es szempothoz hasonloan ez is gazdasagi szempont volt (sokkal konnyebben talalsz valakit, aki OOP-hez ert)

Hát ha van egy _normális_, jól használható debugger, akkor szerintem ... inkább nem kommentálom, mit tennék azzal, aki beleszemetel e célból a forráskódba. ;)
Hm. Jobban belegondolva, felejtsd el a smiley-t: a DD-WRT-ben évekig(?) volt egy szép, méretes backdoor. A kedves fejlesztő benne felejtette a debughoz használt kódrészletet...

Sok mindennel egyetértek, amit írsz, de azért ne keverjük össze a "beleszemetelés ... a forráskódba"-t a naplózással.
A naplózás az nem felesleges dolog, hanem általában egyenesen szükséges is. (Ki, mikor lépett be/ki a rendszerbe/rendszerből, miket miről mire módosított, ...)
Ha van jó naplózás, akkor oda nagyon szépen belefér a debug szintű log is, amit éles (production) használatnál nem kapcsolnak be (bent van a kódban, de mégsem fut).

(már az is meglepő, ha van aki valamiben egyetért velem ;) )

Carlcolt nem logolásról írt a szó eredeti értelmében, hanem debughoz használt sorokról, amiket az élesítés előtt eltávolít a forráskódból.
Rohadt rég kiestem minden ilyesmiből, de én letörném a pici kezét annak, aki ilyesmit csinál és nem én vagyok. :)
Az egy más téma, hogy logolást úgy megcsinálni, hogy állítható a loglevel, de akkor az az éles kódban is ottmarad.

Idézet tőle: "Es melyik a konnyebb, ezt felparameterezni, vagy betenni majd commit elott kivenni a ket plusz logolosort?"

A példáid alapján a Nem ismerem és nem tetszik kategória illik rád. Elég arrogáns azt feltételezni hogy a 40-50 éve fejlődő funkcionális nyelvekben nem létezik megoldás ezekre a problémákra, és csak az általad ismert megoldásokkal érhető el hibamentes kód. Mert a debuggolás és az echoAndExit() elvileg ezt a célt szolgálná.
A titok abban rejlik, hogy mindig az adott nyelv eszköztárát kell használni, és nem kalapáccsal esni neki a csavarnak. Mondjuk láttam már olyan Java kódot, amin látszott, hogy a fejlesztő mostanában tanulhatta a map, fold, flatMap és társait (a kódot a Coursera-s Scala tanfolyam idején láttam), és mindent ezen logika mentén kódolt Java-ban. A Guava nevű library adta a kezébe a puskát, amivel lábon lőtt mindenkit, akinek hozzá kellett nyúlnia a kódhoz. Szóval az emberi hülyeségtől nem ment meg a funkcionális paradigma sem, de adott esetben OO programozó is tud szebb kódot írni ha ismer egy-két dolgot a funkcionális nyelvekből. Szép kódon könnyen karbantartható, általában jobban teljesítő kódot értek, nem az elegánsnak hitt teljesen nyelvidegen szutykot.

Egyébként az echoAndExit és a származtatott osztály példádra is van pontosan ugyanannyira hatékony funkcionális megoldás is. Az első esetben az csak egy függvény, ami visszaadja a bemenetét amellett, hogy kiírja azt. wow. A másodikra ott a pattern matching, funcprog 101, Erlang, Haskell, Scala mind tudja (Lisp-eket nem tudom).

( crystal88 | 2014. 03. 20., cs – 23:04 )

Elsőre azt hittem, értem a kérdést, de így elolvasva a kommenteket nem biztos.

Szóval a "funkcionális programozási [...] paradigmával" való kapcsolatomba beletartozik az, ha multiparadigmás (OOP + funkcionális) nyelveket használok és ki is használom a funkcionális elemeiket? (php scala java8 javascript go stb)

( BaT | 2014. 03. 21., p – 00:19 )

Alapvetően tetszik a koncepció, bár szerintem komplex programokat tisztán funkcionálisan nem szerencsés implementálni. Inkább olyan helyeken használom szívesen, mint pl. c# linq kifejezések, eseménykezelők, stb., vagyis ahol csak kiegészítik az alapvetően oop kódot. Épp ezért se azt nem mondanám, hogy nem használom, se azt, hogy csak hobbi projekteken használom.

Btw épp a héten szívtam egy sort javascripttel, igaz ez inkább a js hibája és nem a funkcionális paradigmáé (magára a problémára hamar rájöttem, a megoldást viszont nem tudtam volna magamtól kitalálni).

( lajos22 | 2014. 03. 21., p – 01:14 )

"Milyen a kapcsolatod..."
Én nem szekálom őt, ő se engem...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( Finder | 2014. 03. 21., p – 04:28 )

Regen eleg sok programot irtam PLT Scheme-ben. Eleinte nem szerettem, de most mar ugy gondolom, hogy hasznos volt. Gyakran futok bele olyan problemaba aminek a funkcionalis megoldasa sokkal erthetobb es elegansabb lenne.

( szemet | 2014. 03. 21., p – 07:47 )

Én a deklaratív stílus (mint absztrakció) nagy híve vagyok, akkor is ha ezért meg kell bontani a kód egységes képét és szemléletét (pl. SQL DDL/DML-t kell használni az adatkezeléshez, XML-t az UI definícióhoz, egy másik féle XML-t a tökömtudjami konfigurációjához stb...)

A funkcionális nyelvek előnye, hogy ez a stílus a természetes bennük, így aki ezt kedveli tisztább szárazabb biztonságosabb (egységesebb) környezetben érezheti magát - ráadásul nem csak ott használható ahol valaki külön beleszuszakolta a lehetőségét a rendszerbe hanem mindenhol/bárhol, illetve mivel az adott deklaratív DSL a nyelv része a kiterjeszthetőség/testreszabhatóság egy természetesen létező lehetőség!

Mondjuk az igazsághoz hozzá tartozik, hogy inkább a funkcionális programozás tett a deklaratív stílus kedvelőjévé mint fordítva.

Akkor lehet látni leginkább az előnyeit, ha az ember egy ideig koherensen rá van kényszerítve a használatára. És egyszer csak azt kezdi észrevenni magán, hogy a hagyományos kódokban az explicit idő (állapotváltozás) látványa valamiféle kellemetlen és kényelmetlen érzéssel tölti el. ;)

( emberk | 2014. 03. 21., p – 08:47 )

A "nem ismerem"-et választottam, de attól picit többet tudok róluk. Egyszer egy mintaprogramot kipróbáltam (ugy emlékszem haskel-ben), de semmi olyat nem adott amit (C-ben, de nem ez a lényeg) nem tudtam volna ugyanilyen könnyedén megvalósítani. Matematikára minden jó, ami gyors. Azon felül kevés a számomra hasznos fejlesztői könyvtár.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( handler | 2014. 03. 21., p – 17:03 )

Kisse meglepo milyen kevesen hasznaljak, foleg munkahoz. Mi a kerdes apropoja ?