Opiskelin it-alalta tutkinnon. Syvennyin ohjelmointiin (java, c#, xml, tietokannat). Työharjoittelussa koodailin puoli vuotta javaa. Myös harrasteneisuutta on. Tykkään ohjelmoinnista, mutta nyt valmistumisen jälkeen haeskelen työpaikkaa, niin rupesin miettimään, että onkohan ohjelmointi sittenkään mun juttu. Seuraavat asiat mietityttää:
Harjottelussa koin ohjelmoinnin tosi stressaavaksi. Samaan aikaa piti koodata, speksata asiakkaiden kanssa, opetella iso kasa uusia asioita, etsiä tietoa ja testata softa laadukkaaksi. Asiat jäi päähän pyörimään helposti illaksi ja jopa yöksi. Mietiskeli, että mitenköhän sen ja senkin jutun toteuttaisi ja mitä kaikkea huomenna pitää saada aikaan.
Mietityttää myös jaksaako kaiken kiireen keskellä myös koko tulevan elämän opetella koko ajan uutta ? Koskaan ei koe olevan hyvin ammattitaitoinen ja kokenut. Se mitä osaa tänään, niin on arvotonta 10v päästä.
Kiitos jäi hyvin vähäiseksi. Hyviä tekemisiä ei niinkään huomattu, mutta pienikin bugi toi paljon negatiivista palautetta.
Meiltä lähti työpaikalta pari henkilöä. Niiden tilalle ei palkattu Suomesta ketään vaan perustettiin Intiaan pikkunen konttori. Ohjelmointia siirrettiin sinne koko ajan enemmissä määrin tai niin oli ainakin suunnitelmissa. Nähtävästi tuo on aika yleinen trendi. Lehdestä luin, että tieto enator esim. suunnittelee noin puolet 15000 työntekijästään siirtävän halpamaihin.
Oletko törmännyt vastaaviin asioihin vai onko mulla vain näkemystä vain liian pienellä kokemuksella ? Onko nuo syyt tai uhat todellisia ?
Ongelma onkin sitten, että mitä muuta kuin ohjelmointia ? Varmaan sitten se asiakasrajapinta tai suunnittelu ?
Ohjelmoijaksi ?
13
3189
Vastaukset
- Kun sinä
saat kirjoitusvirheesi karsittua, voi koodista tulla
toimivaa, esim.
Varmaan sitten se asiakasrajapinta tai suunnittelu ?
Menee näin:
Varmaan sitten se asiakasrajapinta tai suunnittelu?
Se mitä osaa tänään on arvotonta ½ -vuoden päästä...- KeijoKoodari
Täh? Mihin sitä kirjoitustaitoa koodin kanssa tarvitaan? Haastattelussa riitti kielitaitoon vastaus C , C# ja Java. Kukaan ei todellakaan kysynyt mitkä oli äidinkielen numero.
- World
KeijoKoodari kirjoitti:
Täh? Mihin sitä kirjoitustaitoa koodin kanssa tarvitaan? Haastattelussa riitti kielitaitoon vastaus C , C# ja Java. Kukaan ei todellakaan kysynyt mitkä oli äidinkielen numero.
sellaista se nykyajan työelämä on: työt eivät tekemällä lopu. Lähes kaikki työt on stressaavia, jos siitä ottaa stressiä.
Koodareita tarvitaan jatkossakin paljon ja töitä osaajille riittää aina! - uraaaa
Luulin, että kirjoitin keskustelupalstalle, mutta nähtävästi kirjoitinkin ylioppilasainetta. Ihme, että sait asiasisällöstä kuitenkin selvää kun osasit korjata lauseenikin.
- Linja auto asema
Ehkä sinun kannattaisi tarkistaa, että mikä on Suomi24:n yleinen oikeinkirjoituksen taso. Mielestäni alkuperäinen kirjoittaja kirjoitti harvinaisen hyvää suomea (varsinkin koodaajaksi).
- heh
jos uskoisin jumalaan niin tähän sanoisin, että voi hyvä Jumala sun lapsias...tiedoksi sinulle, että sillä välilyönnillä ei kaikessa koodissa ole merkitystä. Tässä voisi sanoa, että synnitön heittäköön ensimmäisen kiven (eipä tuo sinunkaan kielioppisi näytä virheetöntä olevan...)
- spriilancer
Usko tai älä mutta on hyvä piirre mikäli työt ovat mielessä illallakin. Se kertoo ainakin siitä, että tunnet vastuuta työstäsi. Tätäkin palstaa lukemalla voit huomata, miten iso osa porukasta "on vain töissä". Heitä ei kiinnosta vastaako työ sitä mitä asiakas odottaa saavansa kunhan on kivaa.
Asiakasrajapinta on hankala mutta myös antoisa. Koodari ei voi sulkeutua hermeettiseen kuutioonsa ja tehdä aina niinkuin itse tykkää. Esimerkiksi käytettävyyteen liittyvät muutokset otetaan henkilökohtaisesti, ne kirjataan bugzillaan nimikkeellä "kosmeettinen". Ei osata ajatella sitä, että joku väärä kontrolli jossain akkunassa voi aiheuttaa turhaa työtä käyttäjälle joka esimerkiksi joutuu tarttumaan hiireen sen sijaan että voisi kirjoittaa kaiken näppäimistöltä.
Juuri siellä asiakasrajapinnassa opit mikä työssäsi on olennaista. Olennaista ei ole se että ratkaisee ongelmat niinkuin oppitunnilla neuvottiin vaan se, että softa tekee käyttäjän elämän helpommaksi. Jos et tunne sitä toimialaa jolla käyttäjät työnsä tekevät silloin pitää kuunnella ja opetella. Mikä sen parempaa että voi olla itse yhteydessä käyttäjiin eikä tarvitse luottaa jonkun tekemään rekspekkiin. Samalla pääsee näkemään mihin tehtyä työtä oikeasti käytetään. - ...
Ota huomioon, että olet vasta aloittelemassa uraasi. Alussa on paljon sellaista, mihin kokemus vuosien myötä tuo tukea ja tekee elämän helpommaksi. Jatkossa rutiinit menee selkäytimellä ja energian voi laittaa sitten kiperämpiin juttuihin. Ja asiakkaathan ovat työn suola - ei kun siis sokeri. Mulla ainakin on ollut vain mukavia asiakkaita, joiden kanssa on ollut kiva tehdä töitä ja etsiä ratkaisuja heidän ongelmiinsa. En kuitenkaan suosittelisi, että annat työasioiden tulla mukana himaan ihan jatkuvasti. Pitää muistaa pitää elämässä tasapaino työn ja muiden asioiden välillä. Jos jompikumpi horjuu, toinen on ainakin vielä pystyssä.
Tämä ulkoistaminen on tämän päivän trendi, mutta onko se sitä myös huomenna. Maailma muuttuu koko ajan. Kymmenen vuoden kuluttua tilanne voi olla kokonaan toinen. Jos ala kiinnostaa, kannattaa panostaa. Tai sitten etsiä joku toinen homma. Ennen saattoi kuvitella tekevänsä uran samoissa hommissa, jopa saman työnantajan leivissä. Nykyään kannattaa asennoitua muutokseen. Kymmenen vuotta yhtä asiaa on tarpeeksi pitkä aika. - Mika0800
Mikähän siinä on, että suuret yritykset käyttävät pääasiassa C/C /C# -kieliä, vaikka varsinkin 2 ensinmainittua pitäisi tietää riskialttiiksi ?
Tietenkin, koodasipa millä kielellä tahansa, on aina pyrittävä tekemään huolellista työtä.
Mutta C ja C -kielillä koodatut ohjelmat ovat tunnettuja puskurin ylivuotohyökkäyksen mahdollistavista ohjelmointivirheistä.
Virheen syy sinänsä on tietenkin väärin kirjoitettu koodi, ja koodi ei tietenkään voi toimia oikein, jos sitä ei ole kirjoitettu oikein.
Eli ainoa tapa saada koodi toimimaan oikein, on kirjoittaa koodi oikein.
Mutta: mitä tekee väärin kirjoitettu koodi ?
C ja C -ohjelmissa seuraus ohjelmointivirheestä on väärin toimiva ohjelma JA ammottava tietoturvareikä, joka mahdollistaa puskurin ylivuotohyökkäyksen.
Delphi -ohjelmassa seuraus ohjelmointivirheestä on väärin toimiva ohjelma MUTTA EI ammottavaa tietoturvareikää, joka mahdollistaisi puskurin ylivuotohyökkäykstä. Siis jos Delphillä mokaat, niin ohjelmasi ei tietenkään voi toimia oikein, mutta ei se myöskään aiheuta tietoturvareikää.
Tässä vielä Delphillä tehty esimerkkiohjelma, joka demonstroi 3 tapaa käsitellä puskureita:
1. Oikea tapa
2. Väärä tapa, joka ei siltikään mahdollista tietoturvahyökkäystä, vaikkakin sotkee ohjelman.
3. Väärä tapa, jossa hyökkääjä voisi ajaa omaa koodiaan koneessa, jossa tätä ohjelmaa ajetaan.
Ja tässä DELPHI -koodi:
unit TestBugMF;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls;
type
TForm1 = class(TForm)
bnVaarallinenMetodi: TButton;
bnTurvallinenMetodi: TButton;
bnOikein: TButton;
procedure bnVaarallinenMetodiClick(Sender: TObject);
procedure bnTurvallinenMetodiClick(Sender: TObject);
procedure bnOikeinClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
procedure TestIt(P:PChar; MaxLen:Integer);
procedure TestIt_Korjattu(P:PChar; MaxLen:Integer);
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
const
BufLen = 1024;
procedure TForm1.bnVaarallinenMetodiClick(Sender: TObject);
var
Buffer : Array[0..BufLen-1] of AnsiChar;
begin
// VAARA: Tämä mahdollistaa puskurin ylivuotohyökkäyksen (tai mahdollistaisi,
// jos data tulisi netistä). Mutta pinon tämä sotkee, joten ohjelma kaatuu, kun
// metodi "palaa" paikkaan, josta sitä ei koskaan kutsuttu !
TestIt(Buffer, BufLen); // Tämä tekee juuri sen, mihin
// C ja C -ohjelmoijat niin usein syyllistyvät:
// Tämä sotkee pinon kirjoittamalla paikalliseen
// muuttujaan Buffer liikaa dataa, mikä mm.
// ylikirjoittaa funktion paluuosoitteen !
// Jos data ei olisikaan testiohjelman tuottamia
// 'n' -kirjaimia, vaan esim. netistä vihamieliseltä koneelta
// tulevaa dataa, niin järjestelmäsi tietoturvaa vastaan olisi
// nyt helppoa tehdä puskurin ylivuotohyökkäys !
// Vaikka kielenä on Delphi, koodaustyyli tässä on matkittu suoraan
// huonoista C ja C -ohjelmista.
// Älä koskaan tee näin omissa ohjelmissasi !
end;
procedure TForm1.TestIt(P: PChar; MaxLen: Integer);
begin
// SIMULAATIO:
// Tässä kirjoitetaan vain 'n' -kirjainta. Mutta jos data ei olisikaan vakio ja
// pelkkää 'n' -kirjainta, vaan tulisi netistä vieraalta ja vihamieliseltä koneelta...
// niin seuraus ei olisi pelkkä ohjelman sekoaminen, vaan tässä annettaisiin hyökkääjän ajaa
// omaa koodiaan, jos kutsu tehdään bnVaarallinenMetodiClick(...) :stä.
// Mitä tapahtuukaan, jos metodi TestIt(...) ei
// noudatakaan annettua MaxLen -parametriä,
// vaan kirjoittaa osoittimen P osoittamaan paikkaan
// enemmän kuin MaxLen merkkiä ???
// Tässä tehdään tahallaan moka (Älä tee näin omassa koodissasi):
FillChar(P[0], 2 * MaxLen, 'n');
// Kirjoitetaan P:n osoittamaan paikkaan 2 kertaa sallitun pituinen määrä
// 'n' -kirjainta.
end;
procedure TForm1.bnTurvallinenMetodiClick(Sender: TObject);
var
BufferSt : String;
begin
//
SetLength(BufferSt, BufLen); // Nyt mekkijonoon mahtuu BufLen merkkiä
// Tässä mokataan jälleen....
TestIt(PChar(BufferSt), BufLen); // Tämä kirjoittaa myös merkkijonoon enemmän dataa...
// kuin sinne mahtuu. Eli ei näinkään pidä tehdä, koska seurauksena on väärin toimiva
// ohjelma. Mutta: siinä, missä bnVaarallinenMetodiClick() sisältää ammottavan tieto-
// turvareiän, tässä aiheutuu sen sijaan "AccessViolation" -poikkeus.
// Tämä on tietoturvallisempi tapa koodata (vaikka sisältääkin ...
// koodausvirheen, koska tarkoitus on demonstroida, miksi Delphi on turvallisempi MYÖS
// silloin, kun ohjelmoija möhlii.
// Tietenkään tämä ei ole mikään peruste, miksi Delphillä saisi/kannattaisi möhliä.
// Tottakai myös Delphi -ohjelmoijan on syytä koodata koodinsa oikein.
// Mutta jos ohjelmoija kaikesta huolimatta mokaa, tämä metodi EI aiheuta tietoturvareikää,
// mutta kylläkin EAccessViolation -poikkeuksen.
// Ymmärrätkö eron: miksi tämä metodi on tietoturvallinen virheestään huolimatta,
// mutta bnVaarallinenMetodiClick() puolestaan sisältää ammottavan tietoturvareiän ?
// Mikäli et ymmärrä eroa, on syytä vielä opetella lisää koodauksen saloja...
// ennen oikeasti tärkeiden systeemien ohjelmoimista !
end;
procedure TForm1.bnOikeinClick(Sender: TObject);
var
BufferSt : String;
begin
//
SetLength(BufferSt, BufLen); // Nyt mekkijonoon mahtuu BufLen merkkiä
TestIt_Korjattu(PChar(BufferSt), BufLen);
end;
procedure TForm1.TestIt_Korjattu(P: PChar; MaxLen: Integer);
begin
FillChar(P[0], MaxLen, 'n');
// Kirjoitetaan P:n osoittamaan paikkaan sallitun pituinen määrä
// 'n' -kirjainta. Mitään ongelmaa ei nyt ole.
end;
end.C lienee ainoa järkevä ja takuutoimivaksi havaittu kieli toteuttaa vähänkään laitteistojen alemman tason käsiksi pääsyä vaativia juttuja. Javan, Delphin tai vastaavan korkeamman tason kielen käyttämisen siirtymiseen ehdottajalle esim. GSM/3G-puhelinverkon elementtien toteuttamisessa takuulla tultaisiin nauramaan päin naamaa. Tuo on vain yksi paikka, jossa on pakko saada tehtyä tasan sitä mitä halutaan, eikä vain miettiä, miten jonkun kielen hienostuneet ominaisuudet saadaan kierrettyä (kuten vaikka odottamatta käynnistyvä muistin roskankeruuprosessi oliokielissä jne.).
C/C :lla on tietysti helppo kämmätä vaikka muistinvarauksessa ja muistinkäsittelyssä, mutta se vain on niiden käyttämisen hintana, johon pitää varautua. Palkinnoksi saadaan kuitenkin sellainen systeemi kuin itse halutaan.
Eikä ihan kaikki ohjelmointivirheet sentään luo mahdollisuutta puskurien ylivuotoihin...- Mika0800
Mik26 kirjoitti:
C lienee ainoa järkevä ja takuutoimivaksi havaittu kieli toteuttaa vähänkään laitteistojen alemman tason käsiksi pääsyä vaativia juttuja. Javan, Delphin tai vastaavan korkeamman tason kielen käyttämisen siirtymiseen ehdottajalle esim. GSM/3G-puhelinverkon elementtien toteuttamisessa takuulla tultaisiin nauramaan päin naamaa. Tuo on vain yksi paikka, jossa on pakko saada tehtyä tasan sitä mitä halutaan, eikä vain miettiä, miten jonkun kielen hienostuneet ominaisuudet saadaan kierrettyä (kuten vaikka odottamatta käynnistyvä muistin roskankeruuprosessi oliokielissä jne.).
C/C :lla on tietysti helppo kämmätä vaikka muistinvarauksessa ja muistinkäsittelyssä, mutta se vain on niiden käyttämisen hintana, johon pitää varautua. Palkinnoksi saadaan kuitenkin sellainen systeemi kuin itse halutaan.
Eikä ihan kaikki ohjelmointivirheet sentään luo mahdollisuutta puskurien ylivuotoihin..."C lienee ainoa järkevä ja takuutoimivaksi havaittu kieli toteuttaa vähänkään laitteistojen alemman tason käsiksi pääsyä vaativia juttuja"
Ja mikähän estää Delphissä käsittelemästä sen paremmin suoraa laite-IO:ta I/O -portteihin kuin suoraa muistiosoitustakaan.
Win NT, 2000, XP -systeemeissä tuo tietenkin edellyttää esim. GiveIO -ajuria (muuten ei Userland -ohjelmista ole asiaa IO -portteihin tai suoriin muistiosoituksiin oman muistiavaruuden ulkopuolelle).
Mutta ainakin Win98:ssa Delphi pelaa hyvin yhteen VxD:n kanssa DeviceIoControl -funktiolla.
Ja linuxissa taas, kunhan ohjelma ajetaan root -oikeuksin, sillä on täysi pääsy laitteistoon. Linuxissa toki Delphin korvaa Kylix.
Ja em. VxD:tä voi hyvin ohjelmoida assemblerilla.
"Javan, Delphin tai vastaavan korkeamman tason kielen käyttämisen siirtymiseen ehdottajalle esim. GSM/3G-puhelinverkon elementtien toteuttamisessa takuulla tultaisiin nauramaan päin naamaa.
En epäile. Tosin tuo kertoo sen naurajan ammattitaidottomuudesta; Delphi tai Linuxissa Kylix pystyy sovellusohjelmien osalta siihen mihin C:kin. Ja laiteajurien osalta Linuxista löytyy FreePascal ja kyllä senkin kanssa varmasti saadaan assembler pelaamaan yhteen.
Java muuten käännetään bytekoodiksi, Delphi ja Kylix natiiviksi WIN32 EXE:ksi tai Linuxin ELF -binääriksi. Delphi ei ole siis Javan kanssa samalla viivalla. Päinvastoin, Delphin suorituskyky on C:hen ja C :aan verrannollinen, vain syntaksi on paljon selkeämpää.
"eikä vain miettiä, miten jonkun kielen hienostuneet ominaisuudet saadaan kierrettyä"
Delphin ominaisuuksia ei tarvitse kiertää. Perusasiat tulee toki osata, mutta niin on muidenkin kielien osalta.
"kuten vaikka odottamatta käynnistyvä muistin roskankeruuprosessi oliokielissä"
Delphi on oliokieli (kuten C ) mutta ei siinä yllättäen mikään roskienkeruuprosessi käynnisty, vaan kun jokin muistialue (FreeMem) tai objekti ( FreeAndNil(Obj1) tai Obj1.Free ) vapautetaan, tuo muistialue lisätään vapaiden alueiden listaan, ja samalla katsotaan jos sen alku/loppureuna muodostaa yhtenäisen vapaan isomman muistialueen; jos näin on, se automaattisesti yhdistetään niihin.
Lisäksi Delphi tarjoaa suoran pääsyn Windows API -kutsuihin ( esim. GlobalAlloc, GlobalFree ja VirtualAlloc, VirtualFree, VirtualProtect jne.).
Sama pätee Kylixiin, mutta tällöin tietenkin Linux API:n osalta.
Itseasiassa asian voisi ilmaista näinkin: Delphi on kuten C , mutta paljon selkeämmällä syntaksilla. Itseasiassa, asia joka usein yllättää Delphistä tietämättömät C -ohjelmoijat, on tämä:
Delphissä luokan konstruktori voi itse päättää, missä vaiheessa kutsutaan perityn luokan konstruktoria, tai jättää sen kokonaan kutsumatta, jos niin parhaaksi näkee. Jälkimmäistä toki käytetään vain silloin, kun tiedetään, ettei perityn luokan konstruktori tee mitään tärkeää (esim. TObject).
Delphissä myöskään mikään luokan esiintymä ei vapaudu mitenkään automaattisesti, vaan se vapautetaan Free tai FreeAndNil -funktioilla.
Poikkeuksena toisen ilmentymän omistamat instanssit, jotka tuon omistajan Destroy -metodi vapauttaa. Samoin poikkeuksena ovat Interfacet, joissa, kun käyttölaskuri putoaa nollaan, seuraa automaattinen vapautus.
Erona on myös moniperintä: Delphin filosofiaan kuuluu se, että C :n kaltaista luokkatason moniperintää pidetään haitallisena ja sekavana ja siksi ongelmia aiheuttavana. Siksi Delphissä luokkatason moniperintää ei ole, vaan kukin luokka voi suoraan periytyä vain yhdestä luokasta (joka toki voi edelleen periytyä toisesta luokasta jne, eli luokkahierarkia on olemassa).
Sensijaan Interfaceja yksi luokka voi toteuttaa useita. Tämä onkin selkeämpi lähtökohta "moniperinnälle".
Delphi ei myöskään anna mahdollisuutta syntaksilla kämmäämiseen C:n tapaan:
if a = b {
}
kun pitäisi olla:
if a == b {
}
Delphissä sijoitus on := ja yhtäsuuruusvertailu =.
Jos tosiaan erehdyksessä kirjoittaisit Delphissä:
if a := b then begin
end;
niin Delphi ilmoittaa käännösaikaisesta virheestä.
Mielenkiintoista on sekin, että googlettamalla löysin viestin, jossa joku yritti perustella C:n paremmuutta Pascal -pohjaisiin kieliin sillä, että kirjoitti yksirivisen mallikoodin, ja esitti, että Pascalilla tarvitaan useita rivejä.
Kyseinen hemmo ironisesti itse tahtomattaan todisti oikeaksi väitteeni C -kielen syntaksin sekavuudesta: alku- ja loppusulkujen määrä ei vastannut toisiaan! Jos C on niin selkeää, kuin se C -ohjelmoijien mielestä ilmeisesti on, miksi sitten yksinkertaiseen esimerkkikoodiinkin saadaan mahtumaan syntaksivirhe ?!
Kokeilin asiaa: kyllä tuon sai väännetyksi yksiriviseksi Delphi -koodiksikin, tosin tuolla tavalla C-kielen tyyliä matkitusti tehty Delphi -koodi on melkein yhtä lukukelvotonta kuin C -koodikin.
Joiltakuilta eri kielipuiden vertailijoilta unohtuu se, ettei mikään ohjelmointikieli ole olemassa tyhjiössä, vaan kielten sukupuu menee suunnilleen näin:
A-kieli -> B-kieli -> C-kieli -> C
ja vastaavasti Pascal -haara:
Pascal -> Turbo Pascal -> Borland ObjectPascal -> Delphi
Tässä ketjussa siis tuo pelkkä "Pascal" sana viittaa johonkin Niklaus Wirthin 1950 -luvulta peräisin olevaan varsin rajoittuneeseen kieleen!
Ja silti jotkut jaksavat postailla C vs. Pascal -stooreja, joissa vertaavat C-haaran 2. uusinta jäsentä tuon Pascal -haaran ensimmäiseen, ja selvähän se on, että joku 1950 -luvulta oleva rajoittunut opetuskieli sellaisenaan ei voi olla vertailukelpoinen nykyaikaisten ohjelmointityövälineiden kanssa.
Itse muuten olen koodannut Delphillä automaattisen puhelinpalvelujärjestelmän. Se ei ole kertaakaan jumiutunut Delphiin liittyvien ongelmien takia, sensijaan windowsin epävakaus joskus kaataa sen.
Mutta juuri siksi tulen siirtämään sen Kylix -ohjelmaksi Linux -alustalle. Linux on varsin vakaa ja luotettava käyttöjärjestelmäalusta, ja olettaisin linuxiin siirtymisen jälkeen luotettavuuden olevan erinomaista tasoa.
Ja naurakoot tietämättömät pomot ihan mille haluavat, mutta uskoisinpa, että jos koodaan Kylixillä vaikkapa sitten jotain GSM:ään liityvää, niin ei varmasti kaadu ohjelmointivälineestä johtuvista syistä. Eikä linuxin tuntien tuskin käyttöjärjestelmään liittyvistäkään syistä.
Eli jos hommassa käytetään muulla välineellä tehtyä laiteajuria, etsisin mahdollisten softaongelmien osalta syytä niistä. Ja jos taas I/O tehdään suoraan Kylix -ohjelmasta, on syytä epäillä laiteongelmia, ei ohjelmistoa.
Viimeksi mainittu toki sillä edellytyksellä, ettei laitteella ole tiukkoja ajastusvaatimuksia.
Ok, jos kyseessä on puheludatan (ääni, GSM/GPRS data) välitys, niitähän on, mutta silloin ei varmasti voitaisikaan käyttää Linuxin vakiokerneliä, vaan sellaista, joka on räätälöity niin, että yksi userland -ohjelma voidaan määrittää etuoikeutetuksi niin, että sille taataan funktio, jota kutsutaan määrävälein.
Mutta laitteen ajoitusvaatimukset on monimerkityksinen käsite. Ja täsmennettäköön, että jos em. systeemissä sallitaan minkään (myöskään kernelin itsensä) keskeyttää aikakriittinen funktio, niin pieleen menee. Jos ei userland -ohjelmalle voida taata edellisen lisäksi myös keskeytyksetöntä aikajaksoa aikakriittisen I/O:n tekemiseen, silloin oikea paikka noiden asioiden tekemiseen on laiteohjain, ei userland -ohjelma. - hmmhmm
Mika0800 kirjoitti:
"C lienee ainoa järkevä ja takuutoimivaksi havaittu kieli toteuttaa vähänkään laitteistojen alemman tason käsiksi pääsyä vaativia juttuja"
Ja mikähän estää Delphissä käsittelemästä sen paremmin suoraa laite-IO:ta I/O -portteihin kuin suoraa muistiosoitustakaan.
Win NT, 2000, XP -systeemeissä tuo tietenkin edellyttää esim. GiveIO -ajuria (muuten ei Userland -ohjelmista ole asiaa IO -portteihin tai suoriin muistiosoituksiin oman muistiavaruuden ulkopuolelle).
Mutta ainakin Win98:ssa Delphi pelaa hyvin yhteen VxD:n kanssa DeviceIoControl -funktiolla.
Ja linuxissa taas, kunhan ohjelma ajetaan root -oikeuksin, sillä on täysi pääsy laitteistoon. Linuxissa toki Delphin korvaa Kylix.
Ja em. VxD:tä voi hyvin ohjelmoida assemblerilla.
"Javan, Delphin tai vastaavan korkeamman tason kielen käyttämisen siirtymiseen ehdottajalle esim. GSM/3G-puhelinverkon elementtien toteuttamisessa takuulla tultaisiin nauramaan päin naamaa.
En epäile. Tosin tuo kertoo sen naurajan ammattitaidottomuudesta; Delphi tai Linuxissa Kylix pystyy sovellusohjelmien osalta siihen mihin C:kin. Ja laiteajurien osalta Linuxista löytyy FreePascal ja kyllä senkin kanssa varmasti saadaan assembler pelaamaan yhteen.
Java muuten käännetään bytekoodiksi, Delphi ja Kylix natiiviksi WIN32 EXE:ksi tai Linuxin ELF -binääriksi. Delphi ei ole siis Javan kanssa samalla viivalla. Päinvastoin, Delphin suorituskyky on C:hen ja C :aan verrannollinen, vain syntaksi on paljon selkeämpää.
"eikä vain miettiä, miten jonkun kielen hienostuneet ominaisuudet saadaan kierrettyä"
Delphin ominaisuuksia ei tarvitse kiertää. Perusasiat tulee toki osata, mutta niin on muidenkin kielien osalta.
"kuten vaikka odottamatta käynnistyvä muistin roskankeruuprosessi oliokielissä"
Delphi on oliokieli (kuten C ) mutta ei siinä yllättäen mikään roskienkeruuprosessi käynnisty, vaan kun jokin muistialue (FreeMem) tai objekti ( FreeAndNil(Obj1) tai Obj1.Free ) vapautetaan, tuo muistialue lisätään vapaiden alueiden listaan, ja samalla katsotaan jos sen alku/loppureuna muodostaa yhtenäisen vapaan isomman muistialueen; jos näin on, se automaattisesti yhdistetään niihin.
Lisäksi Delphi tarjoaa suoran pääsyn Windows API -kutsuihin ( esim. GlobalAlloc, GlobalFree ja VirtualAlloc, VirtualFree, VirtualProtect jne.).
Sama pätee Kylixiin, mutta tällöin tietenkin Linux API:n osalta.
Itseasiassa asian voisi ilmaista näinkin: Delphi on kuten C , mutta paljon selkeämmällä syntaksilla. Itseasiassa, asia joka usein yllättää Delphistä tietämättömät C -ohjelmoijat, on tämä:
Delphissä luokan konstruktori voi itse päättää, missä vaiheessa kutsutaan perityn luokan konstruktoria, tai jättää sen kokonaan kutsumatta, jos niin parhaaksi näkee. Jälkimmäistä toki käytetään vain silloin, kun tiedetään, ettei perityn luokan konstruktori tee mitään tärkeää (esim. TObject).
Delphissä myöskään mikään luokan esiintymä ei vapaudu mitenkään automaattisesti, vaan se vapautetaan Free tai FreeAndNil -funktioilla.
Poikkeuksena toisen ilmentymän omistamat instanssit, jotka tuon omistajan Destroy -metodi vapauttaa. Samoin poikkeuksena ovat Interfacet, joissa, kun käyttölaskuri putoaa nollaan, seuraa automaattinen vapautus.
Erona on myös moniperintä: Delphin filosofiaan kuuluu se, että C :n kaltaista luokkatason moniperintää pidetään haitallisena ja sekavana ja siksi ongelmia aiheuttavana. Siksi Delphissä luokkatason moniperintää ei ole, vaan kukin luokka voi suoraan periytyä vain yhdestä luokasta (joka toki voi edelleen periytyä toisesta luokasta jne, eli luokkahierarkia on olemassa).
Sensijaan Interfaceja yksi luokka voi toteuttaa useita. Tämä onkin selkeämpi lähtökohta "moniperinnälle".
Delphi ei myöskään anna mahdollisuutta syntaksilla kämmäämiseen C:n tapaan:
if a = b {
}
kun pitäisi olla:
if a == b {
}
Delphissä sijoitus on := ja yhtäsuuruusvertailu =.
Jos tosiaan erehdyksessä kirjoittaisit Delphissä:
if a := b then begin
end;
niin Delphi ilmoittaa käännösaikaisesta virheestä.
Mielenkiintoista on sekin, että googlettamalla löysin viestin, jossa joku yritti perustella C:n paremmuutta Pascal -pohjaisiin kieliin sillä, että kirjoitti yksirivisen mallikoodin, ja esitti, että Pascalilla tarvitaan useita rivejä.
Kyseinen hemmo ironisesti itse tahtomattaan todisti oikeaksi väitteeni C -kielen syntaksin sekavuudesta: alku- ja loppusulkujen määrä ei vastannut toisiaan! Jos C on niin selkeää, kuin se C -ohjelmoijien mielestä ilmeisesti on, miksi sitten yksinkertaiseen esimerkkikoodiinkin saadaan mahtumaan syntaksivirhe ?!
Kokeilin asiaa: kyllä tuon sai väännetyksi yksiriviseksi Delphi -koodiksikin, tosin tuolla tavalla C-kielen tyyliä matkitusti tehty Delphi -koodi on melkein yhtä lukukelvotonta kuin C -koodikin.
Joiltakuilta eri kielipuiden vertailijoilta unohtuu se, ettei mikään ohjelmointikieli ole olemassa tyhjiössä, vaan kielten sukupuu menee suunnilleen näin:
A-kieli -> B-kieli -> C-kieli -> C
ja vastaavasti Pascal -haara:
Pascal -> Turbo Pascal -> Borland ObjectPascal -> Delphi
Tässä ketjussa siis tuo pelkkä "Pascal" sana viittaa johonkin Niklaus Wirthin 1950 -luvulta peräisin olevaan varsin rajoittuneeseen kieleen!
Ja silti jotkut jaksavat postailla C vs. Pascal -stooreja, joissa vertaavat C-haaran 2. uusinta jäsentä tuon Pascal -haaran ensimmäiseen, ja selvähän se on, että joku 1950 -luvulta oleva rajoittunut opetuskieli sellaisenaan ei voi olla vertailukelpoinen nykyaikaisten ohjelmointityövälineiden kanssa.
Itse muuten olen koodannut Delphillä automaattisen puhelinpalvelujärjestelmän. Se ei ole kertaakaan jumiutunut Delphiin liittyvien ongelmien takia, sensijaan windowsin epävakaus joskus kaataa sen.
Mutta juuri siksi tulen siirtämään sen Kylix -ohjelmaksi Linux -alustalle. Linux on varsin vakaa ja luotettava käyttöjärjestelmäalusta, ja olettaisin linuxiin siirtymisen jälkeen luotettavuuden olevan erinomaista tasoa.
Ja naurakoot tietämättömät pomot ihan mille haluavat, mutta uskoisinpa, että jos koodaan Kylixillä vaikkapa sitten jotain GSM:ään liityvää, niin ei varmasti kaadu ohjelmointivälineestä johtuvista syistä. Eikä linuxin tuntien tuskin käyttöjärjestelmään liittyvistäkään syistä.
Eli jos hommassa käytetään muulla välineellä tehtyä laiteajuria, etsisin mahdollisten softaongelmien osalta syytä niistä. Ja jos taas I/O tehdään suoraan Kylix -ohjelmasta, on syytä epäillä laiteongelmia, ei ohjelmistoa.
Viimeksi mainittu toki sillä edellytyksellä, ettei laitteella ole tiukkoja ajastusvaatimuksia.
Ok, jos kyseessä on puheludatan (ääni, GSM/GPRS data) välitys, niitähän on, mutta silloin ei varmasti voitaisikaan käyttää Linuxin vakiokerneliä, vaan sellaista, joka on räätälöity niin, että yksi userland -ohjelma voidaan määrittää etuoikeutetuksi niin, että sille taataan funktio, jota kutsutaan määrävälein.
Mutta laitteen ajoitusvaatimukset on monimerkityksinen käsite. Ja täsmennettäköön, että jos em. systeemissä sallitaan minkään (myöskään kernelin itsensä) keskeyttää aikakriittinen funktio, niin pieleen menee. Jos ei userland -ohjelmalle voida taata edellisen lisäksi myös keskeytyksetöntä aikajaksoa aikakriittisen I/O:n tekemiseen, silloin oikea paikka noiden asioiden tekemiseen on laiteohjain, ei userland -ohjelma."En epäile. Tosin tuo kertoo sen naurajan ammattitaidottomuudesta; Delphi tai Linuxissa Kylix pystyy sovellusohjelmien osalta siihen mihin C:kin. Ja laiteajurien osalta Linuxista löytyy FreePascal ja kyllä senkin kanssa varmasti saadaan assembler pelaamaan yhteen. "
Käsittääkseni Delphiä/Kylix koodia ei voida kumminkaan kääntää arm, mips etc. prosessoriarkkitehtuureille. Arkkitehtuureille joissa vallitsevat myöskin rajat käytettävälle muistille.
"Delphin suorituskyky on C:hen ja C :aan verrannollinen, vain syntaksi on paljon selkeämpää."
Otetaan esimerkiksi 3D pelit en jaksa uskoa että Delphillä päästään samoihin tuloksiin.
Tässä tulee heti mieleen template metaprogramming - mahdollistaako Delphi moisen? Pitäisikö kaikki esim. rekursiiviset laskutoimitukset unrollata?
Onko delphin kääntäjälle mahdollista kertoa että tee loopille unroll? Pystytäänkö muistia käsittelemään freimeittäin - omaa muistinhallintaa? Kuinka hyvin Delhi kääntäjää voidaan optimoida?
Hyvää settiä muuten tiedän enemmän Delphistä tällä hetkellä. - Mika0800
hmmhmm kirjoitti:
"En epäile. Tosin tuo kertoo sen naurajan ammattitaidottomuudesta; Delphi tai Linuxissa Kylix pystyy sovellusohjelmien osalta siihen mihin C:kin. Ja laiteajurien osalta Linuxista löytyy FreePascal ja kyllä senkin kanssa varmasti saadaan assembler pelaamaan yhteen. "
Käsittääkseni Delphiä/Kylix koodia ei voida kumminkaan kääntää arm, mips etc. prosessoriarkkitehtuureille. Arkkitehtuureille joissa vallitsevat myöskin rajat käytettävälle muistille.
"Delphin suorituskyky on C:hen ja C :aan verrannollinen, vain syntaksi on paljon selkeämpää."
Otetaan esimerkiksi 3D pelit en jaksa uskoa että Delphillä päästään samoihin tuloksiin.
Tässä tulee heti mieleen template metaprogramming - mahdollistaako Delphi moisen? Pitäisikö kaikki esim. rekursiiviset laskutoimitukset unrollata?
Onko delphin kääntäjälle mahdollista kertoa että tee loopille unroll? Pystytäänkö muistia käsittelemään freimeittäin - omaa muistinhallintaa? Kuinka hyvin Delhi kääntäjää voidaan optimoida?
Hyvää settiä muuten tiedän enemmän Delphistä tällä hetkellä."Käsittääkseni Delphiä/Kylix koodia ei voida kumminkaan kääntää arm, mips etc. prosessoriarkkitehtuureille. Arkkitehtuureille joissa vallitsevat myöskin rajat käytettävälle muistille. "
No suoranaisesti Delphiä et tosiaankaan voi käyttää harvinaisemmille arkkitehtuureille. Delphi siis Windowsille ja Kylix PC-laitealustalla pyöriville linuxeille. FreePascalilla (ja jos GUI, myös Lazaruksella) voi käsittääkseni koodata muillekin Linuxeille kuin PC-alustalle.
En ole itse käyttänyt FreePascalia, joten tarkista jos asia on tärkeä.
Mitä tulee noihin mikrokontrollereihin, niin googletapa näillä: rainier iafrica.
Ei ihan Delphiä, mutta sanotaan että Delphin osajoukko, jossa objektit on jätetty pois. Jos muistin määrä on niin rajallinen kuin se monessa mikrokontrollerissa on, niin objektit kätevyydestään huolimatta rikkovat nopeasti todella tiukat muistivaatimukset.
Pelien osalta: ensinnäkin: peliohjelmoijat usein "elvistelevät".... mietipä sitä, että liikkuvaa videokuvaa esitetään euroopassa 25 framea/sek eli 40 ms/frame. Miksi sitten peliohjelmoijat eivät laita windowspeleissään pelisilmukkaansa sleep(1) joka nukuttaa säikeen 1 ms ajaksi ?!
Vähentäisi huomattavasti CPU -kuormaa (joka monessa pelissä nykyään kokoajan 100%, aivan tarpeettomasti).
Delphissä ei ole C/C :n kaltaista makrosysteemiä, joten jos tuo "template metaprogramming" perustuu C -kielen makroihin niin ei. Mutta ammattitaitoinen ohjelmoija löytää varmasti myös Delphistä sellaisia näppäriä ominaisuuksia joita esim C :ssa ei ole. mm. paljon kätevämpi ja turvallisempi merkkijonokäsittely (mutta silti yhteensopivuus NULL -loppuisiin C/C -merkkijonoihin; nämähän ovat usein esim. wiundows API -kutsuissa tarpeen), sekä joukkotoiminnot. Siis kyllä: matematiikasta tuttu joukko-oppi kunniaan!
"Pitäisikö kaikki esim. rekursiiviset laskutoimitukset unrollata?"
Toki rekursio on sallittu menetelmä, eli mitään pakkoa välttää sitä ei ole. Toki kannattaa rekursiossa miettiä, mitkä muuttujat on pakko luoda jokaiselle kutsukerralle erikseen, ja muut muuttujat pois autom. luotavien joukosta. Vähentää kivasti muistinkulutusta.
"Onko delphin kääntäjälle mahdollista kertoa että tee loopille unroll?"
Tietääkseni ei. Mutta eipä yleensä ole tarpeenkaan.
Itseasiassa tein kerran MD5 -laskuohjelman Delphillä. Nykykoneissa taatusti riittävän nopea, mutta koska halusin siitä pätevän myös esim. vanhoissa 120-180 MHz pentium (pro) koneissa, niin kokeilin mitä vaikutti assemlerilla luupin kirjoitus auki eli sama koodi useaan kertaan jolloin hyppykäskyt vähenevät. Yllätyksekseni nopeus ei muuttunut kuin hyvin vähän, ei uudessa eikä vanhassa koneessa ! Eli yleensä tuo unrollaus ei ole niin tarpeellinen kuin moni luulee.
Delphiin voi suoraan linkata {$L file1.obj}
tyyliin erillisellä assemblerilla käännettyjä moduleita. Borlandin asm kelpaa sellaisenaan, ja MS:n asminkin saa kelpaamaan kun antaa ML.EXE:lle oikean käännösoption, jolla obj tulee oikeaan muotoon (OMF / COFF). Tuossa tapauksessa voit tietenkin ottaa assemblerin makroista kaiken iloin irti.
Pienempiä määriä asmia saa laittaa suoraan delphi -koodin sekaan asm ... end -avainsanoilla.
"Pystytäänkö muistia käsittelemään freimeittäin - omaa muistinhallintaa?"
Tuohon ei ole mitään erityistä valmista toimintoa, mutta tein kerran Delphillä luokan, joka ottaa täyden hyödyn irti windowsin API -funktioista VirtualAlloc ja VirtualFree. Näillähän voi erottaa toisistaan muistiavaruuden varauksen ja varsinaisen muistin varauksen.
Voit siis esim. varata tilaa datalle, joka tarvitsee heti 4 kilotavua, mutta saattaa kasvaa jopa 20 megatavuun. Siis varaamalla 20 megatavua muistiavaruutta mutta liittämällä siihen aluksi vain 4 kilotavua muistia. Lisää voi liittää kasvavan tarpeen mukaan. Hyötynä se, että jos data tosiaan kasvaa siihen 20 megatavuun, sillä on silti yhtenäinen muistiosoiteavaruus, ja jos ei kasva, muistia kuluu vain tarpeen mukaan.
Ja tuollaisen Delphi -luokan kun kerran tekee, sitä voi toki hyödyntää jatkossa ja/tai periä siitä uusi luokka jos tarpeisiin tulee pieni muutos...
Lisäksi muistinhaliintaguruille löytyy GetMemoryManager ja SetMemoryManager, joilla voi korvata Delphin oletusmuistinhallinnan omatekoisella, jos uskoo pystyvänsä tekemään sen Borlandia paremmin.
Samoin luokalle voi määritellä normaalista poikkeavan tavan varata/vapauttaa luokan datan muistialue. Kätevää, jos tiedät etukäteen tarvitsevasi 10.000 instanssia samasta luokasta, ja haluat optimoida muistinkäsittelyn nopeuden. En ole koskaan tarvinnut tuota, mutta on hyvä tietää, että se on käytettävissä jos joskus tarvitsee.
"Kuinka hyvin Delhi kääntäjää voidaan optimoida?"
DELPHI tekee oletuksena yhtä sun toista optimointia. Itse tosin yleensä laitan jokaisen unitin alkuun tämän:
{$OPTIMIZATION OFF}
On nimittäin raivostuttavaa, kun integroitua debuggeria käytettäessä "Variable A is not available due to optimization" yritettäessä tarkastella muuttujan A arvoa !
Delphin integroitu debuggeri näyttää yleensä koodin lähdekielitasolla, mutta View / Debug windows / CPU :lla saa myös assemblerkieliset käännöksen tulokset esiin.
Noihin on hyvä tutustua, niin näkee, mitä Delphi optimoi ja miten.
pienenä esimerkkinä: on määrämuotoinen tekstitiedosto, jossa on 300.000 tasapituista riviä, joissa määräformaatti eri sarakkeita.
Halusin järjestää tuon tiettyjen sääntöjen mukaan järjestykseen. Kokeilin ensin Delphin omaa TStringlistin Sort -metodia. Useamman minuutin tuloksettoman odottelun jälkeen kyllästyin ja lopetin ohjelmansuorituksen.
Sitten päätin tehdä homman niin, että lajitteluavaimen ensimmäinen kirjain käsitellään omalla koodilla erikseen ja vain samalla kirjaimella alkavat jätetään Delphin vakiotoimintojen huoleksi. Muutettu ohjelma hoiti koko homman muutamassa kymmenessä sekunnissa.
Tästä voidaan oppia se, että nopeuteen vaikuttaa enemmän se, miten koodinsa koodaa kuin käytetty kääntäjä. (Noh, ehkä tulkkaavat kielet ovat aina hitaimpien joukossa vaikka koodaaja olisikin osaaja). Delphi on kuitenkin aito kääntäjä, kuten myös Kylix.
Uusimpien Delphien osalta en ole asiaa selvittänyt, mutta ainakaan Delphi5 ei osaa kääntäessä hyödyntää MMX -käskykantaa. Mutta sehän ei estänyt minua koodaamasta erästä signaalikäsittelytehtävää MS Macro assemblerilla, jolloin MMX:stä saadaan kaikki hyöty irti, ja tuon voi hyvin kääntää suoraan Delphi -ohjelman osaksi.
Peleistä vielä: kokeilepa googlettaa:
Delphi DirectX jedi
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
57-vuotiads muka liian vanha töihin?
On tämä sairas maailma. Mihin yli 55-vuotiaat sitten muka enää kelpaavat? Hidasta itsemurhaa tekemään, kun eläkkeelle ei3914976Haluatteko miellyttää kumppaninne silmää?
Entä muita aisteja? Mitä olette valmiita tekemään sen eteen että kumppani näkisi teissä kunnioitettavan yksilön? Olette2852761By the way, olet
mielessäni. Olet minulle tärkeä, niin suunnattoman tärkeä. En kestäisi sitä jos sinulle tapahtuisi jotain. Surullani ei1551985Onko kaivattunne suosittu?
Onko teillä paljon kilpailijoita? Mies valitettavasti näyttää olevan paljonkin naisten suosiossa :(1041668J-miehelle toivon
Hyvää yötä. Voisiko nykyistä tilannetta uhmaten vielä pienintäkään toivetta olla, päästä kainaloosi joskus lepääämään.851533- 631397
Onkohan sulla enää tunteita
kun nähdään seuraavan kerran? Niin hyvä fiilis on ollut viime aikoina, että se on nyt pahin pelkoni. Oletkohan unohtanut511390Täytyi haukkuu sut lyttyyn
En haluu tuntee rakkautta sua kohtaan enää ja haluun unohtaa sut mut sit tulee kuiteki paha olo kun haluis vaan oikeesti611377Kylpyläsaaren Lomakylän kahvilaravintola
Kävimme syömässä Kylpyläsaaressa. "Naudanliha burgeri" maksoi 18,90 euroa ja lisäksi limsa 4,50 euroa. Annoksen hinnaks641334Rakkauden riemuvoitto
Valta voidaan voittaa tiedolla. Mutta tieto on huonompi kuin kauneus, hellyys ja rakkaus. Siksi kauneus on vallan ja tie3491111