Hogy miért lehetséges gyorsabban fejleszteni azt nagyon nehéz hacsak nem lehetetlen így ripsz-ropsz elmondani. Kicsit olyan minha mondjuk én csak assembly-ben lennék otthon és anélkül, hogy ismerném a C++ nyelv elemeit és a fogalmak pontos jelentését, úgy kérdezném ugyanezt.
Hogy pár nyelvi dolgot említsek (bocs, de nem fordítom magyarra, mert nem nagyon lehet, de gondolom nem gond):
- lambda (anonymous function)
- functions as first class citizens (nem úgy mint a Java-ban) igazából minden legyen first class citizen, ami annyit jelent, hogy lehet változónak értékül adni, függvény paraméter, visszatérési érték, stb.
- closure (capturing lexical environment) nem keverendő össze az anonymous function-nel
- continuation (full mint pl a scheme-ben vagy delimited mint a CL-ben), CPS transformation
- higher order functions pl: (find x collection :key 'something :test 'egyenlo)
- __NO__ design patterns, ha design patterneket hasznalsz, akkor valami sulyosan hibadzik a programozasi nyelvben, amiben dolgozol. a design pattern az, amit a nyelved nem tud kifejezni, ezert neked kell repetitiv modon kovetned, ahelyett hogy a sziliciumra biznad, ami sokkal gyorsabban es pontosabban teszi ugyanezt
- multiple dispatch (pl: CLOS - Common Lisp Object System) a hagyomanyos single dispatch helyett a meghivott fuggveny nem csak az egyik (azaz a this pointer) parameteren dispatchel
- prototype based object systems (pl: Slate)
- MOP (meta object protocol, lásd CLOS, pl: constraint based change propagation http://common-lisp.net/project/computed-class csak hogy az egyik libünket említsem)
- kód=adat (ez a lispnél jobban sehol se teljesül)
- quoting and quasi quoting (pl: C++-ból C++ kódot generálni a legnagyobb halál (Java detto), nézd meg ugyanezt lisp-ben
- macro system (source code transformers) és itt nem a C++ macroira gondolok, mert az egy vicc
- runtime code evaluation and generation (compile és eval)
- embedding and mixing DSLs with the core language (regular expressions, pattern matching compiled to assembly)
- reflection and introspection (megfigyelés és beavatkozás, pl: milyen member-ek vannak egy osztályban és adjunk hozzá egy újat miközben a program fut)
- mixing programming paradigms in one language (functional, side effects, declarative, pl: egy lisp-ben irt prolog program compile time fordul CPS transzformációval assembly-re és nem interpretálva fut)
- REPL (read eval print loop) sokan nem is gondolnák, hogy ez milyen fontos, írod a kódot, aztán egyszer csak gondolsz egyet és meghívsz egy függvényt (amit éppen írsz mondjuk), hogy megnézd működik-e vagy esetleg az editorod folyamatosan mutatja, hogy a tesztjeid passolnak-e
- etc.
És még sok-sok apróság, némi angol nyelvtudással és a Google segítségével utána lehet olvasni a témának. Egy dolog fontos, amit nem ismerünk azzal nem is gondolkodunk, így könnyen lehet, hogy nem látjuk a lehetőségeket, másként fogalmazva az eszközök és a nyelvek amit használunk megvezetik a gondolkodásunkat.
Ez például egy Scheme bevezető. A Scheme az egy Lisp dialektus, vagyis nagyon rokon nyelvek: http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html
Ha kicsit programozni is akarsz schemeben, akkor a innen letölthető egy open source implementáció:
http://www.plt-scheme.org/
Vagy ha valami eclipse szerűbb IDE-re vágysz, akkor (bár ez elég alpha cucc, de jó irányba halad):
http://www.jazzscheme.org/
Vagy ott van például a Squeak ami egy Smalltalk nyelv aminek a virtuális gépét érdemes kipróbálni, hogy lásd mennyire másként is lehet gondolkodni (nem mondom, hogy jobban) Ahol a programok nem lefordított exe-k (hanem egymással kommunikáló objektumok) és ha egy mail-be belerajzolok egy vonalat, attól az még simán elküldhető úgy hogy az a levél törzsében van és nem pedig attachment.
http://www.squeak.org/
Egy másik tanulságos példa a Slate.
http://slate.tunes.org/
Vagy mondjuk __különösen__ ajánlom Paul Graham (aki szerintem ebben a témában egyszerűen zseniális) irásait:
http://www.paulgraham.com/avg.html
http://www.paulgraham.com/hp.html
szinte az összes többit.
Mi egyébként az SBCL, emacs, SLIME triót használjuk pár customizálással. Ízlések és pofonok, sokaknak nem tetszene azt hiszem. Én használtam már Visual Studio-t, Eclipse-t (forward/backward/roundtrip engineering-et, stb.) és sok egyéb IDE-t, de mégis határozottan egyelőre ez volt a legproduktívabb összeállítás. No nem mintha nem lehetne jobbat elképzelni...
Végezetül álljon itt egy idézet, amit megpróbálok pontosan idézni, a korábbi kollégától eltérően:
Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.
— Philip Greenspun, often called Greenspun's Tenth Rule of Programming[11]
levy