ohjelmoinnin perusteet

ehkä kuitenkin gcc parempi vaihtoehto

Huohhhhhhhhh kirjoitti:

ehkä kuitenkin gcc parempi vaihtoehto

Dev-C ??

Onko hyvä? Vaikea käyttää?

onko hyvä kirjoitti:

Dev-C ??

Onko hyvä? Vaikea käyttää?

Ei ole vaikea käyttää

JavaScript ja Java on täysin eri asia.

JavaScriptillä saa tehtyä kyllä selaimille kaikenlaista hienoa (Googlen toimistotyökalut esimerkkinä), mutta Javalla pystyy vielä paljon enempään, sillä voi tehdä mitä vaan.

Helpoin, yksinkertaisin, nopein opittava kieli.... Ihan mikä vaan mitä alkaa ensin opettelemaan. VBA tosiaan kelpaa yksinkertaisiin kotijuttuihin, joten ehkä se sopii 50 vuotiaille harjoittelijoille. Jollakulla vaan jos on kotona Mac tai Linux, niin se siitä VBA:sta sitten.

Javaan on ilmaisia työkaluja netti pullollaan, java vaan on tarkka syntaksin ja isojen kirjaimien kanssa. Netbeans tai Eclipse taikasanoilla voit ladata netistä jykeviä kehitysympäristöjä jotka sopii ihan aloittelijasta ammattilaiselle. Oppiiko siinä sitten ohjelmoinnin perusteita... tiedä heitä.

"(jo siitä syystä että indeksit alkaa 1:stä yms älytöntä)"

Ei ainakaan taulukon indeksit ala! Sitä paitsi sehän olisi oikein?

"VB...opettaa...ajattelun umpikujaa"

Mitä VB opettaa? Basic on multiparadigmojen multiparadigma jossa ohjelmoija ajattelee. Nämä ajatushelistimet kritisoivat Basicia jossa ei ole ajatusta. Ei tyhjässä basic-ohjelmassa olekaan. Basicin ainoa heikkous on, ettei sillä Lispiäkin sivuvaikutuksettomana kielenä saa oikein mitään tulostusta aikaiseksi. VB sopii loistavasti vaihtoehdoksi Javan ja Pythonin rinnalle 50 ihmisille dementiaa myöhästyttämään.

"C - - opettaa vanhentunutta ajattelutapaa"

Ei C mitään opeta, vaan opettaja opettaa. C ei ole vanhentunut. Sitä käytetään yhä paljon. Se ei varmasti ole paras kieli joka hommaan (mikäpä olisi), mutta oikeissa käsissä tehokas ja tarpeellinen työkalu.

"Olioajatteluun totuttautuminen voidaan aloittaa jo aloituspäivän iltapäivänä."

Parhaissa kursseissa olioroska sivuutetaan kokonaan.

Vain vanhene kirjoitti:

"C - - opettaa vanhentunutta ajattelutapaa"

Ei C mitään opeta, vaan opettaja opettaa. C ei ole vanhentunut. Sitä käytetään yhä paljon. Se ei varmasti ole paras kieli joka hommaan (mikäpä olisi), mutta oikeissa käsissä tehokas ja tarpeellinen työkalu.

"Olioajatteluun totuttautuminen voidaan aloittaa jo aloituspäivän iltapäivänä."

Parhaissa kursseissa olioroska sivuutetaan kokonaan.

Lue lisää

