KESKUSTELU

Tuli vielä mieleen että jos lähtee itseopiskelussa aivan nollasta liikkeelle, niin basic-256 ja sen examplet voisi olla myös ihan mielenkiintoinen tutkiskeltava alkuun.

Mahtaakohan tällaista tilannetta olla koskaan? Kun jotain hommaa lähtee suunnittelemaan, niin siinä tulee otettua huomioon vain tietty "joustavuusaste", johon koodi vaivatta yltää. Joku rajahan joustolle on asetettava, koska rauta ja aikataulut asettavat rajoituksia (koodi nyt vain täytyy saada toimimaan jollain järjellisellä työpanoksella). Yllättäen, kun joku koodi on hakkeroitu toimimaan, niin sitä roikotetaan mukana tasan niin kauan kuin vain pystytään, kauas koodin alkuperäisistä tarkoituksista. Mitä joustavammaksi sen alun perin homman suunnittelit, sitä kauemmin se roikkuu riippakivenä matkassa



Kyllä, täsmälleen samaa mieltä! Varsinkin vähän kovemman luokan DSP-prossujen kanssa alkaa olla hankalaa käsin päästä samaan tehoon kuin mihin kääntäjä pääsee, harva on niin tuttu arkkitehtuurin kanssa. Nuo DSP-C-kääntäjät purkaa C-koodin datafloweiksi ja pystyvät tekemään kaikkia pipeline stall- ja rinnakkaisuusoptimointeja.

C++:n kanssa kyse on ehkä siitä, että DSP:t eivät monestikaan ole niin hyviä niissä (C++-koodissa tavattoman yleisissä) moninkertaisissa epäsuorissa viittauksissa (muistiin, koodiin) kuin tavalliset prossut, jotka on nimenomaan suunniteltu kontrollikoodin ajamiseen (toisin kuin DSP, joka tehdään murskaamaan numeroita). Jos koodi menee (kontrollipuolella) niin kiharaiseksi, että se olisi parempi tehdä C++:lla, niin usein silloin siirretään niitä osia jollekin järjestelmän MCU:ista.

Tämä on totta.

Tosin siinäkään ei olisi järkeä, että protokolla tason serverit, prosessit, palvelut mallinnettaisiin olio maailmaan, kun kuitenkin se raaka laskenta tehdää modulitasolla, joka tarvitsee olla nopeaa koodia ja todennäköisesti C:llä väännetty

Ehkäpä DSP maailmassa voisi ajatella C ja C++ soppaa. Tavallaan siellä on C kielellä pyritty imitoimaan luokkia ja intanssidatoja. Mene ja tiedä

Ehkä siellä vaan on parempi pysyä C -kielessä. Mutta olishan se jännä kokeilu.

Muistan jonkun tutkimusprojektin jossa osa verkko DSP:n toiminnoista mallinnettii ja koodattiin C++. Tulos oli silloin kaikkea muuta kuin nopea. Tiedä sitten tehtiinkö se kunnolla, mutta osa syy varmaan oli sen aikaiset C++ kääntäjät.

Jos palataan alkuperäiseen topicciin, niin kielen valinta riippu täysin siitä mihin niitä sovelluksia tekee. C on todistanut voimansa embedded sovelluksissa, eritoten DSP:ssä, mutta myös monessa MCU sovelluksessa. Sillä saadaan nopeasti aikaan toimivaa koodia ja nopeaa koodia

C++ on valinta silloin kun lähestytään käyttöliittymärajapintoja tai itse käyttöliittymää tai käytetään käyttöliittymän palveluja

Itseopiskelu tuottaa yleensä näprääjiä. Kokonaisuudet jäävät hahmottamatta.
Suosittelen opiskelua ja itseopiskelua sopivassa suhteessa. Esim 1:10. Tai 1:100.

TI-mies joutuu aina tekemää töitä keksiäkseen lainalaisuuden, kun oppimalla asian voi tietää etukäteen.

