Asenna kehitystyökalut kerralla

Tuossa meinas unohtua nämä Windows käyttäjät, myös heille on satoja ilmaisia EBOOKeja. Tähän linkkiin kannattaa tutustua, jokaiselle jotakin, ja eikä maksa mitään.


https://blogs.msdn.microsoft.com/mssmallbiz/2016/07/10/free-thats-right-im-giving-away-millions-of-free-microsoft-ebooks-again-including-windows-10-office-365-office-2016-power-bi-azure-windows-8-1-office-2013-sharepoint-2016-sha/


Linux Mint 18.1 Serena
Xfce 64-bit

PS: Hyvien vinkkien peukuttaminen ei ole kiellettyä.

Sehän vähän riippuu mitä tekee.

Nyt oli selvästikin kyse C ja C ohjelmoinnista ja Visual Studio Community on siihen aika huono.

En asenna Windows ohjelmia vaikka vähän maksettaisiinkin.

Linux Mint 18.1 Serena
Xfce 64-bit

M-Kar kirjoitti:

Sehän vähän riippuu mitä tekee.

Nyt oli selvästikin kyse C ja C ohjelmoinnista ja Visual Studio Community on siihen aika huono.

C ja C ohjelmointi ylipäätään on aika huonoa.

fsafdsfdsafsa kirjoitti:

C ja C ohjelmointi ylipäätään on aika huonoa.

Riippuu mitä tekee.

M-Kar kirjoitti:

Riippuu mitä tekee.

Sellainen ihminen joka tarvii opastuksen käännöstyökalujen asennukseen ei tee mitään sellaista missä c/c olisi järkevää.

En-sitten-ikinä-asenna kirjoitti:

En asenna Windows ohjelmia vaikka vähän maksettaisiinkin.

Linux Mint 18.1 Serena
Xfce 64-bit

Visual Studio ei ole "windows-ohjelma".

sdfasdasdasdas kirjoitti:

Visual Studio ei ole "windows-ohjelma".

Kyllä kaveri puhu "Tai vielä helpommin: lataa ja asenna Visual Studio Community" joka on windows ohjelma, mutta IDE Visual Studio Code on saatavissa lähes kaikille alustoille, jopa minäkin sitä kokeilin, ei miellyttänyt ja poistin.

Linux Mint 18.1 Serena
Xfce 64-bit

Eikä ole, Visual Studion saa myös Macille ja oletettavasti siitä on Linux-versiokin tekeillä.

M-Kar kirjoitti:

Riippuu mitä tekee.

'''''''Riippuu mitä tekee.''''''''
Mitähän sinä luulisit C ja C tehtävän. Tuossa ei järki päätä pakota, kun kirjotellaan.
Pistä nyt hitossa pientä rajaa tuolle mutuilulle.

fyukitklyut kirjoitti:

'''''''Riippuu mitä tekee.''''''''
Mitähän sinä luulisit C ja C tehtävän. Tuossa ei järki päätä pakota, kun kirjotellaan.
Pistä nyt hitossa pientä rajaa tuolle mutuilulle.

Lue lisää

C on työkalu systeemiohjelmointiin. Sillä tehdään matalan tason palikat järjestelmään.

C :lla sitten on vähän erilaisia tarkoituksia. Käytetään middlewaressa, raskaassa numeronmurskauksessa OpenMP:n kanssa, CAD kernelit ja jne.

Eli eri työkaluja ja käytetään eri asioihin.

Visual Studio Community on vähän huono näihin kun se toimii Windowsissa. Windowspalvelimia ei käytetä laskentaklustereissa. Windows on suljettu järjestelmä eikä Windowsiin tehdä itse uusia kirjastoja tai muokata kerneliä. Koska Windows on yleisesti ottaen väärä ympäristö lähes aina C :n sekä C:n käytössä niin myös Visual Studio Community on väärä valinta tähän.

Eli kyllä nyt ihan ensiksi pitäisi tietää mitä halutaan saada aikaiseksi, sitten valitaan työkalut sen mukaan.

M-Kar kirjoitti:

C on työkalu systeemiohjelmointiin. Sillä tehdään matalan tason palikat järjestelmään.

C :lla sitten on vähän erilaisia tarkoituksia. Käytetään middlewaressa, raskaassa numeronmurskauksessa OpenMP:n kanssa, CAD kernelit ja jne.

Eli eri työkaluja ja käytetään eri asioihin.

Visual Studio Community on vähän huono näihin kun se toimii Windowsissa. Windowspalvelimia ei käytetä laskentaklustereissa. Windows on suljettu järjestelmä eikä Windowsiin tehdä itse uusia kirjastoja tai muokata kerneliä. Koska Windows on yleisesti ottaen väärä ympäristö lähes aina C :n sekä C:n käytössä niin myös Visual Studio Community on väärä valinta tähän.

Eli kyllä nyt ihan ensiksi pitäisi tietää mitä halutaan saada aikaiseksi, sitten valitaan työkalut sen mukaan.

Lue lisää

''''''''''Eli eri työkaluja ja käytetään eri asioihin.''''''''''''
Ihanko sinä itse tuon keksit. Sinä epäilit että kaveri ei tuota itse tiedä, niinkö.

dtujyttoy8ulpu90 kirjoitti:

''''''''''Eli eri työkaluja ja käytetään eri asioihin.''''''''''''
Ihanko sinä itse tuon keksit. Sinä epäilit että kaveri ei tuota itse tiedä, niinkö.

Tältähän se vahvasti vaikuttaa kun kerran sanoo, että C:llä ja C :lla ohjelmointi on "huonoa". Ei perustu mihinkään tuollainen naurettava väite.

M-Kar kirjoitti:

Tältähän se vahvasti vaikuttaa kun kerran sanoo, että C:llä ja C :lla ohjelmointi on "huonoa". Ei perustu mihinkään tuollainen naurettava väite.

Eli kaverilla voi olla vain sinun hyväksymä mielipide asiasta, tai muuten alat nälvimään kaverin ymmärrystä, eikä kaverin ajatus voi perustua mihinkään, ja on erittäin naurettava väite.

Mistä tiedät että vain sinun mielipide on se ainut oikea.

e56ur67iu7t68o6 kirjoitti:

Eli kaverilla voi olla vain sinun hyväksymä mielipide asiasta, tai muuten alat nälvimään kaverin ymmärrystä, eikä kaverin ajatus voi perustua mihinkään, ja on erittäin naurettava väite.

Mistä tiedät että vain sinun mielipide on se ainut oikea.

Lue lisää

Toistaiseksi vain minun mielipide perustuu johonkin. On perusteltu ja todistettavissa: http://keskustelu.suomi24.fi/t/14680392/asenna-kehitystyokalut-kerralla#comment-89735922

Ei ole esitetty minkäänlaisia perusteita "huonolle", mutta on todistettavissa että ei pidä paikkaansa. C kieli on defacto systeemiohjelmoinnissa. Kaikki tuotantokernelit ja matalan tason komponentit käyttöjärjestelmissä on tehty C:llä. Se on siis siihen juurikin ideaalinen ohjelmointikieli eikä "huono".

Havaintojen perusteella tähän ketjuun ei ole kukaan esittänyt muuta järjestellistä mielipidettä joka ei olisi todistettavissa virheelliseksi.

M-Kar kirjoitti:

Toistaiseksi vain minun mielipide perustuu johonkin. On perusteltu ja todistettavissa: http://keskustelu.suomi24.fi/t/14680392/asenna-kehitystyokalut-kerralla#comment-89735922

Ei ole esitetty minkäänlaisia perusteita "huonolle", mutta on todistettavissa että ei pidä paikkaansa. C kieli on defacto systeemiohjelmoinnissa. Kaikki tuotantokernelit ja matalan tason komponentit käyttöjärjestelmissä on tehty C:llä. Se on siis siihen juurikin ideaalinen ohjelmointikieli eikä "huono".

Havaintojen perusteella tähän ketjuun ei ole kukaan esittänyt muuta järjestellistä mielipidettä joka ei olisi todistettavissa virheelliseksi.

Lue lisää

Mitä nämä '''''''Kaikki tuotantokernelit''''' ovat ?
Mitä tämä '''''''defacto''''''' tarkoittaa ?

tttktu7ktu7gk7it kirjoitti:

Mitä nämä '''''''Kaikki tuotantokernelit''''' ovat ?
Mitä tämä '''''''defacto''''''' tarkoittaa ?

Tuotantokäytössä olevien käyttöjärjestelmien kernelit tietysti. C on käytössä joka paikassa.

Defacto tarkoittaa teollisuusstandardia. C on teollisuusstandardi tekniikka systeemiohjelmoinnissa.

https://en.wikipedia.org/wiki/De_facto

M-Kar kirjoitti:

Tuotantokäytössä olevien käyttöjärjestelmien kernelit tietysti. C on käytössä joka paikassa.

Defacto tarkoittaa teollisuusstandardia. C on teollisuusstandardi tekniikka systeemiohjelmoinnissa.

https://en.wikipedia.org/wiki/De_facto

Lue lisää

Noin siinä käy kun viljelee sivystyssanoja joiden merkitystä ei ymmärrä:

Defacto-standardeja
Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja.

"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C :lla

rffffftiii78 kirjoitti:

Noin siinä käy kun viljelee sivystyssanoja joiden merkitystä ei ymmärrä:

Defacto-standardeja
Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja.

"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C :lla

Lue lisää

https://www.kernel.org/
https://github.com/opensource-apple/xnu
http://cvsweb.netbsd.org/bsdweb.cgi/?only_with_tag=MAIN
https://cvsweb.openbsd.org/cgi-bin/cvsweb/
https://github.com/freebsd/freebsd
http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253

C näkyy olevan universaalisti.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."

Ei tarvitse edes olla kaupallisuutta mutta jos koko maailma käyttää tiettyä tekniikkaa jossain asiassa tai toimialalla niin se on defacto. Ja jos on defacto niin se on tällä hetkellä kyseissä hommassa soveltuvin.

Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.

C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.

M-Kar kirjoitti:

https://www.kernel.org/
https://github.com/opensource-apple/xnu
http://cvsweb.netbsd.org/bsdweb.cgi/?only_with_tag=MAIN
https://cvsweb.openbsd.org/cgi-bin/cvsweb/
https://github.com/freebsd/freebsd
http://community.qnx.com/sf/sfmain/do/downloadAttachment/projects.core_os/wiki/BuildKernelWithIDE?id=atch1253

C näkyy olevan universaalisti.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."

Ei tarvitse edes olla kaupallisuutta mutta jos koko maailma käyttää tiettyä tekniikkaa jossain asiassa tai toimialalla niin se on defacto. Ja jos on defacto niin se on tällä hetkellä kyseissä hommassa soveltuvin.

Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.

C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.

Lue lisää

"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C :lla
Et sitten antanut yhtään linkkiä tuotantoympäristöön.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."
Tuo oli antamasi linkin sivulta lainattu.

'''''''Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.''''''''
Perustele.

''''''''''C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.'''''''''
Mitkä työkalut ?
Suorituskyky, mihin verrattuna ?
''''''sertifiointia kriittisiin kohteisiin'''': Mistä löytää nää serifikaatit ?
'''''yksinkertaisuus''''': Mihin verrattuna ?

tr78io7t8o66 kirjoitti:

"Tuotantokäytössä olevien käyttöjärjestelmien kernelit"
Anna nyt muutama esimerkki että voin tarkistaa onko kirjoitettu C:llä tai C :lla
Et sitten antanut yhtään linkkiä tuotantoympäristöön.

"Tämän kaltaiset toteutustavat ovatkin levinneet ainoastaan kaupallisista syistä, eivätkä välttämättä ole teknisesti parhaita mahdollisia ratkaisuja."
Tuo oli antamasi linkin sivulta lainattu.

'''''''Esimerkiksi C:n korvaaminen jollain toisella systeemiohjelmoinnissa on jokseenkin varmasti askel taaksepäin.''''''''
Perustele.

''''''''''C:ssä kun on semmoisia juttuja kuin että soveltuu siihen, että ollaan lähellä rautaa. On pitkälle viedyt työkalut oikeellisuuden tarkistamiseen, suorituskyky, sertifiointia kriittisiin kohteisiin, standardoitu, yksinkertaisuus (saa vaatimattomassakin raudassa toimimaan) ja jne.'''''''''
Mitkä työkalut ?
Suorituskyky, mihin verrattuna ?
''''''sertifiointia kriittisiin kohteisiin'''': Mistä löytää nää serifikaatit ?
'''''yksinkertaisuus''''': Mihin verrattuna ?

Lue lisää

"Et sitten antanut yhtään linkkiä tuotantoympäristöön."

Kyseisiä kerneleitä on yleisesti tuotantoympäristöissä käytössä.

Tuotannossahan ne on tietysti käännettynä binäärimuotoon, että sorsistahan se tarkistetaan, tietysti.

"Perustele."

C on standardoitu
C mahdollistaa helposti vakaana pysyvän ABI:n
C on suorituskykyinen
C sopii laitteistonläheiseen ohjelmointiin
C:lle sopivia työkaluja ja systeemikoodia on sertifioitu
C sopii reaaliaikasovelluksiin

Ja sitten vielä se tärkeä juttu, nykyisin käytössä oleva unix arkkitehtuuri on tehty käsi kädessä C kielen kanssa, ja käyttöjärjestelmien ja tämän ohjelmointikielen "filosofia" vastaavat toisiaan. Toista kieltä käyttämällä tulee helposti kummallisuuksia, että ei ole niin unixmainen. Lopputulos on herkästi joku kummajainen.

"Mitkä työkalut ?"

Esimerkiksi työkaluja formaaliin verifiointiin. Vaikka tällainen: https://en.wikipedia.org/wiki/Frama-C

"Suorituskyky, mihin verrattuna ?"

Vaikka tulkattuihin kieliin. Tai kieliin jotka käyttävät garbage collectionia. Tai melkein mihin tahansa kun nuo C kielen kääntäjät ovat niin pitkään optimoituja.

"Mistä löytää nää serifikaatit ?"

Serfifioitujen tuotteiden valmistajat osaavat kertoa tarkemmin. Esim. QNX on IEC 62304 ja sitten lentokoneiden järjestelmissä on DO-178B sertifiointi. Se on itseasiassa vaatimus lentokoneiden tietokonejärjestelmille, että sellaisia päästetään ilmaan ja lentokoneisiin on tehty koodia C:llä.

DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

'''''yksinkertaisuus''''': Mihin verrattuna ?

Verrattuna vaikka Adaan, joka olisi semmoinen toinen suorituskykyinen kieli mikä sopii reaaliaikatarpeisiin ja löytyy sertifioituja työkaluja.

Että voit toki esittää niitä vaihtoehtoja C:lle mutta jokseenkin varmasti et keksi mitään mikä olisi joka asiassa parempi, ja viimeistään kun vaatimuksena on yhdenmukaisuus unix arkkitehtuurin kanssa tarkoittaisi sitä, että korvaaminen toisella tarkoittaisi helposti kaiken mahdollisen koodin tekemistä uusiksi jotta saa pidettyä yhtenäisenä.

M-Kar kirjoitti:

"Et sitten antanut yhtään linkkiä tuotantoympäristöön."

Kyseisiä kerneleitä on yleisesti tuotantoympäristöissä käytössä.

Tuotannossahan ne on tietysti käännettynä binäärimuotoon, että sorsistahan se tarkistetaan, tietysti.

"Perustele."

C on standardoitu
C mahdollistaa helposti vakaana pysyvän ABI:n
C on suorituskykyinen
C sopii laitteistonläheiseen ohjelmointiin
C:lle sopivia työkaluja ja systeemikoodia on sertifioitu
C sopii reaaliaikasovelluksiin

Ja sitten vielä se tärkeä juttu, nykyisin käytössä oleva unix arkkitehtuuri on tehty käsi kädessä C kielen kanssa, ja käyttöjärjestelmien ja tämän ohjelmointikielen "filosofia" vastaavat toisiaan. Toista kieltä käyttämällä tulee helposti kummallisuuksia, että ei ole niin unixmainen. Lopputulos on herkästi joku kummajainen.

"Mitkä työkalut ?"

Esimerkiksi työkaluja formaaliin verifiointiin. Vaikka tällainen: https://en.wikipedia.org/wiki/Frama-C

"Suorituskyky, mihin verrattuna ?"

Vaikka tulkattuihin kieliin. Tai kieliin jotka käyttävät garbage collectionia. Tai melkein mihin tahansa kun nuo C kielen kääntäjät ovat niin pitkään optimoituja.

"Mistä löytää nää serifikaatit ?"

Serfifioitujen tuotteiden valmistajat osaavat kertoa tarkemmin. Esim. QNX on IEC 62304 ja sitten lentokoneiden järjestelmissä on DO-178B sertifiointi. Se on itseasiassa vaatimus lentokoneiden tietokonejärjestelmille, että sellaisia päästetään ilmaan ja lentokoneisiin on tehty koodia C:llä.

DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

'''''yksinkertaisuus''''': Mihin verrattuna ?

Verrattuna vaikka Adaan, joka olisi semmoinen toinen suorituskykyinen kieli mikä sopii reaaliaikatarpeisiin ja löytyy sertifioituja työkaluja.

Että voit toki esittää niitä vaihtoehtoja C:lle mutta jokseenkin varmasti et keksi mitään mikä olisi joka asiassa parempi, ja viimeistään kun vaatimuksena on yhdenmukaisuus unix arkkitehtuurin kanssa tarkoittaisi sitä, että korvaaminen toisella tarkoittaisi helposti kaiken mahdollisen koodin tekemistä uusiksi jotta saa pidettyä yhtenäisenä.

Lue lisää

Sinä halveeraat ihmisten käsityskykyä. Tuommonen pilkanteko tuottaa ihan ansaittua palautetta.

dtyjuyutkit kirjoitti:

Sinä halveeraat ihmisten käsityskykyä. Tuommonen pilkanteko tuottaa ihan ansaittua palautetta.

Miten se on minun halveeraamista jos joku on niin tyhmä, että kysyy linkkejä tuotantoympäristöihin?

Miksi pitää jankuttaa naurettavia kysymyksiä minulle jos itse ei kykene edes perusteisiin perehtyä?

M-Kar kirjoitti:

Miten se on minun halveeraamista jos joku on niin tyhmä, että kysyy linkkejä tuotantoympäristöihin?

Miksi pitää jankuttaa naurettavia kysymyksiä minulle jos itse ei kykene edes perusteisiin perehtyä?

Lue lisää

Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan.
Suomi24:sen suurin trolli sidotaan yhdelle palstalle, niin muut keskustelut saa olla rauhassa paskanjauhannaltasi.

r67i758oi67tol kirjoitti:

Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan.
Suomi24:sen suurin trolli sidotaan yhdelle palstalle, niin muut keskustelut saa olla rauhassa paskanjauhannaltasi.

Lue lisää

"Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan."

Taitaa olla ennemminkin niin, että et ymmärrä mitään ohjelmoinnista.

M-Kar kirjoitti:

"Etkö sinä nyherö tajunnut, minähän vedätin sinua koko ajan."

Taitaa olla ennemminkin niin, että et ymmärrä mitään ohjelmoinnista.

Ei tarvitsekkaan, minusta on mukava kusettaa sinun kaltaisia luusereita.

M-Kar kirjoitti:

"Et sitten antanut yhtään linkkiä tuotantoympäristöön."

Kyseisiä kerneleitä on yleisesti tuotantoympäristöissä käytössä.

Tuotannossahan ne on tietysti käännettynä binäärimuotoon, että sorsistahan se tarkistetaan, tietysti.

"Perustele."

C on standardoitu
C mahdollistaa helposti vakaana pysyvän ABI:n
C on suorituskykyinen
C sopii laitteistonläheiseen ohjelmointiin
C:lle sopivia työkaluja ja systeemikoodia on sertifioitu
C sopii reaaliaikasovelluksiin

Ja sitten vielä se tärkeä juttu, nykyisin käytössä oleva unix arkkitehtuuri on tehty käsi kädessä C kielen kanssa, ja käyttöjärjestelmien ja tämän ohjelmointikielen "filosofia" vastaavat toisiaan. Toista kieltä käyttämällä tulee helposti kummallisuuksia, että ei ole niin unixmainen. Lopputulos on herkästi joku kummajainen.

"Mitkä työkalut ?"

Esimerkiksi työkaluja formaaliin verifiointiin. Vaikka tällainen: https://en.wikipedia.org/wiki/Frama-C

"Suorituskyky, mihin verrattuna ?"

Vaikka tulkattuihin kieliin. Tai kieliin jotka käyttävät garbage collectionia. Tai melkein mihin tahansa kun nuo C kielen kääntäjät ovat niin pitkään optimoituja.

"Mistä löytää nää serifikaatit ?"

Serfifioitujen tuotteiden valmistajat osaavat kertoa tarkemmin. Esim. QNX on IEC 62304 ja sitten lentokoneiden järjestelmissä on DO-178B sertifiointi. Se on itseasiassa vaatimus lentokoneiden tietokonejärjestelmille, että sellaisia päästetään ilmaan ja lentokoneisiin on tehty koodia C:llä.

DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.

'''''yksinkertaisuus''''': Mihin verrattuna ?

Verrattuna vaikka Adaan, joka olisi semmoinen toinen suorituskykyinen kieli mikä sopii reaaliaikatarpeisiin ja löytyy sertifioituja työkaluja.

Että voit toki esittää niitä vaihtoehtoja C:lle mutta jokseenkin varmasti et keksi mitään mikä olisi joka asiassa parempi, ja viimeistään kun vaatimuksena on yhdenmukaisuus unix arkkitehtuurin kanssa tarkoittaisi sitä, että korvaaminen toisella tarkoittaisi helposti kaiken mahdollisen koodin tekemistä uusiksi jotta saa pidettyä yhtenäisenä.

Lue lisää

Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta.
standardithan ovat tekijänoikeuksien alaisia, eli ainoa laillinen tapa hankkia standardiasiakirja on maksaa siitä.
Objectpascalin valinta kieleksi C:n sijasta säästää siis selvää rahaa, kun standardiasiakirjasta ei tarvotse maksaa.


Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n
Objectpascal on suorituskykyinen
Objectpascal sopii laitteistonläheiseen ohjelmointiin
Objectpascal:lle on sopivia työkaluja ja se soveltuu einomaisesti myös systeemikoodin kirjoittamiseen.
Mitään sertifiointeja ei tarvita, eikä sertifiointi oikeasti takaa mitään hyvää. Onpahan tiettyjen tahojen rahstusväline.

Objectpascal sopii reaaliaikasovelluksiin

Objectpascal on ennen kaikkea turvallisempi vaihtoehto.

Muistellaanpa vaikkapa Heartbleed -haavoittuvuutta, jollainen tuli julkisuuteen keväällä 2014 OpenSSL -kirjastosta.

Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Näin koodattu kirjasto olisi suoritettavan koodin koolla mitattuna ollut samaa luokkaa
kuin C -kielellä koodattukin, mutta huomattavasti turvallisempi.

M-Karin päinvastaisia väitteitä ei kannata uskoa, mitään todenperäisyyttä näillä väitteillä ei ole.

C -kielen sekava ja kryptinen syntaksi vie ohjelmoijan aivokapasiteetista suuren osan, ja vain vähäinen määrä
jää jäljelle ratkaistavan asian koodaamiseen. Siksi C -kieli on virhealtis, ja vaikka sitä on historiallisesti
paljon käytettykin systeemikoodin kirjoittamiseen, C -kielellä ei ole mitään sellaista etua
Objectpascaliin verrattuna, joka tekisi siitä jotenkin paremman systeemikoodin kirjoittamisvälineen.

Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja miksi niissä pelkkä Pascal kaikin puolin kehittyneemmän Objectpascalin sijasta ?

Siksi, että mikrokontrollerissa saattaa olla esim. 1024 tavua RAM -muistia, halvimmissa tuotakin vähemmän.

Vaikka Objectpascal on kielenä sekä C:tä että pelkkää Pascalia kehittyneempi, niin
objektipohjaisuus lisää RAM -muistin tarvetta, ja jos mikrokontrollerissa on RAM -muistia
hyvin vähän, silloin sitä ei yleensä ole tarpeeksi objektipohjaiselle lähestymistavalle.

Objectpascal -kääntäjä (kuten esim. Free Pascal) kääntää myös pascalia ilman objekteja.

Eli kääntäjää ei tarvitse edes vaihtaa, vaikka objektit ja luokat jättäisikin käyttämättä,
jos jossain projektissa vaatimuksiin kuuluu minimaalisen pieni RAM -muistin käyttö.

M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures


Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä.

C -kieli on yksinkertaisesti ammattilaisellekin liian vaikeaa.
Tästä on hyvänä osoituksena se, että ammattilaisten, arvostettujen koodaajien jäljiltä
on luettavissa C -kielistä koodia, joissa on alkeellisia virheitä.

Jos sama projekti olisi koodattu Objectpascalilla, kyseisiä virheitä ei olisi tapahtunut.

En aio listata ko. virheitä tähän, sillä jos niin tekisin, joku ehkä kävisi korjaamassa nuo virheet välittömästi.

Silti vastaavia virheitä olisi lisääkin olemassa, mutta en vain ole tietoinen niistä.

C -kielen suunnittelija on tehnyt lukuisia virheitä.

Yksi niistä on idioottimainen if -käskyn syntaksi, josta puuttuu then.


Ilmeisesti tuo M-Karin joko tietämättömyyttään
tai tahallisessa harhaanjohtamistarkoituksessa (en tiedä, kummasta on kysymys)

puffaama Halstead complexity toimii juuri päinvastoin kuin on järkevää.

Hyvin yksinkertainen esimerkki:

C-Kieli:

if (a < b) {
min = a
} else { min = b};


Objectpascal:
if a < b
then min := a
else min := b;

M-Kar ilmeisesti tykkää mielestään todistella tuolla em.
Halstead complexity measures -systeemillä,
että em. C -koodi olisi jotenkin parempaa kuin vastaava Objectpascal -koodi.

then -sana tekee kuitenkin koodista helpommin ymmärrettävää.
Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole,
mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta.

Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C , C#, Java, Javascript, Ada, Perl, PHP ja Python ?


Ja sikäli kuin tarvitaan suoraa ABI -yhteensopivuutta C -kielellä tehdyn toisen ohjelmamodulin kanssa,

Objectpascalissa on ratkaisu tähänkin:

Windows:
function demo(a,b:Integer):integer; cdecl; external 'systemmodule.dll';
function demo2(a,b:Integer):integer; stdcall; external 'systemmodule.dll';

Linux:
function de

C_huono kirjoitti:

Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta.
standardithan ovat tekijänoikeuksien alaisia, eli ainoa laillinen tapa hankkia standardiasiakirja on maksaa siitä.
Objectpascalin valinta kieleksi C:n sijasta säästää siis selvää rahaa, kun standardiasiakirjasta ei tarvotse maksaa.


Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n
Objectpascal on suorituskykyinen
Objectpascal sopii laitteistonläheiseen ohjelmointiin
Objectpascal:lle on sopivia työkaluja ja se soveltuu einomaisesti myös systeemikoodin kirjoittamiseen.
Mitään sertifiointeja ei tarvita, eikä sertifiointi oikeasti takaa mitään hyvää. Onpahan tiettyjen tahojen rahstusväline.

Objectpascal sopii reaaliaikasovelluksiin

Objectpascal on ennen kaikkea turvallisempi vaihtoehto.

Muistellaanpa vaikkapa Heartbleed -haavoittuvuutta, jollainen tuli julkisuuteen keväällä 2014 OpenSSL -kirjastosta.

Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Näin koodattu kirjasto olisi suoritettavan koodin koolla mitattuna ollut samaa luokkaa
kuin C -kielellä koodattukin, mutta huomattavasti turvallisempi.

M-Karin päinvastaisia väitteitä ei kannata uskoa, mitään todenperäisyyttä näillä väitteillä ei ole.

C -kielen sekava ja kryptinen syntaksi vie ohjelmoijan aivokapasiteetista suuren osan, ja vain vähäinen määrä
jää jäljelle ratkaistavan asian koodaamiseen. Siksi C -kieli on virhealtis, ja vaikka sitä on historiallisesti
paljon käytettykin systeemikoodin kirjoittamiseen, C -kielellä ei ole mitään sellaista etua
Objectpascaliin verrattuna, joka tekisi siitä jotenkin paremman systeemikoodin kirjoittamisvälineen.

Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja miksi niissä pelkkä Pascal kaikin puolin kehittyneemmän Objectpascalin sijasta ?

Siksi, että mikrokontrollerissa saattaa olla esim. 1024 tavua RAM -muistia, halvimmissa tuotakin vähemmän.

Vaikka Objectpascal on kielenä sekä C:tä että pelkkää Pascalia kehittyneempi, niin
objektipohjaisuus lisää RAM -muistin tarvetta, ja jos mikrokontrollerissa on RAM -muistia
hyvin vähän, silloin sitä ei yleensä ole tarpeeksi objektipohjaiselle lähestymistavalle.

Objectpascal -kääntäjä (kuten esim. Free Pascal) kääntää myös pascalia ilman objekteja.

Eli kääntäjää ei tarvitse edes vaihtaa, vaikka objektit ja luokat jättäisikin käyttämättä,
jos jossain projektissa vaatimuksiin kuuluu minimaalisen pieni RAM -muistin käyttö.

M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures


Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä.

C -kieli on yksinkertaisesti ammattilaisellekin liian vaikeaa.
Tästä on hyvänä osoituksena se, että ammattilaisten, arvostettujen koodaajien jäljiltä
on luettavissa C -kielistä koodia, joissa on alkeellisia virheitä.

Jos sama projekti olisi koodattu Objectpascalilla, kyseisiä virheitä ei olisi tapahtunut.

En aio listata ko. virheitä tähän, sillä jos niin tekisin, joku ehkä kävisi korjaamassa nuo virheet välittömästi.

Silti vastaavia virheitä olisi lisääkin olemassa, mutta en vain ole tietoinen niistä.

C -kielen suunnittelija on tehnyt lukuisia virheitä.

Yksi niistä on idioottimainen if -käskyn syntaksi, josta puuttuu then.


Ilmeisesti tuo M-Karin joko tietämättömyyttään
tai tahallisessa harhaanjohtamistarkoituksessa (en tiedä, kummasta on kysymys)

puffaama Halstead complexity toimii juuri päinvastoin kuin on järkevää.

Hyvin yksinkertainen esimerkki:

C-Kieli:

if (a < b) {
min = a
} else { min = b};


Objectpascal:
if a < b
then min := a
else min := b;

M-Kar ilmeisesti tykkää mielestään todistella tuolla em.
Halstead complexity measures -systeemillä,
että em. C -koodi olisi jotenkin parempaa kuin vastaava Objectpascal -koodi.

then -sana tekee kuitenkin koodista helpommin ymmärrettävää.
Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole,
mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta.

Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C , C#, Java, Javascript, Ada, Perl, PHP ja Python ?


Ja sikäli kuin tarvitaan suoraa ABI -yhteensopivuutta C -kielellä tehdyn toisen ohjelmamodulin kanssa,

Objectpascalissa on ratkaisu tähänkin:

Windows:
function demo(a,b:Integer):integer; cdecl; external 'systemmodule.dll';
function demo2(a,b:Integer):integer; stdcall; external 'systemmodule.dll';

Linux:
function de

Lue lisää

"Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta."

Ei tarvitse nytkään maksaa. Sertifiointi on se mikä on kallista puuhaa.

"Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n"

Vakaan ABI:n edellytys on vakaa API, ja vakaaseen API:n auttaa standardointi.

"Objectpascal on suorituskykyinen"

C on suorituskykyisempi ja kääntäjien optimoinnit on pidemmälle kehitetty. Object Pascalissahan oli lisäksi kaikennäköistä range checkiä yms. hidastetta.

"Objectpascal sopii laitteistonläheiseen ohjelmointiin."

Johtuen heikommasta suorituskyvystä, ei kannata käyttää. Onhan siinä sitten muitakin outoksia kuten calling convention puljaaminen tai sitten vaikka se, että miljoonien rivien sorsapuu on C:tä niin ei kannata sotkea sekaan mitään Object Pascalia. Tekee vain buildauksesta monimutkaisempaa.

"Objectpascal:lle on sopivia työkaluja"

No mitäs työkaluja on formaaliin verifiointiin?

"Mitään sertifiointeja ei tarvita"

Ilman sertifiointia ei lentokone saa lentää eikä softa voi ohjata röntgen kuvan ottamista tai vaikka keinomunuaista. Vaatimukset tulevat lainsäädännöstä.

"Objectpascal sopii reaaliaikasovelluksiin"

Kyllä. Object Pascal todellakin sopii reaaliaikasovelluksiin. Monet reaaliaikakohteet, kuten lentokoneen järjestelmät, vaan edellyttää myös sitä sertifiointia joten reaaliaikasovellukset joissa Object Pascalia voisi käyttää rajoittuisi teollisuusautomaatioon tai vaikka audiokäyttöön. Turvallisuuskriittiset reaaliaika kohteet ei Object Pascalille käy, sinne valitaan C, Ada ja nykyisin myös käytetään C :sta subsettiä, että ei ole kaikki hilavitkuttimet mukana.

"Objectpascal on ennen kaikkea turvallisempi vaihtoehto."

Kuoleva ohjelmointikieli on taloudellinen riski, ja ohjelmointikieli itsessään ei sovi sinne turvallisuutta vaativiin kohteisiin kuten lentokoneeseen.

"Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut."

Object Pascalilla tehtyä OpenSSL kirjastoa ei olisi kelpuutettu käyttöjärjestelmiin. Turhaa kompeksisuutta tuoda erilaisia kieliä. Systeemiohjelmoijat siivoavat myös C :aa pois, että olisi keskeiset komponentit puhdasta C:tä tai sh skriptiä.

Standardoinnin puute on myös tärkeä syy olla ottamatta Object Pascalia tuollaiseen. 90-luvulla Object Pascal oli johdettu vanhasta Borlandin Turbo Pascalin murteesta ja näin ollen siinä oli riski, että jonkun patentin takia torpataan koko projekti. Javan kanssahan sitä sitten riideltiin patenttien takia muutamaa vuotta myöhemmin.

Toinen vika Free Pascalissa oli lisensointi. Ei BSD järjestelmiin lisätä yhtään GPL koodia lisää saastuttamaan koodipuuta. Ainoat GPL palikat mitä BSD järjestelmissä käytettiin oli aikoinaan just joku GCC ja autotools ja kokoajan GPL koodia on vähennetty koodipohjasta.

Toisin sanoen, Object Pascalilla OpenSSL olisi jäänyt kelvottomaksi torsoksi jota ei olisi ihmiset käyttänyt ja sen tilalle olisi tehty oikeilla työkaluilla toinen kirjasto C:llä.

"Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja sitten kun sitä C:tä kuitenkin on niin tuo vaan lisää kompleksisuutta tuoda ylimääräisiä työkaluja.

C_huono kirjoitti:

Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta.
standardithan ovat tekijänoikeuksien alaisia, eli ainoa laillinen tapa hankkia standardiasiakirja on maksaa siitä.
Objectpascalin valinta kieleksi C:n sijasta säästää siis selvää rahaa, kun standardiasiakirjasta ei tarvotse maksaa.


Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n
Objectpascal on suorituskykyinen
Objectpascal sopii laitteistonläheiseen ohjelmointiin
Objectpascal:lle on sopivia työkaluja ja se soveltuu einomaisesti myös systeemikoodin kirjoittamiseen.
Mitään sertifiointeja ei tarvita, eikä sertifiointi oikeasti takaa mitään hyvää. Onpahan tiettyjen tahojen rahstusväline.

Objectpascal sopii reaaliaikasovelluksiin

Objectpascal on ennen kaikkea turvallisempi vaihtoehto.

Muistellaanpa vaikkapa Heartbleed -haavoittuvuutta, jollainen tuli julkisuuteen keväällä 2014 OpenSSL -kirjastosta.

Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut.

Näin koodattu kirjasto olisi suoritettavan koodin koolla mitattuna ollut samaa luokkaa
kuin C -kielellä koodattukin, mutta huomattavasti turvallisempi.

M-Karin päinvastaisia väitteitä ei kannata uskoa, mitään todenperäisyyttä näillä väitteillä ei ole.

C -kielen sekava ja kryptinen syntaksi vie ohjelmoijan aivokapasiteetista suuren osan, ja vain vähäinen määrä
jää jäljelle ratkaistavan asian koodaamiseen. Siksi C -kieli on virhealtis, ja vaikka sitä on historiallisesti
paljon käytettykin systeemikoodin kirjoittamiseen, C -kielellä ei ole mitään sellaista etua
Objectpascaliin verrattuna, joka tekisi siitä jotenkin paremman systeemikoodin kirjoittamisvälineen.

Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja miksi niissä pelkkä Pascal kaikin puolin kehittyneemmän Objectpascalin sijasta ?

Siksi, että mikrokontrollerissa saattaa olla esim. 1024 tavua RAM -muistia, halvimmissa tuotakin vähemmän.

Vaikka Objectpascal on kielenä sekä C:tä että pelkkää Pascalia kehittyneempi, niin
objektipohjaisuus lisää RAM -muistin tarvetta, ja jos mikrokontrollerissa on RAM -muistia
hyvin vähän, silloin sitä ei yleensä ole tarpeeksi objektipohjaiselle lähestymistavalle.

Objectpascal -kääntäjä (kuten esim. Free Pascal) kääntää myös pascalia ilman objekteja.

Eli kääntäjää ei tarvitse edes vaihtaa, vaikka objektit ja luokat jättäisikin käyttämättä,
jos jossain projektissa vaatimuksiin kuuluu minimaalisen pieni RAM -muistin käyttö.

M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures


Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä.

C -kieli on yksinkertaisesti ammattilaisellekin liian vaikeaa.
Tästä on hyvänä osoituksena se, että ammattilaisten, arvostettujen koodaajien jäljiltä
on luettavissa C -kielistä koodia, joissa on alkeellisia virheitä.

Jos sama projekti olisi koodattu Objectpascalilla, kyseisiä virheitä ei olisi tapahtunut.

En aio listata ko. virheitä tähän, sillä jos niin tekisin, joku ehkä kävisi korjaamassa nuo virheet välittömästi.

Silti vastaavia virheitä olisi lisääkin olemassa, mutta en vain ole tietoinen niistä.

C -kielen suunnittelija on tehnyt lukuisia virheitä.

Yksi niistä on idioottimainen if -käskyn syntaksi, josta puuttuu then.


Ilmeisesti tuo M-Karin joko tietämättömyyttään
tai tahallisessa harhaanjohtamistarkoituksessa (en tiedä, kummasta on kysymys)

puffaama Halstead complexity toimii juuri päinvastoin kuin on järkevää.

Hyvin yksinkertainen esimerkki:

C-Kieli:

if (a < b) {
min = a
} else { min = b};


Objectpascal:
if a < b
then min := a
else min := b;

M-Kar ilmeisesti tykkää mielestään todistella tuolla em.
Halstead complexity measures -systeemillä,
että em. C -koodi olisi jotenkin parempaa kuin vastaava Objectpascal -koodi.

then -sana tekee kuitenkin koodista helpommin ymmärrettävää.
Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole,
mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta.

Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C , C#, Java, Javascript, Ada, Perl, PHP ja Python ?


Ja sikäli kuin tarvitaan suoraa ABI -yhteensopivuutta C -kielellä tehdyn toisen ohjelmamodulin kanssa,

Objectpascalissa on ratkaisu tähänkin:

Windows:
function demo(a,b:Integer):integer; cdecl; external 'systemmodule.dll';
function demo2(a,b:Integer):integer; stdcall; external 'systemmodule.dll';

Linux:
function de

Lue lisää

"M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä."

Ei niin. En ole sellaista sanonutkaan.

Halstead complexity on kyllä ihan pätevä mittari, että se mittaa sitä koodin kompleksisuutta ja ilmaisukykyä.

Suoraan ei voi kahta kieltä näin mitata, koska eri työkaluja tehdään eri käyttötarkoituksiin ja omassa käyttötarkoituksessaan toinen kieli on helposti parempi kuin toinen.

Kritisoin joskus Delphiä siitä, että sellaista kohdetta ei ole mihin ei löytyisi nykyään sopivampaa työkalua. Tuo koskee myös Object Pascalia, että eri käyttötarkoituksiin löytyy kyllä sopivampia kieliä.

Työkaluhan valitaan käyttötarkoituksen mukaan ja kieli on myös työkalu.

"then -sana tekee kuitenkin koodista helpommin ymmärrettävää."

Näitä asioita on tutkittu. Ihmisaivot käsittelevät asioita symboleina ja havaitsevat ryhmittämistä. Se then -sana ei siellä ratkaise vaan ennemminkin se then -blokin sisennys. Se then -sana on siellä sitten vain kohinaa.

Mutta koska ihmisaivot käsittelevät asioita symboleina, tämän object pascal koodin:

if a < b
then min := a
else min := b;

voi sieventää C:lle näin:

min = a < b ? a : b;

Näistä kahdesta tuo minun kirjoittama C koodi on selvästi yksinkertaisempi.

"Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta."

Väärin meni. Se Halstead complexity mittaa kompleksisuutta kokonaisuudessaan. Se huomioi toteutuksen kuin myös sen työkalun.

"Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C , C#, Java, Javascript, Ada, Perl, PHP ja Python ?"

C, C , C#, Java, Javascript mahdollistavat tuon kirjoittamisen täysin samalla tavalla, eli:

min = a < b ? a : b;

PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;

Pythonissa vähän erikoinen järjestys:

min = a if a < b else b

Ada on kompleksinen:

' min := (if a < b
' then a
' else b);

M-Kar kirjoitti:

"M-Kar usein puffaa Halstead -systeemi koodin "laadun" mittarina.
hakukonesanalista: Halstead complexity measures

Tosiasiassa kahden eri ohjelmointikielen vertaaminen tuollaisella mittarilla ei ole mielekästä."

Ei niin. En ole sellaista sanonutkaan.

Halstead complexity on kyllä ihan pätevä mittari, että se mittaa sitä koodin kompleksisuutta ja ilmaisukykyä.

Suoraan ei voi kahta kieltä näin mitata, koska eri työkaluja tehdään eri käyttötarkoituksiin ja omassa käyttötarkoituksessaan toinen kieli on helposti parempi kuin toinen.

Kritisoin joskus Delphiä siitä, että sellaista kohdetta ei ole mihin ei löytyisi nykyään sopivampaa työkalua. Tuo koskee myös Object Pascalia, että eri käyttötarkoituksiin löytyy kyllä sopivampia kieliä.

Työkaluhan valitaan käyttötarkoituksen mukaan ja kieli on myös työkalu.

"then -sana tekee kuitenkin koodista helpommin ymmärrettävää."

Näitä asioita on tutkittu. Ihmisaivot käsittelevät asioita symboleina ja havaitsevat ryhmittämistä. Se then -sana ei siellä ratkaise vaan ennemminkin se then -blokin sisennys. Se then -sana on siellä sitten vain kohinaa.

Mutta koska ihmisaivot käsittelevät asioita symboleina, tämän object pascal koodin:

if a < b
then min := a
else min := b;

voi sieventää C:lle näin:

min = a < b ? a : b;

Näistä kahdesta tuo minun kirjoittama C koodi on selvästi yksinkertaisempi.

"Lisäksi, jos tuo mittaustapa antaa huonommat pisteet kun siinä on then -sana
verrattuna C -kieleen, jossa then -sanaa ei ole mutta siinä taas pakolliset sulut tuon varsinaisen ehdon a<b ynpärillä,
niin se ei todista mitään muuta kuin sen, että tuo
Halstead complexity measures -mittasysteemi on joko:

a) kelvoton yhtään mihinkään

tai

b) kelvoton käytettynä muuten kuin verrattaessa kahta vaihtoehtoista
samalla ohjelmointikielellä tehtyä toteutusta."

Väärin meni. Se Halstead complexity mittaa kompleksisuutta kokonaisuudessaan. Se huomioi toteutuksen kuin myös sen työkalun.

"Pitenköhän pärjäisivät tuolla samalla mittarilla esim. C, C , C#, Java, Javascript, Ada, Perl, PHP ja Python ?"

C, C , C#, Java, Javascript mahdollistavat tuon kirjoittamisen täysin samalla tavalla, eli:

min = a < b ? a : b;

PHP:llä ja Perlillä tulee kohinaa:

$min = $a < $b ? $a : $b;

Pythonissa vähän erikoinen järjestys:

min = a if a < b else b

Ada on kompleksinen:

' min := (if a < b
' then a
' else b);

Lue lisää

Olisi kyllä kiva nähdä koodi joka olisi Object Pascalilla ylivertaisen yksinkertainen verrattuna mihin tahansa muuhun.

TAI, olisi edes ylivertaisen siisti verrattuna kyseisen käyttötarkoituksen muihin soveltuviin työkaluihin. Pitää huomioida vaatimukset mitä tulee lainsäädännöstä, lisensoinnista, työkaluista.

Nyt näkyi C-kielikin toimivan paremmin ja mielestäni C:llä tulee helpommin kompleksista koodia kuin monilla muilla välineillä. Se onkin tarkoitettu matalemmalle tasolle, että sillä tehdään niitä korkeamman tason toimintoja.

Vaikka nuo tarpeettomat $ merkit muuttujissa.

M-Kar kirjoitti:

Vaikka nuo tarpeettomat $ merkit muuttujissa.

Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä. Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä.

OK, kyllä vakio voidaan tehdä C tai C mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse.

<?php
const min = 10;
$min = 0;
$a = 1;
$b = 2;
$min = $a < $b ? $a : $b;
echo $min;
echo min
?>

Lyhyesti-kiitos kirjoitti:

Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä. Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä.

OK, kyllä vakio voidaan tehdä C tai C mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse.

<?php
const min = 10;
$min = 0;
$a = 1;
$b = 2;
$min = $a < $b ? $a : $b;
echo $min;
echo min
?>

Lue lisää

"Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä."

PHP onkin monissa asioissa aika pa5ka.

"Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä."

IDE korostaa väreillä muuttujat, avainsanat ja jne.

Ja kuten näkyy niin muut kielet hoitavat tuon siistimmin.

"OK, kyllä vakio voidaan tehdä C tai C mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse."

Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.

M-Kar kirjoitti:

"Katsoppa tuota kahta echo riviä. PHP sisältää pitkänmatkaa yli 10 000 käsitettä."

PHP onkin monissa asioissa aika pa5ka.

"Tämä mielestäsi tarpeeton merkki kertoo ohjelmoijalle että kyseessä on muuttuja, ei vakio, joka se olis ilman tuota tarpeetonta merkkiä."

IDE korostaa väreillä muuttujat, avainsanat ja jne.

Ja kuten näkyy niin muut kielet hoitavat tuon siistimmin.

"OK, kyllä vakio voidaan tehdä C tai C mukaan, mutta kumpi on luettavampi, kummasta eroittaa heti ilman mitään epäilyjä mistä on kyse."

Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.

Lue lisää

''''Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.
KommentoiIlmianna''''

Otas nyt omassa C tai C kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa.

Eli nuo alla on kaksi funktion paluuarvon asetusta. Osaatko sinä oikeasti edes C tai C , puhumattakaan PHP kielestä.

return eka;
return toka;

Et viittis höpöttää jollet ole asiasta ollenkaan perillä. Ei nämä ihmiset täällä niele mitä tahaansa. mikä sinut ajaa tekemään tämmöistä kiusaa niille jotka tietävät. Aivan hiton rasittavaa kun kaveri joka ei tunne asiaa, kyseenalaitaa faktatietoa, saadakseen vääryydellä uskottavuutta omista kyvyistään.

Lyhyesti-kiitos kirjoitti:

''''Ei mitään eroa koska se näkyy nopeiten väristä tai muuten erilaisesta fontista.
KommentoiIlmianna''''

Otas nyt omassa C tai C kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa.

Eli nuo alla on kaksi funktion paluuarvon asetusta. Osaatko sinä oikeasti edes C tai C , puhumattakaan PHP kielestä.

return eka;
return toka;

Et viittis höpöttää jollet ole asiasta ollenkaan perillä. Ei nämä ihmiset täällä niele mitä tahaansa. mikä sinut ajaa tekemään tämmöistä kiusaa niille jotka tietävät. Aivan hiton rasittavaa kun kaveri joka ei tunne asiaa, kyseenalaitaa faktatietoa, saadakseen vääryydellä uskottavuutta omista kyvyistään.

Lue lisää

"Otas nyt omassa C tai C kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa."

Vakiot kirjoitetaan ISOLLA, muuttujat camelCase, return kun on varattu sana niin se näkyy eri värillä.

Faktatietoa on se, että PHP:ssä tungetaan niitä $ merkkejä muuttujien eteen ja C:ssä ei tarvitse.

Siinä semmoinen juttu, että hyvin kirjoitettu koodi on itsedokumentoiva. Ei tarvitse erikseen dokumentoida mitä joku koodi tekee kun koodin voi tehdä niin luettavaksi, että se on itsessään dokumentaatio.

Toki korostan sitä, että kokonaisuus ratkaisee ja erilaisissa tilanteissa eri työkaluilla saadaan siistimpi lopputulos.

M-Kar kirjoitti:

"Otas nyt omassa C tai C kehitys ympäristössäsi ja kerro millä tavalla väritys eroaa, kun (eka) on vakio, vaikka PII ja (toka ) tyyppiä char sisältäen mitä tahaansa."

Vakiot kirjoitetaan ISOLLA, muuttujat camelCase, return kun on varattu sana niin se näkyy eri värillä.

Faktatietoa on se, että PHP:ssä tungetaan niitä $ merkkejä muuttujien eteen ja C:ssä ei tarvitse.

Siinä semmoinen juttu, että hyvin kirjoitettu koodi on itsedokumentoiva. Ei tarvitse erikseen dokumentoida mitä joku koodi tekee kun koodin voi tehdä niin luettavaksi, että se on itsessään dokumentaatio.

Toki korostan sitä, että kokonaisuus ratkaisee ja erilaisissa tilanteissa eri työkaluilla saadaan siistimpi lopputulos.

Lue lisää

Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla, elikä ei tietenkään siihen ole mitään syntaksi sääntöä, ohjelmoija tekee niin kuin haluaa. Luettavuuden vuoksi jollakin tavalla ohjelmoijan on hyvä leimata vakiot selvästi muuttujista eritavalla. mikään ei estä tekemästä sitä toisinkin päin.

Vaikioiden kirjoittaminen isolla on hyvän tavan mukainen sääntö, jota voi verrata vaikka sääntöön, älä ohjelmoi voileipä toisessa kädessä.

#define pii 3.14

Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?
Ei se anna virheilmoitusta, kun siinä ei ole virhettä, eikä myöskään tässä alla olevassa.

#define PII 3.14

M-Kar kirjoitti:

"Objectpascal ei kaipaa standardeja; tästä on se hyöty, ettei sinun tarvitse maksaa standardiasiakirjasta."

Ei tarvitse nytkään maksaa. Sertifiointi on se mikä on kallista puuhaa.

"Objectpascal mahdollistaa helposti vakaana pysyvän ABI:n"

Vakaan ABI:n edellytys on vakaa API, ja vakaaseen API:n auttaa standardointi.

"Objectpascal on suorituskykyinen"

C on suorituskykyisempi ja kääntäjien optimoinnit on pidemmälle kehitetty. Object Pascalissahan oli lisäksi kaikennäköistä range checkiä yms. hidastetta.

"Objectpascal sopii laitteistonläheiseen ohjelmointiin."

Johtuen heikommasta suorituskyvystä, ei kannata käyttää. Onhan siinä sitten muitakin outoksia kuten calling convention puljaaminen tai sitten vaikka se, että miljoonien rivien sorsapuu on C:tä niin ei kannata sotkea sekaan mitään Object Pascalia. Tekee vain buildauksesta monimutkaisempaa.

"Objectpascal:lle on sopivia työkaluja"

No mitäs työkaluja on formaaliin verifiointiin?

"Mitään sertifiointeja ei tarvita"

Ilman sertifiointia ei lentokone saa lentää eikä softa voi ohjata röntgen kuvan ottamista tai vaikka keinomunuaista. Vaatimukset tulevat lainsäädännöstä.

"Objectpascal sopii reaaliaikasovelluksiin"

Kyllä. Object Pascal todellakin sopii reaaliaikasovelluksiin. Monet reaaliaikakohteet, kuten lentokoneen järjestelmät, vaan edellyttää myös sitä sertifiointia joten reaaliaikasovellukset joissa Object Pascalia voisi käyttää rajoittuisi teollisuusautomaatioon tai vaikka audiokäyttöön. Turvallisuuskriittiset reaaliaika kohteet ei Object Pascalille käy, sinne valitaan C, Ada ja nykyisin myös käytetään C :sta subsettiä, että ei ole kaikki hilavitkuttimet mukana.

"Objectpascal on ennen kaikkea turvallisempi vaihtoehto."

Kuoleva ohjelmointikieli on taloudellinen riski, ja ohjelmointikieli itsessään ei sovi sinne turvallisuutta vaativiin kohteisiin kuten lentokoneeseen.

"Jos olisin itse koodannut OpenSSL -kirjaston Objectpascal -ohjelmointikielellä
ja se olisi käännetty Free Pascal -kääntäjällä useisiin eri käyttöjärjestelmiin,
niin Heartbleed -haavoittuvuutta ei olisi koskaan tapahtunut."

Object Pascalilla tehtyä OpenSSL kirjastoa ei olisi kelpuutettu käyttöjärjestelmiin. Turhaa kompeksisuutta tuoda erilaisia kieliä. Systeemiohjelmoijat siivoavat myös C :aa pois, että olisi keskeiset komponentit puhdasta C:tä tai sh skriptiä.

Standardoinnin puute on myös tärkeä syy olla ottamatta Object Pascalia tuollaiseen. 90-luvulla Object Pascal oli johdettu vanhasta Borlandin Turbo Pascalin murteesta ja näin ollen siinä oli riski, että jonkun patentin takia torpataan koko projekti. Javan kanssahan sitä sitten riideltiin patenttien takia muutamaa vuotta myöhemmin.

Toinen vika Free Pascalissa oli lisensointi. Ei BSD järjestelmiin lisätä yhtään GPL koodia lisää saastuttamaan koodipuuta. Ainoat GPL palikat mitä BSD järjestelmissä käytettiin oli aikoinaan just joku GCC ja autotools ja kokoajan GPL koodia on vähennetty koodipohjasta.

Toisin sanoen, Object Pascalilla OpenSSL olisi jäänyt kelvottomaksi torsoksi jota ei olisi ihmiset käyttänyt ja sen tilalle olisi tehty oikeilla työkaluilla toinen kirjasto C:llä.

"Mikrokontrollerin koodaus voi olla ainoa paikka, jossa Objectpascal ei ole paras kieli.
Mutta niissäkin Pascal on parempi valinta kuin C.

Ja sitten kun sitä C:tä kuitenkin on niin tuo vaan lisää kompleksisuutta tuoda ylimääräisiä työkaluja.

Lue lisää

"DO-178B sertifiointi edellyttää myös sitä, että käytettävät työkalut kuten kääntäjä on perusteellisesti varmistettu oikeelliseksi.


Object Pascal todellakin sopii reaaliaikasovelluksiin. Monet reaaliaikakohteet, kuten lentokoneen järjestelmät, vaan edellyttää myös sitä sertifiointia
joten reaaliaikasovellukset joissa Object Pascalia voisi käyttää rajoittuisi teollisuusautomaatioon ..."


Hmmm....

mikä estää sertifioimasta Objectpascal -kielellä tehtyä ohjelmaa,
joka on käännetty FreePascal -kääntäjällä siten, että se on kelvollinen lentokoneeseen ?

Ovatko muilla kielillä tehdyt lentokoneiden ohjelmat sitten turvallisia?

EIVÄT OLE !

Tai eivät ainakaan olleet kesäkuussa 2009.

googlettakaapa: Air France Flight 447

Viime kädessä toki lentäjän virhe,
mutta olisi epäoikeudenmukaista syyttää pelkästään lentäjää !

Lentokoneen tietotekniikkaa hyödyntävä hallintajärjestelmä
oli suorastaan vaarallisesti ohjelmoitu, ja on samalla malliesimerkki siitä,
että sertifiointi ei oikeasti hyödytä mitään
(muuta kuin sertifiointeja tekevien yritysten omistajien osinkotulojen maksimointia).

Vai väittääkö M-Kar, että Air France lensi lentojaan lentokoneella,
jonka lentotietojärjestelmien sertifiointi ei ollut voimassa ?

Kyseisen lennon lentotietojärjestelmä oli siis ohjelmoitu toimimaan kerrassaan
vaarallisella tavalla:

Kun konetta lennettiin oikein, sakkausvaroitin hälytti jatkuvasti
(kun pitot -noeusanturit antoivat jäätymisen takia väärää tietoa koneen nopeudesta).

Kun konetta lennettiin väärin:

"From there until the end of the flight, the angle of attack never dropped below 35 degrees."

eli koneen nokka osoitti väärin lennettäessä vähintään 35 astetta yläviistoon,

silloin sakkausvaroitin ei varoittanut.

Todella vaarallinen tapa ohjelmoida sakkausvaroitin, eli oli omiaan houkuttelemaan lentäjän
tekemään juuri se virhe, minkä lentäjä sitten tekikin, ja joka ohjasi koneen tuhoonsa.

Mutta, M-Karin mielestä siis muodollinen sertifikaatti on tärkeämpää kuin se,
että ohjelmoija olisi oikeasti ymmärtänyt, mitä ja miten on ohjelmoimassa.

Itse olisin toteuttanut asian toisin:

sakkausvaroitin varoittaa aina, kun kone on joko sakkausvaarassa tai jo sakkaustilanteessa!

Toki pitää löytyä nappi, jota painamalla sakkausvaroittimen varoitusäänen voi hiljentää,
mutta varoitin jatkaa varoittamalla muulla tavalla, siis sekä vilkkuvalolla että
ohjaustikkua ravistamalla, tämä tunnetaan englanniksi nimellä "stick shaker".

ELi siis varoitusÄÄNEN voi hiljentää, mutta itse varoitus jatkuu, kun siihen on aihetta.

Väärä syöte nopeusanturilta on toki hyvin ikävä tilanne,
mutta siihenkin varautumiseen olisi olemassa keinoja.

Mutta on ikävää, jos alalla päätösvalta on annettu M-Karin tapaisille yksilöille,
joita kiinnostaa eniten muodollinen sertifikaatti ja se, että se on kunnossa, mutta

sitten tosiasiallinen oikein toimivuus ei kiinnosta ketään.

Lennon 447 lentäjistä kokenein, eli kapteeni tuli lepovuorosta välittämättä paikalle,
ja ilmeisesti kokeneempana olisi pystynyt pelastamaan
vakavaan vaaratilanteeseen joutuneen lentokoneen,
mutta pelstusyrityksen onnistumisen esti muutama ikävä seikka:

1. Kapteeni saapui lepovuoron keskeyttäneenä liian myöhään takaisin ohjaamoon,
jolloin tilanteen korjaamiseen ei jäänyt riittävästi aikaa.
Kapteenin saapuessa siis kone oli jatkuvassa sakkaustilassa,
ja koneen korkeus putosi huimaa vauhtia kohti valtameren pintaa,
koska nokka osoitti vähintään 35 astetta yläviistoon.

2. Airbusin ohjaamon tekninen suunnittelu ei ole paras mahdollinen!
Boeingin koneissa kapteenin ja perämiehen ohjaimet on mekaanisesti kytketty toisiinsa.

Jos kone olisi ollut Boeing, kapteeni olisi tajunnut välittömästi,
että nokka osoittaa aivan liian ylös.

Mutta Airbusissa asia on (tai ainakin oli kesäkuussa 2009) toisin:
Molemmilla on elektronisesti toteutettu oma ohjaimensa, jolla voi antaa
komentoja lentotietojärjestelmälle.
Jos kapteeni ja perämies antavat eri komennon nokan suuntauksesta
(mikä on mahdollista kun mekaanista yhteenkytkentää ei ole),
mistä lentotietojärjestelmä tietää, kumman komentoa noudattaa ?

Kapteeni ei välttämättä tajunnut, että perämies teki tyhjäksi kapteenin yrityksen
pelastaa lentokoneensa vakavasta vaaratilanteesta !

Jälleen malliesimerkki siitä, mitä seuraa, kun joku muodollinen sertifikaatti on olevinaan
hyvin tärkeää, mutta ohjelman koodaaja ei tunnu ymmärtävän tosiasioita lentämisestä.

Jokaisen koodarin pitäisi ymmärtää ainakin perusasiat fysiikan laeista, joita jokainen
lentokone väkisinkin noudattaa.

Tämän lisäksi, jos koodaaja ei ymmärrä jotakin yksityiskohtaa, vastuullinen koodari
konsultoisi asiassa fyysikkoa, ammattilentäjää tai molempia.

Näin itse olisin toiminut, ja luonnollisesti käyttänyt Objectpascalia koodauksen
käytännön toteutuksessa.

Onko muuten M-Karin mukaan Javalla tuo DO-178B sertifiointi ?

JOS ON, niin se osoittaa kyseisen sertifioinnin lähinnä pelleilyksi.

Poikkeuksena ehkä se, jos jossain Java -toteutuksessa on muita Java -toteutuksia fiksummin
teh

Lyhyesti-kiitos kirjoitti:

Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla, elikä ei tietenkään siihen ole mitään syntaksi sääntöä, ohjelmoija tekee niin kuin haluaa. Luettavuuden vuoksi jollakin tavalla ohjelmoijan on hyvä leimata vakiot selvästi muuttujista eritavalla. mikään ei estä tekemästä sitä toisinkin päin.

Vaikioiden kirjoittaminen isolla on hyvän tavan mukainen sääntö, jota voi verrata vaikka sääntöön, älä ohjelmoi voileipä toisessa kädessä.

#define pii 3.14

Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?
Ei se anna virheilmoitusta, kun siinä ei ole virhettä, eikä myöskään tässä alla olevassa.

#define PII 3.14

Lue lisää

"Vielä kehtasi vääntää päin persettä. Missä pirussa niin sanotaan että vakiot kirjotetaan isolla"

Varmaan kaikissa tyylioppaissa konsensus tästä.

"Minkä virheilmoituksen sinun kehitysympäristö antaa yllä olevasta määrittelystä ?"

Punakynä maalaa tekstit tai sitten jälkikäteen ajettuna lintteri, joku clang-tidy vaikka älähtää.

En minä ole sanonut, että kielen säännöt pakottaisi mutta ei tarvitsekkaan. Se kieli on vain edelleen työkalu millä muotoillaan omat ajatukset tietokoneen ymmärtämään muotoon.

"mikä estää sertifioimasta Objectpascal -kielellä tehtyä ohjelmaa,
joka on käännetty FreePascal -kääntäjällä siten, että se on kelvollinen lentokoneeseen ?"

Se sertifiointiprosessi on niin tiukka, että siihen kuuluu myös kääntäjä ja varmistetaan myös se, että kääntäjä tuottaa oikeaa koodia. Voihan kääntäjissäkin olla bugeja. Ja tietysti sertifiointiin kuuluu myös rauta.

"Ovatko muilla kielillä tehdyt lentokoneiden ohjelmat sitten turvallisia?"

Tällä hetkellä hyväksyttyjä on C, Ada ja riisuttu C missä käytetään vain tiettyjä osia kielestä.

"Kun konetta lennettiin oikein, sakkausvaroitin hälytti jatkuvasti
(kun pitot -noeusanturit antoivat jäätymisen takia väärää tietoa koneen nopeudesta)."

Eli sieltä ei löytytynyt nappia sakkausvaroituksen pois kytkemiseksi. Joko puuttui tai oli typerässä paikassa. Mokahan se mutta siellä ilmailupuolella on tiukat laatuprosessit siksi, että tuollaisia mokia kävisi vähän. Siihen prosessiin kuuluu myös korjata aiemmat mokat, että jatkossa ei pääsisi enää käymään.

"Mutta, M-Karin mielestä siis muodollinen sertifikaatti on tärkeämpää kuin se,
että ohjelmoija olisi oikeasti ymmärtänyt, mitä ja miten on ohjelmoimassa."

ObjectPascal ei tässä olisi pelastanut kun vika oli tehty ennen kuin koodia oli alettu kirjoittamaan.

"Onko muuten M-Karin mukaan Javalla tuo DO-178B sertifiointi ?"

Ei. Javassa on semmoinen ominaisuus kuin roskienkerääjä ja silloin kun roskienkerääjä pyörähtää ja vapauttaa muistia niin lentokoneita alkaisi putoilla. Se roskienkerääjä kun on suunniteltu tilanteissiin missä ei ole jatkuva reaaliaikavaatimus vaan tilanteisiin joissa kuormitus vaihtelee, että sitä ajellaan silloin kun ei olisi kuormaa.

Javasta ollaan kyllä tekemässä jotain tällaisiin tilanteisiin sopivaa, riisuttua versioita missä ollaan jollain konstilla pakotettu muistinhallinta toimimaan reaaliaikavaatimuksilla ja tässä voi olla myös oma rauta myös millä se temppu tehdään.

https://jcp.org/en/jsr/detail?id=302

Tätä on työstetty 11v jo, ei tosiaankaan ole valmis eikä nykyisellään kelpaa lentokoneisiin.

F-35 hävittäjä taisi olla ensimmäinen missä alettiin käyttämään riisuttua C :aa ja tämähän saatiin pari vuotta sitten. C taas on vuodelta -83, että noissa turvallisuuskriittisissä järjestelmissä on aika pitkä sykli sille että softa on nuoltuna siihen kuntoon, että voi ottaa lentokoneen kriittisiin järjestelmiin.

Ada toki on yhtä vanha ja sitä on käytetty pitkään mutta siinä semmoinen ero, että se kieli alusta lähtien suunniteltu käytettäväksi jossain lentokoneiss tai ydinaseissa ja on ollut varmistettuna iäisyyden, että työkalut toimii oikein.

"Jos MUSTA on mustaa ja VALKOINEN on valkoista, siihen ei mitään konsensusta tarvita."

Ei siihen tarvitse mitään lisämerkkejä näyttämään eroa kun vakiot tunnistaa ISOLLA kirjoitetusta.

"Sellaista punakynää ei ole."

Onhan. Hanki kunnon IDE.

"Sinun mielestä kieli on hyvä, eikä muutoksia syntaksiin kaivata, koska joku kolmas osapuoli on tehnyt hyvästä ohjelmointi tavasta poikkeavien kohtien paikantajan."

En ole tuollaista väittänyt.

Et tunnu hahmoittavan sitä, että on asioita joita kielen spesifikaatio pakottaa, muut työkalut pakottaa tai sitten tehdään asia jollain käytännöllä. Lopputulosta se ei muuta, että kumpi työkalu saa tehtyä tuon asian siistimmin ja tässä tapauksessa se oli C.

"C kieli, onko "toka" muuttuja vai vakio ? (vastaus löytyy jostakin lähdekoodista)

return eka;
return toka;

Tuossa tapauksessa molemmat ovat muutujia koska vakiot kirjoitetaan isolla.

"PHP kieli, onko "toka" muuttuja vai vakio ? (vastausta ei tarvitse hakea, se on vakio)"

return $eka;
return toka;

PHP ohjelmoinnissa myös normaali käytäntö kirjoittaa vakiot isolla. tuossa tapauksessa varmaan tulisi virheilmoitus kun muuttujan nimestä puuttuu $. Vakiohan olisi kirjoitettu TOKA

"Vain täysi ummikko voi sanoa $ -merkkiä PHP:ssä ylimääräiseksi. "

Moni muu kieli tekee saman tempun ilman $ merkkiä. Sinä vissiin haluat tunkea sen ObjectPascaliinkin?

M-Kar kirjoitti:

"Jos MUSTA on mustaa ja VALKOINEN on valkoista, siihen ei mitään konsensusta tarvita."

Ei siihen tarvitse mitään lisämerkkejä näyttämään eroa kun vakiot tunnistaa ISOLLA kirjoitetusta.

"Sellaista punakynää ei ole."

Onhan. Hanki kunnon IDE.

"Sinun mielestä kieli on hyvä, eikä muutoksia syntaksiin kaivata, koska joku kolmas osapuoli on tehnyt hyvästä ohjelmointi tavasta poikkeavien kohtien paikantajan."

En ole tuollaista väittänyt.

Et tunnu hahmoittavan sitä, että on asioita joita kielen spesifikaatio pakottaa, muut työkalut pakottaa tai sitten tehdään asia jollain käytännöllä. Lopputulosta se ei muuta, että kumpi työkalu saa tehtyä tuon asian siistimmin ja tässä tapauksessa se oli C.

"C kieli, onko "toka" muuttuja vai vakio ? (vastaus löytyy jostakin lähdekoodista)

return eka;
return toka;

Tuossa tapauksessa molemmat ovat muutujia koska vakiot kirjoitetaan isolla.

"PHP kieli, onko "toka" muuttuja vai vakio ? (vastausta ei tarvitse hakea, se on vakio)"

return $eka;
return toka;

PHP ohjelmoinnissa myös normaali käytäntö kirjoittaa vakiot isolla. tuossa tapauksessa varmaan tulisi virheilmoitus kun muuttujan nimestä puuttuu $. Vakiohan olisi kirjoitettu TOKA

"Vain täysi ummikko voi sanoa $ -merkkiä PHP:ssä ylimääräiseksi. "

Moni muu kieli tekee saman tempun ilman $ merkkiä. Sinä vissiin haluat tunkea sen ObjectPascaliinkin?

Lue lisää

No, minä luotan lukijoiden ymmärrykseen asian suhteen, ja päätän keskustelun omalta osaltani tähän.

Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.

M-Kar kirjoitti:

Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.

Lue lisää

Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. Jotkut tarpeet ovat toki paikattavissa räätälöitävillä yleisohjelmilla, mutta ei läheskään kaikki. Ja osa räätälöinneistäkin on ihan selkeästi ohjelmistokehittämistä, eikä pelkkää konffaamista.

sfsfdfsdf kirjoitti:

Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. Jotkut tarpeet ovat toki paikattavissa räätälöitävillä yleisohjelmilla, mutta ei läheskään kaikki. Ja osa räätälöinneistäkin on ihan selkeästi ohjelmistokehittämistä, eikä pelkkää konffaamista.

Lue lisää

"Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. "

Esim. mitä? Miltä toimialalta puuttuu sovellukset ja mitä?

On normaalia, että ensimmäisessä vaiheessa käytetään kynää ja paperia, sen jälkeen homma tehdään yleiskäyttöisillä toimistosovelluksilla ja lopuksi optimoidaan käyttötarpeisiin tehdyillä sovelluksilla.

M-Kar kirjoitti:

"Maailmasta puuttuu ääretön määrä liiketoimintasovelluksia. "

Esim. mitä? Miltä toimialalta puuttuu sovellukset ja mitä?

On normaalia, että ensimmäisessä vaiheessa käytetään kynää ja paperia, sen jälkeen homma tehdään yleiskäyttöisillä toimistosovelluksilla ja lopuksi optimoidaan käyttötarpeisiin tehdyillä sovelluksilla.

Lue lisää

Ihan jokaiselta yritykseltä joka toimii jonkin prosessin mukaan "puuttuu" siihen prosessiin sovitettu sovellus.

sdfafsdfsd kirjoitti:

Ihan jokaiselta yritykseltä joka toimii jonkin prosessin mukaan "puuttuu" siihen prosessiin sovitettu sovellus.

Esimerkiksi mitä?

sdfafsdfsd kirjoitti:

Ihan jokaiselta yritykseltä joka toimii jonkin prosessin mukaan "puuttuu" siihen prosessiin sovitettu sovellus.

Tämä on täysin 100% totta. Nykyisessä työpaikassa (5v ) olen kehittänyt webissä toimivaa taloushallinnon softaa (prosesseja) ja koskaan tämä ei ole valmis. Uusia asiakkaita tulee, vaatimukset kasvaa, kuormat kasvaa, softa elää jatkuvasti. Open-source softaa käytetään 99% hyväksi ja myös Linux tuli tutuksi tämä työpaikan kautta.

Kävin eräs kerta nettideiteillä ja sanoin naiselle mitä teen työkseni, nainen kysyi että eikö se ole jo valmis? :'D hahaha! Joo niin se on, me vain nojaillaan tuoliin ja pyöritellään peukkuja, ei tod!

Esimerkiksi nakkikioskilta "puuttuu" sovellus joka seuraa tilauksia ja optimoi sen mukaan rasvakeittimen käyttöaikoja.

keps kirjoitti:

Tämä on täysin 100% totta. Nykyisessä työpaikassa (5v ) olen kehittänyt webissä toimivaa taloushallinnon softaa (prosesseja) ja koskaan tämä ei ole valmis. Uusia asiakkaita tulee, vaatimukset kasvaa, kuormat kasvaa, softa elää jatkuvasti. Open-source softaa käytetään 99% hyväksi ja myös Linux tuli tutuksi tämä työpaikan kautta.

Kävin eräs kerta nettideiteillä ja sanoin naiselle mitä teen työkseni, nainen kysyi että eikö se ole jo valmis? :'D hahaha! Joo niin se on, me vain nojaillaan tuoliin ja pyöritellään peukkuja, ei tod!

Lue lisää

Kuormien ja asiakkaiden määrän kasvu ei olennaisesti ole ongelma jos infra on kunnossa. Että uutta serveriä vaan ylös.

Että organisaation tarjoamat palvelut ja tuotteet organisaation ulkopuolelle ja sisäiset palvelut organisaation sisälle ratkaisee että paljon kompleksisuutta, ja kompleksuus kertoo sitten siitä työmäärästä.

Aika monta palikkaa on tietysti valmista ja saatavilla että eihän näitä tyhjästä tarvitse tehdä. Hyvin usein kehittämisen sijasta konfiguroidaan valmiiksi tehty softa toimimaan haluamalla tavalla.

sdfsfdf kirjoitti:

Esimerkiksi nakkikioskilta "puuttuu" sovellus joka seuraa tilauksia ja optimoi sen mukaan rasvakeittimen käyttöaikoja.

Rasvakeitin aitetaan päälle silloin kun on saapumassa asiakkaita. Vai onko ideoita miten asian voisi tehdä paremmin?

M-Kar kirjoitti:

Rasvakeitin aitetaan päälle silloin kun on saapumassa asiakkaita. Vai onko ideoita miten asian voisi tehdä paremmin?

Ruuhkassa voidaan optimoida paistojärjestystä niin että käyttöaste pysyy mahdollisimman korkeana ilman että öljy pääsee kuitenkaan jäähtymään liikaa eikä mikään tilaus veny halutun minuuttimäärän ylitse.

sdfsdfsdfsdg kirjoitti:

Ruuhkassa voidaan optimoida paistojärjestystä niin että käyttöaste pysyy mahdollisimman korkeana ilman että öljy pääsee kuitenkaan jäähtymään liikaa eikä mikään tilaus veny halutun minuuttimäärän ylitse.

Lue lisää

Mihin tässä tarvitsee sitä softaa kun nakkikiskalla näkee sen asiakasmäärän että voi sen mukaan kytkeä päälle tai pois.

M-Kar kirjoitti:

Mihin tässä tarvitsee sitä softaa kun nakkikiskalla näkee sen asiakasmäärän että voi sen mukaan kytkeä päälle tai pois.

Mihin tietokoneitakaan ylipäätään tarvitaan kun ei niitä sata vuotta sittenkään tarvittu? Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta? Mistä ne tilaajat silloin nähdään, että tuleekohan viiden minuutin sisällä kuinka paljon mitäkin tilauksia?

Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja? Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?

sdfgagfdsg kirjoitti:

Mihin tietokoneitakaan ylipäätään tarvitaan kun ei niitä sata vuotta sittenkään tarvittu? Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta? Mistä ne tilaajat silloin nähdään, että tuleekohan viiden minuutin sisällä kuinka paljon mitäkin tilauksia?

Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja? Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?

Lue lisää

"Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta?"

Sittenhän tuo nähdään tilauksista mitä on tehty. Ja netin kautta tilaukseen on softa. Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä.

"Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja?"

Toki ymmärrän mutta sinä et osannut kertoa PUUTTUVAA liiketoimintasovellusta. Ruoan tilaamiseen netin kautta on jo softa.

"Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?"

Sinullahan ne ongelmat näkyy olevan kun yksinkertaiseen kysymykseen ei saa vastausta.

Jatkuvasti joku jankkaa että ohjelmissa on muka vikoja ja sitten kun kysyy miten vian voi toistaa niin ei vastausta. Ja jos ohjelmat on muka keskeneräisiä tai joku ohjelma puuttuu niin ei oikein siihenkään saa vastausta.

Tuossa rasvakeittimessä nyt oli vähän jotain yritystä mutta kyllä se nettitilaus on jo olemassa ja se rasvakeitin lähtee pois siitä napista silloin kun ei ole aktiviiteettia tilauksissa eikä ihmisiä kävelemässä nakkikiskan ympäristössä tai sitä kohti.

M-Kar kirjoitti:

"Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta?"

Sittenhän tuo nähdään tilauksista mitä on tehty. Ja netin kautta tilaukseen on softa. Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä.

"Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja?"

Toki ymmärrän mutta sinä et osannut kertoa PUUTTUVAA liiketoimintasovellusta. Ruoan tilaamiseen netin kautta on jo softa.

"Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?"

Sinullahan ne ongelmat näkyy olevan kun yksinkertaiseen kysymykseen ei saa vastausta.

Jatkuvasti joku jankkaa että ohjelmissa on muka vikoja ja sitten kun kysyy miten vian voi toistaa niin ei vastausta. Ja jos ohjelmat on muka keskeneräisiä tai joku ohjelma puuttuu niin ei oikein siihenkään saa vastausta.

Tuossa rasvakeittimessä nyt oli vähän jotain yritystä mutta kyllä se nettitilaus on jo olemassa ja se rasvakeitin lähtee pois siitä napista silloin kun ei ole aktiviiteettia tilauksissa eikä ihmisiä kävelemässä nakkikiskan ympäristössä tai sitä kohti.

Lue lisää

Jos sinulla on 100 tilausta ranskalaisista, 80 nugetti-tilausta ja 20 kalapihviä, niin eipä tuo nyt täysin triviaalia ole miettiä missä järjestyksessä ne tilaukset ovat tulleet, kuinka paljon mitäkin tavaraa voidaan kerralla keittimeen laittaa ilman että lämmöt laskee liikaa, kuinka lisätyt tuotteet vaikuttavat jo keittimessä olevien paistoaikaan, miten varmistaa että yhden tilauksen tuotteet valmistuvat tietyn aikaikkunan sisällä että osa ei ole jo toimitettaessa kylmää.

Samoin öljyn käyttömäärää pitää pystyä seuraamaan, suunnitella suodatukset, vaihtovälit, seurata ja logittaa lämpötiloja. Eli jos sinä et ymmärrä, että jokaisen olemassa olevan liiketoiminnan prosessin voi mallintaa sovelluksella tai tietojärjestelmällä, ja suuri osa näistä on edelleen mallintamatta niin tämän paksummasta rautalangasta en osaa enkä jaksa asiaa vääntää. On katsos vähän muutakin hommaa tässä niiden puuttuvien liiketoimintasovellusten tekemisen kanssa.

M-Kar kirjoitti:

"Entäs sitten kun nakkikiska alkaa ottamaan tilauksia netin kautta?"

Sittenhän tuo nähdään tilauksista mitä on tehty. Ja netin kautta tilaukseen on softa. Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä.

"Sinäkö et siis ymmärrä mihin liiketoimintasovelluksia tarvitaan, tai miten IT:n avulla voidaan valvoa, raportoida ja optimoida liiketoimintaprosesseja?"

Toki ymmärrän mutta sinä et osannut kertoa PUUTTUVAA liiketoimintasovellusta. Ruoan tilaamiseen netin kautta on jo softa.

"Vai oletko jonkin asteinen AS-persoona tai autisti jolla on ongelmia tällaisessa tavallisessa sosiaalisessa kanssakäymisessä ja jolla on pakkomielle jotenkin vängätä vastaan kaikessa?"

Sinullahan ne ongelmat näkyy olevan kun yksinkertaiseen kysymykseen ei saa vastausta.

Jatkuvasti joku jankkaa että ohjelmissa on muka vikoja ja sitten kun kysyy miten vian voi toistaa niin ei vastausta. Ja jos ohjelmat on muka keskeneräisiä tai joku ohjelma puuttuu niin ei oikein siihenkään saa vastausta.

Tuossa rasvakeittimessä nyt oli vähän jotain yritystä mutta kyllä se nettitilaus on jo olemassa ja se rasvakeitin lähtee pois siitä napista silloin kun ei ole aktiviiteettia tilauksissa eikä ihmisiä kävelemässä nakkikiskan ympäristössä tai sitä kohti.

Lue lisää

"Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä."

Sinä et selkeästi ymmärrä koko liiketoiminta-aluetta. Ei ihmekään että et kykene hahmottamaan mistä tässä puhutaan. Liiketoimintasovelluksen sunnittelu alkaa siitä, että ymmärretään se prosessi jonka parissa toimitaan. Sinulta puuttuu nyt tämän sisäistäminen, mutta vouhotat silti vaahtopallo housuissa kuinka mitään sovellusta ei tarvita tai sellainen on jo.

Ja se, että ruoan tilaamiseen netin kautta on softa ei paljoa lohduta sellaista yritystä jolla ei sitä softaa vielä ole käytössä. Jonkun pitää se asentaa, konfiguroida ja integroida olemassa olevaan ICT infraan ja sovelluksiin joka ei puolestaan käytännössä eroa räätälöidyn ohjelmiston tekemisestä mitenkään muuten paitsi valmiina olevien komponenttien määrän ja hyödynnettävyyden pohjalta. Väitteesi on yhtälailla hölmö kuin että sanoisi webbikehityksen olevan täysin turhaa sillä Wordpress on jo olemassa. No, ei se tyhjä Wordpress-asennus ihan hirveästi pienyrittäjää vielä lämmitä, vaan jonkun pitää sinnekin se sisältö tehdä. Wordpress tai jokin toiminnanohjausjärjestelmä on ainoastaan se viitekehys jonka sisällä se kehitystyö tapahtuu. Ei se tee siitä kehitystyöstä yhtään sen vähänpätöisempää "puhtaaseen" koodaamiseen verrattuna.

dfsdfsdfasf kirjoitti:

"Rasvakeitin vaan päälle silloin kun on tiedossa aktiviteettia ja jos ei tilauksia tulossa eikä asiakkaita ole tulossa nakkikiskalle päin niin sitten napsauttaa sen rasvakeittimen pois päältä."

Sinä et selkeästi ymmärrä koko liiketoiminta-aluetta. Ei ihmekään että et kykene hahmottamaan mistä tässä puhutaan. Liiketoimintasovelluksen sunnittelu alkaa siitä, että ymmärretään se prosessi jonka parissa toimitaan. Sinulta puuttuu nyt tämän sisäistäminen, mutta vouhotat silti vaahtopallo housuissa kuinka mitään sovellusta ei tarvita tai sellainen on jo.

Ja se, että ruoan tilaamiseen netin kautta on softa ei paljoa lohduta sellaista yritystä jolla ei sitä softaa vielä ole käytössä. Jonkun pitää se asentaa, konfiguroida ja integroida olemassa olevaan ICT infraan ja sovelluksiin joka ei puolestaan käytännössä eroa räätälöidyn ohjelmiston tekemisestä mitenkään muuten paitsi valmiina olevien komponenttien määrän ja hyödynnettävyyden pohjalta. Väitteesi on yhtälailla hölmö kuin että sanoisi webbikehityksen olevan täysin turhaa sillä Wordpress on jo olemassa. No, ei se tyhjä Wordpress-asennus ihan hirveästi pienyrittäjää vielä lämmitä, vaan jonkun pitää sinnekin se sisältö tehdä. Wordpress tai jokin toiminnanohjausjärjestelmä on ainoastaan se viitekehys jonka sisällä se kehitystyö tapahtuu. Ei se tee siitä kehitystyöstä yhtään sen vähänpätöisempää "puhtaaseen" koodaamiseen verrattuna.

Lue lisää

"Jos sinulla on 100 tilausta ranskalaisista, 80 nugetti-tilausta ja 20 kalapihviä, niin eipä tuo nyt täysin triviaalia ole miettiä missä järjestyksessä ne tilaukset ovat tulleet, kuinka paljon mitäkin tavaraa voidaan kerralla keittimeen laittaa ilman että lämmöt laskee liikaa, kuinka lisätyt tuotteet vaikuttavat jo keittimessä olevien paistoaikaan, miten varmistaa että yhden tilauksen tuotteet valmistuvat tietyn aikaikkunan sisällä että osa ei ole jo toimitettaessa kylmää."

Eiköhän se keitin ole sit kokoajan päällä jos on jatkuvaa käyttöä.

Oletan nyt, että keittimessä on joko on/off tai säädetään aikaa tai joku rele mikä napsahtaa pois kun ollut tarpeeksi pitkään lämmöt tapissa ja on vaikka joku ylläpitolämpö ja nappi millä voi kuumentaa. Että mitkä ne keittimen ominaisuudet nyt sitten on? En ole ollut nakkikiskassa töissä että en tiedä rasvakeittimen käyttöliittymää.

Kun puhutaan siitä softasta niin sehän tehdään sen keittimen käyttöliittymän ehdoilla mitä se käyttäjä tekee tai muuten tässä on kyse muustakin kuin softasta.

"Samoin öljyn käyttömäärää pitää pystyä seuraamaan, suunnitella suodatukset, vaihtovälit, seurata ja logittaa lämpötiloja."

Tuohon nyt ei tarvitse välttämättä mitään erityistä softaa kun kirjanpidosta saadaan tilaukset niin siitä voidaan laskea paljon öljyä tarvitsee kuluttaa kuukautta kohti. Ymmärtääkseni se ei voi olla liian moneen kertaa käytettyä että tilausmäärästä selviää monta kertaa kuukaudessa pitää vaihtaa.

"Eli jos sinä et ymmärrä, että jokaisen olemassa olevan liiketoiminnan prosessin voi mallintaa sovelluksella tai tietojärjestelmällä"

Tiedän toki että voi mallintaa mutta sen sovellukseksi mallinnuksen pitää hyödyttää ja lopputuloksen pitää tuoda lisäarvoa siihen taulukkolaskentaohjelmaan nähden.

Katsos kun tässä on niitäkin juttuja, jos ylisuunnittelee jonkun liiketoimintaprosessin niin siitä tulee vähän jäykkä ja hankalammin muutettavissa ja toisekseen se voi tarvita omaksumista käyttäjältä mitä taas pitäisi välttää. Kaikki osaa käyttää vasaraa mutta jos joka työpaikassa on oma avaruusasema niin se tuo tarpeetonta käyttökynnystä.

"ja suuri osa näistä on edelleen mallintamatta"

Jos prosessia ei ole edes mallinnettu niin silloin ei tarvitse sovellustakaan. Ensiksi pitää homma olla mallinnettu taulukkolaskentaohjelmalla, että joka kuukausi vaikka tuo kirjanpidosta .csv:n ja laskee halutut asiat ja pyörittelee sillä ja jos sillä saa hommaa jotenkin parannettua (eli saisi joka kuukausi jossain säästöä) ilman että olennaisesti tarvitsee työntekijää kuormittaa niin sen manuaalisen nysvän voi korvata kätevällä sovelluksella.

Minä kyllä väittäisin että nakkikioskissa on prosessi mallinnettu, että keitin napsautetaan päälle kun on tiedossa, että sen pitää olla parissa minuutissa kuuma ja on tietty vaihtoväli sille öljylle ja kuuluu prosessiin ja prosessi voi olla vaikka seinällä muistiin kirjoitettuna mitä toimenpiteitä tehdään päivän päätteeksi.

Se että puuttuuko tästä jotain olennaista sovellusta, että millä tavalla sovellus tuo lisäarvoa niin et nyt osannut sellaista sanoa vaan arvailet, että jotain lämpötilaa voisi mitata mutta mallinnuskin sitten puuttuu. Että kerrohan nyt mistä niitä mallinnuksia revit mistä sovellukset muka puuttuu?

"Ja se, että ruoan tilaamiseen netin kautta on softa ei paljoa lohduta sellaista yritystä jolla ei sitä softaa vielä ole käytössä."

Saahan sen otettua käyttöön. Tekee vaan sopparin softan tarjoajan kanssa ja maksetaan vähän rahaa.

"Jonkun pitää se asentaa, konfiguroida ja integroida olemassa olevaan ICT infraan"

Softa on yleensä softatoimittajan palvelimella, SaaSsiahan nuo ruokatilaukset on. Siellä sitten webserviceä ja näitä konffauksia sitten tekee softan toimittaja kun ostaa sen tilausjärjestelmän.

"No, ei se tyhjä Wordpress-asennus ihan hirveästi pienyrittäjää vielä lämmitä, vaan jonkun pitää sinnekin se sisältö tehdä. Wordpress tai jokin toiminnanohjausjärjestelmä on ainoastaan se viitekehys jonka sisällä se kehitystyö tapahtuu. Ei se tee siitä kehitystyöstä yhtään sen vähänpätöisempää "puhtaaseen" koodaamiseen verrattuna. "

No ei tässä nyt mistään räätälöinnistä ole ollut kysekään vaan siitä että puuttuuko jotain softaa. Jos jossain on tarve jollekin liiketoimintasovellukselle, eli on mallinnettuna tarve ja olkoot se vaikka Wordpress niin sehän on tehty jo.

Niitä puuttuvia sovelluksia ei oikein ole. Siis aidosti puuttuvia. Arvaukset siitä, että jotain voidaan mitata ei vielä tee tarvetta sovellukselle vaan se että toiminta on mallinnettu ja tiedetään joku typerä, manuaalinen toistuva työvaihe (jotain kirjataan paperiin tai taulukkolaskimeen) jollain toimialalla (kaikki nakkikioskit vaikka) jonka softa voi korvata ja säästää sitten jonkun työaikaa tunnin päivässä vaikka.

Hyvä esimerkki sovellustarpeesta oli vaikka se taulukkolaskin silloin 70-luvulla, että ennen yrittäjät pyöritteli näitä ruutupaperilla ja aina kun muutti numeroa niin paperi laskettiin käsin uusiksi. Taulukkolaskin poisti sen manuaalisen vaiheen.

"Mitä sitä turhaan kehittelemään kun kaikki on aivan valmista jo."

Jokatapauksessa tämä on pötypuhetta, enpä olisi töissä alalla jos kaikki olisi jo tehty tai pari naksun päässä palikoilla toteutettavissa =)

M-Kar kirjoitti:

Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.

Lue lisää

'''''''''Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta''''''''''

Täällä ei ole ketään niin tyhmää että rupeaa sairaan mutuilijan lässytyksiä todistelemaan puoleen eikä toiseen.

yjtfujkyfukyf kirjoitti:

'''''''''Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta''''''''''

Täällä ei ole ketään niin tyhmää että rupeaa sairaan mutuilijan lässytyksiä todistelemaan puoleen eikä toiseen.

Lue lisää

Jos olisin väärässä niin se on helppo osoittaa koska kaikki mitä sanon, on todistettavissa oikeaksi tai vääräksi. Jos ei kykene todistamaan vääräksi niin havaintojen perusteella olisin oikeassa.

M-Kar kirjoitti:

Jos olisin väärässä niin se on helppo osoittaa koska kaikki mitä sanon, on todistettavissa oikeaksi tai vääräksi. Jos ei kykene todistamaan vääräksi niin havaintojen perusteella olisin oikeassa.

Lue lisää

''''''''''havaintojen perusteella olisin oikeassa''''''''
Minä muistan joskus kuulleeni armottomasta juoposta, hän myös teki havaintoja, ja oli tietysti aivan oikeassa omasta mielestään.

