/tech/ - Technology

Because it was designed to be used by people who aren’t computer scientists nor programmers and thus be as permissive as possible.

That’s not the real question though, the real question is why would they insist that it must have C-like “Java” syntax despite that knowledge? They could have done anything, they could have stuck to an S-Expression system like initial planned. Everyone could’ve been forced to learn Scheme by now instead of NotJava-Script, which would have been very based.

>>30203
after taking Java, C, C++ and C# courses in college, I ended up getting a desk job at an engineering firm where I never had to program. 10 years later I'm suddenly dealing with javashit and it sucks so much fucking ass and is so stupid and counterintuitive in its output that I don't understand how this was supposed to be "easier" for people who aren't computer scientists. it is downright illogical at points.

>>30203
>Because it was designed to be used by people who aren’t computer scientists nor programmers and thus be as permissive as possible.
No? It's because it was hastily thrown together in ten days. It was not designed.

>[]+[] -> ' '
What transformation does this even represent? Are javascript strings null terminated? Where does the space come frome?

>>30206
There's no space, it's an empty string. For some reason addition with arrays converts them to strings:
> [] + [] == ""
> [1] + [2] == "12"
> [1] + ["a"] == "1a"
> [1] + [["a", "b"]] == "1a,b"
> [1] + [["a", "b"], "c"] == "1a,b,c"

>>30205
>No?
Yes. Dynamic typing isn’t something that happens unintentionally due to a lack of design.

Why the fuck is js everywhere? It should've stayed within the browser and even then should've been killed for something better ages ago.

>>30209
Because pretending like 12 year old scriptkiddies are competitive labour drives down salaries for coders

>>30208
Dynamic typing does not necessarily mean idiosyncratic type coercions. Just look at Scheme, from which JavaScript probably inherited dynamic typing.

Brenden Eich is the modern Yakub / Openheimer. Invented JavaScript in a single week and everything since is the nuclear winter of that. Everything he's done since is in the persuit of releasing an equal or greater plague upon the world.

>>30202
it was designed for some shitty "magic" on what were basically text documents (hypertext) and people thought that since it is easy to use it will destroy the need to hire coders because anyone can use it and so they built a whole bunch of shitty tools with it.
same reason why VB was so popular for a time and why drag-and-drop ASP.NET mess was hot shit until ruby on fails came along that promised to make your shitty "webapp" in 10 mins (5 min blog tutorial), etc.

JS is the same thing from 1995 that AI hype is today.

>2025
>not using Typescript.
barbarism

>>30274
>Turning JS into a lame version of C#
Embrace functional programming

>>30281
>>30274
With wasm you could compile something in a memory safe language like rust.

>>30281
There are a few of these like purescript and reason from the looks of it, but doubt they could get me a job like typescript. Also in React and with underscore.js or similar you're still using functional programming.

>types are le hard
>I know! I'll make a language without types!
>said language grows types anyway
many such cases

>>30282
Memory safety is actually a lot more important currently than it should be, due to long-standing deficiencies in operating systems design. It doesn't matter when programs use well-defined inputs and outputs, see the filter pattern for example, and severely impedes important programming techniques like self-modifying code.

It is a world historic tragedy that JS wasn't designed with a slightly cleaner, more consistent, AppleScript style and syntax.
(Unless you're a programmer/webdev, then you'd be undercut by the fact any normie could DIY stuff.)

>>30203
>Because it was designed to be used by people who aren’t computer scientists nor programmers and thus be as permissive as possible.
That doesn't make any sense. Beginners should stay away from a language that behaves in a nonsensical, inconsistent and seemingly random ways. Just look at the first two or the last two examples OP gave.
It's like they deliberately made a language that would be more prone to stupid bugs.

