Hacker News new | ask | show | jobs
by pedrocx486 2209 days ago
It's a bit sad that people today still "fanboy" against a lang, like a lot of people still do for PHP (which has absolutely improved from the absurdity it was). JS followed the same path, ES2016 is an absolute dream to code on.

Maybe I'm biased? PHP paid my bills for a long time and currently I'm a front-end developer that works mostly with Angular (but sometimes I jump into the .NET Core backends). I love JS and TS, they evolved nicely along the years.

Nothing against being a fanboy for one specific lang, but thinking "X" language is bad/joke/nightmare isn't nice and makes people that work with them look like losers, which they aren't.

5 comments

PHP and Javascript both improved significantly, but both still have horrible legacy baggage that can't be rid of, namely weak typing (not dynamic, where a variable can hold any type, but weak, where "1"+2=3). For me, that makes programming in either language like running in a minefield. And still, I write Javascript daily, because myeusers don't care about weak typing :-)
If you really care so much, why not simply embrace TypeScript?
Perhaps one day I will. When I last started a big JS project it wasn't mature enough to build a company around. This does seem to be changing.
TypeScript is awesome compared to JavaScript and even to other popular C-like languages. But it inherits all of the problems of the JS ecosystem without providing all of the benefits.

To make a JS package consumable by a reasonably strict TS project, someone has to basically rewrite the package. It's less effort than writing one from scratch, but it's not free.

> To make a JS package consumable by a reasonably strict TS project...

I’m not sure what you mean by “strict” here... Certainly one can use JavaScript from TypeScript, and even provide type information for the JS with declaration files. [1] Does a “strict” project require something beyond this?

[1] “Declaration Files”, TypeScript Handbook https://www.typescriptlang.org/docs/handbook/declaration-fil...

Type information is easy to half-ass: list all the exports, mark them as 'string', 'Object', 'Function', done.

Adding the actually correct and reliable types is the hard part. (But easier than writing the code in the first place.)

The typescript compiler can be a bit slow at times as well which dramatically lowers the developer experience when using typescript
Javascript is a lot saner than that. The result is "12". (I'm ok with automatic casting so long as it's an embedding. Every number has a reasonable string representation, but not vice versa. Wanting explicit casts like in Python is defensible, though.)
Huh, what do you know.

Still, this is unforgivable in my book:

  [] + {} == "[object Object]"
  {} + [] == 0
For the first, I frequently (for my own projects) change the Array prototype to have

   Array.prototype.toString = function () {
      return '[' + this.join(', ') + ']';
   };
It would be convenient if Object.prototype.toString by default threw an exception, since the default breaks the embedding rule I described.

The second example is misleading, and it has nothing to do with the rules for addition: the {} at the beginning of the expression is parsed as a code block, played off the rules for what the value of a Javascript statement is. More realistically, we have

   ({}) + [] == "[object Object]"
but the original is, effectively,

   {
   }
   console.log(+[]);
I didn't realise about the second one. Thanks!
Thanks, I never realized that the second one was parsed as a code block rather than an object!
Strong/weak and dynamic/static. JS is dynamic, but variables will always have a type, which is memory safe - which makes types strong.
I’ve heard another definition of strong, which is that the compiler will make more guarantees, and in those cases the terminology was:

    * safe/unsafe
    * strong/weak
    * static/dynamic
Note that while safe/unsafe is basically all-or-nothing, strong/weak and static/dynamic are more of a spectrum, so JavaScript would be safe, weaker, and more dynamic than other languages. Typescript makes JS stronger when authoring code.
Also sound/unsound
I thought weak/strong typing is more about how explicit/implicit type conversion is. In PHP and JS it's almost always implicit and they don't warn you for mixing most types, whereas e.g. Python will complain. That's one thing I don't enjoy with PHP/JS. A lot of certainty goes out of the window with it.
Everyone likes different things.

'1'+1=2 prevents a lot of errors. The languages tries to help you along compared to an harsh error. Maybe you want a harsh error.. halting everything until you declare a new variable with the same type and have to go through a manual conversion. For me let the language handle that. If you are tdding anything unexpected will be caught anyhow if you are worried how things convert.

It's like rust in terms of memory management vs c. It handles it for you..

