Den frie kafeen

[rockPaperScissors()]

Sikkert perl til javascript compiler med litt html.

 

Det finnes flere aktuelle alternativer til php for webutvikling.

Endret 30. mars 2015 av rockPaperScissors()

[Lycantrophe]

Hvordan ville stacken din for å utvikle en nettside/webapp sett ut Lyc, siden du ikke liker hverken php eller javascript?

Det antar at jeg hadde skrevet en webapp. Men ettersom jeg ikke har flanellskjorte og helskjegg og gummistøvler (aka ikke strabuckssippende ultrahipster med mac) er det usannsynlig.

 

Utover det, et av språkene under approved. Antagelig haskell.

[efikkan]

Alt til sin bruk, som jeg bruker å si.

 

Men ikke kom her og snakk stygt om C.

 

Lisp, vel det er interessant men det stopper vel der.

 

Pascal er forøvrig et vakkert språk, bare synd at Borland kjørte alt i grøften. (Object)Pascal er på en del områder penere semantisk enn f.eks. C++.

 

PHP hører forøvrig ikke i samme kategori som ondskapen selv: JavaScript. PHP er riktig nok litt "stygt", men det meste av tragisk PHP-kode skyldes misbruk av elendige utviklere.

[Emancipate]

Hva konkret er problemet med javascript?

[stigfjel]

Men ikke kom her og snakk stygt om C.

Nei, det blir for dumt. C er jo tross alt det språket de fleste språk baserer seg på.

[efikkan]

Dennis Ritchie er virkelig en person som har satt spor etter seg.

[Lycantrophe]

Men ikke kom her og snakk stygt om C.

Jeg gjør i grunn ikke det. Jeg liker C.

 

Men. Problemet er fort mangelen på en del (moderne) ting som gjør at mye C-kode blir bug-prone og mye jobb å maintaine. Derfor anbefaler jeg sjelden C for nye prosjekter, med mindre det er en veldig god grunn. SOm det av og til er.

Endret 30. mars 2015 av Lycantrophe

[toreae]

Synes det er litt søtt når disse diskusjonene dukker opp med 3 ukers mellomrom. 

 

 

(Min karriere er forøvrig CBM64-basic og maskinkode på samme Commadoren. Den karrieren tok en brå slutt da en kamerat klarte å helle cola på den.)

[rockPaperScissors()]

Synes det er litt søtt når disse diskusjonene dukker opp med 3 ukers mellomrom. 

Ventet nesten på at administrator skulle stenge tråden for avsporing, dette er jo tråden for konsoll-editorer og hvilken distribusjon som er best.

 

vim>

[kpolberg]

Du mener den som alltid ender opp med?

[rockPaperScissors()]

Den ja.

Jeg skriver hjkl og esc over alt når jeg ikke bruker vim.
 

[PhelpsTransposed]

 

Men ikke kom her og snakk stygt om C.

Jeg gjør i grunn ikke det. Jeg liker C.

 

Men. Problemet er fort mangelen på en del (moderne) ting som gjør at mye C-kode blir bug-prone og mye jobb å maintaine. Derfor anbefaler jeg sjelden C for nye prosjekter, med mindre det er en veldig god grunn. SOm det av og til er.

 

 

Derfor du satt fortran så langt ned også?

[Lycantrophe]

Hva konkret er problemet med javascript?

Hvor begynner man? this-oppførsel, usannsynlige scope-regler, ubrukelig typesystem, pseudo-functional men uten faktisk gode primitiver, pseudo-oo men uten gode primitiver, pseudo-prosedyrisk men uten gode primitiver, default global scope for å nevne noe.

 

Spesielt siste der er vanlig for mange scriptingspråk, uten at det er noe bedre der.

 

 

Nei, det blir for dumt. C er jo tross alt det språket de fleste språk baserer seg på.

Det stemmer ikke.

[Emancipate]

De siste tingene skjønner jeg, kan du gi noen eksempler på dette:

 

this-oppførsel, usannsynlige scope-regler, ubrukelig typesystem,

 