C ja basic ovat huonoja valintoja ohjelmoinnin opetukseen koska niillä on helppoa tehdä "sutta" ("epäkuranttia)". Tarjolla on paljon parempiakin kieliä opetukseen.

Se on totta että esim C:tä käytetään hyvin paljon ja on hyvä osta sitä mutta vasta sen jälkeen kun osaa ohjelmoida oikein ja osaa välttää kielen ansat. Eli C sopii ammattilaiselle mutta ei kansalaisopiston kursseille!

Älä valitse huonoja opetusk... kirjoitti:

C ja basic ovat huonoja valintoja ohjelmoinnin opetukseen koska niillä on helppoa tehdä "sutta" ("epäkuranttia)". Tarjolla on paljon parempiakin kieliä opetukseen.

Se on totta että esim C:tä käytetään hyvin paljon ja on hyvä osta sitä mutta vasta sen jälkeen kun osaa ohjelmoida oikein ja osaa välttää kielen ansat. Eli C sopii ammattilaiselle mutta ei kansalaisopiston kursseille!

Lue lisää

Kaikilla kielillä voi tehdä sutta, ja se tuntuu olevan niiden yleisin käyttötapakin. C on kuitenkin hyvä aloituskieli, koska se ei peitä tärkeitä asioita käyttäjältä. Se vaikeus kuuluu hommaan.

Muuten ei opi kuin lelukieliä.

Vain vanhene kirjoitti:

"C - - opettaa vanhentunutta ajattelutapaa"

Ei C mitään opeta, vaan opettaja opettaa. C ei ole vanhentunut. Sitä käytetään yhä paljon. Se ei varmasti ole paras kieli joka hommaan (mikäpä olisi), mutta oikeissa käsissä tehokas ja tarpeellinen työkalu.

"Olioajatteluun totuttautuminen voidaan aloittaa jo aloituspäivän iltapäivänä."

Parhaissa kursseissa olioroska sivuutetaan kokonaan.

Lue lisää

Jos uudelleen, vuosien tauon jälkeen, pääsisin tekemään koodia 8-bittiselle mikro-ohjaimelle (se oli kivaa hommaa!), niin C olisi kielenä ykkösvaihtoehto. Myös jollakin tasolla kernel-ohjelmoinnissa se olisi paras. Muualla on aina parempia vaihtoehtoja.

Olioajattelu on yleisohjelmoinnin perusta, ja C:lläkin se on mahdollista, mutta tarpeettoman työlästä.

Yusa kirjoitti:

Jos uudelleen, vuosien tauon jälkeen, pääsisin tekemään koodia 8-bittiselle mikro-ohjaimelle (se oli kivaa hommaa!), niin C olisi kielenä ykkösvaihtoehto. Myös jollakin tasolla kernel-ohjelmoinnissa se olisi paras. Muualla on aina parempia vaihtoehtoja.

Olioajattelu on yleisohjelmoinnin perusta, ja C:lläkin se on mahdollista, mutta tarpeettoman työlästä.

Lue lisää

Olen aikonut tehdä QuickBasicille uuden hauskan IDE:n. Säilyttäisin sen yksinkertaisen kielen, joka siinä oli hyvää. Lisäisin vain graafisen helppouden ja joitain uusia komentoja esim nettikäyttöön. Mutta en "mitään" olioita. Oliottomassa ajattelussa jotain populaarista arvoa täytyy olla...?

Vinkkien määrä:
http://www.ohjelmointiputka.net/koodit.php

WinBasic kirjoitti:

Olen aikonut tehdä QuickBasicille uuden hauskan IDE:n. Säilyttäisin sen yksinkertaisen kielen, joka siinä oli hyvää. Lisäisin vain graafisen helppouden ja joitain uusia komentoja esim nettikäyttöön. Mutta en "mitään" olioita. Oliottomassa ajattelussa jotain populaarista arvoa täytyy olla...?

Vinkkien määrä:
http://www.ohjelmointiputka.net/koodit.php

Lue lisää

Ymmärsin 90-luvun alussa vanhojen C- ja PLM-gurujen karsastuksen olioajattelua kohtaan, mutta sehän oli tietenkin ohimenevä ilmiö: kaikki paitsi eläkkeelle, markkinointiin tai hallinnollisiin hommiin siirtyvät käänsivät kelkkansa, kun ymmärsivät ideat.

Alunperin HW-suunnittelijana minulle olioajattelu oli vanha tuttu juttu plus joitakin lisäetuja.

Tänään vastustus ei voi myöskään johtua mistään muusta kuin äärimmäisen suppeasta ymmärryksestä, ja siitä, ettei ole koskaan tehnyt mitään isompaa, monimutkaisempaa projektia.

WinBasic kirjoitti:

Olen aikonut tehdä QuickBasicille uuden hauskan IDE:n. Säilyttäisin sen yksinkertaisen kielen, joka siinä oli hyvää. Lisäisin vain graafisen helppouden ja joitain uusia komentoja esim nettikäyttöön. Mutta en "mitään" olioita. Oliottomassa ajattelussa jotain populaarista arvoa täytyy olla...?

Vinkkien määrä:
http://www.ohjelmointiputka.net/koodit.php

Lue lisää

Tekisitkö karhunpalveluksen (pettäisit) QB-ihmisille. Eiköhän ole parempi mitä nopeammin he pääsevät eroon QB:stä (se on kuitenkin jo kuoleva ja vanhanaikainen kieli)

Yusa kirjoitti:

Ymmärsin 90-luvun alussa vanhojen C- ja PLM-gurujen karsastuksen olioajattelua kohtaan, mutta sehän oli tietenkin ohimenevä ilmiö: kaikki paitsi eläkkeelle, markkinointiin tai hallinnollisiin hommiin siirtyvät käänsivät kelkkansa, kun ymmärsivät ideat.

Alunperin HW-suunnittelijana minulle olioajattelu oli vanha tuttu juttu plus joitakin lisäetuja.

Tänään vastustus ei voi myöskään johtua mistään muusta kuin äärimmäisen suppeasta ymmärryksestä, ja siitä, ettei ole koskaan tehnyt mitään isompaa, monimutkaisempaa projektia.

Lue lisää

"Tänään vastustus ei voi myöskään johtua mistään muusta kuin äärimmäisen suppeasta ymmärryksestä..."

Se on hyvä peruste tälle kuriositeetilleni. Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia.

WinBasic kirjoitti:

"VB...opettaa...ajattelun umpikujaa"

Mitä VB opettaa? Basic on multiparadigmojen multiparadigma jossa ohjelmoija ajattelee. Nämä ajatushelistimet kritisoivat Basicia jossa ei ole ajatusta. Ei tyhjässä basic-ohjelmassa olekaan. Basicin ainoa heikkous on, ettei sillä Lispiäkin sivuvaikutuksettomana kielenä saa oikein mitään tulostusta aikaiseksi. VB sopii loistavasti vaihtoehdoksi Javan ja Pythonin rinnalle 50 ihmisille dementiaa myöhästyttämään.

Lue lisää

Jos jotain käyttöä BASICille voi keksiä, niin ehkä se on juuri tuo dementian myöhästyttäminen. Mutta ennen BASICin opettamista vastuullinen opettaja varmistaa, ettei opiskelijoista ole koskaan tarkoituskaan tulla ohjelmoijia. Edesmennyt E. W. Dijkstrakin sanoi jo:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

(http://en.wikiquote.org/wiki/Edsger_W._Dijkstra)

WinBasic kirjoitti:

"Tänään vastustus ei voi myöskään johtua mistään muusta kuin äärimmäisen suppeasta ymmärryksestä..."

Se on hyvä peruste tälle kuriositeetilleni. Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia.

Lue lisää

"Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia."

Sellaisista ei ikinä pitäisi ohjelmoijia tullakaan!

??? kirjoitti:

"Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia."

Sellaisista ei ikinä pitäisi ohjelmoijia tullakaan!

...mutta näitä ihmisiä syrjitään, kun eivät hallitse tätä tieteellistä systeemiajattelumallia. No..., jokin yhtä helppo "predikaattikieli" tulee varmasti uudestaan, jos ei muualta niin vaikka Nokialta.

WinBasic kirjoitti:

"Tänään vastustus ei voi myöskään johtua mistään muusta kuin äärimmäisen suppeasta ymmärryksestä..."

Se on hyvä peruste tälle kuriositeetilleni. Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia.

Lue lisää

"Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia."

Olioajattelu on luonnollinen tapa hahmottaa maailmaa. Se pukeminen käytännön ohjelmointiin edellyttää hieman useampien käsitteiden omaksumista kuin proseduraalinen ajattelu, mutta suurin este täytyy olla juuri se, että heti alusta lähdetään väärille teille.

Ihmisen arjan tapa hahmottaa maailmaa on olioajattelua mielummin kuin proseduraalista ajattelua. Juuri siksi myös ohjelmoinnissa pitäisi aloittaa tältä pohjalta, eikä sotkea heti käsitteitä, tehdä asioita jatkossa vaikeaksi. Esimerkiksi Pythonia käyttäen olioajattelun perusteet voi opettaa hyvin yksinkertaisesti.

Nyt puhutaan normaalilla omaksumiskyvyllä varustetuista, ei vammaisista eikä superlahjakkaista.

TRRY kirjoitti:

Jos jotain käyttöä BASICille voi keksiä, niin ehkä se on juuri tuo dementian myöhästyttäminen. Mutta ennen BASICin opettamista vastuullinen opettaja varmistaa, ettei opiskelijoista ole koskaan tarkoituskaan tulla ohjelmoijia. Edesmennyt E. W. Dijkstrakin sanoi jo:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

(http://en.wikiquote.org/wiki/Edsger_W._Dijkstra)

Lue lisää

Ei hän väärässä ole, mutta "practically impossible" on väärä ilmaus, koska meillä on kokonainen sukupolvi, joka tutustui ohjelmointiin juuri basicin kautta, mutta pääsi siitä silti eroon. Pidän perus-C:tä melkein yhtä vahingollisena. Minä aloitin basicillä 70-luvun puolessa välissä, sitten käytin PLM:ää ja Pascalia, joiden jälkeen C:tä. Tein lisäksi paljon HW-suunnittelua ja ehkä siksi C ja luokka- ja interface-käsite tuntuivat ihan heti luonnolliselta ja hyvältä, nehän olivat jo IC-suunnittelussa mukana (periytyminen oli vaikeampaa). Mutta näin miten vaikeaa kaikki oli monille kokeneille C-guruille.

Yusa kirjoitti:

"Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia."

Olioajattelu on luonnollinen tapa hahmottaa maailmaa. Se pukeminen käytännön ohjelmointiin edellyttää hieman useampien käsitteiden omaksumista kuin proseduraalinen ajattelu, mutta suurin este täytyy olla juuri se, että heti alusta lähdetään väärille teille.

Ihmisen arjan tapa hahmottaa maailmaa on olioajattelua mielummin kuin proseduraalista ajattelua. Juuri siksi myös ohjelmoinnissa pitäisi aloittaa tältä pohjalta, eikä sotkea heti käsitteitä, tehdä asioita jatkossa vaikeaksi. Esimerkiksi Pythonia käyttäen olioajattelun perusteet voi opettaa hyvin yksinkertaisesti.

Nyt puhutaan normaalilla omaksumiskyvyllä varustetuista, ei vammaisista eikä superlahjakkaista.

Lue lisää

"Olioajattelu on luonnollinen tapa hahmottaa maailmaa."

(Tuota lausettahan jankutettiin joskus 90-luvulla - luulin sen jo "unohtuneen")

Jos näin on miksi sen oppiminen kestää kuukausia ja toiset ei näytä oppivan sitä ollenkaan.

Ja kun perusteet on oppinut tulee lisää ongelmia luokkahierarkian suunnittelussa:
http://en.wikipedia.org/wiki/Circle-ellipse_problem
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

(Siis nuo "design pattern"-jutut kertoo epäsuorasti kuinka vaikeaa on saada luokkahierarkian "oikein".)

Yusa kirjoitti:

"Suurin osa ihmisistä ei todella tule koskaan ymmärtämään oliomallia."

Olioajattelu on luonnollinen tapa hahmottaa maailmaa. Se pukeminen käytännön ohjelmointiin edellyttää hieman useampien käsitteiden omaksumista kuin proseduraalinen ajattelu, mutta suurin este täytyy olla juuri se, että heti alusta lähdetään väärille teille.

Ihmisen arjan tapa hahmottaa maailmaa on olioajattelua mielummin kuin proseduraalista ajattelua. Juuri siksi myös ohjelmoinnissa pitäisi aloittaa tältä pohjalta, eikä sotkea heti käsitteitä, tehdä asioita jatkossa vaikeaksi. Esimerkiksi Pythonia käyttäen olioajattelun perusteet voi opettaa hyvin yksinkertaisesti.

Nyt puhutaan normaalilla omaksumiskyvyllä varustetuista, ei vammaisista eikä superlahjakkaista.

Lue lisää

...se iäkkäämmiltä onnistuisi jopa paremmin, eli "koskaan" on väärä ilmaisu. Mutta vielä osaisi hyödyntää jossain??? Siihen on pitkä matka.

*palle* kirjoitti:

"Olioajattelu on luonnollinen tapa hahmottaa maailmaa."

(Tuota lausettahan jankutettiin joskus 90-luvulla - luulin sen jo "unohtuneen")

Jos näin on miksi sen oppiminen kestää kuukausia ja toiset ei näytä oppivan sitä ollenkaan.

Ja kun perusteet on oppinut tulee lisää ongelmia luokkahierarkian suunnittelussa:
http://en.wikipedia.org/wiki/Circle-ellipse_problem
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

(Siis nuo "design pattern"-jutut kertoo epäsuorasti kuinka vaikeaa on saada luokkahierarkian "oikein".)

Lue lisää

Olioajattelu ei ole ihmelääke, joka tekee monimutkaiset asiat helpoiksi, ehkä vain hieman helpommiksi, kuin vanhalla ajattelulla. Olen itsekin kritisoinut esim syviä luokkahierarkioita. Niiden kanssa on oltava hyvin varovainen. Niiden kanssa liioitellaan. Mutta silti ne mallintavat ihmisen ajattelua ja sovellusalueen kategorioihin jakamista tavalla, jolle en löydä proseduraalisesta ohjelmoinnista vastinetta. Patternit ovat vain esimerkkiluettelo hyvistä työtavoista, eivät ainoita vaihtoehtoja. Ihan varmasti niitä sovelletaan paljon väärin, olen itse nähnyt (ja ehkä itsekin syyllistynyt).

Tein itse 80-90-luvuilla proseduraalista ohjelmointia SA-menetelmän pohjalta (Structured Analysis) käyttäen ja nyt UML-ajattelu on ehdottomasti mielekkäämpää.

Yusa kirjoitti:

Olioajattelu ei ole ihmelääke, joka tekee monimutkaiset asiat helpoiksi, ehkä vain hieman helpommiksi, kuin vanhalla ajattelulla. Olen itsekin kritisoinut esim syviä luokkahierarkioita. Niiden kanssa on oltava hyvin varovainen. Niiden kanssa liioitellaan. Mutta silti ne mallintavat ihmisen ajattelua ja sovellusalueen kategorioihin jakamista tavalla, jolle en löydä proseduraalisesta ohjelmoinnista vastinetta. Patternit ovat vain esimerkkiluettelo hyvistä työtavoista, eivät ainoita vaihtoehtoja. Ihan varmasti niitä sovelletaan paljon väärin, olen itse nähnyt (ja ehkä itsekin syyllistynyt).

Tein itse 80-90-luvuilla proseduraalista ohjelmointia SA-menetelmän pohjalta (Structured Analysis) käyttäen ja nyt UML-ajattelu on ehdottomasti mielekkäämpää.

Lue lisää

luokkahierarkiat: "Niiden kanssa on oltava hyvin varovainen."

Niin. "Seitsemän sääntö". Itselläni on tuossa editoitavana noin 5 luokkaa kerralla. Tehokkuus ei kai enää parane ottamalla lisää luokkia. Se on kai käsin koodauksen raja?

Patterneja en ole vielä kokeillutkaan. Voisivat tehostaa mukavasti, mutta 7 ei saa silti ylittyä.

Myös muistin kulutus arveluttaa olioissa. Kun ohjelma jaetaan olioihin, niiden väliset viittaukset voivat kasvaa kovin suuriksi. Joskus oliot voivat päinvastoin lyhentää ohjelmakoodin pituutta, kun osoitetaan paljon oman olion attribuutteihin ja metodeihin.

WinBasic kirjoitti:

luokkahierarkiat: "Niiden kanssa on oltava hyvin varovainen."

Niin. "Seitsemän sääntö". Itselläni on tuossa editoitavana noin 5 luokkaa kerralla. Tehokkuus ei kai enää parane ottamalla lisää luokkia. Se on kai käsin koodauksen raja?

Patterneja en ole vielä kokeillutkaan. Voisivat tehostaa mukavasti, mutta 7 ei saa silti ylittyä.

Myös muistin kulutus arveluttaa olioissa. Kun ohjelma jaetaan olioihin, niiden väliset viittaukset voivat kasvaa kovin suuriksi. Joskus oliot voivat päinvastoin lyhentää ohjelmakoodin pituutta, kun osoitetaan paljon oman olion attribuutteihin ja metodeihin.

Lue lisää

Onko sulla mitään hajuakaan siitä mistä puhut? :D

WinBasic kirjoitti:

luokkahierarkiat: "Niiden kanssa on oltava hyvin varovainen."

Niin. "Seitsemän sääntö". Itselläni on tuossa editoitavana noin 5 luokkaa kerralla. Tehokkuus ei kai enää parane ottamalla lisää luokkia. Se on kai käsin koodauksen raja?

Patterneja en ole vielä kokeillutkaan. Voisivat tehostaa mukavasti, mutta 7 ei saa silti ylittyä.

Myös muistin kulutus arveluttaa olioissa. Kun ohjelma jaetaan olioihin, niiden väliset viittaukset voivat kasvaa kovin suuriksi. Joskus oliot voivat päinvastoin lyhentää ohjelmakoodin pituutta, kun osoitetaan paljon oman olion attribuutteihin ja metodeihin.

Lue lisää

Niin. "Seitsemän sääntö". Itselläni on tuossa editoitavana noin 5 luokkaa kerralla. Tehokkuus ei kai enää parane ottamalla lisää luokkia. Se on kai käsin koodauksen raja?

En ymmärrä. Tuo voi ehkä tarkoittaa sitä, että jollakin tasolla ohjelmaa luokkia tms ei ole syytä olla seitsemää enempää (muuten ei pysy hanskassa), mutta tuohan on pinnallinen luku, koska enemmän kuin luokkien lukumäärä, ratkaisee niiden käyttämisen vaikeus. On ihan eri asia käyttää luokkaa, jossa alustamisen jälkeen selvitään kolmella metodilla kuin jos tarvitaan kymmeniä metodeja.

Mutta monimutkaisuus on hyvä piiloittaa, jos siis sitä tarkoitat: jemmataan kokonaisuus pakettiin, jolla on helppo rajapinta ennenkuin tämä osakokonaisuus räjähtää käsiin. Tämähän on olioajattelun perusideoista mielestäni tärkein.

Yusa kirjoitti:

Niin. "Seitsemän sääntö". Itselläni on tuossa editoitavana noin 5 luokkaa kerralla. Tehokkuus ei kai enää parane ottamalla lisää luokkia. Se on kai käsin koodauksen raja?

En ymmärrä. Tuo voi ehkä tarkoittaa sitä, että jollakin tasolla ohjelmaa luokkia tms ei ole syytä olla seitsemää enempää (muuten ei pysy hanskassa), mutta tuohan on pinnallinen luku, koska enemmän kuin luokkien lukumäärä, ratkaisee niiden käyttämisen vaikeus. On ihan eri asia käyttää luokkaa, jossa alustamisen jälkeen selvitään kolmella metodilla kuin jos tarvitaan kymmeniä metodeja.

Mutta monimutkaisuus on hyvä piiloittaa, jos siis sitä tarkoitat: jemmataan kokonaisuus pakettiin, jolla on helppo rajapinta ennenkuin tämä osakokonaisuus räjähtää käsiin. Tämähän on olioajattelun perusideoista mielestäni tärkein.

Lue lisää

"Tuo voi ehkä tarkoittaa sitä, että jollakin tasolla ohjelmaa luokkia tms ei ole syytä olla seitsemää enempää (muuten ei pysy hanskassa)"

Sillä tasolla kun kaikki näistä luokista kommunikoi aktiivisesti keskenään.

"Mutta monimutkaisuus on hyvä piiloittaa, jos siis sitä tarkoitat: jemmataan kokonaisuus pakettiin, jolla on helppo rajapinta ennenkuin tämä osakokonaisuus räjähtää käsiin"

En tarkoita, olen tässä eri mieltä. Pythonissa resurssit ovat oletuksena julkisia, (tarkoitan ettei tarvita public-sanaa siinä luokan edessä). Varsin kiinnostava poikkeus.

WinBasic kirjoitti:

"Tuo voi ehkä tarkoittaa sitä, että jollakin tasolla ohjelmaa luokkia tms ei ole syytä olla seitsemää enempää (muuten ei pysy hanskassa)"

Sillä tasolla kun kaikki näistä luokista kommunikoi aktiivisesti keskenään.

"Mutta monimutkaisuus on hyvä piiloittaa, jos siis sitä tarkoitat: jemmataan kokonaisuus pakettiin, jolla on helppo rajapinta ennenkuin tämä osakokonaisuus räjähtää käsiin"

En tarkoita, olen tässä eri mieltä. Pythonissa resurssit ovat oletuksena julkisia, (tarkoitan ettei tarvita public-sanaa siinä luokan edessä). Varsin kiinnostava poikkeus.

Lue lisää

Hila-pattern, jos sellainen on olemassa, silloin 7 luokkaa, 7 käsitettä, on hyvä.

WinBasic kirjoitti:

"Tuo voi ehkä tarkoittaa sitä, että jollakin tasolla ohjelmaa luokkia tms ei ole syytä olla seitsemää enempää (muuten ei pysy hanskassa)"

Sillä tasolla kun kaikki näistä luokista kommunikoi aktiivisesti keskenään.

"Mutta monimutkaisuus on hyvä piiloittaa, jos siis sitä tarkoitat: jemmataan kokonaisuus pakettiin, jolla on helppo rajapinta ennenkuin tämä osakokonaisuus räjähtää käsiin"

En tarkoita, olen tässä eri mieltä. Pythonissa resurssit ovat oletuksena julkisia, (tarkoitan ettei tarvita public-sanaa siinä luokan edessä). Varsin kiinnostava poikkeus.

Lue lisää

Tein pienen ohjelman, jolla laskin muutaman tunnusluvun eräästä tällä hetkellä työn alla olevista projekteistani. Tarkoitus löytää sieltä jotain, mitä on tyypillisesti seitsemän.

Löytämiäni tunnuslukuja:

metodia / luokka: 0-12 kpl. Jos nollat jätetään laskuista, mediaani: 4 kpl, keskiarvo 4,9 kpl.

koodirivejä / metodi: 1-50 kpl. Mediaani 3 kpl, keskiarvo 5,8 kpl. (Yhden rivin metodeja on aika paljon. Jos ne jätetään laskuista, mediaani: 5 kpl, keskiarvo 8,7 kpl.)

Aineistossa on 49 luokkaa (38 niistä sisältää metodeja, loput perivät luultavasti Exceptionin ;)), 202 metodia, 1109 riviä koodia (ei sisällä tyhjiä eikä kommenttirivejä). Ohjelmointikielenä on Python.

Tietäisikö joku, onko vastaavia tunnuslukuja kerätty ja vertailtu laajemmissa määrin? Olisi kiinnostavaa nähdä, voiko eroja selittää ohjelmointikielellä, ongelma-alueella vai onko tämäkin enimmäkseen ohjelmoijasta riippuva asia.

WinBasicille: vaikka Pythonissa olioiden resurssit ovatkin oletuksena julkisia, niillä on siitä huolimatta paketointitehtävä. Olion rajapinnan (yleensä julkisten metodien) taakse kätketään toteutus, josta olion ulkopuolinen maailma (eli muut oliot ja muut ohjelman osaset) eivät riipu millään tavalla. Paketoinnissa ei ole mitään uutta verrattuna proseduraalisten ohjelmointikielten moduuleihin ja jopa funktioihin (funktiothan *eivät* käytä globaaleja muuttujia, eiväthän...). Sisäisen toteutuksen voi vaihtaa funktiossa, moduulissa tai oliossa toiseksi, minkä seurauksena ohjelma saattaa hidastua tai nopeutua, mutta se ei mene rikki.

Olioilla on paketoinnin lisäksi muitakin mukavia ominaisuuksia. Osa niistä on sellaisia, mitkä eivät proseduraalisessa ohjelmoinnissa ole ihan yhtä helposti tehtävissä, joten olio-ohjelmoinnilla on syynsä elää.

Olio-ohjelmoinnilla on toki myös lukuisia rajoitteita, ja monet ohjelmointitehtävät ratkeavatkin huomattavasti tyylikkäämmin täysin ilman olioita. Toisissa tapauksissa taas olio-ohjelmointia pitää täydentää esim. aspektiohjelmoinnilla, jotta tietyn tehtävän hoitavan ohjelmakoodin ripottelulta ympäri luokkahierarkiaa vältyttäisiin.

TRRY kirjoitti:

Tein pienen ohjelman, jolla laskin muutaman tunnusluvun eräästä tällä hetkellä työn alla olevista projekteistani. Tarkoitus löytää sieltä jotain, mitä on tyypillisesti seitsemän.

Löytämiäni tunnuslukuja:

metodia / luokka: 0-12 kpl. Jos nollat jätetään laskuista, mediaani: 4 kpl, keskiarvo 4,9 kpl.

koodirivejä / metodi: 1-50 kpl. Mediaani 3 kpl, keskiarvo 5,8 kpl. (Yhden rivin metodeja on aika paljon. Jos ne jätetään laskuista, mediaani: 5 kpl, keskiarvo 8,7 kpl.)

Aineistossa on 49 luokkaa (38 niistä sisältää metodeja, loput perivät luultavasti Exceptionin ;)), 202 metodia, 1109 riviä koodia (ei sisällä tyhjiä eikä kommenttirivejä). Ohjelmointikielenä on Python.

Tietäisikö joku, onko vastaavia tunnuslukuja kerätty ja vertailtu laajemmissa määrin? Olisi kiinnostavaa nähdä, voiko eroja selittää ohjelmointikielellä, ongelma-alueella vai onko tämäkin enimmäkseen ohjelmoijasta riippuva asia.

WinBasicille: vaikka Pythonissa olioiden resurssit ovatkin oletuksena julkisia, niillä on siitä huolimatta paketointitehtävä. Olion rajapinnan (yleensä julkisten metodien) taakse kätketään toteutus, josta olion ulkopuolinen maailma (eli muut oliot ja muut ohjelman osaset) eivät riipu millään tavalla. Paketoinnissa ei ole mitään uutta verrattuna proseduraalisten ohjelmointikielten moduuleihin ja jopa funktioihin (funktiothan *eivät* käytä globaaleja muuttujia, eiväthän...). Sisäisen toteutuksen voi vaihtaa funktiossa, moduulissa tai oliossa toiseksi, minkä seurauksena ohjelma saattaa hidastua tai nopeutua, mutta se ei mene rikki.

Olioilla on paketoinnin lisäksi muitakin mukavia ominaisuuksia. Osa niistä on sellaisia, mitkä eivät proseduraalisessa ohjelmoinnissa ole ihan yhtä helposti tehtävissä, joten olio-ohjelmoinnilla on syynsä elää.

Olio-ohjelmoinnilla on toki myös lukuisia rajoitteita, ja monet ohjelmointitehtävät ratkeavatkin huomattavasti tyylikkäämmin täysin ilman olioita. Toisissa tapauksissa taas olio-ohjelmointia pitää täydentää esim. aspektiohjelmoinnilla, jotta tietyn tehtävän hoitavan ohjelmakoodin ripottelulta ympäri luokkahierarkiaa vältyttäisiin.

Lue lisää

"(funktiothan *eivät* käytä globaaleja muuttujia, eiväthän...)."

Mutta eihän OO:ssa käytetä globaaleja...? Tarkoitatko staattisia attribuutteja?

TRRY kirjoitti:

Tein pienen ohjelman, jolla laskin muutaman tunnusluvun eräästä tällä hetkellä työn alla olevista projekteistani. Tarkoitus löytää sieltä jotain, mitä on tyypillisesti seitsemän.

Löytämiäni tunnuslukuja:

metodia / luokka: 0-12 kpl. Jos nollat jätetään laskuista, mediaani: 4 kpl, keskiarvo 4,9 kpl.

koodirivejä / metodi: 1-50 kpl. Mediaani 3 kpl, keskiarvo 5,8 kpl. (Yhden rivin metodeja on aika paljon. Jos ne jätetään laskuista, mediaani: 5 kpl, keskiarvo 8,7 kpl.)

Aineistossa on 49 luokkaa (38 niistä sisältää metodeja, loput perivät luultavasti Exceptionin ;)), 202 metodia, 1109 riviä koodia (ei sisällä tyhjiä eikä kommenttirivejä). Ohjelmointikielenä on Python.

Tietäisikö joku, onko vastaavia tunnuslukuja kerätty ja vertailtu laajemmissa määrin? Olisi kiinnostavaa nähdä, voiko eroja selittää ohjelmointikielellä, ongelma-alueella vai onko tämäkin enimmäkseen ohjelmoijasta riippuva asia.

WinBasicille: vaikka Pythonissa olioiden resurssit ovatkin oletuksena julkisia, niillä on siitä huolimatta paketointitehtävä. Olion rajapinnan (yleensä julkisten metodien) taakse kätketään toteutus, josta olion ulkopuolinen maailma (eli muut oliot ja muut ohjelman osaset) eivät riipu millään tavalla. Paketoinnissa ei ole mitään uutta verrattuna proseduraalisten ohjelmointikielten moduuleihin ja jopa funktioihin (funktiothan *eivät* käytä globaaleja muuttujia, eiväthän...). Sisäisen toteutuksen voi vaihtaa funktiossa, moduulissa tai oliossa toiseksi, minkä seurauksena ohjelma saattaa hidastua tai nopeutua, mutta se ei mene rikki.

Olioilla on paketoinnin lisäksi muitakin mukavia ominaisuuksia. Osa niistä on sellaisia, mitkä eivät proseduraalisessa ohjelmoinnissa ole ihan yhtä helposti tehtävissä, joten olio-ohjelmoinnilla on syynsä elää.

Olio-ohjelmoinnilla on toki myös lukuisia rajoitteita, ja monet ohjelmointitehtävät ratkeavatkin huomattavasti tyylikkäämmin täysin ilman olioita. Toisissa tapauksissa taas olio-ohjelmointia pitää täydentää esim. aspektiohjelmoinnilla, jotta tietyn tehtävän hoitavan ohjelmakoodin ripottelulta ympäri luokkahierarkiaa vältyttäisiin.

Lue lisää

"Olioilla on paketoinnin lisäksi muitakin mukavia ominaisuuksia. Osa niistä on sellaisia, mitkä eivät proseduraalisessa ohjelmoinnissa ole ihan yhtä helposti tehtävissä, joten olio-ohjelmoinnilla on syynsä elää."

Niin on. OO mallintaa hyvin ihmisajattelua.

Yhtä perusteltua olisi pohtia, pitäisikö heti ensimmäisellä kurssilla opettaa web-ohjelmointia (mitä tekniikoita se sitten kenenkin mielestä tarkoittaa: ajax, flash, silverlight, php, cgi-bin, ...), koska kaikenlaisia webissä toimivia ohjelmia on nykyisin niin paljon.

Ongelma on, että sekä web-ohjelmointi että graafisten käyttöliittymien ohjelmointi pakottaa ohjelmoinnin lisäksi opettelemaan ohjelmoinnista riippumattomia asioita, kuten monimutkaisen IDEn tai arkkitehtuurin.

Joissakin tapauksissa IDE kannustaa jopa oikeissa ohjelmointiprojekteissa täysin kestämättömään työskentelytapaan. Esimerkiksi ohjelman logiikka opitaan toteuttamaan tapahtumienkäsittelyrutiineihin (event handlerit, kuten "OnClick" yms.), käyttöliittymän suunnittelu ohittaa arkkitehtuurisuunnittelun ja tietokannan käsittely tapahtuu erilaisten komponenttien välityksellä ohjelmakoodilta lähes salassa.

Käyttäisin opetettavan ohjelmointikielen ja -työkalujen ja valinnassa perusteena sitä, kuinka pienellä ohjelmointiin kuulumattomien opetettavien asioiden määrällä selvitään. Huonoina esimerkkeinä voisin mainita esimerkiksi Java & Eclipsen ja Visual Studio minkätahansa. Mieti, mitä kaikkea joudut opettamaan selittääksesi, "hello world"-ohjelman tekemisen alusta alkaen; kuinka paljon joudutaan kirjoittamaan tai näkemään generoitua ohjelmakoodia, napsuttelemaan lomakkeita, surffailemaan valikoissa tai tutkimaan käännös/linkkauskomentojen parametrejä. Kaikki ovat sellaista tietoja, ettei niillä toisessa ohjelmointiympärisössä tee mitään.

Ohjelmoinnin perusasioita opettaessa on parasta keskittyä olennaiseen ja valita siksi työkalut, joilla se on eniten mahdollista. Tässä keskustelussa aiemmin mainittu Python on esimerkiksi erittäin hyvä vaihtoehto. Tapahtuuko I/O graafisen käyttöliittymän läpi, webissä vai "tekstirivejä näppäimistöltä" ei ole olennaista. Pääasia on, että ohjelmoinnin peruskäsitteet jäävät kirkkaammin mieleen kuin IDEn valikot tai tapahtumakäsittelyrutiinien nimet.

TRRY kirjoitti:

Yhtä perusteltua olisi pohtia, pitäisikö heti ensimmäisellä kurssilla opettaa web-ohjelmointia (mitä tekniikoita se sitten kenenkin mielestä tarkoittaa: ajax, flash, silverlight, php, cgi-bin, ...), koska kaikenlaisia webissä toimivia ohjelmia on nykyisin niin paljon.

Ongelma on, että sekä web-ohjelmointi että graafisten käyttöliittymien ohjelmointi pakottaa ohjelmoinnin lisäksi opettelemaan ohjelmoinnista riippumattomia asioita, kuten monimutkaisen IDEn tai arkkitehtuurin.

Joissakin tapauksissa IDE kannustaa jopa oikeissa ohjelmointiprojekteissa täysin kestämättömään työskentelytapaan. Esimerkiksi ohjelman logiikka opitaan toteuttamaan tapahtumienkäsittelyrutiineihin (event handlerit, kuten "OnClick" yms.), käyttöliittymän suunnittelu ohittaa arkkitehtuurisuunnittelun ja tietokannan käsittely tapahtuu erilaisten komponenttien välityksellä ohjelmakoodilta lähes salassa.

Käyttäisin opetettavan ohjelmointikielen ja -työkalujen ja valinnassa perusteena sitä, kuinka pienellä ohjelmointiin kuulumattomien opetettavien asioiden määrällä selvitään. Huonoina esimerkkeinä voisin mainita esimerkiksi Java & Eclipsen ja Visual Studio minkätahansa. Mieti, mitä kaikkea joudut opettamaan selittääksesi, "hello world"-ohjelman tekemisen alusta alkaen; kuinka paljon joudutaan kirjoittamaan tai näkemään generoitua ohjelmakoodia, napsuttelemaan lomakkeita, surffailemaan valikoissa tai tutkimaan käännös/linkkauskomentojen parametrejä. Kaikki ovat sellaista tietoja, ettei niillä toisessa ohjelmointiympärisössä tee mitään.

Ohjelmoinnin perusasioita opettaessa on parasta keskittyä olennaiseen ja valita siksi työkalut, joilla se on eniten mahdollista. Tässä keskustelussa aiemmin mainittu Python on esimerkiksi erittäin hyvä vaihtoehto. Tapahtuuko I/O graafisen käyttöliittymän läpi, webissä vai "tekstirivejä näppäimistöltä" ei ole olennaista. Pääasia on, että ohjelmoinnin peruskäsitteet jäävät kirkkaammin mieleen kuin IDEn valikot tai tapahtumakäsittelyrutiinien nimet.

Lue lisää

Kysymyshän on siitä, mikä on olennaista ohjelmoinnissa. Miten olennaista on osata käyttää jotain kehitysjärjestelmän IDE:tä tai miten tärkeää on opetella heti jonkin ohjelmointikielen syntaksi.

Kuten itsekin totesit, perinteisen ohjelmointitavan ohjelman arkkitehtuuri on melko tavalla erilainen kuin graafisissa käyttöliittymissä. Tuo eventteihin perustuva logiika saattaa tuntua vieraalta. Toisaalta ei pidä verrata perinteistä konsolisovellusta graafiseen sovellukseen. On ihan eri asia printata konsolille "hello world" kuin luoda graafinen käyttöliittymä. Oletko koskaan luonut graafisia komponentteja API-kutsuilla tai ohjelmoinut noita "OnClick" eventtejä Windows-prosessin messagen perusteella? Heti kun mennään perinteisessä ohjelmoinnissa käyttöjärjestelmäkutsujen alueelle, muuttuu perinteinen ohjelmointi tosi vaikeaksi.

Kuitenkin jokin 40 tuntia on melko vähän kurssin pituudeksi. Jos tosiaan on sitä mieltä, että komponentien raahaaminen formille ja ominaisuus-taulukoiden täyttö on ohjelmointiin kuulumattomia asioita ja "Hello world":n printtaaminen DOS -ikkunaan sitä oikeaa ohjelmointia niin asiat täytyy tietysti laitta tärkeysjärjestykseen.

jyt24 kirjoitti:

Kysymyshän on siitä, mikä on olennaista ohjelmoinnissa. Miten olennaista on osata käyttää jotain kehitysjärjestelmän IDE:tä tai miten tärkeää on opetella heti jonkin ohjelmointikielen syntaksi.

Kuten itsekin totesit, perinteisen ohjelmointitavan ohjelman arkkitehtuuri on melko tavalla erilainen kuin graafisissa käyttöliittymissä. Tuo eventteihin perustuva logiika saattaa tuntua vieraalta. Toisaalta ei pidä verrata perinteistä konsolisovellusta graafiseen sovellukseen. On ihan eri asia printata konsolille "hello world" kuin luoda graafinen käyttöliittymä. Oletko koskaan luonut graafisia komponentteja API-kutsuilla tai ohjelmoinut noita "OnClick" eventtejä Windows-prosessin messagen perusteella? Heti kun mennään perinteisessä ohjelmoinnissa käyttöjärjestelmäkutsujen alueelle, muuttuu perinteinen ohjelmointi tosi vaikeaksi.

Kuitenkin jokin 40 tuntia on melko vähän kurssin pituudeksi. Jos tosiaan on sitä mieltä, että komponentien raahaaminen formille ja ominaisuus-taulukoiden täyttö on ohjelmointiin kuulumattomia asioita ja "Hello world":n printtaaminen DOS -ikkunaan sitä oikeaa ohjelmointia niin asiat täytyy tietysti laitta tärkeysjärjestykseen.

Lue lisää

Lazarus(&FreePascal) kehitysympäristöllä onnistuu graafisten sovellusten ja konsolisoftan teko. Voit halutessasi käyttää yhteisiä käännösyksikköjä tai ajaa konsolisoftaa omassa sovelluksessa rinnakkaisesti moniajona. Kokeile itse!

jyt24 kirjoitti:

Kysymyshän on siitä, mikä on olennaista ohjelmoinnissa. Miten olennaista on osata käyttää jotain kehitysjärjestelmän IDE:tä tai miten tärkeää on opetella heti jonkin ohjelmointikielen syntaksi.

Kuten itsekin totesit, perinteisen ohjelmointitavan ohjelman arkkitehtuuri on melko tavalla erilainen kuin graafisissa käyttöliittymissä. Tuo eventteihin perustuva logiika saattaa tuntua vieraalta. Toisaalta ei pidä verrata perinteistä konsolisovellusta graafiseen sovellukseen. On ihan eri asia printata konsolille "hello world" kuin luoda graafinen käyttöliittymä. Oletko koskaan luonut graafisia komponentteja API-kutsuilla tai ohjelmoinut noita "OnClick" eventtejä Windows-prosessin messagen perusteella? Heti kun mennään perinteisessä ohjelmoinnissa käyttöjärjestelmäkutsujen alueelle, muuttuu perinteinen ohjelmointi tosi vaikeaksi.

Kuitenkin jokin 40 tuntia on melko vähän kurssin pituudeksi. Jos tosiaan on sitä mieltä, että komponentien raahaaminen formille ja ominaisuus-taulukoiden täyttö on ohjelmointiin kuulumattomia asioita ja "Hello world":n printtaaminen DOS -ikkunaan sitä oikeaa ohjelmointia niin asiat täytyy tietysti laitta tärkeysjärjestykseen.

Lue lisää

Alkuperäinen kysyjä pohti sopivaa kieltä "ohjelmoinnin perusteiden" opetukseen. Päättelin sillä perusteella, että olennaista on ohjelmoinnin peruskäsitteistön tuntemus. Mielestäni peruskäsitteistöön eivät kuulu IDE:t eikä tapahtumapohjainen (event-driven) ohjelmointi sen enempää kuin Windows-API, POSIXin C-kirjastostandardi, DOMin käsittely Javascriptillä tai Excelin taulukon täyttäminen VBA-ohjelmilla. Ne ovat kaikki ylimääräistä kuormaa, jonka pyrkisin minimoimaan, jos itse tuollaista kurssia vetäisin.

Tietenkin on olemassa paljon tehtäviä, joissa noitakin tekniikoita tarvitaan, mutta kuhunkin tekniikkaan liittyvät ohjelmat muodostavat vain hyvin pienen osan kaikista maailman tietokoneohjelmista.

Kun ohjelmoinnin peruskäsitteet on opetettu, on hienoa jos ehditään ratkaista joitakin pieniä käytännön ongelmiakin. Siinä tietenkin joutuvat opettajankin taidot koetukselle, jos yksi opiskelija haluaa tehdä lottorivin arvontaohjelman puhelimeensa, toinen Windows-PC:lle ohjelman, joka hälyttää, kun www-sivu x on muuttunut, ja kolmas suomi-englanti-sanaston opettelussa auttavan ohjelman Linuxiinsa. Python on siinä mielessä hyvä valinta opetuskieleksi, että jokainen edellisistä tehtävistä voidaan ratkaista muutamalla ohjelmarivillä muutamassa minuutissa (opiskelijoiden tapauksessa muutamassa tunnissa sopivin vinkein?). Siten on mahdollista antaa pieni käsitys siitä, mitä kaikkea voikaan nykyisin ohjelmoida kohtuullisella vaivalla.

Vastauksena kysymykseesi, kyllä, olen luonut graafisia käyttöliittymiä API-kutsuin useampaakin kirjastoa käyttäen ja useammalle alustalle. Olen tehnyt myös käyttöliittymiä IDEillä piirrellen ja törmännyt nopeasti rajoituksiin, joita siitä seuraa ohjelman ulkoasunkin kannalta (esim. VBA-ympäristössä komponenttien luominen lomakkeille dynaamisesti ei ainakaan Office 97:n aikaan ollut edes mahdollista!). Olen kirjoittanut myös lukuisia konsolisovelluksia "DOS-ikkunoihin" (tosin yleensä en Windows-ympäristöön) ja näiden lisäksi ohjelmia, joilla ei ole GUI- tai tekstikäyttöliittymää lainkaan (kirjoitetaan esim. sarjaporttiin, sockettiin, tiedostoon tai tietokantaan) ja vielä vähän web-ohjelmiakin.

Graafisen käyttöliittymän ohjelmointi on minun kokemukseni mukaan hyvin kaukana niistä ohjelmoinnin perusteista, joita tarvitaan, kun vähänkin irroitetaan katsetta verkkoyhteydettömän Windowsin työpöydältä.

Myönnän oikeaksi kritiikin, että GUI-ohjelmointi ei ole osa ohjelmoinnin perusteita (kuten esim olioajattelu on), mutta jos nyt kuitenkin kielenä olisi java, eikä python, niin olisi opiskelijoille motivoivaa tehdä komponentteja ja layoutteja käyttäen yksinkertainen lomake, esim laskin, jonka ympärille voisi sitten asteittain esitellä muita ohjelmoinnin ulottuvuuksia. Samoin GUI/Engine -arkkitehtuurierittely voisi mahtua viikon kurssiin, vaikka viimeiselle päivälle. Tästä voisi jollekin jäädä hyvä itsetunto, mutta joiltakin toisaalta, voisi lopullisesti pallo kadota. Eli jos kaikki menee hyvin, niin viimeisenä iltapäivänä GUI/Engine - esimerkki, mutta muuten vain kertaillaan epäselviä asioita.

Opettajan homma on vaikeaa, on kokemusta.

FreePascal http://www.freepascal.org/ osaa kaiken minkä TurboPascalkin (ja lisäksi hyvin monessa eri käyttöjärjestelmässä). Onhan se yhteensopiva (sillä voi tehdä myös niitä nykyajan hienouksia)

Ei varmaan huono kurssi, mutta otsikoksi ei oikein kelpaa "ohjelmoinnin peruskurssi". Toivottavasti se silti, tai juuri siitä johtuen vastaa enemmistön kurssilaisista odotuksia.

"Koska suurimmalla osalla oli office kotona ..."

Entäs ne joilla ei ole. No, onhan OpenOfficessa vastaava basic.

"...ja suurin osa naisia,päätin tuntien aikana että kurssi viedään VBA-pohjalta lävitse."

Karmea stereotypia! Naisille ei mitään liian vaikeaa, VBA:ta ne ehkä tajuu! Apuva!

*femakko* kirjoitti:

"Koska suurimmalla osalla oli office kotona ..."

Entäs ne joilla ei ole. No, onhan OpenOfficessa vastaava basic.

"...ja suurin osa naisia,päätin tuntien aikana että kurssi viedään VBA-pohjalta lävitse."

Karmea stereotypia! Naisille ei mitään liian vaikeaa, VBA:ta ne ehkä tajuu! Apuva!

Lue lisää

Sukupuolen käyttäminen VBA-valinnan perusteella täyttää minunkin mielestäni syrjinnän tunnusmerkit. Tuollaisen jälkeen on turhaa enää ihmetellä, miksi naiset saavat keskimäärin vähemmän palkkaakin kuin miehet. ;)

