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

 ( kelemzol | 2011. január 13., csütörtök - 14:20 )
Nem ismerem őket.
46% (338 szavazat)
Ismerem, de nem tetszik.
11% (78 szavazat)
Tetszik az elgondolás, de nem használom.
18% (133 szavazat)
Tetszik, és használom is (munka, hobbi stb..).
9% (69 szavazat)
Csak az eredmény érdekel
16% (116 szavazat)
Összes szavazat: 734

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

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

+1

---
http://xkcd.com/258/

Apple MacBook Pro 13"
C2D 2.26GHz/3MB | 4GB@1067MHz | 160GB@5400rpm SATAII

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

ja, ugy 20 eve. :)

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.

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

tudtommal az erlang is funkcionális és nehéz rá azt mondani, hogy nem használja az ipar :)

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

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

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

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!

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.

utalom a monty pythont.

Z, a javat imadod, most netbsdzel es meg montipajtont sem szereted.

Nyugtass meg kerlek, hogy nem az iparban dolgozol ;-)

de ;-)

+1
Nekem is ez jutott eszembe a hozzászólásról :-)

lolka

nem ez volt a kerdes.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

igy jartal.

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)

nem zavar, kivancsi voltam, hogy hazon kivul mennyire eletkepes. az erlang & otp in action most jelent meg a manningnel, csak azert :)

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.

+1

multkor a Java kodomra ra se lehetett ismerni :-)

(anonymous methodok mint ctorparameter az enum-ertekeknek :))

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/

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 match(List cards);
}

enum Value {
    HCARD(new P() {
        ...
    }),
    PAIR(new P() {
        ...
    }),
    ...
    private final P predicate;

    private Value(P predicate) {
        this.predicate = predicate;
    }

    public List match(List cards) {
        return predicate.match(cards);
    }
}

hasznalni meg egyszeru, mint a faeket: Value.HCARD.match(akarmi)

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

C++/C#/eiffel, kis erlang mostanaban, kis haskell megvolt. tovabbra sem erzem magam kenyelmetlenul:)

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

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

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.

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.

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.

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

Jajj, ilyet ne írj már, mert kezdődik a flamewar :)

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

Juuuuj!
A Java jó a c++ nem?
Ez a legellenszenvesebb hozzászólás, amit a huppon olvastam eddig :)

fejtsd ki, mi az, ami szerinted c++ban olyan tok jo, javaban meg nincs.

Sebesség?

Azért érdekes, hogy a Netbeans és az Eclipse felülete miylen lassú, és hopp - minkető Javas.

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.

melyik C++-ban irt hasonlo tudasu IDE-vel osszehasonlitva erzed lassunak?

Tyrael

Hát nem tudom, hogy melyik IDE-t melyik nyelveken irták, de
xcode, vs(, qtcreator); ezek pl. mind jol müködtek.

Nezz meg egy normalisan megirt Java IDE-t (JetBrains altal fejlesztett cuccok).

ja, sajna a netbeans egy rakat talicska ilyen szempontbol.

btw. PHPStorm-ot nezted mar?
szimpatikus, gondolkozom rajta, hogy megveszem.

Tyrael

Azzal dolgozok kb egy honapja, mindjart jon a 2-es verzio :)

jaja, lattam, betakat szedem szorgalmasan.

Tyrael

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.

Szabadság :)
----
Hülye pelikán

pelda?

É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

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

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

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 convention alapu dolgok sokszor jol mukodnek. :)

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

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

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.

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$%#$#%^*^"

ezt most a .sig-be vagy a híres utolsó mondatok.txt-be tegyen?:)))

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$%#$#%^*^"

igen, igazad van, amire felhivtad a figyelmem, elegansabb lett volna. koszi!

Pedig remenykedtem, hoogy tanulok valami ujat... ;^(

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

+1
A funkcionális paradigmának teljesen megfelel, ahogy használod. Java használata esetén nem is tehetsz mást :-)

Multiparadigmas nyelvek FTW!

+1

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

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

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?

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

Minden nyelven lehet fortranul programozni:)

Minden 100000 sornal nagyobb rendszer tartalmaz legalabb egy felig implementalt LISP interpretert. :)

