- A hozzászóláshoz be kell jelentkezni
- 8500 megtekintés
Hozzászólások
Tetszik az elgondolás, de nem használom, mert nagyon kevés az olyan probléma és környezet, amikor ez volna a jó választás.
--
The Net is indeed vast and infinite...
http://gablog.eu
- A hozzászóláshoz be kell jelentkezni
+1
Apple MacBook Pro 13"
C2D 2.26GHz/3MB | 4GB@1067MHz | 160GB@5400rpm SATAII
- A hozzászóláshoz be kell jelentkezni
Nem tetszik az elgondolás, mert nagyon kevés az olyan probléma és környezet, amikor ez volna a jó választás.
Ha funprogramozást akarok látni, akkor valami egzotikus nyelvben gondolkodok. A funkcionális nyelvek körül egyelőre nagyobb a hype, mint a hasznuk.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
ja, ugy 20 eve. :)
- A hozzászóláshoz be kell jelentkezni
A hype-érzet lehet hogy onnan ered, hogy az egyetemeken és a kutatásban nagyobb a funkcionális nyelvek súlya mint az iparban.
Ennek megvan az oka.
A funkcionális nyelvek közelebb állnak a matematikához, így a kutatásban könnyebb velük dolgozni. Mióta vannak jó fordítóprogramok, az iparban is jobban használhatóak lennének sokféle problémára. Kérdés hogy az ipar felfigyel-e rájuk.
- A hozzászóláshoz be kell jelentkezni
Ez mondjuk igaz, az iparban még csak szűk területeken találkoztam vele, míg az egyetemen több szó volt róluk. Akkor kéne egy felmérést nem friss egyetemistákkal, hogy nekik mi az érzetük.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
tudtommal az erlang is funkcionális és nehéz rá azt mondani, hogy nem használja az ipar :)
- A hozzászóláshoz be kell jelentkezni
tudnal mondani 5 komoly, mindenki altal ismert termeket, ahol erlang van a hatterben?
(facebook xmpp server, illetve az erlangos <1%os shareu webszerver nem er!)
- A hozzászóláshoz be kell jelentkezni
nem, végfelhasználói szoftvert nem tudok mondani, de ha az Ericsson és a Morgan Stanley nem elég komoly cég, akkor nem tudom, hogy mi...
- A hozzászóláshoz be kell jelentkezni
Amazon is használ, T-mobile - SMS gateway, Motorola - a hívásfeldolgozásnál
...Amik először eszembe jutnak
Szerk: meg is van az 5 :)
- A hozzászóláshoz be kell jelentkezni
Aaa, az erlang ilyen kis semmi nyelv, amiben
ilyen kis semmi core halozati eszkozok szoftveret irjak. :)
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
azt, hogy az ericsson hasznalja, azt mindenki tudja. ok talaltak ki, bazz. csunya lenne, ha nem hasznalnak :-)
az volt a kerdes, hogy az ericcson berkein KIVUL hol hasznaljak.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
utalom a monty pythont.
- A hozzászóláshoz be kell jelentkezni
Z, a javat imadod, most netbsdzel es meg montipajtont sem szereted.
Nyugtass meg kerlek, hogy nem az iparban dolgozol ;-)
- A hozzászóláshoz be kell jelentkezni
de ;-)
- A hozzászóláshoz be kell jelentkezni
+1
Nekem is ez jutott eszembe a hozzászólásról :-)
- A hozzászóláshoz be kell jelentkezni
lolka
- A hozzászóláshoz be kell jelentkezni
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
igy jartal.
- A hozzászóláshoz be kell jelentkezni
1. Miért zavar az, hogy az Ericsson használja, ha egyszer gerinchálózati központok vezérlésére a tapasztalat szerint alkalmas ? Amúgy open source, bár tényleg ők találták ki.
2. Mellesleg sok kisebb cég is használja, e-payment, stb. témákban. Ha statisztika érdekel, iratkozz fel az erlang mail listára, és nézd meg, milyen mail domainből jönnek hozzászólások. Nem csak erixonost meg gmailest fogsz látni :)
(www.erlang.org)
- A hozzászóláshoz be kell jelentkezni
nem zavar, kivancsi voltam, hogy hazon kivul mennyire eletkepes. az erlang & otp in action most jelent meg a manningnel, csak azert :)
- A hozzászóláshoz be kell jelentkezni
Tetszik az elgondolas, de nem hasznalom, mert tobbet kellene vele foglalkoznom. Illetve elofordult mar tobbszor olyan, hogy egy problemat funkcionalis stilusban oldok meg imperativ nyelven.
- A hozzászóláshoz be kell jelentkezni
+1
multkor a Java kodomra ra se lehetett ismerni :-)
(anonymous methodok mint ctorparameter az enum-ertekeknek :))
- A hozzászóláshoz be kell jelentkezni
Ott eleg nehez, tekintve hogy a function-t mint nyelvi elemet a 7esbe akartak bevezetni, de aztan meggondoltak magukat.
Osszehasonlitasul: a vilag osszes tobbi p > 1% elofordulasi nyelveben letezik legalabb a fuggvenypointer fogalma
Idekivankozik Lajosba masodik mondata az alabbi napirajzrol: http://napirajz.hu/archives/2010/09/06/0/
- A hozzászóláshoz be kell jelentkezni
nem azt mondtam, hogy funkcionalis, hanem hogy nagyon hasonlo. koszi, tudom mit tud a Java, azt is, hogy mi lesz/lett volna a 7esben.
es az, hogy Javaban nincs fuggvenypointer, sosem hianyzott meg annyira. ahol minimalisan igen, ott meg ki lehetett valtani OOPvel.
de tessek, ilyen egy ilyen kod, ami nyilvan jol kihasznalja a nyelv lehetosegeit:
interface P {
List<Card> match(List<Card> cards);
}
enum Value {
HCARD(new P() {
...
}),
PAIR(new P() {
...
}),
...
private final P predicate;
private Value(P predicate) {
this.predicate = predicate;
}
public List<Card> match(List<Card> cards) {
return predicate.match(cards);
}
}
hasznalni meg egyszeru, mint a faeket: Value.HCARD.match(akarmi)
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy tudod, mi a java :)
Viszont en akarhanyszor hozzanyulok, mindig arra lyukadok ki, hogy a nyelvi hianyossagait kerulgetem, a kenyelmetlen - tudom, az utobbi evekben feljavitott - reflexiot, a fuggvenypointerek hianyat, a rendes delegacio hianyat, a polimorfizmus egyes eseteinek hianyat, stb...
De nyilvan ha valaki java-guru, akkor ezek hianya fel se tunik, mint ahogy magyarban se tunik fel a nemmegkulonboztetes hianya, ram meg furan neznek, ha egy fiuorientalt kornyezetben a veletlenszeruen elofordulo noi fejlesztokre she helyett he-t mondok, mert ugye minden mas nyelvben ott van, en meg csak forditom magamban az o" -t...
Sz'al par ev mas nyelvekkel, es furan fogsz nezni, hogy mennyi minden hianyzik innen :)
- A hozzászóláshoz be kell jelentkezni
C++/C#/eiffel, kis erlang mostanaban, kis haskell megvolt. tovabbra sem erzem magam kenyelmetlenul:)
- A hozzászóláshoz be kell jelentkezni
Java mellett volt C#-os projektem, az egészen baráti volt,
van most egy C++-os is, azt nagyon de nagyon utálom (dcom api-val kommunikálás, ACE framework-kel), egyszerűen állandóan a mit hozunk létre lokálisan, mit heap-en, hogyan konvertálgatunk a kettő között bohóckodással szívok, dislike :)
- A hozzászóláshoz be kell jelentkezni
Ilyen szöveg után ugye sejted, hogy nehéz lesz komolyan venni a véleményed programnyelvek témakörben? :D
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Merthogy?
Egyszerűen kényelmetlennek találom, hogy olyan dolgokkal kell foglalkoznom programozás közben, ami alapvetően és elsősorban a nyelv/interpreter/whatever dolga lenne, amivel én foglalkozni akarok, az a lehető legjobban tesztelt, legjobb struktúrával/olvashatósággal rendelkező kód, amit valamilyen szabályok (design pattern) alapján tudok építeni, lehetőleg minél több nyelvi támogatással.
Java-ban ez nagyjából megvan, de néha itt is úgy érzem, hogy sok felesleges kódot kell írnom.
- A hozzászóláshoz be kell jelentkezni
Ha jol értem amit mondtál, akkor nekem is azt kell mondanom, hogy c++-t ezek szerint sokat nem láttál.
De no offense.
- A hozzászóláshoz be kell jelentkezni
Példák:
- unit test framework-ök elég gyengék
- normális hibajelzés hiánya (visual c++ legalábbis csak azt nem mondja meg, hol van a hiba)
- típuskonverziók különböző könyvtárak között (tipikusan m$ vs saját cuccok)
- UTF8 kezelése nyelvi szinten?
- Refactoring támogatás fejlesztői eszközökben?
- java-ban új objektum létrehozása: new XXX(), és annyi, C++-ban auto_ptr, shared_ptr, lokális, ha nem úgy jött létre, ahogy nekem kell, akkor másolgatni ide-oda
- ACE framework nem igazán tetszik (ez nem a C++ hibája, csak én sirok miatta)
- java-hoz képest nagyon kevés/nehezen integrálható könyvtár
- hosszú fordítási idő vs. java-ban azonnal látom, ha valami nem jó
Értem én, hogy C++-ban ugyanúgy lehet használni a design pattern-eket, egyszerűen csak a Java-hoz képest kényelmetlennek tartom a C++-t, úgy érzem, hogy a nyelvvel/környezettel szenvedek, és nem a feladatot oldom meg.
- A hozzászóláshoz be kell jelentkezni
az ACE tenyleg eleg gaz, nekem se jott be anno. :) a Qt megoldja a tobbi problemad egy reszet. amugy igen: a c++ kenyelmetlen, en sem szeretem :-)
- A hozzászóláshoz be kell jelentkezni
Jajj, ilyet ne írj már, mert kezdődik a flamewar :)
- A hozzászóláshoz be kell jelentkezni
A Qt tenyleg jo, illetve forditashoz erdemes reszben valami fasza make kornyezetet hasznalni (peldaul CMake), reszben pedig agyonparameterezni, ha jol emlekszem Jason kollega egy masik szalban irt erdekes dolgokat, majd megkeresem neked.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Juuuuj!
A Java jó a c++ nem?
Ez a legellenszenvesebb hozzászólás, amit a huppon olvastam eddig :)
- A hozzászóláshoz be kell jelentkezni
fejtsd ki, mi az, ami szerinted c++ban olyan tok jo, javaban meg nincs.
- A hozzászóláshoz be kell jelentkezni
Sebesség?
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Azért érdekes, hogy a Netbeans és az Eclipse felülete miylen lassú, és hopp - minkető Javas.
- A hozzászóláshoz be kell jelentkezni
es tudod mit csinalnak a hatterben, etc? nem azert lassu, mert java, hanem mert a diszked a szuk keretmetszet. egyszer profilozd ki. nem hiaba valtottam ssdre.
- A hozzászóláshoz be kell jelentkezni
melyik C++-ban irt hasonlo tudasu IDE-vel osszehasonlitva erzed lassunak?
Tyrael
- A hozzászóláshoz be kell jelentkezni
Hát nem tudom, hogy melyik IDE-t melyik nyelveken irták, de
xcode, vs(, qtcreator); ezek pl. mind jol müködtek.
- A hozzászóláshoz be kell jelentkezni
Nezz meg egy normalisan megirt Java IDE-t (JetBrains altal fejlesztett cuccok).
- A hozzászóláshoz be kell jelentkezni
ja, sajna a netbeans egy rakat talicska ilyen szempontbol.
- A hozzászóláshoz be kell jelentkezni
btw. PHPStorm-ot nezted mar?
szimpatikus, gondolkozom rajta, hogy megveszem.
Tyrael
- A hozzászóláshoz be kell jelentkezni
Azzal dolgozok kb egy honapja, mindjart jon a 2-es verzio :)
- A hozzászóláshoz be kell jelentkezni
jaja, lattam, betakat szedem szorgalmasan.
Tyrael
- A hozzászóláshoz be kell jelentkezni
Nem értem, hogy miért lenne az eclipse lassú? Nekem egyáltalán nem lassú még a céges gépen sem (P4-es), SSD vinyóval, sem az otthonin (Core2Duo, hagyományos vinyó).
730 megás projekt könyvtár, 35 mega forráskód, 4700 file.
- A hozzászóláshoz be kell jelentkezni
Szabadság :)
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
pelda?
- A hozzászóláshoz be kell jelentkezni
Érzés. A Java ráderőlteti az osztályokat, a C++ nem, ott akármerre el lehet indulni. (ha most jön az, hogy de Javaban is lehet... akkor hagyjuk, persze mindenben mindent lehet, kérdés mit támogat explicit a nyelv)
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Egy alapvetoen oop nyelvben egyaltalan nem baj az, ha minden osztaly, azt az egy plusz sort meg ki lehet birni, masreszt pedig egysegesebb lesz tole a nyelv. Egy OOP nyelvben nem biztos hogy helye van a C/scripting szemleletnek.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
Ezt most miért mondod? A Java OO, a C++ meg nem. Az egyik kötöttebb, a másik meg nem. Egy szó nem volt arról, mi a jó, és mi nem az.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
bizonyos szempontbol a C++ "OO-bb" mint a Java (tobbszoros orokles, templates).
viszont a nyelv teljesen radbizza, hogy hogyan szeretned megkeseriteni az eletedet, szemben a Java-val, ahol ennek jobban megszabott modja van. :)
Tyrael
- A hozzászóláshoz be kell jelentkezni
a convention alapu dolgok sokszor jol mukodnek. :)
- A hozzászóláshoz be kell jelentkezni
Nem arról van szó hogy jó vagy nem jó, hanem hogy java után a c++-ban (fordító hibajelzése, infrastruktúra, fejlesztői eszközök) nagyon sok minden eléggé kényelmetlen, fapados.
(clang elég igéretes, XCode meg hiába szép és jó, csak Mac-re lehet vele fejleszteni, ahogy néztem...)
- A hozzászóláshoz be kell jelentkezni
Senki nem mondta, hogy nem lehet kényelmetlen. Csak az írásod alapján az a kép rajzolódik, hogy te nem is érted, miért van mégis így C++-ban.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
De, teljesen értem, hogy miért van így C++-ban, egyszerűen a java után nagyon kényelmetlennek tartom. Nyilván azért, mert nem foglalkoztam még vele eleget, ettől függetlenül ez a saját tapasztalatom.
- A hozzászóláshoz be kell jelentkezni
HCARD(new P() {
...
}),
PAIR(new P() {
...
})
Ebben az esetben mit nyertel az anonymous inner classal constant specific class bodyval szemben?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
ezt most a .sig-be vagy a híres utolsó mondatok.txt-be tegyen?:)))
- A hozzászóláshoz be kell jelentkezni
Ugyan miert? :^) Szerintem nagyon nyakatekert es hatekonytalan modon oldott meg valamit amihez a nyelvnek van kesz megoldasa.
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
igen, igazad van, amire felhivtad a figyelmem, elegansabb lett volna. koszi!
- A hozzászóláshoz be kell jelentkezni
Pedig remenykedtem, hoogy tanulok valami ujat... ;^(
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
- A hozzászóláshoz be kell jelentkezni
+1
A funkcionális paradigmának teljesen megfelel, ahogy használod. Java használata esetén nem is tehetsz mást :-)
- A hozzászóláshoz be kell jelentkezni
Multiparadigmas nyelvek FTW!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Igen, de csak n.-edik tanult nyelvnek.
Különben úgyis csak "Fortranban" fognak bennük az emberek programozni.
Tanulási szakaszban nincs jobb mint a következetes nyelvek kikerülhetetlen korlátokkal, az emberek lusták és sosem jönnek rá maguktól a következetesség előnyeire - ha nincsenek rákényszerítve, kikerülik a szabályokat ha terhesnek érzik.
Szóval purely-OO és purely-functional nyelvek FTW...
- A hozzászóláshoz be kell jelentkezni
Ez mondjuk nagyon erősen emberfüggő. Én C++-al kezdtem, ami erősen multiparadigma, és mégsem kezdtem el gányolni. Nem érzem magam kivételnek. Persze tudom, hogy kikről beszélsz, ismerek olyat is, de ez túl általános.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Használtál huzamosabb ideig határozottan egyparadigmás nyelvet? (smalltalk, haskell, SML stb...) És onnan visszanézve mondod ezt a korai C++ kódodra?
- A hozzászóláshoz be kell jelentkezni
Attól függ mennyi a huzamosabb idő, de sosem volt olyan, hogy kizárólag egy nyelvet használok. A korai C++ kódjaim nem gányolósak voltak, hanem a kevés lexikális tudásról beszélnek: alig használtam az stl-t, nem volt benne template, virtuális függvények stb. Tehát szépen vezettem bele magam a paradigmákba. Viszont az erőltetett paradigmány nyelveket én baromira korlátozónak és kényelmetlennek érzem (mondjuk van aminél ez nem érződik annyira, de scriptnyelvek annyira nem számítanak itt).
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Minden nyelven lehet fortranul programozni:)
- A hozzászóláshoz be kell jelentkezni
Minden 100000 sornal nagyobb rendszer tartalmaz legalabb egy felig implementalt LISP interpretert. :)
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Ez jó! :)
- A hozzászóláshoz be kell jelentkezni
:)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Kevesebb problemara hatekony, mint amennyire most divatos. (Hosszabb mint zoldebb.)
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
Attól függ mit nevezünk hatékonynak.
Hatékony a megírása, javítása, megértése, futtatása? Melyikre gondoltál?
Szerk.: kimaradt az újrafelhasználása és lehet, hogy van még egy pár :-)
- A hozzászóláshoz be kell jelentkezni
A funkcionális nyelvek hatékonysága leginkább párhuzamosításnál jön ki, ugyanis egy ilyen kódot csont nélkül végre lehet hajtani párhuzamosított feldolgozással. Manapság pedig, ahogy egyre inkább haladunk a (masszívan párhuzamosított végrehajtási rendszerű) GPGPU-k felé, szerintem egyre fontosabbak lesznek a funkcionális nyelvek.
- A hozzászóláshoz be kell jelentkezni
A proceduralis nyelvekben is lehet funkcionalis gondolkodasmoddal programozni. Csak epp joval nagyobb szabadsagod van.
Ergo ez az allitas nepszeru tevhit kategoria.
- A hozzászóláshoz be kell jelentkezni
Nincs nagyobb szabadságod csak más kötöttségeid vannak.
A legjobb nyelvek a multi-paradigmásak, ahol aztán tényleg a programozó döntheti el, hogy milyen stílusban programoz (lásd Scala :-)
- A hozzászóláshoz be kell jelentkezni
Biztos, hogy jó az, ha egy nagyobb projektben többféle paradigma keveredik annak ellenére, hogy ugyanazt a programozási nyelvet használja mindenki?
Szerintem egy programozási projekt az nem demokratikus intézmény, ahol mindenki úgy kódol ahogy neki tetszik. Ezért nem baj, ha egy programnyelvben egy dolgot csak egyféleképpen lehet megcsinálni.
- A hozzászóláshoz be kell jelentkezni
attol fugg. ha OCP -t betartjak, akkor tokmindegy, hogy a modul milyen belul... :)
- A hozzászóláshoz be kell jelentkezni
egeszen addig, amig nem kell belenyulnia valakinek, aki mondjuk nincs otthon az adott paradigmaban :P
ettol fuggetlenul szerintem nem feltetlen rossz az, ha a nyelv olyan szabadsagot ad, amivel konnyen labon tudja loni magat a fejleszto. ez a vonas pedig megtalalhato a php-tol(vagy a Visual Basic-tol) kezdve a c++ -ig eleg sok nyelvben.
Tyrael
- A hozzászóláshoz be kell jelentkezni
"Szerintem egy programozási projekt az nem demokratikus intézmény, ahol mindenki úgy kódol ahogy neki tetszik."
Ezzel egyetértek, de amit levezetsz belőle azzal már nem.
"Ezért nem baj, ha egy programnyelvben egy dolgot csak egyféleképpen lehet megcsinálni."
Tetszőleges programnyelvben egy dolgot nagyon sokféleképp lehet megcsinálni. Akár sok paradigmával, amit esetleg a nyelv nem is támogat. pl. Javaban is lehet funkcionális stílusban programozni, de az nem lesz olyan "szép", mint mondjuk ugyanaz Scalaban.
Ne is legyenek különféle ciklus utasítások (for, while, until, ...), vagy feltételes utasítások (if, switch, ...)! Legyen egy, használja mindenki azt!
Ez pont nem az egyszerűsítés, a jobban érthetőség irányába vezet.
- A hozzászóláshoz be kell jelentkezni
"Javaban is lehet funkcionális stílusban programozni, de az nem lesz olyan "szép", mint mondjuk ugyanaz Scalaban."
Ez úgy hangzik, mintha az lenne a cél, hogy funkcionálisan oldjon meg valamit, de az javaban nem megy olyan könnyen, mint scalaban. Szerintem meg ha javaban kódol, akkor ne is jusson eszébe, hogy tisztán funkcionális alapokon oldjon meg valamit, mert nem ez az elvárt.
"Ne is legyenek különféle ciklus utasítások (for, while, until, ...), vagy feltételes utasítások (if, switch, ...)! Legyen egy, használja mindenki azt!
Ez pont nem az egyszerűsítés, a jobban érthetőség irányába vezet."
Valóban ezek kiválthatók egymással, de valószínűleg azért férnek meg mégis egymás mellett (minden elterjedtebb programozási nyelvben), mert nagyon sokszor használt alapeseteket fednek le. Nekem ezekkel nincs is bajom és nem is kapcsolódnak a vitához. Ezek nem jelképeznek eltérő programozási paradigmákat, mi pedig ebben a szálban a multi-paradigmás nyelvekről társalgunk, amiket te jó dolognak tartasz én meg nem.
Szerintem egy programozónak nem könnyű úgy kiigazodnia egy kódon, hogy annak különböző részei eltérő paradigmák szerint készültek.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg szépen megférnek egymás mellett.
Java nyelven lásd pl.
if (a == null) b = "Alap";
else b = a;
vs
b = (a == null) ? "Alap" : a;
Vagy a nem módosuló osztályok használata: pl. BigDecimal, ...
Szerintem senkinek nem esik nehezére a BigDecimal használata, pedig az FP stílus.
- A hozzászóláshoz be kell jelentkezni
immutable osztalyokat szinte kotelezo irni. ;)
- A hozzászóláshoz be kell jelentkezni
Ja, errol beszelek -- a fel internet arrol enekel, hogy a funkcionalis programokat mennyire jol lehet parhuzamositani. Aztan amikor a konkret feladatot kellene megoldani, akkor mar nem skalazodik annyira jol.
Naiv hozzaallas, hogy a tisztan funkcionalis nyelvek jol parhuzamosithatoak. Egeszen konkretan azert, mert a vegrehajtoegysegek jelenleg tisztan proceduralisak. Erdemes kicsit utanaolvasni, nagyon erdekes tema.
----------------------
while (!sleep) sheep++;
- A hozzászóláshoz be kell jelentkezni
"Egeszen konkretan azert, mert a vegrehajtoegysegek jelenleg tisztan proceduralisak."
Ez csak annyit jelent hogy nehéz funkcionális nyelvekhez jó fordítóprogramot írni. De azért mára már vannak elég jók.
"Aztan amikor a konkret feladatot kellene megoldani, akkor mar nem skalazodik annyira jol."
Lehet hogy igazad van, de esetleg meg sem próbálják rendesen. Kíváncsi vagyok a tapasztalataidra (vagy mások tapasztalataira).
- A hozzászóláshoz be kell jelentkezni
Azért is írtam sokféle hatékonyságot, mert nem csak egy dolog számít.
Nagyon sok program nagyon nagy részében a futási hatékonyság egyáltalán nem számít. (pl. 5ms alatt fut le valami vagy 50ms alatt)
Sokkal inkább számít, hogy mennyi idő elkészíteni, karbantartani, újrafelhasználni, hibát keresni benne, mennyire hibatűrő vagy amit Te is említesz.
A párhuzamosságnál nagyon fontos a konkurrens (van erre valami jó magyar szó?) adatmódosításból eredő hibák kiküszöbölése, amiben szintén nagyon jó a funkcionális programozás.
- A hozzászóláshoz be kell jelentkezni
Kb mint az anyósommal :)
- A hozzászóláshoz be kell jelentkezni
ismered, de nem tetszik? :)
- A hozzászóláshoz be kell jelentkezni
:DD
- A hozzászóláshoz be kell jelentkezni
Csak lazan kapcsolodik (egy regi TDWTF posztnal volt komment):
Only a Deranged Fool would use VB.Net for a task this important. Clearly the only Sane Choice is ... no, I'm not going to calm down. Get your hands off me! I don't care how many side effects that filthy solution has; I'm not going to use a functional alternative.
Dysfunctional languages, that's the way to go.
http://thedailywtf.com/Comments/Spaced-Out.aspx
--
Take my advice; I don't use it anyway.
- A hozzászóláshoz be kell jelentkezni
A "Tetszik, és használom is (munka, hobbi stb..)." opciót választottam, de ez így nem igaz. Ami igaz:
"Tetszik, és most tanulom (hobbi)."
-----
"Én vagyok a hülye, hogy leállok magával vitatkozni."
- A hozzászóláshoz be kell jelentkezni
Olyasmi, mint a kínai. Tetszik és használnám is, de valahogy annyira idegen az ilyen nyelvek logikája számomra, hogy nehézséget okoz, hogy alkalmazkodjak hozzá egy gyakorlati probéma megoldása során. Tanulgatom a Scala nyelvet, de a végén valahogy mindig az objektumorientált logikánál kötök ki, amikor megpróbálok megvalósítani valamit benne.
- A hozzászóláshoz be kell jelentkezni
Kedves emberek,
Az ugye megvan, hogy a javascript egy funkcionalis - nem multiparadigmalis meg mittom - nyelv?
Konkretan regularis kifejezesekkel tetszoleges javascript program atirhato LISPpe. (Belulrol ugyanis egy scheme interpreter, kicserelve a grammatika BNF fajlja)
A jQuery - barmennyire ruhelljem is - pl. funkcionalis, paradigma szerint is.
- A hozzászóláshoz be kell jelentkezni
Alighanem ezért végzett ott a HOVD szavazáson, ahol.
- A hozzászóláshoz be kell jelentkezni
Mert nem ertik, igen :)
Csak ismerve a webfeluletek elterjedtseget, viccesnek tunik a "nemlattammegolyat" aranya...
- A hozzászóláshoz be kell jelentkezni
Talán a "nem ismerem őket" alatt nem azt értik, hogy "nemlattammegolyat". Vagy úgy gondolják, hogy van benne elég OO meg egyéb származék, hogy ne tekintsék csak funkcionális nyelvnek.
- A hozzászóláshoz be kell jelentkezni
Meglepodnenek, ha latnak hogy a self-bol kolcsonzott prototipusos orokles mennyire nem ugy nez ki belulrol, ahogy a nep tobbsege hiszi :)
(Nem ismeri az osztaly fogalmat a javascript, ugye.)
- A hozzászóláshoz be kell jelentkezni
Konkretan mi a baj a jQuery-vel? Napi munkam soran hasznalom, es nem vettem eszre, hogy olyan rossz lenne, sot.
- A hozzászóláshoz be kell jelentkezni
Az elgondolasa nem skalazodik.
Tok jo, ha van 3 gombod amire click event kell, de ha hirtelen komplex widgeteket akarnal osszerakni, amik egymasba vannak agyazva, vagy mediator kene neked tobb widget kozt, akkor rajossz, hogy azok a klasszikus patternek, amiket a jQuery kidobott, megiscsak jok valamire.
Ha maskor nem, akkor, amikor fel ev mulva el kene olvasni a kodot.
Persze be lehet rendezni egy kodot ugy, hogy valahol nagyon alul jQuery-t hasznaljon, es megis legyen valami ranezesre is eszlelheto architekturaja, csak a tobbiek ebben meg jobbak.
Pici dolgokra meg a jQuery jobb nyilvan. Csak nem szoktak eszrevenn, amikor atlepik ezt a hatart, ill. a legritkabb esetben allnak at valamire, vagy rendezik a kodot valami konzekvens es szabvanyos strukturaba, hanem folytatjak tovabb a projektet, aztan ez megy 1-2 evig, utana meg bogozd ki.
- A hozzászóláshoz be kell jelentkezni
tenyleg, en ezt nem tudtam konkretan rola, de amikor nem a javascript tutorial szeru megkozelitest lattam, hanem lattam mas, nem annyira ovodas modon leirt javascript kodot, vmi nagyon ismeros volt...
- A hozzászóláshoz be kell jelentkezni
miert kellett megkavarni a dolgokat azzal h javascript-nek nevezzuk?
miert nem lehet ecmascript?
- A hozzászóláshoz be kell jelentkezni
ha komolyan kerdezed, akkor valoszinuleg azert, mert elobb volt a javascript nyelv mint implementacio, amit eloszor lekoppintott/kiterjesztett a Microsoft JScript neven, majd a Netscape megkerte az ECMA-t, hogy standardizalja, valamint keszitsen belole specit, ez lett az ECMA-262.
tehat tekinthetunk rajuk ugy, mint specire(ecma) illetve implementaciora(javascript, actionscript).
http://en.wikipedia.org/wiki/Ecmascript
sajna ott van meg a problema, hogy meg a kulonbozo js engine-ek sem ugyanolyan modon/mertekben tamogatjak a specit, csak hogy tovabb fregmentalodjon a piac.
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(ECMAScript)
Tyrael
- A hozzászóláshoz be kell jelentkezni
Tetszik és használom is -- hobbiból, mert még messze van az amikor programozói munkát fogok végezni... :)
Tengernyi indokot lehetne felhozni mellette, de az internetes viták jellemzően nem az érvekről szólnak, szóval menjen inkább a flame:
“When the limestone of imperative programming is worn away, the granite of functional programming will be observed.”—Simon Peyton Jones
;)
-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO
- A hozzászóláshoz be kell jelentkezni
És ha már PL topic van a hupon:
http://www.americanscientist.org/issues/id.3489,y.0,no.,content.true,pa…
-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO
- A hozzászóláshoz be kell jelentkezni
Ez tetszik! :-)
"Little-Endians of Lilliput and the Big-Endians of Blefuscu"
Szerk.: ez is:
"Consider the Java expression Date(2006,1,1); what calendar date do you suppose that specifies?The answer is February 1, 3906. In Java we count months starting with 0, days starting with 1, and years starting with 1,900."
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Idézet a cikkből hogy ne kelljen kattintani:
"Ahogy a szoftver egyre bonyolultabbá válik, egyre fontosabb hogy jól strukturált legyen. Jól strukturált szoftvert könnyű írni és debugolni, és a kapott modulgyűjtemény újrafelhasználásával csökkenthetők a programozási költségek. A cikkben bemutatjuk hogy két funkcionális programozásbeli eszköz, a magasabbrendű függvények és a lusta kiértékelés hogyan járul hozzá lényegesen a modularitáshoz."
- A hozzászóláshoz be kell jelentkezni
Ismerem, tanulom, és belátom, hogy bizonyos esetekben hasznos, de egyszerűen nem szeretem. Feladata válogatja a megoldáshoz használt eszközt.
- A hozzászóláshoz be kell jelentkezni
Ezzel az allatkaval az imapfilter hasznalata soran talalkoztam, mely a lua nyelvet hasznalja filternyelvkent. Nem mondom, hogy egyszeru, de legalabb bonyolult. Tetszik, de magamtol ilyen nyelvben nem irnek semmit.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal
- A hozzászóláshoz be kell jelentkezni
egyeb: tetszik az elgondolas, hasznaltam de mar nem hasznalom.
- A hozzászóláshoz be kell jelentkezni
Szerintem az FP tokre hasznalhato a gyakorlatban is. En 3D engine-t es hozza pelda jatekot fejlesztek Haskellben.
Nemreg pl 3 nap alatt sikerult osszedobnom par szaz sorbol egy Quake3 palyamegjelenitot.
Meg sztem a legnagyobb elonye hogy, a szigoru tipusrendszernek koszonhetoen majdnem bugmentes progit lehet benne gyorsan osszehozni.
Akit erdekel az csekkolja le a forrast:
http://code.google.com/p/lambdacube/source/browse/#svn%2Ftrunk%2Fbsploa…
http://code.google.com/p/lambdacube/source/browse/#svn%2Ftrunk%2Flambda…
http://code.google.com/p/lambdacube/source/browse/#svn%2Ftrunk%2Flambda…
- A hozzászóláshoz be kell jelentkezni
Jópofa, elég tömörnek tűnik. Egyetemen tanultam prolog/sml-t, de valahogy sosem fogott meg. Java-ban használtam a a lambdaj-t, az egészen hasznos néhány esetben, de nem szükségszerű.
Mennyire lehet használni az oop gondolkodásmódot, tervezési mintákat, mennyire lehet nagy programokat készíteni mondjuk haskell-ben?
- A hozzászóláshoz be kell jelentkezni
Teljesen jol lehet nagy projekteket fejleszteni haskellben. Nagyon nagy segitseg a type inferences es type checking, na meg a type classok.
Az oop gondolkodasmod viszont felejtos, mashogy kell tervezni a programot FP-ben, sokkal abstraktabban es altalanosabban lehet kodolni. Sokkal kevesebb lesz a boiler plate kod.
- A hozzászóláshoz be kell jelentkezni
Na ez az, konkrétan ezek a dolgok érdekelnének. Mert most java-ban programozunk, és megvannak a nagyon szépen/jól bevált design pattern-jeink, a tervezéstől, a kódoláson át a tesztelésig. Esetleg olyat tudnék elképzelni, hogy a kód egy része funckionális lenne, viszont oo alapokra építve, viszont ez lehet, hogy öntökönlövés kategória. Az, hogy mennyi a boilerplate az erőteljesen függ attól, hogy mit hoznak nyelvi szintre/milyen könyvtárak vannak. Ami nekünk fontosabb, hogy jól tervezhetően, tesztelhetően, integrálhatóan tudjunk kódokat írni... (baromira nem érdekel, hogy {}-t vagy ;-t kell írni, a fent említettek sokkal fontosabbak...)
Létezik valamilyen leírás a neten erről?
- A hozzászóláshoz be kell jelentkezni
Bocs, nem teljesen a kérdésedre fogok válaszolni de hátha érdekes.
A funkcionális nyelveknek nagyon erős matematikai alapjai vannak. Ezeknek a nyelveknek elméleti modellje a lambda kalkulus amit az 1930-as években fejlesztettek ki matematikusok. Ezzel elmondható hogy mi az hogy számítás és egy nagyságrenddel egyszerűbb mint a Turing-gép.
A matematika tulajdonképpen a dolgok formális leírásának a nyelve. Kérdés, hogy megeszi-e a számítógép. A funkcionális programozók hisznek ebben és ezt az álmot igyekszenek megvalósítani egyfajtaképpen.
OO programozással is leírhatod a dolgokat tömören, érezni fogod hogy mit jelent, de sosem fogod tudni pontosan mit jelent amit írtál.
(Ez persze egy végletesen leegyszerűsített szubjektív megfogalmazás. :)
- A hozzászóláshoz be kell jelentkezni
Számomra az OO programozás azt jelenti, hogy egy struktúrát építek fel bizonyos szabályok szerint,
amibe bele tudom kapcsolni az új feladatokat elvégző elemeket, tervezhető módon. Valójában eljut az ember arra a szintre, amikor a nyelv csak egy eszköz, és igazából struktúra szinten gondolkozik, nyelvi szinten csak megvalósítja azt. Erre vannak "épitési segédletek": design pattern-ek, illetve best practice-ok.
Részemről a funkcionális nyelven programozás azt jelenti, hogy a nyelvet változtatom, a kérdés az, hogy egy gondolkodásmódjában alapvetően eltérő programozási nyelvnél ezeket a mintákat/sablonokat mennyire tudom jól/egyáltalán felhasználni...
- A hozzászóláshoz be kell jelentkezni
Minél inkább tervezés a programozás és nem próbálgatás, annál kevésbé számít a nyelv, tényleg csak egy eszköz.
De ha egy nagy, komplex rendszert kell alkotni, akkor esetleg érdemes egy nyelvet alkotni előbb hozzá, de ha nem akkor meg megéri körülnézni a meglevő nyelvek között. Szóval mégiscsak számít a nyelv.
Az OO mintákat nem lehet közvetlenül átvinni tisztán funkcionális nyelvekbe, ez jó is így.
A funkcionális programozás szerintem a magasabbrendű függvények (például függvénykompozíció) használatánál kezdődik. Másik jellegzetessége az állapotnélküliség. Például a típusosztályokban nincs és nem is lehet adattag.
- A hozzászóláshoz be kell jelentkezni
Ezért kérdeztem, hiszen OO-ra nagyon jó módszereink vannak, amik jól működnek, tervezhető (időben, költségben, struktúrában), míg ezt én nem látom a funkcionális nyelveknél. Ami nem jelenti azt, hogy nincs, inkább azt, hogy nem köztudott, ismert...
- A hozzászóláshoz be kell jelentkezni
Én úgy látom hogy ezek a módszerek még messze nincsenek kidolgozva funkcionális nyelveknél. Több fontos részterületen most alakulnak ki a bevett módszerek. Például ilyen az interaktív programok írásában az FRP (Functional Reactive Programming), hcube ilyen kódot linkelt be.
Az oktatásban érdekes kísérletezés folyik. Jó hogy van egyáltalán lehetőség az oktatásra a mainstream nyelvek mellett, de kellene kb. egy három féléves tárgy a megtanulásukhoz. Szerintem technológiai fölényben vannak a funkcionális nyelvek, de egyelőre absztraktabb gondolkodás is kell hozzájuk pont azért mert nincsenek jól bejáratott módszerek.
- A hozzászóláshoz be kell jelentkezni
Egy tisztán egy szemléletű nyelv sosem lehet "technológiai fölényben", az mindig megmarad egyetemi illetve egyéb, nagyon speciális célra. Viszont az eredménye megvan a kutatásnak, még ha soha nem is jön el a "funkcionális nyelvek éve/egyeduralma": a legtöbb nyelv felvett már egy rakás funkcionális jellemzőt, és ez csak folytatódik. Nem kell aggódni, az ipar kitermeli magának a nyelveit, és mivel a visszafele kompatibilitás jó, ezért a régi nyelvek alakulnak át.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
A kevesebb néha több.
Most a két legnépszerűbb nyelv, a C és a Java nem multiparadigmás (http://langpop.com/). A C++ multiparadigmás de úgy tudom kritizálják is miatta.
Technológiai oldalról nézve, a paradigmák hátrányai egyesülnek multiparadigmás nyelvben.
A Haskell például egy tisztán funkcionális nyelv. Ha beletennék az OO paradigmát, akkor az altípusosság miatt elveszne több nagyon erős tulajdonsága, például a determinisztikus típuskikövetkeztetés.
- A hozzászóláshoz be kell jelentkezni
Az oldal amit linkeltél számtalan győztest hoz ki nagyon sok kategóriában, de én egy szóval sem mondtam, hogy CSAK multiparadigmás nyelv lehet sikeres. Sőt, sokmindenre nem alkalmas. A C++-t meg sokmindenért kritizálják, van, amiért jogosan, van, amiért nem. Aki azért kritizálja, amiről beszélünk, az nem érti a lényegét. A C++ egy erős eszköz, erős nyelv, és mint erős nyelv, nehezebben fejezed magad ki rajta. Több lehetőség -> komplexebb nyelv.
Amiről te beszélsz technológiai oldal az az elméleti megközelítés, amit a gyakorlat sokszor cáfol.
Te a Haskellel jössz, ami alapvetően rossz példa, mert egy tisztán X nyelv nyílván veszít az erejévől, ha kevered. De a trendek affelé mutatnak, hogy az imperatív nyelvek felvesznek funkcionális jellemzőket, a funkcionális nyelvek közül meg az lesz sikeres, amelyik nem tisztán az. A "tisztaság" az egyetemre való, kutatáshoz. Az iparnak hatékony eszközök kellenek.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Nem látom hogy a tisztaság miért zárja ki a hatékonyságot.
- A hozzászóláshoz be kell jelentkezni
Mert a követelmények a legritkább esetben tiszták. Nagyon ritkán van szükség egy, és csak egy képességre.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Tisztaság alatt azt érted, hogy _egy_paradigmás_ ?
- A hozzászóláshoz be kell jelentkezni
Arról már rég elhaladtunk.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Annyira mégsem http://hup.hu/szavazasok/20110113/kerdes_programozas_funkcionalis_parad… itt is erre használod a "tiszta" jelzőt, pedig ez mást jelent.
Tiszta akkor lesz egy nyelv, ha garantálható egy számítás mellékhatásmentessége.
- A hozzászóláshoz be kell jelentkezni
maradjunk annyiban, hogy abban a tudományágban, amit te a magadénak tekintesz, ezt hívják tisztának.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Több mindent jelent.. Jogos.
- A hozzászóláshoz be kell jelentkezni
A mérések szerint a Haskell pl. hatékony kódot készít.
Ha a programozási eszközökre gondolsz, akkor azok valóban hiányoznak, de ez nem a technológia hibája.
A programozási paradigma meg attól paradigma hogy minden lényeges kérdésre tud választ, nem csak egyre.
Véleményem szerint azzal hogy azt mondod hogy a funkcionális programozás nem minden környezetben megfelelő, kb. azt mondod hogy matematikai eszközökkel nem lehet mindent formalizálni. De ez egy erősen szubjektív vélemény.
- A hozzászóláshoz be kell jelentkezni
mar csak azt nem ertem, hogyha annyira megfeleloek mindenre az fp. nyelvek, akkor csak alig-alig futottak be ennyi ido alatt...
- A hozzászóláshoz be kell jelentkezni
Nehéz hozzájuk jó fordítóprogramot írni, nincsenek kidolgozva a módszerek, nincsenek implementálva az eszközök.
- A hozzászóláshoz be kell jelentkezni
20 eves a Haskell. keves volt ennyi ido?
en inkabb az ipari erdeklodes hianyat velem felfedezni e mogott.
- A hozzászóláshoz be kell jelentkezni
Igen, kb. 20 év kellett hogy iparilag használható fordítóprogramot írjanak a nyelvhez. Ha nincs fordító, nincs ipari érdeklődés érthető módon.
- A hozzászóláshoz be kell jelentkezni
Háát...
- Az általános célú script nyelvekhez is mostanában jelennek meg használhatóbb eszközök (refactoring, statikus ellenőrzések, code completion stb... )
- Nagyságrendekkel lassabbak még ma is mint a fordított nyelvek
És mégis a 90-es években már úgy terjedtek mint a gomba, szóval én mégis inkább magában az FP paradigmában látom a terjedés lassúságát: szinte teljesen más hozzáállást, tudást stb.. igényel:
pl. tonnányi számítás és algoritmuselméleti felfedést kell kidobnod vagy újra gondolni ha nem "konstans időben módosítható állapotokban" gondolkozol
- A hozzászóláshoz be kell jelentkezni
Igen, igaz de ez a 2. pont :)
Ha ki lennének dolgozva a programozási módszerek, meg hogy hogyan oktassuk, akkor nincs itt gond.
Sőt, a matematikai eszköztárban felhalmozódott több száz éves tapasztalatot a funkcionális nyelvek tudják leginkább kihasználni.
- A hozzászóláshoz be kell jelentkezni
Egyik sem talált. Arról beszélek, hogy a valós életbeli problémák olyanok, hogy egy tiszta nyelv nem tud minden részére hatékony választ adni. Minden paradigma jó valamire, de ha szerinted mindegyik ugyanannyira jó mindenre, akkor minek találtak volna ki többet?
A "nem megfelelő" nem azt jelenti, hogy "alkalmatlan". Tudod, mint sajtreszelővel maszturbálni.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Kb. jól látod hogy miért nehéz a paradigmaváltás.
- A hozzászóláshoz be kell jelentkezni
Na igen, erre jók a funkcionális nyelvek. Hülyéskedni. Carmacknak a Q3:A-nál meg kellett oldani, hogy egy 166-os Pentium szoftveresen ki tudjon rendereleni egy 10-20k poligonból álló pályát, legalább 8 playerrel.
Erre csak a C meg assembly volt jó.
De ha egy jó kernelt akarsz írni, arra is C kell. A funkcionális nyelvek tudományos munkára meg szórakozásra jók. Ha mission critical dolgot kell csinálni akkor gépközeli nyelvet kell használni, akár bytecodeot.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
azért ezt ennek a cégnek is elmondhatnád:
http://corp.galois.com/
úgy látszik ők nem tudnak erről.
nem is csoda, hogy ilyen szar csóró megrendelőik vannak:
http://corp.galois.com/clients/
- A hozzászóláshoz be kell jelentkezni
Nyilván egy kicsit eltúlzóan írtam. Nekem is használnom kellett ilyen nyelveket munkáim során, de én nem vagyok róluk túl nagy véleménnyel. (a második opciót választottam.)
Amíg gcc-hez lehet interpretert írni a nyelvhez addig jók nálam. :)
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
Nyugtass meg, hogy nem vagy programozo :(
- A hozzászóláshoz be kell jelentkezni
?
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
A mission critical nem mindenkinek azt jelenti, hogy hajtsuk ki a szart is a PC hardware-ből.
Sőt leggyakrabban nem ilyen környezetben használják a kifejezést. Én személy szerint az otthoni 3D-s játék szaggatásánál kisebb informatikai kockázatot szinte elképzelni sem tudok. ;)
Ilyenek szoktak inkább lenni:
hogy fusson évekig leállás nélkül vagy
hogy a teljesítmény lineárisan skálázódjon 1000+ nodeig
hogy (akár matematikai) garanciák legyenek arra hogy bizonyos események meghatározott időpontban bekövetkeznek (vagy hogy épp nem)
hogy tökéletesen megvalósítson valamilyen formális specifikációt
stb...
- A hozzászóláshoz be kell jelentkezni
Közben rájöttem, hogy buzzword amire gondolni akartál inkább a: bleeding edge
- A hozzászóláshoz be kell jelentkezni
Sztem lessel ra erre a slidesorra amit az epic games egyik alapitoja es fo fejlesztoje keszitett:
http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language…
Ebben elmagyarra hogy miert van/lesz helye az FP-nek az iparban.
- A hozzászóláshoz be kell jelentkezni
Carmacknak a Q3:A-nál meg kellett oldani, hogy egy 166-os Pentium szoftveresen ki tudjon rendereleni egy 10-20k poligonból álló pályát, legalább 8 playerrel.
ROTFL, te miről beszélsz, jó ég...
- A hozzászóláshoz be kell jelentkezni
definiáljuk a mission critical-t :D
- A hozzászóláshoz be kell jelentkezni
Annyi a kapcsolatom vele, hogy egyik szigorlati tetel. Amugy nekem nyakatekert a gondolkodasa.
- A hozzászóláshoz be kell jelentkezni
Forog velem a világ, és mégsem SML. :)
- A hozzászóláshoz be kell jelentkezni
nem forog hanem prolog :)
- A hozzászóláshoz be kell jelentkezni
- Hany Prolog programozo kell, hogy becsavarjon egy villanykortet?
- Igen.
- A hozzászóláshoz be kell jelentkezni
Ouch! XD
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
- A hozzászóláshoz be kell jelentkezni
:)
- A hozzászóláshoz be kell jelentkezni
Ismerem személyesen azt, aki Kossuth díjat kapott érte:)
- A hozzászóláshoz be kell jelentkezni
Pötty
- A hozzászóláshoz be kell jelentkezni
Egy ocaml cucchoz kuldtem patch-eket, erdekes volt, de nem estem bele.
- A hozzászóláshoz be kell jelentkezni
alapvetően tetszik, de viszonylag ritkán használom, ha mégis akkor leginkább a strategy pattern "egyszerűsítésére" (funkcióobjektum helyett lambda).
- A hozzászóláshoz be kell jelentkezni
Nálunk most volt ada mint kötelező tantárgy.
Hát mit ne mondjak, nekem nagyon nem jött be.
Részben azért, mert ugy néz ki mint a pascal, másrészt nagyon kötöt
(nagyon sok mindent megtilt, gondolom igy probálták megakadályozni,
hogy az óvatlan programozó ne csinálhasson hülyeséget)
Mutatok vannak, de elvannak "fedve".
És általában rövidebben meglehet irni a feladatot, mint cppben,
de cppben pedig a hosszab kódot is gyorsabban meglehet irni mint adában a rövidebbet :P
- A hozzászóláshoz be kell jelentkezni
az Adanak a legnagyobb elonye, hogy iszonyatosan tipusbiztos, ergo lehet formalisan is bizonyitani. vannak olyan szintek, ahova ez kell, pl az NSA ~1/masfel eve publikalt valamilyen belepteto rendszert, amit egy ada variansban irtak.
ja, meg hogy tamogatja out of the box a concurrencyt.
- A hozzászóláshoz be kell jelentkezni
Meglehet, hogy itt sokakat nem érdekel, de meg lehet írni egy hozzászólást kevesebb helyesírási hibával is. http://magyarispell.sourceforge.net
- A hozzászóláshoz be kell jelentkezni