Alkaa vb-palsta..

"Käyttäjän kannaltahan se on aivan sama millä se ohjelma on tehty, pääasia että se toimii"

Tyhmä käyttäjä on tyytyväinen siihen että ohjelma toimii toimitushetkellä ja siinä koneessa&käyttöjärjestelmässä jota ohjelman toimittaja suositteli.

Viisas käyttäjä on tyytyväinen vasta kun on varma että ohjelma tod.näk. toimii vielä 10 vuoden päästä uudella käyttiksellä, uudella laitteistolla ja sitä voi jatkokehittää uusilla kehitystyökaluilla. Ja nyt en tarkoita pelkästään uutta windows versiota, uutta intel-prossua ja uutta Visual-whatever-IDE.NETtiä. Siksi viisaalle käyttäjälle VB ei ole mikään vaihtoehto.

C saattaa tuntua melkoselta sotkulta VBasicciin verrattuna, mutta bugeja siinä on vähemmän.

aivan sama? kirjoitti:

"Käyttäjän kannaltahan se on aivan sama millä se ohjelma on tehty, pääasia että se toimii"

Tyhmä käyttäjä on tyytyväinen siihen että ohjelma toimii toimitushetkellä ja siinä koneessa&käyttöjärjestelmässä jota ohjelman toimittaja suositteli.

Viisas käyttäjä on tyytyväinen vasta kun on varma että ohjelma tod.näk. toimii vielä 10 vuoden päästä uudella käyttiksellä, uudella laitteistolla ja sitä voi jatkokehittää uusilla kehitystyökaluilla. Ja nyt en tarkoita pelkästään uutta windows versiota, uutta intel-prossua ja uutta Visual-whatever-IDE.NETtiä. Siksi viisaalle käyttäjälle VB ei ole mikään vaihtoehto.

C saattaa tuntua melkoselta sotkulta VBasicciin verrattuna, mutta bugeja siinä on vähemmän.

Kuinka usein käyttäjä on tietoinen millä kielellä ohjelma on tehty? Vuodelta -98 harvemmalla noita ohjelmia on enää edes koneella muutenkaan. Eri juttu on todella kalliiden suunnitteluohjelmistojen kanssa, mutta harvemmin niissäkään 10 vuotta venataan. Esim. omat ohjelmani toimivat ainakin xp-visva ympäristöissä, joten kyllä ne vielä "muutaman" vuoden ovat käyttökelpoisia. Ei ole pakosti takuita siitäkään, että longhornissa toimisi edes c -ohjelmat VB:tä voi jatkokehittää niin kauan kun Visual Studio sitä pitää hengissä. C :aan on olemassa kehitystyökaluja kyllä paljon enemmän, että siitä voi vielä yhden plussan lisätä kielen nimen perään.

C on varmasti monipuolisempi kieli ja sillä pääsee paremmin pureutumaan laitteistoon käsiksi, ei siinä mitään. Visual Basic-palsta tekee kuolemaa varmaan sen takia, kun kieli on niin helppo, niin kellään ei ole siitä puhuttavaa.. :)

aivan sama? kirjoitti:

"Käyttäjän kannaltahan se on aivan sama millä se ohjelma on tehty, pääasia että se toimii"

Tyhmä käyttäjä on tyytyväinen siihen että ohjelma toimii toimitushetkellä ja siinä koneessa&käyttöjärjestelmässä jota ohjelman toimittaja suositteli.

Viisas käyttäjä on tyytyväinen vasta kun on varma että ohjelma tod.näk. toimii vielä 10 vuoden päästä uudella käyttiksellä, uudella laitteistolla ja sitä voi jatkokehittää uusilla kehitystyökaluilla. Ja nyt en tarkoita pelkästään uutta windows versiota, uutta intel-prossua ja uutta Visual-whatever-IDE.NETtiä. Siksi viisaalle käyttäjälle VB ei ole mikään vaihtoehto.

C saattaa tuntua melkoselta sotkulta VBasicciin verrattuna, mutta bugeja siinä on vähemmän.

"C saattaa tuntua melkoselta sotkulta VBasicciin verrattuna, mutta bugeja siinä on vähemmän. "

