VMP touhua nykyspedeily

Anonyymi

Ennen vanhaan hyvään aikaan VB6:ssa määritettiin tila esim.
Dim state as Integer
Dim fault as Boolean

Tänään:

Hooks? Redux? Rematch? Recoil? (luettele tähän perään seuraavat 20 javascript state management kirjastoa)

MIKSI ???

25

1418

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
      • Anonyymi

        Suomessa liikkeellä hanakka kalastelukampanja – Kyberturvallisuuskeskus: tuhansia viestejä lähetetty lukuisiin organisaatioihin
        Erityisesti organisaatioiden keskuudessa on viime viikkoina levinnyt Microsoftin Power Apps -portaalia hyödyntävä tietojenkalastelukampanja.


    • Anonyymi

      Miksi WP6 ei olisi entinen, senkun käytät.

      • Anonyymi

        WP6 kääntäjä ei toimi W10 ja W11:sta. WPrun....


    • Anonyymi

      Siitä syystä että ohjelman tila ei olisi levällään olioissa eri puolilla ohjelmaa vaan yhdessä paikassa. Objektit halutaan myös tehdä niin, että niiden tilaa ei voida muuttaa, eli olisivat immutable.

      Tämähän on pääsyy miksi miksi vanhat Visual Basic ja Delphi ohjelmat ovat paskaa kun ovat täynnä älyttömiä bugeja johtuen siitä, että ohjelman tila on levällään olioissa. Kun tilan muutosta ei hallita, tulee sitten hassuja tlanteita että jokin olio on tilassa mitä ei huomioida.

      React kehityksessä Redux oli aivan ykkösvaihtoehto aiemmin tilan hallinnassa mutta nykyään Reactissa on valmiina se React hooks jota voi käyttää kuin Reduxia niin ei tarvitse erillistä palikkaa tuohon. Tuo riittää React kehityksessä hyvin pitkälle että jos Reactilla tekee niin ei oikeastaan tarvitse muuta enää miettiä, ei ennenkuin siitä React hooksista tulee joku oikea ongelma että tarvitsisi parempaa.

      Se sitten taas johtuu React ekosysteemistä miksi niitä palikoita on paljon, kun React ei ole framework, se on kirjasto joka ratkaisee käyttöliittymäkomponenttien tekemisen ja virtualdomin. Eri asioihin on sitten kirjastoja joten tilan hallintaan tehty useita kirjastoja.

      • Anonyymi

        Entä onko vanhat C, C , C harp -ohjelmat myös pashaa?


      • Anonyymi
        Anonyymi kirjoitti:

        Entä onko vanhat C, C , C harp -ohjelmat myös pashaa?

        Mitäs se kirjoitustaidottomille kuuluu.


      • Anonyymi
        Anonyymi kirjoitti:

        Entä onko vanhat C, C , C harp -ohjelmat myös pashaa?

        Nyt on kyse käyttöliittymäohjelmoinnista eikä kielestä.

        Windowsille oli aikoinaan WPF ja tälle XAML, että sillä sai jo ihan hyvin tehtyä asian. Tuota käytettiin paljon C#:lla ja sillä sai jo ihan mukavasti.

        C:llä ja C :lla käyttöliittymäohjelmoinnin ongelma ei ole niinkään kielessä vaan kirjastoissa. Kyllä se käyttöliittymäpuoli oli lähinnä kuraa näissä. Nykypäivänä jos pitäisi näillä tehdä niin alkaisi projekti jonkun state managementin kirjoittamisesta.


      • Anonyymi

        "Tämähän on pääsyy miksi miksi vanhat Visual Basic ja Delphi ohjelmat ovat paskaa kun ovat täynnä älyttömiä bugeja johtuen siitä, että ohjelman tila on levällään olioissa"

        Taas M-Karin katteettomia höpinöitä.

        Koko luokkien ideahan on nimenomaan siinä, että luokka voi sisältää (ja yleensä sisältääkin) sekä koodia että dataa, jotka liittyvät toisiinsa.

        Siinä, että tila tallennetaan luokan kenttiin, ei ole mitään väärää.

        Se, että siinä olisi jotain väärää, on vain M-Karin aivopieru.

        Toki, jos samassa ohjelmassa on useita olioita, tulee huolehtia siitä, etteivät oliot ole keskenään ristiriidassa.

        Minulle ainakaan tilan tallennus olioihin ei ole ikinä aiheuttanut minkäänlaisia ongelmia.

        Toki ne oliot ja niiden vuorovaikutus toisten olioiden kanssa pitää suunnitella oikein, ja jos tässä tekee virheitä, niin tietenkin silloin on sekasotkua luvassa.


      • Anonyymi
        Anonyymi kirjoitti:

        "Tämähän on pääsyy miksi miksi vanhat Visual Basic ja Delphi ohjelmat ovat paskaa kun ovat täynnä älyttömiä bugeja johtuen siitä, että ohjelman tila on levällään olioissa"

        Taas M-Karin katteettomia höpinöitä.

        Koko luokkien ideahan on nimenomaan siinä, että luokka voi sisältää (ja yleensä sisältääkin) sekä koodia että dataa, jotka liittyvät toisiinsa.

        Siinä, että tila tallennetaan luokan kenttiin, ei ole mitään väärää.

        Se, että siinä olisi jotain väärää, on vain M-Karin aivopieru.

        Toki, jos samassa ohjelmassa on useita olioita, tulee huolehtia siitä, etteivät oliot ole keskenään ristiriidassa.

        Minulle ainakaan tilan tallennus olioihin ei ole ikinä aiheuttanut minkäänlaisia ongelmia.

        Toki ne oliot ja niiden vuorovaikutus toisten olioiden kanssa pitää suunnitella oikein, ja jos tässä tekee virheitä, niin tietenkin silloin on sekasotkua luvassa.

        "Koko luokkien ideahan on nimenomaan siinä, että luokka voi sisältää (ja yleensä sisältääkin) sekä koodia että dataa, jotka liittyvät toisiinsa."

        Miksi yrität vääntää käyttöliittymäkomponenttia luokkana kun sen voi tehdä paremmin funktiona?

        Lisäksi olet ymmärtänyt olio-ohjelmoinnin väärin. Olio-ohjelmoinnin idea ei ole kytkeä koodia ja dataa toisiinsa, vaan mallintaa käsitteitä.

        "Minulle ainakaan tilan tallennus olioihin ei ole ikinä aiheuttanut minkäänlaisia ongelmia.

        Toki ne oliot ja niiden vuorovaikutus toisten olioiden kanssa pitää suunnitella oikein, ja jos tässä tekee virheitä, niin tietenkin silloin on sekasotkua luvassa."

        Sanoit että ei olisi aiheuttanut ongelmia mutta sitten kerrot että voi tulla virheitä ja sekasotkua.


      • Anonyymi

        Ilmankos ilma tieteen laitoksen xmlhttp olio on hajallaan ja jättää tiedot amazonin palvelimelle.


      • Anonyymi
        Anonyymi kirjoitti:

        Nyt on kyse käyttöliittymäohjelmoinnista eikä kielestä.

        Windowsille oli aikoinaan WPF ja tälle XAML, että sillä sai jo ihan hyvin tehtyä asian. Tuota käytettiin paljon C#:lla ja sillä sai jo ihan mukavasti.

        C:llä ja C :lla käyttöliittymäohjelmoinnin ongelma ei ole niinkään kielessä vaan kirjastoissa. Kyllä se käyttöliittymäpuoli oli lähinnä kuraa näissä. Nykypäivänä jos pitäisi näillä tehdä niin alkaisi projekti jonkun state managementin kirjoittamisesta.

        Siksi Wintoosasta onkin koodattu toinen puoli hinkuvintiassa java scriptillä. Billin hyväntekeväisyytenä ja toinen puoli machine coodilla Intelin tehtaalla.


    • Anonyymi

      Enpä sanoisi, että kaikki olisi ollut noin huonosti Pascal/Delphi/C/Cpp aikana: Kyllä sitä aiemminkin on osattu tehdä tila-olio, joka sisältää kaiken tilaan liittyvän. Ja C:ssä on tehty vastaavasti struct(Pascalin record), joka sisältää tilan(ja kaiken muun tarvittavan pointterin päässä) ja kuljetetaan mukana funktioille parametrina. Ennemminkin kyse on huonosta ohjelmointityylistä eli luokkiin voi sisällyttää (vahingossa) tilamuuttujia, joilla olisi tarvetta laajemmallekin näkyvyydelle eikä pelkästään kyseisessä oliossa ja koska sijainti on luokassa eikä ohjelman tilasta vastaavassa oliossa sitä ei välttämättä huomata riippuvuuksia tarkastettaessa - kehitysvaiheessa tavallaan unohdettu viedä kantaluokan puolelle tieto, mikä sinne kuuluisi.
      Ennen oli kaikki vaikeampaa.

      • Anonyymi

        Hyvä kommentti. Kirjoitit C-koodista ikäänkuin menneessä aikamuodossa, mutta C-kielihän on yhä edelleen vahvassa asemassa etenkin sulautetuissa järjestelmissä. Tyypillisesti nekin ovat erittäin laajoja ohjelmistoja nykyään ja saattavat rakentua sadoista moduuleista ja lukuisista ohjelmakirjastoista. Ilman objektimallia tällaisten projektien hallinta olisi toivotonta. Vaikkei C-kieli olekaan lähtökohtaisesti OO, osaavan koodarin kädenjäljen tunnistaa OO-ajattelusta.

        Pienen mikrokontrollerin pieni koodi voi olla mitä vain, kukaan ei huutele perään. Mutta projektia, jossa on mukana useita kehittäjiä ja jossa mm. koodin uudellenkäytöllä on arvoa, globaalien resurssien Dimensointi siten kuin ennen vanhaan hyvään aikaan oli tapana, ei kanna pitkälle.


      • Anonyymi

        Olet oikeassa. Kyllä ennen vanhaankin sai tehtyä hyvin ohjelmia mutta vanhan ajan työkalut teki huonon ohjelmoinnin helpoksi ja lopputulos oli sen mukaista. Käyttöliittymäkomponentit ovat kuitenkin lähes täysin tilattomia.


      • Anonyymi
        Anonyymi kirjoitti:

        Hyvä kommentti. Kirjoitit C-koodista ikäänkuin menneessä aikamuodossa, mutta C-kielihän on yhä edelleen vahvassa asemassa etenkin sulautetuissa järjestelmissä. Tyypillisesti nekin ovat erittäin laajoja ohjelmistoja nykyään ja saattavat rakentua sadoista moduuleista ja lukuisista ohjelmakirjastoista. Ilman objektimallia tällaisten projektien hallinta olisi toivotonta. Vaikkei C-kieli olekaan lähtökohtaisesti OO, osaavan koodarin kädenjäljen tunnistaa OO-ajattelusta.

        Pienen mikrokontrollerin pieni koodi voi olla mitä vain, kukaan ei huutele perään. Mutta projektia, jossa on mukana useita kehittäjiä ja jossa mm. koodin uudellenkäytöllä on arvoa, globaalien resurssien Dimensointi siten kuin ennen vanhaan hyvään aikaan oli tapana, ei kanna pitkälle.

        "Hyvä kommentti. Kirjoitit C-koodista ikäänkuin menneessä aikamuodossa, mutta C-kielihän on yhä edelleen vahvassa asemassa etenkin sulautetuissa järjestelmissä. Tyypillisesti nekin ovat erittäin laajoja ohjelmistoja nykyään ja saattavat rakentua sadoista moduuleista ja lukuisista ohjelmakirjastoista."

        Saahan sitä C-kielellä tehtyä laajoja ohjelmistoja mutta kyseinen kieli on tehty siihen, että prosessit ovat yksinkertaisia. C-kielellä se luontainen tapa tehdä laajoja ohjelmistoja on suunnitella ne toimimaan isosta määrästä stdin->stdout putkissa olevista palikoista joita käyttöjärjestelmä ajaa omina prosesseinaan ja näiden prioriteetteja voi säätää.

        Tämä malli sitten automaattisesti jakaa laitteella kuormaa eri käyttäjille, eri prosessoreille ja toimii erittäin vähäisellä muistin käytöllä ilman että tarvitsisi miettiä rinnakkaisuutta matalalla tasolla. Mutta, se vaan kuitenkin on ajalta kun muistin määrä rajoitti ja käsiteltävät datamäärät olivat pienempiä. Ongelma tässä mallissa kun on se latenssi mikä tulee aina käynnistettäessä prosessia joten ajamalla sitä laajempaa softaa isommassa, monoliittisemmassa prosessissa saadaan huimasti parempi suorituskyky muistin kulutuksen kustannuksella. Ja se se isompi, monoliittinen prosessi sitten on C:llä ikävää tämän nimiavaruuden takia.

        "Vaikkei C-kieli olekaan lähtökohtaisesti OO, osaavan koodarin kädenjäljen tunnistaa OO-ajattelusta."

        No ei mitenkään selvästi. OO-ajattelu toimii liiketoimintalogiikassa tai kun mallinnetaan käsitteitä. Tietorakenteiden, algoritmien ja vähän matemaattisempien asioiden kanssa funktionaalinen malli on ylivertainen.


      • Anonyymi
        Anonyymi kirjoitti:

        "Hyvä kommentti. Kirjoitit C-koodista ikäänkuin menneessä aikamuodossa, mutta C-kielihän on yhä edelleen vahvassa asemassa etenkin sulautetuissa järjestelmissä. Tyypillisesti nekin ovat erittäin laajoja ohjelmistoja nykyään ja saattavat rakentua sadoista moduuleista ja lukuisista ohjelmakirjastoista."

        Saahan sitä C-kielellä tehtyä laajoja ohjelmistoja mutta kyseinen kieli on tehty siihen, että prosessit ovat yksinkertaisia. C-kielellä se luontainen tapa tehdä laajoja ohjelmistoja on suunnitella ne toimimaan isosta määrästä stdin->stdout putkissa olevista palikoista joita käyttöjärjestelmä ajaa omina prosesseinaan ja näiden prioriteetteja voi säätää.

        Tämä malli sitten automaattisesti jakaa laitteella kuormaa eri käyttäjille, eri prosessoreille ja toimii erittäin vähäisellä muistin käytöllä ilman että tarvitsisi miettiä rinnakkaisuutta matalalla tasolla. Mutta, se vaan kuitenkin on ajalta kun muistin määrä rajoitti ja käsiteltävät datamäärät olivat pienempiä. Ongelma tässä mallissa kun on se latenssi mikä tulee aina käynnistettäessä prosessia joten ajamalla sitä laajempaa softaa isommassa, monoliittisemmassa prosessissa saadaan huimasti parempi suorituskyky muistin kulutuksen kustannuksella. Ja se se isompi, monoliittinen prosessi sitten on C:llä ikävää tämän nimiavaruuden takia.

        "Vaikkei C-kieli olekaan lähtökohtaisesti OO, osaavan koodarin kädenjäljen tunnistaa OO-ajattelusta."

        No ei mitenkään selvästi. OO-ajattelu toimii liiketoimintalogiikassa tai kun mallinnetaan käsitteitä. Tietorakenteiden, algoritmien ja vähän matemaattisempien asioiden kanssa funktionaalinen malli on ylivertainen.

        VITUN ITSEKSEEN JUTTELIJA!


    • Anonyymi

      "MIKSI ???"

      Pitäähän se käyttöliittymän tilan oltava jossain. Tuo VB6 esimerkkisi ei hallinnoi koko käyttöliittymän tilaa, eikä huolehdi sen tilan muutoksista.

      React hooks on valmiina Reactissa, että ei tarvitse erillistä kirjastoa.

      • Anonyymi

        Voi voi! WP6 Hallitsi! Muuta ei nykyään.
        WP6 kääntäjä ei toimi W10 ja W11:sta. WPrun....


    • Anonyymi

      Jaska puhetta, .NET corea on microsfotin kaikille alustoille ujuttama tulevaisuuden koodialusta ja se perustuu XAML:ään ja manageroituihin kieliin, eikä mihinkään björnin c-bunkkerissa 70-luvlla kyhäämään pula-ajan peruna-murteeseen.

      Ja kaiken maailman xml-jsonnit on yliopistohaihattelijoiden oikeaa ohjelmointia ymmärtämätöntä sekasotkua mikä vie yhden datayksikön esittämiseen 100 x paketoitua muka-kaiken maailman datan kategoroivaa non sensea.

      Ja kuka päästi valloilleen scriptikääntäjän laajennukset ylemmän-ylemmän-ylemmän tason loputtamaan purkkasotkuiluun valloissa, täytyyhän lapsilla olla tekemistä ja rahaa kulua. Todellako päivän lämpötilan esittämiseen kuluu 100 GB laajakaistaa, 10 GB kovalevytilaa ja 10 THz prosessoriaikaa. Antakaa meidän jo nauraa.

      • Anonyymi

        .NET on itc mailman surkeutta, älä nyt sillä mitään tee.


      • Anonyymi

        Et vaan osaa.


    • Anonyymi

      Ja katsokaapa sinne tietokoneen sisällle, siellä on 2 x 8 senttiä kokoinen muistilätyskä, kuinka sellaisen edestakaisin vääntellyyn kuluu yhtä paljon energiaa kuin koko maailman historian esittämiseen.

      No sellaista se on kun resurssit kohdennetaan vuosikymmeniä yhden ja saman asian jauhamiseen ja tuloksena on Andromedaan ulottuva iisakin kirkko.

      Siellä on Ram-muisti ja prosessori, ei sen monimutkaisempaa ole, kaikki teidän reaktinne ja muut olionne, ne siirtelevät vain bittejä pitkin yhtä ja samaa RAm-muistia.
      Pitäkää nyt jo järki päässä ja asiat yksinkertaina, kun ne sellaisia lopulta ovat.
      ATK ei ole mikään luonnonlaki, vaan tekniikan taidetta ja logiikan säveltämistä. Ei pidä antaa ahneuden viedä koko yhteiskuntaa loputtomaan sekasotkuun ja rahan haaskaukseen.

      • Anonyymi

        .NET ei ole mitään tekemistä WP6 kanssa!


      • Anonyymi

        React nimenomaan on yksinkertainen.


    Ketjusta on poistettu 1 sääntöjenvastaista viestiä.

    Luetuimmat keskustelut

    1. Tänään pyörit ajatuksissa enemmän, kun erehdyin lukemaan palstaa

      En saisi, silti toivon että sinä vielä palaat ja otetaan oikeasti selvää, hioituuko särmät ja sulaudummeko yhteen. Vuod
      Ikävä
      22
      5304
    2. Huomenta ihana

      Kauniskasvoinen ihanuus 😘 saan sut vielä
      Ikävä
      25
      4498
    3. Hei rakas...

      Miten on työpäivä sujunut? Rakastan sinua 💗
      Ikävä
      28
      2621
    4. Edelleen sitä on vaikea uskoa

      Että olisit oikeasti rakastunut muhun
      Ikävä
      34
      2284
    5. Toiveikas vai toivoton

      torstai? Ajatuksia?
      Ikävä
      37
      2028
    6. Vitsi mihin menit. Heti takasin.

      Mä näin sut tuu takasin! Oli kiire, niin en ehtiny sin perään!
      Ikävä
      15
      1968
    7. En ole koskaan kokenut

      Ennen mitään tällaista rakastumista. Tiedän että kaipaan sinua varmaan loppu elämän. Toivottavasti ei tarvitsisi vain ka
      Ikävä
      19
      1627
    8. Mukavaa päivää

      Mun rakkauden kohteelle ❤️ toivottavasti olet onnellinen
      Ikävä
      12
      1551
    9. Voi ei! Jari Sillanpää heitti keikan Helsingissä - Hämmästyttävä hetki lavalla...

      Ex-tangokuningas on parhaillaan konserttikiertueella. Hän esiintyi Savoy teatterissa äitienpäivänä. Sillanpää jakoi kons
      Suomalaiset julkkikset
      21
      1297
    10. Kerranki asiat oikein

      Ilkka ja muut pienpuolueeet...teitte hyvän työn kun valitsitte pätevän henkilön virkaan eikä kepulle passelia!! Jatkakaa
      Haapavesi
      10
      1214
    Aihe