No niin, huumori pois. Hyvää kurssin jatkoa!

TRRY kirjoitti:

Sukupuolen käyttäminen VBA-valinnan perusteella täyttää minunkin mielestäni syrjinnän tunnusmerkit. Tuollaisen jälkeen on turhaa enää ihmetellä, miksi naiset saavat keskimäärin vähemmän palkkaakin kuin miehet. ;)

No niin, huumori pois. Hyvää kurssin jatkoa!

Lue lisää

Naiset ajattelevat eri tavoin kuin miehet, ja ohjelmointi vaatii tietynlaista ajattelumallia.

Kuinka monta naista tunnet joka osaa ohjelmoida esim. C :lla? Itse en tunne yhtäkään mutta tunnen monta miestä.

ja sille ei femakkokaan mit... kirjoitti:

Naiset ajattelevat eri tavoin kuin miehet, ja ohjelmointi vaatii tietynlaista ajattelumallia.

Kuinka monta naista tunnet joka osaa ohjelmoida esim. C :lla? Itse en tunne yhtäkään mutta tunnen monta miestä.

Lue lisää

Ensimmäinen tuntemani C ohjelmoija oli nainen, joskus 85-87, en ole varma vuodesta, itse en tiennyt silloin mitään kielestä, enkä yleensäkään olioajattelusta.

