Nyt mielenkiintoinen tarjous.

Windows lagaa aina!

Kollivapunen asialla!

🤮 Se haju! Ääääh..

W11... Tarkkana. Ohhoh, huh huh,, 🚽
💩💩💩💩💩💩💩

Asiahan on niin!
Windows on ihan sysipaska kurttaus

"ICT-juttuja ja juurikin liittyy paljonkin omaan hommaani eli hardware device driver -ohjelmointi, assembly, DirectX, OpenGL, 3D-ohjelmointi ym.."

Hardware device driver, näitä hommia on tuoteyrityksissä jotka tekevät jotain laitteita. Näissä varsin yleisesti on Linux ja sinne sitten voi tehdä low level koodia että laitetaan se kommunikoimaan raudan kanssa.

DirectX ja OpenGL ohjelmointia on melko vähän, korkean tason 3D ohjelmointia tehdään paljon, yhden hengen firmoissakin. Näissä tietenkin hyödynnetään olemassa olevia työkaluja että mitään 3D-moottoreita ei tehdä.

"MUTTA niin, ettei pakoteta C/C++ (tai minkään muunkaan kielen) käyttöön, vaan ohjelmointikielen saa itse valita niistä kielistä, mitkä teknisesti soveltuvat ko .käyttöön."

Ihan normaalia, ohjelmoivan asiantuntijakonsultin työtä. Minä valitsen joka projektissa välineet ja minulta nimenomaan kysytään sitä, että millä kannattaisi tehdä.

"Tarkoittaa siis sitä, että esim. JAVAn voi valita heti, kun joku tarjoaa JAVA -kääntäjää, joka ei enää käännä JAVA -tavukoodiksi, vaan kyseisen CPU:n aidolle konekielelle."

Näitä on ollut vuosikymmeniä mutta tähän mennessä Java on nimenomaan haluttu kääntää tavukoodiksi että saa paremman suorituskyvyn. Tämä muuttui vasta kun serverless containerien myötä kun containerin boottiajalla oli niin paljon merkitystä. Itse käytän Javan kääntämiseen tätä: https://www.graalvm.org/

Tavukoodiversio voi kyllä joissakin tilanteissa paremmin kun se JIT kääntäjä optimoi sille missä sitä ajetaan ja voi myös ajonaikana optimoida toimintaa mutta tuo käynnistymisaika on siinä huono ja se haittaa kun palveluja nostetaan ylös kuorman mukaan.

"Itseasiassa gcj kai teoriassa on tuollainen kääntäjä, tosin ei ole tiedossani, täyttääkö se laatuvaatimukset, eli voisiko gcj:llä oikeasti kirjoittaa laiteohjaimia vai ei."

Ei Java ole sellaiseen tarkoitettu. Linux on C-kieltä ja vasta hiljattain siinä on alettu käyttämään myös Rust:ia. Niillä voi tehdä ne laiteohjaimet.

Toki joissakin laitteissa käytetään FreeBSD:tä ja OpenBSD:tä mutta niissä mennään C-kielellä sitten.

"Freepascal sensijaan ON aito kääntäjä, joka kääntää ObjectPascalia konekieleksi, ja se on saatavissa hyvin monelle eri CPU -arkkitehtuurille kääntäväksi. "

Mutta sillä ei tehdä laiteajureita. Jos nyt on tehnyt jonkun hardwaaren ja haluaisi sen ajurikoodin mukaan kerneliin että olisi helpompi ylläpitää niin ei sinne mitään Pascalia haluta sotkemaan. Halutaan se koodi pitää siistinä ja yhdenmukaisena.

"Miksi yrityksille ei kelpaa Laiteohjaimiin FreePascal ja melkein kaikkee muuhun Delphi?"

1. Laitetason koodissa C-kieli on lähes defacto. Ja jos tehdään ajurikoodia niin se mieluusti halutaan ylläpitosyistä liittää sinne Linuxiin tms. mutta ei sellainen mene läpi kun haluavat pitää koodipuun yhtenäisenä.

2. Delphi on älyttömän kallis ja sisältää vanhaa kurakoodia.

3. Backend kehittäjillä useinkin on jotain linuxeja ja frontend kehittäjillä useinkin Mac OS. Delphi ei siis ole yhteensopiva kehittäjien tietokoneiden kanssa.

4. Delphi on älyttömän vaikea integroida CI/CD prosesseihin ja samasta syystä. Jenkins serverit ihan normisti linuxeilla.

