Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is Good, Actually

ashfurrow.com

Post reply on HN
Print view View original

321–330 of 369 posts

Re: JavaScript is Good, Actually

#321

Post by the_af »

CiPHPerCoder wrote: post #308
the_af wrote: post #303

Earlier quoted context omitted.

No need for sarcasm and my argument wasn't that there aren't bugs in programs written in Haskell. My argument is that people who claim "writing Python is easier" usually ignore that it's writing buggy /throwaway code in Python that is actually easier (aka "look, I can write bugs fast"). Writing large, maintainable and bug-free code in Python is not easier than in other languages -- it's arguably harder, but since tha…

Every language has its faults. Even a "perfect" language is faulty if the barriers between its current state and mass adoption are insurmountable. Completely reform education in this country to make purer languages like Haskell more palatable for younger generations than, say, PHP, and I'll totally be wrong in 50 or so years.

I don't think I'm arguing the perfect language exists, nor do I think a complete education reform is needed.

I'm arguing that "Python is easier" is false, simple as that.

Re: JavaScript is Good, Actually

#322

Post by the_af »

AnimalMuppet wrote: post #309
the_af wrote: post #302

Earlier quoted context omitted.

> Are there anecdotes of non-absolute-beginners failing to understand that? For first-year students, sure. Do working software engineers have trouble with it? Sorry, I was unclear: I was talking about beginners. My argument was about intuitivity and "it's easier/harder to learn programming this way". Software engineers are already down the road of "I'm used to this, therefore this is the best way" :P If I understand…

So a language is more intuitive if it's similar to what we already know, and we already know math, and therefore "=" for assignment is not intuitive? OK, for first learning a language, I can buy that. I don't recall ever having trouble with that myself, but that's anecdote, not data...

To be fair, I never had trouble with that either. It was just an example of something I've occasionally read about some people approaching programming languages for the first time.

Re: JavaScript is Good, Actually

#323

Post by ricardobeat »

peterbraden wrote: post #118

Oh man, I hate these articles as they bring out the trolls. Javascript is a great language because it allows you to develop incredibly fast (scripting language) for a platform that runs everywhere (the web). It used to be far simpler, but IMHO, insecurity because of all of the FUD that this sort of article prescribes, has meant that the language has bloated to incorporate all sorts of syntax improvements and new patt…

This was true 7 years ago. Today JS is in frontend servers everywhere, and powering everything from games to IoT to developer tools, robots and smart fridges. All things that used to be territory of typed/compiles languages.

Re: JavaScript is Good, Actually

#324

Post by wruza »

slikts wrote: post #137
wruza wrote: post #39

Semantics and configurability is what what makes a language great. JS doesn’t have function environments, i.e. every unlexical lookup goes to global/window and that cannot be redirected. It doesn’t have green threads (at least). There are generators, but one cannot just yield without marking all the functions generators too (async/await in modern terms). Stack traces are lost when generators throw(). JS has no good i…

The generators or async/await in JS are 'shallow' coroutines because you can only `yield` or `await` in the direct scope of a generator or async function, but the benefit of shallowness is that the control flow is explicit; you don't have to consider whether a function call will suspend the calling context's execution or not. I find the explicit clarity to outweigh the reduced power of shallow coroutines. As an aside…

Thanks for node-fibers, that is something I missed and it looks promising, should try it server-side at least. But I'm not sure what you mean by "reflect on module exports", since there seems to be no way to enumerate all functions (in node), except those exported by hand. I workarounded it via "autoexport(module, x => eval(x))" and "// @export" tags, but it feels dirty.

I also bet that I couldn't make 'in' work for proxy with empty abstract target, but maybe it's just me. Btw, 'in' and 'of' are two separate iterators, one iterates array elems and the other iterates object's keys -- something essential to metaprogramming. My whole point on in/enumerate is that it considered legacy by someone special.

And on Vue: I didn't know that, but if Vue can't take advantage of Proxy, can I?

Re: JavaScript is Good, Actually

#325

Post by kbp »

cpburns2009 wrote: post #290
rusk wrote: post #65

Earlier quoted context omitted.

You still need to make `ObjectStream os = new ObjectInputStream(new FileInputStream(filename))); MyObject mo = (MyObject) os.readObject();` which is the most basic form I can think of (you've got to put in all them bloody `try/catches` as well don't forget, along with `public class MyClass { public static void main(String[] args) { ...` etc. etc.). Whereas javascript you can just go `require(myjsonfile)` I love java,…

> Whereas javascript you can just go `require(myjsonfile)` I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it?

> I'm not current on Node features, but that looks dangerous to do. Is that equivalent to reading the file and `eval()`ing it?

No:

    > const fs = require('fs')
    undefined
    > fs.writeFileSync('file.js', 'console.log("yes")'); require('./file')
    yes
    {}
    > fs.writeFileSync('file.json', 'console.log("no")'); require('./file.json')
    SyntaxError: file.json: Unexpected token c in JSON at position 0

Re: JavaScript is Good, Actually

#326

Post by kuon »

alangpierce wrote: post #252
bgorman wrote: post #185

Earlier quoted context omitted.

Almost everyone writing JavaScript these days uses a compiler like Babel, webpack, browserfy etc..

I think by "compiler", they really mean "typechecker", which is much more important for maintainability than code transformations. JavaScript does has two good typecheckers, TypeScript and Flow.

I worked with typescript for a project, but the compiler don't help a lot compared to the elm compiler.

Re: JavaScript is Good, Actually

#327

