Onko Visual Basic olio-ohjelmointia noudattava kieli? Ainaskin syntaksissa esiintyy Privatet ja Publicit jne..?? Mutta en tajua mitä hyötyä niistä on.
Joudun töissä korjaamaan ja laajentamaan erään toisen työntekijän Visual Basic koodia, joka ei sisällä kommentin kommenttia, aika helevettiä selvitellä, mitä mikäkin systeemi sen koodissa tekee, murrr! ;/
Itse en ole koskaan aijemmin Visual Basicilla ohjelmoinut, mutta kokemusta on C/C , Java, Delphi jne... Eli kyllähän tuon Visual Basicin syntaksin nopeesti oivaltaa tutoriaaleja pikaisesti selaamalla.
Mutta tämä jäi mieleeni siitä koodista, että vaikka siinä esiintyy mukamas Private ja Public, mutta koodi on yhtä perus Basic sukkaa, ylhäältä pötkönä alas jnee. Näky siellä jopa goto hypytkin vilisevän ;D hehe!
Toivottavasti jatkossa saan keskittyä Delphiin, paljon elegantimpi ja parempi sovelluskehitin kuin tuo Visual Basic 6, mikä on nyt käytössä. Tosin uusimmasta Visual Basicista ei ole kokemusta.
Visual Basic?
20
2129
Vastaukset
- xxxxx
Kyllä Visual Basicia voi mielestäni sanoa olio-ohjelmoitikieleksi, vaikka siitä puuttuu monia olio-toimintoja. VisualBasic.Net on ainakin Wikipedian mielestä olio-ohjelmointikieli http://fi.wikipedia.org/wiki/Olio-ohjelmointi
Usein kuitenkin joku tarttuu johonkin triviaaliin merkityksettömään käsitteeseen haukkuen jotain ohjelmointikieltä. Olio-ohjelmointi ei ole itseisarvo eikä sitä pidä käyttää ennen kuin hallitsee ohjelmoinnin perusasiat. Oliot ovat käytännössä vain tietyissä tilanteissa vanhoja aliohjelmia ja funktioita parempia.
Oliokeskustelu on vähän samaa kuin aikoinaan C-kielen kehuminen ja VB:n haukkuminen pointtereiden puutteen vuoksi. Harva C-ohjelmoijakaan käyttää paljoa pointereita vaan koodaa tavallisilla muuttujilla.
Kaikilla kielillä pystyy kyllä räpeltämään. Goto-käskyn suurimittainen käyttö osoittaa, että kunnon ohjelmointitaito ei ole ollut edeltäjälläsi hallussa. Tosin joissakin tapauksissa goto helpottaa ohjelman muutoksen tekoa kun ei tarvitse ajatella koko ohjelmaa. Monesti if-then-goton käyttö on varsin kätevää kunhan sitä käytetään selkeästi.
Ja vain ääliö ei laita tekemäänsä ohjelmakoodiin kommentteja eikä käytä pitkiä selkeitä nimiä muuttujissa ja aliohjelmissa. Tai sitten edeltäjäsi halusi tehdä itsestään korvaamattoman spagettikoodilla, ettei kukaan muu pysty ohjelmia ylläpitämään.
Joten kun itse olen tehnyt Visual Basicilla ohjelmia yli 10 vuotta, niin siltä pohjalta voin sanoa että VB on loistava ohjelmointikehitin.
Ohjelmoija joutuu yleensä yksin ratkaisemaan monia ongelmia, keksimään kiertoteitä, testaamaan ja kirjoittamaan moduleita uudestaan, joten asennoituminen ohjelmointiin pitää olla se, että ei ota negatiivista asennetta, vaan ajattelee aina että miettimällä homma hoituu. Tämä negatiivinen asenne paistaa myös sinun kirjoituksesta kun haukut työvälinettä, jolla joudut työsi tekemään.
Neuvo kaikille ohjelmoijille ja muille työtätekeville: Pidä työvälinettäsi riittävän pätevänä apuvälineenä niin kauan kun sen kanssa joudut töitä tekemään :)
Microsoftin Basic oli mielestäni loistava ohjelmointikieli jo yli 20 vuotta sitten. Visual Basicia ne ovat kehittäneet yli 10 vuotta, joten kyllä se ihan pätevä on.
Joten mene ohjelmoimaan iloisesti lauleskellen ja positiivisella asenteella, niin kyllä pärjäät.- mukaan..
jos pitää pihalla ajaa nurmikko, niin turha sitä varten on leikkuupuimuria ostaa.
aika monessa hommassa visual basicilla on pieni ohjelma siinä vaiheessa jo tehty, kun c :ssa määriteltäisiin vielä muuttujia.
itse olen tosin visual basicin korvannut realbasicilla. sillä kun saa samalla vaivalla käännökset windowsille, linuxille ja macillekin.
tosin tuo windowsille kääntämisen tarve nyt vähenee päivä päivältä. - Seuraava askel
mukaan.. kirjoitti:
jos pitää pihalla ajaa nurmikko, niin turha sitä varten on leikkuupuimuria ostaa.
aika monessa hommassa visual basicilla on pieni ohjelma siinä vaiheessa jo tehty, kun c :ssa määriteltäisiin vielä muuttujia.
itse olen tosin visual basicin korvannut realbasicilla. sillä kun saa samalla vaivalla käännökset windowsille, linuxille ja macillekin.
tosin tuo windowsille kääntämisen tarve nyt vähenee päivä päivältä.Seuraava askel eteenpäin on Lazarus tai esim. Delphi. Tällöinhän ei menetetä mitään (esim. helppokäyttöisyydessä) mutta saadaan paremmat ominaisuudet (esim. olio-ominaisuudet).
http://wiki.mureakuha.com/wiki/Lazarus
http://wiki.mureakuha.com/wiki/Delphi - käytettyäkin
Seuraava askel kirjoitti:
Seuraava askel eteenpäin on Lazarus tai esim. Delphi. Tällöinhän ei menetetä mitään (esim. helppokäyttöisyydessä) mutta saadaan paremmat ominaisuudet (esim. olio-ominaisuudet).
http://wiki.mureakuha.com/wiki/Lazarus
http://wiki.mureakuha.com/wiki/Delphidelphi on tuttu versiosta 3 lähtien. kylixiä tuli joskus kokeiltua, mutta sehän on nyt kuopattu.
lazarustakin kokeilin, mutten tiedä miksi se ei nyt koneellani ole..
pitääkin ladata se heti.
ainakin itse saan mielestäni parempaa koodia delphillä kuin vb:llä. ei se siltikään mitään hyvää koodia taida olla :)
mutta riittää kun toimii.. - ap.
Sori negatiivisuuteni, mutta jotenkin ärsytyskäyrä nousi tuon työntekijän VB-koodin takia, mitä joutui korjailemaan :/
Mielestäni olio-ohjelmointi nimenomaan auttaa siinä vaiheessa kun ja jos ohjelmasta alkaa tulla iso, koodin hallittavuus paranee kummasti hyvän olio-ominaisuuden myötä.
Seuraava ongelma esimerkkinä, missä olio-ohjelmointi auttoi kummasti :)
Kun tein softan joka piti kirjoittaa tekstitiedostot unicode muodossa. Aluksi tein luokan joka kirjoitti tiedostot Unicode Windows-1251 muodossa. Sitten kävikin ilmi, että tämä olikin väärä muoto, oikea oli UTF-8. No, kirjoitin uuden luokan joka kirjoittaa tiedostot UTF-8 muodossa. Alkuperäisen softan koodissa (Delphi) ei tarvinut vaihtaa kuin pari riviä uuteen ja softa kirjoitti lopputuloksen UTF-8 muodossa, koska näiden luokkien metodit pysyivät samoina :)
Eli kyse ei ole pelkästään aliohjelmien samankaltaisuus metodeihin, vaikka niiden tarkoitusperät vaikuttavatkin samankaltaisilta alkuun.
Lisäksi näen pointerit erittäin hyödyllisiksi, niillä saa nopeutta koodiin jos ne vain hallitsee tarpeeksi hyvin.
Delphistä tykkään juuri siksi, että se on ominaisuudeltaa juuri Basicin ja C väliltä, hyviä puolia kummastakin :) - xxxxx
ap. kirjoitti:
Sori negatiivisuuteni, mutta jotenkin ärsytyskäyrä nousi tuon työntekijän VB-koodin takia, mitä joutui korjailemaan :/
Mielestäni olio-ohjelmointi nimenomaan auttaa siinä vaiheessa kun ja jos ohjelmasta alkaa tulla iso, koodin hallittavuus paranee kummasti hyvän olio-ominaisuuden myötä.
Seuraava ongelma esimerkkinä, missä olio-ohjelmointi auttoi kummasti :)
Kun tein softan joka piti kirjoittaa tekstitiedostot unicode muodossa. Aluksi tein luokan joka kirjoitti tiedostot Unicode Windows-1251 muodossa. Sitten kävikin ilmi, että tämä olikin väärä muoto, oikea oli UTF-8. No, kirjoitin uuden luokan joka kirjoittaa tiedostot UTF-8 muodossa. Alkuperäisen softan koodissa (Delphi) ei tarvinut vaihtaa kuin pari riviä uuteen ja softa kirjoitti lopputuloksen UTF-8 muodossa, koska näiden luokkien metodit pysyivät samoina :)
Eli kyse ei ole pelkästään aliohjelmien samankaltaisuus metodeihin, vaikka niiden tarkoitusperät vaikuttavatkin samankaltaisilta alkuun.
Lisäksi näen pointerit erittäin hyödyllisiksi, niillä saa nopeutta koodiin jos ne vain hallitsee tarpeeksi hyvin.
Delphistä tykkään juuri siksi, että se on ominaisuudeltaa juuri Basicin ja C väliltä, hyviä puolia kummastakin :)"Eli kyse ei ole pelkästään aliohjelmien samankaltaisuus metodeihin, vaikka niiden tarkoitusperät vaikuttavatkin samankaltaisilta alkuun."
Ei sinun esimerkkisi valota olio-ohjelmoinnin pätevyyttä perinteisiin aliohjelmiin.
En minä ymmärrä mikä esimerkissäsi on varsinaista olio-ohjelmointia enkä etenkään miten tuo ei olisi ollut vielä helpommin ratkaistavissa perinteisillä aliohjelmilla. Paitsi jos alkuperäisessä koodissa olit laittanut merkistömuunnokset koodisi sisään etkä omaan aliohjelmaan.
Itse ainakin kun olen joskus tehnyt ääkkösmuutoksia eri merkistöjen välillä, niin tietysti olen tehnyt niille oman funktion (tai yhden jossa määrittelen mikä muutos tehdään). Joten merkistömuutos (kuten esimerkissäsi) ei olisi tarvinnut "tavalliseen" aliohjelmafunktioon kuin yhden rivin korjauksen. Sinä teit esimerkissäsi enemmän koodimuutosta ja käytit siihen myös enemmän aikaa. Eli jos esimerkkisi kertoo pätevän esimerkin olio-ohjelmoinnista, niin ei sitä kannata ottaa käyttöön, sillä se ei nopeuta ohjelmamuutoksia eikä lisäyksiä.
"Lisäksi näen pointerit erittäin hyödyllisiksi, niillä saa nopeutta koodiin jos ne vain hallitsee tarpeeksi hyvin."
Pointtereiden käytössä tulee helposti virheitä, sillä ne voivat käyttää mitä osaa muistista tahansa. Eikä ne ole hyödyllisiäkään kuin jossain esimerkkitapauksissa joita ei ohjelmoinnissa paljon käytetä. Parempi onkin käyttää vaikka muuttujataulukoita, jolloin on mahdotonta viitata vahingossa taulukon ulkopuoliseen muistiin.
Kertoisitko vielä miten pointterit nopeuttavat ohjelmakoodin suoritusta? Esimerkiksi kutsuttaessa (ainakin VB:ssä) aliohjelmaa, käyttää välitetyt parametrit oletusarvoisesti muuttujan osoitetta eikä välitä muuttujan sisältöä jos sitä ei haluta (byval-käskyllä). Ja jos pointterin sijasta käytetään taulukkoviittauksia, niin ei niiden käyttö ole hitaampia kuin pointterienkaan käyttö. Lisäksi muistinkäsittely hoituu automaattisesti.
Tietokoneet tulevat jatkuvasti nopeammiksi, joten ei normaaleissa sovelluksissa nopeus ole oleellista. Tärkeää on sen sijaan ohjelmakoodin selkeys ja helppo ylläpidettävyys. - Olio-ohjelmointi
xxxxx kirjoitti:
"Eli kyse ei ole pelkästään aliohjelmien samankaltaisuus metodeihin, vaikka niiden tarkoitusperät vaikuttavatkin samankaltaisilta alkuun."
Ei sinun esimerkkisi valota olio-ohjelmoinnin pätevyyttä perinteisiin aliohjelmiin.
En minä ymmärrä mikä esimerkissäsi on varsinaista olio-ohjelmointia enkä etenkään miten tuo ei olisi ollut vielä helpommin ratkaistavissa perinteisillä aliohjelmilla. Paitsi jos alkuperäisessä koodissa olit laittanut merkistömuunnokset koodisi sisään etkä omaan aliohjelmaan.
Itse ainakin kun olen joskus tehnyt ääkkösmuutoksia eri merkistöjen välillä, niin tietysti olen tehnyt niille oman funktion (tai yhden jossa määrittelen mikä muutos tehdään). Joten merkistömuutos (kuten esimerkissäsi) ei olisi tarvinnut "tavalliseen" aliohjelmafunktioon kuin yhden rivin korjauksen. Sinä teit esimerkissäsi enemmän koodimuutosta ja käytit siihen myös enemmän aikaa. Eli jos esimerkkisi kertoo pätevän esimerkin olio-ohjelmoinnista, niin ei sitä kannata ottaa käyttöön, sillä se ei nopeuta ohjelmamuutoksia eikä lisäyksiä.
"Lisäksi näen pointerit erittäin hyödyllisiksi, niillä saa nopeutta koodiin jos ne vain hallitsee tarpeeksi hyvin."
Pointtereiden käytössä tulee helposti virheitä, sillä ne voivat käyttää mitä osaa muistista tahansa. Eikä ne ole hyödyllisiäkään kuin jossain esimerkkitapauksissa joita ei ohjelmoinnissa paljon käytetä. Parempi onkin käyttää vaikka muuttujataulukoita, jolloin on mahdotonta viitata vahingossa taulukon ulkopuoliseen muistiin.
Kertoisitko vielä miten pointterit nopeuttavat ohjelmakoodin suoritusta? Esimerkiksi kutsuttaessa (ainakin VB:ssä) aliohjelmaa, käyttää välitetyt parametrit oletusarvoisesti muuttujan osoitetta eikä välitä muuttujan sisältöä jos sitä ei haluta (byval-käskyllä). Ja jos pointterin sijasta käytetään taulukkoviittauksia, niin ei niiden käyttö ole hitaampia kuin pointterienkaan käyttö. Lisäksi muistinkäsittely hoituu automaattisesti.
Tietokoneet tulevat jatkuvasti nopeammiksi, joten ei normaaleissa sovelluksissa nopeus ole oleellista. Tärkeää on sen sijaan ohjelmakoodin selkeys ja helppo ylläpidettävyys.Voisi sanoa että jos ei tajua olio-ohjelmointia (vaikka sitä ilman voi tulla toimeenkin ja ennen vanhaan tultiinkin) ei paljon ymmärrä ohjelmoinnista.
Olio-ohjelmoinnin "suola" on periytyminen!
(ilmeisesti sitä ei vieläkään ole VB:ssä mutta se löytyy kaikista muista kielistä: Delphi, FreePascal, Lazarus, C , Java, Smalltalk) - xxxxx
Olio-ohjelmointi kirjoitti:
Voisi sanoa että jos ei tajua olio-ohjelmointia (vaikka sitä ilman voi tulla toimeenkin ja ennen vanhaan tultiinkin) ei paljon ymmärrä ohjelmoinnista.
Olio-ohjelmoinnin "suola" on periytyminen!
(ilmeisesti sitä ei vieläkään ole VB:ssä mutta se löytyy kaikista muista kielistä: Delphi, FreePascal, Lazarus, C , Java, Smalltalk)Ai että ilman olio-ohjelmointia ei paljon ymmärrä ohjelmoinnista. Heh. Ylimielinen sinä olet vaikka tekstistäsi päätellen sinulla ei ole siihen potentiaalia.
Kun sanot että "Olio-ohjelmoinnin "suola" on periytyminen!",
niin miksi suola ja miksi se on vielä lainausmerkeissä? Eikö se olioiden periytyminen sitten olekaan kielen varsinainen perusrakenne jota kaikki olio-kielellä ohjelmoivat jatkuvasti käyttävät?
Oletetaan että väitteesi pitää paikkaansa ja periytyminen on siis vain viimeinen mauste, niin miten määrittelet periytymisen suhteen vaikka käyttöympäristön (=kuvaruudut) aseman siihen? Eikö niiden hiomisen helppous ja kätevyys paremminkin olisi suola, sillä se mauste jää ohjelmaa käyttävän suuhun.
Olen nähnyt huonosti tehtyjä ohjelmia ja vaikeasti ymmärrettävää koodia on sitä helpompi tehdä, mitä enemmän kielessä on typeriä huuhaa-toimintoja joita jotkut kehuvat. Eli olio-ohjelmoinnin typeryys on suuri periytyvyyden käyttö, jolloin koodin ja muuttujien tietyn hetken rakenteen selvittäminen ja muistaminen on hankalaa. Koodin täytyy olla selkeätä ja helppolukuista. Sen vuoksi monet ohjelmointikielet ovat syntaksinsa mukaan varsin tarkkoja (esim. Pascal, Cobol, Ada). Niillä on kyllä typerää tehdä ohjelmia kun ne rajoittavat ohjelmakoodin joustavuutta, mutta niillä tehtyjä ohjelmakoodeja on helppo ymmärtää. Mitä enemmän tehdään sisäkkäisiä ja periytyviä olioita (aliohjelmia ja muuttujarakenteita), sitä vaikeampaa on toisen tekemää koodia tajuta. Java on myös erittäin tarkan syntaksin kieli, joten miksi siihen on täytynyt ympätä periytyvyys? Tajuan kyllä että joissain tilanteissa on kätevää kun ohjelmaan tekee muutoksia, että vanhan koodin voi jättää ennalleen ja tehdä sitten periytyvyydellä lisäyksen. Mutta niitä tilanteita ei ole paljon ja periytyvyydestä tuleekin joillekin ohjelmoijille itseisarvo (eivätkä he siisti aikaisempaa koodia vaan tekevät kaikki korjaukset periytyvyyden kautta), jolloin lopputulos on todellista spakettikoodia.
Vastauksesi on siis varsin töykeä, sillä se sisältää väitteen, että jos en ymmärrä olio-ohjelmoinnin erinomaisuutta, niin olen tyhmä. Tuollainen väite pitää aina perustella, mutta sitä sinä et tee. Et siis mitenkään perustellut edellisen tekstini väitteitä, vaan ylimielisesti pystyit määrittelemään ylivertaisuutesi. Jos sinä ymmärrät paljon minua enemmän ohjelmoinnista, niin sinun on helppo perustellä minun väärät tietoni vääriksi. Minä olen kuitenkin oikeassa, etkä tule siinä onnistumaan. Joten haastan sinut tässä väittelyyn tästä asiasta.
Aloita nyt tämän tekstini alussa olevista kysymyksistä. En ole sanonut että en ymmärtäisi olio-ohjelmointia. Tietysti ainakin sen verran ymmärrän, että "tavalliset" aliohjelmat ovat olioita. Olen sanonut haluavani jotain selkeätä tietoa sen erinomaisuudesta siihen kun ohjelmia tehdään ilman monimutkaisia periytyviä luokkia. Kun sinä väitteesi mukaan tajuat paljon ohjelmoinnista, niin kerro muutama esimerkki tekemistäsi "olioista", joissa olet käyttänyt periytyvyyttä. - ap.
xxxxx kirjoitti:
"Eli kyse ei ole pelkästään aliohjelmien samankaltaisuus metodeihin, vaikka niiden tarkoitusperät vaikuttavatkin samankaltaisilta alkuun."
Ei sinun esimerkkisi valota olio-ohjelmoinnin pätevyyttä perinteisiin aliohjelmiin.
En minä ymmärrä mikä esimerkissäsi on varsinaista olio-ohjelmointia enkä etenkään miten tuo ei olisi ollut vielä helpommin ratkaistavissa perinteisillä aliohjelmilla. Paitsi jos alkuperäisessä koodissa olit laittanut merkistömuunnokset koodisi sisään etkä omaan aliohjelmaan.
Itse ainakin kun olen joskus tehnyt ääkkösmuutoksia eri merkistöjen välillä, niin tietysti olen tehnyt niille oman funktion (tai yhden jossa määrittelen mikä muutos tehdään). Joten merkistömuutos (kuten esimerkissäsi) ei olisi tarvinnut "tavalliseen" aliohjelmafunktioon kuin yhden rivin korjauksen. Sinä teit esimerkissäsi enemmän koodimuutosta ja käytit siihen myös enemmän aikaa. Eli jos esimerkkisi kertoo pätevän esimerkin olio-ohjelmoinnista, niin ei sitä kannata ottaa käyttöön, sillä se ei nopeuta ohjelmamuutoksia eikä lisäyksiä.
"Lisäksi näen pointerit erittäin hyödyllisiksi, niillä saa nopeutta koodiin jos ne vain hallitsee tarpeeksi hyvin."
Pointtereiden käytössä tulee helposti virheitä, sillä ne voivat käyttää mitä osaa muistista tahansa. Eikä ne ole hyödyllisiäkään kuin jossain esimerkkitapauksissa joita ei ohjelmoinnissa paljon käytetä. Parempi onkin käyttää vaikka muuttujataulukoita, jolloin on mahdotonta viitata vahingossa taulukon ulkopuoliseen muistiin.
Kertoisitko vielä miten pointterit nopeuttavat ohjelmakoodin suoritusta? Esimerkiksi kutsuttaessa (ainakin VB:ssä) aliohjelmaa, käyttää välitetyt parametrit oletusarvoisesti muuttujan osoitetta eikä välitä muuttujan sisältöä jos sitä ei haluta (byval-käskyllä). Ja jos pointterin sijasta käytetään taulukkoviittauksia, niin ei niiden käyttö ole hitaampia kuin pointterienkaan käyttö. Lisäksi muistinkäsittely hoituu automaattisesti.
Tietokoneet tulevat jatkuvasti nopeammiksi, joten ei normaaleissa sovelluksissa nopeus ole oleellista. Tärkeää on sen sijaan ohjelmakoodin selkeys ja helppo ylläpidettävyys.Tarkemmin huomenna tai ylihuomenna, kun olen selväpäinen. Täällä näkyy olevan väittelyä olio-ohjelmonnista. Nyt puhun pelkästään VB6:sta, tuosta anaalisesta basicien jälkeläisestä!
Ok. nyt olen liian kännissä kommentoimaan sory!
Huomiseen! - ap.
xxxxx kirjoitti:
"Eli kyse ei ole pelkästään aliohjelmien samankaltaisuus metodeihin, vaikka niiden tarkoitusperät vaikuttavatkin samankaltaisilta alkuun."
Ei sinun esimerkkisi valota olio-ohjelmoinnin pätevyyttä perinteisiin aliohjelmiin.
En minä ymmärrä mikä esimerkissäsi on varsinaista olio-ohjelmointia enkä etenkään miten tuo ei olisi ollut vielä helpommin ratkaistavissa perinteisillä aliohjelmilla. Paitsi jos alkuperäisessä koodissa olit laittanut merkistömuunnokset koodisi sisään etkä omaan aliohjelmaan.
Itse ainakin kun olen joskus tehnyt ääkkösmuutoksia eri merkistöjen välillä, niin tietysti olen tehnyt niille oman funktion (tai yhden jossa määrittelen mikä muutos tehdään). Joten merkistömuutos (kuten esimerkissäsi) ei olisi tarvinnut "tavalliseen" aliohjelmafunktioon kuin yhden rivin korjauksen. Sinä teit esimerkissäsi enemmän koodimuutosta ja käytit siihen myös enemmän aikaa. Eli jos esimerkkisi kertoo pätevän esimerkin olio-ohjelmoinnista, niin ei sitä kannata ottaa käyttöön, sillä se ei nopeuta ohjelmamuutoksia eikä lisäyksiä.
"Lisäksi näen pointerit erittäin hyödyllisiksi, niillä saa nopeutta koodiin jos ne vain hallitsee tarpeeksi hyvin."
Pointtereiden käytössä tulee helposti virheitä, sillä ne voivat käyttää mitä osaa muistista tahansa. Eikä ne ole hyödyllisiäkään kuin jossain esimerkkitapauksissa joita ei ohjelmoinnissa paljon käytetä. Parempi onkin käyttää vaikka muuttujataulukoita, jolloin on mahdotonta viitata vahingossa taulukon ulkopuoliseen muistiin.
Kertoisitko vielä miten pointterit nopeuttavat ohjelmakoodin suoritusta? Esimerkiksi kutsuttaessa (ainakin VB:ssä) aliohjelmaa, käyttää välitetyt parametrit oletusarvoisesti muuttujan osoitetta eikä välitä muuttujan sisältöä jos sitä ei haluta (byval-käskyllä). Ja jos pointterin sijasta käytetään taulukkoviittauksia, niin ei niiden käyttö ole hitaampia kuin pointterienkaan käyttö. Lisäksi muistinkäsittely hoituu automaattisesti.
Tietokoneet tulevat jatkuvasti nopeammiksi, joten ei normaaleissa sovelluksissa nopeus ole oleellista. Tärkeää on sen sijaan ohjelmakoodin selkeys ja helppo ylläpidettävyys.Entäs jos taas tapahtuu muutoksia koodiisi ja joudut käyttämään alkupeäisiä ominaisuuksia, tai voit kloonata ominaisuuksia toisiin ohjelmiin, helposti olio-ominaisuudella, että pitää aina kirjoittaa juttuja uusiksi. Sehän on olio-ohjelmoinnin koko idea!!! Pyörää ei kannata keksiä aina uudelleen!!! Tuo oli vain pieni esimerkki jäävuoren huipusta, miksi oliomaista ajattelua kanantta opiskella heti alusta pitäen! Kaikki merkittävät kielet sitä tukee!
Pointerit kannattaa opetella, niillä saa tehokasta koodia aikaan helposti, jos ne hallitsee hyvin ja jos kieli sen sallii. Enempää en tähän sano, ottakoon itse siitä selvää ken haluaa. Jos on liian vaikeeta, kannattaa vaihtaa alaa! - ap.
ap. kirjoitti:
Entäs jos taas tapahtuu muutoksia koodiisi ja joudut käyttämään alkupeäisiä ominaisuuksia, tai voit kloonata ominaisuuksia toisiin ohjelmiin, helposti olio-ominaisuudella, että pitää aina kirjoittaa juttuja uusiksi. Sehän on olio-ohjelmoinnin koko idea!!! Pyörää ei kannata keksiä aina uudelleen!!! Tuo oli vain pieni esimerkki jäävuoren huipusta, miksi oliomaista ajattelua kanantta opiskella heti alusta pitäen! Kaikki merkittävät kielet sitä tukee!
Pointerit kannattaa opetella, niillä saa tehokasta koodia aikaan helposti, jos ne hallitsee hyvin ja jos kieli sen sallii. Enempää en tähän sano, ottakoon itse siitä selvää ken haluaa. Jos on liian vaikeeta, kannattaa vaihtaa alaa!Sanotaan että ohjelma käytää struktuureja, rakenteita, joka voi sisältää paljon tietoja, eri muuttujia. Sitten luot linkitetyn listan, johon voi näitä struktuureja lisätä mielin määrin, niin paljon koneessa on kapasiteettia.
Pistät vain listaa aina uuden rakenteen.
lista.add( rakenne ); // jne...
Tästä on kätevä etsiä näitä rakenteita, ilma että tehdään asijoista liian monimutkaisia, ilman pointereinta tämä homma ei onnistuisi. Sitä paitsi vaikka Javassa ei ole pointereita, silti ne on siellä olemassa "sisällä" ja joka ei tajua POINTEREIDEN merkityksestä mitään, on HUKASSA!!! Nähty on! - ap.
xxxxx kirjoitti:
Ai että ilman olio-ohjelmointia ei paljon ymmärrä ohjelmoinnista. Heh. Ylimielinen sinä olet vaikka tekstistäsi päätellen sinulla ei ole siihen potentiaalia.
Kun sanot että "Olio-ohjelmoinnin "suola" on periytyminen!",
niin miksi suola ja miksi se on vielä lainausmerkeissä? Eikö se olioiden periytyminen sitten olekaan kielen varsinainen perusrakenne jota kaikki olio-kielellä ohjelmoivat jatkuvasti käyttävät?
Oletetaan että väitteesi pitää paikkaansa ja periytyminen on siis vain viimeinen mauste, niin miten määrittelet periytymisen suhteen vaikka käyttöympäristön (=kuvaruudut) aseman siihen? Eikö niiden hiomisen helppous ja kätevyys paremminkin olisi suola, sillä se mauste jää ohjelmaa käyttävän suuhun.
Olen nähnyt huonosti tehtyjä ohjelmia ja vaikeasti ymmärrettävää koodia on sitä helpompi tehdä, mitä enemmän kielessä on typeriä huuhaa-toimintoja joita jotkut kehuvat. Eli olio-ohjelmoinnin typeryys on suuri periytyvyyden käyttö, jolloin koodin ja muuttujien tietyn hetken rakenteen selvittäminen ja muistaminen on hankalaa. Koodin täytyy olla selkeätä ja helppolukuista. Sen vuoksi monet ohjelmointikielet ovat syntaksinsa mukaan varsin tarkkoja (esim. Pascal, Cobol, Ada). Niillä on kyllä typerää tehdä ohjelmia kun ne rajoittavat ohjelmakoodin joustavuutta, mutta niillä tehtyjä ohjelmakoodeja on helppo ymmärtää. Mitä enemmän tehdään sisäkkäisiä ja periytyviä olioita (aliohjelmia ja muuttujarakenteita), sitä vaikeampaa on toisen tekemää koodia tajuta. Java on myös erittäin tarkan syntaksin kieli, joten miksi siihen on täytynyt ympätä periytyvyys? Tajuan kyllä että joissain tilanteissa on kätevää kun ohjelmaan tekee muutoksia, että vanhan koodin voi jättää ennalleen ja tehdä sitten periytyvyydellä lisäyksen. Mutta niitä tilanteita ei ole paljon ja periytyvyydestä tuleekin joillekin ohjelmoijille itseisarvo (eivätkä he siisti aikaisempaa koodia vaan tekevät kaikki korjaukset periytyvyyden kautta), jolloin lopputulos on todellista spakettikoodia.
Vastauksesi on siis varsin töykeä, sillä se sisältää väitteen, että jos en ymmärrä olio-ohjelmoinnin erinomaisuutta, niin olen tyhmä. Tuollainen väite pitää aina perustella, mutta sitä sinä et tee. Et siis mitenkään perustellut edellisen tekstini väitteitä, vaan ylimielisesti pystyit määrittelemään ylivertaisuutesi. Jos sinä ymmärrät paljon minua enemmän ohjelmoinnista, niin sinun on helppo perustellä minun väärät tietoni vääriksi. Minä olen kuitenkin oikeassa, etkä tule siinä onnistumaan. Joten haastan sinut tässä väittelyyn tästä asiasta.
Aloita nyt tämän tekstini alussa olevista kysymyksistä. En ole sanonut että en ymmärtäisi olio-ohjelmointia. Tietysti ainakin sen verran ymmärrän, että "tavalliset" aliohjelmat ovat olioita. Olen sanonut haluavani jotain selkeätä tietoa sen erinomaisuudesta siihen kun ohjelmia tehdään ilman monimutkaisia periytyviä luokkia. Kun sinä väitteesi mukaan tajuat paljon ohjelmoinnista, niin kerro muutama esimerkki tekemistäsi "olioista", joissa olet käyttänyt periytyvyyttä.Periytyminen on vain yksi suola muiden joukossa. Eikä sitä paljon tule edes käytettyä, paitsi jos se tarjoaa äärimmäistä hyötyä tai on valmiissa luokissa jo jotenkin määritelty, vain yksi ominaisuus.
Itse näen olio-ohjelmoinnin etuna sen kloonattavuus ja kaikkea voi kopioida mielin määrin muistiin ja ohjelman hallittavuus paranee huomattavasi oliomaisuuden myötä. Koodi ei ole pelkää sillisalaattia ylhäältä pötkänä alas. Olen koodaillut jo vuodesta 1989 aloittaen juuri Basicista, olio-ohjelmoinnin idean opettelin vuonna 1998, joten kokemusta sen eduista kyllä löytyy. - xxxxx
ap. kirjoitti:
Sanotaan että ohjelma käytää struktuureja, rakenteita, joka voi sisältää paljon tietoja, eri muuttujia. Sitten luot linkitetyn listan, johon voi näitä struktuureja lisätä mielin määrin, niin paljon koneessa on kapasiteettia.
Pistät vain listaa aina uuden rakenteen.
lista.add( rakenne ); // jne...
Tästä on kätevä etsiä näitä rakenteita, ilma että tehdään asijoista liian monimutkaisia, ilman pointereinta tämä homma ei onnistuisi. Sitä paitsi vaikka Javassa ei ole pointereita, silti ne on siellä olemassa "sisällä" ja joka ei tajua POINTEREIDEN merkityksestä mitään, on HUKASSA!!! Nähty on!Et voi olla tosissasi. Siis siinä että väität olevasti hyväkin ohjelmoija. Sanoit seuraavasti:
"Tästä on kätevä etsiä näitä rakenteita, ilma että tehdään asijoista liian monimutkaisia, ilman pointereinta tämä homma ei onnistuisi. Sitä paitsi vaikka Javassa ei ole pointereita, silti ne on siellä olemassa "sisällä" ja joka ei tajua POINTEREIDEN merkityksestä mitään, on HUKASSA!!! Nähty on!"
Tuo tekstisi on karmeaa sokellusta ja osoittaa ettet tiedä ohjelmoinnista paljoakaan. Eli et ole ohjelmoija, vaan joku harrastelija joka selittää asioita joita ei ymmärrä. Et ymmärrä kokonaisuutta ja kuitenkin yrität esiintyä asiantuntijana niin, että hallitset yksityiskohdat. Perustelen väitteeni mahdollisimman ymmärrettävästi.
Kuten sanoit, niin Javassa ei ole pointtereita, joten niitä ei voi Javassa käyttää. Itse määriteltyjä linkitettyjä listoja voi tietysti käyttää kaikissa ohjelmointikielissä. Sivulla http://javala.cs.tut.fi/show.do?category=collections on tuosta sinun mainitsemastasi linkitetystä listasta. Mutta se ei siis liity pointtereihein vaan on linkitetty lista. Se miten ohjelmointikielen sisäisten käskyjen taustalla oleva koodi on toteutettu on näkymätöntä eikä siitä tarvitse tietääkään. Väitteesi että pointterit on Javassa "sisällä" on siten ääliömäinen. Eli Javassa on lista johon voi lisätä olioita. Listaa voidaan lajitella ja sitä voidaan käsitellä muilla toimenpiteillä. Sillä ei ole merkitystä miten Java sisäisesti esim. listan lajittelun hoitaa.
Käyttäähän ohjelmointikieletkin esim. aliohjelmien kutsuissa muuttujien (olioiden) osoitteita, paitsi jos ohjelmoija haluaa että aliohjelmalle välitetään muuttujan sisältö. Mutta ei noita ole ennenkään pointtereiksi kutsuttu.
Ohjelmoinnissa tärkeintä tietysti on lopullinen ohjelma. Se miten ohjelma on koodattu on loppukäyttäjälle yksi hailee, sillä hän ei tiedä koodista mitään vaan näkee vain analogisen (toivottavasti ei digitaalisen) lopputuloksen. Vähän samaan tapaan kuin digi-television käyttäjä ei mieti miten radioaalloista muodostuu kuva televisioon. Ohjelmoija on sitten samassa tilanteessa siinä, miten ohjelmointikieli sisäisesti asiat hoitaa. Ei niitä tiedä eikä ainakaan tarvitse tietää. Täysin älytöntä on, jos joku esittää väitteen, että jokin ohjelman sisäinen asia pitäisi tietää tai on hukassa.
Sanoit ylempänä myös näin:
"Pointerit kannattaa opetella, niillä saa tehokasta koodia aikaan helposti, jos ne hallitsee hyvin ja jos kieli sen sallii. Enempää en tähän sano, ottakoon itse siitä selvää ken haluaa. Jos on liian vaikeeta, kannattaa vaihtaa alaa!"
Miten niin pointtereilla saa tehokasta koodia aikaan helposti? Tehokkaampaa koodi on siltä osin kun ohjelmointikieli ei valvo muistirajoja, mutta se vaikeuttaa ohjelman tekemista. Tosin kuten ylempänä jo perustelin, niin et ymmärrä pointtereita, koska puhut niistä kielistä jotka ei niitä sisällä.
C sisältää pointterit eli osoittimet http://trade.hamk.fi/~lseppane/courses/cpp/doc/pointer.html
Mutta tuo mainitsemasi esimerkki Javasta on siis lista eikä pointterit liity siihen. Näin ollen tekstisikään ei varsinaisesti liity pointtereihin. - ap.
xxxxx kirjoitti:
Et voi olla tosissasi. Siis siinä että väität olevasti hyväkin ohjelmoija. Sanoit seuraavasti:
"Tästä on kätevä etsiä näitä rakenteita, ilma että tehdään asijoista liian monimutkaisia, ilman pointereinta tämä homma ei onnistuisi. Sitä paitsi vaikka Javassa ei ole pointereita, silti ne on siellä olemassa "sisällä" ja joka ei tajua POINTEREIDEN merkityksestä mitään, on HUKASSA!!! Nähty on!"
Tuo tekstisi on karmeaa sokellusta ja osoittaa ettet tiedä ohjelmoinnista paljoakaan. Eli et ole ohjelmoija, vaan joku harrastelija joka selittää asioita joita ei ymmärrä. Et ymmärrä kokonaisuutta ja kuitenkin yrität esiintyä asiantuntijana niin, että hallitset yksityiskohdat. Perustelen väitteeni mahdollisimman ymmärrettävästi.
Kuten sanoit, niin Javassa ei ole pointtereita, joten niitä ei voi Javassa käyttää. Itse määriteltyjä linkitettyjä listoja voi tietysti käyttää kaikissa ohjelmointikielissä. Sivulla http://javala.cs.tut.fi/show.do?category=collections on tuosta sinun mainitsemastasi linkitetystä listasta. Mutta se ei siis liity pointtereihein vaan on linkitetty lista. Se miten ohjelmointikielen sisäisten käskyjen taustalla oleva koodi on toteutettu on näkymätöntä eikä siitä tarvitse tietääkään. Väitteesi että pointterit on Javassa "sisällä" on siten ääliömäinen. Eli Javassa on lista johon voi lisätä olioita. Listaa voidaan lajitella ja sitä voidaan käsitellä muilla toimenpiteillä. Sillä ei ole merkitystä miten Java sisäisesti esim. listan lajittelun hoitaa.
Käyttäähän ohjelmointikieletkin esim. aliohjelmien kutsuissa muuttujien (olioiden) osoitteita, paitsi jos ohjelmoija haluaa että aliohjelmalle välitetään muuttujan sisältö. Mutta ei noita ole ennenkään pointtereiksi kutsuttu.
Ohjelmoinnissa tärkeintä tietysti on lopullinen ohjelma. Se miten ohjelma on koodattu on loppukäyttäjälle yksi hailee, sillä hän ei tiedä koodista mitään vaan näkee vain analogisen (toivottavasti ei digitaalisen) lopputuloksen. Vähän samaan tapaan kuin digi-television käyttäjä ei mieti miten radioaalloista muodostuu kuva televisioon. Ohjelmoija on sitten samassa tilanteessa siinä, miten ohjelmointikieli sisäisesti asiat hoitaa. Ei niitä tiedä eikä ainakaan tarvitse tietää. Täysin älytöntä on, jos joku esittää väitteen, että jokin ohjelman sisäinen asia pitäisi tietää tai on hukassa.
Sanoit ylempänä myös näin:
"Pointerit kannattaa opetella, niillä saa tehokasta koodia aikaan helposti, jos ne hallitsee hyvin ja jos kieli sen sallii. Enempää en tähän sano, ottakoon itse siitä selvää ken haluaa. Jos on liian vaikeeta, kannattaa vaihtaa alaa!"
Miten niin pointtereilla saa tehokasta koodia aikaan helposti? Tehokkaampaa koodi on siltä osin kun ohjelmointikieli ei valvo muistirajoja, mutta se vaikeuttaa ohjelman tekemista. Tosin kuten ylempänä jo perustelin, niin et ymmärrä pointtereita, koska puhut niistä kielistä jotka ei niitä sisällä.
C sisältää pointterit eli osoittimet http://trade.hamk.fi/~lseppane/courses/cpp/doc/pointer.html
Mutta tuo mainitsemasi esimerkki Javasta on siis lista eikä pointterit liity siihen. Näin ollen tekstisikään ei varsinaisesti liity pointtereihin.Nojuu, minä en jaksa mitää fiiniä läppää tähän heittää, kerron vain kokemuksistani. Tässä on "muutama vuos" kummiskin koodailtu sekä harrastuksena, että työnä.
Kyllähän siellä Javan sisällä pitää jotkin "osoittimet" (vaikka se oliolista sitten) olla jos luodaan olio ja se lisätään vaikka sitten sinne linkitettyyn listaan. Tätä ajoin nimenomaan takaa. Muutenhan koko homma EI OLISI edes mahdollinen.
Vai oli kommenttini ääliömäinen?? :D
Eikös se oliolista ole juuri sama asia kuin jokin pointeri joka osoittaa tiettyy kohtaan koneen muistissa???? C /Delphissä se lista on vain itse koneen muisti! Eli eiköhän ne pointerit ole siellä Javassakin silti "sisällä" kuten sanoin. Jokatapauksessa toimintatapa on täsmälleen sama niin C :ssa kuin Javassakin, esim. jos halutaan lisätä jokin olio sinne linkitettyyn listaan.
Kyllä tässä hakataan ihan samaa puuta, minulla on vain oma käsitykseni asiasta joka toimii käytännössä, se riittä mulle.
Ja tosi on, olen itseoppinut harrastelia, aloitin vuodesta 1989 ja tänään koodailen työkseni. - Lehtori
Olio-ohjelmointi kirjoitti:
Voisi sanoa että jos ei tajua olio-ohjelmointia (vaikka sitä ilman voi tulla toimeenkin ja ennen vanhaan tultiinkin) ei paljon ymmärrä ohjelmoinnista.
Olio-ohjelmoinnin "suola" on periytyminen!
(ilmeisesti sitä ei vieläkään ole VB:ssä mutta se löytyy kaikista muista kielistä: Delphi, FreePascal, Lazarus, C , Java, Smalltalk)Vain Suomessa puhutaan ja sauhutaan Olio-ohjelmoinnista. Muualla maailmassa puhutaan objekti orientoituneesta ohjelmoinnista, ilman sen kummempaa meteliä. Objektin idea on jo vanha, rengasta ei tarvitse keksiä uudelleen.
- Hannu Haa
xxxxx kirjoitti:
Et voi olla tosissasi. Siis siinä että väität olevasti hyväkin ohjelmoija. Sanoit seuraavasti:
"Tästä on kätevä etsiä näitä rakenteita, ilma että tehdään asijoista liian monimutkaisia, ilman pointereinta tämä homma ei onnistuisi. Sitä paitsi vaikka Javassa ei ole pointereita, silti ne on siellä olemassa "sisällä" ja joka ei tajua POINTEREIDEN merkityksestä mitään, on HUKASSA!!! Nähty on!"
Tuo tekstisi on karmeaa sokellusta ja osoittaa ettet tiedä ohjelmoinnista paljoakaan. Eli et ole ohjelmoija, vaan joku harrastelija joka selittää asioita joita ei ymmärrä. Et ymmärrä kokonaisuutta ja kuitenkin yrität esiintyä asiantuntijana niin, että hallitset yksityiskohdat. Perustelen väitteeni mahdollisimman ymmärrettävästi.
Kuten sanoit, niin Javassa ei ole pointtereita, joten niitä ei voi Javassa käyttää. Itse määriteltyjä linkitettyjä listoja voi tietysti käyttää kaikissa ohjelmointikielissä. Sivulla http://javala.cs.tut.fi/show.do?category=collections on tuosta sinun mainitsemastasi linkitetystä listasta. Mutta se ei siis liity pointtereihein vaan on linkitetty lista. Se miten ohjelmointikielen sisäisten käskyjen taustalla oleva koodi on toteutettu on näkymätöntä eikä siitä tarvitse tietääkään. Väitteesi että pointterit on Javassa "sisällä" on siten ääliömäinen. Eli Javassa on lista johon voi lisätä olioita. Listaa voidaan lajitella ja sitä voidaan käsitellä muilla toimenpiteillä. Sillä ei ole merkitystä miten Java sisäisesti esim. listan lajittelun hoitaa.
Käyttäähän ohjelmointikieletkin esim. aliohjelmien kutsuissa muuttujien (olioiden) osoitteita, paitsi jos ohjelmoija haluaa että aliohjelmalle välitetään muuttujan sisältö. Mutta ei noita ole ennenkään pointtereiksi kutsuttu.
Ohjelmoinnissa tärkeintä tietysti on lopullinen ohjelma. Se miten ohjelma on koodattu on loppukäyttäjälle yksi hailee, sillä hän ei tiedä koodista mitään vaan näkee vain analogisen (toivottavasti ei digitaalisen) lopputuloksen. Vähän samaan tapaan kuin digi-television käyttäjä ei mieti miten radioaalloista muodostuu kuva televisioon. Ohjelmoija on sitten samassa tilanteessa siinä, miten ohjelmointikieli sisäisesti asiat hoitaa. Ei niitä tiedä eikä ainakaan tarvitse tietää. Täysin älytöntä on, jos joku esittää väitteen, että jokin ohjelman sisäinen asia pitäisi tietää tai on hukassa.
Sanoit ylempänä myös näin:
"Pointerit kannattaa opetella, niillä saa tehokasta koodia aikaan helposti, jos ne hallitsee hyvin ja jos kieli sen sallii. Enempää en tähän sano, ottakoon itse siitä selvää ken haluaa. Jos on liian vaikeeta, kannattaa vaihtaa alaa!"
Miten niin pointtereilla saa tehokasta koodia aikaan helposti? Tehokkaampaa koodi on siltä osin kun ohjelmointikieli ei valvo muistirajoja, mutta se vaikeuttaa ohjelman tekemista. Tosin kuten ylempänä jo perustelin, niin et ymmärrä pointtereita, koska puhut niistä kielistä jotka ei niitä sisällä.
C sisältää pointterit eli osoittimet http://trade.hamk.fi/~lseppane/courses/cpp/doc/pointer.html
Mutta tuo mainitsemasi esimerkki Javasta on siis lista eikä pointterit liity siihen. Näin ollen tekstisikään ei varsinaisesti liity pointtereihin.Sinulle VB taitaa olla ideologia? Kuulostat kuin kakarat PS vs. XBOX taisteluissaan.
- koko vb-roska
jos omaa masokistisia taipumuksia niin kannattaa käyttää vb:tä, muuten delphiä/c /javaa... siitä päivästä lähtien kun vb julkaistiin sillä on tehty lähinnä roskaa ja tilanne ei ole nykyään muuttunut tippaakaan, mutta sitä käytetään vain koska se on microsoftin, vaikka ehdottomasti surkeimpia viritelmiä mitä on olemassa niin kieleltään kuin muutenkin.
otan osaa jos joudut vb:llä tekemään oikeasti jotain leipäsi eteen.- stefan5
Moniko muuten vastasi alkuperäiseen kysymykseen ? Vaikka hakoteillehän sekin meni...
- miksi jämähtää?
stefan5 kirjoitti:
Moniko muuten vastasi alkuperäiseen kysymykseen ? Vaikka hakoteillehän sekin meni...
Työpaikalla tilanne missä VB6:lla koodanneita ja pitäisi kohta päivittä käyttis Windows 7:aan. VB7 muut kielet ovat kuulemma oliopaskaa..
- heeguli.
Duunipaikalla nyt kovasti kuhinaa, kun pitää vb6- juttuja päivittää .netille. Samoten päivittää vanhoja Officen vba- makroja win7- alustalle.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Ensitreffit Jenni laukoo viinilasin ääressä suorat sanat Jyrkin aikeista: "Mä sanoin, että älä"
Voi ei… Mitä luulet: kestääkö Jennin ja Jyrkin avioliitto vai päättyykö eroon? Lue lisää: https://www.suomi24.fi/viihde272930Ymmärrän paremmin kuin koskaan
Roikut kädessäni ja vedät puoleesi. Näen kuitenkin tämän kaiken lävitse ja kaikkien takia minun on tehtävä tämä. Päästän342622- 1482284
Hullu liikenteessä?
Mikä hullu pyörii kylillä jos jahti päällä? Näitä tosin kyllä riittää tällä kylällä.542259Niina Lahtinen uudessa elämäntilanteessa - Kotiolot ovat muuttuneet merkittävästi: "Nyt on...!"
Niina, tanssejasi on riemukasta seurata, iso kiitos! Lue Niinan haastattelu: https://www.suomi24.fi/viihde/niina-lahti241880Kun Venäjä on tasannut tilit Ukrainan kanssa, onko Suomi seuraava?
Mitä mieltä olette, onko Suomi seuraava, jonka kanssa Venäjä tasaa tilit? Ja voisiko sitä mitenkään estää? Esimerkiks3911716Ano Turtiainen saa syytteet kansankiihoituksesta
Syytteitä on kolme ja niissä on kyse kirjoituksista, jotka hän on kansanedustaja-aikanaan julkaissut Twitter-tilillään1051664- 3121569
- 1351469
Varokaa! Lunta voi sataa kohta!
Vakava säävaroitus Lumisadevaroitus Satakunta, Uusimaa, Etelä-Karjala, Keski-Suomi, Etelä-Savo, Etelä-Pohjanmaa, Pohjanm131456