Paras kieli aloittajalle

Nuo linkit kertoivat selvästi sen että perustelut pohjautuvat viime vuosituhannelle. Eli perustelut ei ota huomioon tämän hetkistä tilannetta!

Oisko tuo sitten hyvä? Saako sen ilmaiseksi?

Kysyisin ihan vaan, että miten sillä piirretään ympyrä ruudulle? Onko vaikeaa? Kiinnostaisi vähän grafiikan suunnalta aloitella tuota ohjelmointia.

The N00b kirjoitti:

Oisko tuo sitten hyvä? Saako sen ilmaiseksi?

Kysyisin ihan vaan, että miten sillä piirretään ympyrä ruudulle? Onko vaikeaa? Kiinnostaisi vähän grafiikan suunnalta aloitella tuota ohjelmointia.

Lazaruksella ympyrän piirtäminen onnistuu näin
Canvas.Pen.color:=clRed; // reunan väri on punainen
Canvas.Brush.color:=clWhite; // joka on täytetty valkoisella värillä
Canvas.Ellipse(x1,y1,x2,y2); // piirtää ellipsin alueen x1,y1,x2,y2 sisään

Lazarus on hyvä valinta kirjoitti:

Lazaruksella ympyrän piirtäminen onnistuu näin
Canvas.Pen.color:=clRed; // reunan väri on punainen
Canvas.Brush.color:=clWhite; // joka on täytetty valkoisella värillä
Canvas.Ellipse(x1,y1,x2,y2); // piirtää ellipsin alueen x1,y1,x2,y2 sisään

Ympyrän piirtämisestä oli kyse:

CIRCLE (x, y), radius

Qbasic / QuickBasic / Visual Basic

knowledge$ kirjoitti:

Ympyrän piirtämisestä oli kyse:

CIRCLE (x, y), radius

Qbasic / QuickBasic / Visual Basic

Sepäs onkin helppoa. Se osaa ilmeisesti itse arpoa mille tasolle, millä värillä, täytetäänkö millä värillä vai ollenkaan, jne.

Kyllä on fixuja nuo mikkiksen softat. ;)

siis muiden kielien tulkinta tuntuu vaikeammalta

Silmäilin (vain) tuon oppaan läpi. Se mitä tuossa oppaassa oli niin sain sen kuvan ettei se pärjää Lazarukselle (esim. moniajo, prosessit). Mutta kyllä sillä voi perusteita opetella (ja kun on se asenne että voi vaihtaa kieltä toiseksi). Mielestäni Lazarus on helpompi todellisille aloittelijoille jotka haluavat tehdä pieniä graafisia sovellutuksia heti.

(Tämä mielipide perustuu vain tuohon linkkiin (Pythonin osalta))

Ei pärjää Lazarukselle kirjoitti:

Silmäilin (vain) tuon oppaan läpi. Se mitä tuossa oppaassa oli niin sain sen kuvan ettei se pärjää Lazarukselle (esim. moniajo, prosessit). Mutta kyllä sillä voi perusteita opetella (ja kun on se asenne että voi vaihtaa kieltä toiseksi). Mielestäni Lazarus on helpompi todellisille aloittelijoille jotka haluavat tehdä pieniä graafisia sovellutuksia heti.

(Tämä mielipide perustuu vain tuohon linkkiin (Pythonin osalta))

Sait siis käsityksen, että esimerkiksi moniajo on hoidettu Lazaruksessa paremmin kuin Pythonissa. Haluaisin kuulla perusteesi.

Esimerkin vuoksi alla on kahta säiettä suorittava Python-ohjelma, jonka suoritus kestää noin kaksi sekuntia. Noin sekunnin kohdalla pääohjelman kanssa rinnakkainen säie tulostaa terveiset.

import thread, time
def tulosta(odotusaika,teksti):
   time.sleep(odotusaika)
   print teksti
thread.start_new_thread(tulosta,(1,"terveiset"))
time.sleep(2)