Tään juopon havainnot, oli pikku-ukkoja, joita hän välillä pyyhkäsi kädellään pöydän reunalta lattialle. Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä.

rset6yhtr7ur67yik7t kirjoitti:

''''''''''havaintojen perusteella olisin oikeassa''''''''
Minä muistan joskus kuulleeni armottomasta juoposta, hän myös teki havaintoja, ja oli tietysti aivan oikeassa omasta mielestään.

Tään juopon havainnot, oli pikku-ukkoja, joita hän välillä pyyhkäsi kädellään pöydän reunalta lattialle. Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä.

Lue lisää

"Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä."

Se sinun juopposi katsos näki olemattomia asioita. Niin vissiin sinäkin kun näet olemattomia havaintoja.

Minä taas seuraan tätä ketjua mitä tässä on sanottu ja jos on jotain negaativista länkytystä ilman todistetta, tai väittämää ei ole mahdollista todistaa oikeaksi tai vääräksi niin ainoat havainnot ovat ne mitä jää jäljelle. Esimerkiksi se mitä minä sanon.

rset6yhtr7ur67yik7t kirjoitti:

''''''''''havaintojen perusteella olisin oikeassa''''''''
Minä muistan joskus kuulleeni armottomasta juoposta, hän myös teki havaintoja, ja oli tietysti aivan oikeassa omasta mielestään.

