Programozási nyelvek összehasonlításánál az erősen típusosságot vagy a gyengén típusosságot tartod előnynek?

 ( carlcolt | 2013. május 7., kedd - 7:48 )
az erősen típusosságot
43% (189 szavazat)
a gyengén típusosságot
8% (35 szavazat)
mindkettőnek kb. hasonló mennyiségben tudnám felsorolni az előnyeit és a hátrányait
30% (130 szavazat)
nem értem miről van szó
19% (85 szavazat)
Összes szavazat: 439

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

Mindkettőnek van értelme, különböző helyeken. Egy folyamat automatizálására nem fogok egy erősen típusos nyelvben bonyolult dolgokat írni, ha arra bőven megfelelő a bash is. Szerintem nem az a legfőbb szempont, hogy az adott nyelv mennyire típusos. Vannak fontosabb szempontok szerintem...

Ez kb. olyan, mintha a villat meg a kanalat kene osszehasonlitani :D. Ha csak egy scriptet irsz, akkor minek a eros tipusossag... ha viszont hardware-t tervezel ott az "nagyon nem artalmas dolog". Right tool for the right purpose, vagy mi.

------------------------------------------
Lenovo Thinkpad T430 :: Ubuntu 12.10
Lenovo Thinkpad T61 :: FreeBSD 9.0
Lusta vagyok én már a csempézéshez...

+1

Nálam a sorrend:
1. Erősen típusos nyelv, ami hozza a gyengén típusos nyelvek előnyeit is.
2. Erősen típusos nyelv.
3. Gyengén típusos nyelv.

+1

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

a feladathoz valasztom meg a nyelvet, nem igazan hasonlitgatom a tipussaguk alapjan oket.

Diktatorok kezikonyve

Elég nagy hiba.
Én mindig elő szoktam venni a "Programozási nyelvek típusossági határozóját" (egyetemi jegyzet), és kizárólag 5-ös érték fölötti nyelvet választok komolyabb munkához.

olvasd el megegyszer, amit irtam, kulonos hangsullyal a "feladathoz a nyelvet" reszt...

Diktatorok kezikonyve

ez most poen vagy komolyan irtad?

--
NetBSD - Simplicity is prerequisite for reliability

Nem tudom, de ezt a könyvet linkelhetné valaki, ha nem esik ezt korlátozó szerzői jog alá, mert érdekelnek a 6+ osztályok :D
----
India delenda est.
Hülye pelikán

Szerintem poén. Túlságosan betegesen hangzott ahhoz, hogy komoly legyen...

Komoly munkára csak erősen típusos nyelvet, scriptelésre meg ott a Python, ami szintén az. A gyengén típusosságra egyszerűen nincs szükség, bár kis méretekben nem jön elő a hátránya, viszont ezek a kis projektek néha elburjánzanak, és akkor jön az anyázás.
----
India delenda est.
Hülye pelikán

+1
Nem is értem miért kultiválja bárki is a gyenge típusosságot:

A statikus vs. dinamikus típusellenőrzés vonal sokkal alkalmasabb lenne a flame-re, ott legalább vannak jó pro-kontra érvek... ;)

szerk: és valaki aki arra szavazott mondja meg, hogy számára mi az előnye ha se fordítási se futásidejű hibát nem okoz a 10+"12" (és hogy mi szerinte "helyes" megoldás, ha ő tervezné a kedvenc gyengén típusos nyelvét: "1012" vagy 22 vagy hol ez hol az - ez csak kíváncsiság;)

"...és hogy mi szerinte "helyes" megoldás..."

A helyes válasz az "attól függ" :)

10+"12" = 22
"10"+12 = 1012

(Erősen típusosságot jelöltem).

++
--
unix -- több, mint kód. filozófia.
Life is feudal

+1

Én úgy csinálnám ahogy az Assembly, úgy optimális is. Első vagy utolsó számjegyhez tartozó char-hoz hozzáadom az intet. :D Na jó, egy warningot azért dobatnék vele, hogy ilyet nem illik és biztos ezt akarta-e. :D :D

Viccet félretéve: nem véletlen NEM a + jel szokott a konkatenálás műveleti jele lenni gyengén típusos nyelvekben (pl. PHP-nál a . teljesen megoldHATNÁ ezt a kérdést).

És szerintem a válasz 22, mert a "+" csak számokra értelmezhető, ami nem szám, azt konvertáljuk (osztásnál a számlálót _alapesetben_ double-lé, amit még a Java-nak sem sikerült double eredmény várása esetén, pedig ő erősen típusos). A 10 + "foobar" viszont dobjon kivételt, sőt, a 10 + "3róka" is.

"(osztásnál a számlálót _alapesetben_ double-lé, amit még a Java-nak sem sikerült double eredmény várása esetén, pedig ő erősen típusos)"

A művelet végrehajtásakor nem veheti figyelembe, hogy milyen típusra kell végül castolni, ezért mi mást is adhatna vissza, mint intet. Vagy akkor ha azt írom le, hogy int a=10/3;, dobjon hibát, hogy nem tudja a lebegőpontos számot implicit castolni intre?

"amit még a Java-nak sem sikerült double eredmény várása esetén"

Most azt akarod, hogy környezetfüggő legyen a nyelvtan (még annál is jobban, mint amennyire feltétlenül szükséges)? Biztos ezt akarod? A Perl az ilyen nyelv, és nézd meg, milyen.
----
India delenda est.
Hülye pelikán

Utánanéztem, igazatok van, valóban egyszerűbb azt várnia a nyelvnek, hogy kézzel kelljen double-lé alakítani a számlálót. Egyéb esetben magát a műveletet vagy az eredményt kell azzá alakítani, maradéknál meg az meg még problémásabb.

Ez alatt az utánanézésem alatt elkönyveltem egy újabb mínuszpontot a gyengén típusos nyelveknek is.

A gyengén típusos nyelv nem jó mindenre, de szerintem több az előnye mint a hátránya. Nyelvtől függetlenül kétes esetekben mindig kell(ene) ellenőrzéseket végezni. De a példádat nem tartom jónak, mert ilyen csak egy kezdő programozónál fordulhat elő. Soha nem írnék ilyen vagy hasonló kódot. Ha már a példánál maradunk akkor ha nagyon lusta vagyok ezt írnám str(10)+"12". Egyből egyértelmű.

Ha valaki stabil korrekt kódot ír, akkor nem látom a hátrányát egy gyengén típusos nyelvnek. Egyébként az általad írt példára minden rendes python IDE dob egy warrning-ot.

Azért választottam a gyengén típusos nyelvet, mert szabadidőmben csak pythont használok, és nagyon sok problémát sokkal egyszerűbben meg lehet oldani vele mint C-ben.

A python erősen (dinamikusan) típusos. Szerintem a dinamikus vs statikussal kevered.

Megmondom őszintén, hogy nem tudom a pontos definíciót, de akárkit kérdeztem, hogy mondjon egy gyengén típusos nyelvet, ők mind pythont mondták.

Szóval akkor a szavazás eredménye igen csak ellentmondó.

Akkor te olyan emberekkel beszélsz, akik ha bizonytalanok valamiben, nem néznek utána :) Csak gondoltam jó tudni.
----
India delenda est.
Hülye pelikán

Termeszetesen eros tipusbiztonsagot. Az nem programnyelv, hanem ipari hulladek, amelynel egy valtozorol nem lehet barmilyen korulmenyek kozott egzaktul eldonteni, hogy az mifele a mindenfele ostoba type juggling, mint ami pl. a PHP-ben van a (nagyon keveske) rovid tavu elonyei mellett hosszu tavon inkabb csak a hatranyokat termeli.

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

ez mekkora ordas nagy faszsag, mar ne is haragudj

-1

+1 a -1-re :)

-1 a "+1 a -1re"
:P

Na mond, miért jó az, hogy
- teremthet bizonytalan helyzeteket
- statikus kódanalízis gyakorlatilag felejtős
- innen kezdve a kód futtatása nélkül még annyira sem tudod megjósolni a kimenetét
- arról nem is beszélve, hogy öröm hozzá toolt fejleszteni.

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

+0.8 de bennem felmerül, hogy valóban csak olyan rosszul lehet megoldani a gyengén típusosságot mint a PHP-nál? Ott mást is elszúrtak, amit más nyelvekben nem.

class Akarmi()
{
  function A() {}
}

class Valami()
{
  function B() {}
}

function Foo($e)
{
  if ($e == null) throw new Exception("e is null");

  // ...

  if (mt_rand(0,1) == 1)
    $e = new Akarmi();

  // ...

  $e->A();
}

Esetek felében fatal error, ha csak körbe nem bástyázod, esélyed sincs futtatás nélkül megmondani, hogy valóban futni fog-e ez a kód így.

De hogy ne menjünk ennyire magas, OOP szintű dolgokra: nem egyszer visszatérő eset az, hogy volt egy számítás, amely később került bele egy adattáblába. Ezzel nem is volt gond, mert $_GET-en keresztül mindig szám jött (le volt ellenőrizve a formátuma, de számmá már nem lett átalakítva, mert így is működött és senkinek nem tűnt fel), és mivel a használt RDBMS is konvertálta a szövegeket szó nélkül, így nem volt gond.

Majd egyszer csak elkezdték máshonnan is hívni azt a függvényrészt és egy hiba miatt néha bele-belekerült szöveg is, ami miatt elkezdett egészen másképp működni a kód, amelyet nem ritkán SQL hibával honorált a rendszer, hogy ne akarjak már szöveget berakni egy szám mezőbe.

Rá lehet fogni, hogy mi írtunk hibás kódot? Nyilvánvalóan. Kivédte volna egy erősen típusos nyelv a fenti hibákat? 99,99%-ban.

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

Megkapod a maradék 0.2-t is a "+"-ba. :)

programozni tudni kell. az, hogy te nem vagy képes elszakadni az erős típusosságú szemlélettől, az nem a nyelv hibája, hanem a tiéd. az, hogy nem vagy tisztában az adott nyelv típus kezelésével (mit mikor hogyan értelmez, mire konvertál), az szintén nem a nyelv hibája, hanem a tiéd. megfelelő tapasztalat és tudás hiányában felesleges fikázni bármit is.

-1 a nyelv feladata, hogy védje a programozót a gyakran elkövethető hibáktól, illetve lehetőséget biztosítson arra, hogy minél hamarabb (amennyiben van fordítás,
még fordítási időben) kibuktassa a hibákat, mert minél később jön elő egy probléma, annál drágább kijavítani.

Hiába tud valaki profin programozni, ha bekerül a csapatba egy junior fejlesztő, aki esetleg kevésbé jól tud.
Nagy segítség (a juniornak is és a seniornak is), ha nem túl liberális egy nyelv.

Fuszenecker_Róbert

+1

A korlátok nem azért vannak, hogy szívassanak minket és állandóan meg kelljen azokat kerülni, hanem hogy megvédjenek magunktól.

he? szerinted a nyelvnek meg kéne védenie a hozzá nem értéstől? jézusmáriaszentjózsef...

Az úgy van hogy a kocsiban a biztonsági öv/légzsák megvéd ha valaki beléd hajt, az hogy akkor is megvéd ha a kihalt utcán belehajtasz a villanyoszlopba már csak extra. Rengeteg sofőr van akinál sosem nyílt még ki a légzsák, ha azt mondod h. akkor az ő autóikból ki kéne szerelni akkor nem jól méred fel a problémateret...

Vrumm vrumm. Ide is megérkeztek az autós hasonlatok. \o/

pl.

if (a = 3) jobb nyelvekben le sem írhatod, mert error-t dob. nem véletlenül..

És erre találták ki a C kóderek a Yoda conditions használatát, azaz if (3 == a) forma használatát

A legjobb megoldás szerintem a compiler warning.

Vagy hogy ne legyen az értékadás kifejezés.

Ez utóbbi akkor nem jó, amikor láncolt értékadást szeretnél csinálni, azaz az a = b = 5; alakot nem tudnád használni.

Akkor a "while ($row = mysql_fetch_array())" se működjön? Ez butaság lenne.

nem ugyanarról beszélünk...

de

nem

én azt írtam "if (a = 3) jobb nyelvekben le sem írhatod, ..."

nem azt, hogy while, hanem azt, hogy if.

Mindkettő (if és while) logikai értéket vizsgál. A két utasítás ebben ekvivalens, HTH.

Oké, átgondoltam. Nem engedném a while-t sem, csak így:

while ((row = mysql_fetch_array()) != NULL){

}

