Taas on Delphi myyty!

FireMonkey oli alunperin eräs pascal kirjasto OpenGL:lle joka sitten myytiin Embarcaderolle (niin kuin Delphikin)

Borland ihan itse sössi sen Delphin, ei sen muuten olisi sitä tarvinnut myydä.

Olisi Borland kehittänyt Lazaruksen suuntaan ja inhimillisin hinnoin, mutta tuo embarcadero alkoi puskemaan "uusia" versioita jopa 2 kertaa vuodessa, bugit jätti korjaamatta ja korjauspäivityksistä sai vain unelmoida. Mitä järkee semmoista työkalua on hankkia joka vanhenee heti käsiin bugisena pökäleenä ja on vielä kalliskin kuin prkele.

ex-delphisti kirjoitti:

Olisi Borland kehittänyt Lazaruksen suuntaan ja inhimillisin hinnoin, mutta tuo embarcadero alkoi puskemaan "uusia" versioita jopa 2 kertaa vuodessa, bugit jätti korjaamatta ja korjauspäivityksistä sai vain unelmoida. Mitä järkee semmoista työkalua on hankkia joka vanhenee heti käsiin bugisena pökäleenä ja on vielä kalliskin kuin prkele.

Lue lisää

Ei siinä pari kertaa vuodessa tehtävässä julkaisussa mitään ongelmaa ole. Ihan normaalia upstreamissa, kehittäjien leluissa että on uusin tekniikka niin halutessaan. Bugeja on mutta ei niistä silloin tietenkään mitään makseta.

Sitten kun halutaan vakautta ja projekti on mennyt siitä alkuvaiheen muovattavasta tilasta raskasliikkeisemmäksi, mennään sitten isommissa julkaisuissa.

Embarcadero osti mielummin FireMonkeyn kuin olisi sijoittanut rahaa QT:n ympärille. He siis näkivät että FireMonkey olisi parempi.

Kylix perustui nimenomaan QT:n. Tosin tällöin QT oli vielä norjalaisomistuksessa. QT:n tuki oli silloin surkeaa. Todennäköisesti nykyinen omistaja ei ylläpidä enään kyseistä QT:n versiota.

QTkinVanhenee kirjoitti:

Kylix perustui nimenomaan QT:n. Tosin tällöin QT oli vielä norjalaisomistuksessa. QT:n tuki oli silloin surkeaa. Todennäköisesti nykyinen omistaja ei ylläpidä enään kyseistä QT:n versiota.

Lue lisää

"Kylix perustui nimenomaan QT:n."

Niin siis Delphin rajapinta oli VCL joka oli lähinnä wrapperi Win32:lle. Kylixissä sitten otettiin rajapinnaksi CLX joka oli joku wrapperi Qt:lle.

Eli siis Delphillä kun teki softaa niin ei sitten toiminut Kylixissä ja päin vastoin. Virhe oli tehty jo aiemmin kun VCL oli niin tiukasti naimisissa Win32:n kanssa ja Borland ei ymmärtänyt uusia koko rajapintaa. Koko Kylixissä ei ollut mitään järkeä ja se osoitti myös sen, että Delphillä ei ole tulevaisuutta. Java jyräsi ja Microsoftilla sitten oli .NET.

Delphin vahvuudeksi jäi sitten tämän vanhanaikaisuus kun ei ollut sitä JIT käännöstä ja roskienkerääjiä niin jos halusi rakentaa visuaalisista komponenteista paikallisesti ajettavaa softaa, Delphissä oli pienimmät latenssit vastaavista työkaluista.

Qt on nykyään erinomaisen hyvin ylläpidetty. Sehän on avointa koodia ja integroitu käyttöjärjestelmiin, että ei riipu mitenkään Digiasta se ylläpito. Jokainen käyttöjärjestelmään integroitu versio on tuettuna yhtä pitkään kuin käyttöjärjestelmä. Red Hatilta esimerkiksi saa siis 13v stabiilisti tuettuja alustoja Qt:lle.

Kylixistä ilmestyi ainakin kolme versiota. Kylix koodi oli monilta osin delphi yhteensopivaa (voisi sanoa että paljon yhteensopivampaa kuin eri valmistajien C-koodi). Jos QT:lle kehittäminen olisi ollut tuottoisaa niin sitä ei olisi lopetettu. Valmistajahan sai synergiaetuja Kylixistä (sama "moottori" kuin Delphissä).