Implicit string to number conversion is more like C in terms of memory management, in the sense that it's a huge footgun that you will definitely shoot yourself with. I have never seen it prevent errors, only make them worse by hiding them from QA so they can reach production and ruin your weekend.
It's unfortunately in JS that + is used for both string concatenation and number addition. There are however defined rules that anything concatenated with a string becomes a string. And anything used with -/* > < becomes a number. As a beginner in JS I always used -- instead of plus when doing addition. But as I got more experienced I learned what was strings and what was numbers. And if I'm not sure I add an assertion - so that there will be an early error. I also parse all input (user input etc) not even a static strong type system will help you there, you always have to check/parse the input at runtime! JavaScript is strongly typed as in whatever the user inputs it will be converted to a type. JS don't have that many types and usually it becomes a string.
Would you agree that a language X can be objectively superior to language Y?

I worked with PHP professionally for some 10 years, with very competent colleagues from whom I've learned a lot. The PHP ecosystem with Composer and Symfony components is quite good. Still, PHP itself is a terrible language. I have less knowledge but a similar opinion of JavaScript. Doesn't mean people working with PHP or JavaScript are losers - I admire their tenacity and do feel a little bad for them.

The point is that a language can evolve so much they are not even the same language. I prefer ES2016 to Python for example.
Eh, the weak typing intrinsic in JS still makes Python win out between those two.
That really is use case dependent for me. In the context where I have made a thoughtful choice to use a dynamically typed language, I find strong typing seems to make things unnecessary clunky with not much gain, especially in webdev dealing with a lot of JSON and UI display. And if I’m in a situation where JS/dynamic language is not a good choice then I prefer a real statically typed language, not a middle-ground.
In what situations do you find weak typing useful? I've only ever had it introduce bugs and not make my life any easier. Meanwhile dynamic typing makes it a lot quicker to prototype things (vars that can be null or an int, for instance).
Python turns you into someone who cares how many invisible characters and of which type for each line you code. Weaking typing vs strong typing is the least of your concern
You (should) do that in other languages too. I'm not a fan of the way Python does it, but 1. it's not like you decide tabs vs spaces anew on each line, and 2. this is simply not a practical issue, unlike weak vs strong typing.
Numpy wouldn't work in JS because you can't overload operators afaik. Numpy/scipy are reasons why many people love Python.
It would work. All those overridden operators are just functions. It wouldn't be as concise or as intuitive though.
Yes, that was the point ;) Both languages are practically Turing complete so they are equivalent if you're just interested in what you can build with them.
Ah ok, by "numpy wouldn't work in JS" you meant something like it wouldn't be popular or as loved. Makes more sense now.
Terrible compared to what? What do you find a better language? What makes a language terrible for you?

Is COBOL terrible or C Or Go?

Good questions, not sure I can answer satisfactorily :)

> Terrible compared to what?

Terrible compared to other available programming languages.

> What do you find a better language?

Lisps, Haskell, Erlang, Rust, but even eg Python, Ruby, C, Java.

> What makes a language terrible for you?

Allowing me to do unreasonable things and resulting in unreasonable behaviour. Eg JavaScript:

[] + {} == [object Object]

{} + [] == 0

> Is COBOL terrible or C Or Go?

Programming languages are products of their time and context.

When COBOL was created, it might've been the best there was. By now, I think COBOL can be considered worse than many alternatives. If someone decided to write a non-toy greenfield project in COBOL today, I'd be surprised and might question their sanity.

C has two things going for it: it's a simple language and it's close to the hardware. I wouldn't call it terrible.

Go, now I really dislike Go, but I think there might be situations where it's the right tool for the job. Simple web services perhaps?

PHP was terrible already when it was created. I don't hold that against Rasmus, he just wanted to get simple things done, and didn't even intend to create a full-fledged programming language.

JavaScript... Brendan Eich wanted to put Scheme scripting in the browser, but because Java was popular, he was told by management to make it look more like Java and also to call it JavaScript. Oh also he had like a two week deadline or something.

Yea, I dunno... good hard questions :)

I don't really post anti-Javascript commentary, but I have an intense hatred for it because I disliked it and I had to use it for 10 years because it was the only client side language for the web. It is a bit irrational at this point, but I'm not a fan of imperative languages these days, and combining that with past experience makes me really not like it.

I don't particularly care about php because I have basically zero experience with it.

You're biased, they suck. Doesn't make you a loser for working with them, we all do it. But it's just pulling the wool to think that their obvious utility somehow counter-acts their (also obvious) lousy design. My personal advice is don't identify with your tools. Mark of a mature craftsman is knowing the nature of your tools and getting the job done anyway.
“PHP paid my bills” is the same argument as “NHS saved my life” in the UK