Kaikki tunteman ohjelmoinnin parissa työskentelevät naiset ovat minua fiksumpia (no se ei sinänsä paljon todista). Oletan logiikan olevan sen, että naisilla on erittäin suuri henkinen kynnys ryhtyä tällaisiin hommiin, ja ne jotka sen kynnyksen ylittävät ovat sitten todella hyviä.

Tällä ei ole mitään erityistä tekemistä sen seikan kanssa, etteikö sukupuolten ajattelukyvyillä olisi sekä laadullisia että määrällisiä tilastollisia eroja. Mutta asiaa on tuskin pätevästi tutkittu. Jokin viite on sekin, että akateemisen loppututkinnon suorittaneiden naisten määrä senkun kasvaa, mutta ihan huipulla ei paljon naisia näe. Se voi tietysti johtua jonkinlaisista akatemisen maailman sisäänrakennetuista syrjintämekanismeista. Nämä ovat erittäin vaikeita kysymyksiä, turha ottaa jyrkkää kantaa.

Yusa kirjoitti:

Ensimmäinen tuntemani C ohjelmoija oli nainen, joskus 85-87, en ole varma vuodesta, itse en tiennyt silloin mitään kielestä, enkä yleensäkään olioajattelusta.

Kaikki tunteman ohjelmoinnin parissa työskentelevät naiset ovat minua fiksumpia (no se ei sinänsä paljon todista). Oletan logiikan olevan sen, että naisilla on erittäin suuri henkinen kynnys ryhtyä tällaisiin hommiin, ja ne jotka sen kynnyksen ylittävät ovat sitten todella hyviä.