Tään juopon havainnot, oli pikku-ukkoja, joita hän välillä pyyhkäsi kädellään pöydän reunalta lattialle. Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä.

Lue lisää

Väännetään asia varmuuden vuoksi rautalangasta...

Jos minä sanon jonkun mielipiteen, täysin vapaasti todistettavissa vääräksi tai oikeaksi, usein vieläpä kerron mihin asian perustan niin jos sinä alat siitä lässyttää ja alat esittämään jotain negatiivisia väittämiä esim. joistakin yrityksistä, tuotteista tai minusta etkä esitä mitään todistetta niin sehän tarkoittaa sitä, että sinun lässytyksesi epäonnistui kumoamana alkuperäistä väittämää ja se siis on kestänyt muiden ihmisten tarkastelun ja kritisoinnin voittajana.

Minun mielipide voi siis myös jäädä ainoaksi havainnoksi jos kukaan ei kykene esittämään vaihtoehtoisia mielipiteitä tai todistamaan väittämiä.

Tällä tavalla siitä asiasta tulee tietysti vähitellen se hyväksytty totuus, kuten kävi vaikka evoluutioteorialle. Kaikennäköiset hihhulit ovat yrittäneet kumota sitä ja lässyttäneet vastaan mutta epäonnistuneet.

Taidat vissiin olla sitä raamattu -väkeä kun asioita ei tarvitse mitenkään todistaa vaan voi uskoa höpönpöppöön?

