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

361–369 of 369 posts

Re: JavaScript is Good, Actually

#361

Post by SZJX »

CiPHPerCoder wrote: post #157
tromp wrote: post #98

Earlier quoted context omitted.

I like to think of Haskell as a great language. It still has its warts (e.g. last [0,1/3..2] > 2), but if you wan't wart free, there's probably nothing beyond lambda calculus. Being the closest thing to lambda calculus with enough syntactic sugar on top to make it practical is a large part of what makes Haskell great.

The one thing that makes Haskell not great is that its understanding is not widely intuitive. People with mathy backgrounds that don't blink at the phrase "lambda calculus" won't consider this, but a lot of people struggle with math. If you can't put it in the hands of a 6th grader (in the public school system with no special tutoring) and have a reasonable chance of it being understood (n.b. I self-taught myself ear…

Depends on how you define "great". Haskell intentionally keeps itself off the mainstream. That has always been a deliberate choice. There are now already plenty of more practical functional languages, e.g. OCaml, F#, Julia, Elixir, Clojure, which are in part driven by the advancement in research brought about by Haskell, so it has been fulfilling its duty in that way.

Re: JavaScript is Good, Actually

#362

Post by steveklabnik »

SZJX wrote: post #360
anton-107 wrote: post #86

Earlier quoted context omitted.

> It's not a great language (clearly demonstrated by the discussion about it being good or not) but it's not terrible I'm wondering what would be an example of a great language? Because we know that there are only two kinds of languages: the ones people complain about and the ones nobody uses

My two cents is that I currently find Elixir and Julia to combine productivity and all the goodness from functional programming really well. Not sure what sort of backlash they'll get if they go more mainstream in the future (which I believe they will). I don't think it's totally hype since I also tried my hands on Rust a lot but I really struggled and eventually disliked it a lot. I couldn't seem to implement any co…

Complex data structures often need unsafe; writing them isn’t a good way to learn Rust. Most already have implementations you can just use, so it’s not something most rust programmers do often.

Re: JavaScript is Good, Actually

#364

Post by wruza »

slikts wrote: post #355
wruza wrote: post #320

Earlier quoted context omitted.

I tried to include all my rant points into this example. E.g. what if fetch() doesn't go async? Then we don't have to mark it like that and don't have to await. Where ui and commit lives? There should be a unique environment for this specific api call or a whole subsystem. objs is something both enumerable and proxied, etc. It can be done in JS, but IRL it will be: ./file.js: function foo(ctx) { // @export for (let x…

Having to explicitly mark where the control flow goes to the event loop with `await` is a very small price to pay for making the code much more clear. This is why I don't recommend node-fibers or deep coroutines in general. Destructuring would make your example look better: foo({ui, commit, objs}), and then there's no need for typing out ctx. Another thing that's not needed with for-of loops is .iterate(). Using eval…

I used eval as a workaround; autoexport does fs.readFile() on module’s filename and adds all lines marked with @export comment to exports. Eval is the only way to get a function value from other module, since functions are local to the context that is implicit and only accessible through eval-ing closure. That’s my code and my company, so I don’t push it to anyone now or in the future. I know how important antipatterns are in general.

Destructuring looks good here, you’re right. Actually, this thread somewhat relaxed my js hostility and I see it as an alternative that has reasonable tradeoffs (but still not as a friend though).

Re: JavaScript is Good, Actually

#365

Post by m45t3r »

StavrosK wrote: post #341
m45t3r wrote: post #329

Earlier quoted context omitted.

> 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 th…

> we have too many non-programmers in the community, that simply want something to work and get on with theirs life The impact of those people in the ecosystem is zero, though. They don't inconvenience anyone by producing badly-written libraries, they literally do their job, produce what they want to produce and everyone is happy. I'm not sure why they get lumped in with "this problem". I don't know why I hear this a…

Well, it impacts those people who needs their work, for example for validation of scientific experiments.

It doesn't impact the ecosystem very much for sure, however I wouldn't say that the impact is zero.

Re: JavaScript is Good, Actually

#366

Post by Volt »

pjmlp wrote: post #126
hardwaresofton wrote: post #84

Earlier quoted context omitted.

> 1. We've had higher order functions since 1960s, it's not a new discovery that is singular to JS, that award goes to LISP and Scheme. My point wasn't that javascript invented higher order functions, it was that making them first class isn't something all languages have chosen to do, and is clearly a good choice. > 2. Concurrent execution has also been introduced in the 1960s (Dijkstra 1965), Ada and Erlang supporte…

> people from Java Java will continuously bash JS as being the worst language they've ever seen. Rightfully so. What positive things can we say about a programming language where this is valid code? [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!!) Just a snippet, more fun can be had at http://www.jsfuck.com/ Or the community tradition of writing one liners…

For comparison, Haskell: https://gist.github.com/folone/3486644

Re: JavaScript is Good, Actually

#368

Post by slikts »

wruza wrote: post #364
slikts wrote: post #355

Earlier quoted context omitted.

Having to explicitly mark where the control flow goes to the event loop with `await` is a very small price to pay for making the code much more clear. This is why I don't recommend node-fibers or deep coroutines in general. Destructuring would make your example look better: foo({ui, commit, objs}), and then there's no need for typing out ctx. Another thing that's not needed with for-of loops is .iterate(). Using eval…

I used eval as a workaround; autoexport does fs.readFile() on module’s filename and adds all lines marked with @export comment to exports. Eval is the only way to get a function value from other module, since functions are local to the context that is implicit and only accessible through eval-ing closure. That’s my code and my company, so I don’t push it to anyone now or in the future. I know how important antipatter…

I have trouble picturing what advantage that setup would give over using ESM or node modules.

The Function constructor is a better alternative for eval(), but still only as a last resort. eval() itself has no use cases.

I find that most JS criticism is ill-informed, because people are too quick to jump to blaming the language due to its reputation. Not that I'd call JS a great language, but it has redeeming aspects.

Re: JavaScript is Good, Actually

#369

Post by hueving »

amelius wrote: post #190
hueving wrote: post #162

Earlier quoted context omitted.

You pass functions just like any other argument. clos = 42 def foo(x): return x + clos def bar(y): return y * clos higher_order(foo, bar) What's so hard about that?

Here's a challenge: try inlining the foo and bar in the call (because this is how functions are typically composed in functional programming) You could do this with a lambda construct in Python; but this only works if the function has a single expression-statement; it doesn't work e.g. when you have a bunch of assignments inside the function you are inlining.

>Here's a challenge: try inlining the foo and bar in the call (because this is how functions are typically composed in functional programming)

Sure, it's ugly but I think it's a silly challenge. Complex functions defined in the function call are un-maintainable anyway IMO.

Post reply on HN