3 ms·

The problem is that javascript is fundamentally flawed by design. It has the WORST and most idiotic type system out there, it has no clue whether it wants t

The problem is that javascript is fundamentally flawed by design. It has the __WORST__ and most idiotic type system out there, it has no clue whether it wants to be oop or a functional language and there are outrageous amounts of inconsistencies everywhere you look. The argument for spaghetti C code is valid, but you'd find a lot more js spaghetti than C spaghetti, even if you adjust for the number of C code to match the amount of js code. And there are two reasons for it: 1. The horrid language that is javascript in it's core. 2. Everyone and their dog is a developer these days, and in 99% of all cases js developers without any fundamental understanding of memory management, data structures or algorithms(basically cs 101). For C, you need some fundamental understanding of all of those things for anything beyond "hello world". I'm willing to bet that if you ask 10000 js developers what the heap and stack are and how they work, 9998 of them would have never heard of those terms. And you'd probably have to add a few zeros before you get to someone who can answer that correctly. As for the extensive usage - well yeah... All you need is a browser to interpret it. In the same way all you need to keep yourself warm in winter is to chop down a tree and set it on fire. That doesn't mean it's a wise idea to go out chopping trees in mass, does it? I lost the countless attempts to make a better language for the web and they were all killed off by the Stalinists at w3 and mozilla. As I said, react is a symptom of that stupidity, not the cause. I've said it before, I'll say it again: a good engineer and a good community are defined by their ability to say "OK, that was a stupid idea, let's go back to the drawing board". The web is in it's worst shape it has ever been. Coldfusion, flash and the ridiculous java applets were heaven compared to what we have now.

ironmagma 6y ago
Whether the aesthetics are good or bad does not dictate whether a language is a “programming language.” That is determined by whether you can write programs with it. JavaScript is used to generate billions, if not trillions of dollars each year, through the fact that you can run programs on a computer with it, therefore being a programming language. There’s no subjectivity there, JavaScript is not a toy. Incidentally, there are a lot of spaghetti code encouraging platforms like LabView, Matlab, and PLC which nevertheless accomplish similar results, even in safety critical applications. Those are not toys either, despite their lack of sophistication. What the language designer accomplished is not simple. JS packaged functional expressivity and dynamic binding from Scheme and Smalltalk into a marketable form using Java/C syntax. That is not a corruption, it’s a design feature. Languages that use S-expressions, while pleasing to the purists, do not see much market traction. The best languages are the ones that balance functional idealism with pragmatism. It is true that the language has warts, but there is ultimately a reason that all the JS alternatives, such as Flash, Applets, Silverlight, VBScript and Pyodide failed. I agree the web is worse now, but it’s not due to technical reasons. We have more options for web coding than ever before with AsmJS and Wasm, plus all the compile-to-javascript languages. You can choose to write using one of those ‘superior languages’ like with Scala.js, Elm, Elixir, Clojurescript, or any number of runtime translation layers like Brython or Skulpt, but people don’t choose to. Because that isn’t the problem. The problem is that businesses want less logic in the backend and don’t find sufficient benefit in optimization to prioritize it over feature work. That’s a disturbing business trend and hardly related to technical choice. For most operations, JS is blazingly fast due to the millions of hours that have gone into optimizing it. Last, the people who are beginners and don’t understand the stack or heap, are not the ones running Webpack and writing (a significant amount of) React code. Those are distinctly different personas, and conflating them is insane. Either you are seasoned and can deal with the complexity that is the JS tooling infrastructure, or you are not and you probably aren’t using it as a result.
- axegon_ 6y ago
  The language designer's intentions were completely different(very similar situation as the situation with php). His intentions were to give very basic interactivity to the plain documents that was the web. And for that purpose javascript is fine. For anything beyond that, it's simply retarded. I've worked in large corporations for most of my life and in all instances stunts like javascript-only development or react were the consequence of either someone from management being a javascript "developer" or management blindly trusting their "top engineers". Just open up history books and look at how many times humanity has been wrong. Hell, just turn on the news and look at the political landscape - the people who were democratically elected, and you'll instantly see what I'm on about. My argument remains equally valid for the people developing those frameworks. The fact that their barebone examples eat up 200 megabytes of memory and basic navigation pumps up my cpu to at least 40% is a clear indication. And my personal computer is not a raspberry pi gen 1. Far, far from it. Look around HN and you'll see a growing support for my message: javascript is crap and needs to be abolished. As for javascript being "blazingly fast": lol. Compared to what? calculating 924^42 with pen and paper? Yeah, in that respect it's fast. For anything beyond that it remains a paper plane. Wasm initially terrified me because it potentially opened the floodgates for all the "developers" to jump into what are real programming languages and make a mess out of them too. For the time being it's fine though: Jumping from this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() = this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() + 1; to type ConnectionError = Box<dyn std::error::Error + Send + Sync + 'static>; is not humanly possible... For now...
  - ironmagma 6y ago
    JavaScript is fast compared to what it used to be, and faster than Python for example, in many circumstances. [1] As far as large groups of people being wrong, that also applies to HN. The industry trend has been toward larger frontend components, and that’s not because of tyrannical engineers (since when do engineers have business power?). It’s just cheaper to create code on the frontend a lot of the time, especially if you have to weigh writing the code in JS versus e.g. Go with a properly formed GraphQL backend. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The problem is that javascript is fundamentally flawed by design. It has the __WORST__ and most idiotic type system out there, it has no clue whether it wants t