M-Kar kirjoitti:

"Turha sinulle niin kuin tuolle armottomalle juopollekkaan oli mennä kertomaan että havainnot on vääriä."

Se sinun juopposi katsos näki olemattomia asioita. Niin vissiin sinäkin kun näet olemattomia havaintoja.

Minä taas seuraan tätä ketjua mitä tässä on sanottu ja jos on jotain negaativista länkytystä ilman todistetta, tai väittämää ei ole mahdollista todistaa oikeaksi tai vääräksi niin ainoat havainnot ovat ne mitä jää jäljelle. Esimerkiksi se mitä minä sanon.

Lue lisää

Noin se juoppukin sanoi

t6jy6rfkuy kirjoitti:

Noin se juoppukin sanoi

Juurihan sanoit, että juoppo havaitsi olemattomia pikku-ukkoja.

Minä en havaitse olemattomia asioita.

M-Kar kirjoitti:

Juurihan sanoit, että juoppo havaitsi olemattomia pikku-ukkoja.

Minä en havaitse olemattomia asioita.

Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa.

t78ikt78o76to kirjoitti:

Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa.

"Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa."

Sinähän niitä vaihtoehtoisia mielipiteitä näit havaittavissa. Missä?

M-Kar kirjoitti:

"Niin niin, juopponkaan mielestä ei pikku-ukot olleet olemattomia, ja sinun mielestä havainnot ei ole olemattomia, kummallisen paljon samakaltaisuutta teissä molemissa."

