Javascript er populært til mobilapps

parseInt("25")

Her vil jeg så gerne have set det andet parameter, radix, være angivet. Det gør måske ikke så meget lige med den streng (bortset fra at jeg ser mange tal encoded som strenge i hexadecimal notation, så jeg bliver altid mistænksom for, om der menes 25 i decimal notation eller 25 i hexadecimal notation).

Men hvis du nu står med noget input, som har foranstillede nuller, som f.eks. "025", er det så i oktal eller decimal notation? Ja, det er så implementationsafhængigt.

PS: Og få mig ikke igang med, hvad der sker, når man konverterer fra byte[] og til String. F.eks. har Java en constructor til String, som kun tager byte[] som parameter, og jeg citerer: "Constructs a new String by decoding the specified array of bytes using the platform's default charset." og "The behavior of this constructor when the given bytes are not valid in the default charset is unspecified". What could possibly go wrong...!

Har du et eksempel?

parseFloat("0.23") parseInt("25")

Begge dele bliver parset til en værdi af typen number. :D Number er en Double. Så du har kun heltal i 53 bit.

Hvis du parser en streng til et number I JavaScript så forbliver den et number I det runtime. Så du vil ikke få 122 hvis du har sikret dig at typen korrekt.

Har du et eksempel?

Når nu der ikke findes nogen typing som så i Javascript?

Hvis du parser en streng til et number I JavaScript så forbliver den et number I det runtime. Så du vil ikke få 122 hvis du har sikret dig at typen korrekt.

Hvor går skillelinjen?

Det svarer vel lidt til framework I andre sprog. Der findes sandsynligvis ikke noget der er så rodet og inkonsekvent som browser API til JavaScript, men du må jo huske på at standardiseringen har lidt under de forskellige browser krige. Microsoft nægtede i lang tid at efterleve HTML standarden, så imens nogle ting blev pioneret af MS, andre ting af Netscape/Firefox og andre ting af Google så var der i lang tid ingen enighed om tingene. Men JavaScript sproget er standardiseret i ECMAScript 262. Den første standard blev udgivet i 1997. Disse ting kunne jo muligvis blive rettet uden at JavaScript standarden blev involveret.

Et hvert sprog der læser en input værdi fra en Textbox skal vel parse inputet fra streng til double/int. Det er vel ikke anderledes her.

For hvis jeg i et andet sprog definerer en variabel som f.eks. et heltal, så vil det selvføgelig (fordi input kun kan være en streng) være nødvendigt at lave en strtoint, men da jeg ikke ved hvad en variabel ender som i Javascript, så er det op af bakke.

Men hvad vil du konkret gøre?

De property og functions navne der her nævnes er en del af Browser API og ikke Javascript. Du kan vel næppe klandre Javascript for det.

Hvor går skillelinjen?

Og hvis der var nogen der så lavede et begavet ikke casefølsomt funktionssprog, så kan de for min sags skyld kalde det hvad de vil, men jeg (og givetvis 99% af resten af kloden) anser ovenstående som Javascript.

Hvis det skal være noget simpelt så, jo da, det kunne jeg da godt finde på.

Ok. Så giver det hele jo mere mening. Ville det så ikke være bedre et argumentere for/imod fortolkede sprog?

Hej Christian

Tak for svar.

Eksempelvis: jeg laver en beregning når jeg forlader et inputfelt, som skal lægge værdien af det til et andet - der er min tolerancetærskel lidt for lavt til at jeg kan acceptere at udfaldet enten kan være 122, eller de 23 det vitterlig skal være.

Et hvert sprog der læser en input værdi fra en Textbox skal vel parse inputet fra streng til double/int. Det er vel ikke anderledes her.

</p>
<ul><li>så man skal lige selv fjerne alle de små x'er jeg har proppet ind - suk):

De property og functions navne der her nævnes er en del af Browser API og ikke Javascript. Du kan vel næppe klandre Javascript for det.

Hvem kan i ædru tilstand finde på at bruge noget så tåbeligt som JavaScript til at lave serverside programmering?

Hvis det skal være noget simpelt så, jo da, det kunne jeg da godt finde på.

Som udgangspunkt - ja.

Ok. Så giver det hele jo mere mening. Ville det så ikke være bedre et argumentere for/imod fortolkede sprog?

Jeg kan godt se hvad du mener, men det er efter min mening, normalt ikke et problem. Mængden af type checking i et javascript project er forsvindende lille.

Eksempelvis: jeg laver en beregning når jeg forlader et inputfelt, som skal lægge værdien af det til et andet - der er min tolerancetærskel lidt for lavt til at jeg kan acceptere at udfaldet enten kan være 122, eller de 23 det vitterlig skal være.