Kielistä kannatta valita sopiva paletti.
C:tä alemmalle tasolle ei kannata mennä.
C++ pitää hallita. Oliokieli ei kuitenkaan ole kovin "täydellinen" ja rajaa mahdollisuuksia.
Fortran kuuluu jo yleissivistykseen.
Ja sitten tietysti joku korkean tason valmispaketti.


Itse tein aika paljoin töitä linjalla c,C++,*Cbuilder.
Kyse oli tietenkin embeddistä, user interfaceen.

Nettikoodauksesta kieltäydyin. Se ei ollut arvolle sopivaa.

Nykyään en koodaa ollenkaan. On se niin joutavaa...

Tavallaan voi sanoa, että kielen valinta on kuin valitsisi ämpärin: Ämpärissä pysyt.

-Matalan tason kielellä voi tehdä monimutkaisempia asioita.(toteuttaahan jokainen kieli koneeen mikrokäskyjä),
-C suorastaan vapautti mielikuvituksen.
-Algol 68:ssa oli aivan mahtavia piirteitä.

Parasta on kuitenkin ruutupaperi ja B-lyijykynä. Ja kumi.

I Love It!

Ai niin, unohdin sanoa, että olen TI-mies.

En ole samaa mieltä. Muodollinen koulutus on tietenkin iso bonus, mutta parhaat ohjelmoijat ovat niitä, joilla on myös harrastustaustaa ja aito kiinnostus asiaan. Kouluttamatonkin näprääjä pesee kuvitellun rahan perässä alalle hakeutuneen rimaa hipoen korkeakoulutetun 100-0.


Vanhahtavalta kuulostava paletti. Aloittelijan kannattaa aina valita jokin moderni kieli. Harmittaahan se tällaisia vanhoja partoja, kun tietää kuinka helpolla nykyään voi päästä asiassa alkuun. Kielet ja välineet ovat kehittyneet huimasti.

C++ ei ole rehellisesti sanottuna kovin hyvä oliokieli (oikeastaan se on paremminkin moniparadigmakieli). Fortran on jo suorastaan järkyttävän vanhanaikainen (juu, tiedän, että siitä on tuoreitakin painoksia, mutta silti), joskin tieteellisessä laskennassa ilmeisesti edelleen ykkönen.

C on tavallaan elegantti kieli, mutta on se vaan yleiseen käyttöön ja aloittelijalle aivan liian matalatasoinen.


Webbisovelluksien ohjelmointi saattaa jopa olla sieltä vaativimmasta päästä -- riippuen tietenkin ihan siitä, millaista sovellusta tehdään. Erilaisia tekniikoita pitää yleensä tuntea melkoinen nippu, ja alusta on monella tapaa haastava. Google Maps ei ole mikään finninaamaisten kesäharjoittelijoiden kyhäelmä.


Toistan itseäni: parhaat ohjelmoijat ovat niitä, joilla on myös harrastustaustaa ja aito kiinnostus asiaan. Tuo lausunto vie pohjaa kaikilta kommenteiltasi.


Ei pidä paikkaansa. Millä hyvänsä yleiskäyttöisellä ohjelmointikielellä voi tehdä aivan niin mutkikkaita asioita kuin sielu sietää. Korkean tason kielillä se on kuitenkin yleensä huomattavasti helpompaa, sillä ne vapauttavat ohjelmoijan teknisestä näpräämisestä, ja antavat paremmat eväät pureutua muihin haasteisiin. Joissain tapauksissa se näprääminenkin saattaa tietenkin olla varsin viihdyttävää ja palkitsevaa, ja toisinaan se on suorastaan pääasia.

Ainoa korkean tason kielten heikkous on niiden potentiaalinen hitaus. Joskus pitää päästä lähelle rautaa, että riittävät tehot saadaan irti. Tällaiset tilanteet eivät kuitenkaan ole ohjelmointia opetellessa kovin todennäköisiä. Kun minä aloittelin harrastusta, assemblerillakaan ei päässyt kuin muutamaan promilleen siitä tehosta, jonka nykyisin saavuttaa Javalla.

Torvalds on joskus kertonut kehittäneensä Linuxin kernelin C:llä, johon sotkettu assembleria.