Post by hajile »

_o_ wrote: post #315
hajile wrote: post #301

Earlier quoted context omitted.

Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just…

Sorry but I believe you are wrong in basic presumptions. If they will do it properly, in c++ compiled to webassembly scenario, there will be no need for parsing (except some headers). Browser code (V8 in chrome?) will just take the opcodes and execute them, similar as CPU execute machine code in native applications. But normally, if this is a scripting language like, lets say python, that webassembly compiled python…

First, I suppose I'm obligated to say that I'm a huge fan of Wasm (and was a huge fan of pnacl for years before that).

Wasm (like asm.js before it) is target at unmanaged languages. A C++ codebase likely does very well with good performance. That was not what I was talking about. Convincing a game company to write their games in C++ is trivial. Convincing that same game company to write their normal CRUD website in C++ would be incredibly difficult.

Looking at apps, there's still issues. Consider Qt. While it's very possible to write everything in C++, loads of companies jumped straight onto the QML/JS bandwagon because its (generally speaking) much faster to write safe code in JS (also, running the v8 version that Qt requires would be terribly slow compared to the native engine). UI development is hard no matter what and C++ doesn't do it any favors. JS features like closures and dynamic objects make many things easier than static classes functions.

This means we need to look away from C++ to something that is managed and has faster code turnaround times. The best possible languages for this are (IMO) Scheme (or maybe Common Lisp) and SML (or maybe Ocaml or F#). You could also make arguments for something in the vein of Dart or Kotlin.

How do you bring these languages to wasm? If you use a JIT, you run into a rather large payload (4-10mb of code is going to have obvious impacts). In some cases like Ocaml where a native compiler to wasm is in the works, you still have a GC issue (basically, you can make an advanced GC that is slow or a basic GC that is "fast", but with other issues).

The addition of DOM API will solve the GUI issues (and maybe they'll rework them to be more like dart's API). Adding hooks into the builtin GC would reduce payload size down to something closer to unmanaged languages. 10 years after those are added (when outdated browsers can finally be ignored), wasm will finally be ready to replace JS.

Adding those features doesn't seem to be highest priority. Unfortunately, you and I will probably be nearing retirement age before they are generally usable.

As a point of interest, JS code could be getting much smaller and much faster to parse (plus becoming a better compilation target) with the JS binary AST proposal.

https://github.com/binast/ecmascript-binary-ast

Re: JavaScript is Good, Actually

#328

Post by hajile »

pjmlp wrote: post #307
hajile wrote: post #301

Earlier quoted context omitted.

Consider python. With all the built-in libraries, it's many MB of code. If my app is 1-2mb, I'll be pushing the limits (I'll definitely be looking at multiple bundles to reduce and spread out the load parse time). If that goes up to 10-15mb (which can't be split), you're now going to have major usability issues. That's before all that analytic stuff that isn't going away. People do notice the difference and will just…

A plan that is already in motion regardless how much you hate it. Not all languages are like Python, a language that I only use for shell scripts anyway. Blazor, Qt, Unity are all getting there. Adobe can even bring Flash back.

I love the idea of wasm allowing other languages, but it's going to take at least a decade to be usable for anything aside from heavy number crunching with C++. For a webpage, replacing the DOM with UI toolkit X is a pipe dream with problems ranging from aria/accessibility to web crawling and indexing issues.

Adobe won't be bringing flash back. It was basically just ES4. ESnext and HTML5 have almost all the good stuff plus quite a bit more while having far better performance than flash could achieve.

Re: JavaScript is Good, Actually

#329

Post by m45t3r »

lostcolony wrote: post #245
StavrosK wrote: post #209

Earlier quoted context omitted.

I don't know, getting people to run my Python code currently consists of "make sure you have Python 3, run `pipenv install`, run the code".

And if every Python developer, researcher using Python, etc, did that, it would be much less of a problem. The reality is, many, many don't. It's kind of ironic, really. With the Zen of Python stating "There should be one-- and preferably only one --obvious way to do it" why is it that it's so common for people to not do the thing that makes it reasonably portable? I mean, I currently am working with some code that,…

> Is the author not a Python developer? Well, he's a researcher.

I think this is why the situation is bad in Python: we have too many non-programmers in the community, that simply want something to work and get on with theirs life. If they can get by it by installing a bunch of libraries by running some command incantations as root, they're happy enough.

You don't have this problem with Node because the only niche that Node really matters is Web, and WEB DEVELOPERS know that their environment should be reproducible.

*: Even in Node this isn't really true, since we have yarn vs npm. Ruby is way more stable thanks to bundler.

Re: JavaScript is Good, Actually

#330

Post by CiPHPerCoder »

the_af wrote: post #321
CiPHPerCoder wrote: post #308

Earlier quoted context omitted.

Every language has its faults. Even a "perfect" language is faulty if the barriers between its current state and mass adoption are insurmountable. Completely reform education in this country to make purer languages like Haskell more palatable for younger generations than, say, PHP, and I'll totally be wrong in 50 or so years.

I don't think I'm arguing the perfect language exists, nor do I think a complete education reform is needed. I'm arguing that "Python is easier" is false, simple as that.

And I'm arguing that the average newcomer (if we need a specific definition of average, how about chosen at random among low-income American sixth graders far removed from big cities like San Fransisco or New York?) would have an easier time understanding Python to the level of being capable of basic file/network I/O than they would with Haskell, because Python will be more immediately familiar to them because they don't need to even know what a thrice-damned monad is.
Post reply on HN