Hej!
Är det någon annan än jag som programmerar än jag?
Isåfall, vilket språk?

Yup
You name it, I'm likely to use it.. (fast kanske inte typ varje dag..)

Ada

C, perl, assembler, Verilog.

Ska skippa Veriog till förmån för VHDL som medger mer avancerade triggermöjligheter.

plåtmonster skrev:C, perl, assembler, Verilog.

Ska skippa Veriog till förmån för VHDL som medger mer avancerade triggermöjligheter.

Anser du att Verilog/VHDL är programmeringsspråk? Eller är det syntax för definition av ett beteende i ett elektroniknät med semantiken att definiera hur cellerna i en FPGA/ASIC/etc ska konfigureras?

Det är väl egentligen ett språk för att definiera en konfiguration. Men en uppgift som lätt tillfaller en programmerare. Dock måste man ha absolut koll på signalrace, latens, och omslagstider osv. Något man slipper i imperativa språk.

Funktionella språk är ju annars något som ställer imperativa vanor på huvudet
Eller för all del trådad programmering.

Just race och latens har ju inte så mycket med huruvida en har ett funktionellt eller imperativt språk att göra utan mer hur den exekverande mekanismen arbetar.

Men intressant att du definierar HDL's som just konfigurerande.
Vad ska vi då säga om C? En kan ju tänka att efter kompilering, assemblering och länkning har vi en vektor med ord vars innehåll är en konfiguration som exekveras av den (troligen) von Neumann-maskin som implementerats i kisel (givet en "'hård' processor).

C/C++/Objective-C... och så Javascript och PHP, men intepreterande räknas inte lika mycket även om det är lika mycket programmering

Pieohpah skrev:C/C++/Objective-C... och så Javascript och PHP, men intepreterande räknas inte lika mycket även om det är lika mycket programmering

Vem säger att interpreterade inte gills lika mycket? I vart fall okunnigt av denne/dem.

Skriv en bootstrap för operativsystem i skriptspråk så får du se

plåtmonster skrev:Skriv en bootstrap för operativsystem i skriptspråk så får du se

Hoppas du menade att vara skämtsam eller nå't.
Om inte så har du just avslöjat dig som en av de okunniga (!)

Huruvida ett visst språk är interpreterande eller kompilerande är delvis en fråga om definition.
Gemensamt för alla språk är att de tolkas av något för att utföra de definierade operationerna.

Varje språk har sin tillämpning. För varje språk finns det tillämpningar som inte är lämpliga.

Och för att bemöta ditt skämt(?): Ta vilket interpreterat språk du vill, huruvida du kan skriva en boot i det beror helt på vad processorn har för instruktioner och vad "assemblatorn" kan tolka.

Tja, är det en assembler inblandat så är det väl definitionsmässigt inte ett interpreterat språk vi talar om.
Distinktionen är för all del inte helt glasklar när det gäller t.ex. LISP på hårdvara skräddarsydd för språket.
Dessutom kan ju många interpreterade språk även kompileras och för att komplicera det hela ytterligare kan man kompilera både till maskinkod/assembler och till p-kod/virtuell maskin.
Pratar vi boot-kod torde det vara kompilering/assemblering till maskinkod som är det relevanta.

nallen skrev:Tja, är det en assembler inblandat så är det väl definitionsmässigt inte ett interpreterat språk vi talar om.
Distinktionen är för all del inte helt glasklar när det gäller t.ex. LISP på hårdvara skräddarsydd för språket.
Dessutom kan ju många interpreterade språk även kompileras och för att komplicera det hela ytterligare kan man kompilera både till maskinkod/assembler och till p-kod/virtuell maskin.
Pratar vi boot-kod torde det vara kompilering/assemblering till maskinkod som är det relevanta.

I praktiken har du ju förstås rätt, om vi med "i praktiken" menar hur det ser ut mest nu för tiden.

Men i princip kan en bygga en processor för vilket (dator)språk som helst. LISP-maskinerna var ett exempel på det men det finns konstrukter för t.ex. Python och Forth. (De sistnämnda har inte rönt någon större kommersiell framgång dock.) När väl detta är gjort är det fråga om rak översättning från syntax till maskinspråk enligt den operationella semantik språket har definierat.
Vidare, den gängse innebörden av "assembler" förstår vi båda och på samma sätt. Den principiella skillnaden mellan assembler och kompilator är dock liten. Jag argumenterar att det inte är någon skillnad.
Till sist, den principella skillnaden mellan interpretator och processor är även den liten, om ens någon. Det handlar mest om vilken nivå av virtuell arkitektur en vill prata om.

I assembler kan man skriva allt. Fast det är rätt otympligt

I C kan skriva det mesta och arbetsinsatsen är rimlig.

Men skall man t.ex snabbt bygga upp ett webbsystem med SQL etc, så är skriptspråk som t.ex Perl rätt effektivt och då väljer man det även om man KAN välja C eller assembler. Men ett skriptspråk är i stort sett inkapabelt att hantera systemfunktioner på låg nivå (även C++ har sina sidoeffekter).

Så skriptspråk har absoluta fördelar under vissa förutsättningar, i övriga sammanhang är det skräp.

Något som jag tycker är intressant är funktionella språk. I synnerhet när det finns ett frekvenstak på enskilda processorer. Det tvingar folk att tänka om och stänger vägen att bara höja klockfrekvensen.

Jag tycker termen interpreterat programmeringsspråk är felaktig i sig. Det handlar ju om en implementationsdetalj, inte om språket i sig.

Flera språk som för ett par år sedan benämndes scriptspråk har numer kompilatorer för .Net och JVM, vilka i sin tur kan AOT-kompileras till maskinkod. Med JIT-kompilatorer blir det ännu mer luddigt.
Vidare finns det interpretatorer för C och ingen skulle väl kalla C ett interpreterat programmeringsspråk.

Men självklart lämpar sig olika språk olika mycket för olika typer av implementationer. Dynamiska språk är svåra att skriva effektiva kompilatorer för.

Sammelsurium skrev:Jag tycker termen interpreterat programmeringsspråk är felaktig i sig. Det handlar ju om en implementationsdetalj, inte om språket i sig.

En bra poäng!
Lite i linje med hur jag uppfattar det (och skriver i ovan) men sett ur en annan vinkel.

Sammelsurium skrev:Dynamiska språk är svåra att skriva effektiva kompilatorer för.

Det beror på vilket "dynamiskt språk" vi tittar på och på vilket sätt denna dynamik yttrar sig i det valda språket.
LISP har numera mycket effektiva kompilatorer som ger en snabbhet jämförbar med C! Det tog dock några år av forskande innan detta blev realitet. Lite synd att så många ryggar för detta eminenta språk..
Python är svårare (eller så handlar det återigen om att det måste forskas lite). Kanske beror det på hur objektreferenser löses runtime och att det finns fler grunddatatyper, jämfört med LISP. Kanske blir det även svårare i fallet applikationen använder mycket introspektion.

Men ofta blir det nästan lite typ fånigt att envisas med att skriva kompilatorer för språk som är i grunden definierade utifrån antagandet att det ska finnas en virtuell maskin i botten (Python, Java, C#, Ruby, Lua osv).
Om en först bygger hela systemet i det språk en valt och sedan skriver om de mest tidskritiska delarna i t.ex. C++ och drar in som moduler, som en optimering, så kommer de icke optimerade delarna inte spela någon större roll. Har skrivit tämligen mycket och stora mojjar i Python och där är effekten påtaglig.

lillmupp skrev:Lite synd att så många ryggar för detta eminenta språk..

Vad är det som du tycker är så bra med språket?

lillmupp skrev:

Sammelsurium skrev:Dynamiska språk är svåra att skriva effektiva kompilatorer för.

Det beror på vilket "dynamiskt språk" vi tittar på och på vilket sätt denna dynamik yttrar sig i det valda språket.
LISP har numera mycket effektiva kompilatorer som ger en snabbhet jämförbar med C! Det tog dock några år av forskande innan detta blev realitet. Lite synd att så många ryggar för detta eminenta språk..
Python är svårare (eller så handlar det återigen om att det måste forskas lite). Kanske beror det på hur objektreferenser löses runtime och att det finns fler grunddatatyper, jämfört med LISP. Kanske blir det även svårare i fallet applikationen använder mycket introspektion.

En kul bieffekt av "den nya webben" är all forskning och utveckling som läggs på att kunna exekvera Javascript snabbare. Den kunskapen kan sedan användas för att utveckla snabbare implementationer av andra dynamiska högnivåspråk.

För Python har det gjorts en hel del forskning i PyPy-projektet. LuaJIT är ett annat bra exempel.

Men ofta blir det nästan lite typ fånigt att envisas med att skriva kompilatorer för språk som är i grunden definierade utifrån antagandet att det ska finnas en virtuell maskin i botten (Python, Java, C#, Ruby, Lua osv).

Jo, men samtidigt är det rätt trevligt att kunna skriva en naiv implementation av ett one off-script, köra det i PyPy istället för CPython och se hastigheten öka ~40x (även om PyPy är en JIT-kompilator och inte AOT).

Eller så definierar man ett språk som är tänkt för denna flexibilitet..

Det går att använda en skiftnyckel som hammare, men det är ingen bra lösning.

plåtmonster skrev:

lillmupp skrev:Lite synd att så många ryggar för detta eminenta språk..

Vad är det som du tycker är så bra med språket?

Jag har väl en särskild vurm för parenteser..

Mer seriöst, den extremt enkla syntaxen är närmast poetiskt vacker Introspektion är totalt integrerat. Det är trivialt att välja pre- kontra post-order evaluation (eller om du vill, partialevaluering). Givetvis även möjligheten att skriva kod som skriver kod som sedan exekveras. Den totala konsekvensen i att alla anrop sker vad som betraktas som funktioner (och ja, jag vet att det finns implementationer som gör avsteg).

Sammelsurium skrev:Jo, men samtidigt är det rätt trevligt att kunna skriva en naiv implementation av ett one off-script, köra det i PyPy istället för CPython och se hastigheten öka ~40x (även om PyPy är en JIT-kompilator och inte AOT).

Visst är det najs! Men kanske just det, najs.
Cython finns ju också, men då får en välja bort vissa konstruktioner. Det blir fart iaf
IronPython är en CLR-front och det kan ju vara användbart. Hur snabbt det blir vet jag inte men jämförelsen ska ske mot C# m.fl.

Just CPython ska ju, i en prestandastudie, ses som en referensimplementation av språket och dess runtime mm
De diskussioner jag brukar se går ut på att klaga på ditt och datt men det blir fånigt för van Rossum är ju tydlig med vilka aspekter som inte ens addresseras. (Thread safety är ett exempel som är lite udda hanterat med GIL)

plåtmonster skrev:Eller så definierar man ett språk som är tänkt för denna flexibilitet..

Det går att använda en skiftnyckel som hammare, men det är ingen bra lösning.

I princip det jag försöker säga så vi är väl ense då..

Svarar lite kort (trööött).

Just nu på jobbet har det varit Perl, SQL ("Inte Direkt Programmering" (IDP) ?), lite Java, Bash/Ksh Unixskript. Tidigare var det C, HTML (IDP), CSS, Javascript, XML (IDP), lite XSL.


[ Fritiden/skolan, de flesta decennier sedan: Python (lite), C++, Java, Forth (lite), Basic, Assembler (6502, 68000, NS32032), Pascal.]

SQL kan vara väldigt mycket programmering, T-SQL är ett väldigt kraftfullt språk.