Onko rinnakkaisen ohjelman tekeminen Lazaruksessa jotenkin kätevämpää? Entä aloittelijalle selkeämpää? (Toivotaan kuitenkin, ettei rinnakkaisuus ole muutenkaan aloittelijallemme ensimmäisenä vastaan tuleva juttu.)

Itse olen vakaasti sitä mieltä, että Python riittää huomattavan paljon pidemmälle kuin pelkkään aloitteluun. Jos aikoo ohjelmoida paljon, jossain vaiheessa on joka tapauksessa syytä tutustua johonkin kunnolliseen dynaamiseen kieleen (esim. Python tai Ruby, tietyin varauksin JavaScript, Perl, ...).

Minkä tahansa dynaamisen kielen hallitsevalle Pascal (eli myös Lazarus), Java, C ja muut staattisesti tyypitetyt imperatiiviset kielet tuntuvat tarpeettoman kömpelöiltä, yksinkertaiset asiat monimutkaisiksi tekeviltä, lähinnä konekirjoituksen harjoitteluun sopivilta ohjelmointikieliltä.

"Jos taas kiihdytettyä 3D-grafiikkaa meinaat harrastaa enemmänkin niin sitten järkevintä opetella se C ."

C on liian vaikea alottelijoille. 3D ja 2D graffaan C ja SDL:
http://cs.stadia.fi/~silander/ohjelmointi/
http://www.libsdl.org/
http://jt11-55-2.tky.hut.fi/l10n/sdl/fi/intro.fi/toc.html

(Muuten, ensin väität että java "Riittää kaikkeen" ja sitten pitäisikin opetella C ) (ja Swing/SWT on helvetin rumia)

snjöö kirjoitti:

"Jos taas kiihdytettyä 3D-grafiikkaa meinaat harrastaa enemmänkin niin sitten järkevintä opetella se C ."

C on liian vaikea alottelijoille. 3D ja 2D graffaan C ja SDL:
http://cs.stadia.fi/~silander/ohjelmointi/
http://www.libsdl.org/
http://jt11-55-2.tky.hut.fi/l10n/sdl/fi/intro.fi/toc.html

(Muuten, ensin väität että java "Riittää kaikkeen" ja sitten pitäisikin opetella C ) (ja Swing/SWT on helvetin rumia)

Siis kyllähän Javallakin saa aikaseksi kiihdytettyä 3D-grafiikkaa (esim. Java3D tai SDL joka käy myös Javaan) mutta tarkoitin lähinnä vakavaa 3D-suunnittelua tyyliin peliohjelmointi missä nopeus ja laiteläheisyys on tärkeämpiä kuin Javan antamat edut.

"C on liian vaikea alottelijoille."

Liian vaikea? Tuota noin, MIKÄÄN asia ei ole ohjelmoinnissa LIIAN vaikeaa, vaan se on aina kynnyskysymys JAKSAAKO panostaa opiskeluun vai ei. Alan kirjoja löytyy kirjakaupoista, tutoriaaleja netistä, kursseja kouluista yms. joten ei ole mitään syytä opiskella ei-oliopohjaista kieltä vaan opettelee alusta asti ne oliot hyvin.

"ja Swing/SWT on helvetin rumia"

Win32 ja MFC:kö on sitten kauniita? ;)

Edellinen kirjoitti:

Siis kyllähän Javallakin saa aikaseksi kiihdytettyä 3D-grafiikkaa (esim. Java3D tai SDL joka käy myös Javaan) mutta tarkoitin lähinnä vakavaa 3D-suunnittelua tyyliin peliohjelmointi missä nopeus ja laiteläheisyys on tärkeämpiä kuin Javan antamat edut.

"C on liian vaikea alottelijoille."

Liian vaikea? Tuota noin, MIKÄÄN asia ei ole ohjelmoinnissa LIIAN vaikeaa, vaan se on aina kynnyskysymys JAKSAAKO panostaa opiskeluun vai ei. Alan kirjoja löytyy kirjakaupoista, tutoriaaleja netistä, kursseja kouluista yms. joten ei ole mitään syytä opiskella ei-oliopohjaista kieltä vaan opettelee alusta asti ne oliot hyvin.