Sinähän niitä vaihtoehtoisia mielipiteitä näit havaittavissa. Missä?

Lue lisää

Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita. Samalla tavalla se juoppo teki niitä omia havaintoja, jotka ei oleet kenenkään muun mielestä oikeita.

u9ioly89p8y9p kirjoitti:

Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita. Samalla tavalla se juoppo teki niitä omia havaintoja, jotka ei oleet kenenkään muun mielestä oikeita.

Lue lisää

"Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita."

Tein havainnot mielipiteistä mitä löytyi. Oli kaksi havaintoa. Minun mielipiteeni sekä toinen "C ja C on huonoa" mikä osoittautui virheelliseksi.

Jäljelle jäi siis havainto joka oli minun mielipiteeni. Selvästikin se havainto löytyy kun itse juuri jankkaat minun mielipiteestäni.

On myös täysi syy pitää mielipiteeni olevan oikeassa kun sitä ei ole onnistuttu todistamaan vääräksi. Tämä minun mielipiteeni on siis se havainto joka ei ole mikään mielikuvituksen tuote.

"jotka ei oleet kenenkään muun mielestä oikeita."

Jos on olevinaan väärin niin pitäisi todistaa se. Jos ei onnistu vaikka virheellinen väite on helposti todistettavissa vääräksi niin silloinhan havaintojen perusteella näyttäisi pitävän paikkansa.