Edit: Altså hvorfor det er problematisk.

Endret 30. mars 2015 av Emancipate

[Lycantrophe]

This:

den kan reassignes (what the fuck). Den binder også til caller, ikke til environmentet i tilfellet closure. Det er problematisk av rimelig åpenbare grunner, og det er enda en kilde til bugs. Men kanskje mest fordi det funker subtilt annerledes enn andre lignende språk. Least surprise etc.

 

Scope-regler er snåle: http://stackoverflow.com/questions/500431/what-is-the-scope-of-variables-in-javascript

 

Typesystemet er ubrukelig fordi det mer eller mindre lar bugs slippe gjennom der man kunne fanget de. Jeg er ikke en spesielt stor fan av dynamiske språk i utgangspunktet, men javascript er nok verst i klassen. Det er mange eksempler på dette, der klassikeren er mangel på transitivitet som følge av coercions. Igjen, bugs.

 

Javascript burde aldri eksistert, og det burde aldri blitt brukt i den grad det blir brukt i dag.

[Emancipate]

den kan reassignes (what the fuck).

Jeg ser ikke problemet.

 

Scope-regler er snåle

Jeg ser ikke hva som er rart. Det eneste som virkelig er rart med javascript er at man kan assigne til medlemmet prototype på en instans, uten at det har en effekt på instansens faktiske prototype.

 

Den binder også til caller, ikke til environmentet i tilfellet closure

Jeg skjønner ikke alternativet til at this settes til objektet funksjonen kalles på.

 

Men kanskje mest fordi det funker subtilt annerledes enn andre lignende språk.

Det kommer vel bare an på hvilket språk man har begynt med hva som er "annerledes".

[Lycantrophe]

Jeg ser ikke problemet.

Ok. chek urself m8.

 

Jeg ser ikke hva som er rart. Det eneste som virkelig er rart med javascript er at man kan assigne til medlemmet prototype på en instans, uten at det har en effekt på instansens faktiske prototype.

Har lite med scope å gjøre, men ok. Det er vel analogt til mutere-klasse-mot-mutere instans.

 

Jeg skjønner ikke alternativet til at this settes til objektet funksjonen kalles på.

Sånn this fungerer i alle andre språk med this? hhv C++, python, java, C#, perl og sikkert flere.

 

Det kommer vel bare an på hvilket språk man har begynt med hva som er "annerledes".

Javascript er vel the odd one out.

[Emancipate]

 

Jeg skjønner ikke alternativet til at this settes til objektet funksjonen kalles på.

Sånn this fungerer i alle andre språk med this? hhv C++, python, java, C#, perl og sikkert flere.

 

Jeg tror jeg skjønner. Forskjellen består i at i disse språkene er this en lokal variabel som er et parameter til funksjonen, og dermed bare er tilgjengelig i medlemsfunksjoner, mens i JavaScript er this en global variabel som oppdateres automatisk. Right?

 

Jeg begynte med programmering i Game Maker, og der ble variabelen self satt til instansen når en event oppsto på den instansen. Om man kalte opp et script (tilsvarer funksjon i andre språk) var variabelen fortsatt definert, ettersom den var en "vanlig" variabel. Husker jeg rett kunne den også reassignes. Dette blir vel det samme som JavaScript?

 

(En forskjell var at det kun fantes medlemsvariabler, ikke lokale variabler. Så alle variabler var permanente på en instans. Om this er et implisitt parameter eller en vanlig variabel blir muligens helt likegyldig pga dette. Med forbehold om at jeg husker feil.)

 

I tillegg var det en global variabel "other" som ble satt på events der to objekter var involvert (f.eks. om dette objektet har kollidert med et annet).

 

Jeg ser ikke hvorfor det er dummere. Det er det jeg er vant med. Det skaper egentlig ingen problemer å late som om man er i C++, og ikke bruke this utenfor medlemsfunksjoner.

 

Og jeg skjønner heller ikke det du mente i forhold til closures: "Den binder også til caller, ikke til environmentet i tilfellet closure"

 

 

