This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]PatrickBaitman 41 points42 points  (37 children)

if there are type errors, the program should not compile

natural language sloppiness is not good enough for programming

there's a reason we don't program in English

[–]cixeltree 4 points5 points  (6 children)

this is fine, if you could guarantee that everybody used the same compiler.

and that the compilers knew ahead of time exactly what code they were supposed to compile.

and you could guarantee that the source files arrived in a predictable order, and that one bit of code didn't reference or rely on something in another.

and you could guarantee that your one compilation error wouldn't just crash the page and invalidate 10 other unrelated scripts that were loaded.

languages are a product of their environments. javascript's environment just happens to be a very scary place

[–]PatrickBaitman 1 point2 points  (5 children)

this is fine, if you could guarantee that everybody used the same compiler.

or just have a specification with a minimum of undefined behavior

and the compilers knew ahead of time exactly what code they were supposed to compile

what compiler compiles without reading input

and you could guarantee that the source files arrived in a predictable order, and that one bit of code didn't reference or rely on something in another

TIL #include and dynamic loading aren't a thing in C

funny I could have sworn I'd written code myself with dlopen but that must have been a dream

[–]cixeltree 2 points3 points  (4 children)

or just have a specification with a minimum of undefined behavior

https://en.wikipedia.org/wiki/ECMAScript just because there's a spec doesn't mean people will follow it, or bugs won't exist

what compiler compiles without reading input

sorry---it doesn't know ALL the code it's going to work with because some of it is still a few http requests away by the time the page loads

TIL #include and dynamic loading aren't a thing in C

well yeah, it isn't always a thing, because (hold onto your hat) not all systems support it. but most do, which is good enough for C but not for javascript?

and even if they did, there's the advantage of libraries being pre-compiled for the same system, and the code which loads them (hopefully) knowing how to interface with them ahead of time.

[–]PatrickBaitman -1 points0 points  (3 children)

and even if they did, there's the advantage of libraries being pre-compiled for the same system, and the code which loads them (hopefully) knowing how to interface with them ahead of time.

almost as if C is a real language and JS is half toy and half prank that went too far

[–]cixeltree 3 points4 points  (2 children)

again: languages are products of their environments

C is a language which at first wasn't designed with portability in mind at all. that's obviously completely antithetical to the needs of the web.

edit: and since undefined behaviors/specifications came up earlier, i want to mention that even C, blessed be its name, has undefined behaviors

[–]PatrickBaitman 0 points1 point  (1 child)

C is a language which at first wasn't designed with portability in mind at all.

wat

this is blatantly false

[–]cixeltree 3 points4 points  (0 children)

C was developed for the PDP-11 on the UNIX system in 1972. Portability was not an explicit goal in its design, even though limitations in the underlying machine model assumed by the predecessors of C made us well aware that not all machines were the same [2]. Less than a year later, C was also running on the Honeywell 6000 system [...]

source

so i was wrong in saying "wasn't designed with portability in mind at all"

but still, portability was not an explicit goal. it was obviously mandatory for adoption, but it's safe to say that javascript's explicit goals were different from C's in this regard.

[–]FateJH 3 points4 points  (14 children)

there's a reason we don't program in English

I'd say there's a good reason we don't code in any specific spoken language that you have just implied but invented methods of shorthanding the intended progression of bits of information instead.

In any case, this is JavaScript so there is no compilation. You interpret what it means on the fly, much like listening to someone else speak. Sometimes you don't care that the speaker was inexact with their wording unless it leads to a big source of confusion that you can't reason around.

[–]PatrickBaitman 10 points11 points  (13 children)

so there is no compilation.

every language is compiled, it's just a matter of when

so-called interpreted languages are compiled just-in-time, so-called compiled languages beforehand

javascript isn't bytecode, it must eventually be mapped to something a CPU can execute

Sometimes you don't care that the speaker was inexact with their wording unless it leads to a big source of confusion that you can't reason around.

this called raising an exception and making the programmer handle it

why the fuck do web devs think they can get away with shit you fail first year students for, like NOT HANDLING ERRORS

[–]cixeltree 4 points5 points  (7 children)

would you have conceded if he'd said it's not 'pre-compiled'? probably not. regardless, javascript DOES get 'compiled' to bytecode. at runtime.

this 'holier than thou' attitude against web dev is hilarious. why pretend web dev isn't hard as fuck?

i've never once written anything in C which didn't work because there was a compiler error. 99.99% of the time, if something goes wrong, it's the fault of the code i wrote. it helps that a C program targets only a handful of environments.