Ebből már csak egy lépés a:

while ( (igenTenylegErteketAkarokAdniIde!!!444!44) (a = a_kezdoerteke_ciklushoz)) {

Természetesen ezt lokalizáltan vezetném be, ha angol billentyűzettel programozták, akkor 4-esek heylett 1-eseket várna a fordító.

Azaz külön logikai típus kell, és while azt fogadja csak el - ez sok nyelvben így van.

(Egy eset ellen nem véd ha a függvény logikai értékkel tér vissza akkor az = esetén a visszatérési értékre tesztelsz, az == esetén meg arra hogy az egyenlő-e a változóval - mondjuk erre lehet warningolni...)

C++ logikai kifejezést vár, mégsem kell egyenlőségvizsgálni.
----
India delenda est.
Hülye pelikán

Implicit típuskonverzió gondolom... Akkor hozzáveszem még, hogy: ne legyen implicit NULL->false típuskonverzió ;)

Mert ez azon múlik hogy az "=" jel után kifejezést kapunk, meg minek kéne pont csak az ifet diszkriminálni? Meg a "while (a = b)" "while (a == b)" helyett se életszerűtlen, és ugyanúgy hibát okozhat.

Warning: támogatom (sőt, a fordítók is).
Ne legyen kifejezés: ez marhaság. Miért NE lenne kifejezés? Ezzel tudsz jókat cselezni (főleg C++-ban).
----
India delenda est.
Hülye pelikán

Na ezzel a cselezgetéssel van gondom, amikor a magát vagánynak gondoló kóder - mert ő bizony
aztán mindenféle trükköt tud - elkezd alkotni, aztán kiderül, hogy mégsem volt olyan kib@szottul
okos, és debuggolhatjuk hárman egy hétig a kódját (természetesen már régóta nincs a cégnél), és ha szerencsénk van, akkor még nem is könnyen reprodukálható a hiba. Ezek után érdemes végiggondolni,
hogy mennyibe is kerül egy ilyen stílusban kódoló fejlesztő a cégnek (elárulom, nagyon sokba...)

Lehet gányolni is, meg lehet trükközni is. A kettő kurvára nem ugyanaz. Az a szép a (jól megcsinált) absztrakcióban, hogy amíg nem akarsz belepiszkálni, nem kell érteni a működését, és könnyíti az életet. Lásd a <<, >> operátorok és a streamek, meg template mágiák mindenfele az STL-ben.
----
India delenda est.
Hülye pelikán

if (a=3) azért nem a trükközés kategória, hanem nagyon komoly hibákat lehet vele elkövetni. Ezeknek a programozástechnikai elírásoknak a mennyiségét egy nyelvnek kutya kötelessége lenne lecsökkenteni, ezáltal is kényszeríteni a programozót, hogy helyes kódot írjon.

Erre gondolsz?
if(a=3) vs. if(a==3)?
Ezt sokáig nyomozzátok?
Unit tesztet szoktatok készíteni?
CI van a cégeteknél?

--
unix -- több, mint kód. filozófia.
Life is feudal

az if (a=3) az egy példa volt, amitől a nyelvnek alapból védeni kell, de mindenki tudna a saját nyelvében egy csomó hasonlót írni, legalábbis aki már szívott azzal, hogy debuggolt x időn keresztül,
és utána a fejét verte a falba, hogy bakker, ezt az egy sort kellett átírni, amitől esetleg még a fejlesztőeszköz is megvédhetett volna.

Éppen ezért a magam részéről a szépen megírt, tiszta és olvasható, nem pedig a "nagyon trükkösen összerakott" kódot preferálom, már csak a szívás faktor miatt is. Vannak olyan esetek, amit a unit teszt nem véd le, mert mondjuk nem csináltunk teljes lefedő tesztelést, esetleg nem volt rá idő, vagy mondjuk hozzádvágnak egy 200 megás kódbázist, amit 27 másik ember írt. Sajnos az élet gyakran felülírja a "hogy kellene helyesen" csinálni dolgokat.

Góban megoldották, hogy ne legyen kifejezés, olvass utána!

Sok helyütt megoldották, hogy ne legyen kifejezés. Miért is releváns ez?
----
India delenda est.
Hülye pelikán

Pascalban is megoldották, olyan is lett a nyelv, és kb. pont annyira is segít megtanulni mindjárt az elején az ilyen problémákat elkerülő stílust. De nem baj, az a legjobb tanulónyelv (nagyon nem).

,,Miért NE lenne kifejezés?"

én, mint linux felhasználó, valamilyen szinten szeretném, ha a lelkes hobbikóderek, akik az általam használt programokat írják, bugmentesebb kódot termelnének. Egy szavazáson, mely arról szól, hogy megkössék-e az ő kezüket egyértelműen erre szavaznék.


Puppy linux felhasználó

Annyira azért nem lehet ez gyakori hibaforrás, ráadásul a legtöbb IDE konfigolható, hogy szóljon, ha feltételben értékadás van. Rendes tesztelés, QA és megfelelő folyamatok (pl. csak peer review után kerülhet be a módosítás etc.) kell erre.

Kivitelezők is építenek szar épületet, mégsem szabályozzák le őket, hogy csak 2x3 méteres faldarabokat legózhatnak össze mert azt nem lehet elrontani, hanem van műszaki átvétel.

BlackY

Haggyuk már, mindenki tudja, hogy kellene minőségi kódot csinálni, vajon az open source programok mekkora része van úgy fejlesztve,
ahogy iparilag kellene, és nem lelkes amatőrök által? Na ugye.

És hány olyan sikeres (itt: elterjedt) open-source projekt van, amit kizárólag lelkes amatőrök fejlesztenek, ami mögött nincs céges fejlesztői gárda, de legalábbis egy érdekelt cég? (meg persze hány olyan openszórsz cucc van, amit a Linus-féle "csak a C" miatt a lehető legrosszabb választható nyelven fejlesztenek?) Nem a nyelvvel van gond, az meg rossz hozzáállás, hogy a rossz management (processz management, jogosultság-menedzsment stb.) miatt az összes (így a jóktól is) fejlesztő kezéből vegyünk el eszközöket.

Ismét házas hasonlat: csak azért, mert az ukrán vendégmunkások szar házat építenek és ők kalapáccsal csinálták, tiltsuk be a kalapács-használatot?

BlackY

Hogy lett a leginkább kipufogócsőre emlékeztető ragacsosfém megnevezhetetlen "szerszám"-ból kalapács? Mert az elágazva értékadás házépítésben leginkább ennek felel meg, és nem a kalapácsnak.

Az a pointer-aritmetika lenne :)

Amúgy arra vonatkozott a fenti megállapítás, hogy csak azért, mert lehet egy eszközt rosszul használni, még nem az eszköz a hibás, vagy még ha az is lenne, akkor sem kell megtiltani.

BlackY

Az if (a=b) ellen viszont az se véd :)

Két külön dologról beszéltek.
--
unix -- több, mint kód. filozófia.
Life is feudal

De ez rontja a kód olvashatóságát.
Engem nem az érdekel, hogy 3 egyenlő-e "a"-val, hanem az, hogy "a" egyenlő-e 3-mal.
Ne mi legyünk már a nyelvért, hanem a nyelv legyen értünk.

Fuszenecker_Róbert

Fokozzátok még légyszi! Akinek gondot okoz olvasáskor fejben megcserélni egy számot és egy változót, az ne programozzon, hanem szüljön inkább, kevesebb kárt termel a munkáltatójának.

Ez elég undorító hozzászólás volt...

Ezaz! Felejtsük el a beszédes változóneveket is! Akinek gondot okoz észbentartani, hogy mit jelent a "hsrp", "hsrq", "sc", "se", az bele se kezdjen fejlesztésbe!

Mennyivel jobban is olvashatók, mint a:

HttpServletResponse -> servletResponse -> response
HttpServletRequest -> servletRequest -> request
ServletContext -> servletContext -> context
Session -> session

Akkor a nyelv követelje meg a coding convention helyett, hogy csak angol szavakból lehessen változónevet kreálni? Vagy hogy jön ez ide?

Igen, olvashatóbb az alsó négy példa, én is jobban szeretek olyat olvasni, de más 10 változónevet megjegyezni, mint egy sort fordítva olvasni, ez utóbbi több évvel a szakmában ne okozzon már gondot.

Mi bajod a C-vel? :)

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

Ha most tippelnem kellene, akkor azt mondanám, hogy C-ben kódolsz és mindenki hülye, aki nem azt beszéli 0. anyanyelvének.

Nos, a helyzet az, hogy jelenleg a világ tetemes részének időre kell nagyobb mennyiségű kódot termelnie, amikor jobb nem a triviális hibákkal szívni. Minden elismerésem, ha te elsőre tökéletes kódot írsz, mindig gondolsz az összes use-casera, összes lehetséges alul/felül/jobbra/balra csordulásra, persze mindezt anyanyelvi szinten anélkül, hogy egyáltalán át kellene gondolnod a feladatot. És nyilván egymagad produkálsz egymillió kódsort/nap, ami miatt melléd nem kell senkit se felvenni.

Egy szóval nem mondom, hogy nem kell ismerni azt a nyelvet, amiben dolgozunk, de attól még ne engedjen már meg fasságokat a nyelv, amiből probléma lehet.

De hajrá, még mindig várom az érveid:

http://hup.hu/szavazasok/20130507/programozasi_nyelvek_osszehasonlitasanal_az_erosen_tipusossagot_vagy_a_gyengen_tipusossagot_tartod_elonynek#comment-1600102

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

"C-ben kódolsz és mindenki hülye, aki nem azt beszéli 0. anyanyelvének."

En ilyet sosem allitottam, meg csak nem is sugalltam. Te ellenben:

"Az nem programnyelv, hanem ipari hulladek, amelynel egy valtozorol nem lehet barmilyen korulmenyek kozott egzaktul eldonteni, hogy az mifele a mindenfele ostoba type juggling, mint ami pl. a PHP-ben van"

Btw, teljesen mindegy, miben kodolok, nem ez a lenyeg. A reakciommal nem a gyengen tipusos nyelveket akartam favorizalni, csak nem tetszett, ahogyan lekezeled azokat. Minden nyelvnek van erossege, gyengeje, de olyan nincs, hogy jo es rossz nyelv. Jo es rossz programozo van. Engem sosem zavart a nyelvek kulonbozosege, mindig megprobaltam a leheto legjobban alkalmazkodni az eppen hasznalthoz, es nem csepultem, hogy miert nem olyan, mint amivel korabban dolgoztam. Termeszetesen szoktam en is elkovetni trivialis hibakat, de egyreszt megfelelo gyakorlattal azert minimalizalni lehet ezeket, masreszt vannak ra eszkozok, amik segitenek a hiba felderiteseben, harmadreszt letezik olyan, hogy code review: ha en nem veszem eszre, akkor eszreveszi mas.

De irhattam volna masnak is, nem csak neked, mert itt az emberek jo resze lathatoan teljesen el van szallva a kedvenc (erosen tipusos) programozasi nyelvetol, es ugy osztjak magas lorol az eszt, hogy kozben halvany lila seged fogalmuk sincs, mirol beszelnek. Tudom, ez megszokott dolog itt a hupon, nem tegnap regisztraltam en sem, de neha nem tudok elmenni szo nelkul a jelenseg mellett.

Amint eljut a futás a randomtól függő értékadásig, $e értéke szuperpozícióba kerül, és onnantól mindegyik lehetséges értékére helyesnek kell lennie a kódnak. Nem kell futtatni ahhoz, hogy megmondd, hogy 50% esély van rá, hogy hibát dob - gondolom te se futtattad le, miután megírtad.

Mekkora hulladek a C is, hiszen annak is weak type systeme van!

Ott legalább a statikus típusellenőrzés néha megdobál warningokkal: de amikor meg épp nem akkor lehet is koppanni miatta - ezt én nem nevezném előnynek...

Lehet haszna is.

Csak hogy ne php legyen, mondok lua-példát: írtam az awesome ablakkezelőhöz egy kis modult, amellyel "hotkey-láncokat" lehet definiálni, és a függvény egyik paramétere több dolgot is elfogad: vagy egy tömböt, vagy pedig egy függvényt. Ha tömb, akkor megvan, ami kell, ha meg függvény, akkor meghívja, és majd a függvény visszatérési értéke adja a tömböt (hasznosság: ha munkaasztalt akarok váltani, olyan kell, amin már van valami - üresre minek => ezt pedig egy függvény generálja).
Persze lehetne kettő függvényt is írni, egy, amely tömböt vár, és egyet, amely függvényt vár - de miért kellene kétszer leírni ugyanazt, mikor gyakorlatilag a függvényes verzió egy sorral több? Function overload... nem tudom, van-e lua-ban, de akkor is egyszerűbb egy
local tomb = (type(parameter)=="function") and parameter() or parameter
sorral kezdeni a függvényt, és utána a tomb változót használni.

