[Foto] minden proci minden nyelven

[dMT alias Medve]

>> Az én véleményem szerint a mai piaci helyzetben minden területen a
>> legjobbat kell nyújtani.
> Persze, csak hát régi mondás itt a listán, hogy nincs (és nem is lesz)
> "legjobb fényképezőgép". ADOTT SZEMPONTBÓL legjobb, az esetleg.
Vevő szemével nézed.
Eladó szemével nézve jobbnak kell lenned, mint a konkurenciának.
Ha a konkurencia 120ms alatt tudja, akkor Neked 99ms alatt kell.
Természetesen azonos áron.

>> Senki nem fogja megvenni tőlem a drágább,
>> hamarabb lemerülő fényképezőgépet csak azért, mert nekem könnyebb volt
>> kifejlesztenem,
> Bukfencezni méltóztatsz. :)
> Ha könnyebb volt kifejlesztened, akkor biza olcsóbb az a gép, nem drágább.
> Ha emiatt jóval erősebb (drágább) hardver kell bele, akkor összeségében kb.
> azonos árnál vagy, de előbb, kisebb kockázattal tudtad kihozni a cuccot,
> ami egyáltalán nem mindegy.
Ez nagyon sorozatfüggő! Nagy sorozatnál (és nagy sorozatról beszélünk
akár fényképezőgépről, akár villanyóráról van szó) jobban eloszlik a
fejlesztési költség.
Itt van előttem az RKV. ASM-ben írtam meg a programot, minden bájtot
vadásztam. Hogy elég legyen a kisebb (64kB) mikrokontroller, mert az
100Ft-tal olcsóbb. Várahatóan eladunk belőle 300000 darabot. 30MFt
nyereség az alkatrészen. Azért 30MFt-ért hajlandó vagyok ASM-ben írni!
Ott a mozdonyfedélzetink. (Azon csak a tápegység processzorában 256MB
memória van, mert olcsóbb a fejlesztés, ha minden kártyán ugyanaz a
keretrendszer van.) Abban egy 20eFt-s hardver van, ami Linuxot futat.
Számoljunk csak! eladunk belőle 1500 darabot. 30MFt a Linux alatti
hardver. Vajon megírnám a teljes feladatát egy 1000Ft-os
mikrokontrollerre 30MFt-ért? Hát, határeset.

> Igazából az lenne a kulcs, hogy mindent arra kék használni, amire
> való. Ehelyett mindenki megtanul szigorúan egy dolgot (lásd
> kalapács), aztán onnantól mindent szögként modellez...
Kedvenc mondásomat idézted!
Ezért jó cég a Prolan, mert sokféle technológia birtokában van és egy
új feladatnál el lehet dönteni, hogy milyen technológiával kell
megoldani és akkor annak a csapatnak adni. Mert azért egy villanyórába
nem szeretnék MB-okat, sok száz MHz-et, Linuxot, stb. Nem fér bele az
árba. Viszont az ELMÜ-ÉMÁSZ közös központi számítógépét nehezen tudom
elképzelni üres hardverre ASM-ben megírva.

>> > +: nagyon gyorsan készíthető modell/prototípus,
>> Szerintem a modell/prototípus nagyon veszélyes fegyver. Mert kivállóan
>> alkalmas arra, hogy egy ad hoc, nem megfelelő architektúra,
>> technológia megváltoztathatatlanul bebetonozódjon.
> Márpedig korai prototípus nélkül nincs agilis fejlesztés...
Kell korai prototípus, hogy definiálni lehessen a feladatot.
Hogy a leendő júzernek meg lehessen mutatni az UI-t. De a prototípus
felhízlalásának sok hátrányát tapasztaltam. Idekében kell tudni
kiszállni egy zsákutcából, nem három évi szenvedés után.

> Itt igazából a tudatosság lenne a fontos, mind fejlesztői, mind vezetési
> szinten. Azt kell jó előre, még indulás előtt rögzíteni, hogy egy ilyen
> fejlesztési folyamatban igen gyakori esemény, hogy architekturális
> főelemeket komplett kidob, újratervez majd újraír az ember fia, azaz a
> folyamat előrehaladása egyáltalán nem szig. mon...
Tökéletesen egyetértek.

> Ha ezek a lépések nem történnek meg időben, az a gányolás.
Igen.

>> Merthogy kellő mennyiségű szakértelem nélkül akármilyen technológiával
>> szenved a fejlesztő. Ha viszont átlátja, megérti a feladatot, akkor
>> szinte mindegy, hogy mi az eszköz, mert bármivel közel azonos
>> hatékonysággal dolgozik.
> Azért már na.
> Hány programozót ismersz, aki képes egy RT kernelt (a Te példád!)
> megbízhatóan, emberi időn belül összehozni?
Hármat biztosan. Persze ezek közül egynek a teremtményei sem közelítik
meg azt a tökéletességet, ami az enyémeket jellemzi...