"ja Swing/SWT on helvetin rumia"

Win32 ja MFC:kö on sitten kauniita? ;)

"Liian vaikea? Tuota noin, MIKÄÄN asia ei ole ohjelmoinnissa LIIAN vaikeaa, vaan se on aina kynnyskysymys JAKSAAKO panostaa opiskeluun vai ei."

Sinänsä totta, mutta kun ei tiedetä ko. aloittelijan (tai ylensäkään jonkun aloittelijan) motivaatiota eikä henkistä kapasiteettia (ÄO/matemaattinen lahjakkuus etc.), niin on varmenpaa aloittaa C:llä kuin C :lla ja semminkin kun ei se C-opiskelu mene kuitenkaan hukkaan (ja OO-homma menee usein överiksi kts. alla).

"...joten ei ole mitään syytä opiskella ei-oliopohjaista kieltä vaan opettelee alusta asti ne oliot hyvin. "

Kyllä on osattava ainakin proseduraalinen ja OO paradigma, pelkkä OO on virhe. Tätä mieltä on esim. OO-guru Stroustrup (C :n "luoja"): http://www.artima.com/intv/goldilocks2.html

"Kaikki pitää olla OO:ta" on siis suunnitteluvirhe ja täten esim. Java pelkkänä OO-kielenä on suunnitteluvirhe.

Edellinen kirjoitti:

Siis kyllähän Javallakin saa aikaseksi kiihdytettyä 3D-grafiikkaa (esim. Java3D tai SDL joka käy myös Javaan) mutta tarkoitin lähinnä vakavaa 3D-suunnittelua tyyliin peliohjelmointi missä nopeus ja laiteläheisyys on tärkeämpiä kuin Javan antamat edut.

"C on liian vaikea alottelijoille."

Liian vaikea? Tuota noin, MIKÄÄN asia ei ole ohjelmoinnissa LIIAN vaikeaa, vaan se on aina kynnyskysymys JAKSAAKO panostaa opiskeluun vai ei. Alan kirjoja löytyy kirjakaupoista, tutoriaaleja netistä, kursseja kouluista yms. joten ei ole mitään syytä opiskella ei-oliopohjaista kieltä vaan opettelee alusta asti ne oliot hyvin.

"ja Swing/SWT on helvetin rumia"

Win32 ja MFC:kö on sitten kauniita? ;)

"Win32 ja MFC:kö on sitten kauniita? ;)"

Ööö.. enpä enää muista miltä näyttivät (alkava demis).
Oikestaan kaikki GUI:t on rumia toiset vaan rumempia (Swing/SWT).

snjöö kirjoitti:

"Liian vaikea? Tuota noin, MIKÄÄN asia ei ole ohjelmoinnissa LIIAN vaikeaa, vaan se on aina kynnyskysymys JAKSAAKO panostaa opiskeluun vai ei."

Sinänsä totta, mutta kun ei tiedetä ko. aloittelijan (tai ylensäkään jonkun aloittelijan) motivaatiota eikä henkistä kapasiteettia (ÄO/matemaattinen lahjakkuus etc.), niin on varmenpaa aloittaa C:llä kuin C :lla ja semminkin kun ei se C-opiskelu mene kuitenkaan hukkaan (ja OO-homma menee usein överiksi kts. alla).

"...joten ei ole mitään syytä opiskella ei-oliopohjaista kieltä vaan opettelee alusta asti ne oliot hyvin. "

Kyllä on osattava ainakin proseduraalinen ja OO paradigma, pelkkä OO on virhe. Tätä mieltä on esim. OO-guru Stroustrup (C :n "luoja"): http://www.artima.com/intv/goldilocks2.html

"Kaikki pitää olla OO:ta" on siis suunnitteluvirhe ja täten esim. Java pelkkänä OO-kielenä on suunnitteluvirhe.

"Kaikki pitää olla OO:ta" on siis suunnitteluvirhe ja täten esim. Java pelkkänä OO-kielenä on suunnitteluvirhe."

