Hacker News Reader

> Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language

Everybody is everybody who has used other languages intensively or is into programming languages or, the most negative parties against JS, people who are into formal methods. But 'everybody'; I get often downvoted to hell for being negative on JS on Reddit. And i'm not using a baseball bat; i'm subtle about it as I don't care for language wars. Use what you want, but please don't say it's the best thing to happen to humanity. But no; 'everybody' (as in headcount) thinks it is the best thing that happened to humanity and that other languages should die because you can write everything in JS anyway.

I said 'almost everybody'.

Even the most ardent JS fans I work with call it objectively bad.

It's hard to be objective on this.

A modern JavaScript engineer would point out that:

  - The community is very accepting of new engineers. 
  - The ecosystem is huge and there are great solutions
    available to many problems.
  - It's easy to write consistent code while avoiding
    many problems with the language if you use `eslint`,
    `prettier` and `flowtype`. Tooling on the web is
    excellent and rapidly improving.
  - You can use one language on the back-end and front-end.
    You can even use the same language to write desktop,
    embedded, command-line and curses applications.
  - `babel` drives the adoption of new features into the
    language with greater vigor than many other languages.
  - The VM is very fast due to lots of work by Google,
    Mozilla, etc. There's also methods of interacting with
    modules written in WebAssembly or if you're on the
    back-end native modules written in Rust/C++.    
  - JavaScript is driving a lot of momentum for
    new programming languages (Reason, Elm, PureScript, etc)
    since as a transpilation target it gives you access
    to many environments and libraries at the get-go.

In my opinion JavaScript in 2017 is a much better language than JavaScript in 2012. I wouldn't call it objectively good but I certainly wouldn't call it 'objectively bad'. There are many reasons to choose it beyond the syntax and semantics of the language itself, and there are effective treatments available for most of the warts it was once known for.

It's dominating because of the sheer drive within the community, and if there were award ceremonies it'd be winning 'Most Improved' year-upon-year.

How much of that is just solving a problem created by Javascript?

A community accepting of new engineers isn't. But it isn't something to brag about either, because it never means its literal sense. Instead, people say a community accepts new engineers when it has low enough standards that newbies feel empowered without learning anything new. The one language to rule them all mentality is also about low standards.

The ecosystem is just compensating the lack of native features and bad overall design; so is the tooling. Babel is a great tool, but it's just compensating for the lack of a good VM at the browsers; ditto for all the transpiled languages.

Besides, no JS VMs aren't very fast. They are faster than the slowest popular languages (Python, Ruby), but can't get anywhere near the moderately fast ones like Java and .Net.

Almost none of the things I mentioned are solutions to 'a problem created by JavaScript' therefore your question seems deliberately misleading.

An accepting community can be a large funnel: it doesn't need to mean that nobody improves or that there are no selection effects. More candidates means more chaff, but also more wheat.

Babel isn't merely contributing to a 'lack of a good VM'. It's more valuable to see it as a playground and streamlined process for large-scale testing of language-level features. (It solved this problem later on. It was originally meant only to solve the problem of running modern code on older VMs.)

I guess you could argue that the VM should have been complete in 1995 but what programming language has managed this?

Also, I don't think that comparing JavaScript's VM to the VMs of statically typed languages is fair. You mentioned yourself that in comparison to similar dynamically typed languages it's faster. Compare apples to apples.

I don't think I'm bending the truth here. There's been a lot of investment into JavaScript, and not all of the problems that have been solved are obvious or easy.

At this point it is ascendant because it has effectively solved lots of problems that relate to speed of change and it has done this seamlessly on a large number of platforms. I think people look at this and pattern-match to 'first-mover advantage' or 'JavaScript has a monopoly on browsers' but neither of these things were what got us to this place: it was innovation in maneuverability.

(It won't necessarily stay ascendant now that it is so easy to circumvent writing JavaScript but yet still plug into its ecosystem.)

> More candidates means more chaff, but also more wheat.

That needs substantiation. It's not immediately obvious in any way.

About Babel, notice how we never had a problem playing with language-level features that target the PC? That's the difference a good VM makes (although on the PC case, it's not virtual). Besides, you are conflating VMs and languages somehow - they have only a tenuous relation.

About the speed, Javascript misses most of the expressiveness of Python and Ruby. It's more on line with Java but if you want dynamically typed languages, with PHP and Perl too. Yet, it's not any faster than PHP and Perl. It has reasonably fast runtimes - those are not an issue for the language, but are not a big selling point either.

Overall, the reason Javascript still exists and is viewed as a serious language is all because it has a monopoly on the browsers. It was worked on enough that if that monopoly goes away it will still be a good choice for some stuff, but it is not an stellar language, and can't be coerced into becoming one unless it can pass through a Perl5 - Perl6 level transition.

