Är Python, pyton eller ej?
Tänkte just säga det; det beror nog väldigt mycket på vilken marknad man vill slå sig in på.
Har man bara kontakter i MS-världen så lär Python kanske inte vara bästa valet rent ekonomiskt, men det finns mycket mer än så. Många ställen har produkten som enda målsättning, och vad den görs av är upp till utvecklarna.
Har man bara kontakter i MS-världen så lär Python kanske inte vara bästa valet rent ekonomiskt, men det finns mycket mer än så. Många ställen har produkten som enda målsättning, och vad den görs av är upp till utvecklarna.
> Vad gäller val av språk så skulle jag säga att det mest produktiva borde vara det rätta valet...
Tyvärr kraschar allt för många IT-projekt i dag p.g.a den inställningen.
I praktiken är ofta det som är mest produktivt (d.v.s spar tid) för *programmeraren*
även det som får driftmiljön att gå in i väggen.
Allt för många amatörer bygger bara på och försöker få något som (skenbart)
fungerar så snabbt som möjligt, utan att tänka en tanke på hur det senare
ska köras (och ofta utan kunskap om det heller...).
Det är ju knappast någon hemlighet att många "moderna" och "produktiva"
verktyg har stora skalbarhetsproblem. Och de som inte fattar bättre säger
ofta bara att det "är inget problem, bara att kasta mer hårdvara på problemet".
Tyvärr kraschar allt för många IT-projekt i dag p.g.a den inställningen.
I praktiken är ofta det som är mest produktivt (d.v.s spar tid) för *programmeraren*
även det som får driftmiljön att gå in i väggen.
Allt för många amatörer bygger bara på och försöker få något som (skenbart)
fungerar så snabbt som möjligt, utan att tänka en tanke på hur det senare
ska köras (och ofta utan kunskap om det heller...).
Det är ju knappast någon hemlighet att många "moderna" och "produktiva"
verktyg har stora skalbarhetsproblem. Och de som inte fattar bättre säger
ofta bara att det "är inget problem, bara att kasta mer hårdvara på problemet".
Det är inte direkt min erfarenhet efter 25 år i branchen att det är produktiva utvecklingsverktyg som gör att IT Projekt kraschar, utan snarare
- Dålig projektledning
- Dåligt formulerade behovskrav från början.
- Dålig support från beställaren på ledningsnivå (I större bolag)
Trenden i dag inom alla stora OS är att gå mot mer produktiva verktyg (application frameworks) och projektledningsmodeller (Agile). Vilket jag anser gagnar kunden, med en kunnig leverantör får han det han verkligen behöver både snabbare och billigare än tidigare.
Hårdvaran är nästan alltid den minsta kostnaden i de flesta utecklingsprojekt. Så i regel är det billigare för kunderna att "kasta" in mer hårdvara än konsulttid. Man gör det även ofta för att det skall bli enklare/billigare att underhålla och vidareutveckla i framtiden.
Rätt eller fel ? De flesta kunder vill ju betala så lite som möjligt och det är ju alltid kunden som bestämmer.
- Dålig projektledning
- Dåligt formulerade behovskrav från början.
- Dålig support från beställaren på ledningsnivå (I större bolag)
Trenden i dag inom alla stora OS är att gå mot mer produktiva verktyg (application frameworks) och projektledningsmodeller (Agile). Vilket jag anser gagnar kunden, med en kunnig leverantör får han det han verkligen behöver både snabbare och billigare än tidigare.
Hårdvaran är nästan alltid den minsta kostnaden i de flesta utecklingsprojekt. Så i regel är det billigare för kunderna att "kasta" in mer hårdvara än konsulttid. Man gör det även ofta för att det skall bli enklare/billigare att underhålla och vidareutveckla i framtiden.
Rätt eller fel ? De flesta kunder vill ju betala så lite som möjligt och det är ju alltid kunden som bestämmer.
-
MicaelKarlsson
- Inlägg: 4669
- Blev medlem: 18 juni 2004, 09:16:07
- Ort: Aneby
- Kontakt:
Kanske inte var alldeles tydlig på den punkten i mitt första inlägg. Jag tänkte att formuleringen "Har funderat på att lära mig ett nytt programmeringsspråk" skulle ge tillräcklig information om att det var för hobbybruk.pern skrev:Tillbaka till topic
En viktig sak att belysa när man skall rekommendera någon vilket programmeringsspråk/utvecklingsmiljö de skall lägga sin tid på att lära sig är att de bör ställa sig frågan om vad de skall använda kunskapen till.
Är det bara för rent intresse/hobby-bruk så kör på med det som du tycker verkar roligt. Att lära sig Python kan säkert vara utvecklande och vad jag förstått så kan det lösa det du är ute efter.
Om det kommer användas i arbete är det i alla fall billigare med Python än med Matlab som jag hittills pysslat mest med.
.... och det är till hobby jag skall ha mina pythonkunskaper. Ja när projektet/prylen är klar har man fått ut den njutningen man är ute efter.Icecap skrev:Skillnaden är väl VAD man gör.
Är det till hobby är själva "resan mot målet" ju oftast det som eftersträvs, när prylen väl fungerar är den ju tråkig.
Andax: Tack för alla tips!! Eftersom gräddtårtor inte går att posta så blir det en sådan här istället!
Tack till alla Er andra för intressant läsning!!
Lite off-topic har inte skadat någon!
-
486-Moddare
- Inlägg: 258
- Blev medlem: 30 oktober 2005, 19:03:11
Den inställningen stör mig rätt rejält, eftersom många tänker att datorernas prestanda inte är något problem slutar det med inneffektiva program som är en pina att använda på ett i dag relativt långsamt system. Nu är detta oftast inte något problem när det gäller hobby-bruk. Men ska man göra något som förväntas användas av många är det defenetivt värt att lägga lite extra tid på att optimera och kanske t.o.m. använda ett effektivare programmeringsspråk för uppgiften.speakman skrev:Tror hårdvarukostnaderna idag är betydligt billigare än tiden för en utvecklare att skriva varenda lilla frontend i C.
Om du vet hur man designar högprestanda system för t.ex internet så ingår det ju redan i den grundläggande design att det skall vara optimerat. Och Om din designen är optimerad tjänar du mer på att t.ex bygga ut hårdvaran på databasservrar än att hålla på att pula med vissa funktioner i lågnivå-språk.
Dessutom ingår ju det som heter "Code refactoring" i de flesta utecklingsmodeller numera just för att snygga till och optimera kod i efterhand. Men hur långt man skall ta det är ju alltid en kostnadsfråga för kunden som sagt.
Men skall du skriva ett nytt Photoshop eller liknande så håller jag dock med...
Dessutom ingår ju det som heter "Code refactoring" i de flesta utecklingsmodeller numera just för att snygga till och optimera kod i efterhand. Men hur långt man skall ta det är ju alltid en kostnadsfråga för kunden som sagt.
Men skall du skriva ett nytt Photoshop eller liknande så håller jag dock med...
sodjan:
När man pratar servermiljö så är det ganska logiskt att det är en punkt som verkligen sätter krav på optimering, och jag har också påtalat att det på den punkten kan vara värt kostnaden att skriva i ett mer optimerat statiskt språk. Den kostnaden distribueras ju dessutom på varje klient.
Däremot kan ju en bakomvarande logik skötas av ett högnivåspråk. Se alla stora siter som bygger på Python. Inte så jag tror att den drar igång en ny pythoninterpreter från disk för varje förfrågan. Där sköter webbservern caching o.s.v. medans python står för "logiken". Sammantaget en mycket effektiv miljö i både produktivitet och kapacitet.
Sedan kan man ha åsikter som 486-moddare, men återigen vill få betala någon för att skriva enorma frontends i C. Så får han störa sig på vilken inställning han vill sen.
Det handlar i slutändan ändå om färdigheten hos programmeraren. Det går att skriva mycket effektivt i Python, och det går att skriva mycket ineffektivt och slött i C.
När man pratar servermiljö så är det ganska logiskt att det är en punkt som verkligen sätter krav på optimering, och jag har också påtalat att det på den punkten kan vara värt kostnaden att skriva i ett mer optimerat statiskt språk. Den kostnaden distribueras ju dessutom på varje klient.
Däremot kan ju en bakomvarande logik skötas av ett högnivåspråk. Se alla stora siter som bygger på Python. Inte så jag tror att den drar igång en ny pythoninterpreter från disk för varje förfrågan. Där sköter webbservern caching o.s.v. medans python står för "logiken". Sammantaget en mycket effektiv miljö i både produktivitet och kapacitet.
Sedan kan man ha åsikter som 486-moddare, men återigen vill få betala någon för att skriva enorma frontends i C. Så får han störa sig på vilken inställning han vill sen.
Det handlar i slutändan ändå om färdigheten hos programmeraren. Det går att skriva mycket effektivt i Python, och det går att skriva mycket ineffektivt och slött i C.
På jobbet har de fått dille på att använda excel till ALLT...
Alla "hjälpprogram" som underlättar i produktionen är gjorda i excel och VB.
De läser tex ur databaser genom att skicka förfrågningar till asp-script på servern... vanligtvis används ju internwebben...
Something is about to break
Vet inte om det beror på denna utveckling... men man råkar ut för en del deadlock i andra program nu med... det verkar inte bra...
Vet inte riktigt om detta går att knyta till topic... men kanske till ang. optimerade serverprogram, högnivåspråk eller liknande...
Alla "hjälpprogram" som underlättar i produktionen är gjorda i excel och VB.
De läser tex ur databaser genom att skicka förfrågningar till asp-script på servern... vanligtvis används ju internwebben...
Something is about to break
Vet inte om det beror på denna utveckling... men man råkar ut för en del deadlock i andra program nu med... det verkar inte bra...
Vet inte riktigt om detta går att knyta till topic... men kanske till ang. optimerade serverprogram, högnivåspråk eller liknande...
Det är i grund och botten liknande problem.
Självklart ska man se till att produktionskritiska hjälpsystem
byggs på ett förnuftigt sätt. Det betyder väldigt sällan Excel. Eller
Access som också används frekvent till lokalt hemmapulande på
avdelningsnivå.
Det finns allt för många potentiella problem med detta för att ta upp
här. Förrutom rena tekniska databasproblem som låsningar/deadlocks
tillkommer frågor kring administration, dataintegritet, dokumentation
o.s.v där det ofta brister vid denna typ av "utveckling".
Självklart ska man se till att produktionskritiska hjälpsystem
byggs på ett förnuftigt sätt. Det betyder väldigt sällan Excel. Eller
Access som också används frekvent till lokalt hemmapulande på
avdelningsnivå.
Det finns allt för många potentiella problem med detta för att ta upp
här. Förrutom rena tekniska databasproblem som låsningar/deadlocks
tillkommer frågor kring administration, dataintegritet, dokumentation
o.s.v där det ofta brister vid denna typ av "utveckling".