Tällä ei ole mitään erityistä tekemistä sen seikan kanssa, etteikö sukupuolten ajattelukyvyillä olisi sekä laadullisia että määrällisiä tilastollisia eroja. Mutta asiaa on tuskin pätevästi tutkittu. Jokin viite on sekin, että akateemisen loppututkinnon suorittaneiden naisten määrä senkun kasvaa, mutta ihan huipulla ei paljon naisia näe. Se voi tietysti johtua jonkinlaisista akatemisen maailman sisäänrakennetuista syrjintämekanismeista. Nämä ovat erittäin vaikeita kysymyksiä, turha ottaa jyrkkää kantaa.

Lue lisää

Useimmista miehistä ei tulisi hyviä kätilöitä ja useimmista naisista ohjelmoijia. Mielestäni siinä ei ole mitään ihmeellistä. Aivot ovat fyysiseltä rakenteeltaan erilaisia ja se vaikuttaa ajattelutapaan.

"Mutta asiaa on tuskin pätevästi tutkittu."
Asiaa on tutkittu "pätevästi" ja paljon.

"An argument of a female tends to become emotional, although an argument of a male is structural."
http://www.natureinterface.com/e/ni01/P058/

Lisää tietoa kyllä löytää
http://www.google.fi/search?hl=fi&client=firefox-a&rls=org.mozilla:en-US:official&hs=9Gr&q=(woman man)|(female male) brain &btnG=Hae&meta=