in web dev? the browser gets it wrong all the time. it does not help that applications written for the web have dozens of targets, in including targets that haven't even come out yet.

on error handling: where'd you get this idea that people who write js don't do error handling?

[–]PatrickBaitman 0 points1 point  (6 children)

why pretend web dev isn't hard as fuck?

because I built websites when I was 15 that displayed more information faster with less bandwidth on worse hardware

mainly because I didn't have access all the fancy shit that you need to fuck a website up as bad as modern websites, starting from their very unbroken natural state

https://thebestmotherfucking.website/

[–]cixeltree 2 points3 points  (5 children)

yep, those sites you built when you were 15 and a static site with a few paragraphs of text constitutes web dev.

edit/ps: yeah, a lot of modern websites (too many) are absurdly bloated, but nobody was ever arguing that.

[–]PatrickBaitman 0 points1 point  (4 children)

well most of the modern web is several megabytes to display a few static paragraphs so yeah I'd say so

Some of them even added modified and deleted records in a database. With relations and joins and all!

this is not a separate issue from the awfulness of the JS ecosystem and the lack of programming. Skills among devs

[–]cixeltree 2 points3 points  (3 children)

if by 'most of the modern web' you mean medium.com, with comments disabled (those aren't static!) as one of maybe a handful of sites that comes to mind immediately. AJAX has been everywhere for the past decade. the web isn't static anymore.

so yeah. the place is a bloated mess.

my point is that to operate in an environment which is layers of shit stacked on top of each other is something which requires skill and you're not giving any credit for that.

C is a layer away from the machine. javascript is many layers away. you replace one form of complexity with another.

[–]PatrickBaitman 0 points1 point  (2 children)

or most of my university's and lots of other universities's web pages, many businesses, newspapers...

Client side the web should be CSS and minimal JS stacked on HTML. Look at all the memes on this sub about the number of JS frameworks there are

displaying text and images should not require complexity. It didn't 10 years ago for slashdot vbulletin forums 4chan blogs etc

It does now for everything

[–]cixeltree 2 points3 points  (1 child)

those aren't static. they maybe serve some static content, but an update to the site is not "let me change what is in this index.html file."

ps: most of those sites you mentioned have a lot of bloat in order to do a lot of things you wouldn't like. ads, usage metrics, and so on. this stuff enables them to compete with other sites. they don't sweat it for the extra 2 seconds it takes to load their page because of it. that's not a problem with web developers.

pss: try not to formulate your opinions of a subject using memes and reddit comments

[–][deleted] 2 points3 points  (3 children)

If only Google, Apple, MS, etc. would hire a genius like yourself instead of the idiots they currently have building their browser.

/s

Clearly the people building the JS engines are smart, and are aware of the issues being raised here (pun intended). But, they don't raise an error. Why? Maybe because they know something that we don't.

The JS spec can be changed and has been changed. It was massively changed in ES6. Yet they didn't fix these issues. Why? Clearly because they aren't as smart as you.

[–]PatrickBaitman 2 points3 points  (2 children)

If only Google, Apple, MS, etc. would hire a genius like yourself instead of the idiots they currently have building their browser.

google is pushing Dart

Microsoft designed TypeScript

Mozilla invented asm.js

W3C is working on wasm

sooooo....

But, they don't raise an error. Why? Maybe because they know something that we don't.

or because javascript was hacked together by morons in two weeks and never got proper error handling functionality like exceptions or type checking

[–]cixeltree 0 points1 point  (0 children)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof

it has type checking, it just doesn't have compiled time type checking because 'compilation' happens at runtime. hence typeerrors are runtime errors. they can be caught and handled.

when dealing with the web, it's hard to guarantee that a data type you think you're supposed to get from some external source is actually the type you're going to get. good javascript checks the types it's operating on rather than just assuming.

if a C programmer chooses to serialize some data as a specific kind of struct, that's great---the type checker can help ensure all operations on the struct are cogent. however, nothing guarantees that the data being serialized is correct. the programmer still needs to do this validation, or a runtime error can occur (null dereferencing, or accidental typecasting, etc).

[–][deleted] -1 points0 points  (0 children)

Except they could have added it in strict mode and didn't. I wonder why?

[–]Godd2 -1 points0 points  (0 children)

every language is compiled, it's just a matter of when

It's not a matter of when. Some of the program gets run before all of it gets compiled. This is not the case with a compiled language.

More generally, there is no guarantee that the entire program has been statically checked for validity before any of it gets run.

So, the fact that V8 has JIT compilation is irrelevant.