>>30373
Yes but the bugs are in terms of unexpected output, they seemingly wanted JS to be like HTML and CSS in that you don't get scary error messages when you do something technically incorrect like use the string input of a textbox as an integer.
Everyone being like
>that's retarded, they should have actually had a really strict language to force newbs into being good programmers
don't realise that all that was important in the 90s was adoption during an era when the world wide web was still primarily marketed as a platform for user content that anyone can work with but otherwise corporate uses was a big question mark outside of just being a network of brochures.

Yes, with the power of hindsight and seeing how far JS went and how complicated webpages ended up getting after Web 2.0, it seems obvious now that a language easier to reason about the outcome of would have been preferable. But alas, the key to adoption was having HTML, CSS and JS not put anyone off of this new humanistic technology by shitting out error messages whenever you forget a closing tag or compare the wrong types and it apparently worked at achieving adoption.

>>30373
a computer always appears to behave in nonsensical and random ways when you're a beginner.
that there are such terrible consequences downstream from making an easier-than-usual language that actually behaves randomly is by and large a failure by everyone else to make a good beginner's language - but how can they when they don't know what a beginner wants or needs?
i think of it like drawing - ask an artist how to draw and he'll tell you to grind away at anatomy or construction or whatever "to avoid building bad habits", but "bad habits" are the concern of someone who already knows how to draw: if you really want to learn how to draw from an unskilled starting point, the single most important rule is to draw, if grinding anatomy makes it harder to draw and isn't fun, you won't draw. drawing but building bad habits is much better than not drawing at all - and you can basically ctrl+f "drawing" for "coding" here. so long as you're not in a production environment on a program i'm likely to use: do it badly, then learn from your mistakes.

>>30373
Read the thread. It's not the way it is because it was designed to be a "beginners' language", but because it was done on an impossibly tight deadline.

>>30380
Nobody outside the clueless imbeciles in this thread consider JavaScript to be a beginners' language.

>a failure by everyone else to make a good beginner's language
Python. That's THE beginners' language and it is good. Not perfect, but good. It solves exactly the problem you describe, it lets you program without having to grind "anatomy".

>>30375
You got it backwards, neither HTML or JS was designed to be fault tolerant, they had to be made that way because people were abusing them. You don't want people to switch to some other browser because that one manages to display your uncle's messed up Geocities site while yours chokes on a misplaced marquee tag.

>>30380
>>30381
>>30382
It’s right there on the Wikipedia page
>The goal was a "language for the masses", "to help nonprogrammers create dynamic, interactive Web sites".
With the source being Eich himself and Netscape.


If you want to seethingly claim
>erm ackshually it was never for beginners or non-programmers because it’s confusing type conversion rules aren’t a consequence of trying to implement consistency with having all types implicitly convert, it’s just the language was rushed, Netscape hated both new and old developers alike and the industry are all retards who adopted JS despite knowing one day it will become a language for more than 50 line tidbits of interactivity on Web 1.0 pages
Then fine, but you’re completely divorced from reality.

>>30383
You can have sane type conversion rules, JavaScript does not have them because it was rushed.

>>30387
Big boy languages restrict implicit conversion from some types to another type where the outcome is obvious and requires explicit conversion in all other cases, JavaScript tries to enable implicit conversion for every type to every other type because consistent behaviour is “good” and that’s just never going to result in solutions that matches everyone’s logic, it’s not therefore a matter of being rushed because the ECMA standard was like a year or two later than the first release of Netscape that included JavaScript and thus if people at the time *really* thought the conversion rules were an example of getting rushed, then I think they’d have tried to fix that before standardising the language with the rules it already had.

>>30388
It's the same issue mentioned already, assume that they fixed the conversion rules and a browser implemented it, suddenly a lot of sites that used to rely on the old behaviour would be broken and as a consequence users would use other browsers where their favourite sites still worked.

>>30389
In 1997? The standard came about because there was already incompatibilities between browsers…

>>30390
In 1997, yes.

>>30391
Okay, a nicer hill than any other to die on lmao

>>30373
>technology/abstraction intended to facilitate computer programming for people with no formal computer science knowledge is actually full of unintended caveats which complicates programming rather than simplify it
How many times has this happened before