[Lycantrophe]

Jeg tror jeg skjønner. Forskjellen består i at i disse språkene er this en lokal variabel som er et parameter til funksjonen, og dermed bare er tilgjengelig i medlemsfunksjoner, mens i JavaScript er this en global variabel som oppdateres automatisk. Right?

Mer eller mindre, ja. This binder til den this som er nærmest stedet som -kaller- noe som bruke this. Ikke der this originalt kom fra. Retarded.

 

 

Jeg begynte med programmering i Game Maker, og der ble variabelen self satt til instansen når en event oppsto på den instansen.

Altså motsatt av javascript.

 

 

Dette blir vel det samme som JavaScript?

Nei, sett bort ifra reassignment.

 

 

Jeg ser ikke hvorfor det er dummere. Det er det jeg er vant med. Det skaper egentlig ingen problemer å late som om man er i C++, og ikke bruke this utenfor medlemsfunksjoner.

Problemet er når du bruker this i medlemsfunksjoner og en annens medlemsfunksjoner blir kalt fordi du ble kalt fra et annet environment. Det er altså ikke mulig å resonnere rundt hva som kalles her og der fordi det settes fra utsiden.

 

Og jeg skjønner heller ikke det du mente i forhold til closures: "Den binder også til caller, ikke til environmentet i tilfellet closure"

http://www.toptal.com/javascript/10-most-common-javascript-mistakes

Denne har de i greie eksempler. #1 og #3 spesielt.

Endret 31. mars 2015 av Lycantrophe

[Emancipate]

 

Jeg begynte med programmering i Game Maker, og der ble variabelen self satt til instansen når en event oppsto på den instansen.

Altså motsatt av javascript.

 

Hvordan blir det motsatt? En event på en instans i Game Maker tilsvarer ca å kalle en metode på en instans i JS.

 

I begge språkene er det en stakk (separat fra den vanlige stakken) av this-pekere. Når man kaller en metode på en instans pushes verdien til this på stakken, og this settes til en referanse til instansen før metoden kalles. Når metoden returnerer blir this=thisStack.pop().

Det er det samme.

 

 

Jeg ser ikke hvorfor det er dummere. Det er det jeg er vant med. Det skaper egentlig ingen problemer å late som om man er i C++, og ikke bruke this utenfor medlemsfunksjoner.

Problemet er når du bruker this i medlemsfunksjoner og en annens medlemsfunksjoner blir kalt fordi du ble kalt fra et annet environment. Det er altså ikke mulig å resonnere rundt hva som kalles her og der fordi det settes fra utsiden.

 

This fungerer jo som en stakk (se over), en stakk er rimelig enkel å resonnere rundt.

 

 

 

Og jeg skjønner heller ikke det du mente i forhold til closures: "Den binder også til caller, ikke til environmentet i tilfellet closure"

http://www.toptal.com/javascript/10-most-common-javascript-mistakes

Denne har de i greie eksempler. #1 og #3 spesielt.

 

#1. Ja, ser at det er et problem som ikke har en "godkjent" løsning. Det skyldes egentlig ikke this, men tre andre ting.

 

1. Other mangler i JavaScript. Det bør være en innebygget variabel "other" som aksesserer toppen i this-stakken.

2. This kan ikke reassignes manuelt (this = ref).

3. setTimeout() er designet av en C-programmerer. Problemet blir analogt til å bruke et C api fra et C++-objekt. setTimeout() er da heller ikke en del av JS-standarden, men en funksjon i HTML5-standarden nettleseren eksporterer.

 

setTimeout() kunne vært designet på mange andre måter:

A. Ta et objekt (this) som parameter og kalle metoden "timeout()" på det.

B. Ta et objekt (this) og en funksjon og sett this før man kaller callbacket.

C. lagre "other" inni settimeout og sette this til den lagrede other før man kaller callbacket.

 

#3. Det er dårlig design av språket å gjøre det så enkelt å skape slike problemer.