Lue keskustelun säännöt.
Miksei C poistunut käytöstä heti kun C++ keksittiin?
Kommentit (78)
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Kompaktius ja nopeus.
Jos haluaa tehdä todella tehokasta koodia (esim. käyttöjärjestelmän ohjelmointi, pelit) on mentävä niin lähelle rautaa kuin on pragmaattista. C:sta ei ole enää pitkä loikka assembleriin.
Entä Fortran?
En ole sama henkilö, mutta tietääkseni toisin kuin C-kieli, Fortran ei ole yleiskieli, vaan soveltuu lähinnä matemaattiseen laskentaan. Esimerkiksi fyysikot saattavat käyttää sitä apunaan työssään.
Bah! Fortrania ole käyttänyt kukaan vuosikymmeniin. Fyysikot koodaa C++:lla tai Matlabilla.
Jos tehdään laskentaa, tehdään C:llä (ei C++:lla) tai Fortranilla. Tietenkään pieniä datasettejä ei erkkikään pyörittele Fortranilla, mutta suuret datamäärät + Matlab on aika... mielenkiintoinen ehdotus.
Kieli valitaan käytön mukaan. (Ja historian. Erkkikään ei kirjoita megalomaanisia ohjelmistoja uudelleen vain siksi, että Fortran on vanhanaikainen, kun Erkin pitäisi saada tuloksia nyt eikä kolmen vuoden päästä.)
Sisältö jatkuu mainoksen alla
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
printf("Hello world");
Kehitä tuota vielä vähän.
Kelpaako tää sulle:
int main(){
printf("Hello World");
}T. ex-C-koodari
#include puuttuu
void puuttuu
return puuttuu
t. toinen ex koodari
puts() on kevyempi kuin printf(), silloin kun ei tarvitse
format-string käsittelyä. Tällä on merkitystä toistuvissa
rakenteissa ja kun pyritään pieneen koodiin. Tai vaikka
sitten mikrokontrollereissa, joissa alimman kerroksen
io-funktiot pitää itse koodata kirjastoon, koska puts()
pienempi ja myös helpompi itse koodata.
Huvittava seurata tätä keskustelua kun itsellä +35v c-lläkin takana :D
t. kolmas ei-ex-koodari (ura ei tosin ole vain ollut koodamista, kaukana siitä, mutta se on toinen tarina ...)
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Minusta nuo kaikki oliokielet on täyttä ulostetta ja tarpeetonta kompleksisuutta. Olin sitä mieltä jo kun C++ ja Java tulivat. Silloin kaikki vähän naureskelivat, että hitsi mikä dinosaurus, vastustaa edistystä. Nyt kuitenkin alan työelämässä näen, että kaikenlaiset skriptikielet yleistyy ja oliopohjaiset ohjelmointikielet harvinaistuu. Lopulta ne on huomanneet että turhaa tehdä asioita vaikeasti kun ne voi tehdä helpostikin.
Täh. Ei oliopohjaiset kielet mihinkään ole katoamassa, mutta ei niillä aina kannata mitään scriptejä tehdä... jollain Rubyllä voi toki tehdä vaikka molempia. C:llä tehdään sitten toisia asioita. Kuinkahan suuri osuus jostain webbisovelluksista on tehty jollain oliopohjaisella? Aika lailla suurin osa.
Näin vielä on, mutta selkeä koodi on poispäin niistä. Mikropalveluarkkitehtuurit, pilvipalvelut jne edistää tätä kehitystä. Ei enää tehdäkään sitä isoa j2ee sovellusta jossa se yksi sovelluspaketti sisältää kaiken vaan pieniä mikropalveluita johonkin docker swarmiin lillumaan.
Miksei mikropalveluakin kannattaisi koodata oliopohjaisesti? Vaikka yksittäinen palvelu olisikin pienempi kokonaisuus, ei se poista oliomallin etuja mihinkään. Toki vaihtoehtojakin löytyy, kuten funktionaaliset kielet.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Mutta noita webbisoftia pyörittää ihan hyvin javapohjaisinakin, sovelluspalvelimilla jotka osaa rinnakkaistaa käyttäjämäärän mukaan.
Eli käytännössä sitä korvataan raskaalla raudalla että ohjelmoijia täytyy pitää javapumpulissa.
Rauta on halpaa.
Jos koodarin työtunti oheiskuluineen maksaa 100 € niin aika nopeasti päädytään tilanteeseen, ettei kannata tehdä nopeaa koodia vaan tehdä mahdollisimman tehokkaasti valmista koodia. Koodataan nopeasti ohjelma joka tekee tehtävänsä ja jos se toimii liian hitaasti niin ostetaan lisää rautaa.
Heh, et ole vielä ymmärtänyt, että jos niitä laitteita jossa sen koodin pitää pyöriä valmistetaan vähintääkin miljoonissa, niin lisäkustannus raudassa ei ole parin serverin hinta vaan merkittävästi enemmän. Se lisäkustannus myös yleensä nostaa myytävän tuotteen hintaa, asemaa markkinoilla tai sitten omistajille maksettavaa osinkoja. Nämä asiat tulevat vastaan hyvin varhaisessa vaiheessa kun joudut tekemisiin sulautettujen järjestelmien kehittämisen kanssa.
Toisekseen, lisärauta kuluttaa enemmän energiaa, vaatii enemmän jäähdytystä ja on siten vähemmän ekologista usein myös suurissa määrin käytettynä vähemmän taloudellista. Isojen pilvifirmojen, kuten Googlen kannattaa tehdä hyvinkin radikaaleja temppuja esim. PUE arvon parantamiseksi ja tehdä / valmistuttaa verkkolaitteita joissa on vain ne ominaisuudet, joita he tarvitsevat eikä käyttää markkinajohtajien (Cisco, HPE, Juniper, jne), sama storagepuolella.
Vetämällä johtopäätöksiä ja yleistämään oman ympäristösi kokemuspiiriin projektien tilanteesta kaikkia koskevaksi osoitat lähinnä sen, että vielä täysin ymmärrä kovin laajasti ohjemistonkehityksen laaja-alaisuutta.
Tuski ihan heti tullaan siihen ettei enää tarvittaisi mitään matalamman tason kieltä, mihinkään.
Ja kun sitä tarvitaan, on kieli luonnollisesti C, koska se on melko hyvä ja tunnettu (eikä kenenkään intresseissä ole enää kehitellä jotain vastaavaa uutta tilalle).
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Mutta noita webbisoftia pyörittää ihan hyvin javapohjaisinakin, sovelluspalvelimilla jotka osaa rinnakkaistaa käyttäjämäärän mukaan.
Eli käytännössä sitä korvataan raskaalla raudalla että ohjelmoijia täytyy pitää javapumpulissa.
Rauta on halpaa.
Jos koodarin työtunti oheiskuluineen maksaa 100 € niin aika nopeasti päädytään tilanteeseen, ettei kannata tehdä nopeaa koodia vaan tehdä mahdollisimman tehokkaasti valmista koodia. Koodataan nopeasti ohjelma joka tekee tehtävänsä ja jos se toimii liian hitaasti niin ostetaan lisää rautaa.
Heh, et ole vielä ymmärtänyt, että jos niitä laitteita jossa sen koodin pitää pyöriä valmistetaan vähintääkin miljoonissa, niin lisäkustannus raudassa ei ole parin serverin hinta vaan merkittävästi enemmän. Se lisäkustannus myös yleensä nostaa myytävän tuotteen hintaa, asemaa markkinoilla tai sitten omistajille maksettavaa osinkoja. Nämä asiat tulevat vastaan hyvin varhaisessa vaiheessa kun joudut tekemisiin sulautettujen järjestelmien kehittämisen kanssa.
Toisekseen, lisärauta kuluttaa enemmän energiaa, vaatii enemmän jäähdytystä ja on siten vähemmän ekologista usein myös suurissa määrin käytettynä vähemmän taloudellista. Isojen pilvifirmojen, kuten Googlen kannattaa tehdä hyvinkin radikaaleja temppuja esim. PUE arvon parantamiseksi ja tehdä / valmistuttaa verkkolaitteita joissa on vain ne ominaisuudet, joita he tarvitsevat eikä käyttää markkinajohtajien (Cisco, HPE, Juniper, jne), sama storagepuolella.
Vetämällä johtopäätöksiä ja yleistämään oman ympäristösi kokemuspiiriin projektien tilanteesta kaikkia koskevaksi osoitat lähinnä sen, että vielä täysin ymmärrä kovin laajasti ohjemistonkehityksen laaja-alaisuutta.
Tehokasta koodia tarvitaan niissä suorituskykykriittisissä kohdissa, jotka ovat yleensä vain minimaalinen osa kokonaisuutta. On selvää, että korkeamman tason kielet dominoiva jatkossa, koska ohjelmistojen kompleksisuus vain kasvaa kasvamistaan, ja time to market on king.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Mutta noita webbisoftia pyörittää ihan hyvin javapohjaisinakin, sovelluspalvelimilla jotka osaa rinnakkaistaa käyttäjämäärän mukaan.
Eli käytännössä sitä korvataan raskaalla raudalla että ohjelmoijia täytyy pitää javapumpulissa.
Rauta on halpaa.
Jos koodarin työtunti oheiskuluineen maksaa 100 € niin aika nopeasti päädytään tilanteeseen, ettei kannata tehdä nopeaa koodia vaan tehdä mahdollisimman tehokkaasti valmista koodia. Koodataan nopeasti ohjelma joka tekee tehtävänsä ja jos se toimii liian hitaasti niin ostetaan lisää rautaa.
Heh, et ole vielä ymmärtänyt, että jos niitä laitteita jossa sen koodin pitää pyöriä valmistetaan vähintääkin miljoonissa, niin lisäkustannus raudassa ei ole parin serverin hinta vaan merkittävästi enemmän. Se lisäkustannus myös yleensä nostaa myytävän tuotteen hintaa, asemaa markkinoilla tai sitten omistajille maksettavaa osinkoja. Nämä asiat tulevat vastaan hyvin varhaisessa vaiheessa kun joudut tekemisiin sulautettujen järjestelmien kehittämisen kanssa.
Toisekseen, lisärauta kuluttaa enemmän energiaa, vaatii enemmän jäähdytystä ja on siten vähemmän ekologista usein myös suurissa määrin käytettynä vähemmän taloudellista. Isojen pilvifirmojen, kuten Googlen kannattaa tehdä hyvinkin radikaaleja temppuja esim. PUE arvon parantamiseksi ja tehdä / valmistuttaa verkkolaitteita joissa on vain ne ominaisuudet, joita he tarvitsevat eikä käyttää markkinajohtajien (Cisco, HPE, Juniper, jne), sama storagepuolella.
Vetämällä johtopäätöksiä ja yleistämään oman ympäristösi kokemuspiiriin projektien tilanteesta kaikkia koskevaksi osoitat lähinnä sen, että vielä täysin ymmärrä kovin laajasti ohjemistonkehityksen laaja-alaisuutta.
Tehokasta koodia tarvitaan niissä suorituskykykriittisissä kohdissa, jotka ovat yleensä vain minimaalinen osa kokonaisuutta. On selvää, että korkeamman tason kielet dominoiva jatkossa, koska ohjelmistojen kompleksisuus vain kasvaa kasvamistaan, ja time to market on king.
Onhan se varmasti sillä sinulle tutuimmalla osa-alueella, mutta se kun ei ole koko 'markkina'. Ohitit kommentitta keskeiset kohdat yllä, elät kuplassa jonka ulkopuolelle kieltäydyt näkemästä joko tarkoituksellisesti tai mikä luultavampaa, et vain ymmärrä asioita vielä riittävän laajasti.
Se mitä esität pätee nyt vain osalla toimialaa, mutta sielläkin muutoksen tuulet puhaltavat.
Välineet kehittyvät vauhdilla ja nopeasti koodattavan bulkkikoodin tekeminen vähenee vuosi vuodelta, kunnes sitten jossain vaiheessa spekseistä ja suunnitteludokumenteista tekoäly tuottaa jo suurimman osan, kykenee testaamaan sen ja koodi on optimoidumpaa ja virheettömämpää kun mihin ihminen olisi kyennyt. Muutama vuosi sitten kokeiltiin jo ja annettiin ai:n suunnitella IP:n kaltainen tietoliikeneprotokolla. Lopputuloksena oli nopeampi ja tehokkaampi protokolla kun nykyisin käytetyt ihmisen suunnittelemat.
Nopeasti markkinoille vietävät pienohjelmat (appsit) ja enimmäkseen bulkkikoodia sisältävät triviaalit softia tuottavat ovat ne joiden tuotantoa automatisoidaan ai:ta sisältävillä koodia generoivilla työvälineillä, joita on jo kehitetty jonkin aikaa.
https://github.com/tonybeltramelli/pix2code
Koodin generointi ei ole mitenkään uusi asia, olin itsekin jo -80 luvulla kehittämässä välinettä (talon sisäinen sovelluskehitin), jolla sovellusohjelman näytöt, valikot ja raportit piirrettiin visuaalisilla ohjelmilla ja niillä talletetuista spekseistä sitten tuotettiin suuri osa koodista sovelluksen tarvitsemista näytöistä, raporteista ja valikoista. Se lisäsi tuottavuutta merkittävästi kun kyse oli suuren taloushallinnon ohjelmistojen kehittämisestä jossa vakioituja komponentteja käytettiin ja piti saada yhdenmukainen asu kaikkialle. Ei sitä 75% bulkki-scaffoldia, jota sovellukseen tarvittiin kukaan täysipäinen halunnut moneen kertaan koodata. Välineen avulla päästiin siihen, että tuo osa tehtiin templeittien avulla ja sovelluksen kehittäjä sai keskittyä tekemään varsinaista ohjelmiston substanssia paremmin. Lisääntyvän AI:n käytön myötä vastaavat järjestelmät hoitavat aisian vieläkin paremmin.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Mutta noita webbisoftia pyörittää ihan hyvin javapohjaisinakin, sovelluspalvelimilla jotka osaa rinnakkaistaa käyttäjämäärän mukaan.
Eli käytännössä sitä korvataan raskaalla raudalla että ohjelmoijia täytyy pitää javapumpulissa.
Rauta on halpaa.
Jos koodarin työtunti oheiskuluineen maksaa 100 € niin aika nopeasti päädytään tilanteeseen, ettei kannata tehdä nopeaa koodia vaan tehdä mahdollisimman tehokkaasti valmista koodia. Koodataan nopeasti ohjelma joka tekee tehtävänsä ja jos se toimii liian hitaasti niin ostetaan lisää rautaa.
Heh, et ole vielä ymmärtänyt, että jos niitä laitteita jossa sen koodin pitää pyöriä valmistetaan vähintääkin miljoonissa, niin lisäkustannus raudassa ei ole parin serverin hinta vaan merkittävästi enemmän. Se lisäkustannus myös yleensä nostaa myytävän tuotteen hintaa, asemaa markkinoilla tai sitten omistajille maksettavaa osinkoja. Nämä asiat tulevat vastaan hyvin varhaisessa vaiheessa kun joudut tekemisiin sulautettujen järjestelmien kehittämisen kanssa.
Toisekseen, lisärauta kuluttaa enemmän energiaa, vaatii enemmän jäähdytystä ja on siten vähemmän ekologista usein myös suurissa määrin käytettynä vähemmän taloudellista. Isojen pilvifirmojen, kuten Googlen kannattaa tehdä hyvinkin radikaaleja temppuja esim. PUE arvon parantamiseksi ja tehdä / valmistuttaa verkkolaitteita joissa on vain ne ominaisuudet, joita he tarvitsevat eikä käyttää markkinajohtajien (Cisco, HPE, Juniper, jne), sama storagepuolella.
Vetämällä johtopäätöksiä ja yleistämään oman ympäristösi kokemuspiiriin projektien tilanteesta kaikkia koskevaksi osoitat lähinnä sen, että vielä täysin ymmärrä kovin laajasti ohjemistonkehityksen laaja-alaisuutta.
Tehokasta koodia tarvitaan niissä suorituskykykriittisissä kohdissa, jotka ovat yleensä vain minimaalinen osa kokonaisuutta. On selvää, että korkeamman tason kielet dominoiva jatkossa, koska ohjelmistojen kompleksisuus vain kasvaa kasvamistaan, ja time to market on king.
Onhan se varmasti sillä sinulle tutuimmalla osa-alueella, mutta se kun ei ole koko 'markkina'. Ohitit kommentitta keskeiset kohdat yllä, elät kuplassa jonka ulkopuolelle kieltäydyt näkemästä joko tarkoituksellisesti tai mikä luultavampaa, et vain ymmärrä asioita vielä riittävän laajasti.
Se mitä esität pätee nyt vain osalla toimialaa, mutta sielläkin muutoksen tuulet puhaltavat.
Välineet kehittyvät vauhdilla ja nopeasti koodattavan bulkkikoodin tekeminen vähenee vuosi vuodelta, kunnes sitten jossain vaiheessa spekseistä ja suunnitteludokumenteista tekoäly tuottaa jo suurimman osan, kykenee testaamaan sen ja koodi on optimoidumpaa ja virheettömämpää kun mihin ihminen olisi kyennyt. Muutama vuosi sitten kokeiltiin jo ja annettiin ai:n suunnitella IP:n kaltainen tietoliikeneprotokolla. Lopputuloksena oli nopeampi ja tehokkaampi protokolla kun nykyisin käytetyt ihmisen suunnittelemat.
Nopeasti markkinoille vietävät pienohjelmat (appsit) ja enimmäkseen bulkkikoodia sisältävät triviaalit softia tuottavat ovat ne joiden tuotantoa automatisoidaan ai:ta sisältävillä koodia generoivilla työvälineillä, joita on jo kehitetty jonkin aikaa.
https://github.com/tonybeltramelli/pix2code
Koodin generointi ei ole mitenkään uusi asia, olin itsekin jo -80 luvulla kehittämässä välinettä (talon sisäinen sovelluskehitin), jolla sovellusohjelman näytöt, valikot ja raportit piirrettiin visuaalisilla ohjelmilla ja niillä talletetuista spekseistä sitten tuotettiin suuri osa koodista sovelluksen tarvitsemista näytöistä, raporteista ja valikoista. Se lisäsi tuottavuutta merkittävästi kun kyse oli suuren taloushallinnon ohjelmistojen kehittämisestä jossa vakioituja komponentteja käytettiin ja piti saada yhdenmukainen asu kaikkialle. Ei sitä 75% bulkki-scaffoldia, jota sovellukseen tarvittiin kukaan täysipäinen halunnut moneen kertaan koodata. Välineen avulla päästiin siihen, että tuo osa tehtiin templeittien avulla ja sovelluksen kehittäjä sai keskittyä tekemään varsinaista ohjelmiston substanssia paremmin. Lisääntyvän AI:n käytön myötä vastaavat järjestelmät hoitavat aisian vieläkin paremmin.
Ei se koodin generointi kuitenkaan poista ihmisen koodaustarvetta. En tiedä ai:sta, mihin se lopulta johtaa, mutta tälläkin hetkellä tehdään paljon valmiita frameworkkeja, platformeja, kirjastoja, joita yhdistellään ohjelmoistoihin ja räätälöidään se oma sovellus niiden päälle. Eli generoidaan runko, valitaan sopivat kirjastot, mutta tuota räätälöintityötä on paljon, eikä mitään generaattoreita ole tekemään sitä työtä. Eikä myöskään tuota komponenttien valintaa ja niiden yhdistämistä kokonaisuudeksi voi tehdä kuin ihminen. Ehkä ai joskus, mutta tuskin vielä aikoihin.
Myös AI tekee vain sen mitä se käsketään tekemään. Se tarkoittaa vain että speksin ja koodin välinen ero hämärtyy - speksaajista tulee enemmän koodaajia, koodaajista enemmän speksaajia.
Sisältö jatkuu mainoksen alla
Vierailija kirjoitti:
Myös AI tekee vain sen mitä se käsketään tekemään. Se tarkoittaa vain että speksin ja koodin välinen ero hämärtyy - speksaajista tulee enemmän koodaajia, koodaajista enemmän speksaajia.
Näin se tulee ainakin aluksi olemaan. Kehityshän voi johtaa siihenkin, että AI oppii itsenäisesti lisää ja tuottaa ratkaisuja, joita ihminen ei edes kykenisi tuottamaan tai ajattelemaan. Lähtee niin sanotusti lapasesta.
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Vierailija kirjoitti:
Mutta noita webbisoftia pyörittää ihan hyvin javapohjaisinakin, sovelluspalvelimilla jotka osaa rinnakkaistaa käyttäjämäärän mukaan.
Eli käytännössä sitä korvataan raskaalla raudalla että ohjelmoijia täytyy pitää javapumpulissa.
Rauta on halpaa.
Jos koodarin työtunti oheiskuluineen maksaa 100 € niin aika nopeasti päädytään tilanteeseen, ettei kannata tehdä nopeaa koodia vaan tehdä mahdollisimman tehokkaasti valmista koodia. Koodataan nopeasti ohjelma joka tekee tehtävänsä ja jos se toimii liian hitaasti niin ostetaan lisää rautaa.
Heh, et ole vielä ymmärtänyt, että jos niitä laitteita jossa sen koodin pitää pyöriä valmistetaan vähintääkin miljoonissa, niin lisäkustannus raudassa ei ole parin serverin hinta vaan merkittävästi enemmän. Se lisäkustannus myös yleensä nostaa myytävän tuotteen hintaa, asemaa markkinoilla tai sitten omistajille maksettavaa osinkoja. Nämä asiat tulevat vastaan hyvin varhaisessa vaiheessa kun joudut tekemisiin sulautettujen järjestelmien kehittämisen kanssa.
Toisekseen, lisärauta kuluttaa enemmän energiaa, vaatii enemmän jäähdytystä ja on siten vähemmän ekologista usein myös suurissa määrin käytettynä vähemmän taloudellista. Isojen pilvifirmojen, kuten Googlen kannattaa tehdä hyvinkin radikaaleja temppuja esim. PUE arvon parantamiseksi ja tehdä / valmistuttaa verkkolaitteita joissa on vain ne ominaisuudet, joita he tarvitsevat eikä käyttää markkinajohtajien (Cisco, HPE, Juniper, jne), sama storagepuolella.
Vetämällä johtopäätöksiä ja yleistämään oman ympäristösi kokemuspiiriin projektien tilanteesta kaikkia koskevaksi osoitat lähinnä sen, että vielä täysin ymmärrä kovin laajasti ohjemistonkehityksen laaja-alaisuutta.
Tehokasta koodia tarvitaan niissä suorituskykykriittisissä kohdissa, jotka ovat yleensä vain minimaalinen osa kokonaisuutta. On selvää, että korkeamman tason kielet dominoiva jatkossa, koska ohjelmistojen kompleksisuus vain kasvaa kasvamistaan, ja time to market on king.
Onhan se varmasti sillä sinulle tutuimmalla osa-alueella, mutta se kun ei ole koko 'markkina'. Ohitit kommentitta keskeiset kohdat yllä, elät kuplassa jonka ulkopuolelle kieltäydyt näkemästä joko tarkoituksellisesti tai mikä luultavampaa, et vain ymmärrä asioita vielä riittävän laajasti.
Se mitä esität pätee nyt vain osalla toimialaa, mutta sielläkin muutoksen tuulet puhaltavat.
Välineet kehittyvät vauhdilla ja nopeasti koodattavan bulkkikoodin tekeminen vähenee vuosi vuodelta, kunnes sitten jossain vaiheessa spekseistä ja suunnitteludokumenteista tekoäly tuottaa jo suurimman osan, kykenee testaamaan sen ja koodi on optimoidumpaa ja virheettömämpää kun mihin ihminen olisi kyennyt. Muutama vuosi sitten kokeiltiin jo ja annettiin ai:n suunnitella IP:n kaltainen tietoliikeneprotokolla. Lopputuloksena oli nopeampi ja tehokkaampi protokolla kun nykyisin käytetyt ihmisen suunnittelemat.
Nopeasti markkinoille vietävät pienohjelmat (appsit) ja enimmäkseen bulkkikoodia sisältävät triviaalit softia tuottavat ovat ne joiden tuotantoa automatisoidaan ai:ta sisältävillä koodia generoivilla työvälineillä, joita on jo kehitetty jonkin aikaa.
https://github.com/tonybeltramelli/pix2code
Koodin generointi ei ole mitenkään uusi asia, olin itsekin jo -80 luvulla kehittämässä välinettä (talon sisäinen sovelluskehitin), jolla sovellusohjelman näytöt, valikot ja raportit piirrettiin visuaalisilla ohjelmilla ja niillä talletetuista spekseistä sitten tuotettiin suuri osa koodista sovelluksen tarvitsemista näytöistä, raporteista ja valikoista. Se lisäsi tuottavuutta merkittävästi kun kyse oli suuren taloushallinnon ohjelmistojen kehittämisestä jossa vakioituja komponentteja käytettiin ja piti saada yhdenmukainen asu kaikkialle. Ei sitä 75% bulkki-scaffoldia, jota sovellukseen tarvittiin kukaan täysipäinen halunnut moneen kertaan koodata. Välineen avulla päästiin siihen, että tuo osa tehtiin templeittien avulla ja sovelluksen kehittäjä sai keskittyä tekemään varsinaista ohjelmiston substanssia paremmin. Lisääntyvän AI:n käytön myötä vastaavat järjestelmät hoitavat aisian vieläkin paremmin.
Ei se koodin generointi kuitenkaan poista ihmisen koodaustarvetta. En tiedä ai:sta, mihin se lopulta johtaa, mutta tälläkin hetkellä tehdään paljon valmiita frameworkkeja, platformeja, kirjastoja, joita yhdistellään ohjelmoistoihin ja räätälöidään se oma sovellus niiden päälle. Eli generoidaan runko, valitaan sopivat kirjastot, mutta tuota räätälöintityötä on paljon, eikä mitään generaattoreita ole tekemään sitä työtä. Eikä myöskään tuota komponenttien valintaa ja niiden yhdistämistä kokonaisuudeksi voi tehdä kuin ihminen. Ehkä ai joskus, mutta tuskin vielä aikoihin.
Kyllä ihmistä tarvitaan vielä pitkään, mutta vuosi vuodelta vähemmän bulkkisoftien tekemisessä, joilla on usein se kovin kiire saada ne markkinoille.
Se mitä nyt tehdään frameworkkeistä ja kirjastoista kasaamalla voidaan tehdä suurelta osin ja enemmän ohjatusti AI:n tukemana, samoin koodin refaktorointi kun se taustalla huomaa, että teet jotain mitä on jo lähes tehty ja joista voidaan tehdä luokka tai lisätä metodi olemassa olevaan. Tuottavuus paranee ja apuvälineet tekevät suuremman osan toistoa vaativasta koodaamisen osasta.
Ai voi käydä läpi isoja versionhallinta repoja, oppia niistä ja tehdä ehdotuksia muutoksiksi, jotka koodaaja sitten hyväksyy , ottaa pohjaksi avustetulle muutokselle tai hylkää jos se ei ole haluta sitä jostain syystä. Ihmiselle jää enemmän osittain ohjaava rooli ja se osa koodista mitä AI ei voi lähtötietojen puutteen vuoksi päätellä ja implementaation tekemisessä on sama vaiva kun speksin tekemisessä, josta AI ymmärtäisi mitä halutaan.
Mutta palatakseni aiempaan, jäljelle jää osia ohjelmistotuotannosta, jossa tehtäväalue on uusi, koneresurssit on pidettävä alhaisina taloudellisten, ekologisten tai muuten vain olosuhteiden vaatimuksesta. Näitä on vaikea opettaa jollekin AI:lle, jokainen kilo massaa kuljetettavaksi mukana tai ammuttavaksi avaruuteen maksaa paljon enemmän kun useimmat ohjelmoijat osaavat arvata pyytäessään alustaan lisää resursseja.
Sen vuoksi on varsin naiivia yleistää että se mikä pitää paikkansa johonkin geneeriselle serverille tai kännykkään sovelmia tekevän koodari mielestä on helppo lisätä kun hänelle koodaamisesta tulee helpompaa kun ei tarvitse pihistellä resursseista. Ohjelmistoja tehdään niin monenlaisille alustoille ja tarpeisiin, se mikä pätee yhtäällä ei välttämättä tule kysymykseenkään jollain toisella alustalla jo mainituista syistä.
Sisältö jatkuu mainoksen alla
C pieni ja hwlppo kieli oppia. C ABI on yksinkertainen ja helppo, useimmille kielille löytyy valmis FFI C-moduulien kutsumiseen. C:tä myös käytetään paljon välikielenä esim. Scheme-toteutuksissa.
Sisältö jatkuu mainoksen alla
MOV AX,BX
Aikoinaan sanottiin, että hyvä koodari tekee tätä 5 riviä toimivaa koodia työpäivässä.
Prosessiteollisuudessa on vielä paljon Fortranilla tai Cobolilla tehtyjä ohjelmia
Itse en kyllä koskaan oppinut C:tä ja C++:aa yhtä hyvin kuin assembly-kieltä. Ainakin m68k-sarjan prosessoreille on jopa helpompaa ohjelmoida assemblerilla kuin C-kielellä. Tein Amigalle esim. modeemille terminaaliohjelman, joka meni 30 kilotavussa assembler-lähdekoodina, ja jonkun yksinkertaisen paintohjelman, jossa popup-menuja, viivanpiirtoa, ja täyttöä, ja vei varmaan koko ohjelma noin 20 kt lähdekoodina. En myöskään käyttänyt mitään käyttöjärjestelmää, vaan esim. spritejä ja blitteriä suoraan. Käännettynä näistä ohjelmista sitten tuli muutama kilotavu konekoodia, vaikka kohtuullisen paljon toimintoja niissä oli. Nykyään tuhlataan liikaa muistia turhiin asioihin.
Vierailija kirjoitti:
MOV AX,BX
Aikoinaan sanottiin, että hyvä koodari tekee tätä 5 riviä toimivaa koodia työpäivässä.
Aika hidasta. Itse koodailin parhaimpina aikoinani 1000 riviä debugattua 386 assya päivässä.
Eipä kukaan suomalainen firma kuitenkaan halunnut maksaa siitä mitään.
Emovalmistajat huutelivat aikansa assembler-osaajien perään biosin tiimoilta ja siirtyivät sitten uefiin.