Kimmelie skrev:Jag håller på och lär mig Python, men har inte kommit så långt än. Annars skulle jag gärna hakat på ert projekt. Den här tråden stärker min övertygelse om att det var ett klokt val att börja med Python. (Har tänkt lära mig C också, nån gång i framtiden...)

Jag var helfrälst på Java och C++ fram till något år sedan då jag började med Python, nu vill jag aldrig använda något annat. Tror det är säkert att säga att jag aldrig kommer återvända till Java/C++.

Sjukt bra språk! Mycket straight-forward och effektivt att utveckla med. Det enda jag stört mig på är dessa förbannade UnicodeDecodeErrors man får dras med i början, men de försvinner sakta men säkert.

****************

Jag gillar KOM. Tyvärr är de flesta skadade efter att ha exponerats av phpBB och liknande under lång tid, så det är nog ingen realistisk lösning. Kanske saknas "användarvänliga" klienter också.
Mycket enklare sätt att läsa forum på, dock.

Håller med om vad som skrivits om Python. Unicode-problemen i Python2 kommer från gamla dagar, då en sträng var detsamma som en sekvens med bytes. Python2 har både str-objekt (byte-strängar) och unicode-objekt (Unicode-strängar) med samma interface. Det är fixat i Python3.

PyPy är något man bör ha i bakhuvudet om man programmerar i Python. En JIT-kompilator för Python som fungerar förvånansvärt väl. Fler än en gång har jag funderat om jag måste skriva om diverse småverktyg i något lågnivåspråk men istället kört scriptet i PyPy, 10-20x snabbare.

Python? Jag har lite svårt för språk som är känsliga för indentering. Det är tillbaka till 50-talet, innan man kommit på vitsen med kontextfria språk.

Det fungerade acceptabelt i FORTRAN IV på hålkort och det fungerar faktiskt förvånansvärt vettigt i Python. Det finns andra delar av det smäcket som jag tycker sämre om.

nallen skrev:Det fungerade acceptabelt i FORTRAN IV på hålkort och det fungerar faktiskt förvånansvärt vettigt i Python. Det finns andra delar av det smäcket som jag tycker sämre om.

Visst går det, men varför återinföra problem som man lärde sig att slippa för 50 år sedan?

Det är inte ett problem i Python, det faller sig helt naturligt efter ett par dagar. För 50 år sen hade vi inte språkkänsliga editorer heller.

Men, jag är fel människa att försvara Pyton. Jag gillar det inte; det går inte att kompilera och länka som riktiga språk, det kräver att jag använder self-variabeln hela tiden men tillåter inte att jag ger den ett vettigt namn (i C++ behöver jag sällan använda den och i Ada är den en parameter vilken som helst och kan således ha vettiga namn).

Kvasir skrev:

nallen skrev:Det fungerade acceptabelt i FORTRAN IV på hålkort och det fungerar faktiskt förvånansvärt vettigt i Python. Det finns andra delar av det smäcket som jag tycker sämre om.

Visst går det, men varför återinföra problem som man lärde sig att slippa för 50 år sedan?

Berätta mer! Jag har som sagt bara väldigt liten erfarenhet av Python och när animal talar låter det ju helt annorlunda.

*tar en påse popcorn i väntan på en intressant föreläsning och historik*

weasley skrev:

Kvasir skrev:

nallen skrev:Det fungerade acceptabelt i FORTRAN IV på hålkort och det fungerar faktiskt förvånansvärt vettigt i Python. Det finns andra delar av det smäcket som jag tycker sämre om.

Visst går det, men varför återinföra problem som man lärde sig att slippa för 50 år sedan?

Berätta mer! Jag har som sagt bara väldigt liten erfarenhet av Python och när animal talar låter det ju helt annorlunda.

*tar en påse popcorn i väntan på en intressant föreläsning och historik*

Nja, det får bli kort och snabbt bara. Jag kommer inte ihåg den exakta syntaxen i just Python, men principen är att du markerar block med indentering. Tänk dig att du slopar "måsvingarna" i C/C++. Då skulle det plötsligt vara skillnad på

Kod: Markera allt

if villkor
  sats1;
  sats2;

