Ó, lennének ötleteim! Ha nem is mind ezekből a nyelvekből.
De a szigorú típusosság babonáját még oktatják is, és általában egy nyelv nagy jóságának tartják. Általában minél képzettebb programozó valaki, annál inkább ragaszkodik hozzá.
//lehet hogy itt is provokáló lesz ez a megjegyzés, de nem baj :-)
De összeszedhetjük, kinek mi a kedvence. Példának néhány az enyémek közül:
hosszú kulcsszavak, főleg a gyakran használtak esetén - fieldbyname több szavas kulcsszavak - group by, order by több utasításban szereplő, mást jelentő kulcsszavak - end
Horváth Gyula Szerintem az statikus es/vagy eros tipusossag inkabb projekt meret es penz (marmint mennyitol esik el a tulajdonos, ha megsem okes valami) kerdese. 1-2 fejleszto, zero business risk: nem igenyel tipusossagot. 20-50-100 fejleszto, nanosecundumban mert 5 szamjegyu kieses: el sem kepzelheto nelkule
Richárd Kovács Mivel 5 fő feletti fejlesztésről nem tudok nyilatkozni, elfogadom, amit mondasz. Ugyanakkor tartom, hogy egy olyan pinf egyszerű dologról van szó, amit a fordítónak kezelnie kell(ene).
Meg aztán sok év alatt rengeteg hülye hibával találkoztam, de soha olyannal, amit típushiba okozott volna.
Horváth Gyula Akkor te szerencses vagy :) Ha nincsenek tipusok a fejleszto feladata kezelni oket, innentol vagy jo lesz vagy nem. A legnagyobb baj a dinamikusan tipusos nyelvekkel, hogy csak runtime derulnek ki a turpiszsagok, es en jobb szeretem a runtime hibakat minimalizalni. De felreteve a mit nyelsz ha vannak tipusaid dolgot, mit nyersz azon ha nincsenek? Egy kis gepelest, aminek joreszeben segit az ide? (Raadasul vannak tipusos nyelvek, amik kitalaljak a tipust, ott meg csak extra gepeles sincs.)
Richárd Kovács Például azt nyerem, hogy a fordító nem vernyákol nekem, hogy a két string változó vagy integer között nem tud értékadást végezni. Meg azt is nyerem, hogy lehetőség szerint a feladat kreatív részével foglalkozhatok, nem a favágással. Meg nem kéne hülye lebegőpontos számokat használni csak azért mert a fix tizedesesek nem tudnak elég nagy számokat kezelni. Pénzügyi rendszereknél napi probléma.
A fejlesztőnek mit kell kezelni? Bevezet egy változót mondjuk partnernev néven. Ugye sejted milyen típus? A méretellenőrzést meg attól függően kell megtenni, hova lesz letárolva, de ha a változóban is látni akarom (nem akarom), akkor lehet a neve partnernev100 is. Nem fogom akarni ezzel a változóval számolni egy eladás áfáját, se egy termék összsúlyát.
Nem az zavar, ha az elején meg kell mondanom mi ez, bár felesleges, de ha a stringekből több van, integerből több van az macera.
De nem is azzal van bajom, ha van ilyen, hanem azzal, ha ezt tekintik egy programnyelv jósága mértékének. Nem az, ez a compiler butasága, és a mesterséges intelligencia hiánya azon a területen (programozás), ahol a legkönnyebben megoldható feladatok vannak.
Horváth Gyula "hogy a fordító nem vernyákol nekem" hanem majd runtime jon. mennyivel jobb
"a feladat kreatív részével foglalkozhatok" csak atalkitani ne kelljen, mert akkor lehet nyomni a shift kontrol f-et orrverzesig meg tesztelni mindent, mert ha csak 1 helyen nem irtad at a hivatkozast runtime jon a baj
"Ugye sejted milyen típus?" persze a fejleszto sejtni, csak a user nem, aki majd bekuld eletkornak romai szamokat
"partnernev100" clean code? ez kb olyan mintha kommentbe melleirnad, aza semmi, mert semmi nem garantalja, hogy az kesobb is az lesz
"tekintik egy programnyelv jósága mértékének" nem ez a josag merteke, legalabbis szerintem, hanem az, hogy minimalis erobefektetesert cserebe oriasi nyereseg az, hogy compile time elojonnek a hibak, es hogy olyan ide tamogatas van, amirol a dinamikus/gyengen tipusos nyelvek csak almodnak.
Mi 16an dolgozunk a backenden kb 150000 kodsoron 24 subprojektben (es szerintem a mienk egy kicsi projekt). Vert pisalnank ha nem volna minden tipusos, meg nem volna ide tamogatas.
Na mindegy valszeg nem fogjuk egymast meggyozni :)
Amugy azert szeretem a Go-t mert a skriptnyelvek egyszerusegevel lehet megis tipusos kodot irni, es a parancssori eszkoz tud mindent, amit elvarok egy ide-tol
Valszeg tényleg nem. De lehet hogy azért nem, mert én még sose találkoztam futásidőben olyan hibával, amit ez okozott volna. Persze amikor épp szigorúan típusos nyelvvel dolgoztunk, akkor azért nem, de sokszor dolgoztunk lazán típusos nyelvvel is és automatikus típuskonverzióssal is. Arra a pár évre, amíg a MI átveszi teljesen a programozást tőlünk meg már tényleg mindegy :-)
:D
VálaszTörlésMég beleraknám a Forth fordított lengyel jelölését :D
Ó, lennének ötleteim! Ha nem is mind ezekből a nyelvekből.
VálaszTörlésDe a szigorú típusosság babonáját még oktatják is, és általában egy nyelv nagy jóságának tartják. Általában minél képzettebb programozó valaki, annál inkább ragaszkodik hozzá.
//lehet hogy itt is provokáló lesz ez a megjegyzés, de nem baj :-)
De összeszedhetjük, kinek mi a kedvence. Példának néhány az enyémek közül:
VálaszTörléshosszú kulcsszavak, főleg a gyakran használtak esetén - fieldbyname
több szavas kulcsszavak - group by, order by
több utasításban szereplő, mást jelentő kulcsszavak - end
Horváth Gyula Szerintem az statikus es/vagy eros tipusossag inkabb projekt meret es penz (marmint mennyitol esik el a tulajdonos, ha megsem okes valami) kerdese. 1-2 fejleszto, zero business risk: nem igenyel tipusossagot. 20-50-100 fejleszto, nanosecundumban mert 5 szamjegyu kieses: el sem kepzelheto nelkule
VálaszTörlésRichárd Kovács Mivel 5 fő feletti fejlesztésről nem tudok nyilatkozni, elfogadom, amit mondasz. Ugyanakkor tartom, hogy egy olyan pinf egyszerű dologról van szó, amit a fordítónak kezelnie kell(ene).
VálaszTörlésMeg aztán sok év alatt rengeteg hülye hibával találkoztam, de soha olyannal, amit típushiba okozott volna.
Excel képletek magyar nyelven.
VálaszTörlésDe ráérnek :)
VálaszTörlésHorváth Gyula Akkor te szerencses vagy :) Ha nincsenek tipusok a fejleszto feladata kezelni oket, innentol vagy jo lesz vagy nem. A legnagyobb baj a dinamikusan tipusos nyelvekkel, hogy csak runtime derulnek ki a turpiszsagok, es en jobb szeretem a runtime hibakat minimalizalni. De felreteve a mit nyelsz ha vannak tipusaid dolgot, mit nyersz azon ha nincsenek? Egy kis gepelest, aminek joreszeben segit az ide? (Raadasul vannak tipusos nyelvek, amik kitalaljak a tipust, ott meg csak extra gepeles sincs.)
VálaszTörlésSancho Vi At Bizony ám!
VálaszTörlésRichárd Kovács Például azt nyerem, hogy a fordító nem vernyákol nekem, hogy a két string változó vagy integer között nem tud értékadást végezni. Meg azt is nyerem, hogy lehetőség szerint a feladat kreatív részével foglalkozhatok, nem a favágással. Meg nem kéne hülye lebegőpontos számokat használni csak azért mert a fix tizedesesek nem tudnak elég nagy számokat kezelni. Pénzügyi rendszereknél napi probléma.
A fejlesztőnek mit kell kezelni? Bevezet egy változót mondjuk partnernev néven. Ugye sejted milyen típus? A méretellenőrzést meg attól függően kell megtenni, hova lesz letárolva, de ha a változóban is látni akarom (nem akarom), akkor lehet a neve partnernev100 is. Nem fogom akarni ezzel a változóval számolni egy eladás áfáját, se egy termék összsúlyát.
Nem az zavar, ha az elején meg kell mondanom mi ez, bár felesleges, de ha a stringekből több van, integerből több van az macera.
De nem is azzal van bajom, ha van ilyen, hanem azzal, ha ezt tekintik egy programnyelv jósága mértékének. Nem az, ez a compiler butasága, és a mesterséges intelligencia hiánya azon a területen (programozás), ahol a legkönnyebben megoldható feladatok vannak.
Szidjuk inkább a hülye nyelvi megoldásokat!
Horváth Gyula
VálaszTörlés"hogy a fordító nem vernyákol nekem" hanem majd runtime jon. mennyivel jobb
"a feladat kreatív részével foglalkozhatok" csak atalkitani ne kelljen, mert akkor lehet nyomni a shift kontrol f-et orrverzesig meg tesztelni mindent, mert ha csak 1 helyen nem irtad at a hivatkozast runtime jon a baj
"Ugye sejted milyen típus?" persze a fejleszto sejtni, csak a user nem, aki majd bekuld eletkornak romai szamokat
"partnernev100" clean code? ez kb olyan mintha kommentbe melleirnad, aza semmi, mert semmi nem garantalja, hogy az kesobb is az lesz
"tekintik egy programnyelv jósága mértékének" nem ez a josag merteke, legalabbis szerintem, hanem az, hogy minimalis erobefektetesert cserebe oriasi nyereseg az, hogy compile time elojonnek a hibak, es hogy olyan ide tamogatas van, amirol a dinamikus/gyengen tipusos nyelvek csak almodnak.
Mi 16an dolgozunk a backenden kb 150000 kodsoron 24 subprojektben (es szerintem a mienk egy kicsi projekt). Vert pisalnank ha nem volna minden tipusos, meg nem volna ide tamogatas.
Na mindegy valszeg nem fogjuk egymast meggyozni :)
Amugy azert szeretem a Go-t mert a skriptnyelvek egyszerusegevel lehet megis tipusos kodot irni, es a parancssori eszkoz tud mindent, amit elvarok egy ide-tol
Valszeg tényleg nem. De lehet hogy azért nem, mert én még sose találkoztam futásidőben olyan hibával, amit ez okozott volna. Persze amikor épp szigorúan típusos nyelvvel dolgoztunk, akkor azért nem, de sokszor dolgoztunk lazán típusos nyelvvel is és automatikus típuskonverzióssal is. Arra a pár évre, amíg a MI átveszi teljesen a programozást tőlünk meg már tényleg mindegy :-)
VálaszTörlés(Go-t nem ismerem.)
VálaszTörlésÓ, bzmg! Extjs legyen a frontend!
VálaszTörlés