[Foto] minden proci minden nyelven

[dMT alias Medve]

>> Ezért kell a lehető legkevesebb bizonytalanságot belevinni.
>> Ismeretlen, külső eszközök, alvállalkozók mind kockázatosak.
> Szerintem meg alapesetben bármely saját kód ezerszer kockázatosabb
> bármely elterjedt nyelv sztenderd könyvtárainál.
_Általánosságban_ nem értek egyet, vannak ez ellen ható tényezők is,
amelyek lehetnek erősebbek is. Például:
* Milyen minőséget akarok elérni?
  A saját kód olyan minőségű, amennyi munkát, időt belefektettek. Ha
  nekem csak egy kísérlet kedvéért kell egy funkció, akkor
  összebarkácsolom fél pillanat alatt. Lehet, hogy rosszabb minőségű
  lesz, mintha fél év keresgélés után megtalálnám a tuti könyvtárat,
  de hamrabb megvan.
  Fordítva is igaz. Ha én nagyon jó minőségű kódot akarok, akkor
  lehet, hogy a sztenderd kód nem elég jó nekem. Például a legjobb
  tudomásom szerrint a Linuxot CERNben SIL2 minősítésig sikerült
  elvinni. Ha nekem egy SIL4-es biztonsági szintű oprendszer kell,
  akkor nem használhatom a Linuxot, mert hiába elterjedt, hiába fut
  milliónyi példány, hiába fésültek ki belőle szinte minden hibát, még
  mindig több van benne, mint nekem kell.
* A sztenderd kód az univerzális. Az én céljaimre épp soha nem jó,
  csak kompromisszumokkal. És sokszor nem megengedhetőek ezek a
  kompromisszumok.
* Ha meg nagyon okos, nagyon univerzális a szenderd kód, akkor krva
  bonyolult. Rettentő erőforrásigányes.
* Az okos sztenderd kódnál a leggyakoribb hiba a hibás használat.
  Merthogy ha én magam írom meg funkcionalitást, akkor az a "véremben
  van". Ha viszont egy bonyolult "beépített" osztályt használok, akkor
  a fene tudja, hogy mi is az ötödik paraméter és vajon felszabítja a
  memóriát, vagy nekem kell, stb.
* Just for fun!!!

>> > > Én meg látom a memóriát, ott vannak a rekeszek, bennük érték,
>> > > mellette(!!) a programkód 40-80 tökéletesen ledokumentált utasítással.
SG>> Már elnézést, de ez 100% eszköz, 0% feladat. :-P
>> A programkód oldja meg a feladatot, a dokumentációja írja le!
> A feladatban se rekesz, se memória, se programkód nincs, pláne az utóbbi
> helye nem érdekes. Implementációs kérdés mind, annak is a lehető legalsó
> szintje.
Hát nem teljesen. Mert csak az látja át a problémát, csak az tud
hatékonyan dolgozni, aki a tetejétől az aljáig látja. Az én feladatom
az implementáció. Mi az implementáció? Megfeleltetés a feladat
fogalmai és a bitek között. Ezért kell látnom mind a kettőt. Aki csak
biteket és integereket lát, az nem jó. De az sem jó, aki csak
menetrendeket és vonatokat lát.

>> C-hez nehéz fordítót csinálni.
> Szerinted... :)
Viszonyítva egy "tisztességes" nyelvhez.

>> Nehéz, mert matematikai értelemben nem (illetve csak erőltetéssel)
>> nyelv.
> Éppúgy Chomsky 2. osztályú formális nyelv, mint a legtöbb programnyelv.
Mondok egy példát! Egy rendes nyelvben ahol utasítás áll, oda tehetek
{utasítás; utasítás}-t. A C-ben nem, mert pl. a for()-nál nem írhatok
oda összetett utasítást. Tehát az "utasítás" lexikális egység
feldolgozóba nem tehetem bele, hogy, ha {-t lát, akkor hívja meg magát
rekurzívan }-ig.
De ott van a castolás is. Más a szintaktikája, mint egy függvénynek,
csak úgy a vicc kedvéért. Egyszer csináltunk egy programnyelvet,
amiben minden tpíushoz (A júzerdefiniáltakhoz is!) automatiusan
létrejött egy konverziós függvény. Tehát az természetes, hogy ha van
integer típus, akkor van integer() függvény is. (Pontosan overloadolt
függvények, mert van integer(float), integer(char), stb. függvény is.
És nem úgy kell leírni, hogy a=(integer)2.5*4, hanem úgy, hogy
a=integer(2.5*4); Micsoda különbség!

>> Ezen kívül a C egy nagy halom függvény, ami nem más, mint a
>> processzor utasításkészletének kiterjesztése.
> Mondjuk így felfogva minden program a processzor utasításkészletének
> kiterjesztése. Mondtunk ezzel valami értelmeset? Baj ez?
Nem, ez szükséges. De az viszont baj, hogy ez a kiedészítés egy 30
évvel ezelőtti buherátortechnikát tükröz. Például a sztringkezelés,
stb.


>> Tragikus sztringkezelés.
> Ezzel vitáznék, szerintem a C ebben igenis kifejezzetten jó.
> Nézd meg pl. a Javát és csodálkozz... :)
Igazad van, mindent lehet fokozni. Lefokozni.

> Ja kérem, ahol 1 user 1-2 programkája a terhelés, oda jegyzetfüzet meg
> ceruzahegyező kell, nem számítógép... :)))
CSak épp a feladatok általában 1 user 1-2 programkája. Mert a
számítógép olcsó, mindenben van egy számítógép. A DVD játszódban, az
autó ajtóban, a mozdonyon, a GPSe-nben. Sőt az asztali számítógép
előtt is egyedül ülök és egy agyam, egy szemem, egy kezem van egy
dolgot csinálok. Most például levelet írok.
Persze vannak gigantikus szerverek, oda más architektúra kell. (Én ott
sem az egy processzor teljesítményének fokozását látom értelmes útnak,
hanem a feladat elosztását. Nem feltétlenül úgy, ahogy manapság van a
több magos processzorokkal, de ez messzire vezetne.)

> Arra céloztam, hogy az OOP-t nagyon kevesen szeretik igazán.
> Momentán ezzel kell főzni, ez van...
Miért kellene ezzel főzni?
Miért kellene minden áldott nap, minden fogásra mélyen átitatott OOP-t
alkalmazni?
Differenciáljunk! Van amire hasznájuk, van amire nem.
Van ahol csak egy architektúrális alapelv, de van ahol maga a kódolás
is OP történik. Egyet kell kiverni az emberek fejéből, hogy az OOP,
(épp úgy mint sok más) nem csodaszer, hogy amire ráöntjük, az
meggyógyul.

--
dMT alias Medve