och

Kod: Markera allt

if villkor
  sats1;
sats2;

I det första fallet exekveras sats2 bara om villkoret är uppfyllt, medan i andra fallet exekveras sats2 alltid.

Även om det delvis är en myt att man kraschade en satellit pga ett missat blanktecken i ett Fortranprogram, så fanns det i princip sådana problem i Fortran, vilket ledde till att man fortsättningsvis försökte konstruera programspråk som inte var känsliga för den typen av fel. T.ex. ska ett missat eller extra blanktecken antingen ge felmeddelande eller inte påverka betydelsen.

Just det är är väl ändå ett bra exempel på varför det är bra att styra det med indentering istället för med en blockkonstruktion som är en sats.
I Ada är blocket obligatoriskt, det kan inte ersättas av en ensam sats.

nallen skrev:Just det är är väl ändå ett bra exempel på varför det är bra att styra det med indentering istället för med en blockkonstruktion som är en sats.
I Ada är blocket obligatoriskt, det kan inte ersättas av en ensam sats.

Ada är utmärkt tänkt på den punkten. Tyvärr fick det och dess idéer inte så mycket genomslag.

Jag använder det inte dagligen längre... men jag hoppas på ändring till det bättre på den punkten i höst.

Kvasir skrev:

weasley skrev:

Kvasir skrev:Visst går det, men varför återinföra problem som man lärde sig att slippa för 50 år sedan?

Berätta mer! Jag har som sagt bara väldigt liten erfarenhet av Python och när animal talar låter det ju helt annorlunda.

*tar en påse popcorn i väntan på en intressant föreläsning och historik*

Nja, det får bli kort och snabbt bara. Jag kommer inte ihåg den exakta syntaxen i just Python, men principen är att du markerar block med indentering. Tänk dig att du slopar "måsvingarna" i C/C++. Då skulle det plötsligt vara skillnad på

Kod: Markera allt

if villkor
  sats1;
  sats2;

och

Kod: Markera allt

if villkor
  sats1;
sats2;

I det första fallet exekveras sats2 bara om villkoret är uppfyllt, medan i andra fallet exekveras sats2 alltid.

Även om det delvis är en myt att man kraschade en satellit pga ett missat blanktecken i ett Fortranprogram, så fanns det i princip sådana problem i Fortran, vilket ledde till att man fortsättningsvis försökte konstruera programspråk som inte var känsliga för den typen av fel. T.ex. ska ett missat eller extra blanktecken antingen ge felmeddelande eller inte påverka betydelsen.

Verkar som du också för min talan i den här frågan, vare sig du vill eller ej. Jag hade en klasskamrat här under vårterminen som brukade retas med mig och säga "använder du indentering för att skapa block är du garanterad en plats i helvetet"... Ett par månader sedan började han själv lära sig Python och insåg snabbt vitsen med det och började komma med nyfikna frågor istället för pikar. En liten anekdot bara...

Vitsen är naturligtvis att det a) skapar en visuell och entydig struktur för all kod (oavsett vad man har för skit bakom ratten), b) tar typ 50 % mindre tid att klicka på tab resp. backspace än att göra måsvingar och c) man slipper arslen som envisas med att sätta måsvingarna fel, typ

Kod: Markera allt

void callHome(int[] foo)
{
    /.../
}

istället för korrekt placering av måsvingarna:

Kod: Markera allt

void callHome(int[] foo) {
    /.../
}

[Holy war]
Funktionsdefinitioner i C-liknande språk ska ha måsvingarna i kolumn 1 (undantaget indentering för namnrymder).

Kod: Markera allt

void
CallHome (int [] number)
/**
 *  Exempel på hur en korrekt funktionsdefinition skall se ut.
 */
{
   ;
} /* int CallHome (int []) */


Slutsignaturen kontrolleras av pre-commit script som slår dig på fingrarna om du inte gjort rätt.
[/Holy war]

nallen skrev:[Holy war]
Funktionsdefinitioner i C-liknande språk ska ha måsvingarna i kolumn 1 (undantaget indentering för namnrymder).

Kod: Markera allt