Det er vist en overdrivelse der hindrer forståelsen. Enhver der kan læse c, c++, C# eller Java har ikke problemer med at forstå disse ting.

xdocument: Nå vi skriver åbenbart med småt.

getxElementxByxId: Nåeh, nej vi starter med småt, og så bruger vi versaler til at indikere "orddeling".

onxreadyxstatexchange: Nej, og så åbenbart alligevel ikke.

innerxHTML: Nåeh ja, vi kan selvfølgelig også lade et helt delord være med versaler.

XMLxHttpxRequest(): Jamen hov, vi kan jo godt lade noget starte med versaler også.

Osv, osv.

Du kan nemt forbinde Chrome Dev Tools til et nodejs

Hvem kan i ædru tilstand finde på at bruge noget så tåbeligt som JavaScript til at lave serverside programmering?

Hvilket fortolket sprog har denne mulighed?

Det lyder som om at du har noget imod fortolkede sprog.

En opgave der tager relativt lang tid at implementere i Javascript på grund af Javascripts ulemper.

Det er ikke uden grund at Javascript er det mest "populære" sprog på StackExchange - så sandelig ikke fordi det er godt, men fordi det er det der er mest bøvl med.

Jo da, men de færreste fortolkede sprog har en kompiler der kan finde fejl.

Hvis du skal lave en simpel app til en mobil telefon

Det må anses for ret uprofessionelt at et site der hævder at være for IT professionelle, som Bjarne også skriver, kan stå bag noget så ringe.

Skomagerens børn og smedens hest ...

Nej det er en server fejl der opstår, i forbindelse med at de forsøger escape "farlige" ord, eksempelvis "javascript". Det har været her i årevis og gør det meget svært at skrive indlæg om visse sprog.

Det er lidt bekymrende omkring kodekvaliteten bag sitet...

Men det er vel slet ikke meningen at man skal debattere noget så politisk ukorrekt som programmering.

Hint: indsæt nogle ekstra tegn, eksempelvis skriv java_script for at fixe det. Man kan ofte skrive ordet én gang men flere gange får den til at fejle.

Brug Gennemse funktionen til at verificere at det ikke fejler.

Altså, nu er det her ikke et debatforum for IT-professionelle, vel, så vi kan vel ikke forvente at kunne skrive om IT-relaterede spidsfindigheder. Det må vi gøre i vores fagmedier; her kan vi diskutere politik og andet samfundsfagligt.

...hov, vent lige et øjeblik!

Jeg skulle til at liste en række Javascript ord op, og så ender jeg bare med en fejl.</p>
<p>Så det stinker langt væk at at der vitterlig er et problem med Javascript.

Nej det er en server fejl der opstår, i forbindelse med at de forsøger escape "farlige" ord, eksempelvis "javascript". Det har været her i årevis og gør det meget svært at skrive indlæg om visse sprog.

Det er lidt bekymrende omkring kodekvaliteten bag sitet...

Hint: indsæt nogle ekstra tegn, eksempelvis skriv java_script for at fixe det. Man kan ofte skrive ordet én gang men flere gange får den til at fejle. Brug Gennemse funktionen til at verificere at det ikke fejler.

Nej jeg giver op, dette her lorteforum virker jo slet ikke.

Jeg skulle til at liste en række Javascript ord op, og så ender jeg bare med en fejl.

Så det stinker langt væk at at der vitterlig er et problem med Javascript.

Gud fader bevares.

Det er vist en overdrivelse der hindrer forståelsen. Enhver der kan læse c, c++, C# eller Java har ikke problemer med at forstå disse ting.

Jeg kan godt se hvad du mener, men det er efter min mening, normalt ikke et problem. Mængden af type checking i et javascript project er forsvindende lille.

Eksempelvis: jeg laver en beregning når jeg forlader et inputfelt, som skal lægge værdien af det til et andet - der er min tolerancetærskel lidt for lavt til at jeg kan acceptere at udfaldet enten kan være 122, eller de 23 det vitterlig skal være.

Der kommer denne fejl når man prøver at poste et langt svar:

"The requested URL was rejected. Please consult with your administrator.

Your support ID is: 3167237971509436189"

Så det kommer i bidder over 3-4 indlæg.

Virkelig imponerende.

det er vel noget Javascript der ikke virker.

Touché. ? Ville ellers gerne have læst det.

Jeg havde egentlig skrevet et længere svar her, men V2's lorteforum fucker op når man prøver at poste længere indlæg - det er vel noget Javascript der ikke virker.

