Är Python, pyton eller ej?
-
486-Moddare
- Inlägg: 258
- Blev medlem: 30 oktober 2005, 19:03:11
-
486-Moddare
- Inlägg: 258
- Blev medlem: 30 oktober 2005, 19:03:11
"vad jag vet" är nog nyckelorden där. Du vet uppenbarligen inte.
> skiten var ju omodern redan på 80-talet
Det är möjligt (det är lite oklart vad du menar med "omodernt"),
ändå söks det dagligen COBOL kompetens till både konsult- och fast-tjänster.
För bara 3-4 år sedan beräknandes det att över 80 % av alla finansiella
transaktioner utfördes av COBOL kod. COBOL kod utgjode då ca 65% av
*all* programvarukod i aktiv användning (ca 200 miljarder kodrader). Ca
5 miljarder nya kodrader skrevs i COBOL. Detta var alltså 2003. Det fanns
då även fler COBOL programmerare än för något annat språk (d.v.s som
har det till sitt yrke, inte bara som hobby), uppskattat till ca 3 miljoner
COBOL programmerare world-wide. Siffror enligt Gartner.
Allt snack om COBOL's snara död är bara okunskap.
> skiten var ju omodern redan på 80-talet
Det är möjligt (det är lite oklart vad du menar med "omodernt"),
ändå söks det dagligen COBOL kompetens till både konsult- och fast-tjänster.
För bara 3-4 år sedan beräknandes det att över 80 % av alla finansiella
transaktioner utfördes av COBOL kod. COBOL kod utgjode då ca 65% av
*all* programvarukod i aktiv användning (ca 200 miljarder kodrader). Ca
5 miljarder nya kodrader skrevs i COBOL. Detta var alltså 2003. Det fanns
då även fler COBOL programmerare än för något annat språk (d.v.s som
har det till sitt yrke, inte bara som hobby), uppskattat till ca 3 miljoner
COBOL programmerare world-wide. Siffror enligt Gartner.
Allt snack om COBOL's snara död är bara okunskap.
> Det är inte många nya projekt som innefattar COBOL vad jag vet, skiten var ju omodern redan på 80-talet
Tror du missade första satsen där. Jag tror inte heller att det startas direkt många nya större system COBOL. Utan det handlar snarare om underhåll/överlevnad av redan befintliga system.
> skiten var ju omodern redan på 80-talet
Då antar jag du menar som programmeringsspråk sett. Ja, jag vet inte det direkt. På 80-talet satt vi ju mest med C, Pascal, Fortan eller 4G "Språk" som Dataflex mm. Och nog var en "bra" COBOL likvärdig med det. IAf för administrativa rutiner, där var det till och med bättre.
Sedan när objectorienterade språk som C++ osv kom, då blev det ju iof efter. C++ kom ju också på 80-talet men slog inte igenom förren sent 80-tal.
Och COBOL finns ju även under .NET, så vem vet vad som händer i framtiden, men jag skulle nog inte satsa några större pengar på det.
Tror du missade första satsen där. Jag tror inte heller att det startas direkt många nya större system COBOL. Utan det handlar snarare om underhåll/överlevnad av redan befintliga system.
> skiten var ju omodern redan på 80-talet
Då antar jag du menar som programmeringsspråk sett. Ja, jag vet inte det direkt. På 80-talet satt vi ju mest med C, Pascal, Fortan eller 4G "Språk" som Dataflex mm. Och nog var en "bra" COBOL likvärdig med det. IAf för administrativa rutiner, där var det till och med bättre.
Sedan när objectorienterade språk som C++ osv kom, då blev det ju iof efter. C++ kom ju också på 80-talet men slog inte igenom förren sent 80-tal.
Och COBOL finns ju även under .NET, så vem vet vad som händer i framtiden, men jag skulle nog inte satsa några större pengar på det.
Jag tycker att du, Sodjan, har väldigt många bra poänger i den här tråden. Jag önskar att det var fler i mjukvarubranschen som bejakade dessa grundläggande principer. Det är tyvärr väldigt många "proffs" i branschen med 25 års erfarenhet som "vet" att man bara kastar hårdvara på problemen när den "optimerade designen" inte levererar.
Jag har flertalet gånger sett konsulter boota upp eclipse eller visual studio innan de hört vad som ska utvecklas.
Jag har flertalet gånger sett konsulter boota upp eclipse eller visual studio innan de hört vad som ska utvecklas.
> Jag har flertalet gånger sett konsulter boota upp eclipse eller visual studio innan de hört vad som ska utvecklas.
Bara för att man kallar sig konsult så innebär det inte automatiskt att man vet vad man gör och startar man bara upp en dator och börjar hacka kod utan att analysera vad som skall göras först, då är man på hobbynivå som utvecklare.
Men det pratas om 2 olika saker här.
- Program/System som körs av en användare på en dator.
Där måste man givetvis anpassa sin kod efter hårdvaran och optimera mesta möjligt där det är försvarbart.
- Program som körs på en server mot ett nätverk/internet mm
Tidigare var en "server" ganska likvärdigt med en fysisk dator, och när man skalade då så gjorde man det genom att utöka minnet, byta processor mm. Då var det extremt viktigt som flera säger att verkligen optimera koden för maximal prestanda.
Idag när man designar nätverkssystem så är termen "server" mer abstrakt. Skall man bygga ett system som skall kunna hantera 10 000-tals samtida användare så är hårdvarudesignen lika viktig som mjukvaran. För det spelar ingen roll hur mycket hårdvara du stoppar i en enstaka dator, den kan bara hantera ett visst antal användare samtidigt oavsett hur bra din kod är.
Idag så är en server för sådana system alltid ett antal datorer kopplade i kluster och lastballanserade för att kunna skala. En website kan t.ex ha 4a webbserverar, 2 SQL servrar, 1 mailserver och 1 filserver. Det är väl knappast någon som tror att Google bara har en dator och optimerar koden hela tiden ?
När man sedan vill kunna hantera fler användare så skalar man genom att Stoppa in fler datorer, dvs skalar med hårdvara.
Givetvis förutsätter det att designen är bra från början med. Dvs du har en bra kodbas, bra objektstruktur, bra databasstruktur, bra hantering av serverresurser som trådar, databaskopplingar, caching mm. Har du det så måste man skala med hårdvara. Dålig kod aldrig lösas med bara hårdvara och framför allt kan man inte "laga" gamla dåliga system bara genom att "kasta" ny hårdvara på dem.
Bara för att man kallar sig konsult så innebär det inte automatiskt att man vet vad man gör och startar man bara upp en dator och börjar hacka kod utan att analysera vad som skall göras först, då är man på hobbynivå som utvecklare.
Men det pratas om 2 olika saker här.
- Program/System som körs av en användare på en dator.
Där måste man givetvis anpassa sin kod efter hårdvaran och optimera mesta möjligt där det är försvarbart.
- Program som körs på en server mot ett nätverk/internet mm
Tidigare var en "server" ganska likvärdigt med en fysisk dator, och när man skalade då så gjorde man det genom att utöka minnet, byta processor mm. Då var det extremt viktigt som flera säger att verkligen optimera koden för maximal prestanda.
Idag när man designar nätverkssystem så är termen "server" mer abstrakt. Skall man bygga ett system som skall kunna hantera 10 000-tals samtida användare så är hårdvarudesignen lika viktig som mjukvaran. För det spelar ingen roll hur mycket hårdvara du stoppar i en enstaka dator, den kan bara hantera ett visst antal användare samtidigt oavsett hur bra din kod är.
Idag så är en server för sådana system alltid ett antal datorer kopplade i kluster och lastballanserade för att kunna skala. En website kan t.ex ha 4a webbserverar, 2 SQL servrar, 1 mailserver och 1 filserver. Det är väl knappast någon som tror att Google bara har en dator och optimerar koden hela tiden ?
När man sedan vill kunna hantera fler användare så skalar man genom att Stoppa in fler datorer, dvs skalar med hårdvara.
Givetvis förutsätter det att designen är bra från början med. Dvs du har en bra kodbas, bra objektstruktur, bra databasstruktur, bra hantering av serverresurser som trådar, databaskopplingar, caching mm. Har du det så måste man skala med hårdvara. Dålig kod aldrig lösas med bara hårdvara och framför allt kan man inte "laga" gamla dåliga system bara genom att "kasta" ny hårdvara på dem.
Språk går ju också moderniseras och snyggas upp för bättre översikt ur programerarsynvinkel. God exempel är ju Visual Basic som inte har så mycket gemensamt med den radorienterade ABC80-basicen (minns någon den?) eller GW-basicen medföljande DOS på sin tid.
Fortran och Lisp är fortfarande stor inom matematik och vetenskap och ses ofta som referenskod som portas (till ofta stor möda och mycket buggar under lång tid) till andra språk just för att den hanterar komplexa tal som en del av själva språket och inte som påhäng efteråt - och än idag så designas inte den delen in trots nydesignade språk som java och C# utan tvärt om blir hemskt omständiga att hantera då åtm. java inte har operatörsöverlagring på samma sätt som C++ (har inte koll på C# i det avseendet)
Kan man sin hålkortsorienterade Fortran utan och innan så är det bara extremt besvärligt att hoppa till 'modernare' språk då dom inte gör som förväntat (ur fortranögon) i olika extremsituationer - och det är massor av dessa i vetenskapliga och simuleringsprogram och det är för få som kan debugga dessa effektiv när de portas vilket gör att portningar kan ta flera år innan de når en rimlig felfrihet.
'Spice' är ett känt sådant programpaket och 'C' versionen maglades säkert i 5 år innan det ansågs tillräkligt bra - bara för en 'enkel' portning...
Fortran och Lisp är fortfarande stor inom matematik och vetenskap och ses ofta som referenskod som portas (till ofta stor möda och mycket buggar under lång tid) till andra språk just för att den hanterar komplexa tal som en del av själva språket och inte som påhäng efteråt - och än idag så designas inte den delen in trots nydesignade språk som java och C# utan tvärt om blir hemskt omständiga att hantera då åtm. java inte har operatörsöverlagring på samma sätt som C++ (har inte koll på C# i det avseendet)
Kan man sin hålkortsorienterade Fortran utan och innan så är det bara extremt besvärligt att hoppa till 'modernare' språk då dom inte gör som förväntat (ur fortranögon) i olika extremsituationer - och det är massor av dessa i vetenskapliga och simuleringsprogram och det är för få som kan debugga dessa effektiv när de portas vilket gör att portningar kan ta flera år innan de når en rimlig felfrihet.
'Spice' är ett känt sådant programpaket och 'C' versionen maglades säkert i 5 år innan det ansågs tillräkligt bra - bara för en 'enkel' portning...
Det kan ju finnas begränsningar i lägre skikt än i själva applikationen.
Antalet session för olika protokoll t.ex. Antalet threads i web-servern,
eller något annat...
I det OS jag jobbar togs nyligen bort begränsningen på max 9999 telnet
sessioner t.ex, man kan nu har 5 siffriga device nummer på telnet "devicen"...
Antalet session för olika protokoll t.ex. Antalet threads i web-servern,
eller något annat...
I det OS jag jobbar togs nyligen bort begränsningen på max 9999 telnet
sessioner t.ex, man kan nu har 5 siffriga device nummer på telnet "devicen"...
Senast redigerad av speakman 6 februari 2008, 15:09:14, redigerad totalt 3 gånger.
jbulow skrev:Hur menar du med "....den [datorn] kan bara hantera ett visst antal användare samtidigt oavsett hur bra din kod är" ?
Varje användare som är inne på datorn reserverar och förbrukar ju ett antal systemresurser. När du nått en viss gräns med samtida användare så kommer datorn gå så långsamt att svarstiderna blir olidliga. Då måste du "plugga" in en dator till.