void
CallHome (int [] number)
/**
 *  Exempel på hur en korrekt funktionsdefinition skall se ut.
 */
{
   ;
} /* int CallHome (int []) */


Slutsignaturen kontrolleras av pre-commit script som slår dig på fingrarna om du inte gjort rätt.
[/Holy war]

Det här kan vi garanterat bråka om länge länge utan att någon ger sig... Typexempel på varför det är jobbigt att sätta sig in i andras kod.

I Python är det desto enklare:

Kod: Markera allt

def myfavorites(apply_censorship=True):
    """Example of a best practices function definition using Python.
       
    Arguments:
        apply_censorship: Blah blah blah...
    Returns:
        Blah blah blah...
    """
   
    /.../

print myfavorites() # Short comment.

Sedan är det bara att autogenerera dokumentationen med PyDoc istället för Javadoc. Ingen diskussion och inget utrymme för meningsskiljaktigheter.

Eller..

Kod: Markera allt

void
/**
 *  Exempel på hur en korrekt funktionsdefinition skall se ut.
 */
CallHome (int [] number) {
   ;
} /* CallHome() */

Brukar iofs sätta tydlighet och läslighet, samt till viss mån effektivt att skriva som överordnat mål framför ev regler. Men just indentionskänsliga språk får iaf mig att bli tveksam. Om problemet sitter 404 mm bakom ratten så är det där som problemet ska åtgärdas istället för att skruva fast ratten så att den endast klarar rakkörning. Samma problematik dyker upp på universiteten där man använder "hårt typade" språk för att studenterna ej bedöms klara av något annat. Men matematik ska visst gå bra, och där finns definivt ingen kompilator som skriker om man glömmer något.

animal skrev:Ang. funktionell programmering så är det en av styrkorna hos Python – språket ger utvecklaren rätt stor frihet att välja paradigm efter smak och kontext. Orka tillverka ett forum i Lisp liksom? Är det något du helt uppriktigt skulle överväga som ett konkurrenskraftigt alternativ?

Funktionell programmering ger ett helt annat perspektiv på hur man kan lösa programmeringsproblem. Jag tror inte att det lämpar sig för projektet med forummotor. Men om man nu tar med t.ex även Lisp i diskussionen. Så det som gäller är att hitta det språk där man kan uttrycka sitt problem på det mest effektiva sättet. Kan man ej språket så lär man sig det. Jobbigt, men man har igen det sedan. I slutändan gäller det att överväga alla alternativ och inte dra sig för att välja jobbiga om de uppfyller målkraven.

Läste om en utvecklare som konkurrerade med en storkoncern om ett e-handelssystem där storföretaget använde ett skriptspråk medan den oberoende utvecklaren använde Lisp. I slutändan vann den oberoende utvecklaren som använde Lisp just för att han kunde uttrycka sitt problem snabbare och effektivare än sin konkurrent. Lisp är uppenbarligen komplext, men om det är effektivt så kan det vara värt att lära sig.

När det gäller ADA så är VHDL inspirerat av detsamma, och det avskräcker
(Verilog är mycket populärare..)

Det finns 10 sorters människor, de som C:er framtiden och de som inte gör det

Naturligtvis ska man använda indentering för att ange blockstrukturen, av läsbarhetsskäl, men det är farligt om betydelsen hänger på det eftersom det är så lätt att råka ändra indenteringen av misstag och ingen editor kan veta hur det är tänkt. Tro mig, jag har provat Python. Jag hade svårt att ens komma ihåg själv hur det skulle vara när jag råkat sabba indenteringen.

Sedan gillar jag egentligen inte måsvingarna i C/C++ heller, eftersom det inte finns något riktigt snyggt och bra sätt att skriva dem för att förtydliga blockstrukturen. Ada och liknande lösningar är överlägset på denna punkt.

Ovanstående gäller förstås bara imperativa språk. Funktionella och deklarativa språk har vanligen en helt annan typ av syntax i grunden.

plåtmonster skrev:Lisp är uppenbarligen komplext, men om det är effektivt så kan det vara värt att lära sig.