Jos QT:n koodi ei vanhenisi niin valmistaja voisi ottaa Kylixin tuotevalikoimaan. Eli kyse on paljolti QT:stä (Onko sillä markkinoita? Saako siitä rahaa? Kannattaako sillä kehittää?)

QTvanhenee kirjoitti:

Kylixistä ilmestyi ainakin kolme versiota. Kylix koodi oli monilta osin delphi yhteensopivaa (voisi sanoa että paljon yhteensopivampaa kuin eri valmistajien C-koodi). Jos QT:lle kehittäminen olisi ollut tuottoisaa niin sitä ei olisi lopetettu. Valmistajahan sai synergiaetuja Kylixistä (sama "moottori" kuin Delphissä).

Jos QT:n koodi ei vanhenisi niin valmistaja voisi ottaa Kylixin tuotevalikoimaan. Eli kyse on paljolti QT:stä (Onko sillä markkinoita? Saako siitä rahaa? Kannattaako sillä kehittää?)

Lue lisää

"(voisi sanoa että paljon yhteensopivampaa kuin eri valmistajien C-koodi)"

Ei tosiaankaan. C-kielen standardikirjasto ollut iäisyyden äärimmäisen hyvin yhteensopivaa.

"Valmistajahan sai synergiaetuja Kylixistä (sama "moottori" kuin Delphissä)."

No ei. Se Kylix IDE oli Winen kautta toimiva Win32 softa. Eli pahinta mahdollista purkkaviritystä ja rajapinta oli eri.

"Jos QT:lle kehittäminen olisi ollut tuottoisaa niin sitä ei olisi lopetettu."

Ei se voinut olla tuottoisa kun se oli niin paska, että se ei kelvannut kenellekään. Silloin 2000-luvun alussa niin wxWidgets, Qt, Java jne. olivat kaikki parempia kuin se Borlandin kyhäelmä.

"Jos QT:n koodi ei vanhenisi niin valmistaja voisi ottaa Kylixin tuotevalikoimaan."

Kylix ei ollut Qt koodia vaan se oli käytännössä Win32 API:lle tehty Delphi 5. Kylixiä ei ikinä ole tehty Qt:lle. Se niiden väännös siitä Delphi 5:sta sitten käänsi CLX:lle VLC:n sijasta joka oli hieman yhteensopimaton versio VCL:stä.

Eli se Borlandin ensimmäinen mokailu oli tehty jo silloin 90-luvun alussa kun olivat sitoneet sen oman tekniikansa täysin Win32 API:n ja toinen virhe oli, että eivät sitten ymmärtäneet uudelleenkirjoittaa sitä niin, että ei olisi naimisissa Win32 API:n kanssa. Sen jälkeen sitten räpiköitiin .NET:n kanssa eikä siitä tullut mitään ja möivät sen Delphin pois, ja sitten ihmeteltiin taas että mihin suuntaan tätä nyt viedään. Tämän takia Delphi 7 jäi pitkäksi aikaa käyttöön. Sillä oli oikein kiva kääntää uusiksi vanhat Delphiohjelmat ja ylläpitää niitä kunnes niitä sitten alettiin uudelleenkirjoittamaan joskus 2006-2009. Näinhän se homma meni. Siitä lähtien Delphi ollut tarpeeton ja nyt niitä roskaohjelmia mitä ei jostain syystä aikoinaan uudelleenkirjoitettu, ylläpidetään jollain Lazaruksella.

Lisäksi et nähtävästi käsitä sitä, että olennaisinta tuollaisilla teknologiafirmoilla on olla jollain tavalla relevantti, vaikka tarjoamalla maksutta jotain että voivat rakentaa liiketoimintaa. Koska jos tekniikka ei ole millään tavalla relevantti niin se menettää merkityksensä. IT-alalla mennään aika paljon defactoilla.

Esim. Microsoft taistelee siitä, että saisi jotain teknologiaa olemaan nykypäivänä relevantti ja siksi .NET:ä jaetaan open sourcena koska jos kukaan ei käytä Microsoftin tekniikkaa, menettää Microsoft myös merkityksensä.

"Eli kyse on paljolti QT:stä (Onko sillä markkinoita? Saako siitä rahaa? Kannattaako sillä kehittää?)"

Nykyään tilanne on viimeiset 6v ollut se, että HTML5 ollut standardialusta millä tehdään siirrettävät sovellukset mutta jos se ei jostain syystä käy niin Qt ollut se seuraavaksi paras. Adobe Flashia/AIR:ia käytettiin myös ahkerasti joskus 2004-2012. Adoben sisällöntuottotyökalut vaikuttaneet tähän.