puuuuuuuuuuuuh kirjoitti:

Useimmista miehistä ei tulisi hyviä kätilöitä ja useimmista naisista ohjelmoijia. Mielestäni siinä ei ole mitään ihmeellistä. Aivot ovat fyysiseltä rakenteeltaan erilaisia ja se vaikuttaa ajattelutapaan.

"Mutta asiaa on tuskin pätevästi tutkittu."
Asiaa on tutkittu "pätevästi" ja paljon.

"An argument of a female tends to become emotional, although an argument of a male is structural."
http://www.natureinterface.com/e/ni01/P058/

Lisää tietoa kyllä löytää
http://www.google.fi/search?hl=fi&client=firefox-a&rls=org.mozilla:en-US:official&hs=9Gr&q=(woman man)|(female male) brain &btnG=Hae&meta=

Lue lisää

Ihan tuttuja väitteitä..

Tottakai on tutkimuksia, joissa on vertailtu miehiä ja naisia, niin fysiologisesti, fNMR- ja PET-kuvauksella, psykologisilla testeillä ym. Mutta toistaiseksi on vain irrallisia tuloksia, joista on vedetty hyvin kiistanalaisia johtopäätöksiä.

Mutta ei ole mitään kiistatonta kokonaiskuvaa, tilanteesta ja syistä, naisten menestyksestä akateemisessa maailmassa. Tarkoitan erityisesti eri tekijöiden vaikutusta: fysiologiset syyt, kulttuurilliset syyt, sosiologiset syyt, organisaatioiden rakenteesta johtuvat syyt ym. Ei ole päteviä tutkimuksia, ei tietoa.