weak typing != dynamic typing, fyi

Ez nem erős/gyenge típusosság kérdése hanem a futásidejű típusellenőrzés megléte, ilyesmi erősen típusos nyelvben is lehet (pl. instanceof a Javaban), illetve a te példádban még az is kell, hogy a függvények önmagukban is teljes értékű típusok legyenek (ez sem erős vagy gyenge típusosság kérdése).

És mint te is írod, ha minden kötél szakad ez megoldható polimorfizmussal és két függvénnyel, a közös részt persze akár kiemelheted külső metódus(ok)ba - ha sikerül, nincs redundancia!

szerk.: Egyébként meg üdvözlet a jelen törésvonal másik oldaláról - én egy pár évig (amíg csak én használtam a gépem) lelkes xmonad felhasználó voltam... ;P

Hm, valóban, ez nem volt jó példa.

+1 az awesome-ra!

Ma már az erősen típusos nyelvek (elsősorban a C#-ra gondolok) is olyan könnyen kezelhetők, mint a gyengén típusosak.
Hamarabb oldom meg a feladatot egy (általam) ismert, erősen típusos nyelvvel, mint egy részben ismeretlen / régen használt, gyengén típusossal.

Fuszenecker_Róbert

Attól függ. Gyengébb felkészültségű programozóknak, akik nem írnak maguktól szépen és jól áttekinthető kódot sokat segíthet az erős típusosság, mert kevesebb lehetőséget hagy a khm... "kreativitásuk" számára. Erősebb felkészültségű programozóknak jó játékszer a gyenge típusosság. Csak higgyem el, hogy eléggé ért hozzá, hogy jól használja a lehetőségeit...

Tudnál mondani egy példát, amikor jól használod a gyenge típusosságot?

Nem. Én nem vagyok elég jó programozó ahhoz, hogy erre elég jó példát tudjak mondani.

Perl: amikor egy hash-táblába belepakolsz mindent amit csak akarsz.
A konfigurációt a perl úgy kezeli, hogy egy hash-ben vannak az egyes attribútumok értékei. Ezek tetszőlegesek lehetnek, tömb, hash,...

Javaban a HashTable[String,Object]-nek felel meg egy ilyen adatszerkezet.

Persze a java is megoldja a getInt, getString, getArray,... metódusokkal, ahol lehet.

Ha van egy txt fájlod, amit egy másik txt-vé akarsz alakítani, a perl ideális. Megírod 10 perc alatt, nem idétlenkedsz a típusokkal. A gány ide tökéletes, megoldás kell, nem pedig szépségverseny.

Természetesen, ha nem r=1, hanem bonyolultabb feladatokat akarsz megoldani, onnantól a gány megoldás többé nem járható.

C#-ban is bele lehet rakni egy List-be akármit, de azt te ki nem szeded úgy, hogy ne úgy kezeld le, ahogy bedobtad. És ez jó.

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

A listáknál generics-et használnak <String>.

Ez fordítási időben kerül ellenőrzésre. Természetesen írhatsz Object-et is, de akkor már tényleg semmi értelme az egész generics-nek, mert utána kasztolhatsz ezerrel és agybajt fogsz kapni az idióta kódtól. A régi java-nál, amíg nem volt generics, kötelező volt kasztolni, ha a hash-ből egy elemet kivettél.

Természetesen mindenre van megoldás:


public <T> T getValue(String name, T dflt)
{
  T response = (T)hash.get(name);
  return (response != null) ? response : dflt;
}

Ez olyan értéket ad vissza, amilyen default-ot megadsz. Vannak java-s cuccok, amik kifejezetten szeretik hash-ben tartani az értékeket, utána meg a fentiekhez hasonló generikus hívásokkal játszanak.

Bocs, List<object> volt az eredeti hozzászólásban, más kérdés, hogy a fogyi drupal lenyelte.

De igen, értelmes ember ilyet csak nagyon indokolt esetben csinál.

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

Hát, ha csak ez kell, van egy jó hírem:


public <T> T getItem(int index, T dflt)
{
  T response = (T)array.get(index);
  return (response != null) ? response : dflt;
}

...
String s = obj.getItem(1, (String)null);
Integer i = obj.getItem(2, 23);
...

:)

Vagy használom a sima List<T>-t. .NET 2.0 már mindenhol van, ami számít és .NET.

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

Nem ismerem annyira a C#-ot.

Hogyan tudsz kasztolás nélkül egy listából String-et, Integer-t, List-et kivenni (java-ban a fentiekkel megy)?

Ugyan miért menne? Olyan szép ClassCastException lesz a return előtti sorban, a kivételnél, mint a huzat.

Kár filozofálni, futtasd le és vond le a tanulságot:


import java.util.ArrayList;
import java.util.List;

public class Test {
  private List<Object> list = new ArrayList<Object> ();

  public <T> void addItem( T item )
  {
    list.add( item );
  }

  public <T> T getItem( int index, T dflt )
  {
    T resp = (T)list.get( index );
    return (resp == null ) ? dflt : resp;
  }

  public static void main( String []args )
  {
    Test obj = new Test();
    obj.addItem("Hello");
    obj.addItem(23);
    String str = obj.getItem(0,"");
    Integer in = obj.getItem(1,0);
    System.out.println(str);
    System.out.println(in);
  }
}

Nem ismerem a Java Genericset, de C# az készít egy-egy fv-t stringhez, integerhez, hasonló esetben. És hogy ha ott te nem int/stringet raksz bele a listádba, akkor dobni fog egy InvalidCastExceptoin-t. Meglepődnék, ha Java-ban máshogy lenne.

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

Ha megnézed a kódom, itt is 2*2 függvény készül, meglepődnék, ha C# alatt ez nem menne.

void addItem(String item);
void addItem(Integer item);
String getItem(int index, String item);
Integer getItem(int index, Integer item);

Ami a ClassCastException-t illeti, az dobódik, ha nem az a típus, amit ki akarsz olvasni.

A GWT/GXT rendre ezt a módszert használta, valószínűleg azért, mert a hash-ekkel könnyebben boldogult, mint más adatszerkezettel (java->javascript fordító). Emellett nem akarták, hogy a kód 90%-a kasztolásból álljon.

Nem készül két függvény, nézd meg a bytekódot. Egy darab metódus fog fordulni, ha megnézed reflectionnel, akkor sem látsz két metódust majd.

A részleteket nem ismerem.

És még a C++ templatekre mondják, hogy túl van komplikálva :)
----
India delenda est.
Hülye pelikán

Mivel List<Object>-ben minden elfér, ezen nincs mit csodálkozni. Ha a listád mondjuk List<String> lenne és Integer-t vennél ki belőle, lenne ClassCastException. Vagy amikor azt mondod, hogy String in = obj.getItem(1,"") és láss csodát.

Az előző hozzászólásodban még nem volt arról szó, hogy nem muszáj annak a ClassCastException-nek dobódnia. Legalábbis nekem az jött le, hogy mindig dobódni fog, ami ugye nem igaz.

A kódom egyébként majdnem ekvivalens a (String)list.get(1) átalakítással, azzal a nagy különbséggel, hogy nem kell éjjel-nappal kasztolni, mert a generics azt megcsinálja helyettem.

:)

És most ugrik a majom a vízbe: különböző visszatérési érték, ugyanaz a paraméterlista.
Láss csodát: működik, hol stringet, hol intet ad vissza ugyanaz a függvény.


import java.util.ArrayList;
import java.util.List;

public class Test {
  private List<Object> list = new ArrayList<Object> ();

  public <T> void addItem( T item )
  {
    list.add( item );
  }

  public <T> T getItem( int index )
  {
    return (T)list.get( index );
  }

  public static void main( String []args )
  {
    Test obj = new Test();
    obj.addItem("Hello");
    obj.addItem(23);
    String str = obj.getItem(0);
    Integer in = obj.getItem(1);
    System.out.println(str);
    System.out.println(in);
  }
}

Nem, a type erasure után ő mindig objectet ad vissza, és a fordító a hívás helyére helyez egy implicit cast-ot String-re vagy Integerre, ClassCastExceptionnel, mindennel.

BlackY

Igazából egészen hasonló, mint a Java-ban (csak kicsit máshogy nevezték el a Generics-es típusokat).

var dic = new Dictionary();

dic.Add(1, "egy");
dic.Add(2, "ketto");

string s1 = dic[1]; // Indexer

// vagy

string s2 = null;
if (!dic.TryGetValue(2, out s2))
{
  //  Jellemzően valami hibakezelés
}

Na meg persze, objektumok esetén, ami az interface-ra illeszkedik és/vagy gyerekosztály, olyat tudsz kiszedni. Castolás nélkül természetesen nem tudsz, de értelmetlen castolásokat eleve le se enged fordítani (pl. nem tartozik bele az objektumfába) - mint a Java.

Persze, még mindig lehet ész nélkül object-re castolni és onnan vissza, ez ellen ez a nyelv sem véd, de a C# generics azért meglehetősen sok mindenre jó...

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


List listam = new ArrayList();
listam.add("stringem");
String str = (String) listam.get(0);

--
unix -- több, mint kód. filozófia.
Life is feudal

List<Object>nek van egy korábbi megfelelője a generic előtti időkből. Úgyhogy object esetén szerintem nem kell genericet használni.
--
unix -- több, mint kód. filozófia.
Life is feudal

Van, System.Collections.ArrayList a neve. Bár nem emlékszem, hogy valaha is kellett különösebben.

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

Ne keverjük a szezont a fazonnal. A List egy interfész, az ArrayList egy megvalósítás, csakúgy mint a LinkedList, Vector és a többiek.

A generics előtt kasztolás volt.


List l = new ArrayList();
l.add("String);
String first = (String)l.get(0);

Ne keverjük a C#-ot a Java-val ;)

BlackY

Tényleg. :)

Igazából csak azt nem értem, hogy a Sun Microsystems miért nem kezdte perelni a Microsoftot, hogy újraírta a java-t. :)
A két nyelv valahogy kísértetiesen hasonlít egymásra, a fenti csevegésnél egyedül a package-nevekből derül ki, hogy C#-ról van szó.

Ha a Microsoft idióta menedzserei nem win-only nyelvet csináltak volna, akkor java-t már csak a lexikonokban látnánk, mint történeti érdekesség.

Azért ne már azon jogászkodjunk, hogy a List-et List-nek hívják minden nyelvben. (Egyébként pl. a HashMap (vagy mi Java-ban) az itt Dictionary, krákogtak is miatta, hogy kissé inkonzisztens lett).

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

"...a fenti csevegésnél egyedül a package-nevekből derül ki, hogy C#-ról van szó."

Azért van elvileg más különbség is. C#-ban a property-k nagybetűvel kezdődnek, nem?

Hát, C#-ban vannak property-k, java-ban nincsenek.
A függvények elnevezési konvenciója más C#-ban, FunctionName, mint javaban functionName.

Meg még sok egyéb más dolog is van, de alapvetően egy korszerűsített java.

de alapvetően egy korszerűsített java

Azért, mert ugyanúgy byte code-ot használ, mert virtuális gépben fut meg mert objektum-orientált? Ezek alapján inkább egy korszerűsített Smalltalk (trollok mindjárt úgyis kijavítanak, hogy volt korábban is nyelv/környezet, amire illett ez a három tulajdonság).

Egyszerűen egy logikus lépés függetleníteni az alkalmazások kódját az architektúrától/op.rendszertől (bár ez utóbbi nem volt cél MS-nél), nem találtak olyan technológiát, amivel a saját ötleteiket is megvalósíthatnák (lásd a Java ragaszkodását a visszafele kompatibilitáshoz, a nyelvi elemek/API-k nagyon lassú standardizálását), csináltak egy sajátot. Amihez fogták az összes dolgot, ami nekik más nyelvben szimpatikus volt és beletették. Ennyi. (tudod, jótól lopni, meg great artists steal stb.)

BlackY

A java sok idióta feature-ét pedig nem vették át:

- rendes destruktor jelölés finalize helyett (csak szintaktikai)
- előjel nélküli adattípusok (java csak előjeles)
- operator overloading
- JIT fordítás (a java másképp oldja meg)
- property-k

Java esetén a főokosok az operator overloading-ot eleve elvetették, de számomra ez inkább bug, mint feature. Legalábbis az emberek 99%-a az == leírásánál arra kíváncsi, hogy az adott objektum megegyezik, a maradék 1% kíváncsi a referencia szerinti összehasonlításra.

- Destruktor - ritka, ahol kifejezetten jól jönne, de előfordul (ha már nincs szükség egy objektumra, akkor egy metódushívással felszabadítom a feleslegesen foglalt erőforrásokat [fájlok, adatbázis kapcsolatok etc.], memóriát meg úgyis a GC ill. a processz kinyírásakor a VM kezeli).
- Előjeles típusok - hasznos lenne.
- OO: Az ==-vel egyetértek, pl. == -> equals, === -> identitás ellenőrzés jobb lenne, vagy akár fordítva és akkor visszafelé is kompatibilis maradna. Vagy pl. a === b -> Objects.equals(a,b) oszt jónapot. Viszont az operator overloading tipikusan olyan, hogy 1-2 nagyon indokolt esetben tényleg nagy hasznos tud lenni, de minden helyes használatra lehet 10 rossz példát találni, a céges policy/peer review/stb. meg nem biztos, hogy segít.
- Property-k - Hitvita, hogy jó-e teletömködni egy nyelvet új nyelvi elemekkel (property-k, LINQ stb.), mindkettőnek van előnye-hátránya, szerintem nem.

BlackY

Nekem az a véleményem, ha bizonyos nyelvi elemek segítik a kód megértését (esetleg megírását), akkor használom azokat.
A LINQ szerintem kifejezetten kellemesen olvasható :-) Propertyk, eventek ugyancsak tetszenek nekem.

Fuszenecker_Róbert

Az operator overloadinghoz annyit tennék hozzá, én egy olyan megoldást hiányolok, hogy csak egy interface-t kelljen megvalósítani, és onnantól kezdve lehessen használni az ahhoz tartozó operátorokat. Pl. Comparable megvalósításával megkapod a ==, !=, <, >, <=, >= operátorokat. Így invalid lenne az az érv, hogy lehetőség van inkonzisztensen felüldefiniálni az operátorokat. Az operátorok csak nyelvi elemként jelennének meg, fordításkor szépen kicserélődnének a megfelelő metódushívásra. Tényleg csak a == operátorral van gond, de ahogy te is mondtad, be lehetne vezetni még egy operátort.

Propertyk, delegatek, eventek, linq, yield return, extension methods, lambda kifejezések stb.: jó dolgok ezek, ha ésszel használja az ember. Érteni kell, mit csinálnak a háttérben, és nem is kötelező ezeket használni (tervezési mintákkal nagyrészt kiválthatóak), viszont jelentősen meggyorsíthatják egy program fejlesztését.
Szerk: oké, propertyket nehéz megkerülni, viszont arra nem tudok ellenérveket felhozni. :)

Van ahol hasonló: pl. Haskellben ott az Ord typeclass, ha implementálod a compare-t, "ingyen" kapod a <,>,<=,>=, min, max operátorokat (az egyenlőségre külön class van)

De mondjuk ott sincs a standard nyelvben teljesen következetesen végig csinálva (pl. numerikus típusoknál), libraryban vannak próbálkozások.

Pl. ha az összeadás tulajdonságait kikényszerítjük (http://hackage.haskell.org/packages/archive/numeric-prelude/0.3.0.2/doc/html/Algebra-Additive.html) akkor nem lehetne zavart keltő módon + jellel egymáshoz fűzni stringeket - hiszen a konkatenálásnál negáltként működő stringet úgysem tudjuk definiálni ("string"+ (-"string") == "") stb...

Ez baromság, mármint hogy minden összeadható elemnek kell legyen negáltja. Csoportelméletből buktak a nyelv tervezői.
----
India delenda est.
Hülye pelikán

Miért? Nem kell negált? Itt: http://en.wikipedia.org/wiki/Group_%28mathematics%29
azt írja " group axioms, namely closure, associativity, identity and invertibility"
Milyen csoportnál nincs invertálás és akkor miért is csoport az - vagyis milyen csoport definíció alapján csoport invertálhatóság nélkül?

Nem csoportról beszélek, hanem csoportelméletről. Bőven van olyan struktúra, ahol a műveletre nem megkövetelt az inverz megléte (lásd pl félcsoport, ha van balinverz az megegyezik a jobbinverzzel (tehát szimplán inverz), de nem kötjük ki).
----
India delenda est.
Hülye pelikán

Ok. Egyébként nem a nyelv hanem a library tervezői, és nem az ő hanem az én hülyeségem ;) Az én hirtelen ötletem volt hogy lehetne + operátort csoportokra korlátozni, de végül is ez felesleges - egy erősen típusos nyelv így is úgy is kihány valami hibát ha rossz típusokkal használod a függvényeit, gyengén típusos nyelvekben meg kényszerűségből úgyis külön függvényeket felvesznek a külön típusokra (pl. PHP strcmp vs. "1000"=="1e3")...

"(ha már nincs szükség egy objektumra, akkor egy metódushívással felszabadítom a feleslegesen foglalt erőforrásokat [fájlok, adatbázis kapcsolatok etc.], memóriát meg úgyis a GC ill. a processz kinyírásakor a VM kezeli)."

Pontosan erről van szó, hogy kell egy explicit függvényhívás, pont mint C-ben. Amit el fogsz hagyni, illetve osztott tulajdonlás esetén rendkívül nehéz eldönteni, kinek a dolga. Ezért jó a destruktor.
----
India delenda est.
Hülye pelikán

Erre C#-ban van két jó találmány: using statement és az IDisposable pattern. Oké, minden felszabadítás így sem fog egyből megtörténni, de azokat, amelyeket muszáj felszabadítani (pl. fájlok esetén), azokat egyértelműen fel tudod.

DB kapcsolatokra meg más kérdés, hogy sok esetben egyébként is connection poolt használ és emiatt nem zárja be valójában.

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

Én ezt tudom, és ezzel is csak azt bizonyítjuk, hogy C# > Java. Csak ezt próbáltam alátámasztani.
----
India delenda est.
Hülye pelikán

Ezt bizonygathatod 1000 évig is, mert az igazság az, hogy C# << Java.

Magyarra fordítva a C# a java mellett elhanyagolható tényező. Ezt pedig annak köszönheti, hogy nem keresztplatformos, emiatt kizárólag Windows gépeken lehet használni.

Mindenkit lebeszélek a C#-ról, amikor érdeklődik, hogy érdemes-e belekezdeni. Nem, mert nincs hordozható GUI, a WinForms, a Gtk#, Qt# ... mind egy kalap trágyalé.

A java tudás eladható Windows/Linux/Android/Solaris/Mac OS/... rendszereken, a C#-pal meg a seggedet törölheted.

"Magyarra fordítva a C# a java mellett elhanyagolható tényező. Ezt pedig annak köszönheti, hogy nem keresztplatformos, emiatt kizárólag Windows gépeken lehet használni."

http://www.mono-project.com/Software
http://netduino.com/

A .net nem csak gui-s alkalmazások írására jó, ezért a hordozható gui sokszor egyáltalán nem szempont. Java-ban sem csak desktop alkalmazásokat írnak, biztos vagyok benne, hogy te is több natív multiplatform gui-s alkalmazást tudsz felsorolni, mint java-sat.

A mono kizárólag olyan alkalmazásokat képes futtatni, amelyet eredetileg is mono alá terveztek.
Ha megfogsz egy tetszőleges C# alkalmazást és kipróbálod mono-val, akkor 95%, hogy nem fog menni. Ennyit a hordozhatóságról.

Folytassuk a licenszeléssel. Miből gondolod, hogy az MS nem fog szabadalmi perekkel szétzúzni, ha mono-t használsz? Mert ugye a C#-nak szabványos része (ECMA) igencsak kis területet fed le. Ha te mono alatt WinForms-ot kezdesz használni és ebből milliárdos bevételt csinálsz, akkor jelentkezni fog az MS részesedésért, ebben biztos lehetsz.

Miguel de Icaza eredetileg a GNOME-ot akarta C# alapokon újraírni, de kiszavazták, jogosan. Teljesen bizonytalan a mono háttere és erre építeni MS-től független rendszert ostobaság.

A mono kizárólag olyan alkalmazásokat képes futtatni, amelyet eredetileg is mono alá terveztek.
Ha megfogsz egy tetszőleges C# alkalmazást és kipróbálod mono-val, akkor 95%, hogy nem fog menni. Ennyit a hordozhatóságról.

Az arányra citation needed, de még ha ennyi is: ebben az esetben a platform a hibás, vagy az open szósz implementáció?

Miből gondolod, hogy az MS nem fog szabadalmi perekkel szétzúzni, ha mono-t használsz?

Meg van ez jogászkodva: http://www.mono-project.com/FAQ:_Licensing
Ráadásul: mit értesz "mono-t használat" alatt? A végfelhasználó feltelepítheti, mert a licenszkedéssel a Microsoft legfeljebb a Mono Project-et támadhatja. Hogy a kóder MonoDevelopban készíti a kódjait? Hogy disztribúció-fejlesztő csomagot tart benne a default repóban? Az egyetlen, aminél kérdéses, az az, hogy eladásra szánt zárt forráskódú szoftverek esetén mi van, ilyet gyártva meg még magánszemélynek is megéri megvenni a Visual Studio-t (cégnél végképp).

BlackY
ui.: Nem a Microsoft-ot védem, C#-al eddig csak tanórán találkoztam, Java-t ismerem/használom, csak ezzel a "kiáltsuk ki az ördögnek a Microsoftot mert fúj C# és ha írok egy HelloWorld-öt akkor szétperelnek" dolog zavar.

"Ha megfogsz egy tetszőleges C# alkalmazást és kipróbálod mono-val, akkor 95%, hogy nem fog menni. "

Muhahaha, látszik, hogy csak a szokásos antims fika szól belőled.

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

WPF-et hogyan futtatod monoval?

hogy nem keresztplatformos, emiatt kizárólag Windows gépeken lehet használni.

Leszámítva, hogy a második tagmondat féligazság (Mono), még a logikai kapcsolatot is sikerült megfordítanod.

Mindenkit lebeszélek a C#-ról, amikor érdeklődik, hogy érdemes-e belekezdeni.
Vallási okból lebeszélni valakit piacképes technológiáról (mert van piaca) meg rossz döntés, különösen, hogy emiatt úgyis a Java-t választja és neked konkurrenciád lesz, nem jó döntés.

Nem, mert nincs hordozható GUI, a WinForms, a Gtk#, Qt# ... mind egy kalap trágyalé.
AWT/Swing? Azért azok sem tökéletesek, na...

BlackY

"különösen, hogy emiatt úgyis a Java-t választja és neked konkurrenciád lesz, nem jó döntés."

Lehet, hogy Csab titokban .net fejlesztő. :)

Ui, nem neked, általánosan: a C# csak egy nyelv, a .NET a platform, ne keverjük.

A C# nyelv az valóban szebb, mint a java. De csak a nyelv, amivel önmagában semmire sem mész, ha a libek használhatatlanok.

A WPF platformfüggő, a WinForms még a Commodore 64 időket idézi, amikor nem relatívan helyezed el az elemeket, hanem a (20,30)-as pozícióba (50,62) méretben, a Gtk# meg pontosan olyan stabil, mint a Gtk, a dokumentációja meg a forráskód.

Bocs, de a Swing legalább dokumentálva van és nem a (23,47)-re kell az elemeket elhelyezni, hanem 10%-25%.

Igen, elkezdtem C#-ban programozni, ami a Gtk szartúrásával végződött, mert egy rohadt doksit sem tudtak az API-ról csinálni.

Tehát te béna vagy => a C# szar. Ezért nem lehetnek szép dolgaink, mert ilyen megmondóemberek ülnek a döntéshozó pozíciókban is (mert ugye arra hamar rájönnek, hogy termelő munkát képtelenek végezni).
----
India delenda est.
Hülye pelikán

Nem értelek, azért vagyok béna mert nem vagyok hajlandó Gtk-os forráskódot túrni a programozáshoz?
Ott a java, dokumentálva van és minden platformon működik, megy is erőfeszítés nélkül!

