> Pl. az istenített C vagy Pascalban rengeteg hiby van.
En tiz eve programozok rendszeresen, es csak egyetlenegyszer fordult elo, hogy egy C-fordito hibas kodot generalt, azt is csak massziv optimalizacios beallitasok mellett. Ha valami nem müködött arrol elöbb utob kiderül, hogy a programozo hibaja. Mas kerdes, hogy a C-ben könnyebb hibas programokat irni, mint egy jobban tipusellenörzött nyelvben, mint a Pascal, Eiffel vagy OCaml.
En (ha megnezed a korabbi a hozzaszolasaimat, lathatod) nem istenitem a C-t, de az elterjedtsegnek, es hosszu piaci jelenletnek biztosan megvan az az elönye, hogy a forditok extrem stabilak.
Bocsi most csak erre reagálok, mert megyek el és csak a jövő héten leszek. Idegeskedj! Is. De windows alatt csak olyat ami ledögölhet. Egyébként azt hiszem soha nem mondtam, hogy csak windowst használok, sőt! Lehetőleg DOS-t, azaz a megfigyelőrendszereknél, amelyek ön működőek.
Ja még valami a teljesség igénye nélkül, mivel csak beleolvastam és nem végig. Nem hangsúlyozom a BASIC-et, hanem azt mondom, nincs kiemelkedően jó és kiemelkedően szar, vagy gagyi program nyelv. Pl. az istenített C vagy Pascalban rengeteg hiby van. És a jó öreg FORTRAN, gyors is és megbízható. Na egyelőre ennyit, majd ha megtjöttem a többit.
az ember azt gondolna, hogy aki 30 even keresztul rabirta a gepeket a sajat akaratara az o nyelvukon a magyar nyelvvel is megbirkozik hogy embertarsai megertsek...
eh, tudod mit, felteszek par kerdest az altalad irtakkal kapcsolatban, hatha megis sikerul kihamozni az ertelmet
>Nos a BASIC lassu
Melyik basic lassu es mihez kepest?
>a BASIC ... elég stabil
Mit jelent az hogy a BASIC stabil, es mi az ami ezzel szemben nem stabil?
>müködik is. De csak addig amíg valami miatt ki nem akad és nem az általam megírt program miatt, hanem mert bizonytalan
most akkor mukodik vagy bizonytalan? Ha bizonytalan, es nem a program miatt, akkor mi miatt? Es ha nem a program miatt bizonytalan, akkor miert nem mindegy hogy a program milyen?
>És qrvára kell szégyelem az ifjú titánok előtt: azért, hogy ne dögöljön le a program Basicban kell +írnom. Na ennyit a nyelvekről
Vagyis minden mas nyelven csak ledoglos programot vagy kepes irni, es ezt a nyelvek hibajanak tartod. Vagy mit akartal voltakepp modani ezzel a mondattal?
- ----
Es ha nem szereted az eloiteleteket, akkor miert irod a magad eloiteleteit alig ker sorral elotte?
Es en peldaul meg nem programozok 30 eve, de nem allok le dolgozni olyannak, akit nem erdekel, hogy a buli fog-e mukodni. Van eleg kokler, foglalkozzanak ok a szemettel. Vagy ha olyanban kerik, amirol tudom hogy alkalmatlan a feladat megoldasara.
Ettol meg te biztos szuper programokat irsz, csak szerintem ezt a BASIC stabilitas dolgot nem fejtetted ki eleg reszletesen, hogy -en legalabbis- megertsem.
legalabb az FFT-t vegzo rutint tuti, hogy C-ben, vagy netan assemblyben irnam, (vagy keresnek egy kesz libraryt) meg akkor is, ha nem abban irnam a teljes szoftvert. Bar a mai procikkal gondolom mar nem igazan szempont.
De csak addig amíg valami miatt ki nem akad és nem az általam megírt program miatt, hanem mert bizonytalan. Nos a BASIC lassú (ez ma már nem gond) de 30 éves tapasztalatom alapján mondhatom, hogy elég stabil. Nos, nem egeszen ertem, miert hangsulyozod a BASIC-et.
Ha nekem megbizhato mero-megfigyelo programot kellene irnom, gondolom eloszor az oprendszert dontenem el, ami elkepzelheto, hogy egy megbizhato real-time oprendszer lenne.
Ezutan kivalasztanam a programozasi nyelvet, es a hasznalt konyvtarakat. Fontos, hogy a konyvtarak stabilak legyenek, es ha valamifele interpretalt nyelvrol van szo, akkor a futtatokornyezet is stabil legyen. Ha nem interpretalt a nyelv, akkor a futtatokornyezet instabilitasa szoba sem johat, igy hat ha jol programozol C/C++-ban, akkor gondot csak az instabil oprendszer, vagy bugos osztalykonyvtarak jelenthetik.
Te viszont nem emlitesz sem platformot, sem azt, hogy milyen BASIC implementaciorol van szo, csak annyit irsz, hogy a BASIC (ami pusztan egy nyelv!) stabil, mas, nem megemlitett alternativakhoz kepest. Ezt igy ebben a formaban szerintem nehez ertelmezni.
Ezt a megjegyzésed nem értem, ki fikázott téged? A törpe? Legfeljebb te engem. No de az előző +jegyzésedre: én mérő-megfigyelő rendszereket készítek, amelyek különböző egységeket kezelnek. Ezeknek a programoknak rendkívül gyorsnak és megbízhatóaknak kell lenniük, mivel igen drága gépekre felügyelnek. Esetenként 100-200000 minta/sec-os sebesség mellett FFT (frekvencia analízist) kell csinálni. És persze közben mintavételezni, dönteni, irányítani, a többi géppel kommunikálni. Ha értelmezed azt hogy több programnyelven TUDOK programozni, az nem azt jelenti, hogy valami túrót összehanyálok, hanem, hogy az müködik is. De csak addig amíg valami miatt ki nem akad és nem az általam megírt program miatt, hanem mert bizonytalan. Nos a BASIC lassú (ez ma már nem gond) de 30 éves tapasztalatom alapján mondhatom, hogy elég stabil. Úgy érzem, te is azok közé tartozol, akik, ha nem cben van írva valami, akkor az már nem is program. Nos nem akarok snekit sem meggyőzni mi a jó és mi a rossz, csupán az előitéleteket nem szeretem, meg a nagyképű fazonokat. Találkozom a megrendelőim között is olyanokkal, akiket nem az érdekli működni fog-e dolog, hanem, hogy miben íródik. Nos abban kapják amiben kérik.
Bizonyára igazad van, és nekem nehéz a felfogásom, de még mindig nem tudom mi a válasz a (67)-ben feltett kérdésemre: Csak BASIC-ben lehet stabil programot csinálni, vagy csak BASIC-ben tudsz stabil programot csinálni?
Sziasztok!
Beleolvastam az elejébe is, nagyon teccik aszály gondolata.
Csak az a baj az agy számítógépként való m?ködésével, hogy vannak agyak, amik C64 szinten m?ködnek és ez még nem minden.
Náluk a normális emberek outputja az iput. :-)
Te amúgy tudsz olvasni? Vagy csak jártatod a szádat, illetve a kicsinyke ujjaidat. Mielőtt baromságokat írnál, olvasd el alaposan amire válaszolsz, mert nem csinálsz hülyét magadból.
Mit is kellene ebből megértenünk? Azt, hogy csak BASIC-ben lehet stabil programot írni, vagy azt, hogy te csak BASIC-ben tudsz stabil programot írni?
Off (Elég "fiatalos" a helyesírásod... ez kissé gyanús)
Szóval, immár 30 éve foglalkozom programozással. Ebből élek. Nem könyvelő programokat, henem real time mérő-megfigyelő rendszereket csinálok. Ebből aránylag jól meg lehet élni :)))))) hehe. Szóval szerénytelenség nélkül: bármilyen progit megírok, fortranban, cben, pascalban meg 1éb marhaságban. (én még tanultam és programoztam algolban, cobolban, PL1 ben). És qrvára kell szégyelem az ifjú titánok előtt: azért, hogy ne dögöljön le a program Basicban kell +írnom. Na ennyit a nyelvekről. Egy baja volt a basicnak, hogy lassú. pl ha 100000/sec mintás FFT kell csinálni, de ma már ez sem gond. Nos ezt mongya 1 embör aki ebből él és csak azt nézi mi a biztos meg tán nem is hüje hozzája. Sok olyan egyetemi oktató ismerősöm van (barátja a ráknak), aki azért tanít csak c-t mert az a menő, de egy normális programot nem tud megírni. Szóval a programnyelv túl van lihegve. Nem a nyelv a lényeg, henem amit vele nyalunk..... izé írunk. (elnyalás volt)
Szerintem a jövö programozasi nyelvet azert lehetetlenseg megjosolni, mert a most elterjedt nyelvek elterjedeseben sem azok minösege jatszott szerepet.
Szerintem a programozas törtenete soran elterjedt nyelvek kifejezetten vacakok:
A jövő programozói a vegyészek és a mikrobiológusok lesznek, a nyelv pedig a kémián, kvantummechanikán, valószínűségszámításon, esetleg neurális hálózatok elvén fog alapulni. Persze a hagyományos egzakt, bináris alapú programozás is megmarad, de csak egyre speciálisabb szerepekben, mint pl. napjainkban az elektroncsövek.
activer,
Egyébként az utóbbi évek nagy felfedezése, hogy az agysejtek (neuronok), úgyanúgy keletkeznek, mint a másfajta sejtek. Sokáig úgy tartották, hogy az agysejtekből nem keletkeznek újak, de ez - a mai felfogás szerint - nem igaz.
hol lehet tobbet olvasni errol az uj fellfogasrol es felfedezesrol?
"az objektumok és osztályaik közötti kapcsolatrendszer átalakul (összemosódik) megreformálódik, (héttérbe húzódik)" Lehet, hogy ez így egyszer (jó) lesz, de ahhoz az is kellene, hogy először az objektumok és osztályaik közötti kapcsolatrendszer (legalábbis a használók fejében) szétváljon, a különbségek világosan látszódjanak. Ez ma még sajnos nem feltétlenül jellemző.
(Lehet, hogy ebből is egy tézis-antitézis-szintézis jellegű folyamat jön létre?)
Igen szép dolgokat írtál. Nagyon is egyetértek veled.
A kritikám csak annyi volna, hogy - szerintem - az objektumok és osztályaik közötti kapcsolatrendszer átalakul (összemosódik) megreformálódik, (héttérbe húzódik). Valamint a sok-sok (féle) diagram közt előtérbe kerülnek a hagyományos vezérlés (szabályozás) technikai elemek és enne következtében kibővülnek a grafikai készletek.
Az ablak bezárásával (vagy megfelelő "nyomógombra") elkészül (automatikusan fordul és szerkesztődik) az objektum (kupac), mely máris futtatható. A kapott futtatható kód NewAgeAssembly-ben (nyomott objektumokon -kal) visszanézhető. Ez is assembly: a jellemzője pedig az, hogy logikus. Nem tartanám borzalmasnak sem a kódot, sem a struktúráját, sőt én büszke vagyok arra, hogy az "őskor"-ban használhattam. Arra, hogy a megoldások között válogattunk, és (az egyes utasítások órajel igényeit ismerve) futási sebességre optimalizáltunk, melynek eredménye képen fura elvadult kódokat, kaptunk. "Félre" és helyesen használtuk a környezet által nyújtott lehetőségeket és eszközöket. Egy példa. Feltöltésre az LDIR helyett (a lassúsága miatt) 16 v 32 db PUSH DE-t, egy DEC-et meg egy feltételes JR-t használtunk.
A korábban leírt észrevételezéseim alapján (l. 46-os) én úgy képzelem el, hogy a jövő programnyelve valójában már nem a hagyományos értelmezésű programnyelv. A hagyományos programfejlesztés - szövegbevitel, fordítás, linkelés - rég a múlté, bár álcázottan még jelen van.
A jövőben programtervező rendszereken fogunk programozni. A rendszer a legmesszemenőbbekig el lesz látva vizuális segédeszközökkel (azaz nagyrészt egérműveletek, minimális billentyűzéssel). A tervezés szinte minden folyamatát segíti és minden lépését dokumentálja. Azaz az egész nem más mint egy gigantikus egybeintegrált CASE rendszer.
A rendszer - hacsak valami újat megint ki nem találnak - teljesen objektumorientált. A lineáris szövegek helyett inkább hierarchikus - azaz fa - struktúrákba szervezetten találjuk meg a programunk elemeit. Tehát pl. az egyik oldalról: osztályokat hozhatunk létre, melyeket csomagokba csoportosíthatunk, majd a csomagokat is összevonhatjuk újabb csomagokba. Másrészt egy osztályt részletesebb formába is kibonthatunk. Láthatjuk az adatait, metódusait. Ha egy metódust boncolgatunk tovább: az a paramétereiből, a lokális változóikból és a "kód"-ból áll. Ám a kód is vezérlő szerkezetek sorozata. Ha akarunk, betekinthetünk egy ciklus belsejébe (ha nem, akkor el van rejtve), s azon belül is "kód" van. Tehát itt is navigálhatunk a fa szerkezetben. Bizonyos dolgok "link" szerűen működnek. Pl. ha a kódban egy metódus hívás van, átugorhatunk a metódus definícióra, és onnan böngészhetünk tovább akár egy felsőbb szintre (itt az osztály definicióra), akár egy alsóbbra (itt a metódus paraméterei, vátozói, kódja). A programozás részben nem más mint ezeknek a fa struktúráknak a fölépítése.
Egy objektumorientált programterv nagy része nem más mint diagramok sokasága. Mai tudásunk szerint ezek az UML diagramjai (használati eset, osztály, együttműködési, szekvencia, aktivitás, állapot diagrammok.) Ezek előállítása alapvetően a programtervezővel történik. Ezek azonban nem csak dokumentatív célokat szolgálnak, hanem forrásai a lefordítandó programnak. Némelyik a deklarációkat helyettesíti (pl. az osztálydiagramm), másnak pedig "kód" vonzata van. Ezek a diagrammok olyan dolgokat ábrázolnak, melyeket esetleg nem is lehet hierarchikus formába (fába) gyömöszölni.
A fentiek alapján leginkább a "kód"-nak nevezett részekben bukkanhatunk valami olyasmire, ami a régi nyelvekhez hasonlít. Ehhez főként a kifejezések képzési szabályait kell megtanulnunk, bár - ó mily borzalom - a kifejezések is ábrázolhatók fa struktúrában. Mindenesetre kell tudni a különböző operátorok jeleit, prioritásokat, illetve adatstruktúrák (tömbök, objektumok) elemeihez való hozzáférés jelölésének módját, és még egy pár apróságot. Ezekre azonban alig-alig mondhatjuk, hogy komoly nyelvi definíciók volnának.
És mindezekhez szerintem hozzá kell venni az elmúlt sirámaimban megemlített dolgokat: az UNICODE használatát, a kódban a finomítás elvét (érdekes, a Jackson ezt még tudta), az osztálydiagramként megrajzolt adatmodellt analizáló/ellenőrző eszközt, stb.
Néhány - egyébkén fontos - dologról nem beszéltem (feladatleírás, fogalomtár, stb.), mivel nem akartam a programtervezés - ma már láthatóan nam túl egyszerű - folyamatát teljesen visszataszító köntösben megjeleníteni.
Ha visszatekintek az "őskor"-ban írt assembly programjaimra, megkérdezhetném magamtól, de tőletek is: Hát nem borzalmas?
Igazad van. A programozás ma már nem egy, hanem több szakma. De a lefedetlen területek közül csak egy van, ami gigantikus méretű: az Információs Rendszerek (magyarul adatbázisos alkalmazások). És mindegy, hogy WEB-es vagy nem WEB-es, mert lassan minden elWEBesül.
Rendszerprogramozókra, grafikus alkalmazást készítőkre nincs ezerszám szükség. Játékprogramokból túlkínálat van.
Talán mikrokontroller programozókra lenne még nagy szükség, ott azonban komolyabb HW-es előképzettség nélkül labdába sem lehet rugni. Nem csoda, hogy ma már technikailag elképesztő dolgokat lehetne művelni, de még a méregdrága mobilok is igen primitív képességűek.
Egyetértek. Sajnos a fejlesztők a többségben lévő rossz programozókból indulnak ki, őket szolgálják ki. Ez is a szoftver krízis miatt van. A hiánygazdaság (vö. szocializmus) hosszú távon nem vezet jóra.
"programozo reszerol viszont rossz uzlet ha egy fejlesztoeszkoz rabjava valik (igy lesz valakibol 'Delphi-programozo' a masikbol 'OracleForms-programozo'"
Hát azért nem biztos, hogy rossz üzlet. A programozás manapság már akkora terület, hogy szakosodni kell. Ha ezt nem teszed meg, akkor igazából csak Mek-Mester lehetsz... Tudod: mindenhez értek, de csak egy picikét.