Niinkuin jo sanoin aikaisemmin, tottakai naisten ja miesten aivojen suorituskyvyssä on tilastollisia laadullisia ja määrällisiä eroja, samoin kuin ihmisrotujen edustajien aivoissa. Mutta tällä hetkellä varmoiksi luokiteltavia, tukimuksiin perustuvia faktoja ei juuri ole. Ei ainakaan noissa viitteissä.

Yusa kirjoitti:

Ihan tuttuja väitteitä..

Tottakai on tutkimuksia, joissa on vertailtu miehiä ja naisia, niin fysiologisesti, fNMR- ja PET-kuvauksella, psykologisilla testeillä ym. Mutta toistaiseksi on vain irrallisia tuloksia, joista on vedetty hyvin kiistanalaisia johtopäätöksiä.

Mutta ei ole mitään kiistatonta kokonaiskuvaa, tilanteesta ja syistä, naisten menestyksestä akateemisessa maailmassa. Tarkoitan erityisesti eri tekijöiden vaikutusta: fysiologiset syyt, kulttuurilliset syyt, sosiologiset syyt, organisaatioiden rakenteesta johtuvat syyt ym. Ei ole päteviä tutkimuksia, ei tietoa.

Niinkuin jo sanoin aikaisemmin, tottakai naisten ja miesten aivojen suorituskyvyssä on tilastollisia laadullisia ja määrällisiä eroja, samoin kuin ihmisrotujen edustajien aivoissa. Mutta tällä hetkellä varmoiksi luokiteltavia, tukimuksiin perustuvia faktoja ei juuri ole. Ei ainakaan noissa viitteissä.