Samaan tapaan teen minäkin: esimerkiksi FFT:n ydintä on todella hassua mennä tekemään esimerkiksi C:llä. ASM ja konekieli on ainoa järkevä vaihtoehto reaaliaikaiseen prosessointiin. Käyttäjäliitynnät sun muut tiedostonhallinnat ym. sivuseikat voi sitten tehdä millä haluaa.

C-koodia vastaavan asm-koodin suoritusnopeus on suunnilleen kolminkertainen. Todettu juuri FFT:llä.

Aikoinani -80 luvun alkupuoliskolla, nuorena juippina, aloittelin TI koodauksen sen aikaisilla laitteistoilla ja silloin ei ollut tuon taivallista tietoa mentelmistä, dokumentoinnista, modulaarisuudesta yms. Sitä vaan koodattiin putkeen kaikenlaista ja tuloksena oli tietysti toimiva, mutta varsin "herkkä" tuotos. Pienikin muutos aiheutti julmetun säätämisen koko systeemissä

TI taidoista oli sitten alan koulutuksessa varsin paljon hyötyä. Helpotti kummasti kun osasi sen teknisen näpretelyn entuudestaan. Koulutuksen tuoma hyöty oli siinä, että syystemiä alkoi ajattelemaan paremmin kokonaisuutena. Ja siinä etenkin rajapintojejen tunnistaminen, modulaarisuus ja myöhemmin luokka- ja olioajattelut, dokumentointi jne.

Luulen, että kaveri joka on aikoinaan aloitellut koodauksen TI menetelmillä, hieman kouluttautunut ja harrastaa sitä ammatin ohessa, omaa varsin hyvät eväät tehdä lähes mitä tahansa, mille kielellä tahansa ja missä ympäristössä tahansa.

Kaveri jolla on palava halu koodata, mutta ei kunnon koulutusta, niin ei vaan toimi isommissa järjestelmissä. Näitä on nähty ja tullaan näkemään. Mutta tällaisesta tyypistä saa tehtyä pienellä koulutuksella ja perehdytyksellä hyvän ammattilaisen

Työnantajien pitäisi nykyään katsoa myöskin harrastustaustaa, eikä pelkästään sitä kuinka monta yliopiston SW kurssia kaveri on suorittanut. Yliopiston jannu omaa tietysti hyvät valmiudet, mutta onko sitä "intohimoa"...

TI koodari olisi hyvä ja halpa vaihtoehto monelle alan yritykselle, mutta eipä ne oikein taida antaa mahdollisuuksia. Se on harmi. Kaverit sopisivat varsin hyvin ns. sw factory hommiin, jossa pelkästään speksin pohjalta tuotetaan koodia liukuhihnalta

Ala tarvitsisi riippumattoman "katsastus & kehitysorganisaation" jossa olisi laajasti alan tuntemusta ja kuka vain voisi käydä tarkistamassa missä menee ja mihin suunnata tai aloittaakko olenkaan alalla. Into sen tiettyyn sovellusympäristöön on arvokas ponnin. Ala on hyvin sirpaloitunut sen kaoottisen sovellusviidakon vuoksi. Kaupallinen ristiveto on tässäkin ketjussa nähty.

Kiitos softbuster!
Ikä tuo viisautta.

Aloitin 70-luvun alussa, joten voin kyllä jo levätä.
Opintokirjassa on melko objektiivinen arvio: 3+/3, luulisi sen kelpaavan.

--------------------------
Ei muuten kelvannut. Ämpäreitä riittää joka oksalle.

Kyllä sitä katsotaan, mutta kyllä jokaisen TI-jampan kannattaa käydä hakemassa itselleen edes yksi (mikä tahansa) softa-alan tutkinto, se kertoo kuitenkin työnantajalle jotain kaverin motivaatiosta.