----------------------
while (!sleep) sheep++;

Ez jó! :)

:)

+1

Kevesebb problemara hatekony, mint amennyire most divatos. (Hosszabb mint zoldebb.)

----------------------
while (!sleep) sheep++;

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 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 proceduralis nyelvekben is lehet funkcionalis gondolkodasmoddal programozni. Csak epp joval nagyobb szabadsagod van.
Ergo ez az allitas nepszeru tevhit kategoria.

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

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.

attol fugg. ha OCP -t betartjak, akkor tokmindegy, hogy a modul milyen belul... :)

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

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

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

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.

immutable osztalyokat szinte kotelezo irni. ;)

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++;

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

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.

Kb mint az anyósommal :)

ismered, de nem tetszik? :)

:DD

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

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.

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.

Alighanem ezért végzett ott a HOVD szavazáson, ahol.

Mert nem ertik, igen :)

Csak ismerve a webfeluletek elterjedtseget, viccesnek tunik a "nemlattammegolyat" aranya...

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.

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

Konkretan mi a baj a jQuery-vel? Napi munkam soran hasznalom, es nem vettem eszre, hogy olyan rossz lenne, sot.

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.

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

miert kellett megkavarni a dolgokat azzal h javascript-nek nevezzuk?
miert nem lehet ecmascript?

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

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

És ha már PL topic van a hupon:
http://www.americanscientist.org/issues/id.3489,y.0,no.,content.true,page.1,css.print/issue.aspx

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

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

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

Ismerem, tanulom, és belátom, hogy bizonyos esetekben hasznos, de egyszerűen nem szeretem. Feladata válogatja a megoldáshoz használt eszközt.

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

egyeb: tetszik az elgondolas, hasznaltam de mar nem hasznalom.

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%2Fbsploader
http://code.google.com/p/lambdacube/source/browse/#svn%2Ftrunk%2Flambdacube-engine
http://code.google.com/p/lambdacube/source/browse/#svn%2Ftrunk%2Flambdacube-examples

http://www.haskell.org/haskellwiki/LambdaCubeEngine

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?

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.

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?

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

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

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.

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

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

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

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

Nem látom hogy a tisztaság miért zárja ki a hatékonyságot.

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

Tisztaság alatt azt érted, hogy _egy_paradigmás_ ?

Arról már rég elhaladtunk.
----
Hülye pelikán

Annyira mégsem http://hup.hu/szavazasok/20110113/kerdes_programozas_funkcionalis_paradigmak#comment-1205762 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.

maradjunk annyiban, hogy abban a tudományágban, amit te a magadénak tekintesz, ezt hívják tisztának.
----
Hülye pelikán

Több mindent jelent.. Jogos.

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.

mar csak azt nem ertem, hogyha annyira megfeleloek mindenre az fp. nyelvek, akkor csak alig-alig futottak be ennyi ido alatt...

Nehéz hozzájuk jó fordítóprogramot írni, nincsenek kidolgozva a módszerek, nincsenek implementálva az eszközök.

20 eves a Haskell. keves volt ennyi ido?

en inkabb az ipari erdeklodes hianyat velem felfedezni e mogott.

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.

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

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.

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

Kb. jól látod hogy miért nehéz a paradigmaváltás.

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.

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/

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.

Nyugtass meg, hogy nem vagy programozo :(

?

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

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

Közben rájöttem, hogy buzzword amire gondolni akartál inkább a: bleeding edge

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-A-Game-Developers-Perspective-by-Tim-Sweeney

Ebben elmagyarra hogy miert van/lesz helye az FP-nek az iparban.

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

definiáljuk a mission critical-t :D

Annyi a kapcsolatom vele, hogy egyik szigorlati tetel. Amugy nekem nyakatekert a gondolkodasa.

--
http://www.micros~1

Forog velem a világ, és mégsem SML. :)

nem forog hanem prolog :)

- Hany Prolog programozo kell, hogy becsavarjon egy villanykortet?
- Igen.

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

:)

Ismerem személyesen azt, aki Kossuth díjat kapott érte:)

Pötty

Egy ocaml cucchoz kuldtem patch-eket, erdekes volt, de nem estem bele.

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

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

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.

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