>Overall, the reason Javascript still exists and is viewed as a serious language is all because it has a monopoly on the browsers.

Basically, this. ClojureScript and others are simply the efforts of sane, experienced developers that don't want to cope anymore with Javascript and its warts.

I don't think that comment requires more substantiation than yours that there are "low enough standards that newbies feel empowered without learning anything new". The more people that learn your language, the more likely it is that you will find some that can contribute to its state-of-the-art. A low bar doesn't effect people that would surpass a higher bar with ease: they still wish to learn and sate their natural curiosities.

In fact, the normal stereotype of JavaScript developers as people constantly chasing new technologies and libraries is actually true, but what you are claiming is the exact opposite: "people feeling empowered without learning anything new". People are empowered and learning new things because there is a low barrier to doing so and this is exciting.

  > misses most of the expressiveness of Python and Ruby.
  > It's more on line with Java

Have you actually written modern JavaScript code? I personally think it's more expressive than both Python and Ruby, and certainly much more so than Java.

  > Overall, the reason Javascript still exists and is
  > viewed as a serious language is all because it has a
  > monopoly on the browsers.

As it stands JavaScript doesn't have a monopoly on the browser. You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia? I'd argue that it's investment in the platform itself and particularly 'innovation in maneuverability' (number of environments, speed of prototyping, backward compatible code, ease of hiring) which keeps developers using the platform.

In my opinion, the existence of NPM and a broad range of environments that you can run your code on will likely mean that JavaScript would still be a productive environment even if the web was to die.

>You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia?

No, it isn't inertia -- one important reason is that creating a transpiler to JS invariably ends up with a crippled (feature-restricted), slower version of the original language (Clojure, etc.)

Thus the hope placed in Webassembly.

People aren't choosing between those languages based on performance or avoiding any due to missing features. I've never heard of anybody doing that.

People generally choose languages due to assumptions about their hiring pool.

If people only choose languages based on popularity, how do you imagine any language ever becomes popular?

My point is that those transpiled languages aren't that stymied. You can use them without a lot of problems, and they're being left on the bench for reasons other than their feature set.

Companies generally choose JavaScript because there are lots of developers to choose from, it runs everywhere and the ecosystem is huge.

Engineers choose something like PureScript as it's not a 'blub' language and people think that by choosing it they will be able to hire (or be seen as) "math geniuses". I'm sure the feature set is important, but it's not enough to unseat a language with the previously described properties.

> Javascript misses most of the expressiveness of Python and Ruby.

Could you please give examples of expressiveness of Python or Ruby that Javascript lacks?

You can't change the rules interpreting your source code so that the parser will expand a small command into an entire program, or that it will read a more fitting DSL that does not resemble your original language.

You can not inspect an object and change its type or the set of available properties based on some calculation.

You can not run some code in a controlled environment separated from your main code.

> Even the most ardent JS fans I work with call it objectively bad.

Counterargument: Read

Douglas Crockford - JavaScript: The Good Parts

Even though this book is somewhat "aged" (it is from 2008), I know no better book where it is presented so well what is so interesting about JavaScript and how this language is so often misunderstood.

If after reading this book you still consider JavaScript as "objectively bad", so be it. But first read the arguments that are presented in this book.

It is very telling that you don't see the irony of the fact that a language needs a book titled "Language X: the good parts".

Good tech mostly speaks for itself. When you need entire books to convince you that a language has good parts, then you know the language has a problem.

What are their objective measures?

I can think of one: the fraction of design decisions that the language's creator, standardizers, and serious developers wish they could change but can't.

> but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry.

What language is not flawed? And why are we "screwed"? I don't get this FUD...there are more important things than language-choice such as dependency management system + community + ecosystem. JS lets you get on with the job and get things done quickly. You need performance - use C/C++ bindings. Its been clear for a long time that JS is the safest long-term choice and is slowly creeping into every other language's castle.

It doesn't bother you that huge portions of our tech stack are sitting on top of layers of terrible language design that our ancestors will have to deal with? Perhaps the parent post is looking more to the future. Of course it all still works, but when you think we could be doing the same job with Lisp, Smalltalk, (insert any non perfect, but much better than JS technology), it does make me cringe a little.

> that our ancestors will have to deal with

You meant descendants?

Anyway, they won't. They will throw away the garbage and rewrite anything good they find. Just like we do.

Haha, yes my goof up. I disagree that they will rewrite though. Nobody is willingly rewriting millions of loc.

Well, you were right about one thing: you don't get it. ;)

Just look at the prototype hell. Look at the quirkiness of the comparison operator. Type inference. The mess piles up extremely quickly.