Kerrotko lisää?

VBfaniko kirjoitti:

Kuinka usein käyttäjä on tietoinen millä kielellä ohjelma on tehty? Vuodelta -98 harvemmalla noita ohjelmia on enää edes koneella muutenkaan. Eri juttu on todella kalliiden suunnitteluohjelmistojen kanssa, mutta harvemmin niissäkään 10 vuotta venataan. Esim. omat ohjelmani toimivat ainakin xp-visva ympäristöissä, joten kyllä ne vielä "muutaman" vuoden ovat käyttökelpoisia. Ei ole pakosti takuita siitäkään, että longhornissa toimisi edes c -ohjelmat VB:tä voi jatkokehittää niin kauan kun Visual Studio sitä pitää hengissä. C :aan on olemassa kehitystyökaluja kyllä paljon enemmän, että siitä voi vielä yhden plussan lisätä kielen nimen perään.

C on varmasti monipuolisempi kieli ja sillä pääsee paremmin pureutumaan laitteistoon käsiksi, ei siinä mitään. Visual Basic-palsta tekee kuolemaa varmaan sen takia, kun kieli on niin helppo, niin kellään ei ole siitä puhuttavaa.. :)

VB:n suosio perustuu siihen, että se oli joskus vuosina -91 -> -96 erinomainen vaihtoehto tietokantasovellusten käyttöliittymiin ja oli aikoinaan hetkellisesti suosituin kieli. Luonnollisesti vanhoja softia pitää ylläpitää joten sitä edelleen käytetään.

VB:n kielihän on ihan paska, ja tunnetusti räätälöity softa maksaa valtavasti joten se on erittäin tärkeätä huomioida miten se softa toimii 10v kuluttua. C on standardoitu, että se kyllä on merkittävin etu tälle kielelle.

??? kirjoitti:

"C saattaa tuntua melkoselta sotkulta VBasicciin verrattuna, mutta bugeja siinä on vähemmän. "

Kerrotko lisää?

Kyllä varmaan C tuntuu VB-koodia vääntäneeseen tosi sotkuiselle, on mitä ihmeellisimpiä *, ->, &, {}  juttuja. C on tosiaan sääntöjen viidakko ja pakko ollakkin, koska muutoin homma ei toimi ja niitä bugeja syntyy jos ei sääntöjä ymmärrä.

Mutta kerran kun ne säännöt iskostaa takaraivoon, siitä se elämä helpottuu :)

ap. kirjoitti:

Kyllä varmaan C tuntuu VB-koodia vääntäneeseen tosi sotkuiselle, on mitä ihmeellisimpiä *, ->, &, {}  juttuja. C on tosiaan sääntöjen viidakko ja pakko ollakkin, koska muutoin homma ei toimi ja niitä bugeja syntyy jos ei sääntöjä ymmärrä.

Mutta kerran kun ne säännöt iskostaa takaraivoon, siitä se elämä helpottuu :)

Mulle ei ainakaan ole mikää ongelma käyttää osoittimia (*, ->) tai muita merkkejä. Olen tässä koittanut lukea yhtä vanhempaa visual c kirjaa, kun en uudempaakaan tähän hätään löytänyt. Ihan sute kirja.

Kaikkein tuskasinta on se, että kun keksis mihin noi kaikki koodit pitäis työntää. Konsoliohjelman tekeminen ei ole mikään ongelma, vaan form-ohjelman. Jos haluan tehdä luokan, joka sisältää valmiita funkioita, joita sitten kutsun, niin mihin vattuun sen teen ja mihin pitää se include laittaa. Pitääkö mun ottaa noista valmiista templateista Class library ja liittää se varsinaiseen Windows form applicationiin? (Noi saa valittua File->New->Project).

Sama homma Päivi Hietasen C ja olio-ohjelmointi. Esimerkkejä niin perkuleesti. Vielä kun keksis miten niistä saa oikean Windows Form ohjelman kasaan.

Koodin logiikka on samanlaista kuin Visual Basicissä, eikä noiden merkkien "puuttuminen" mitään bugeja aiheuta Visual Basicissä. Tekee vain koodista selkeämpää.