JavaScript is Good, Actually • Hacker News Board

Re: JavaScript is Good, Actually

#351

Post by pjmlp » Thu, May 17, 2018, 6:28 AM UTC

hardwaresofton wrote: post #347

pjmlp wrote: post #126

Earlier quoted context omitted.

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

> What positive things can we say about a programming language where this is valid code? Just because it parses doesn't mean anyone would ever write it in a serious project. Also, I've seen worse in Java (AbstractSingletonProxyFactoryBean), the only difference being that someone wrote the code with good intentions -- not as a joke. "Idiomatic" Java code is often bloated, and people who write it have been trained to d…

Go is good as better C replacement for all use cases still being written in C that could actually be done safely in a GC enabled language, as they aren't targeting stuff like 16KB PICs.

For anything else, we have seen the future.

Re: JavaScript is Good, Actually

#352

Post by vinayms » Thu, May 17, 2018, 6:50 AM UTC

hajile wrote: post #348

vinayms wrote: post #134

Earlier quoted context omitted.

Because there is usually a need to input data or parameters and I prefer a GUI textbox more than file based or command based approach. I also prefer visual inspection and debugging. Browsers make all this simpler.

Consider bootstrapping a simple Electron instance. You get the whole browser, but you get the great node stuff too. https://electronjs.org/

May be I will try it when writing full fledged server side node code, but as of now a browser suffices for what I want.

Re: JavaScript is Good, Actually

#353

Post by pjmlp » Thu, May 17, 2018, 8:03 AM UTC

hardwaresofton wrote: post #345

pjmlp wrote: post #122

Earlier quoted context omitted.

We are in 2018, Java 8 was released in 2014. Before we used anonymous classes for the same effect. Also plenty of developers on the Java platform are polyglot.

Java was released in 1995, we're going to just ignore ~19 years of a consistent bad decision to make ergonomics worse for people who use the language? To be fair, good alternatives also haven't really existed for a long time either -- alternative languages on the JVM weren't popular, Golang and Rust didn't exist, C# required changing to a MS shop, ObjC was ObjC... But I'm not going to sit here and forget about a bad…

As mentioned "Also plenty of developers on the Java platform are polyglot.".

I never worked in a company of "Language X developer", rather developers that would use whatever language suited the project. Including mixing multiple languages on the same project if that would be the best approach.

In those 19 years, JavaScript was mostly used to make graphics jump all around the page and form validation, hardly something worthy of high order functions and currying.

Javascript, the language that was largely tolerated until a book called "JavaScript: The Good Parts" came out, in 2008.

Re: JavaScript is Good, Actually

#354

Post by tannhaeuser » Thu, May 17, 2018, 8:31 AM UTC

hajile wrote: post #331

tannhaeuser wrote: post #74

Earlier quoted context omitted.

I'm using JSON all the time, but it's hardly the be-all/end-all solution for even the basic use case of service payload serialization, let alone config file syntax or document syntax. To begin with, JSON lacks types for URLs, dates/times, and spatial data; it also lacks conventions for error messages and data graphs other than trees, etc. So I think Java not integrating JSON literals at the language level or some suc…

I think that lack is a strength. Lists, Maps, Booleans, Numbers, Strings. With these powers combined, you can create basically anything you can think of. Dates can be unix timestamps or ISO strings which are universal. Spatial data is a compound datatype anyway (plus, there are quite a few data representations depending on number of dimensions, cartesian vs polar, etc). The one datatype that JS could potentially bene…

Agree with your points regarding comments and multi-line strings; don't like optional commas, though.

With respect to your "lack is strength" argument, I can't help but find this unconvincing. We all know JSON is derived from JavaScript object/array literal syntax; your argument is akin to retro-fitting the requirements for service payload serialization to the suboptimal de-facto situation with JSON.

Re: JavaScript is Good, Actually

#355

Post by slikts » Thu, May 17, 2018, 11:34 AM UTC

wruza wrote: post #320

slikts wrote: post #258

Earlier quoted context omitted.

The criteria for this list of languages seems to have been "isn't JS". The story for metaprogramming in JS certainly is limited in some aspects; for example, there's no operator overloading and JS isn't homoiconic like lisps, but between dynamic inheritance in older JS and the newer additions like proxies, symbols, accessors, reflection API, protocols and being able to extend the 'exotic' behavior of arrays, JS can p…

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() is a very strong anti-pattern, and it's not needed there anyway. JS has the `with` statement that allows running code with a specific context, but its use is discouraged as it's really bad for readability and hard to optimize.