Aika kova väite, koska vaikka Java on oliokieli, niin siinä on myös ei-oliomaisia ominaisuuksia (staattiset attribuutit, primitiivityypit) eikä kukaan estä ohjelmoimasta Javalla ei-oliomaisesti, mutta se vain on äärimmäisen typerää.

Se on totta, että kaikkea ei voi mallintaa olioin, ja sillon kun ei voi, en ainakaan itse Javan kanssa työskennellessäni ole joutunut turvautumaan purkkaviritelmiin.

snjöö kirjoitti:

"Win32 ja MFC:kö on sitten kauniita? ;)"

Ööö.. enpä enää muista miltä näyttivät (alkava demis).
Oikestaan kaikki GUI:t on rumia toiset vaan rumempia (Swing/SWT).

Mitä tarkoitat "rumuudella"? Arkkitehtuuria? Ulkoasua? Jos et tiennyt niin sellaista GUI-kirjastoa tuskin onkaan enää mitä ei voisi kustomoida mielin määrin mieleisekseen. Ainakin juuri nuo Swing ja SWT mahdollistavat täydellisen kustomoinnin eri komponenteille niin toiminnallisesti kuin graafisesti.

Suunnitteluvirhe kirjoitti:

"Kaikki pitää olla OO:ta" on siis suunnitteluvirhe ja täten esim. Java pelkkänä OO-kielenä on suunnitteluvirhe."

Aika kova väite, koska vaikka Java on oliokieli, niin siinä on myös ei-oliomaisia ominaisuuksia (staattiset attribuutit, primitiivityypit) eikä kukaan estä ohjelmoimasta Javalla ei-oliomaisesti, mutta se vain on äärimmäisen typerää.

Se on totta, että kaikkea ei voi mallintaa olioin, ja sillon kun ei voi, en ainakaan itse Javan kanssa työskennellessäni ole joutunut turvautumaan purkkaviritelmiin.

Kyllä liiallinen olio-orientoituneisuus on jonkinlainen virhe silloin jos imperatiivinen Basic-koodi olisi mukautuvampaa. Olioiden suurin hyöty on virheiden vähenemisessä, mutta muussa nuo "apupyörät" rajoittavat. Oliothan ovat oikeastaan pelkkiä valmisohjelmia, joita kutsutaan käyttöliittymänsä kautta.

Eli aloittelijalle sopiva kieli on sellainen missä jo tutut käsitteet vastaavat sitä mitä käyttäjä olettaa.

Esim tämä kriteeri pudottaa monta kieltä pois:

Eli jos verrataan jotain asiaa niin yhtäsuurus merkki tarkoittaa yhtäsuurutta

if (a = b )
// pitää tarkoitta sitä onko a yhtäsuuri kuin b

Tälläinen kirjoitti:

Eli aloittelijalle sopiva kieli on sellainen missä jo tutut käsitteet vastaavat sitä mitä käyttäjä olettaa.

Esim tämä kriteeri pudottaa monta kieltä pois:

Eli jos verrataan jotain asiaa niin yhtäsuurus merkki tarkoittaa yhtäsuurutta

if (a = b )
// pitää tarkoitta sitä onko a yhtäsuuri kuin b

a = a 1

pitää olla epätosi

Tälläinen kirjoitti:

a = a 1

pitää olla epätosi

Delphi on selkeä, ja täyttää em. vaatimukset "=" merkistä.

Eli:

{$APPTYPE console}
if A = 5 then Writeln('A:n arvo on viisi.');

tai GUI -ohjelmassa:

if A = 5 then Memo1.Lines.Add('A:n arvo on viisi.');

Lisäksi, Delphissä ei tarvita erillisiä & ja && -operaattoreit, joista pitäisi vielä erikseen muistaa kumpi on kumpi.

Delphissä asia on selkeä:

var
A,B,C : Boolean;
I, J, K : Integer;

begin
A := B AND C; // looginen AND
I := J AND K; // bittikohtainen AND
end;

Tuo C/C++:n tarve erillisille & ja && -operaattoreille johtuu kielten kehnosta/olemattomasta tyypityksestä.

Jotkut vihaavat (Object)pascalin vahvaa tyypitystä, koska kokevat sen rajoittavaksi.

