Med dagens hårdvara är det knappast några problem med interpreterande språk.
Många stora webbsiter byggs idag med Ruby on Rails och Django för Python.
Ibland körs dom dessutom under JRuby eller Jython som är respektives tolk skrivna i ren Java. Alltså interpreterande under Java (Java är *inte* interpreterande!).
Jag undrar hur dessa siter fungerar... Launchpad är ett exempel på massiv användning både siten och all Bazaar som går under skalet, allt skrivet i Python.
Rent affärsekonomiskt är det inte lönsamt att skriva större saker i sådana miljöer i C då felfaktorn är mycket högre än i hög(re)nivåspråk.
Produktiviteten är mångfalt större dessutom.
OpenVMS
> Med dagens hårdvara är det knappast några problem med interpreterande språk.
Det beror ju lite på vad det är man vill pressa ur hårdvaran.
D.v.s vad applikationen ska göra. Det är ju skillnad på en burk
"på bordet" med en användare framför mot en burk som kör
450-500 processer (varav 200 ligger och jobbar mot samma databas)
och 150 inloggade användare vid terminaler och PC. Där kan man
inte ha en massa overhead från JVM, JIT och liknande prylar.
Tekniker som JIT och "Hotspot" gör situationen bättre, men det visar
också att det är ett känt problem att Java är lite resurshungrigt.
Portabiliteten är naturligstvis den fördel man får med dessa nackdelar.
Vad som är viktigast varierar och får bedömmas från miljö till miljö.
> att skriva större saker i sådana miljöer i C då felfaktorn är mycket högre än i hög(re)nivåspråk.
Nej visst, bättre då att köra COBOL så får man både korrekt och lättunderhållen
kod och bästa möjliga prestanda på samma gång...
Det beror ju lite på vad det är man vill pressa ur hårdvaran.
D.v.s vad applikationen ska göra. Det är ju skillnad på en burk
"på bordet" med en användare framför mot en burk som kör
450-500 processer (varav 200 ligger och jobbar mot samma databas)
och 150 inloggade användare vid terminaler och PC. Där kan man
inte ha en massa overhead från JVM, JIT och liknande prylar.
Tekniker som JIT och "Hotspot" gör situationen bättre, men det visar
också att det är ett känt problem att Java är lite resurshungrigt.
Portabiliteten är naturligstvis den fördel man får med dessa nackdelar.
Vad som är viktigast varierar och får bedömmas från miljö till miljö.
> att skriva större saker i sådana miljöer i C då felfaktorn är mycket högre än i hög(re)nivåspråk.
Nej visst, bättre då att köra COBOL så får man både korrekt och lättunderhållen
kod och bästa möjliga prestanda på samma gång...
Den där lasten låter inte farligt i jämförelse med vad som pågår på Launchpad där bl.a. hela utvecklingen för Ubuntu ligger.
Nu består säkert inte Launchpad av en burk utan av flera, men jag gissar ändå att det är värt hårdvaran att slippa skriva all kod i C.
Och COBOL är väl ett ypperligt exempel egentligen. Framtaget för ett specifikt ändamål, men garanterat säkert istället.
Det finns ju dock lite modernare allround-språk som Python, Perl och Ruby idag...
Ser att Facebook ser ut att vara skrivet i PHP. Det säger ju en hel del det...
Nu består säkert inte Launchpad av en burk utan av flera, men jag gissar ändå att det är värt hårdvaran att slippa skriva all kod i C.
Och COBOL är väl ett ypperligt exempel egentligen. Framtaget för ett specifikt ändamål, men garanterat säkert istället.
Det finns ju dock lite modernare allround-språk som Python, Perl och Ruby idag...
Ser att Facebook ser ut att vara skrivet i PHP. Det säger ju en hel del det...
Visst, det är ju så utvecklingen ser ut i dag. Kör gärna ineffektiva
verktyg, det är ju bara att slänga extra servrar på "problemet".
Det här är ingen fråga om modernt vs. omodernt, det handlar om
effektivitet. Ibland är programmerarens effektivitet viktigare än
applikationens, ibland är det tvärt om. That's life.
verktyg, det är ju bara att slänga extra servrar på "problemet".
Det här är ingen fråga om modernt vs. omodernt, det handlar om
effektivitet. Ibland är programmerarens effektivitet viktigare än
applikationens, ibland är det tvärt om. That's life.
Absolut, men jag syftade till att visa på att du inte har rätt i uttalanden som dessa:
Jag tror m.a.o. att du underskattar de moderna högnivåspråken.
Även om de tar mer prestanda än kompilerat så väger det sällan emot produktiviteten och en extra server (eller kraftigare).
Men så kör "man" gärna på fritt OS och standard hårdvara så en till server blir sällan dyr förhållande till prestandan.
Det har ganska stora fördelar, inte så små som du verkar vilja påskina. Samt att Java inte är interpreterande utan kompileras till bytecode som i sin tur körs (ganska effektivt) under JREs.sodjan skrev:Rent *tekniskt* är naturligtsvis Java ett skit-språk (interpreterande och
rellativt ineffektivt jämfört med "vanliga" språk som C/C++, COBOL, Fortran
eller likande), även om det finns en del *praktiska* fördelar.
Jag tror m.a.o. att du underskattar de moderna högnivåspråken.
Även om de tar mer prestanda än kompilerat så väger det sällan emot produktiviteten och en extra server (eller kraftigare).
Men så kör "man" gärna på fritt OS och standard hårdvara så en till server blir sällan dyr förhållande till prestandan.
En kompis till mej jobbar på en statlig myndighet där dom enbart kör Solaris/Sparc, utom en maskin som kör AIX, detta är för att AIX kan köra Cobol native (på nåt vänster).
Man har alltså en gammal applikation skriven i cobol som man måste ha, då har man tre alternativ.
1. Köra den i solaris (emulerat)
2. Porta till annat språk
3. Köra ett OS som kan köra den native
Alla alternativ är dåliga, att köra den i solaris tar EXTREMA resurser, och då har detta verket hela hallar fulla med modern sunhårdvara.. tvåan finns inte på kartan efterssom det är ett för stort projekt som skulle kosta en massa pengar, då återstår trean som är dålig efterssom man helst inte vill drifta flera olika miljöer, men det är det kostnadseffektivaste ändå.
Man har alltså en gammal applikation skriven i cobol som man måste ha, då har man tre alternativ.
1. Köra den i solaris (emulerat)
2. Porta till annat språk
3. Köra ett OS som kan köra den native
Alla alternativ är dåliga, att köra den i solaris tar EXTREMA resurser, och då har detta verket hela hallar fulla med modern sunhårdvara.. tvåan finns inte på kartan efterssom det är ett för stort projekt som skulle kosta en massa pengar, då återstår trean som är dålig efterssom man helst inte vill drifta flera olika miljöer, men det är det kostnadseffektivaste ändå.
I mitt fall stavas nog behovet av VMS - historia(men även en del driftsäkerhet)!
Jag ser ju dock att organisationen kommer att få kompetensproblem i framtiden om man fortsätter att bygga fast sig i fortran på VMS. Och jag tror väl det är lite därför HP levererar Java till VMS....för att möjliggöra för fler att koda för operativet.
Nåväl, det var många intressanta frågor som kom upp.
Idag finns det en massa program(om det är exe eller funktioner har jag ingen aning om, på vilket sätt gör det skillnad?) skrivna i fortran som lagrar data i RDB. Förut använde man vanliga VT100 terminaler som "klienter". Sedan några år bygger man klienterna på Windows i .NET. Och till varje system har man något 10-tal klienter på varje VMS-burk. För att kommunicera mellan VMS och Windows har man använt en egen lösning där man har en egen "server" som snackar TCP/IP och där VMS och Windows kopplar upp sig med var sin socket och lämar/läser data i nåt som liknar en punktdatabas(alltså ett definierat antal punkter som man kan läsa eller skriva). Dessutom läser ju windows klienterna direkt i RDB databasen, antingen via ODBC eller via den nya .NET providern.
Detta fungerar, men har sina nackdelar t.ex. typsäkerheten.
Nu har jag kommit in i detta utifrån och försöker se på detta med nya ögon. För mig blir det oklart vart "affärslogiken" i systemet hamnar......i praktiken blir det ju så att en del hamnar hos klienten(genom databasaccesen) och en del på servern(i fortran koden). Min första spontana tanke var att flytta all logik till .NET och bara använda RDB och VMS för datalagringen, men av praktiska och historiska skäl är inte det genomförbart. Då tycker jag det bästa vore att vända på steken och lägga allt i VMS, men där saknar jag ett bra gränssnitt mellan systemen.
Och det var därför jag startade denna tråden för att om möjligt få lite inputs på hur detta lösts på andra ställen......
Jag ser ju dock att organisationen kommer att få kompetensproblem i framtiden om man fortsätter att bygga fast sig i fortran på VMS. Och jag tror väl det är lite därför HP levererar Java till VMS....för att möjliggöra för fler att koda för operativet.
Nåväl, det var många intressanta frågor som kom upp.
Idag finns det en massa program(om det är exe eller funktioner har jag ingen aning om, på vilket sätt gör det skillnad?) skrivna i fortran som lagrar data i RDB. Förut använde man vanliga VT100 terminaler som "klienter". Sedan några år bygger man klienterna på Windows i .NET. Och till varje system har man något 10-tal klienter på varje VMS-burk. För att kommunicera mellan VMS och Windows har man använt en egen lösning där man har en egen "server" som snackar TCP/IP och där VMS och Windows kopplar upp sig med var sin socket och lämar/läser data i nåt som liknar en punktdatabas(alltså ett definierat antal punkter som man kan läsa eller skriva). Dessutom läser ju windows klienterna direkt i RDB databasen, antingen via ODBC eller via den nya .NET providern.
Detta fungerar, men har sina nackdelar t.ex. typsäkerheten.
Nu har jag kommit in i detta utifrån och försöker se på detta med nya ögon. För mig blir det oklart vart "affärslogiken" i systemet hamnar......i praktiken blir det ju så att en del hamnar hos klienten(genom databasaccesen) och en del på servern(i fortran koden). Min första spontana tanke var att flytta all logik till .NET och bara använda RDB och VMS för datalagringen, men av praktiska och historiska skäl är inte det genomförbart. Då tycker jag det bästa vore att vända på steken och lägga allt i VMS, men där saknar jag ett bra gränssnitt mellan systemen.
Och det var därför jag startade denna tråden för att om möjligt få lite inputs på hur detta lösts på andra ställen......
OK, du har du inte bara världens bästa OS, utan också världens bästa databas!
Jag har jobbat 15 år med Rdb (skrivs *inte* "RDB" !), så jag tycker att jag kan den ganska bra.
Ditt läge är ganska typiskt för många VMS/Rdb siter i dag.
För några år sedan var olika "message queueing" produkter populära.
Som t.ex BEA MessageQ :
http://www.bea.com/framework.jsp?CNT=in ... e/messageq
Hette DECMessageQ innan den såldes till BEA, så den fungerar utmärkt på VMS...
Eller IBM's MQ :
http://www-306.ibm.com/software/integration/wmq/
som också har VMS klienter, både Alpha och Itanium.
Sedan fanns olika CORBA baserade lösningar för de som föredrar det.
Att köra direkt mot databasen (ODBC eller liknande) har en del nackdelar
som du säger, en del av dessa kan man jobba runt m.h.a triggers och
"external funktions" i Rdb. Men det kräver en del tid och utveckling.
Du skulle kunna läsa en del av de handouts (Powerpoint kopior) från den
senaste "OpenVMS Technical Update" (Stockholm i November). Det var
flera där som just tog upp framtida metoder och verktyg för app-utveckling.
Jag hittar just nu inte länken till Stockholms materialet, men här ligger
i princip samma material som användes i Holland :
http://gerritwoertman.eu/VMSTUD2007/
Kolla t.ex "OpenVMS Application Development in the 21st Century - Meg Watson"
där finns en del kring applikations utveckling.
Jag har jobbat 15 år med Rdb (skrivs *inte* "RDB" !), så jag tycker att jag kan den ganska bra.
Ditt läge är ganska typiskt för många VMS/Rdb siter i dag.
För några år sedan var olika "message queueing" produkter populära.
Som t.ex BEA MessageQ :
http://www.bea.com/framework.jsp?CNT=in ... e/messageq
Hette DECMessageQ innan den såldes till BEA, så den fungerar utmärkt på VMS...
Eller IBM's MQ :
http://www-306.ibm.com/software/integration/wmq/
som också har VMS klienter, både Alpha och Itanium.
Sedan fanns olika CORBA baserade lösningar för de som föredrar det.
Att köra direkt mot databasen (ODBC eller liknande) har en del nackdelar
som du säger, en del av dessa kan man jobba runt m.h.a triggers och
"external funktions" i Rdb. Men det kräver en del tid och utveckling.
Du skulle kunna läsa en del av de handouts (Powerpoint kopior) från den
senaste "OpenVMS Technical Update" (Stockholm i November). Det var
flera där som just tog upp framtida metoder och verktyg för app-utveckling.
Jag hittar just nu inte länken till Stockholms materialet, men här ligger
i princip samma material som användes i Holland :
http://gerritwoertman.eu/VMSTUD2007/
Kolla t.ex "OpenVMS Application Development in the 21st Century - Meg Watson"
där finns en del kring applikations utveckling.
Ja visst ! Det var precis det jag skrev, man kör WEB Services om man måste...
Det kit som jag har använt/använder är en port av gSOAP till VMS :
http://www.johndapps.com-a.googlepages.com/download .
Det är lite mer "lightweight" än det officiella WSIT kittet och ställer
inte samma krav på VMS systemet, t.ex behövs ingen Java installation.
Du får fädiga fiunktioner som antingen anropas direkt från Fortran
eller via stubbar. Både klient och server kod genereras automatiskt.
Det är den väg jag skulle gå för att integrera mot en befintlig VMS applikation.
EDIT: Se även : http://www.cs.fsu.edu/~engelen/soap.html
Det kit som jag har använt/använder är en port av gSOAP till VMS :
http://www.johndapps.com-a.googlepages.com/download .
Det är lite mer "lightweight" än det officiella WSIT kittet och ställer
inte samma krav på VMS systemet, t.ex behövs ingen Java installation.
Du får fädiga fiunktioner som antingen anropas direkt från Fortran
eller via stubbar. Både klient och server kod genereras automatiskt.
Det är den väg jag skulle gå för att integrera mot en befintlig VMS applikation.
EDIT: Se även : http://www.cs.fsu.edu/~engelen/soap.html
De har samma huvudarkitekt, Dave Cutler. Dave plockades över från DEC till
MS för att hålla i trådarna för MS uppföljare till OS/2 efter att MS och IBM hade
gått åt olika håll. Det finns många likheter mellan kernel funktioner i NT
och VMS. T.ex prioritetshantering, interrupt, I/O hantering, ACL'er o.s.v.
Från början saknades det mycket dokumentation till NT så många använde
"VMS internals" för att få beskrivet hur NT fungerade internt...
Sen är det en bedömning vad man menar med "baserat på".
Att sedan WNT = VMS + 1, betyder kanske mindre...
MS för att hålla i trådarna för MS uppföljare till OS/2 efter att MS och IBM hade
gått åt olika håll. Det finns många likheter mellan kernel funktioner i NT
och VMS. T.ex prioritetshantering, interrupt, I/O hantering, ACL'er o.s.v.
Från början saknades det mycket dokumentation till NT så många använde
"VMS internals" för att få beskrivet hur NT fungerade internt...
Sen är det en bedömning vad man menar med "baserat på".
Att sedan WNT = VMS + 1, betyder kanske mindre...