Re: JavaScript is Good, Actually

#356

Post by slikts » Thu, May 17, 2018, 11:35 AM UTC

lambdadmitry wrote: post #296

slikts wrote: post #137

Earlier quoted context omitted.

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…

> You actually can reflect on module exports and dynamically change them with node modules; you can't do it with ES modules, but that has the significant advantage of enabling static analysis. And yet even that advantage got thrown out from the language with the introduction of "import()". Apparently static analysis is a non-goal (see discussion in [1]). [1]: https://github.com/tc39/proposal-dynamic-import/issues/35

Dynamic imports don't replace static imports.

Re: JavaScript is Good, Actually

#357

Post by slikts » Thu, May 17, 2018, 11:52 AM UTC

wruza wrote: post #324

slikts wrote: post #137

Earlier quoted context omitted.

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…

eval() has no legit use case in JS, and I really don't understand what the point of "// @export" would be. You can't reflect on module or function scopes, but that's a feature and gives you encapsulation.

for-in is a legacy feature; due to dynamic inheritance, it's generally not safe to use without also calling Object#hasOwnProperty() every iteration. for-of is not for "array elems", it uses the iteration protocols that are implemented for all built-in collection types, not just Array, and some DOM types, and can be implemented for any user types. Protocols are a much more flexible and clean approach to metaprogramming than overloading the for-in looping construct would be.

You can't use Proxy if you need to target legacy browsers like IE9, and Vue needs to, since it's about 15% of all browsers.

Re: JavaScript is Good, Actually

#358

Post by blauditore » Thu, May 17, 2018, 1:06 PM UTC

cesarb wrote: post #228

blauditore wrote: post #101

The fact that the author omits semicolons in JS somehow fits the theme of this post...

There is a school of thought that semicolons in JavaScript should be omitted except where they can't: https://github.com/standard/standard/blob/master/RULES.md#se...

I'm well aware of "Standard"JS, and it's highly controversial to put it mildly.

The fact it was named "standard" is quite infuriating, as it's just a bunch of random people churning out an arbitrary set of formatting rules. This is not how standards are acquired. Now, many devs unfamiliar with JS use it because they google "javascript standard formatting" and obviously find this.

Re: JavaScript is Good, Actually

#359

Post by SZJX » Thu, May 17, 2018, 2:57 PM UTC

egeozcan wrote: post #75

rusk wrote: post #55

Earlier quoted context omitted.

I think that much of these criticism relate to the implementation, and the runtime (i.e. browser) rather than the language itself. As a scripting language for a browser environment it's pretty good. Modern variants have lots of lovely language features and tools like babel mean you can use a lot of these new features without sacrificing backward compatibility. The threadless/nonblocking model is "interesting" but in…

There are a lot of valid criticisms against JavaScript. This is a fact. It's not a great language (clearly demonstrated by the discussion about it being good or not) but it's not terrible. I doubt anyone calls JS terrible on its own merits. There is a lot of hate against the runtime (edit: I mean the browser, not JS VMs or interpreters). The runtime enforces JS and the runtime itself is enforced everywhere. There is…

Not sure many people would think that "Ruby is the only language", and not sure what's your point there. From my impression, if somebody can decently do backend work with Ruby, then they're probably a better programmer than some JS-only newcomer. Is Ruby already becoming the new PHP? Don't think it's time yet, and Ruby despite its many drawbacks is still generally much better. Not to mention Node seems to be all the rage in recent years and Ruby isn't even that "popular" anymore. Though indeed I personally always had doubts about Ruby. I haven't touched Ruby ever since I started programming projects in Elixir, which I like much more.

Re: JavaScript is Good, Actually

#360

Post by SZJX » Thu, May 17, 2018, 3:09 PM UTC

anton-107 wrote: post #86

egeozcan wrote: post #75

Earlier quoted context omitted.

There are a lot of valid criticisms against JavaScript. This is a fact. It's not a great language (clearly demonstrated by the discussion about it being good or not) but it's not terrible. I doubt anyone calls JS terrible on its own merits. There is a lot of hate against the runtime (edit: I mean the browser, not JS VMs or interpreters). The runtime enforces JS and the runtime itself is enforced everywhere. There is…

> 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 complex structure without resorting to unsafe code. Maybe I'm just a shit low-level programmer in terms of thinking about ownership though.