Jep, itselläni on vähän samanlainen tausta kuin softbusterilla. Muodolliseen koulutukseen ajauduin vasta pitkän harrastaneisuuden jälkeen. Kantapään kautta oppiminen on hyvin hidas ja tuskallinen menetelmä, joten TI-jamppojen tosiaan kannattaisi se tutkinto käydä hakemassa. Väittäisin jopa, että asiaan ennalta perehtynyt saa muodollisesta koulutuksesta paljon enemmän irti kuin täysin untuvikko.


Juu, toki -- aikansa kutakin. Mutta että koodaaminen on turhaa touhua? Ohjelmointi on kuitenkin ainoa vaihe tietojärjestelmän kehittämisessä, jota on mahdotonta ohittaa.


Mitähän tuolla oikeastaan tarkoitat? Miksi pitäisi tyytyä yhteen ämpäriin? Tyypillisellä pitkän linjan harrastajalla on kai jonkinlaista tuntumaa vähintään viiteen yleisohjelmointikieleen ja lisäksi nippuun muita kieliä (SQL, XML, HTML jne.). Harrastajan etu on se, että ei ole mitään ammatillista pakkoa pysyä yhdessä ämpärissä.

Useampaan eri paradigmaan tutustuminen on muuten ihan suositeltavaa ohjelmoinnista kiinnostuneelle. Sillä tutullakin ämpärillä alkaa tehdä aivan erilaisia hiekkakakkuja, kun on kokeillut vähän toisenlaista lähestymistapaa.

Kyllä, kyllä

Mutta tunne paljon ihmisiä, joita ei kertakaikkiaan kiinnosta se koulun ns. "turha tieto". He haluavat vain koodailla ja koodaavat lähes mitä tahansa. Heitä ei kiinnosta jonkun matemaattisen yhtälön perustelut yms.

Suomessa on paljon softa-alan työvoimareserviä, jotka haluaisivat alalle ja osaavat koodata. Mutta he eivät osaa opiskella. Joillakin saattaa olla joku terveydellinen este opiskelulle, mutta se ei estä heitä koodaamasta

Onko suomessa tälle alalle mahdollista tehdä oppisopimuskoulutusta ?

Jos ei ole, niin miksi ei ?

Itse voisin ajatella palkkaavani tuon tyyppisiä jannuja tekemään pikku sovelluksia, joihin nyt ei tarvitse mitään korkeakoulututkintoa. Sellasia hommia on paljon.

Milläköhän prosessorilla ja kääntäjällä?

Jos kohteena on joku moderni prosessori, jossa on vähintään puolentusinaa erillistä liukuhihnaa, käskyt suoritetaan "väärässä" järjestyksessä, rekisterien uudelleennimeäminen on käytössä ja hyppyjä ennustetaan spekulatiivisesti, niin saa olla aika mato konekielikoodaaja, ettei tulos ole yli kymentäkertaa hitaampi kuin kunnollisen optimoivan kääntäjän - varsinkin, jos kääntäjässä on optimoidut matematiikkakirjastot.

Lisäksi hyvä kääntäjä osaa itse automaattisesti rinnakkaistaa loopit ja monissa laskentatehtävissä nopeutus voi olla lähes lineaarinen suhteessa ytimien määrään (tietysti vain kohtuullisilla ytimien määrillä).

Tietysti, jos prosessori on simppeli ja käytettävissä oleva kääntäjä huono optimoimaan, niin kyllähän koodin käsinnyplääminen voi kannattaa. Itsekin koodasin joskus opiskeluaikana tutkan signaalinkäsittelyn lopullista maalinosoitusta lukuunottamatta alusta loppuun (sämpläys, ikkunointi, fft, iir ja fir) konekielellä signaaliprosessorille.

C:n ongelma on funktiokutsujen yhteydessä suoritettavat push- ja pop-käskyt. Assemblerilla noiden määrän voi optimoida kullekin funktiolle. Eipä onnistu C-kääntäjillä. Niissä pinotaan rekistereitä aivan riippumatta siitä, tarvitsisiko niitä pinota. Aritmetiikasta tulee aivan turhan kankeaa. Esimerkiksi perhosen koodi, joka assemblerilla on hyvin suoraviivainen, muodostuu todelliseksi sekamelskaksi C:llä kaikkine funktiokutsuineen.