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

Programozás

az erősen típusosságot
43% (191 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
29% (130 szavazat)
nem értem miről van szó
19% (85 szavazat)
Összes szavazat: 441

( iron v | 2013. 05. 07., k – 08:55 )

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

( kanos_giliszta | 2013. 05. 07., k – 09:04 )

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

( enpassant v | 2013. 05. 07., k – 09:06 )

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.

( tetra | 2013. 05. 07., k – 09:24 )

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

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

( saxus | 2013. 05. 07., k – 10:08 )

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™

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™


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™

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.

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

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

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

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.

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

É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

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.

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_osszehasonlitasa…

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

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.

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

( uid_720 | 2013. 05. 07., k – 11:37 )

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

( uid_4656 v | 2013. 05. 07., k – 11:59 )

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

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

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.

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.

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

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<int, string>();

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™

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

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.

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

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

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™

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.

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

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.

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

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.

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

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

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

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

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

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

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.

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

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.

( egeresz | 2013. 05. 07., k – 13:51 )

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.

( aludanyi | 2013. 05. 07., k – 15:36 )

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

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

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

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.

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

( enpassant v | 2013. 05. 08., sze – 06:55 )

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?

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

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

( xzsolt | 2013. 05. 08., sze – 07:40 )

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

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

( Aadaam v | 2013. 05. 09., cs – 01:08 )

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