Epäonnistuneet yritykset kumota mielipidettäni ovat myös havaintoja sen puolesta, että olen oikeassa.

M-Kar kirjoitti:

"Älähän nyt käännä asiaa päälaelleen, vain sinä sanoit tehneesi havaintoja joiden mukaan vain sinun hyväksymät mielipitee on oikeita."

Tein havainnot mielipiteistä mitä löytyi. Oli kaksi havaintoa. Minun mielipiteeni sekä toinen "C ja C on huonoa" mikä osoittautui virheelliseksi.

Jäljelle jäi siis havainto joka oli minun mielipiteeni. Selvästikin se havainto löytyy kun itse juuri jankkaat minun mielipiteestäni.

On myös täysi syy pitää mielipiteeni olevan oikeassa kun sitä ei ole onnistuttu todistamaan vääräksi. Tämä minun mielipiteeni on siis se havainto joka ei ole mikään mielikuvituksen tuote.

"jotka ei oleet kenenkään muun mielestä oikeita."

Jos on olevinaan väärin niin pitäisi todistaa se. Jos ei onnistu vaikka virheellinen väite on helposti todistettavissa vääräksi niin silloinhan havaintojen perusteella näyttäisi pitävän paikkansa.

Epäonnistuneet yritykset kumota mielipidettäni ovat myös havaintoja sen puolesta, että olen oikeassa.

Lue lisää

Taas teet niitä ihme havaintoja, ja pultsari huitoo pikku-ukkoja pöydän reunalta.

t789o8796 kirjoitti:

Taas teet niitä ihme havaintoja, ja pultsari huitoo pikku-ukkoja pöydän reunalta.

Teithän sinäkin sen havainnon. Et muuten kirjoittaisi niistä mielipiteistä.

Minun mielipide löytyy, sinulta ei löydy.

M-Kar kirjoitti:

Teithän sinäkin sen havainnon. Et muuten kirjoittaisi niistä mielipiteistä.

Minun mielipide löytyy, sinulta ei löydy.

Lueppa nyt ihan ajatuksen kanssa, mitä kirjoitit.

ed65ur6iur67i kirjoitti:

Lueppa nyt ihan ajatuksen kanssa, mitä kirjoitit.

Luin. Tässä ketjussa on esitetty kaksi mielipidettä. Toinen ei kestänyt argumentointia ja toinen kesti.

Jäljelle jäi siis yksi mielipide jonka sinä havaitset (havainto) koska kirjoitat asiasta viestejä ja samoin minä (havainto).

Sitten puhut jostain uusista havainnoista, mistä? Kuka on ja mitä mieltä? Nämä sinun uudet havainnot on niitä juopon tonttuja koska kukaan muu ei niitä havaitse.

M-Kar kirjoitti:

Luin. Tässä ketjussa on esitetty kaksi mielipidettä. Toinen ei kestänyt argumentointia ja toinen kesti.

Jäljelle jäi siis yksi mielipide jonka sinä havaitset (havainto) koska kirjoitat asiasta viestejä ja samoin minä (havainto).

Sitten puhut jostain uusista havainnoista, mistä? Kuka on ja mitä mieltä? Nämä sinun uudet havainnot on niitä juopon tonttuja koska kukaan muu ei niitä havaitse.

Lue lisää

Viittasin "tässä ketjussa" noilla kahdella mielipiteellä ylemmässä ketjussa olevaa argumentointia C:n ja C :n "huonoudesta".

M-Kar kirjoitti:

Viittasin "tässä ketjussa" noilla kahdella mielipiteellä ylemmässä ketjussa olevaa argumentointia C:n ja C :n "huonoudesta".

Ei se riitä että lukee, pitää myös ymmärtää lukemansa, joten lueppa uudestaan

t678o6968tttyo9 kirjoitti:

Ei se riitä että lukee, pitää myös ymmärtää lukemansa, joten lueppa uudestaan

Sitä ennen voisit nyt kertoa niistä muista mielipiteistä. Yrität kokoajan siirtää keskustelua pois siitä olennaisesta asiasta, että voidaan osoittaa että sinulla oli niitä juopon harhoja.

M-Kar kirjoitti:

Sitä ennen voisit nyt kertoa niistä muista mielipiteistä. Yrität kokoajan siirtää keskustelua pois siitä olennaisesta asiasta, että voidaan osoittaa että sinulla oli niitä juopon harhoja.

Lue lisää

No hyvä on, pyydä että joku, (ellei äiti jouda) lukee ne sinulle.

e56u76r7i677rt5 kirjoitti:

No hyvä on, pyydä että joku, (ellei äiti jouda) lukee ne sinulle.

Ei kukaan muu ole havainnut mitään juopon harhoja, nehän oli vain sinulla.

Todistat juuri sitä kun et kykene osoittamaan tästä ketjusta niitä muita mielipiteitä C tai C :sta, eli ei ole niitä siitä sinun keksimiäsi muita havaintoja.

M-Kar kirjoitti:

Totta tuokin. Hirveä itkuvalistus ohjelmista mutta kyselin sitten että miten sen ongelman voi toistaa niin ei vastausta. Sitten kun väitettiin keskeneräiseksi ohjelmia niin kysyin, että mitäs tästä maailmasta nyt sitten niinkuin oikeasti puuttuu niin en saanut siihenkään vastausta.

Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa.

Lue lisää

"Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa."

Niin. Mielestäsi siis OpenSSL:n vuoden 2014 alussa olleessa versiossakaan ei ollut mitään vikaa.

Sehän oli koodattu C:llä, kehumallasi systeemiohjelmointikielellä.

Mutta niin vaan iskivät rikolliset turva-aukkoon !

Vetoat tietysti siihen, että "virhe on jo korjattu".

1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin).

2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen? Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?

On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)

Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia
tietoturva-aukkoja, joihin rikollisten on helppoa iskeä.

Ja samaan aikaan Objectpascalilla koodattuja systeemikirjastoja (jollainen esim. olisi Objectpascalilla koodattu versio SSL -salauskirjastosta, ilman ensimmäistäkään tietoturva-aukkoa) eivät siis linuxjakelujen johtajat halua hyväksyä osaksi jakeluaan.

JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua.

linuxjakelut_sucks kirjoitti:

"Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa."

Niin. Mielestäsi siis OpenSSL:n vuoden 2014 alussa olleessa versiossakaan ei ollut mitään vikaa.

Sehän oli koodattu C:llä, kehumallasi systeemiohjelmointikielellä.