Egyáltanán nem muszáj szart használni, ha normális megoldás is van!

Tehát azért, mert a GTK# alul-dokumentált, a C#/.NET a hibás. Akkor ezek szerint, ha meghakkolom az swt oldalát és törlöm az összes dokumentációt, akkor a Java szar lesz?

BlackY

Pontosan, a minőségi kód minőségi dokumentációt tartalmaz.

Ha én menedzser vagyok és látom, hogy java alatt valamit kifejleszteni 1 hónap, míg C# alatt az aluldokumentált Gtk miatt 2 hónap, akkor vajon melyik nyelv mellett fogok dönteni?

A másik válasz a kérdésedre: igen, amennyiben rendes Gtk dokumentáció készül, akkor ez a döntés megváltozhat.

Akkor közvetlenül rákérdezek, mert nem jött át az előbb: az miért a C#/.NET/Microsoft/Mono/akármi hibája, hogy egy tőlük független projekt aluldokumentált? Ilyen alapon:


package foo.bar;

class Foo {

}

Tessék, van egy nem dokumentált, nem unit testelt, nem ... Java project, akkor a Java most rossz és ha válaszolsz erre a kérdésre (ezzel elvéve a szerkesztési jogom), akkor a Java javíthatatlanul és véglegesen szar lesz?

BlackY

Lehet, hogy az én tudásom kevés.
Feladat: grafikus C# alkalmazást írni, ami platformfüggetlen.

Kérlek írd le a megoldást, ezután beszéljünk a részletekről!

Az elméletek az IT-ben senkit sem érdekelnek, a kérdés, hogy hogyan kezdjek hozzá.

http://www.mono-project.com/Gui_Toolkits
Válogass.

Amúgy meg lentebb írod, hogy fejlesztesz, nem Windows-t használsz. Azért időnként illik minden célzott platformon tesztelni a programot, mert a Java mindenhol cross-platform, kivéve ahol nem.

BlackY

Ezeket a köröket már végigfutottam és arra jutottam, hogy java-n fogok feljeszteni.
(Vesd össze a monodevelopot mondjuk az Eclipse-szel)

Ez van, sajnos. Nem véletlenül marginális Linuxon a C# használata.

Egyértelműen ki lehet mondani, hogy Linux alatt nincs értelme C#-ban programozni, mert sem megfelelő stabil library-k, sem rendes fejlesztőeszközök, sem dokumentáció nem áll rendelkezésre.

Egy random embernek nem sikerült => a C# nagyobb valószínűséggel szar, mintha sikerült volna.

Vagy hogy máshogy határozod meg, hogy mi szar valószínűleg?


Puppy linux felhasználó

Nézd, abba a hibába estél, hogy feltételezed, hogy én ugyanazon metrika szerint értékeltem a nyelvet, ahogy te. Pedig nem.
A C# az a nyelv, amit a Javasok szerettek volna, csak (még) buták voltak hozzá, amikor elkezdték.
----
India delenda est.
Hülye pelikán

> A C# az a nyelv, amit a Javasok szerettek volna, csak (még) buták voltak hozzá, amikor elkezdték.
Merész kijelentés alá is tudod támasztani?

Szerintem azért nem igaz ez, mert nagyon sok olyan dolog is kimaradt a Javából, ami C#-ban van (pl. operátortúlterhetés), viszont már (pl. C++-ban) a Java kezdetén is volt. Ergo nem azért maradt ki, mert a Javasok "buták voltak hozzá". Nekem inkább úgy rémlik, hogy minél egyszerűbb (szintaktikailag is), de erősen OO nyelvet akartak. És valljuk meg, ez nekik igen jól sikerült.

Nem azt állítottam, hogy nem léteztek azok a dolgok, amiket pl kihagytak, hanem hogy rosszul tervezték meg a nyelvet. Nagy különbség. Elmagyarázom, mert tudom, hogy kell (hiszen már elsőre sem értetted): volt operátortúlterhelés, de azt hitték, jó lesz kihagyni (néhány nem elemi típusra aztán mégis csinálni). Hülye döntés volt, a C# tervezői már látták, hogy a Javaban miket rontottak el, és azt nem úgy csinálták.
----
India delenda est.
Hülye pelikán

There are some things that I kind of feel torn about, like operator overloading. I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++. I've spent a lot of time in the past five to six years surveying people about operator overloading and it's really fascinating, because you get the community broken into three pieces: Probably about 20 to 30 percent of the population think of operator overloading as the spawn of the devil; somebody has done something with operator overloading that has just really ticked them off, because they've used like + for list insertion and it makes life really, really confusing. A lot of that problem stems from the fact that there are only about half a dozen operators you can sensibly overload, and yet there are thousands or millions of operators that people would like to define -- so you have to pick, and often the choices conflict with your sense of intuition. Then there's a community of about 10 percent that have actually used operator overloading appropriately and who really care about it, and for whom it's actually really important; this is almost exclusively people who do numerical work, where the notation is very important to appealing to people's intuition, because they come into it with an intuition about what the + means, and the ability to say "a + b" where a and b are complex numbers or matrices or something really does make sense. You get kind of shaky when you get to things like multiply because there are actually multiple kinds of multiplication operators -- there's vector product, and dot product, which are fundamentally very different. And yet there's only one operator, so what do you do? And there's no operator for square-root. Those two camps are the poles, and then there's this mush in the middle of 60-odd percent who really couldn't care much either way. The camp of people that think that operator overloading is a bad idea has been, simply from my informal statistical sampling, significantly larger and certainly more vocal than the numerical guys. So, given the way that things have gone today where some features in the language are voted on by the community -- it's not just like some little standards committee, it really is large-scale -- it would be pretty hard to get operator overloading in. And yet it leaves this one community of fairly important folks kind of totally shut out. It's a flavor of the tragedy of the commons problem.

http://www.gotw.ca/publications/c_family_interview.htm

Annyira imádom, amikor azért szar/használhatatlan/trágya/rosszul tervezett... egy nyelv, mert nincs benne valami, amiről a vélemények szanaszét megoszlanak. Hasznos időnként? Igen. Gyakran előfordul, hogy túlzásba viszik a használatát és legalább annyira ocsmány és olvashatatlan lesz a kód, mintha simán függvényekkel csinálnák? (nem lennék meglepve, ha valahol production rendszerben a Person típuson a +/- overloaded lenne és másik Person-nal a házasodást/elválást jelölné)

Nagyon jó hozzáállás az, amit Stroustrup-tól mindig idéznek, hogy "a programozó kezébe kell adni a döntést még ha a rossz döntést hozza is", evolúciós szempontból is jó lenne mindenkinek egy pisztolyt adni a kezébe, hogy ha akarja lábon lőhesse magát, csak mondjuk egy library kódban idiótán beszúrt OO azt jelenti, hogy az eredeti fejlesztő mindenkit lábon lő, akinek használnia kell majd a kódját.

De már egyszer valahol lent/fent leírtam: szerintem is NAGYON INDOKOLT ESETBEN kifejezetten jó lenne NÉHÁNY operátort felülbírálhatóvá tenni (meg is lehetne csinálni [byte kód szinten] backward compatible módon pl. a Java 9-re), de attól, hogy a nyelv nem biztosít egy eszközt, ami NEKED személy szerint tetszik, még nem feltétlenül szar a nyelv.

Nekem pl. a Smalltalk kifejezetten tetszik a tényleg minden objektum, de nem híresztelem, hogy a Java/C#/C++/... rosszul tervezett, csak azért, mert pl. primitív típusokhoz kell autoboxing, hogy objektumként kezeljem, vagy hogy nem tudok pl. egy metódusnak egy feltételt simán paraméterként átadni.

Edit: Ja, és még egy. Nyugodtan lehetne alternatív fordítót írni, ami akár csak annyival tud többet, hogy van benne OO, mégse tolonganak az OO-kiterjesztett javac forkok.

BlackY

Remélem nem veszitek tolakodásnak, hogy a dialógusotokba beleszösszenek egy kicsit!

Tetrának annyiból igaza van, hogy lehet egy nyelvet jól tervezni (főleg, ha van előtte példa, amin lehet tanulni) és lehet rosszabbul.
A java előtt igazán jó nyelvek nem voltak, tehát nem volt olyan nagy merítési lehetősége.
A java kifejezetten jó nyelv (volt), és még jobb is lehetne, csak hát a fejlődése kicsit lelassult.
Tetrának viszont abban nincs igaza, hogy attól, hogy van egy jobb nyelv (egyesek szerint), attól a másik nyelv sz@r.

Hadd hozzam ide a Scala-t, ami rengeteg nyelvet vehetett példának és igen jó érzékkel lett megtervezve. Mégsem mondom, hogy a C# sz@r, mert jobb nála a Scala.
Ott például van operator overloading, miközben nincs is operátor :) Jó mi?!
Ott az operátorok is metódusok, minden objektum, nincsenek benne primitív típusok, ...
A nyelv magja nagyon kicsi. A hozzárakott library-któl lesz bámulatosan nagy tudású, és ezt akár saját library-kkal is saját ízlésünkre állíthatjuk.
Szóval a Java egy jó nyelv, a C# egy kicsivel jobb, de a Scala messze a legjobb.

Nem veszem tolakodásnak, ha meg még velem is értesz egyet, akkor különösen :) (legalábbis valami hasonlót akart az előző jelenteni, de lehet már túlságosan este volt :) )

A Scala-t meg már itt többet írtátok, valamikor részletesebben is meg kéne már néznem.

BlackY

A Java előtt nem voltak jó OLYAN nyelvek. Ez a kulcs a következő részhez is: a Scalaval összehasonlítani azért baromság, mert nem a Javaval áll pariban. Más típusú nyelv, ellentétben a C#-al, ami teljesen olyan alapötletre épül, mint a Java, csak a framework más. És a C#-hoz képest a Java igenis szar, olyan nincs, hogy egy nyelv kontextus nélkül létezik.
----
India delenda est.
Hülye pelikán

A C#-hoz képest a Java-ban kevesebb nyelvi elem van. Más API-k vannak a hozzá tartozó framework-ökben. Ettől még a Java nem lesz "igenis szar", legfeljebb "igenis más" vagy "igenis kevesebb nyelvi elemet tartalmazó".