Lue lisää

"Ihan tuttuja väitteitä.. "

Väitteitä? Kyllä ne ihan faktoja ovat.

"Mutta ei ole mitään kiistatonta kokonaiskuvaa, tilanteesta ja syistä, naisten menestyksestä akateemisessa maailmassa."

Puhut ihan omiasi. Tässä ei ollut alunperinkään kyse naisten menestymisestä akateemisessa maailmassa, vaan ohjelmoinnista ja naisten ajattelumallista, jossa on tieteellisten tutkimusten mukaan selvä ero miesten ajattelumalliin.

"fysiologisesti, fNMR- ja PET-kuvauksella, psykologisilla testeillä ym. "

Monta hienoa sanaa laitoit tekstiisi mutta sillä et minua valitettavasti hurmaa. Voisin minäkin luetella vaikka mitä hienoja sanoja jotta vaikuttaisin tietäväni asiasta enemmän kuin tiedänkään, mutta minun ei tarvitse.

"Niinkuin jo sanoin aikaisemmin, tottakai naisten ja miesten aivojen suorituskyvyssä on tilastollisia laadullisia ja määrällisiä eroja, samoin kuin ihmisrotujen edustajien aivoissa. "

Sanot että eroja on, mutta mistä vedät tämän johtopäätöksen jos kerta mielestäsi ei ole alalta luotettavia tutkimuksia? Mitä tarkoitat määrällisillä eroilla?

"Mutta tällä hetkellä varmoiksi luokiteltavia, tukimuksiin perustuvia faktoja ei juuri ole."

Et ole tainnut lukea tieteellisiä julkaisuja alalta, ööhmm, 10 vuoteen? Vai onko sinulla antaa jotain tuoretta viitettä sanojesi tueksi?