AVR32Studio - Java!?

[speakman]

vfr: Hela poängen med såna högnivåspråk som Python är just att du inte behöver bry dig om det.

[sodjan]

Löst typade språk: lite "enklare" programmering men samtidigt lättare att få skitfel.

Hårt typade språk: Man fär göra lite mer jobb, men resultatet blir stabilare och snabbare.
Kompilatorn kan göra med kontroller vid "compile-time" som annars måste göras i "run-time"
vilket tar tid och resurser.

Det ena är inte nödvändigtsvis bättre är det andra, de har bara olika användningsområden.

> Hela poängen [...] är just att du inte behöver bry dig om det.

Just att inte "bry sig" om viktiga saker är väl just ett stor anledning till
att många IT projekt i dag kraschar. Man förstår helt enkelt inte vad man
håller på med och hur det (t.ex) skalar.

[speakman]

Mycket skitsnack, sodjan. Så om man varje gång måste ta hänsyn till variabelbredder så blir det aldrig fel? Och på vilket vis blir ett hårt typat språk stabilare?

Det är klart att ett helt kompilerande språk i princip måste ha hård typning, men det enda man får ut av det är väl ändå hastigheten?

Din slutledning är hsh att stora projekt bara går att göra i hårt typade språk? Suck...

[arte]

Löst typade språk: lite "enklare" programmering men samtidigt lättare att få skitfel.

Hårt typade språk: Man fär göra lite mer jobb, men resultatet blir stabilare och snabbare.
Kompilatorn kan göra med kontroller vid "compile-time" som annars måste göras i "run-time"
vilket tar tid och resurser.

Det ena är inte nödvändigtsvis bättre är det andra, de har bara olika användningsområden.

Just att inte "bry sig" om viktiga saker är väl just ett stor anledning till
att många IT projekt i dag kraschar. Man förstår helt enkelt inte vad man
håller på med och hur det (t.ex) skalar.

Håller verkligen med, för tools och för mindre saker så är det jätte bra med mera lösa program språk men i stora projekt med flera olika utecklare, verktyg och miljöer så måste man minimera riskerna för fel.
Man kan inte alltid lita på att någon annan utecklare någonstans har gjort rätt, bättre ifall språket isig minimerar felen

Ofta läser man att pyhton är så himla bra för det är mindre rader och kortare ord i python än i t.ex JAVA, kan ibland vara rätt meningslöst anser jag. Skälva skrivandet i programmeringen är inte den stora biten.
Specielt när man i IDEer sällan behöver skriva så mycket skeletkod utan all går att generera med kortkommandon.


Men som sagt, alla har väl olika preferenser.

[Icecap]

Jag ställer mig på sodjan och arte's sida i detta, kör man "ensam-projekt" kan hårdare typning fortfarande vara en fördel i mitt tycke.

[sodjan]

> Det är klart att ett helt kompilerande språk i princip måste ha hård typning, men det enda man får ut av det är väl ändå hastigheten?

Hastighet plus att mycket kontroller redan är gjorda vid "compile-time". Många skitfel kan
också enklare fångas upp av kompilatorn i hårt typade språk. Och det är ju inte så att
prestandan/hastigheten på koden bara är en liten skitsak, det är det kanske helt avgörande
för hur resultatat skalar i produktion.

> Och på vilket vis blir ett hårt typat språk stabilare?

Jag tyckte jag sa det. Man måste "bry sig" mer om vad man håller på med. Kompilatorn har lättare
att fånga upp fler olika fel i koden. O.s.v. Det är ju inte direkt något konstigt med det.

> Din slutledning är hsh att stora projekt bara går att göra i hårt typade språk? Suck...

Det sa jag väl inte riktigt.
Jag sa att många stora IT projekt poå senare tid har kraschat p.g.a *bl.a* p.g.a av att
dagens programmerare har lärt sig (bl.a genom "moderna" verktyg) att man inte behöver "bry sig".
Hård/lös typning är bara en del i detta, men det hänger ofta ihop med den typ av verktyg
som har använts i denna typ av projekt. D.v.s verktyg som t.ex är lite svåra att bedöma
hur de "skalar".