Mutta niin vaan iskivät rikolliset turva-aukkoon !

Vetoat tietysti siihen, että "virhe on jo korjattu".

1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin).

2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen? Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?

On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)

Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia
tietoturva-aukkoja, joihin rikollisten on helppoa iskeä.

Ja samaan aikaan Objectpascalilla koodattuja systeemikirjastoja (jollainen esim. olisi Objectpascalilla koodattu versio SSL -salauskirjastosta, ilman ensimmäistäkään tietoturva-aukkoa) eivät siis linuxjakelujen johtajat halua hyväksyä osaksi jakeluaan.

JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua.

Lue lisää

Toisaalta: jos M-Kar on tässä oikeassa, tämä herättää uuden kysymyksen...

Jos onnistun etsimään ja löytämään OpenSSL:stä uuden, julkisesti tuntemattoman tietoturva-aukon, mistä löydän eniten rahaa tarjoavan rikollisen, jolle myydä tiedot ko. tietoturva-aukosta ?

Ainahan voisi koodata Objectpascalilla korvaajan OpenSSL:lle, ja myydä sitä.

Kun sen koodaa alusta alkaen itse käyttämättä GPL -lisensioitua kirjastoa, silloinhan sen käyttölisenssejä voi myydä ja omistaa tekijänoikeudet edelleen itse.

Kertoisi vaan julkisesti, että jos tietoturvasi on sinulle oikeasti tärkeä, niin osta lisenssi ja asenna korvaaja linuxjakelun alkuperäisen OpenSSL:n korvaajaksi.

Jokainen voi itse valita, ostaako lisenssin vai jatkaako turvaallisuudeltaan heikon OpenSSL:n käyttöä.

Veikkaanpa, että jos jaksaisi tosissaan etsiä, niin OpenSSL:stä löytyy vielä monta tähän mennessä (ainakin suurelle yleisölle) tuntematonta tietoturva-aukkoa lisää.

Tosin, ainakin osa näistä tietoturva-aukoista voivat olla jo esim NSA:n tiedossa.

Eiköhän tuollainen valtiollisen tason toimija, jolla on jättibudjetti, voi palkata hyvät osaajat etsimään tietoturva-aukkoja, joita NSA voi sitten hyödyntää omiin tarkoituksiinsa.
Eiväthän he löytämiään aukkoja julkisesti kerro.
Veikkaanpa muuten, että NSA on tiennyt siitä samasta tietoturva-aukosta, joka OpenSSL:n osalta tuli julkisuuteen keväällä 2014, jo paljon aikaisemmin.

He vain ovat salaa hyödyntäneet ko. aukkoa omiin tarkoituksiinsa, ja siksi tieto ei ole sitä kautta levinnyt.

Miksiköhän muuten linuxjakelujen tekijät eivät halua laadukasta, Objectpascalilla koodattua ohjelmakoodia heikkolaatuisen ja turvattoman C:llä tehdyn koodin sijasta ? (edellyttäen, että M-Karin asiaa koskeva väite pitää paikkansa)

Muuttuisiko tilanne, jos joku etsisi useita turva-aukkoja linuxjakeluista ja myisi tiedot kustakin aukosta eniten tarjoavalle rikolliselle ?

Itse olen vakuuttunut siitä, että useimmista, ellei peräti kaikista sellaisista ohjelmista ja ohjelmakirjastoista, jotka on koodattu joko C:llä, C :lla, tai näiden yhdistelmällä, löytyy tietoturva-aukkoja, kustakin yksi tai useampi.

Mutta jatkakaa vaan linux- ja GPL -lisenssifanaatikot sitä C:llä koodailua M-Karin ja tietoverkkomurtoja tekevien iloksi.

linuxjakelut_sucks kirjoitti:

"Tämän hetkisten havaintojen perusteella tietokoneohjelmat ovat valmiita eikä niissä ole mitään olennaista vikaa."

Niin. Mielestäsi siis OpenSSL:n vuoden 2014 alussa olleessa versiossakaan ei ollut mitään vikaa.

Sehän oli koodattu C:llä, kehumallasi systeemiohjelmointikielellä.

Mutta niin vaan iskivät rikolliset turva-aukkoon !

Vetoat tietysti siihen, että "virhe on jo korjattu".

1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin).

2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen? Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?

On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)

Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia
tietoturva-aukkoja, joihin rikollisten on helppoa iskeä.

Ja samaan aikaan Objectpascalilla koodattuja systeemikirjastoja (jollainen esim. olisi Objectpascalilla koodattu versio SSL -salauskirjastosta, ilman ensimmäistäkään tietoturva-aukkoa) eivät siis linuxjakelujen johtajat halua hyväksyä osaksi jakeluaan.

JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua.

Lue lisää

"1. Jos OpenSSL olisi koodattu Objectpascalilla, tuollaista virhettä ei olisi alunperinkään ollut olemassa. Se, että se ei jonkun linuxjakelun kokoajalle olisi kelvannut, kun se olisi ollut "väärällä välineellä koodattu" - siis se olisi uudelleenkirjoitettu C:llä (ja saatu aikaiseksi juuri sama turva-aukko, joka siitä sitten 2014 keväällä löytyikin)."

Kyllä se tarve on enemmän ollut BSD järjestelmissä, että ei oteta GPL koodia mukaan tai sitten suljetuissa järjestelmissä jotka hyödyntävät juurikin BSD koodia.

"2. Entä, kun C:llä, suurella ja mahtavalla systeemiohjelmointikielellä koodatusta OpenSSL:stä löytyy seuraava turva-aukko, ja rikolliset iskevät sitten siihen?"

Tuollaiset virheet löytyvät tavallisesti koodista joissa ei ole laatuprosesseja ollut olemassa kun tekeminen on aloitettu. Niiden käyttäminen jälkikäteen on hankalampaa.

"Sinun mielestäsi, M-Kar, C on varmaan senkin jälkeen oikein hyvä systeemiohjelmointikieli, ei siis haittaa yhtään, että C -kielellä saadaan aikaiseksi massiivisia tietoturva-aukkoja?"

Kyllä työkaluja voi käyttää väärin. Mutta onhan juurikin C-kiellä mahdollista tehdä ne huipputurvalliset sovellukset

"On suuri vahinko, että linuxjakelujen johtajina on henkilöitä, joiden ajatustenjuoksu on yhtä pahasti pielessä kuin M-Karilla. (edellyttäen, että M-Karin edellä esittämät johtopäätökset ovat oikeita, ovatko ne ???)"

Miten tämä nyt liittyy Linuxiin?

"Siis C -kieltä on vaan pakko käyttää, vaikka on tunnettua, että C -kielen typerä rakenne suorastaa houkuttelee koodaajia tekemään sellaisia virheitä, että syntyy juurikin sellaisia tietoturva-aukkoja, joihin rikollisten on helppoa iskeä."

Saat vapaasti kirjoittaa uuden kernelin ja systeemitason sovellukset uudella sertifioidulla työkalulla, aloittaa siis kaikki ihan alusta, kääntäjä mukaanlukien ja kääntäjät perusteellisesti testit.

Tällä hetkellä kiinnostukset ja resurssit tuollaiseen taitaa olla vain Googlella.

"JOS M-Kar on oikeassa tuossa, että "ei olisi hyväksytty", niin silloinhan linuxjakelujen johtajat puuhaavat varsinaista hölmöläisten touhua."

Ei tämä liity millään tavalla Linuxiin. Ei se minun vikani ole, että FreePascal on standardoimaton, sertifioimaton ja lisäksi vielä GPL koodia. Kyllä sitä käytetään sellaisia komponentteja mitkä on lisenssiyhteensopivia, harmonisia muun koodin kanssa ja jossa ei tule mitään typerää rajoitetta pitkällä aikavälillä.

Linux_Hölmölä_alas kirjoitti:

Toisaalta: jos M-Kar on tässä oikeassa, tämä herättää uuden kysymyksen...

Jos onnistun etsimään ja löytämään OpenSSL:stä uuden, julkisesti tuntemattoman tietoturva-aukon, mistä löydän eniten rahaa tarjoavan rikollisen, jolle myydä tiedot ko. tietoturva-aukosta ?

Ainahan voisi koodata Objectpascalilla korvaajan OpenSSL:lle, ja myydä sitä.

Kun sen koodaa alusta alkaen itse käyttämättä GPL -lisensioitua kirjastoa, silloinhan sen käyttölisenssejä voi myydä ja omistaa tekijänoikeudet edelleen itse.

Kertoisi vaan julkisesti, että jos tietoturvasi on sinulle oikeasti tärkeä, niin osta lisenssi ja asenna korvaaja linuxjakelun alkuperäisen OpenSSL:n korvaajaksi.

Jokainen voi itse valita, ostaako lisenssin vai jatkaako turvaallisuudeltaan heikon OpenSSL:n käyttöä.

Veikkaanpa, että jos jaksaisi tosissaan etsiä, niin OpenSSL:stä löytyy vielä monta tähän mennessä (ainakin suurelle yleisölle) tuntematonta tietoturva-aukkoa lisää.

Tosin, ainakin osa näistä tietoturva-aukoista voivat olla jo esim NSA:n tiedossa.

Eiköhän tuollainen valtiollisen tason toimija, jolla on jättibudjetti, voi palkata hyvät osaajat etsimään tietoturva-aukkoja, joita NSA voi sitten hyödyntää omiin tarkoituksiinsa.
Eiväthän he löytämiään aukkoja julkisesti kerro.
Veikkaanpa muuten, että NSA on tiennyt siitä samasta tietoturva-aukosta, joka OpenSSL:n osalta tuli julkisuuteen keväällä 2014, jo paljon aikaisemmin.

He vain ovat salaa hyödyntäneet ko. aukkoa omiin tarkoituksiinsa, ja siksi tieto ei ole sitä kautta levinnyt.

Miksiköhän muuten linuxjakelujen tekijät eivät halua laadukasta, Objectpascalilla koodattua ohjelmakoodia heikkolaatuisen ja turvattoman C:llä tehdyn koodin sijasta ? (edellyttäen, että M-Karin asiaa koskeva väite pitää paikkansa)

Muuttuisiko tilanne, jos joku etsisi useita turva-aukkoja linuxjakeluista ja myisi tiedot kustakin aukosta eniten tarjoavalle rikolliselle ?

Itse olen vakuuttunut siitä, että useimmista, ellei peräti kaikista sellaisista ohjelmista ja ohjelmakirjastoista, jotka on koodattu joko C:llä, C :lla, tai näiden yhdistelmällä, löytyy tietoturva-aukkoja, kustakin yksi tai useampi.

Mutta jatkakaa vaan linux- ja GPL -lisenssifanaatikot sitä C:llä koodailua M-Karin ja tietoverkkomurtoja tekevien iloksi.

Lue lisää

"Jos onnistun etsimään ja löytämään OpenSSL:stä uuden, julkisesti tuntemattoman tietoturva-aukon, mistä löydän eniten rahaa tarjoavan rikollisen, jolle myydä tiedot ko. tietoturva-aukosta ?"

Miksi se rikolliselle pitäisi myydä kun varmaan löytyy muutama firma mikä maksaisi siitä.

"Ainahan voisi koodata Objectpascalilla korvaajan OpenSSL:lle, ja myydä sitä."

Ei kukaan ostaisi.

"Kun sen koodaa alusta alkaen itse käyttämättä GPL -lisensioitua kirjastoa, silloinhan sen käyttölisenssejä voi myydä ja omistaa tekijänoikeudet edelleen itse."

FreePascal kääntäjä on GPL lisensoitu. Tuo tarvisi FreePascalin lisäämistä käyttöjärjestelmän buildaukseen itsessään ja toisi GPL koodia sinne saastuttamaan.

Sinun tarvitsisi ensiksi tehdä uusi BSD lisensoitu kääntäjä ja saman tien kirjoittaa uusiksi kaikki userlandin palikat uusiksi BSD lisenssillä.

Mutta sitten herää mieleen että miksi? Miksi ei samantien tekisi tätä Go compilerilla joka on jo BSD lisensoitu?

"Veikkaanpa, että jos jaksaisi tosissaan etsiä, niin OpenSSL:stä löytyy vielä monta tähän mennessä (ainakin suurelle yleisölle) tuntematonta tietoturva-aukkoa lisää."

Niinhän niitä löytyi ja korjattiin myös. Siitä myös sitten tehtiin semmoinen turvallinen palikka myös: https://www.libressl.org/

Tosin, ainakin osa näistä tietoturva-aukoista voivat olla jo esim NSA:n tiedossa.

"Miksiköhän muuten linuxjakelujen tekijät eivät halua laadukasta, Objectpascalilla koodattua ohjelmakoodia heikkolaatuisen ja turvattoman C:llä tehdyn koodin sijasta ?"

Tuohan riippuu käyttöjärjestelmästä. Eri käyttöjärjestelmävalmistat vakioi eri tekniikkaan. Microsoft menee C#:n ja siellä sitten C on legacyä ja C on matalalla tasolla, Apple menee Swiftiin, ObjectiveC on legacyä ja C:tä matalalla tasolla. Red Hatissa C matalalla tasolla mutta rakentavat kaiken middlewaren Javalla. Oracle tekee samoin. Ubuntussa matalataso on C:tä ja muuten tätä tunnutaan käyttävän monilla kielillä. Debianissa sama juttu .

OpenBSD:ssä sitten päättivät siivota kaiken muun paitsi C:n ja sh skriptit pois.

Debianissa ja Ubuntussa vähän avoimempaa se vastaanotto erilaisille softapinoille ja hyväksyvät helpommin eri välineillä tehtyä koodia.

Semmoista ObjectPascal koodia on kovin vähän vain. Kukaan ei tee semmoista eikä ketään oikein kiinnosta. Parempiakin työkaluja on.

Voisin kuvitella että jos uudelleenkirjoitat matalan tason kompontit vaikka Go langilla siistimmin mitä nykyiset, 70-luvulta saakka kehityt palikat on ja saisit määriteltyä ABI yhteensopivuuden niin voisi jotain kiinnostaa.

Se tuskin kiinnostaa jos tuot vain ylimääräistä tekniikkaa sinne etkä esim. poista samalla C-kääntäjää userlandin käännöstä. Tuohan olisi kätevää kun kerneli käännettäisiin C:llä ja userland olisi sitten uusittu C:stä vapaaksi niin se voisi olla parannus, ehkä.

"Itse olen vakuuttunut siitä, että useimmista, ellei peräti kaikista sellaisista ohjelmista ja ohjelmakirjastoista, jotka on koodattu joko C:llä, C :lla, tai näiden yhdistelmällä, löytyy tietoturva-aukkoja, kustakin yksi tai useampi."

Varmasti näin olikin 90-luvulla. Nythän nuo keskeiset komponentit ovat aika huolella nuoltu bugeista, että harvemmin löytyy. Esim. zlibistä löytyi edellisen kerran 12v sitten.

sudo apt-get install .... piti olla äh kun ei voi muokata jälkikäteen