Prøver at poste en anden dag, så kan man jo håbe på det virker.

Tja lidt efter forgodtbefindende bliver det enten 122 eller 23.</p>
<p>Virkelig fedt.

Jeg kan godt se hvad du mener, men det er efter min mening, normalt ikke et problem. Mængden af type checking i et javascript project er forsvindende lille.

Ja og man kan også vænne(!) sig til at skrive på russisk - men det gør det ikke lettere.

Det er vist en overdrivelse der hindrer forståelsen. Enhver der kan læse c, c++, C# eller Java har ikke problemer med at forstå disse ting.

Ja hvis jeg høvler f.eks. et Freepascal program gennem compileren, så finder den alle triviel fejlene for mig.</p>
<p>Men med Javascript - puha.

Du kan nemt forbinde Chrome Dev Tools til et nodejs runtime og få en udemærket debugger.

Men jeg kan stadig ikke lave ordentlig binær kode ud af det, og jeg har stadig ikke en ordenlig compiler til at hjælpe med dummefejl.

Hvilket fortolket sprog har denne mulighed? Det lyder som om at du har noget imod fortolkede sprog.

Man kan altid finde noget der er langsommere, men det er nu heller ikke hastigheden jeg bitcher over, men den generelle elendighed, og den kollossale mængde tid man skal bruge på at løse selv helt trivielle opgaver.

Kan du ikke komme med et eksempel her? En opgave der tager relativt lang tid at implementere i Javascript på grund af Javascripts ulemper.

Hvorfor det?</p>
<p>Man påstår at Javascript er et programmeringssprog - så skal det da også kunne tåle sammenligning.

Jo da, men de færreste fortolkede sprog har en kompiler der kan finde fejl.

Jeg vil give dig ret i alle dine pointer om Javascripts mangler og fejl, men personligt mener jeg bare ikke at det er et stort problem. Personligt synes jeg faktisk at man løser trivielle opgaver hurtigt i Javascript. Der er dog nogle opgaver som jeg aldrig ville vælge javscript til at løse. Jeg kunne ALDRIG finde på at skrive en driver i Javascript. Men jeg kunne heller aldrig finde på at skrive en web backend i Fortran.

Javascript er en udemærket løsning til et bestemt opgave rum. Sproget overlapper med en del andre sprog i dette rum. Hvis du skal lave en simpel app til en mobil telefon er det en udemærket løsning, efter min mening.

Men det betyder ikke at det er et problem og at man ikke kan løse opgaver med sproget. Man skal blot være klar over det.

F.eks. tage højde for:

funktion blabla (variabel) { var helstettal = 1 + variabel }

Nå og hvad bliver helstettal hvis man propper f.eks 22 ind i variabel?

Tja lidt efter forgodtbefindende bliver det enten 122 eller 23.

Virkelig fedt.

Muligvis, men det vender man sig hurtigt til. Desuden skæmmer det ikke læsbarheden.

Javascript er da nemt at debugge. Kan du komme med et eksempel?

Men med Javascript - puha.

Det er jo et fortolket sprog. Men det bliver jo faktisk JIT compilet i de fleste runtime miljøer.

Desuden er javascript muligvis det hurtigste fortolkede sprog overhovedet.

Prøv at benchmarke hastigheden med f.eks. CPython.

Du skal jo, klart nok, ikke sammenligne javascript med et kompileret sprog. Det ville være en fejl.

Man påstår at Javascript er et programmeringssprog - så skal det da også kunne tåle sammenligning.

Elendig typingcasting (eller rettere totalt fravær af selvsamme).

Bizarre caseafhængige navne.

Umulig debugging

Scriptet, ikke compileret

Du skal jo, klart nok, ikke sammenligne javascript med et kompileret sprog. Det ville være en fejl.

Rodbehandling er også populært. Hvis man har dårlige tænder.

Jeg synes at javscript er et udemærket sprog.

Elendig typingcasting (eller rettere totalt fravær af selvsamme). Bizarre caseafhængige navne. Umulig debugging Scriptet, ikke compileret . . .

Som er prøve at programmere en elastik.

Den eneste grund til at Javascript er "populært" er udelukkende fordi man ikke kan undgå det hvis man skal have funktionalitet på klientsiden af en webpage.

Jeg synes at javscript er et udemærket sprog. Det mangler dog nogle få ting. Hvis man f.eks. skal håndtere en long variable (int64), så er der ikke nogle indbyggede typer til det. Man skal derfor ud i mystiske hacks for at lave helt almindelige operationer.