5. Ohjelmointikielen tarkoitus on olla yhteinen kieli ihmisten ja tietokoneen välillä. Tästä syystä ohjelmointikieleksi valitaan se mitä muutkin käyttävät. Samasta syystä ohjelmissa kommentit ovat englanniksi kun englannin kieli on lingua franca ohjelmistokehityksessä ja kaikki kehittäjät puhuvat sitä.

Pascalin ehdottaminen on samaa kuin vaihtaisi ohjelman dokumentaation arabiaksi. Ei mitään järkeä jos yksi porukasta puhuu arabiaa ja muut englantia. Eri tyyppisissä hommissa on eri kieliä käytössä mitä muutkin käyttää. Laiteajurihommissa se on C-kieli.

Käyttöliittymähommissa Typescript/Javascript on ne millä yleensä mennään, paitsi sitten jos käännetään jotain erikoisempaa kuten hyödynnetään pelimoottoria niin sitten on muitakin kuten C#. CAD-kerneleissä ja monille servereille jaetussa laskennassa C++ on se kieli mitä käytetään. Verkkokauppa ja CMS hommissa PHP on erittäin käytetty. Backend puolella yleisesti on sitten monia kieliä käytössä kuten Java, Typescript, Go, C# ja Python. Kirjoitettaessa domain spefic kieliä tai kun yleisesti on eristetty koko homma muista saattaa olla käytössä vaikka Haskell. Funktionaaliseen ohjelmointiin yleisellä tasolla on niinikään monia kieliä. Näissä olennainen juttu on yleensä korkeampi varmuus virheettömyydelle.

Kieli valitaan siis tilanteen mukaan ja se yleensä se mitä muut käyttävät eikä jotain arabiaa.

"Miksi kehtaatte valittaa "osaajapulaa" kun oikeasti pula näyttää olevan orjista, jotka suostuvat huonoihin työvälinevalintoihin ?"

Kyllä tämä nyt näyttäisi olevan vika sinussa, että yrität ehdottaa sellaista työkalua mikä soveltuu tehtävään hommaan huonosti. Voit toki perustaa yrityksen ja tarjota palveluna jos uskot että joku haluaa jotain Delphikuraa yhtään mihinkään.

Anonyymi00013 kirjoitti:

"ICT-juttuja ja juurikin liittyy paljonkin omaan hommaani eli hardware device driver -ohjelmointi, assembly, DirectX, OpenGL, 3D-ohjelmointi ym.."

Hardware device driver, näitä hommia on tuoteyrityksissä jotka tekevät jotain laitteita. Näissä varsin yleisesti on Linux ja sinne sitten voi tehdä low level koodia että laitetaan se kommunikoimaan raudan kanssa.

DirectX ja OpenGL ohjelmointia on melko vähän, korkean tason 3D ohjelmointia tehdään paljon, yhden hengen firmoissakin. Näissä tietenkin hyödynnetään olemassa olevia työkaluja että mitään 3D-moottoreita ei tehdä.

"MUTTA niin, ettei pakoteta C/C++ (tai minkään muunkaan kielen) käyttöön, vaan ohjelmointikielen saa itse valita niistä kielistä, mitkä teknisesti soveltuvat ko .käyttöön."

Ihan normaalia, ohjelmoivan asiantuntijakonsultin työtä. Minä valitsen joka projektissa välineet ja minulta nimenomaan kysytään sitä, että millä kannattaisi tehdä.

"Tarkoittaa siis sitä, että esim. JAVAn voi valita heti, kun joku tarjoaa JAVA -kääntäjää, joka ei enää käännä JAVA -tavukoodiksi, vaan kyseisen CPU:n aidolle konekielelle."

Näitä on ollut vuosikymmeniä mutta tähän mennessä Java on nimenomaan haluttu kääntää tavukoodiksi että saa paremman suorituskyvyn. Tämä muuttui vasta kun serverless containerien myötä kun containerin boottiajalla oli niin paljon merkitystä. Itse käytän Javan kääntämiseen tätä: https://www.graalvm.org/

Tavukoodiversio voi kyllä joissakin tilanteissa paremmin kun se JIT kääntäjä optimoi sille missä sitä ajetaan ja voi myös ajonaikana optimoida toimintaa mutta tuo käynnistymisaika on siinä huono ja se haittaa kun palveluja nostetaan ylös kuorman mukaan.

"Itseasiassa gcj kai teoriassa on tuollainen kääntäjä, tosin ei ole tiedossani, täyttääkö se laatuvaatimukset, eli voisiko gcj:llä oikeasti kirjoittaa laiteohjaimia vai ei."

Ei Java ole sellaiseen tarkoitettu. Linux on C-kieltä ja vasta hiljattain siinä on alettu käyttämään myös Rust:ia. Niillä voi tehdä ne laiteohjaimet.