"Disciplined devs don't make those mistakes" is NOT an argument and never was. Decades later, people believing themselves to be godlike C/C++ devs still make stupid mistakes.

But I guess learning from the past won't happen for people who fanboy and have a survivorship bias. And have money on the line.

It's flawed because 99.999% of the time your code will work just fine. Job done. Then one day, "undefined is not a function" and your airplane falls out of the air.

This happens in all languages... look at the Toyota acceleration bug for a real world of example of your hyperbole. They were using MISRA C. Languages dont fix spaghetti, laziness, tight deadlines, bad engineers, etc.

> This happens in all languages...

To some extent, yes, that happens in all languages. To some extent 10^100 and 1 are both numbers. That does not mean you can even compare them.

I'm not sure you can do spaghetti and still do MISRA C. Doesn't MISRA have some things about goto, cyclomatic complexity, and such?

type safety is becoming a hugely desired feature for developers again

I don’t think anyone ever hated type safety, I think they hated verbose syntax and unfortunately conflated the two.

Now we’re finding a happy medium with compiler type inference and people are like, wait what?

Dynamic typing is objectively much more flexible and easier to prototype in. Static typing is much easier to build large and robust systems in. Eventually we'll get to the point where everything you can do in dynamicly languages can be done in staticly typed languages (more verbosely), but we're not there yet.

For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity.

This is actually, IMHO, one way Go strikes a happy balance between static and dynamic typing. It provides a (runtime) safe and low-verbosity way to write dynamically-typed code, i.e. `interface{}`. Rust is slated to get something similar with `impl Trait` values.

> For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity.

Look at this verbose OCaml:

    type my_return_type = AFloat of float | AnInt of int | AString of string;;

    let my_fun n =
        if n < 0 then AString "negative"
        else if n == 0 then AFloat 0.0
        else AnInt n

    # my_fun (-4);;
    - : my_return_type = AString "negative"
    # my_fun 0;;
    - : my_return_type = AFloat 0.
    # my_fun 42;;
    - : my_return_type = AnInt 42