> Så om man varje gång måste ta hänsyn till variabelbredder så blir det aldrig fel?

Vad menar du med "variabelbredder" ? Och "aldrig" är ett lite stark ord...

[speakman]

Så nu är det amatörer som använder löst typade språk? Eller var vill du komma?

Naturligtvis *kan* man göra fel. Men jag förutsätter naturligtvis att det är professionell utveckling, och där har man vanligtvis utvecklingsmetoder som exempelvis Test-Driven Development som är väldigt populärt.

För större kollaborativa projekt sköter man källkodshanteringen med distribuerade verktyg och skickar patchar in till mainline genom en patch queue manager som först går igenom den inskickade koden, sedan försöker merga in den i mainline-branchen och slutligen kör igenom alla testsuites i projektet.

På så vis undviker man fel som skulle uppstått oavsett typning, och det finns ingen direkt anledning att söka semi-säkerhet i ett typat språk.

Men vill man bara sitta själv och kodonanera så kanske man behöver hårt typade språk för att inte göra bort sig?

[sodjan]

> Så nu är det amatörer som använder löst typade språk?

Det var fasen vad du läser in mycket mellan raderna...

Problemet är att det inte spelar den minsta roll hur proffsig man är, vilka fantastiska projektmodeller
man använder eller vad man använder för verktyg för code-management, det hjälper inte om man
i alla fall sitter och jobbar med fel verktyg. Det är också fullständigt klart att man inte kan *testa* sig till
lyckade projekt. Det är ju å andra sidan inte så konstigt att "test-driven development" har blivit så
populärt i och med de utvecklingsmetoder som har kommit på modet under senare tid. Det är lite
märkligt eftersom det inom andra områden (som t.ex tillverkning av vanliga "prylar") är helt klart
att brister i början av processen aldrig kan uppvägas av tester senare i processen. Samma tankesätt
kan naturligtsvis även appliceras på programutveckling.

Jag sa också att det inte *enbart* handlar om just typningen, men det hänger ihop med annat
i dessa miljöer som gör att de är fel verktyg i vissa fall (typ de system som Försäkringskassan behöver,
även om det kanske inte var Python i det fallet, men du förstår tanken i alla fall).

Jag är helt övertygad om att Försäkringskassan hade lyckats bättre till lägre kostnad om man hade
köp in ett par "System z10 Enterprise Class" och utvecklat rubbet i COBOL med intern personal
i stället för SAP (m.m.) med inhyrda konsulter...

> För större kollaborativa projekt...skickar patchar in till mainline... merga in den i mainline-branchen...

Hm, jag var på en dragning för någon månad sedan där källkodshanteringen inom OMX beskrevs.
Väldigt intressant. Inte bara har de det du beskriver ovan (vilket ju är ganska standardmässigt) utan
de ska också när som helst kunna "dra ut" den aktuella koden som t.ex börsen i Shanghai eller
värdepappeshandlen i New York kör *just nu* och köra den i deras testanläggning. Det finns alltså
inte en enda "mainline" utan ett separat kodspår för varje installation som OMX har runt världen.
Och vissa ändringar ska patchas in i en kundspecifikt kodspår, andra, mer generella, patchar ska
in i alla kodspår. De har tittat på verktyg som cvs och de andra liknande populära prylarna, men
de räcker helt enkelt inte riktigt till.

Slutligen så sa jag också att dessa verktyg (*typ* Python) visst har sina användningsområden. Jag
använder själv Python till vissa saker, där just Pythons fördelar överväger, men det skulle
aldrig gå att ersätta kärnan i det systemet med samma funktionallitet skriven i Python...

Men, vad vet jag, jag har bara pysslat med programutveckling i knappt 30 år...

[speakman]

[..] aldrig kan uppvägas av tester senare i processen. Samma tankesätt
kan naturligtsvis även appliceras på programutveckling.

