Kehitän yhtä softaa Lazaruksella, lähinnä oman projektin testaukseen ja kun olen vanha Delphi-koodari (koodailin eka kertaa Delphillä 1996), toki mukava Lazaruksella on edelleen koodailla.
Yhtä asiaa toivoisin Lazarukselta, että se kehittyisi vähän eteenpäin, vaikka Delphi 7 olikin loistava kehitysväline, voisihan Lazarus mennä jo vähän eteenpäin tuosta Delphistä, jonka esikuva se on, tai ottaisivat forkin ja kehittäisivät eteenpäin Lazarusta?
Unelmaa olisi, jos tuossa Lazaruksessa olisi vaikka Vscoden kaltainen se editori, jossa yhdessä välilehdessä voisi olla tuo desgntime -toiminto, UI:n teko. Toisaalta etsi-toiminto voisi olla Vscoden kaltainen, ei tuommoinen erikseen esille pompsahtava dialogi, tuo on jo aika vanha tapa. Kaipailisin myös debug break -listaa, onko tämmöistä Lazaruksessa? Ettei niitä debug break -pompuloita tarvi etsiä ja niitä vois kytkeä päälle/pois Vscoden tapaan.
Itse Pascal -kielikin vois kehittyä, tai tuon voisi korvata kokonaan D-kielellä, jossa muuttujat voi määritellä immutableiksi, muutenkin kuin argumenteissa consteiksi ja jossa voi käyttää assosiatiivisia taulukoita jne.. D-kieli on kuin paranneltu versio C-kielestä, mutta ei niin sekoboltsi kuin C++.
Eli tietynlaista jämähtämistä ja jäykkyyttä tuossa Lazaruksessa on, toivoin että olisi tullut jotain isompaa muutosta kun versio muuttui 3.
Toki Lazarus on avoimen lähdekoodin versio ja jossa on tietty taaksepäin yhteensopivuus Delphin kanssa, toki tältä kannalta ymmärrän tämän.
Lazarus 3.0
31
845
Vastaukset
- Anonyymi
Miksi ei sitten koodailisi VS Codella ja jollain uudemmalla kielellä?
UI ohjelmoinnissa Typescript on yleensä paras ja siihen saa Chromen päivittymään reaaliajassa rinnalle, että näkee miltä näyttää.- Anonyymi
Niin koodailenkin Vscodella ja D-kielellä sovelluskirjastot, jotka kääntyy sekä Windows- että eri Linux -jakeluihin. Näitä testailen tuolla Lazaruksella tekemälläni softalla. Nuo web-systeemit vähän nahistaa, ainakin desktop-sovellusten teossa, nettisivut on asia erikseen.
- Anonyymi
Anonyymi kirjoitti:
Niin koodailenkin Vscodella ja D-kielellä sovelluskirjastot, jotka kääntyy sekä Windows- että eri Linux -jakeluihin. Näitä testailen tuolla Lazaruksella tekemälläni softalla. Nuo web-systeemit vähän nahistaa, ainakin desktop-sovellusten teossa, nettisivut on asia erikseen.
Hyvinhän sitä Typescriptillä kirjoittaa desktop sovellusta.
- Anonyymi
Anonyymi kirjoitti:
Hyvinhän sitä Typescriptillä kirjoittaa desktop sovellusta.
Purralespon Ukrainan tukeminen 2 Miljardilla Suomen tässä tilanteessa on HULLUUTTA!
- Anonyymi
Anonyymi kirjoitti:
Purralespon Ukrainan tukeminen 2 Miljardilla Suomen tässä tilanteessa on HULLUUTTA!
Sinänsä Ukrainan tukeminen on viisautta koska jos Ukraina voittaa sodan, se takaa rauhan muuallekin Eurooppaan ja myös Suomeen. SE taas ei ole viisautta että rakennetaan Turun tunnin juna jossa säästyy aikaa matkustaessa jopa 10 minuuttia ja junaradan tekemiseen menee 4 miljardia euroa ja ne rahat revitään eläkeläisiltä ja duunareilta, sekä sote-alueilta ja kolmannen osapuolen sotejärjestöitlä!!
- Anonyymi
K-o-l -l-i-m-a-a-t-t-o-r-i ☠
💩💩💩💩💩💩💩💩💩
KUOPIONPERSEREIJÄN MILESTÄ KAIKKI WINDOWSIN VIAT JA ONGELMAT JOHTUU KÄYTTÄJÄSTÄ TAI MUISTA LAITTEISTA!
VAJAKIT ON VAJAKKEJA! VAEHTELIJOITA! - Anonyymi
😍😋😍😋😍😋😍😋😍
😋 Nymfomaani -> https://ye.pe/finngirl21#18260516
🔞❤️💋❤️💋❤️🔞❤️💋❤️💋❤️🔞
- Anonyymi
Hieman väärä palsta ehkä esittää kehitysehdotuksia? En usko, että kehittäjäyhteisössä on mukana suomenkielisiä.
Toisekseen kehitysehdotukset kerrotaan yleensä hyvissä ajoin ennen julkaisua jotta tarvittavista muutoksista ehditään keskustella ja päättää tehdäänkö niitä vai hylätäänkö ominaisuus.
Hankala nähdä miten toisen yrityksen koodipohjaa voisi ylipäätään hyödyntää avoimen koodin projektissa - varsinkin kun kyseessä on VS-Code - joka jakaa mielipiteitä. - Anonyymi
"Itse Pascal -kielikin vois kehittyä, tai tuon voisi korvata kokonaan D-kielellä, jossa muuttujat voi määritellä immutableiksi,"
HÖNÖ Hei, kaikissa ohjelmointikielissä on vakioiden asettaminen mahdollista, mitä helvettiä siitä tulisi ellei muuttujaa voisi vakioksi asettaa.- Anonyymi
Et nyt ymmärrä mitä ajoin takaa, esim D-kieleesä
immutable count = cast(int) array.length;
^ Tuota count -muuttujaa ei voi tuon alustuksen jälkeen enää muuttaa koodissa toiseksi, tuo on muutenkin hyvä tapa, että ainoastaan muuttujat joita oikeesti tarvii muuttaa (mutable) käytetään ns. perinteisinä muuttujina. Mitä vähemmän "liikkuvia osia" koodissa on, sen parempi.
- Anonyymi
Oletko MKar ? On taas niin paikkaansa pitämätöntä lässyttämistä ettei tuollaisia kirjoituksia saisi julkaista ollenkaan.
- Anonyymi
Hah, no en ole M-Kar, lienekkö tuo enää edes hengissä? Lisäksi M-Kar taisi inhota Pascalia yli kaiken?
-ap - Anonyymi
Anonyymi kirjoitti:
Hah, no en ole M-Kar, lienekkö tuo enää edes hengissä? Lisäksi M-Kar taisi inhota Pascalia yli kaiken?
-apInhosi Delphiä ja Lazarusta...
Ei sentään tainnut Pascalia vihata?
- Anonyymi
"Unelmaa olisi, jos tuossa Lazaruksessa olisi vaikka Vscoden kaltainen se editori, jossa yhdessä välilehdessä voisi olla tuo desgntime -toiminto, UI:n teko."
Olipas tuo tyhmästi sanottu, mutta tarkoittanet kuitenkin käyttöliittymän suunnittelua ohjelmaan. Iloksesi voin kertoa että sellainen on ollut jo useita vuosia käyttöön otettavissa, ilmestymis vuotta en muista kun en sitä käytä.- Anonyymi
Nimen omaan UI:n tekoa Delphi tyyliin, se on paras asia Delphissä/Lazaruksessa, kaiken näköinen nysvääminen jollakin Bootstrap/js/html -virityksellä ym. on arseesta ainakin web-devauksessa, kun asiaa ei voi tehdä visuaalisesti.
- Anonyymi
Anonyymi kirjoitti:
Nimen omaan UI:n tekoa Delphi tyyliin, se on paras asia Delphissä/Lazaruksessa, kaiken näköinen nysvääminen jollakin Bootstrap/js/html -virityksellä ym. on arseesta ainakin web-devauksessa, kun asiaa ei voi tehdä visuaalisesti.
Voihan sitä devausta tehdä visuaalisesti webbiin.
Käyttöliittymä kuitenkin on tietorakenteena puu, eli siihen lisätään juurisolmun alle komponentteja ja niiden alle lisää komponentteja, että saadaan koko käyttöliittymä kuvattua. Se näkyy siinä Lazaruksessakin vasemmassa yläreunassa "Components" kohdassa: https://wiki.lazarus.freepascal.org/images/c/ca/lazarus_win10_19044_1706.png
Eli siihen rakentuu se puu.
Bootstrap sen enempää kuin JS ei sitä käyttöliittymän rakennetta tee. Se on se HTML/DOM. Ja JS hommissakin rakennetta sitä hierarkiaa voi kuvata JSX:llä.
On noihin visuaalisia välineitä toki myös mutta kysehän on puun rakennuksesta ja siellä olevien solmujen ominaisuuksien muuttamisesta.
- Anonyymi
Lazaruksessa on aina ollut esimerkki sovellus kustakin komponentista mutta vasta tässä 3 versiossa ne on asetettu valikosta tavoitettaviksi ja se on kiitoksen arvoinen teko.
- Anonyymi
Monessa Linux jakelussa on kalenteri työpöytä vempain (widget) joka on hankalasti modifioitavissa sellaiseksi kun haluaa.
Mutta nyt on Lazaruksen komponenttipaletissa uusi kalenteri komponentti, jonka viimeistely on paljon helpompaa kuin järjestelmään valmiiksi asennetun kalenterin tyylittely.
Kannattaa kokeilla taitojaan vaikket koskaan aiemmin olisi ohjelmoinut Lazaruksella mitään.
Luultavasti saat korvattua järjestelmän tylyn kalenterin itse tehdyllä. - Anonyymi
"muuttujat voi määritellä immutableiksi"
KUKA hullu haluaa jotain "immutable" -roskaa ehdoin tahdoin lisää ???
1. Delphissä voi määritellä VAKIOITA (ei muuttujia) const -avainsanalla (var -avainsanan sijasta).
2. STRINGit ovat jo muutenkin immutable silloin, kun STRINGin "referecnce count" >= 2.
Jos taas STRINGin "referecnce count" = 1, niin tuo immutable on vain ja ainoastaan haitallinen ominaisuus !
Ja jos taas jotain merkkijonoa ei KOSKAAN ole tarkoitus muuttaa, silloin näin:
const
VakioStr = 'tämä ei muutu ikinä';
Jotkut kai kannattavat tuota immutable -systeemiä, kun ajattelevat, että se on monisäikeisessä koodissa nopeampi. Ehkä onkin, mutta tuollainen immutable -systeemi aiheuttaa ongelmia muistinhallinnalle, lisää ohjelman RAM -muistin kulutusta, ja jos RAM on vähissä, Windows ottaa SWAPFILE:n käyttöön - eli jos on mekaaninen kiintolevy, kone hidastuu huomattavasti.
SSD -levyillä hidastuminen on vähäisempää, mutta SSD -levyillä taas on rajallinen kirjoituskertamäärä, ja kun se tulee täyteen, niin:
1) tietoa voi kadota/vahingoittua
JA
2) SSD -levy täytyy tällöin uusia, eli tulee lisää kustannuksia.- Anonyymi
HAITALLISTA SEKOILUS
"2. STRINGit ovat jo muutenkin immutable silloin, kun STRINGin "referecnce count" >= 2.
Jos taas STRINGin "referecnce count" = 1, niin tuo immutable on vain ja ainoastaan haitallinen ominaisuus !
"
Jos et tunne termiä, käytä ihan kotimaista sanavarastoasi selittäessäsi asioita, vaikutat typerykseltä yrittäessäsi olla itseäsi älykkäämmän oloinen.
TÄTÄ ET YMMÄRRÄ JA SIKSI SEITYKSESI ON IHMEELLINEN HUUHAA SEPITYS.
"Jos taas STRINGin "referecnce count" = 1"
Olisit vaan kirjoittanut näin
"Jos MERKKIJONO TYYPPISEN muuttujan "viittausten määrä" = 1"
Minua oksettaa tuollaiset satusedät jotka yrittävät antaa mielikuvan pätevästä taitajasta hämäämällä laajemmin tuntremattomilla termeillä, suoraan sanottuna:
OLET MISTÄÄN MITÄÄN TIETÄMÄTÖN PASKAHOUSU
Yäk hyi - Anonyymi
Helvetin idiooti
- Anonyymi
"KUKA hullu haluaa jotain "immutable" -roskaa ehdoin tahdoin lisää ???"
Vaikka sellainen joka haluaa, että ohjelma toimii nopeammin.
Kun on immutable, kääntäjä tietää että ei ole muuttunut ja tehdä tehokkaita optimointeja. Kääntäjä voi vaikka automaattisesti jättää asioita kopioimatta ja käyttää viittauksia ja pitää dataa kertaalleen siellä muistissa koska immutablella voidaan varmistaa että ei muutu.
Ram muistin kulutuksesta ei sovelluksen koodissa tarvitse oikein välittää. Se oli sitä Turbo Pascal aikaa kun oli niitä 64kt muistirajoja. - Anonyymi
"immutable -systeemi aiheuttaa ongelmia muistinhallinnalle, lisää ohjelman RAM -muistin kulutusta"
Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään.
Ihan ihmeellistä pätemisen tarvetta puhua täyttä paskaa. - Anonyymi
Anonyymi kirjoitti:
"immutable -systeemi aiheuttaa ongelmia muistinhallinnalle, lisää ohjelman RAM -muistin kulutusta"
Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään.
Ihan ihmeellistä pätemisen tarvetta puhua täyttä paskaa.Taitaa olla sama tyyppi jonka mielestä Delphi on paras ohjelmointikieli ja sillä tehdyt ohjelmat ovat virheettömiä.
Hauska ristiriita tässä että jos jokin immutable niin sillä juurikin vältetään tekemästä sivuvaikutuksia. - Anonyymi
Anonyymi kirjoitti:
Taitaa olla sama tyyppi jonka mielestä Delphi on paras ohjelmointikieli ja sillä tehdyt ohjelmat ovat virheettömiä.
Hauska ristiriita tässä että jos jokin immutable niin sillä juurikin vältetään tekemästä sivuvaikutuksia.Oletko hullu?
- Anonyymi
Anonyymi kirjoitti:
"KUKA hullu haluaa jotain "immutable" -roskaa ehdoin tahdoin lisää ???"
Vaikka sellainen joka haluaa, että ohjelma toimii nopeammin.
Kun on immutable, kääntäjä tietää että ei ole muuttunut ja tehdä tehokkaita optimointeja. Kääntäjä voi vaikka automaattisesti jättää asioita kopioimatta ja käyttää viittauksia ja pitää dataa kertaalleen siellä muistissa koska immutablella voidaan varmistaa että ei muutu.
Ram muistin kulutuksesta ei sovelluksen koodissa tarvitse oikein välittää. Se oli sitä Turbo Pascal aikaa kun oli niitä 64kt muistirajoja.Immutable ei mitenkään mystisesti muuta ohjelmaa nopeammaksi.
Monisäikeisessä koodissa tiettyjä nopeusetuja voi olla, mutta hintana on moninkertainen RAM -muistin kulutus.
Itse en todellakaan halua mitään pakko-immutablea ohjelmiini. Saavutettu nopeusetu 1-säikeisessä koodissa on NOLLA, ja monisäikeisessä ohjelmassa vähäinen. Sensijaan RAM -muistin kulutus kasvaa aivan älyttömästi tuolla Immutable -systeemillä.
"Ram muistin kulutuksesta ei sovelluksen koodissa tarvitse oikein välittää"
Päinvastoin!
Web -selain on malliesimerkki ohjelmasta, jossa Ram muistin kulutuksella on erittäin tärkeä merkitys, mutta hölmöt kehittäjät eivät tätä halua tajuta.
Itselläni kaatuu web -selain useita kertoja joka ikinen päivä, syynä web -selainten täyspaska muistinhallinta.
Delphissä tyyppi String (ja AnsiString ja uudemmissa myös UnicodeString) toimii näin:
JOS viittausten määrä = 1, merkkijonoa voi suoraan muuttaa.
MUTTA jos viittausten määrä >= 2, merkkijono itsessään on jo valmiiksi immutable.
Jos tällöin muutat yhtä merkkijonomuuttujaa, niin ko. muuttujalle allokoidaan uusi sisältö ja alkuperäisen reference countia pienennetään yhdellä.
Tuo käytäntö itseasiassa tarjoaa kaikki immutablen hyödyt ilman immutablen haittoja!
immutablen ainoa hyöty kun tulee siitä, että monisäikeisessä ohjelmassa kunkin säikeen koodin täytyy ottaa huomioon mahdollisuus, että toinen säie muokkaa sisältöä, paitsi immutable, jolloin jo etukäteen tiedetään, ettei sisältö voi muuttua.
Ainoa tilanne, jossa muutoskelpoisuus aiheuttaa hitautta, on se, jossa 2 tai useampi säiettä toistuvasti muuttaa saman muuttujan sisältöä. Tämä tosiaan aiheuttaa hitautta, mutta oikein suunnitellussa ohjelmassa harvinainen tilanne.
Muita hitauden lähteitä:
Delphissä oletusmuistimanageri on sellainen, että aina, kun mikä tahansa osa ohjelmasta kutsuu GetMem, FreeMem tai ReallocMem, niin muistimanageri monisäikeisissä ohjelmissa lukitsee tilansa, tekee tarvittavat muutokset, ja lopuksi vapauttaa lukituksen.
Jos säie kutsuu mitä tahansa em. muistinkäsittelyfunktiota tilanteessa, jossa ko lukko on jo ennestään lukittu, silloin ko. säie lukittuu, kunnes alkuperäinen säie vapauttaa lukon, jonka jälkeen toinen säie pääsee hoitamaan asiansa (ja itse lukitsemaa ko. lukon).
Ainoa keino estää tuo hitauden lähde olisi sellainen muistimanageri, jossa suurin osa muistioperaatioista on säikeen sisäisiä, eikä siten vaikuta muihin säikeisiin.
Tämä kuitenkin vaatisi, että jokaista säiettä kohti on oma muistipoolinsa, eli lisäisi RAM -muistin kulutusta.
Nykyohjelmissa RAM -muistin kulutus on kriittinen resurssi, mutta CPU -aika 99%:ssa ohjelmista EI OLE kriittinen resurssi.
Ehkä 1% ohjelmista on sellaisia, joissa nopeammasta prosessorista olisi jotain hyötyä.
Loput ohjelmista ovat sellaisia, joissa hyöty nopeammasta prosessorista olisi joko nolla tai ainakin mitättömän pieni.
Omassa koneessani on 16 Gigatavua RAM -muistia.
Kaikille muille ohjelmille paitsi web -selaimelle tuo muistin määrä on riittävä.
Sensijaan Web -selamen osalta tuo 16 Gt ei riitä mihinkään, vaan muisti loppuu jatkuvasti kesken.
Web -selain on nykyohjelmista pahin muistisyöppö!
Muissa ohjelmissa muistin riittävyys ei ole koskaan ollut ongelma.
Ja hitaus ei Delphi -ohjelmia häiritse yleensä koskaan.
Tosin:
Tietyissä erityistehtävissä voi törmätä hitauteen!
Esimerkki:
Jos on tiedosto, jossa on useita satojatuhansia tietueita, ja haluat järjestää nuo tietueet tiettyyn järjestykseen, tällöin esim. yksi ainoa TStringList ja StringList.Sort on hidas ratkaisu.
Sensijaan, jos kyse on tekstimuotoisesta tiedosta, niin 1 StringList per jokainen mahdollinen alkukirjain, ja aineiston jako alkukirjaimen mukaan eri StringListoihin on huomattavasti nopeampi ratkaisu.
Esimerkkitapauksessa edes 15 minuuttia ei riitä yhden ainoan valtavan stringlistin lajitteluun.
Sitävastoin, kun aineisto jaettiin 1 stringlist per alkukirjain, niin muutama sekunti, ja lajittelu oli valmis.
Oikein järkeilty ohjemointityö on paljon tehokkaampi tapa nopeuttaa ohjelmaa kuin mikään tekninen ratkaisu. - Anonyymi
Anonyymi kirjoitti:
"immutable -systeemi aiheuttaa ongelmia muistinhallinnalle, lisää ohjelman RAM -muistin kulutusta"
Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään.
Ihan ihmeellistä pätemisen tarvetta puhua täyttä paskaa."Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään."
YKSITTÄISEN vakion käyttö ei tietenkään lisää muistin tarvetta.
Mutta immutable -käytäntö STRING -tyypin toteutuksessa lisäisi RAM -muistin tarpeen moninkertaiseksi.
Selittääköhän tämä muuten web- selainten aivan järkyttävän muistintuhlaamisen ?
Onko nyky -webselaimet toteutettu jollain sellaisella ohjelmointikielellä, jossa nimenomaan jokainen merkkijono on immutable ?
JOS näin on, nyt löytyi selitys web- selainten aivan järkyttävän muistinkulutukseen!
immutable -merkkijonot (siis tarkoittaa sitä, että ohjelmointikielen merkkijonototeutus pakottaa siihen, että JOKAINEN merkkijono on immutable), tämä on ohjelmistomaailman syöpä, joka moninkertaistaa RAM -muistin kulutuksen.
Jotkut tahot ovat ikävä kyllä Delphiinkin tällaista harkinneet.
JOS jokin Delphin uusi versio uudelleentoteuttaa merkkijonot aina immutableina, niin tuollaisella uudelle Delphi -versiolla käännettynä sama lähdekoodi käännettynä:
muistinkulutus verrattuna vanhalla Delphi -versiolla käännettyyn on silloin moninkertainen!
Esimerkki:
var
S : String;
begin
S := 'abc' ;
S := 'def'; // JOS string -tyyppi on immutable, niin tämä aiheuttaa sen, että varataan uusi muistialue merkkijonolle 'def'. Samalla merkkijonon 'abc' muistialue joko vapautetaan heti (hyvä) tai kuten Javassa, merkitään myöhemmin vapautettavaksi (erittäin huono).
end;
Miksikö Javan käytäntö on erittäin huono ?
SIKSI, että tällöin RAM -muisti jossain vaiheessa loppuu. Ja KUN se loppuu, käynnistyy muistinsiivousajo, joka voi kestää pitkään, ja jonka aikana muu osa Java -ohjelmasta ei tee eikä voi tehdä mitään, koska sen suoritus on "jäädytettynä" muistinsiivousajon loppuun saakka. - Anonyymi
Anonyymi kirjoitti:
"Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään."
YKSITTÄISEN vakion käyttö ei tietenkään lisää muistin tarvetta.
Mutta immutable -käytäntö STRING -tyypin toteutuksessa lisäisi RAM -muistin tarpeen moninkertaiseksi.
Selittääköhän tämä muuten web- selainten aivan järkyttävän muistintuhlaamisen ?
Onko nyky -webselaimet toteutettu jollain sellaisella ohjelmointikielellä, jossa nimenomaan jokainen merkkijono on immutable ?
JOS näin on, nyt löytyi selitys web- selainten aivan järkyttävän muistinkulutukseen!
immutable -merkkijonot (siis tarkoittaa sitä, että ohjelmointikielen merkkijonototeutus pakottaa siihen, että JOKAINEN merkkijono on immutable), tämä on ohjelmistomaailman syöpä, joka moninkertaistaa RAM -muistin kulutuksen.
Jotkut tahot ovat ikävä kyllä Delphiinkin tällaista harkinneet.
JOS jokin Delphin uusi versio uudelleentoteuttaa merkkijonot aina immutableina, niin tuollaisella uudelle Delphi -versiolla käännettynä sama lähdekoodi käännettynä:
muistinkulutus verrattuna vanhalla Delphi -versiolla käännettyyn on silloin moninkertainen!
Esimerkki:
var
S : String;
begin
S := 'abc' ;
S := 'def'; // JOS string -tyyppi on immutable, niin tämä aiheuttaa sen, että varataan uusi muistialue merkkijonolle 'def'. Samalla merkkijonon 'abc' muistialue joko vapautetaan heti (hyvä) tai kuten Javassa, merkitään myöhemmin vapautettavaksi (erittäin huono).
end;
Miksikö Javan käytäntö on erittäin huono ?
SIKSI, että tällöin RAM -muisti jossain vaiheessa loppuu. Ja KUN se loppuu, käynnistyy muistinsiivousajo, joka voi kestää pitkään, ja jonka aikana muu osa Java -ohjelmasta ei tee eikä voi tehdä mitään, koska sen suoritus on "jäädytettynä" muistinsiivousajon loppuun saakka."Selittääköhän tämä muuten web- selainten aivan järkyttävän muistintuhlaamisen ?
Onko nyky -webselaimet toteutettu jollain sellaisella ohjelmointikielellä, jossa nimenomaan jokainen merkkijono on immutable ?"
Selaimet kuluttavat paljon muistia siksi kun:
1. Ne osaavat paljon enemmän kuin 25 vuotta sitten.
2. Käsiteltävän datan määrä on kasvanut hurjasti
3. Välimuistien koko kasvanut. Varaavat itseasiassa helposti muistia sen mukaan miten paljon muistia löytyy.
"Esimerkki:"
Ei toimi noin. Kääntäjä älähtää jos yrittää merkkijonoa muutella mikä ei saa muuttua.
"muistialue joko vapautetaan heti (hyvä) tai kuten Javassa, merkitään myöhemmin vapautettavaksi (erittäin huono)."
Muistialueen vapauttaminen myöhemmin ei ole mitenkään huono asia, se nimittäin helposti lisää suorituskykyä.
"SIKSI, että tällöin RAM -muisti jossain vaiheessa loppuu. Ja KUN se loppuu, käynnistyy muistinsiivousajo, joka voi kestää pitkään, ja jonka aikana muu osa Java -ohjelmasta ei tee eikä voi tehdä mitään, koska sen suoritus on "jäädytettynä" muistinsiivousajon loppuun saakka."
Muistinsiivous toimii omassa säikeessä taustalla, ja muistinsiivoukselle on useita triggereitä. Ei tosiaankaan tarvitse odottaa muistin loppumista. Muistinsiivousta tehdään myös incrementaaliseti ilman, että mitään jäädyttämistä tapahtuisi. - Anonyymi
Anonyymi kirjoitti:
"immutable -systeemi aiheuttaa ongelmia muistinhallinnalle, lisää ohjelman RAM -muistin kulutusta"
Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään.
Ihan ihmeellistä pätemisen tarvetta puhua täyttä paskaa."Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään."
Itse et ymmärrä asiaa lainkaan !
Jos on normaali (muuttamiskelpoinen) string, niin sen arvoa voi suoraan muuttaa , eikä muuttaminen siksi lisää muistin käyttöä yhtään.
MUTTA:
JOS jokainen string on immutable (= muuttamiskelvoton), niin joka kerran, kun merkkijonon arvoa muutetaan, joudutaan luomaan uusi kopio itse merkkijonosta, se alkuperäinen kun on immutable, sitä ei voi muuttaa, mutta merkkijonomuuttujan arvoa voi silti muuttaa, mutta se muuttaminen tehdään niin, että luodaan uusi merkkijonosisältö (vanhaan ei kosketa kun se kerran on immutable) ja laitetaan se merkkijonomuuttuja viittaamaan tuohon uuteen kopioon (muutetun) merkkijonon arvosta.
Eli joka kerta, kun merkkijonomuuttujan arvoa muutetaan, kuluu muistia hukkaan, sillä merkkijonomuuttujan vanhan arvon sisältäneet muistipaikat ovat nyt ns. roskasisältöä - jota ei tarvita mihinkään - mutta joka silti kuluttaa muistia ohjelmansuorituksen loppuun saakka.
Tuo immutable on kammottava idea, ja vaikka joissain tapauksissa monisäikeinen ohjelma saattaa saada siitä hetkellisesti nopeushyötyä, mutta kun katsotaan kokonaisuutta, tuosta immutable -periaatteesta on pelkkää haittaa.
Vakiot on sitten niitä tilanteita varten, kun jokin arvo lyödään lukkoon jo ohjelmaa kirjoitettaessa, jolloin jotain vakiota ei todellakaan muuteta.
Mutta immutable -muuttujat: kammottavaa !
Jostain käsittämättömästä näitä "ohjelmoinnin muotiguruja" jotkut kuuntelevat - surullisin seurauksin: heikkolaatuisia ohjelmistoja ja lisäkustannuksia - usein myös tietoturvallisuuteen liittyviä ongelmia.
Ohjelmistoalallakin toimii ns. "keisarilla ei ole vaatteita" -ilmiö. - Anonyymi
Anonyymi kirjoitti:
"Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään."
Itse et ymmärrä asiaa lainkaan !
Jos on normaali (muuttamiskelpoinen) string, niin sen arvoa voi suoraan muuttaa , eikä muuttaminen siksi lisää muistin käyttöä yhtään.
MUTTA:
JOS jokainen string on immutable (= muuttamiskelvoton), niin joka kerran, kun merkkijonon arvoa muutetaan, joudutaan luomaan uusi kopio itse merkkijonosta, se alkuperäinen kun on immutable, sitä ei voi muuttaa, mutta merkkijonomuuttujan arvoa voi silti muuttaa, mutta se muuttaminen tehdään niin, että luodaan uusi merkkijonosisältö (vanhaan ei kosketa kun se kerran on immutable) ja laitetaan se merkkijonomuuttuja viittaamaan tuohon uuteen kopioon (muutetun) merkkijonon arvosta.
Eli joka kerta, kun merkkijonomuuttujan arvoa muutetaan, kuluu muistia hukkaan, sillä merkkijonomuuttujan vanhan arvon sisältäneet muistipaikat ovat nyt ns. roskasisältöä - jota ei tarvita mihinkään - mutta joka silti kuluttaa muistia ohjelmansuorituksen loppuun saakka.
Tuo immutable on kammottava idea, ja vaikka joissain tapauksissa monisäikeinen ohjelma saattaa saada siitä hetkellisesti nopeushyötyä, mutta kun katsotaan kokonaisuutta, tuosta immutable -periaatteesta on pelkkää haittaa.
Vakiot on sitten niitä tilanteita varten, kun jokin arvo lyödään lukkoon jo ohjelmaa kirjoitettaessa, jolloin jotain vakiota ei todellakaan muuteta.
Mutta immutable -muuttujat: kammottavaa !
Jostain käsittämättömästä näitä "ohjelmoinnin muotiguruja" jotkut kuuntelevat - surullisin seurauksin: heikkolaatuisia ohjelmistoja ja lisäkustannuksia - usein myös tietoturvallisuuteen liittyviä ongelmia.
Ohjelmistoalallakin toimii ns. "keisarilla ei ole vaatteita" -ilmiö.10 miljardia salasanaa jaossa - kaikkien aikojen suurin salasanavuoto
---------------------------------------------------------------------------------------- - Anonyymi
Anonyymi kirjoitti:
"Mitä hittoa sinä sössötät. Millä tavalla vakion käyttö lisää muistin käyttöä, ei mitenkään."
Itse et ymmärrä asiaa lainkaan !
Jos on normaali (muuttamiskelpoinen) string, niin sen arvoa voi suoraan muuttaa , eikä muuttaminen siksi lisää muistin käyttöä yhtään.
MUTTA:
JOS jokainen string on immutable (= muuttamiskelvoton), niin joka kerran, kun merkkijonon arvoa muutetaan, joudutaan luomaan uusi kopio itse merkkijonosta, se alkuperäinen kun on immutable, sitä ei voi muuttaa, mutta merkkijonomuuttujan arvoa voi silti muuttaa, mutta se muuttaminen tehdään niin, että luodaan uusi merkkijonosisältö (vanhaan ei kosketa kun se kerran on immutable) ja laitetaan se merkkijonomuuttuja viittaamaan tuohon uuteen kopioon (muutetun) merkkijonon arvosta.
Eli joka kerta, kun merkkijonomuuttujan arvoa muutetaan, kuluu muistia hukkaan, sillä merkkijonomuuttujan vanhan arvon sisältäneet muistipaikat ovat nyt ns. roskasisältöä - jota ei tarvita mihinkään - mutta joka silti kuluttaa muistia ohjelmansuorituksen loppuun saakka.
Tuo immutable on kammottava idea, ja vaikka joissain tapauksissa monisäikeinen ohjelma saattaa saada siitä hetkellisesti nopeushyötyä, mutta kun katsotaan kokonaisuutta, tuosta immutable -periaatteesta on pelkkää haittaa.
Vakiot on sitten niitä tilanteita varten, kun jokin arvo lyödään lukkoon jo ohjelmaa kirjoitettaessa, jolloin jotain vakiota ei todellakaan muuteta.
Mutta immutable -muuttujat: kammottavaa !
Jostain käsittämättömästä näitä "ohjelmoinnin muotiguruja" jotkut kuuntelevat - surullisin seurauksin: heikkolaatuisia ohjelmistoja ja lisäkustannuksia - usein myös tietoturvallisuuteen liittyviä ongelmia.
Ohjelmistoalallakin toimii ns. "keisarilla ei ole vaatteita" -ilmiö."Jos on normaali (muuttamiskelpoinen) string, niin sen arvoa voi suoraan muuttaa , eikä muuttaminen siksi lisää muistin käyttöä yhtään."
Ahaa, jos on string "Hello world" ja sen muuttaa stringiksi "Terve maailma!" niin oletko varma että stringi pysyy muistissa samankokoisena?
"Eli joka kerta, kun merkkijonomuuttujan arvoa muutetaan, kuluu muistia hukkaan, sillä merkkijonomuuttujan vanhan arvon sisältäneet muistipaikat ovat nyt ns. roskasisältöä - jota ei tarvita mihinkään - mutta joka silti kuluttaa muistia ohjelmansuorituksen loppuun saakka."
Höpöhöpö.
Miksi kuvittelet että niitä muuttujia pitäisi säilöä muistissa ohjelmasuorituksen loppuun saakka? Normaalisti muuttujat poistuvat muistista kun poistutaan scopesta.
Ketjusta on poistettu 4 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/viihde192460- 1482214
Ymmä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än292132Hullu liikenteessä?
Mikä hullu pyörii kylillä jos jahti päällä? Näitä tosin kyllä riittää tällä kylällä.522109Niina 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-lahti201674Kun 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ää? Esimerkiks3871583Ano Turtiainen saa syytteet kansankiihoituksesta
Syytteitä on kolme ja niissä on kyse kirjoituksista, jotka hän on kansanedustaja-aikanaan julkaissut Twitter-tilillään961506- 2771388
Varokaa! Lunta voi sataa kohta!
Vakava säävaroitus Lumisadevaroitus Satakunta, Uusimaa, Etelä-Karjala, Keski-Suomi, Etelä-Savo, Etelä-Pohjanmaa, Pohjanm131369- 1301346