Ha a nyelveket te aszerint sorolod jó - szar kategóriákba, hogy milyen elemeket ad, az a te hibás hozzáállásod, mert vannak ennél fontosabb dolgok. Mint például hogy önmagán belül konzisztens legyen (lásd: PHP). A saját definiált követelményeinek (Java esetében: platform-független, visszafelé kompatibilis, már régóta közösségi módon fejlesztett, elsősorban vállalati szoftverek (akár mobile (ME), desktop (SE), akár web (EE)) fejlesztésére képes nyelv/technológia. C#/.NET esetén a "szoftverek fejlesztésére képes nyelv/technológia" az, ami meg is állja a helyét) megfelel-e. Megfelelő eszköz-támogatás van-e hozzá (nem csak fordítók, kódelemzők stb.) de legalábbis készíthetőek-e hozzá [már ha a saját definiált követelmények alapján erre szükség van]. Mennyire tanulható (Brainfuck: 30 másodperc). Mennyire egyszerű használni (Brainfuck: élet is kevés).

És akármeddig folytathatjuk még (jó troll vagyok, nem adom fel), elfogadom a véleményed, hogy neked jobban teszik a C#, csak azt nem, hogy azért, mert van egy másik nyelv, ami szerinted jobb, a másik már csak szar lehet. Személyes preferencia alapján ne tegyél objektívnak beállított állításokat, legfeljebb azt állítsd, hogy "szerintem rosszabb".

BlackY

Miután a java és a .net nem kis részt hasonló feladatkörre lett tervezve, szerintem meglehetősen jól összehasonlítható.

PHP-t meg bármiféle konzisztenciát egy mondatba rakni meg a rossz vicc kategória.

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

A PHP ott mint rossz példa akart szerepelni, ezért előtte a "lásd: " (annak ellenére, hogy szerintem kényelmes használni, ha minden faszságát ismered). És továbbra is: nem azt vitatom, hogy összehasonlító, össze is hasonlítottuk, megállapítottuk, hogy nyelvi elemekben a Java valódi részhalmaza a C#-nak, csak azt írom már le többedszer, hogy ez legfeljebb egyéni ízléstől függően jelenti azt, hogy rosszABB, mint a C# (azt, hogy objektíven szar, továbbra sem). Merthogy ezen logika mentén pusztán azzal, hogy létezik a C++ a C#-nak is objektíven szarnak kéne lennie, mert utóbbiban pl. nincs Turing-teljes template-zés, de hát másik nyelvben van és ezért amiben nincs az már csak szar lehet. Objektívan. Mindenkinek.

Projecthez, feladathoz, csapathoz kell platformot választani. Ennyi.

BlackY

C++ egy egész más pályán evez.

Ellenben c#/.net vs java:
- propertyk hiánya
- delegáltak hiánya
- linq és társai
- extension methods
- operator overloading
- csomó parallel jóság
- closure-k és nem túlbonyolított helyi interface implementálások (csomó plusz szeméttel a kódban)
- talán a .net fw valamivel letisztultabb (igaz, ehhez hozzátartozik az is, hogy kevésbé koros)

java:
- hotswap (amit nem értek, miért nem koppintották le egy az egyben, hisz elvileg az infrastruktúra adott hozzá)
- platformfüggetlenebb

Csak pár dolog így pro/kontra érvben.

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

- property: syntatic sugar a getter/setter metódusok helyett.
- delegate-k: jogos.
- továbbra is hitvita, hogy kell-e/lehet-e egy-egy API-nak saját nyelvi kiterjesztés létrehozni
- extension methods: syntatic sugar (és mondjuk én köteleznék mindenkit IDE használatra, azzal nem gond azonnal megtalálni, hogy a meghívótt metódust éppen melyik három névtérrel arréb levő osztályban definiáltad)
- operator overloading: talán most negyedszerre ebben a topicban: ritka esetben nekem is jól jönne.
- csomó parallel jóság: ?
- closure: már a 7-esben is kellett volna lennie, 8-ra már megint nagyon ígérik. (A csomó szemetet meg azért a C#-os IDE generálta kódokról is el lehet mondani)
- letisztultság: fejlődik ebben is a Java, csak backward compat miatt sokáig csak Deprecated a "régi szemét" osztály/metódus és kell egy pár kiadás, mire kidobják.

java:
+ nagyobb 3rd party kódbázis
+ egymással konkuráló (és így dinamikusan fejlődő) kapcsolódó szoftverek (alkalmazás-szerver, webszerver stb.), Google nélkül pl. az Apache+Mono párosításos mókán kívül nem tudnék IIS-en kívül másik .NET-képes webkiszolgálót mondani
+ közösségi, nyílt fejlesztés (lásd a Silverlight-ot, tudom hogy még támogatott stb., de mint cég az MS megteheti, hogy kihátrál belőle úgy, hogy egy hosszú support idő után egyszerűen eldobja, bár lehet, hogy openszósszá téve lenne olyan, akinek jobban megéri vinni az SL fejlesztését is mint migrálni az abban készült cuccait)

De akkor mégegyszer: igen, szép és jó nyelv a C#, vannak hasznos kiegészítései a Java-hoz képest nyelvi szinten, lehet a két nyelv/platform közt Pro/Kontra érveket hozni, akár sorrendet is lehet felállítani köztük (ami nem lesz objektív, mert a felsorolt dolgok fele szürkezóna), de attól, hogy az egyik más/több/jobb, mint a másik, még nem következik, hogy a másik objektívan egy szar. De hátha kódban:

tetra állítása:

boolean c_sharp_good = true;
boolean java_good = !c_sharp_good; /* tekintve, hogy az érve az, hogy AZÉRT szar a Java, mert a C# jobb */

Amit próbálok megértetni:

double c_sharp_goodness = base_oop_goodness + java_goodness + some_enhancements_goodness - things_MS_fucked_up_according_to_ME;
double java_goodness = base_oop_goodness + java_goodness; /* a nem deklarált változók mind double-ök és tetszőleges, de jól definiált és konzisztens nagyságrendűek, adott személy preferenciájának megfelelően */

A fekete-fehéren kívül is van világ.

BlackY

- property: syntatic sugar a getter/setter metódusok helyett.

Mert ugye sokkal jobb a

private int _basz;
public int getBasz() {
  return _basz;
}
public void setBasz(int value) {
  _basz = value;
}

a trivialis esetekben, mint a

public int Basz { get; set; }

Arról nem is beszélve, hogy ha refactoring kell, külön vannak csoportosítva és egyébként is élmény, hogy getFoo() meg isFoo()-ra is figyelni kell, ha boolean.

"- extension methods: syntatic sugar "

Akkor te nem ismered, hogy mire jó az Extension method. Nem picit tudja produktívvá tenni a munkát az, hogy egy-egy interface-t bővítesz vele (akár generikusat!), nagyon jó példa erre a LinQ. Mennyivel jobb minden egyes gyűjteményre megírni ezeket mind.

"- csomó parallel jóság: ?"

lock statement, Interlocked osztály, Parallel osztály (parallel foreach, parallel for), Task thread, Async, stb. Vagy most a C#4.5-ben rebesgettek még sok-sok mindent a parallel linq-ról meg valami részleges actor modellről, de ismereteim kb. a C#4-ig terjednek és ezen a téren egyébként is hiányaim vannak.

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

Igen, rövidebb, aminek sok előnye van. Ettől függetlenül továbbra is fenntartom, hogy szerintem nem több, mint syntatic sugar. Mindkettő (*). Mert nem kell minden egyes gyüjteményre megírni, egyszer kell egy osztályba statikus metódusként megírni, aztán azt hívogatni, átadva paraméterként a tényleges példányt. Tekintve hogy C#-ban is erre fordul le, syntatic sugar.

A parallel jóság osztályoknak utána kellene olvasnom, hogy érdemben hozzá tudjak szólni.

De továbbra is: NEM azt vitatom, hogy vannak-e a C#-nak/.NET-nek érdemei (fentebb pont erről győzködöm Csab-ot), bár szerintem túlságosan bloated, azt vitatom, hogy azért, mert más érdemei vannak, mint a Java-nak, a Java-t még nem lesz - tetra szavával élve - szar.

BlackY
*: A propertyk annyiból nem, hogy pl. reflection-nel látszik a különbség a kettő közt, legalábbis gondolom nem jelenik meg az osztálydefinícióban, mint metódus, csak mint a property settere.

Nézd SzBlackY,

én már 5 évvel ezelőtt elkezdtem a C#-pal játszani, még abban az időben, amikor monodevelop alatt debuggolni sem lehetett, hanem Console.WriteLine-nal ment minden.

Utána írogattam ezt-azt, várva, hogy talán egyszer végre megjavul minden és beindul. Azóta elmúlt 5 év, minimális előrelépés volt, átütő eredmény nincs (na jó, tudsz debuggolni). Kicsit olyan a helyzet, mint a WINE körül, ma már a Windows 2000-es programok mennek.

A Mono hellyel-közzel döcög, Miguel de Icaza csapatának arra van kb. ereje, hogy próbálja követni az MS változtatásait, de mondjuk egy WPF implementációra, vagy rendes fejlesztőkörnyezet kiépítésére nincs sem energia, sem pénz.

Komolyan nem is értem, hogy a Novell hogy bírja anyagilag a Mono-ablakon szórni kifelé a pénzt, amikor két kezén az ember meg tudja számolni a Linux mono alapon futó projektjeit. Ha véletlen elfelejted telepíteni, fel sem fog tűnni...

Elég fals érv a C#/.NET-tel szemben, hogy a mono szar, ugye ezt érzed? Nem mindig követelmény, hogy valami linuxon is menjen, akkor pedig előveszel egy Windowst, egy Visual Studiot, és örülsz.

Az okostelefonok 60%-a Android és egy java származék (dalvik) fut rajtuk.
A C# részesedése a telefonok piacán gyakorlatilag semmi.

Az asztali gépeket szorítják ki az ilyen-olyan tabletek, okostelók, célgépek.

Ezeken a java elfut (kivéve az MS termékeket), a C# még csak nem is igény.
Az MS-nek észre kellene vennie, hogy nem 1990 van, a platformfüggű szarokra a világ már nem kíváncsi.

Oké, elfogadom, hogy nem találtál az igényeidnek teljesen megfelelő libeket/toolokat az adott platform egy alternatív implementációjánál, ezért neked nem tetszik a C#.
Oké, elfogadom, hogy saxus-nak és tetra-nak nem tetszik, hogy a Java nem ad olyan nyelvi eszközöket, amiket a C# igen, ezért nekik nem tetszik a Java.

Ettől még a nyelv nem szar, a platform nem szar, egyszerűen a te/ti elvárásai(d|tokat) nem teljesíti teljes mértékben (és elfogadom, hogy akár a használt elnevezési konvenciók is lehetnek ennek oka, lásd BaT lentebbi hozzászólását).

BlackY

Azért az nagy előny ám, hogy a property refactoringkor propertyként látszik, és nem getter/setter metódusként. Ugyanis az, hogy egy getter metódus neve get-tel kezdődik, csak konvenció. Én pl. nem szeretem a kisbetűs metódusneveket, ezért ha magamnak programozok akkor javaban is lehetőleg nagybetűvel kezdem a metódus nevét, getterek és setterek esetén is, pl. GetFoo(). Csakhogy ha ezután olyan libet használok, ami refactoringgal akar bizonyos attribútumokat lekérni, az getFoo()-t fog keresni és szépen el fog hasalni. Propertyknél nincs ilyen probléma, ott pontosan olyan nevű propertyt fog keresni, amit én adok meg, max akkor fog elhasalni ha elgépeltem a nevét (WPF-fel bele lehet ilyenekbe futni, a legjobb hogy nem is szól érte).

Smalltalkban legalább (és as amik eleget nyúltak tőle - Ruby talán...) nem jelent gondot implementálni - ha valaki igényli - a fenti:
10+"12" == 22
"10"+12 == "1012"
Implicit típuskonverziós példát... :)

Egyébként nekem is nagyon szimpatikus nyelv, de vannak akik szerint épp részben a szabadság (monkey patching stb..) miatt idővel átláthatatlanná váló rendszerek rontottak pl. a renoméján . (talán ebben is van erről szó: http://www.youtube.com/watch?v=YX3iRjKj7C0)

"It is interesting to see what is being done out in the world under the name object-oriented. I have been shown some very, very strange looking pieces of code over the years, by various people, including people in universities, that they have said is OOP code written in an OOP language—and actually I made up the term object-oriented, and I can tell you, I didn't have C++ in mind.
—Alan Kay, Smalltalk co-creator,"

Stroustrupban azt szeretem, hogy leszarta az akadémikus balfaszokat, mint pl Alan Kay, noha valószínűleg tiszteli őt a munkásságáért, és a C++ sokat merít mindenhonnan, de nem lesz használhatatlan, elméleti nyelv.

Amúgy nagyrészt unrelated, csak eszembejutott.
----
India delenda est.
Hülye pelikán

+1

Szereted Stroustrupban, hogy felhasználja valaki eredményeit úgy, hogy tiszteli a munkásságáért és ezzel létrehoz egy de facto ipari standardot, de az az ember, akinek a munkásságát felhasználva hozta ezt létre (még azzal együtt is, hogy ipari felhasználásra talán tényleg először alkalmasan) egy balfasz (amúgy annyira imádom ezt a hozzállást is, hogy a közvetlenül nem feltétlenül hasznosítható eredményeket felmutató kutatók mind balfaszok, akik viszont rájuk építkezve csinálnak valamit (óriások vállán, tudod), ami bejön, azok istenek). Hm.

BlackY

Nem, a kutatók önmagukban nem balfaszok. Akkor lesznek balfaszok, ha utána rinyálnak, hogy hát úristen ők nem ezt akarták. Az ipar ezt akarta.
----
India delenda est.
Hülye pelikán

Off, de amennyit tudok róla az alapján nekem Alan Kay is nagyon szimpatikus.

Az az elköteleződése, hogy a számítógép használat legyen maximálisan kreatív, alkotó tevékenység a "közemberek"-nek is - és ne pusztán passzív tartalomfogyasztás - és az ennek érdekében végzett oktatási erőfeszítései alapján Kodályra emlékeztet... Jó hogy vannak ilyenek még ha az iparnak a tartalomfogyasztás is az elsődleges szempont. (praktikussági/termelési okokból, abból is: "a minél többen minél kevesebb félét" irány a legkifizetődőbb ugye)

(Szegénynek szerintem már-már fizikai szenvedést okoz, hogy olyan eszközökkel amik "kreativitási potenciálja" az ő fiatalkorában még elképzelhetetlen lett volna, ma már csak deklaráltan fogyasztásra kihegyezett windows 8 csempéket futtatnak. ;)

Elmagyarázom, mert tudom, hogy kell (hiszen már elsőre sem értetted): azt kértem, hogy az olyan jellegű öncélú kijelentéseid, hogy "Hülye döntés volt", támaszd alá. Nem tetted.

Látszik, hogy értesz valamennyit a témához, de az is, hogy itt nem vagy vitapartner.

Azért a Java sem szintaktikai kánaán... Gondolom nem kell az enum bonyolultságát bemutatni, de ez talán nem annyira ismert:
int i = 3;
i *= 2.5;

Meg tudod mondani, hogy mi történik? Fordítási hiba? Warning? Lefordul és a i értéke 7, talán 8? Esetleg 6, vagy 9? C#-ban? Mi volt a tipped mielőtt lefordítottad?
De természetesen az új dolgok is hoztak szintaktikai ,,bonyolódást'', például a számok csoportosítása _ jelekkel, de a többszörös catch sem feltétlen az egyszerű dolgok mintapéldája. (A checked exception-ök is inkább a bonyolultságot reprezentálják, hiszen egyféle effect-system-et takar.) Az anonim osztályok szintén bonyolultnak hathatnak a kezdőknek, vagy C# fejlesztőknek, hisz lényegében azok a closure-ök (Java 7-ig bezárólag) elég terjedelmes szintaktikával. Ami érdekes lehet, hogy viszonylag intuitíven oldották meg ezeket, együtt lehet élni az itteni bonyolultsággal, meg lehet szokni, némelyiket ki lehet találni.

Félre ne érts, nem azt mondom, hogy ez mind rossz, vagy a C# butább lenne. Mások, máshol bonyolultabbak. (Nekem mindkettő jól használható, mégis inkább a Scala a szimpatikusabb.)

(Ui.: Remélem nem vétettem hibát, kissé hosszú volt a nap.)

Én javaban fordítási hibára (loss of precision) gondoltam, de meglepett, nem ez van. 7-et ír ki. Természetesen nem hagyott a dolog, kipróbáltam i = i*2.5-tel is, itt bizony hiba van. Na az, hogy ez különbözik, kicsit tényleg confusing.
C++-szal (gcc) mindkét verzió lefordul, 7-et ad eredményül. Haskellban nem fordul (a szorzás, *= hiányában, ugyebár pure)

Értem, hogy a mondandód az, hogy azért a java sem lett túl egyszerű, a példáid valóban alátámasztják. Sőt én is ráteszek egy lapáttal, a 8-as, 9-es verziókban bejövő funkcionális elemek méginkább bővítik, bonyolítják a nyelvet.

A *= példád is jó, de az, hogy én nem tudtam, nem feltétlenül a nyelvet minősíti, hanem a tudásom.

Ha esetleg a miértre vagy kíváncsi. Egyébként hasonlóan gondolkodtam én is. És igencsak meglepődtem amikor egy refactor után (ahol a 2.5 érték előzőleg egy int változó volt és double lett) nem kaptam semmilyen hibát. Akkor úgy gondoltam, hogy itt valami nagyon nem stimmel.

Az existential types szintén elég bonyolult, még ha hasznos is néha. (Be kell valljam 3.5-ös C#-ban szerettem volna néha használni.) Az, hogy a tömbök kovariánsak (bocs, nem tudom mi magyarul a szakszó, remélem nem nagyon lőttem mellé) érthető kompromisszum volt a kialakulásukkor, de amikor a .NET bevezette a reified generics-eket, akkor C#-ban, VB.NET-ben ezzel leszámolhatott volna, hiszen úgyis többnyire inkompatíbilissé vált. (Az F#-nál mondjuk tanultak belőle.)

Attól, hogy eladható(bbnak hiszed), még nem lesz jobb nyelv. Egyébként érdekes látni, hogy a .NET FW részét (WinForms - amely pont van Monora is) és mindenféle 3rd party izét (GTK#, QT#) fikázod - amely közül egyébként egy sem a C# része -, miközben a valóban platformfüggő WPF-et (ahol tart jelenleg a .NET világ idestova sok-sok éve) meg se említed.

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

A WPF nem opció, miután életem 2/3-át Linuxon töltöm. Nem fogom platformfüggő megoldásokkal szopatni magam. Programozni akarok, nem pedig Windowst használni.

A java erre a célra tökéletes. A C#-ot pedig kizárólag a platformfüggetlen értelmes GUI hiánya miatt vetem el. Ha az MS megerőltetné magát és előállna valami használhatóval, akkor talán én is váltanék, de addig hanyagolom.

try-with-catch, AutoCloseable. Java 7-ben már ezek is vannak :)

BlackY

comparator? Hümm?
--
unix -- több, mint kód. filozófia.
Life is feudal

Jajj, bocsánat, én azt hittem, hogy a Property == tagváltozó, de mint lejjebb olvasom és utánagugliztam, nem :)

Amúgy nem néz ki hülyeségnek.

Nem feltétlen nagybetűvel kell kezdődnie a property nevének IMHO.
--
unix -- több, mint kód. filozófia.
Life is feudal

.NET Elnevezési konvenció. Osztálynevek, függvények, propertyk, enumok, névterek, stb. PascalCase, mezőnevek _camelCase (általában szokás elé egy _), statikus mezők meg s_camelCase.

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

Ne keverjük a szezont a fazonnal, a System.Collection.ArrayList az nem java.lang.ArrayList és az egy IList, ami IEnumerable, ICollection :)

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

Ne keverjük a szezont a fazonnal, java.util.ArrayList ;)