Lisp är inte det minsta komplext. Tvärtom är det väldigt enkelt och logiskt. Dock kan det förefalla svårt och konstigt i början om man är väldigt inkörd i det imperativa tänkandet.
Därmed inte sagt att Lisp är ett lämpligt språk till alla applikationer. Sedan finns modernare funktionella språk som möjligen är bättre, men de har jag ingen koll på.

Kvasir skrev:Även om det delvis är en myt att man kraschade en satellit pga ett missat blanktecken i ett Fortranprogram, så fanns det i princip sådana problem i Fortran, vilket ledde till att man fortsättningsvis försökte konstruera programspråk som inte var känsliga för den typen av fel. T.ex. ska ett missat eller extra blanktecken antingen ge felmeddelande eller inte påverka betydelsen.

Felet lär ha varit att det var ett komma istället för en punkt (eller tvärtom) vilket gjorde att kompilatorn svalde det, men vid exekveringen blev resultatet väldigt fel...

@weasley, borde inte den här tråden delas så att diskussionen om programspråk blir en egen tråd?

Miche skrev:

Kvasir skrev:Även om det delvis är en myt att man kraschade en satellit pga ett missat blanktecken i ett Fortranprogram, så fanns det i princip sådana problem i Fortran, vilket ledde till att man fortsättningsvis försökte konstruera programspråk som inte var känsliga för den typen av fel. T.ex. ska ett missat eller extra blanktecken antingen ge felmeddelande eller inte påverka betydelsen.

Felet lär ha varit att det var ett komma istället för en punkt (eller tvärtom) vilket gjorde att kompilatorn svalde det, men vid exekveringen blev resultatet väldigt fel...

Ja, historien förekommer i olika versioner, varav den med blanktecknet är en, men som inte verkar vara den riktiga. Det förefaller också vara en myt att en satellit faktiskt kraschade. Felet hann upptäckas tidigare. Dock bidrog nog denna händelse till att sätta fokus på problemen med Fortrans syntax.

Roliga programmeringsfel finns det gott om. Vi har det amerikanska stridsplanet som plötsligt vände upp och ned när det passerade ekvatorn, pga. ett teckenfel. Detta lär dock ha upptäckts i simulator innan det inträffade i verkligheten.

En marslandare som räknade fel när den skulle bromsa in i Mars atmosfär, NASA hade specificerat programvara i metriska systemet, men amerikanerna som utförde själva programmeringen använde det gamla systemet (vilket inte de två andra programmeringsteamen gjorde), men det är en helt annat typ av fel... Det upptäcktes inte i simulator!

Tipsar om.. RISKS Digest
NASA har för övrigt infört SI över hela linjen numera vad jag vet.

Men huvudfrågan kanske kan återformuleras så här "vilket språk är det mest lämpade för att skriva en ny forummotor i?".

Är det inte lite väl mycket mental masturbation över den här tråden just nu?

animal skrev:Det här kan vi garanterat bråka om länge länge utan att någon ger sig...

Jo, det är ju därför det brukar kallas för heliga krig. Samma med att bestämma om vi eller Emacs är bästa texteditorn.

animal skrev:Typexempel på varför det är jobbigt att sätta sig in i andras kod.

Det förstår jag däremot inte, så länge det är något så när konsekvent och inte helt galet så tycker jag inte att det spelar någon större roll för läsbarheten. Det är lite jobbigt i några veckor att byta stil när granskningsverktygen rapar ur sig några hundra anmärkningar på kod som såg helt korrekt ut i det förra projektet. Men men, sånt är programmerarlivet.

Om jag förstod trådämnet rätt, handlade det om att göra ett försök att förbättra forumet.
Numera handlar det snarast om vem som kan argumentera bäst för diverse språk.

Det hela liknar dom meningslösa projektmöten jag suttit av då jag fortfarande var tvungen att slita för brödfödan, dom handlade ofta bara om att vissa personer ville göra sin röst hörd .

Tror diskussionerna här har samma inverkan på entusiasterna som hade ett mål, som våra projektmöten hade. Man tappade helt lusten att över huvud taget göra något.

Mina programeringskunskaper begränsar sig ill att skriva hej world i C++. Därför lägger jag mig inte i programspråken. Men här verka finnas tillräckligt med kunskaper för att fixa åtminstone fem nya forum.