ironmagma 6y ago

Whether the aesthetics are good or bad does not dictate whether a language is a “programming language.” That is determined by whether you can write programs with it. JavaScript is used to generate billions, if not trillions of dollars each year, through the fact that you can run programs on a computer with it, therefore being a programming language. There’s no subjectivity there, JavaScript is not a toy. Incidentally, there are a lot of spaghetti code encouraging platforms like LabView, Matlab, and PLC which nevertheless accomplish similar results, even in safety critical applications. Those are not toys either, despite their lack of sophistication. What the language designer accomplished is not simple. JS packaged functional expressivity and dynamic binding from Scheme and Smalltalk into a marketable form using Java/C syntax. That is not a corruption, it’s a design feature. Languages that use S-expressions, while pleasing to the purists, do not see much market traction. The best languages are the ones that balance functional idealism with pragmatism. It is true that the language has warts, but there is ultimately a reason that all the JS alternatives, such as Flash, Applets, Silverlight, VBScript and Pyodide failed. I agree the web is worse now, but it’s not due to technical reasons. We have more options for web coding than ever before with AsmJS and Wasm, plus all the compile-to-javascript languages. You can choose to write using one of those ‘superior languages’ like with Scala.js, Elm, Elixir, Clojurescript, or any number of runtime translation layers like Brython or Skulpt, but people don’t choose to. Because that isn’t the problem. The problem is that businesses want less logic in the backend and don’t find sufficient benefit in optimization to prioritize it over feature work. That’s a disturbing business trend and hardly related to technical choice. For most operations, JS is blazingly fast due to the millions of hours that have gone into optimizing it. Last, the people who are beginners and don’t understand the stack or heap, are not the ones running Webpack and writing (a significant amount of) React code. Those are distinctly different personas, and conflating them is insane. Either you are seasoned and can deal with the complexity that is the JS tooling infrastructure, or you are not and you probably aren’t using it as a result.

axegon_ 6y ago
The language designer's intentions were completely different(very similar situation as the situation with php). His intentions were to give very basic interactivity to the plain documents that was the web. And for that purpose javascript is fine. For anything beyond that, it's simply retarded. I've worked in large corporations for most of my life and in all instances stunts like javascript-only development or react were the consequence of either someone from management being a javascript "developer" or management blindly trusting their "top engineers". Just open up history books and look at how many times humanity has been wrong. Hell, just turn on the news and look at the political landscape - the people who were democratically elected, and you'll instantly see what I'm on about. My argument remains equally valid for the people developing those frameworks. The fact that their barebone examples eat up 200 megabytes of memory and basic navigation pumps up my cpu to at least 40% is a clear indication. And my personal computer is not a raspberry pi gen 1. Far, far from it. Look around HN and you'll see a growing support for my message: javascript is crap and needs to be abolished. As for javascript being "blazingly fast": lol. Compared to what? calculating 924^42 with pen and paper? Yeah, in that respect it's fast. For anything beyond that it remains a paper plane. Wasm initially terrified me because it potentially opened the floodgates for all the "developers" to jump into what are real programming languages and make a mess out of them too. For the time being it's fine though: Jumping from this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() = this.prop.element.parent.third_degree_cousin.grandParent.neighbors_dog.value.get_value().toInteger() + 1; to type ConnectionError = Box<dyn std::error::Error + Send + Sync + 'static>; is not humanly possible... For now...
- ironmagma 6y ago
  JavaScript is fast compared to what it used to be, and faster than Python for example, in many circumstances. [1] As far as large groups of people being wrong, that also applies to HN. The industry trend has been toward larger frontend components, and that’s not because of tyrannical engineers (since when do engineers have business power?). It’s just cheaper to create code on the frontend a lot of the time, especially if you have to weigh writing the code in JS versus e.g. Go with a properly formed GraphQL backend. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...