BlackY

Bocs, igaz. Látszik, hogy csak nagyritkán Java-zok. :)

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

Te agyad szísárpra jár :)
Bocs, én a java.util Collectionsra céloztam :P
1.4-es javaig nem volt generic. Akkor Object-eket lehetett a coll.-ba tenni.
--
unix -- több, mint kód. filozófia.
Life is feudal

Az a gond, hogy bármikor beesik egy kevésbé felkészült programozó, aki szétqrja az egész kódot, vagy van, hogy kiderül, hogy a nagyon felkészült néha mégsem annyira,
és ezzel nem csak magát, hanem másokat is megszivat. A magam részéről maradok az erős statikus típusosságnál, az a biztos. Igy is lehet eleget szívni, de jobb, ha
fordítás időben meg tudom fogni a problémákat, mintha futási időben kell szívni vele.

A "kevésbé felkészült programozó" is egy környezet. A környezet bármiféle megadása nélkül, nem lehet megmondani hogy a típusosságnak milyen erőssége a legjobb. Mert nincs is ilyen. Annak volt igaza, aki azt mondta hogy "right tool for the right task". Nehogymár java-ban írjak meg egy programot ami cron-ból adatot fog menteni. Miért dolgoznék vele 1 órát, mikor meg lehet oldani 1 perc alatt? És megfordítva: file system drivert nem fogok perl-ben írni (bár emlékeim szerint volt olyan aki csinált ilyet...)

Nehogymár java-ban írjak meg egy programot ami cron-ból adatot fog menteni. Miért dolgoznék vele 1 órát, mikor meg lehet oldani 1 perc alatt? És megfordítva: file system drivert nem fogok perl-ben írni

+1, ennyi

Diktatorok kezikonyve

Az a baj, hogy keverjük az adott programozási nyelv feature-jeit a típusossággal. Ez önmagában csak egy jellemzője a nyelvnek. Pl. ha bash-ban lenne típus, akkor annyival
lassabban lehetne kódolni?

++
Ez a vitaképtelenség. Bashben nem azért gyorsabb tűzfalat konfigolni, mert gyengén típusos, hanem mert bashes felülete van.
----
India delenda est.
Hülye pelikán

te tenyleg javaval esnel neki mondjuk egy faek egyszerusegu szovegfeldolgozashoz?

Diktatorok kezikonyve

olvasd el mégegyszer, hogy mit írtunk... nem egy adott nyelvről beszélgetünk, hanem az erős/gyenge típusosságról..

Az erős típusosság magasszintű nyelvet feltételez (legalábbis nem találkoztam alacsonyszintű szigorúan típusos nyelvvel).

Ha veszel egy 500Ft-os mikrokontrollert, amibe 2k program memóriát, 256 byte adatmemóriát belepakoltak, akkor a C ideális megoldás, mert a fordító a területnek csak 30%-át barmolja szét (rossz optimalizációval), de szerencsés esetben még marad annyi, hogy a programod beleférjen. A lefordított assembly-t megtekintheted a C fordítás végén.

Természetes, hogy ebben a környezetben a kasztolás, konstruktor, copy konstruktor,... ágyúval lövöldözés a verébre (bár C++-ban is lehet MCU-t programozni, de 95% a C-t használja, nem véletlenül).

Ebben a környezetben a trükkös programozás alapnak számít, bár jóformán típusok sincsenek, csak int8, int16, int32, int64.

Szövegértés?

Ugyan napi szinten csak scriptben és C -ben programozok, de rendes és betartatott típusok jól jönnének.

Egyetértek azzal, hogy a gyenge típusosság + erős programozó általában és leginkább csak gányolást csinál, több a kára, mint a haszna.

Itt azert megemlitenem, hogy 'weakly typed' != 'dynamically typed' && 'strongly typed' != 'statically typed', mert sajnos azt tapasztaltam, hogy sokan ezeket a dolgokat keverik. A kerdes azert is eleg ertermetlen mert most fejbol nem jut eszembe a PHP-n, VBScripten es a UNIX Shell-en kivul semmi ami nem 'strongly typed'.

pl.

C, C++, Java = statically typed && STRONGLY typed
Python, Perl, Ruby, JavaScript = dynamically typed && STRONGLY typed
C# = statically typed (with dynamically typed extension = "dynamic", DLR) && STRONGLY typed

...tehat mind STRONGLY typed!!!

A C-t speciel gyengén típusos nyelvként tüntetik fel a legtöbb helyen. Ez nem egy bináris tulajdonság, szóval nehéz meghúzni a határt, ezért is nem írják pl a C++-hoz hogy micsoda. Valahol középen van.
----
India delenda est.
Hülye pelikán

Nem a K&R C hanem a modern C.

Hát, ha már a C-be kötöttél bele, szerintem a Javascript inkább gyengén típusos (ott csak "var" van, nem int vagy char)

Na EZ nem releváns. Ez a dinamikus típusosság témaköre, hogy egy változó milyen típusú lehet.
----
India delenda est.
Hülye pelikán

Ebben van valami, hiszem lazán C-ben lazán lehet különféle típusú pointerek között castolni, sőt még a pointer <-> integer is elmegy egy warninggal.

Ugyanakkor C-ben biztosan nem fog az ember véletlenül integer <-> string konverziót csinálni, vagy ehhez hasonló dolgokat.

A string C-ben char[]. A char[] pedig legtöbb helyen char*-ként jelenik meg, tehát visszavezetve az int <-> pointer témára, de, simán csinál. Max el is hasal tőle.
----
India delenda est.
Hülye pelikán

Viszont épp az elhasalás miatt relatív könnyű észrevenni. Plusz a compiler figyelmeztet az esetek nagy részében.

Debugoltam en mar harom hetet ilyesmi miatt.

Csak alátámasztottam a korábbi állítást, hogy a C bezony a weak oldalon van a típuserősségi skálán.
----
India delenda est.
Hülye pelikán

A C-t szokták gyengén típusosnak is tartani (+ statikus típusellenőrzés persze), gondolom mert az átlagnál több implicit konverzió van benne, illetve a típusrendszer "megkerülhető" - abban az értelemben hogy pl. egy pointer castoláskor bármit mondhatok, hogy ott milyen típusú adat van, a C elhiszi - a többi erősen típusos nyelveben nem lehet ennyire vakon castolni

Szerintem a C 'strongly typed' csak nagyon liberalis ;) ha nagyon kell lehetseges (a C nem akar korlatozni), de egyebkent "alapjaban" = 'strongly typed'.

Hát igen, de a kiskapuk kihasználása azért nem ritka. Ha az egyik legelterjedtebb könyvtári függvénycsaládot vesszük példának a ..printf, ..scanf:
stringben kapja a típusokat aztán azt parse-olva értelmezi(vagy értelmezi félre) a paraméterlistáját - nem egy deklaráltan erősen típusos nyelvre valló megoldás

A C nem idealistaktol-idealistaknak hanem pragmatikusoktol-pragmatikusoknak fele nyelv. Es mivel a valosagban semmi sem feher vagy fekete akkor idealista szempontbol nem 100% 'strongly typed' de praktikus szempontbol igen.