Hade du bemödat dig läsa om TDD så hade du sett att det innebär att man gör testerna *före* man skriver kod.

Jag är helt övertygad om att Försäkringskassan hade lyckats bättre till lägre kostnad [..]

Jag är iofs helt övertygad att du inte ens är insatt i Försäkringskassans krav och system. Jag är också ganska säker att det blev mycket mer komplicerat än någon expert ens kunnat tänka sig, med tanke på hur det gick (går?). Du kanske borde maila och erbjuda dina tjänster? Det gick ju ganska fort att hitta en lösning åt dom här nu.

> För större kollaborativa projekt...skickar patchar in till mainline... merga in den i mainline-branchen...

Det här var en väldig förenkling. Alternativet hade antagligen blivit ett par sidor.

Inte bara har de det du beskriver ovan (vilket ju är ganska standardmässigt) utan
de ska också när som helst kunna "dra ut" den aktuella koden som t.ex börsen i Shanghai eller [..]

Det du beskriver är standard inom de flesta open source-projekt idag. Det hade ingått i mitt alternativ under citeringen ovan.

De har tittat på verktyg som cvs och de andra liknande populära prylarna, mende räcker helt enkelt inte riktigt till.

Var du på dragningen för några månader sedan eller några decennier sedan? CVS använde man på "typ 70-talet". Sa jag inte distribuerade system? Se t.ex. när Linus Torvalds talar om Git som är det som används för Linuxkerneln. Han nämner även några "värmande" ord om CVS där...

Själv använder jag främst Bazaar som är lika kompetent som Git fast gör saker på ett litet annorlunda vis och enligt mig är lite enklare att komma igång med. Dessutom kan man med Bazaar nyttja Launchpad som är en grymt bra tjänst för kollaborativa projekt. Bazaar är även sedan ett år en del av GNU-projektet. Men tyvärr är det skrivet i Python så det borde vara både litet och osäkert.

Slutligen så sa jag också att dessa verktyg (*typ* Python) visst har sina användningsområden. Jag
använder själv Python till vissa saker, där just Pythons fördelar överväger, men det skulle
aldrig gå att ersätta kärnan i det systemet med samma funktionallitet skriven i Python...

Inte sagt att det inte finns användning för andra språk. Jag är ju rätt tacksam att Linux utvecklas i C t.ex..

Men, vad vet jag, jag har bara pysslat med programutveckling i knappt 30 år...

Fast jag får ibland känslan av att du knappt sysslat med programutveckling *på* 30 år...

[sodjan]

Seems as we agree to disagree...

[speakman]

Det är inte att underskatta att iallafall vara överens om *nånting*

Vill dock rekommendera en till video där Greg Kroah-Hartman (som har ansvar för stora delar av Linuxkerneln) går igenom hur den otroligt snabba utvecklingen av kerneln hanteras. Tyvärr dör min webbläsare när jag besöker Firefox just nu, men några siffror från LKML:

Turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did:
lines added per day: 4945
lines removed per day: 2006
lines modified per day: 1702

And note, that is real stuff, not renames or file moves at all, git
handles not reporting that.

"Projekthantering" på mjukvara är ett stort men väldigt intressant område!

[AAVE]

lite OT, men har ni hört detta uttyck förut?

"code for readability, not writeability"

Python är hur kul som helst för små projekt. Men när projektet växer går utvecklingen långsammare och långsammare. För C, C++, Java m.fl. gäller det motsatta, när man väl har fått en stabil bas så blir det faktiskt mycket enklare att fortsätta koda.

vilket leder oss till följande:

Python provides you with a good environment for quickly developing an initial prototype. ...Once you’re satisfied with the GUI interface or program output, you can translate the Python code into C++, Fortran, Java, or some other compiled language.

Kika gärna på Python Advocacy HOWTO där ovanstående har stulits från

---