> Aztán persze lehet, hogy nálatok csak ilyen ember van, de az egy
> nem mindennapi, és igencsak megbecsülendő kegyelmi állapot...
Sajnos 8 éve nem kamatoztathattam ilyen irányú képességeimet.
Akkor írtam az utolsó RT kernelt. Előtte átlag 2-3 évente szükség volt
egyre.

>> Egy javás fejlesztő az eszközre koncentrál.
>> Egy ASM fejlesztő meg a feladatra.
> Hááát...
Nekem ez a tapsztalatom. Nézem, hogy mit össze szenvednek a kollégák,
hogy vajon mit jelent, ha szögletes zárójelben leírják, hogy pont-pont
veszőcske és vajon mikor gyűjt szemetet, stb.
É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.

> Épp azért lettek kitalálva a magas szintű nyelvek jópár évtizede, mert
> egyértelműen kiderült, hogy bizonyos komplexitású feladat és hardwer
> fölött az ASM és vidéke teljesen kezelhetetlen az emberi agy számára.
Igen.
De
* Ez egy másik zsákutcába vezetett. Létrehoztunk olyan bonyolult
  keretrendszereket, amelyek tökéletesen átláthatotlanok az emberi agy
  számára. Jön a "patkánymódszer." Te figyelj, vajon mit csinál ez a
  program? Hát próbáld ki!
  Idézet egy belső levélből:
    Mit ir ki az alabbi program(ocska)?
     #include <stdio.h>
     #include <stdlib.h>
     #include <string.h>
     int main(int argc, char *argv[])
    {
     char *line  = "asdf:sfdgd;dfg";
     char *delim = ":;";
     char *token;
     token = strtok(line, delim);
     printf("%s\n", token);
     exit(EXIT_SUCCESS);
    }
  a. "bela vagyok"
  b. "asdf"
  c. "Memory fault"
  d. semmit
 És bizony kevesen tudták megmondani! Pedig ez egy 30 éves
 programnyelv! Egy bonyolultabb C++ program már igencsak nehezen
 uralható.

* Ezek az eszközök azért nem hoztak megoldást az általad felvetett
  problémára, mert az a baj, hogy maguk a feladatok bonyolódtak el
  annyira, hogy az emberi agy által átláthatatlanok.

* Persze, csak kötözködöm, alapvetően igazad van. Csak azt próbáltam
  érzékeltetni, hogy a dolog nem annyira egyszerű, hogy azzal nem
  lehet megoldani, de feltalálták ezt és azóta mindenki boldog.

> Hány műveleti egység hány regiszterét tudod fejben tartani?
Eddig max. 8 processzoros gépet csináltam.

> Átnevezés után is?
Nem szoktam átnevezni semmit.

> Az OOP egy következő lépés a komplexitás újabb dimenzióinak kezelésére,
> és biztos lehetsz benne, hogy nem az utolsó.
Egyetértek. Annyival kiegészíteném, hogy az én véleményem az OOP-ről
rosszabb, mint az átalagemberé. Valós tapasztalatalatokból
táplálkozóan. Egy picit jobb formalizmus, sok területen jól
használható, de sok területen több problémát hoz be, mint amennyit
megold. Saját véleményem, a saját területemről, hogy oOp-t kell
használni, vagyis szigorúan "orientált". Tehát objektum orientáltan
kell gondolkozni. De ez nem jelenti azt, hogy ezrével ontsuk az
iszonyú bonyolult osztályhierarchiákat. Egy adott komplexitás után már
nem áttekinthető. És akkor aztán olyan kérdésre, hogy mennyi idő alatt
is fut le nincs válasz. (Írtam már én is olyan C++ programot, hogy egy
kolégának két napjába kerlt, mire kibogozta, hogy vajon egy egyszerű
műveletnél vajon mi is fut le!)

> Persze ha a Te feladataid nagyon egyszerűek, akkor tán még egy
> rendesebb assembler szolgáltatásait se fogod kihasználni, semmi
> szükséged a felsőbbekre.
Nem, a feladataim nagyon sokrétűek. Jelemleg 24KB ASM kB oldja meg.
Napokig tudnám sorolni, hogy mit kell csinálni. (Több, mint 700
követelményazonosító van.)

> Na jó, de érted-e most magadat?
Igen.


--
dMT alias Medve