Toki joissakin laitteissa käytetään FreeBSD:tä ja OpenBSD:tä mutta niissä mennään C-kielellä sitten.

"Freepascal sensijaan ON aito kääntäjä, joka kääntää ObjectPascalia konekieleksi, ja se on saatavissa hyvin monelle eri CPU -arkkitehtuurille kääntäväksi. "

Mutta sillä ei tehdä laiteajureita. Jos nyt on tehnyt jonkun hardwaaren ja haluaisi sen ajurikoodin mukaan kerneliin että olisi helpompi ylläpitää niin ei sinne mitään Pascalia haluta sotkemaan. Halutaan se koodi pitää siistinä ja yhdenmukaisena.

"Miksi yrityksille ei kelpaa Laiteohjaimiin FreePascal ja melkein kaikkee muuhun Delphi?"

1. Laitetason koodissa C-kieli on lähes defacto. Ja jos tehdään ajurikoodia niin se mieluusti halutaan ylläpitosyistä liittää sinne Linuxiin tms. mutta ei sellainen mene läpi kun haluavat pitää koodipuun yhtenäisenä.

2. Delphi on älyttömän kallis ja sisältää vanhaa kurakoodia.

3. Backend kehittäjillä useinkin on jotain linuxeja ja frontend kehittäjillä useinkin Mac OS. Delphi ei siis ole yhteensopiva kehittäjien tietokoneiden kanssa.

4. Delphi on älyttömän vaikea integroida CI/CD prosesseihin ja samasta syystä. Jenkins serverit ihan normisti linuxeilla.

5. Ohjelmointikielen tarkoitus on olla yhteinen kieli ihmisten ja tietokoneen välillä. Tästä syystä ohjelmointikieleksi valitaan se mitä muutkin käyttävät. Samasta syystä ohjelmissa kommentit ovat englanniksi kun englannin kieli on lingua franca ohjelmistokehityksessä ja kaikki kehittäjät puhuvat sitä.

Pascalin ehdottaminen on samaa kuin vaihtaisi ohjelman dokumentaation arabiaksi. Ei mitään järkeä jos yksi porukasta puhuu arabiaa ja muut englantia. Eri tyyppisissä hommissa on eri kieliä käytössä mitä muutkin käyttää. Laiteajurihommissa se on C-kieli.

Käyttöliittymähommissa Typescript/Javascript on ne millä yleensä mennään, paitsi sitten jos käännetään jotain erikoisempaa kuten hyödynnetään pelimoottoria niin sitten on muitakin kuten C#. CAD-kerneleissä ja monille servereille jaetussa laskennassa C++ on se kieli mitä käytetään. Verkkokauppa ja CMS hommissa PHP on erittäin käytetty. Backend puolella yleisesti on sitten monia kieliä käytössä kuten Java, Typescript, Go, C# ja Python. Kirjoitettaessa domain spefic kieliä tai kun yleisesti on eristetty koko homma muista saattaa olla käytössä vaikka Haskell. Funktionaaliseen ohjelmointiin yleisellä tasolla on niinikään monia kieliä. Näissä olennainen juttu on yleensä korkeampi varmuus virheettömyydelle.

Kieli valitaan siis tilanteen mukaan ja se yleensä se mitä muut käyttävät eikä jotain arabiaa.

"Miksi kehtaatte valittaa "osaajapulaa" kun oikeasti pula näyttää olevan orjista, jotka suostuvat huonoihin työvälinevalintoihin ?"

Kyllä tämä nyt näyttäisi olevan vika sinussa, että yrität ehdottaa sellaista työkalua mikä soveltuu tehtävään hommaan huonosti. Voit toki perustaa yrityksen ja tarjota palveluna jos uskot että joku haluaa jotain Delphikuraa yhtään mihinkään.

Niin ja sitten tietenkin se koneoppiminen... Niin siellä sitten vakiokieli on Python.

Tässä nyt ei pitäisi olla mitään epäselvää että kieli valitaan sen mukaan mitä halutaan tehdä mutta sinä et nähtävästi osaa valita sopivaa työkalua joten kaikki toteavat että et ole hyvä ohjelmoija.

Delphissä VOI tehdä näin (jos välttämättä haluaa):

function XYZ(L:Longword ):Longword;
asm
db $90, $90, $90, $90, $90, $90, $90
end;

Yritäpä tehdä gcc:lle kelpaavaksi C:llä sama - taatusti törmäät ongelmiin !

ei taida onnistua ihan näin:

__asm {
db $90, $90, $90, $90, $90, $90, $90
}