Qt on myös paras silloin kun halutaan kääntää prosessorin omalle arkkitehtuurille se koodi ja halutaan rakentaa käyttöliittymä visuaalisista komponenteista läiskimällä lomakkeille editorissa.

Ei Kylixin IDE:ssä isompia ongelmia ollut vaan niissä QT kirjastoissa.
Toki perus C-koodi on yhteensopivaa mutta se ei ole käytännössä koskaan riittänyt.

QT_Vanhenee kirjoitti:

Ei Kylixin IDE:ssä isompia ongelmia ollut vaan niissä QT kirjastoissa.
Toki perus C-koodi on yhteensopivaa mutta se ei ole käytännössä koskaan riittänyt.

Ei Qt kirjastoissa ole ollut mitään ihmeen ongelmia, olleet API tasolla vakaita ja kypsiä Qt3:sta lähtien, mikä tuli vuoden 2001 lokakuussa. ABI vakaudesta vastaa osaltaan tietysti käyttöjärjestelmä.

Pystyykö Qt:tä koodailemaan jollakin muulla kielellä kuin ällöllä itsensä kiduttaja-rautakanki-kielellä nimeltä C ?

QT_Vanhenee kirjoitti:

Ei Kylixin IDE:ssä isompia ongelmia ollut vaan niissä QT kirjastoissa.
Toki perus C-koodi on yhteensopivaa mutta se ei ole käytännössä koskaan riittänyt.

Jos vertaa C:n vakiokirjastoa vaikkapa Javaan tai Delphiin niin aika vaatimaton se on.

Saatana_pp kirjoitti:

Pystyykö Qt:tä koodailemaan jollakin muulla kielellä kuin ällöllä itsensä kiduttaja-rautakanki-kielellä nimeltä C ?

Nykyään siinä käytetään QML:lää.

Eikä siinä C :ssa mitään vikaa ole. Miten päin vain parempi kuin Pascal, ja vaikka Java onkin astetta parempi kieli niin Qt:n on niin paljon paremmin suunniteltu, että sillä ollut sujuvampi ohjelmoida kuin Javalla niitä työpöytäsovelluksia.

Eipä se ohjelmointikieli yleensä ole se asia minkä mukaan työkalu valitaan vaan siihen on ihan muut seikat.

a------- kirjoitti:

Jos vertaa C:n vakiokirjastoa vaikkapa Javaan tai Delphiin niin aika vaatimaton se on.

Niin.. siis Delphissä ohjelmoidaan Pascalilla ja siinä on VCL mukana, joka ei Pascaliin kuulu.

Unixeissa sitten oli Motif standardina silloin 90-luvulla ja viime vuosikymmenellä GTK ja Qt tuli osaksi LSB standardia, että väliäkö sillä pelkän kielen vakiokirjastolla on.

M-Kar kirjoitti:

Niin.. siis Delphissä ohjelmoidaan Pascalilla ja siinä on VCL mukana, joka ei Pascaliin kuulu.

Unixeissa sitten oli Motif standardina silloin 90-luvulla ja viime vuosikymmenellä GTK ja Qt tuli osaksi LSB standardia, että väliäkö sillä pelkän kielen vakiokirjastolla on.

Lue lisää

Pascal:ssa toimii mutta muissa ei (tosin Java on lähellä Pascalia).
Kun kirjoitat koodin Delphissä (käytät VCL-kirjastoa) niin tuot sen Lazarukseen (käytät LCL-kirjastoa) niin useimmissa tapauksissa koodi toimii muutoksitta.
Vrt että jos teet esim. standardi C :lla käyttäen QT-kirjastoa niin se ei toimikaan GTK:n kanssa. Jos olet tehnyt 20 vuotta sitten Delphillä koodin niin se (todennäköisesti) toimii tänä päivänä. Eli otat 20 vuotta vanhan lähdekoodin käyttöön. Jos taas otat esim. QT2:n lähdekoodin ja yrität käyttää sitä tänä päivänä niin olet "ongelmissa".

Käytännössänäin kirjoitti:

Pascal:ssa toimii mutta muissa ei (tosin Java on lähellä Pascalia).
Kun kirjoitat koodin Delphissä (käytät VCL-kirjastoa) niin tuot sen Lazarukseen (käytät LCL-kirjastoa) niin useimmissa tapauksissa koodi toimii muutoksitta.
Vrt että jos teet esim. standardi C :lla käyttäen QT-kirjastoa niin se ei toimikaan GTK:n kanssa. Jos olet tehnyt 20 vuotta sitten Delphillä koodin niin se (todennäköisesti) toimii tänä päivänä. Eli otat 20 vuotta vanhan lähdekoodin käyttöön. Jos taas otat esim. QT2:n lähdekoodin ja yrität käyttää sitä tänä päivänä niin olet "ongelmissa".

