6 ms·

It is 'trash' for the general purpose 'one-size-fits-all' programming language that it's fans want to impose upon the world. (I shake my head at microcontroller

It is 'trash' for the general purpose 'one-size-fits-all' programming language that it's fans want to impose upon the world. (I shake my head at microcontrollers running dynamic languages. "micro-python" = spare me. line breaks over a TTY? there's the primary question of on-chip resources and a giant shim between the physical realities of a microcontroller and some high-level fantasies about what programming "should be", absent any information on the low level specifics = the issue here.) It's ES3 API is missing a few things, like Object.keys, etc. I still happily code for browsers in ES5 with a few polyfill functions. JS works fine for it's core competency: manipulating DOM elements and local data representations. It's not JS's fault that the browser is the way it is and that HTTP is the way it is and that using a remote directory "browsing" protocol via a specialized file browser that renders hypertext isn't a 2-way bound GUI framework...

jiofih 5y ago
That’s a load of gibberish. JS as a language has nothing to do with browser APIs, why would you judge it based on that? Also, ES6 was ratified six years ago. Seems like you had a bad experience with espruino / jerryscript or something and are projecting based on that? Dynamic languages are easier to program in. That’s a fact, and why they are so popular.
- golergka 5y ago
  Although I like Javascript (Typescript) a lot, I have to bite: > Dynamic languages are easier to program in. Only if you don't care about writing correct and maintainable programs. The only thing that dynamic languages make easier is writing code. Or, more specifically, the first couple of versions of it. That's not what typical programming as a process mostly consists of.
  - jiofih 5y ago
    By the definition of formally correct, yes, you’re right. But dynamic programming still allows programs to be functionally correct, and verified by testing, which is more often than not good enough.
    - golergka 5y ago
      Writing and maintaining a program in a statically typed language is significantly easier and faster than doing the same in a dynamic language while manually writing all the tests that would cover the same level of correctness that types give you out of the box.
- hootbootscoot 5y ago
  gibberish? "JS as a language has nothing to do with browser APIs, why would you judge it based on that?" Excuse me? That is precisely what JS is based upon. Lemme give you a prime example: JS = a single threaded event loop, ON PURPOSE. That directly affected Node.js as an implementation. Your browser has an embedded scripting engine. Embedded, meaning, the source code for your browser includes the scripting language engine, and JS can run on that and script various permitted things via the browser API. ES6 may have been ratified six years ago, but it's not the target code your front-end build chain spits out, is it... browsers don't uniformly support it yet. fun facts. Look, I've been programming JS since it was invented. I'm not impressed by "classes" that don't exist, arrow functions, async/await, futures, promises, fibers, and assorted hacks that don't mirror the actual CODE (what computers execute) a JS engine actually is based upon. I don't need these tools, why should I use something that I need to transpile when I can code directly for browsers as they are in 2021, including legacy browsers? I don't find ES6 "easier" in any way.. Regarding dynamic languages on microcontrollers: Dynamic languages cannot directly control memory allocation and manipulation, typically are heap based and have no concept of a stack frame, and are basically just a computer program written whose corresponding code instructions (machine code) and execution path is scripted by your high-level language. Read a JS engines source code, study embedded C, and get back to me as to how suitable you find it for timing deterministic embedded programming. LOL Types are directly related to memory size allocations. Study the recent crop of LLVM languages, including some very interesting ones like LuaJIT, which should be right up your alley, and note the role Garbage Collection (check the Boehm implementation, for example) plays in many of the object-oriented languages, as well as Go. Look at the actual assembler instructions you require a computer to perform as a result of your high level specification. I am NOT speaking gibberish. I agree that dynamic languages are considered easier to program in. When speaking of programming languages, they are not all on the same level. One cannot say "oh assembler is fine and all but i prefer lua", as it's like comparing apples and atoms. there's a reason that you can implement a lisp in c, but that the contrary is not viable nor makes any sense. (although metaprogramming c with lisp makes a lot of sense :D)
  - lispm 5y ago
    Though there are C compilers and also C code generators written in Lisp.

jiofih 5y ago

That’s a load of gibberish. JS as a language has nothing to do with browser APIs, why would you judge it based on that? Also, ES6 was ratified six years ago. Seems like you had a bad experience with espruino / jerryscript or something and are projecting based on that? Dynamic languages are easier to program in. That’s a fact, and why they are so popular.

golergka 5y ago
Although I like Javascript (Typescript) a lot, I have to bite: > Dynamic languages are easier to program in. Only if you don't care about writing correct and maintainable programs. The only thing that dynamic languages make easier is writing code. Or, more specifically, the first couple of versions of it. That's not what typical programming as a process mostly consists of.
- jiofih 5y ago
  By the definition of formally correct, yes, you’re right. But dynamic programming still allows programs to be functionally correct, and verified by testing, which is more often than not good enough.
  - golergka 5y ago
    Writing and maintaining a program in a statically typed language is significantly easier and faster than doing the same in a dynamic language while manually writing all the tests that would cover the same level of correctness that types give you out of the box.
hootbootscoot 5y ago
gibberish? "JS as a language has nothing to do with browser APIs, why would you judge it based on that?" Excuse me? That is precisely what JS is based upon. Lemme give you a prime example: JS = a single threaded event loop, ON PURPOSE. That directly affected Node.js as an implementation. Your browser has an embedded scripting engine. Embedded, meaning, the source code for your browser includes the scripting language engine, and JS can run on that and script various permitted things via the browser API. ES6 may have been ratified six years ago, but it's not the target code your front-end build chain spits out, is it... browsers don't uniformly support it yet. fun facts. Look, I've been programming JS since it was invented. I'm not impressed by "classes" that don't exist, arrow functions, async/await, futures, promises, fibers, and assorted hacks that don't mirror the actual CODE (what computers execute) a JS engine actually is based upon. I don't need these tools, why should I use something that I need to transpile when I can code directly for browsers as they are in 2021, including legacy browsers? I don't find ES6 "easier" in any way.. Regarding dynamic languages on microcontrollers: Dynamic languages cannot directly control memory allocation and manipulation, typically are heap based and have no concept of a stack frame, and are basically just a computer program written whose corresponding code instructions (machine code) and execution path is scripted by your high-level language. Read a JS engines source code, study embedded C, and get back to me as to how suitable you find it for timing deterministic embedded programming. LOL Types are directly related to memory size allocations. Study the recent crop of LLVM languages, including some very interesting ones like LuaJIT, which should be right up your alley, and note the role Garbage Collection (check the Boehm implementation, for example) plays in many of the object-oriented languages, as well as Go. Look at the actual assembler instructions you require a computer to perform as a result of your high level specification. I am NOT speaking gibberish. I agree that dynamic languages are considered easier to program in. When speaking of programming languages, they are not all on the same level. One cannot say "oh assembler is fine and all but i prefer lua", as it's like comparing apples and atoms. there's a reason that you can implement a lisp in c, but that the contrary is not viable nor makes any sense. (although metaprogramming c with lisp makes a lot of sense :D)
- lispm 5y ago
  Though there are C compilers and also C code generators written in Lisp.