(But yes, to use these values you have to do pattern matching, and if you're in a FUD mood, that is "runtime downcasting" and incurs a "cost of safety".)

Yes, you can always generate a new union type for your return type and then pattern match on it. That is certainely better than C where you must use unsafe tagged unions or void pointers. It is more verbose than in dynamic duck-typed languages, though I'll give you that it's quite compact in OCaml.

In a dependently typed language, you could reduce verbosity at the use site as well as avoid the extra runtime branch.

So how exactly would you write the above five lines of OCaml in fewer than five lines in Idris?

The verbosity is not in the function definition, its in the match expression needed at _every single call site_. In Idris, the definition would be similar length or longer, but call sites would not need a match expression.

> provides a (runtime) safe and low-verbosity way to write dynamically-typed code, i.e. `interface{}`

Since Go 1.9 was released with its new Type Aliases feature a few months ago, the verbosity is even lower. By putting `type any = interface{}` somewhere in your package, you can just write `any` instead of the verbose `interface{}` everywhere you want some dynamic typing.

The response to the recent Rich Hickey talk definitely points toward "dynamic typing as its own solution" (instead of a stop-gap until someone makes static typing less "verbose") being a popular view nowadays.

https://news.ycombinator.com/item?id=15464423

It's really not that bad. Modern JS isn't ideal but it has many parts of it that are as good as or better than Ruby or Python, but most people don't act like they are horrible languages. I'd gladly use it over either.

What causes you to say that JavaScript is a flawed language? Not trying to be snarky or saying you're wrong, just want to better understand your reasoning.

It seems to me that at one point JavaScript had a lot of confusing/bad design decisions but that more recent changes have largely eliminated them. For example, I almost never have to worry about "this" anymore.

I recently worked on a project using TypeScript and I really appreciated how it changed a lot of the bugs from being runtime to compile time. I could definitely see how that is a big flaw, but it seems like the community is developing solutions.

I don't think "this" in JavaScript was a bad design decision. The bad decision was how functions create their own scope in unexpected situations. Also, I think modern JavaScript still requires a lot of "this," just much less ".bind(this)" or "var that = this."

But the thing is, just because arrow functions exist doesn't mean people are going to use them. Similarly, just because modern browsers allow "let" and "const" doesn't mean people will stop using "var."

I agree that JavaScript is generally fine if you stick to the new parts of the language, but that in itself is a pretty big problem. Maybe not for me and you, but for software development in JavaScript generally it's really not ideal.

https://www.destroyallsoftware.com/talks/wat

About WYSIWYG, we are missing standards on our APIs. SOAP was going that way but it was way too much, way too early.

Either that, or an ASP.Net view where the backend is interacting with the user through a browser. But that doesn't work well. It's much better to standardize the backend API than the entire frontend.

>SOAP was going that way but it was way too much, way too early.

I think SOAP successfully demonstrated that rigorous "API standards" are a pipe dream. Swagger/REST is probably as good as it's going to get.

> WYSIWYG web design (a la Dreamweaver) died off ....

Which is why what we actually need is a la Delphi

I have been thinking about that and there is an issue with it; Delphi (and VB) where written in a time when devs paid a lot for software tools. Besides some niches (embedded) that is not really the case anymore. You expect to pay a few $10 at most in total if that. And a lot of people (but that might be the HN/Reddit echo chamber) demand all to be OSS as well they work with. Making 'a modern Delphi' is a lot of work; years of it. And much of that time is not 'fun', it's hard work polishing little parts and having user test groups feedback on it and polishing it some more. The time that you could be Borland seems gone (unfortunately imho) and i'm not sure how you can make the kind of polished tool you are talking about in the current climate. Maybe someone else here has some different views though.

There are companies trying it though,

https://anvil.works/

https://www.outsystems.com/platform/

JetBrains is probably a good example of a "Borland" like company.

Outside HN/Reddit bubble that are plenty of companies that are willing to pay for software, the supermarket cashier doesn't take pull requests.

Also, the back to native focus on mobile platforms, including Google having to integrate Android apps on ChromeOS, might make it less relevant, given that native IDEs do offer some Delphi like experience.

JetBrains never did any rapid UI IDE like Delphi did. In fact, all their IDEs are in Swing, which is a mess. I'd totally love having CLion/PyCharm with Qt UI designer, but it's not going to happen.

The easiest time I had writing GUIs was when I used PyQT. I designed the UI in Qt Designer, loaded it in the python code, set the bindings and voila, it was working.

Btw Visual Basic continues to exist under Visual Basic.NET and if you stick to the basics you could learn to write C# GUI programs pretty quickly.

I agree writing GUIs by hand is very counter-productive.

They have a GUI designer for Swing.

https://www.jetbrains.com/help/idea/components-of-the-gui-de...

And integrate with Scene Builder for JavaFX.

JavaBeans are the Java version of VCL components.

Qt doesn't have a component eco-system like Java or even .NET enjoy.

The company behind Qt is still trying to sell QML to C++ developers, looking from the set of talks at Qt World Summit.

Outsystems and Jetbrains are these examples but on the other hand they are not; they are 'old'; they both exist since 2000 and at that time pushing into the market was a lot easier. I was more thinking of a company starting now, to which I'll check out Anvil.Works. There are more new companies working in the space, for sure, but they all miss the breadth that Borland had (they really had a lot of cash and developers on hand in those days).

But yes, Outsystems (I worked with them and their product quite a lot in the past) could be considered a Delphi. But still not modern; it's rather painful building apps/sites with it that people seem to want.

Jetbrains can be considered a Borland; I didn't think of that because I consider them more in the space of 'low level' programming tools (which, like you say, includes Delphi functionality, but a modern Delphi wouldn't be like the old Delphi; it would need a lot more innovation).

Anvil founder here!

The crucial difference between Outsystems(/Bubble/etc) and Anvil is that Outsystems tries to be a "no-code" environment, and we think that's a mistake (or at least, a different market).

Delphi and Visual Basic proved that writing code isn't the problem - code is the best way to tell a computer what to do. But writing code in five different languages to produce "Hello World" on the web...now that will slow you down.

(Count 'em: JS, HTML, CSS, backend eg Ruby/Python, SQL. We do everything in Python, which gets you going much faster. We just got back from PyCon UK, where among other things we got an 8-year-old building database-backed web apps in an afternoon. That's the sort of thing that used to happen with VB/Delphi.)

Thanks; that sounds very interesting. I will check it out tonight.

Was the talk recorded?

There's a healthy market of RAD/lowcode tools similar to Delphi these days. One example is Mendix: https://www.mendix.com/application-platform-as-a-service/

Full visual development, runs on a scala runtime, can be deployed (visually) on cloudfoundry, docker/kubernetes, etc.

Thanks for the heads up, one more for my list. :)

Funnily enough I was looking at the title and just thinking in 25 years time I will still be programming in the same three languages C, Pascal/Delphi and SQL I learnt 25 years ago.

Interesting. Can you elaborate more?

Imagine WebComponents finally becoming mature and having a programming environment for RAD on the Web, using toolbox with drop-in components for doing application development.

There are already some attempts at it, for example https://anvil.works/

Unforuntately JavaScript is the present and, yes, we're screwed.

>* If that's the future, we are screwed as an industry.*

Agree 100%. However, i find Javascript pretty good for quick and dirty "MVPs".