Hát, azért a char * p = 112-t szigorúan típusosnak nevezni bátor dolog.
Az, hogy az intből pointert csinál, az kifejezetten durva, ezt még a PERL sem csinálja, pedig ott aztán tényleg nincsenek típusok.

Azoknak van igazuk, akik a kettő közé rakják a C-t.

Nem ezt mondtam? Abszolut (idealista) szempontbol 'weakly typed', de relativ (realista) szempontbol mar 'strongly typed' csak liberalis. ;)

Ez filozofia... nem lehet igazan jol valszolni a kerdesre, minden nezopont es velemeny kerdese, vagyis ez a fa nem terem gyumolcsot...

Perl olyannyira típusos, hogy a típus (scalar, list, hash table) része a változónévnek. Ugyanakkor a skalár sokmindent rejthet (szám, sztring, mutató).

Kezd érdekes lenni a téma.


main()
{
  char * p = 23;
  printf("%d\n", p);
}

Kezembe került ez: http://www.amazon.com/Expert-Programming-Peter-van-Linden/dp/0131774298/

Van benne egy szakasz ahol arról értekezik miért vezették be C-be típusokat amikor a B még típus nélküli nyelv volt (az ok h. a PDP-7 még nem támogatott wordön kívül más típust hardveresen szemben a PDP-11-gyel), a zárómondatot idemásolom, csak azért mert vicces:

"To this day, many C programmers believe that "strong typing" just means pounding extra hard on the keyboard."

Miért, nem azt jelenti? Lehet, hogy csak rosszul lett magyarra fordítva és mi tudjuk rosszul :)
--
unix -- több, mint kód. filozófia.
Life is feudal

JavaScript egész biztos, hogy nem gyengén típusos? Pl. Math.max(true, "42")

+1

Egy kis példán mutatnám be, hogy egy erősen statikusan típusos nyelv is rendelkezhet a gyengén típusos nyelvek előnyeivel.
Ez a nyelv a Scala.

A következő előnyöket nézzük meg:
1. Könnyű scriptet írni
2. Nem kell kiírni a típusokat
3. Automatikus típus konverziók

val xml = scala.xml.XML.load(dir + "sablon2_alap.xml")
val units = xml \\ "unit"
println("# of units: " + units.length)

1. A fenti kód scriptként futtatható, beolvas egy xml-t, leválogatja az összes unit elemet tetszőleges mélységben, majd kiírja ezek számát.
2. Nincs egyetlen típus sem kiírva, pedig használva az XML, Elem, NodeSeq (ez olyan mint egy lista), String és Int is van.
3. A kiíratáskor stringhez adunk (fűzünk) egész számot.

"egy erősen statikusan típusos nyelv is rendelkezhet a gyengén típusos nyelvek előnyeivel"

Csak megjegyzem ez a mondat megint részben a két elterjedt felosztás keverése. (statikus-dinmikus típusellenőrzés, erősen-gyengén típusos)

1. Az hogy ki vannak-e írva típusnevek, az inkább a statikus-dinamikus vitában lenne érdekes (feljebb írtam is, hogy szerintem az sokkal flame alkalmasabb kérdés lenne pont az ilyesmi példák miatt;), ezzel mondjuk a Pythonnak, Rubynak lehetne odamondogatni (mindkettő erősen típusos): "lám egy statikus típus ellenőrzésű nyelv amiben ritkán kell típusokat deklarálni - pont mint a dinamikusokban általában"

2. Statikusan típusos nyelv is lehetne gyengén típusos (lásd a "C milyen" vitát), a típusokról fordításidejű információ van(statikus), de az sokszor kikerülhető vagy csak warningot kapsz

Én most egy erősen, statikusan típusos nyelvnél hoztam példát. A maradék háromból én meg csak kettőt említettem [gyengén (statikus-dinamikus) típusos], mivel a topik alaptémája az erős-gyenge típusosság. Abban igazad van, hogy ez a példa még az erősen, dinamikusan típusos nyelvek előnyeit is hozza statikussága ellenére.

Könyörgöm, milyen előnyei vannak egy gyengén típusos nyelvnek?

Ok, C-nél világos: a hardverhez való közvetlenebb hozzáférés miatt van értelme.

Világos, hogy egy command line-ban nem akarok minden sztringet doublequote-ok közé tenni, így aztán a számok is sztringként lesznek leírva.

De ha magas szintű nyelven fejlesztek olyan kódot, ami hosszabb 10 sornál, mi jó sül ki a gyenge típusosságból?

Ezt miért nekem?

a gyengén típusos nyelvek előnyeivel.

Miféle előnyökről beszélsz?

Olvasd el már, hogy mit írtam! Én pont az erősen és statikusan típusos mellett érveltem, a Scala mellett.

Let me help you.

"Egy kis példán mutatnám be, hogy egy erősen statikusan típusos nyelv is rendelkezhet a gyengén típusos nyelvek előnyeivel."
"statikusan típusos nyelv is rendelkezhet a gyengén típusos nyelvek előnyeivel."
"gyengén típusos nyelvek előnyeivel."

Leírtad a kifejezést, tehát szerinted létezik. :)

Ha még egy kicsit továbbolvasnál, akkor láthatnád is, melyekről van szó.
"A következő előnyöket nézzük meg: ..."

var doc = XDocument.Load(Path.Combine(dir, "sablon2_alap.xml"));
var units = doc.Descendants("unit");
Console.WriteLine("# of units: {0}", units.Count());

Ezt nem csak a Scala tudja.

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

Ezt nem is állítottam. :)
Viszont azt megkérdezném, hogy ezen három soron kívül nem kell semmi más kód és script-ként futtatható?

http://scriptcs.net/
http://www.linqpad.net/

(Értelemszerűen nem árt néhány import/using. Az F# szintén kellemes scriptelésre.
Természetesen egy csomó mindent nem tud a C#/F# amit a Scala tud és fordítva is. Még Java-ban is akad olyasmi amit a .NET-es nyelvek nem olyan szépen/jól oldottak meg.)

De, kis körítés nem árt, viszont ha "scriptként" akarod, akkor PowerShell vagy fogsz egy LinQPad-ot.

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

...azért azt megkérdezném:

ha kidobnánk minden gyengén típusos nyelvet, pl. c, assembly (hogy csak a legalját említsem a fentiek alapján), akkor mégis milyen nyelven írnánk (természetesen főként mások) op rendszert, device driver-t, virtual machine-t és esetleg erősen típusos nyelveket, fordítókat?

....mondjuk javában? ;-)

és még egy labda:

Egyébként, ha mondjuk c++ használ valaki, akkor nem sok értelme van a fenti operátor trollkodásnak, ugye tudjuk miért?

Esetleg D-ben, Vala-ban. Biztos lehetne még sorolni.
Egyébként nem arról van szó, hogy ki kellene dobni, hanem hogy melyik típusosságot tartjuk előnynek.
A gyengén típusossága ellenére még jó nyelv a C, C++.

+1

Nyilván nem azoknak szólt akik kvázi helyesen gondolkodnak és úgy prezentálják a véleményüket.

Szerintem a C++ nem gyengén tipusos, inkább pragmatikus, de statikusan tipusos.

Ja, és a tipusokat nem mindig kell kiírni, attól még nem lesz gyengén típusos.
Pl.

std::list container;
auto iter = container.begin();

Itt nem irtuk ki a tipust, iter tipusa pedig std::list::iterator lesz.

Viszont:

int a = 12;
iter = a; // compile error

auto iter = container.begin();

Itt tulajdonképpen (ha kötözködni akarnék) kiírtuk a típust, amikor másutt deklaráltuk, hogy a container.begin() mit ad vissza.
Amúgy épp ideje volt ezt bevezetni a C++-ba. Tipikusan iterálásnál hasznos.

Ha a C-t kidobjuk, a Vala is megy vele. Vala... vele. Ez jó. Tetszik :)
--
unix -- több, mint kód. filozófia.
Life is feudal

Az, hogy jelenleg ez elterjedt nem jelenti önmagában azt, hogy ez feltétlenül jobb megoldás: http://en.wikipedia.org/wiki/Appeal_to_tradition
A safety critical világ mindenhová képes típusokat csempészni ;) : http://en.wikipedia.org/wiki/Typed_assembly_language

LLVM is egy típusos assembly-t használ.

És a JVM is.

gyengén típusosság.

Úgy vagyok vele, hogy

1) nem láttam még típuskeverésből eredő hibát production kódban (itt sokmillió JS és PHP kódról van szó, ismert, .com szoftverek alatt), úgy, hogy erre ritkán volt unitteszt. Ergo az egészet egy mítosznak gondolom.

2) A java-sok 90%-a a gyakorlatban akkor is HashMap-et és ArrayList-et használ ha nem az a célszerű. Ennél egy automatikus behelyettesítés (pl. CPython dict implementáció) sokkal jobb.

3) Az optimizer gyakran ki fogja cserélni a típusokat, de valamikor csak futás közben derül ki. Így ma már az erősen típusos nyelv se az.

4) régen a memóriamenedzsment nem volt nyelvi fícsör, ma már C++-ban is az. Az automatikus típusfelismerés is lehet az, sőt, vannak már erre vonatkozó gyakorlati megoldások (Google V8), és elméleti tanulmányok is (nem találom épp), bár még gyerekcipőben jár a dolog.

Mint ahogy a leszoktunk a kézi assembly-ről, leszoktunk a kézi memóriakezelésről (és mindig vannak és lesznek helyzetek amikor ezek kellenek, jól jönnek!), a compilerek és IDE-k fejlődésével a típuskezelés is egy "vannak határhelyzetek, amikor nem szabad bízni az automatikában de a mindennapi életben azt tesszük" eset lesz szerintem.

Az emberi agy sebessége nem változik. Se lassabb és türelmesebb nem lesz, mint hittük a web hajnalán, de szerencsénkre gyorsabb se. Persze ezt a java is mondta, csak nem volt igazuk (akkor és ott, 1.1 idején), de ha egy program 0.1 mp alatt válaszol az az embereknek mindegy, hogy 0.1 vagy 0.05.

Hát ezek nekem pl. (biztos szubjektív) nem tűnnek olyan ütős érvnek:

1) http://en.wikipedia.org/wiki/Anecdotal_evidence
2) Ha nem akarod teleszórni a kódot new ArrayList-tel használhatsz mondjuk DI-t
3) Ha pl. erre gondolsz: http://en.wikipedia.org/wiki/Liskov_substitution_principle + virtuális függvények = late binding, ez nem erős/gyenge típusosság hanem OO kérdése; így van ez az összes OO nyelvben - de pl erősen típusos funkcionális nyelvekben fordítási időben eldőlnek a típusok szerintem - és azzal is remekül együtt lehet élni
4) Az automatikus típusfelismerés jobban teljesíthet erős típusoknál: nem mellesleg ott már 35 éve volt olyan jó típusfelismerés amit egy gyengén típusos nyelv még ma sem hoz (azért ez az informatikában nem piskóta időtartam)
5?) 0.1s /0.05s nem számít, de pl. 1s / 0.5s a google kísérletében már 20%-os forgalomesést okozott: http://glinden.blogspot.hu/2006/11/marissa-mayer-at-web-20.html - lehet persze azt mondani, hogy egy lassabb nyelv legalább rákényszerít hogy ne fejlessz bloatware-t de valahol ez kicsit kifordult logika számomra

Erre csak idézni tudok (innen: https://www.coursera.org/course/progfun):

"What is the coolest thing I'll learn if I take this class?
Write elegant code that works the first time it is run."

A legmegdöbbentőbb, hogy _tényleg_ így van, tulajdonképpen ha lefordul a programom, akkor általában elsőre működik (és _jól_, vagyis azt csinálja, amit én elképzeltem). Ez egészen nagyszerű érzés.

Scala előtt Pythonoztam is (csak hogy a Perlt messzire el tudjam kerülni), jópofa volt, de Scalában legalább 1 nagyságrenddel produktívabb vagyok.

Azért majd ha egyszer sok időm lesz, kipróbálom a Clojure-t is, hackelésre mégis csak az való :-)

Dehát a Python erősen típusos...
----
India delenda est.
Hülye pelikán

de dinamikusan, ez a gond...

Igazad van, a statikus vs dinamikus típusokra koncentráltam, holott az eredeti kérdés nem erről szólt. A Python rossz példa. Viszont a véleményem hatványozottan változatlan :-)