För övrigt vill jag påpeka att Eclipse är industristandard IDE för (bl.a.) inbyggda system. Kan det vara så att det finns fördeler med utvecklingsmiljön som du inte känner till?

[speakman]

Python är hur kul som helst för små projekt. Men när projektet växer går utvecklingen långsammare och långsammare. För C, C++, Java m.fl. gäller det motsatta, när man väl har fått en stabil bas så blir det faktiskt mycket enklare att fortsätta koda.

Du glömde motivera *varför*? Den normala upplevelsen är oftast tvärt om; Python går väldigt snabbt att koda i, oavsett projektets storlek (vad f-n skulle det ha med språket att göra?) men är inte lika snabbt att exekvera som kompilerade program.

Ditt lösryckta citat handlar förresten om att man *kan* använda Python även om man främst jobbar med andra språk just för att ta fram en prototyp. Inget säger att du *bör* konvertera koden, bara att det går. Hela dokumentet verkar rikta sig främst till företag som redan sysslar med utveckling av proprietära program, även om det inte framgår bokstavligt.

Däremot glömde du citera andra delar av det där dokumentet:

A common approach is to write a Python module that implements the lower level operations; for the sake of speed, the implementation might be in C, Java, or even Fortran. Once the primitives are available to Python programs, the logic underlying higher level operations is written in the form of Python code. The high-level logic is then more understandable, and easier to modify.

Det är ju inte helt ovanligt att större Python-moduler har en C-variant för att öka hastigheten, många gånger markant som i fallet cElementTree t.ex..

Eller varför citerades inte det här?

Python is definitely not a toy language that's only usable for small tasks. The language features are general and powerful enough to enable it to be used for many different purposes.

Och sånt här får min första fråga här ovan att aktualiseras ytterligare:

It's certainly possible to write confusing code by using too many features with too little concern for clarity, but most Python code can look a lot like a slightly-formalized version of human-understandable pseudocode.

Precis som med alla språk *går* det att skriva dålig kod, men rätt skrivet (vilket man får förutsätta att en Python-kodade kan) så blir det näst intill exekverbar psuedokod.

Så återigen, vad mer precis är det som gör just *språket* Python svårt att använda i större projekt?

[sodjan]

> vad mer precis är det som gör just *språket* Python svårt att använda i större projekt?

Det är inte så mycket *språket* i sig (Det är rellativt trevligt) och det är inte "svårt att använda" som är problemet.
(Kanske att "lätt att använda" igentligen är ett av problemen... )

Det är implementeringen (som det till viss del har gemensamt med Java, VB och andra "halv-kompilerande" verktyg)
som gör det till kanske det inte mest effektiva verktyget i "större projekt" (vad fasen nu *DET* är )...
Men visst, Python's C-API gör det lättare att fason på de delar som inte "presterar" tillräckigt.

Ganska meningslös diskussion igentligen, det handlar bara om rätt verktyg till rätt behov (som alltid).
Ska man bygga en garage eller ett 5-vånings parkeringshus ? Man kan även göra som t.ex Google
och bygga tusen garage istället för ett gemensamt parkeringshus... Det ser ju ut att
fungera även det...

[AAVE]

låt mig upprepa:
"code for readability, not writeability"

många argumnetrar att deras språk är bättre än andra eftersom den är mer "kompakt" än andra språk. Man behöver bara x rader för att koda en hello-world/webserver/nya world of warcraft/etc jämfört med C/C++/Java/C#/osv som behöver hela x^y rader kod för att åstadkomma samma sak. Vad man inte så gärna pratar om är att det är rätt jobbigt att underhålla den kompakata koden. det ser vi idag på många python projekt som har växt ur kostymen och utvcklingen har mer eller mindre avstannat pga av problem med "maintainability" och buggar (som många ggr uppkommer pga pythons "utvecklarvänlighet" som var så trevligt när projektet startade).


PS. själv har jag inga större problem med prestandan. gåt det för långsamat kodar jag om det i C eller Java (!), men det är inte så ofta man behöver det.