Lue lisää

"Vrt että jos teet esim. standardi C :lla käyttäen QT-kirjastoa niin se ei toimikaan GTK:n kanssa."

GTK ei ole C kirjasto vaan C kirjasto, eikä yritä olla vastaavia. LCL taas pyrki olemaan vastaava VCL:n kanssa.

Qt:lle kun tekee sovelluksen, se sama sovellus toimii pienin tai olemattomin muutoksin koodissa eri käyttöjärjestelmissä ja myös tulevissa versioissa. Delphi epäonnistui tässä.

"Jos taas otat esim. QT2:n lähdekoodin ja yrität käyttää sitä tänä päivänä niin olet "ongelmissa"."

Sanoin, että Qt:stä tuli stabiilia Qt3:ssa. Sen jälkeen päivitykset vain lisäili ominaisuuksia rikkoutumiset tapahtui Qt4 ja Qt5 versioissa. Eli major versiot rikkovat ja muuten päivitykset lisää toiminallisuutta.

Sen lisäksi Qt4:n mukana raahattiin taaksepäinyhteensopivuussyistä Qt3:a. Ja Qt5:ssa raahataan mukana Qt4:sta.

Red Hat Enterprise 7:ssa muuten on Qt4, eli Qt3 on mukana kuvioissa vielä ainakin 12v, eli yhteensä ainakin 26v elinkaari sille rajapintaversiolle.

Sen lisäksi C standardointiin 1998, eli tämän standardikirjasto toki on melko muuttumaton vaikka Qt:stä tuli stabiilia 2001.

Delphi on onnistunut parhaiten windows ympäristössä pitämään lähdekoodin yhteensopivana vaikka k'yttöjärjestelmän versiot ovat vaihtuneet win 3.1 -> win 10:n.

Tähän ei ole päässyt mikään muu. Lähimpänä taitaa olla Java. Esim MS:n omat tuotteet ovat vanhentuneet moneet kertaan (vaikka markkinointi nimi saattaa kuulostaa samalta tai eri nimiseltä)

VanhaQT kirjoitti:

Delphi on onnistunut parhaiten windows ympäristössä pitämään lähdekoodin yhteensopivana vaikka k'yttöjärjestelmän versiot ovat vaihtuneet win 3.1 -> win 10:n.

Tähän ei ole päässyt mikään muu. Lähimpänä taitaa olla Java. Esim MS:n omat tuotteet ovat vanhentuneet moneet kertaan (vaikka markkinointi nimi saattaa kuulostaa samalta tai eri nimiseltä)

Lue lisää

Tietääkseni MFC:ssä ei myöskään ole mitään rajuja muutoksia.

Tuossa ajassa on siirrytty 16-bittisistä 64-bittisiin ohjelmistoihin.

muutoksia_on kirjoitti:

Tuossa ajassa on siirrytty 16-bittisistä 64-bittisiin ohjelmistoihin.

Ei se API:n vaikuta vaan ABI:n.

M-Kar kirjoitti:

Tietääkseni MFC:ssä ei myöskään ole mitään rajuja muutoksia.

Linkissä jotain mitä meni rikki vesion 2013 ja 2015 välillä https://msdn.microsoft.com/en-us/library/bb531344.aspx

rikkiä kirjoitti:

Linkissä jotain mitä meni rikki vesion 2013 ja 2015 välillä https://msdn.microsoft.com/en-us/library/bb531344.aspx

Lue lisää

Niin? Aika pieniä muutoksiahan nuo ovat. Tuolta on nyt sitten poistettu juttuja jotka tiedettiin poistettavaksi 16v takaperin, muutama komentorivi valitsin, pari tapausta jossa alunperinkin paskasti kirjoitettu koodi lakkaa toimimasta, joku juttu ilmoitettu deprekoiduksi että tulee käännösvirhettä mutta homma edelleen toimii.

API näkyy olevan käytännössä sama mutta vanhan projektin kun siirtää uudemmalle työkalulle niin on mahdollista, että jotkut epäselvät ja heikosti ylläpidetyt koodit heittää errorit virhettä ruudulle. Niille sitten tehdään vähän ylläpitoa ja sitten vaan käännetään uusiksi.