Mutta näin ei tarvitse olla:

vaan esim voi tehdä näin:

var
A : Boolean;
B : Byte;

begin
B := byte(A); // lue muuttujan A sisältö ikään kuin A olisi BYTE -tyyppiä, ja kopioi arvo B:hen.
end;


toisinpäinkin voi tehdä, mutta se ei ole järkevää, jollei ole 100% varma, että BYTE -muuttujan arvo on joko 0 tai 1.

Epävarmoissa tapauksissa voi toki tehdä näin:

var
A : Boolean;
B : Byte;

begin
A := bytebool(B); // toimii oikein, olipa B mikä arvo tahansa, Eli tässä 0=false, ja mikä tahansa muu kuin 0 on TRUE.
end;

vastaavasti löytyy wordbool ja longbool 16- ja 32-biitistä boolen muuttujaa varten. Noita ei puhtaassa Delphi -ohjelmoinnissa tarvita, mutta jos kutsut Delphi -ohjelmasta esim C:llä tehtyä kirjasto.DLL:ää (Windows) tai kirjasto.so:ta (Linux), niin mikäli C -kielinen funktio palauttaa teoriassa kokonaisluvun, jonka merkitys kuitenkin on 0=epätosi, ja muu kuin 0 = tosi, niin silloin nuo bytebool, wordbool ja longbool ovat käteviä.

Lisäksi Delphin merkkijonokäsittely on selkeä ja ylivoimainen moneen muuhun verrattuna.

Eli kun käytät Delphin String -tyyppiä, muuttuvapituuksisten merkkijonojen muistinhallinta on Delphin ongelma, ei ohjelmoijan.

Delphin merkkijono voi teoriassa olla jopa 2 gigatavua pitkä. Käytännössä toki muistin määrä ja CPU:n nopeus voivat aiheuttaa harmeja, jos nyt ihan 2 Gt dataa aikoo yhteen merkkijonoon tunkea.

Ja Delphin merkkijonossa (String) jokainen AnsiChar -arvo (eli #0 .. #255 ) on sallittu, eli edes #0 (jonka C- ohjelmoijat tuntevat nimellä null) ei päätä merkkijonoa.

Silti Delphin merkkijonot on suunniteltu olemaan yhteensopivia C -kielen käyttämän AsciiZ -tyyppisen "char* mjono" -tyyppisen ilmaisun kanssa:

Delphin merkkijonon viimeisen merkin jälkeen on automaattisesti tuo #0 eli null -merkki, mutta Delphi itse ei sitä tarvitse, vaan se on siellä valmiiksi yhteensopivuussyistä.

Esim. Delphin oma ShowMessage(St1) kutsuu WinAPI:n MessageBox -funktiota tyyliin

MessageBox(..., PChar(St1), ...)

joten vaikka #0 ei päätä Delphin merkkijonoa, niin se silti päättää merkkijonon tulostuksen silloin, kun tulostaminen tehdään käyttämällä (välillisesti) järjestelmäkutsua, joka ottaa parametrikseen PChar -tyyppisen merkkijono-osoittimen (siis teknisesti sama kuin C -kielen char *), joten NULLeja sisältävän merkkjonon tulostukseen näytölle täytyy kirjoittaa oma rutiini.

Sensijaan tiedostoon merkkijono menee sellaisenaan, vaikka sisältäisikin NULL -merkkejä.

esim. Näin:

var
S1 : TFileStream;
St1 : String;

try
//
St1 := 'abc'#0'def';


S1 : TFileStream.Create('testi1.bin', fmCreate);

S1.WriteBuffer(St1[1], length(St1));
// huomaa: Delphin merkkijonoissa 1. merkin indeksi on 1, ei 0 -kuten C -kielessä.

finally
S1.Free;
end;

Toki, jos merkkijono muunnetaan PChar -tyypiksi:

var

St1 : String;

P : PChar;

begin
St1 := 'abc';

P := PChar(St1);

// nyt St1[1] = 'a'

// ja P[0] = 'a', siis se sama 'a' !!!



end;