5 ms·

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).

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.

SonOfLilit 6y ago
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 :-)
- chrisweekly 6y ago
  If you really care so much, why not simply embrace TypeScript?
  - Kinrany 6y ago
    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.
    - jt2190 6y ago
      > 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-files/introduction.html https://www.typescriptlang.org/docs/handbook/declaration-fil...
      - Kinrany 6y ago
        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.)
    - derangedHorse 6y ago
      The typescript compiler can be a bit slow at times as well which dramatically lowers the developer experience when using typescript
  - SonOfLilit 6y ago
    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.
- z3t4 6y ago
  Strong/weak and dynamic/static. JS is dynamic, but variables will always have a type, which is memory safe - which makes types strong.
  - Ndymium 6y ago
    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.
    - wolco 6y ago
      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..
      - SonOfLilit 6y ago
        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.
        deleted 6y ago
        [deleted]
        z3t4 6y ago
        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.
- kmill 6y ago
  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.)
  - SonOfLilit 6y ago
    Huh, what do you know. Still, this is unforgivable in my book: [] + {} == "[object Object]" {} + [] == 0
    - kmill 6y ago
      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(+[]);
      - SonOfLilit 6y ago
        I didn't realise about the second one. Thanks!
      - skykooler 6y ago
        Thanks, I never realized that the second one was parsed as a code block rather than an object!
tasuki 6y ago
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.
- tarsinge 6y ago
  The point is that a language can evolve so much they are not even the same language. I prefer ES2016 to Python for example.
  - fastball 6y ago
    Eh, the weak typing intrinsic in JS still makes Python win out between those two.
    - wolco 6y ago
      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
      - MauranKilom 6y ago
        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.
    - tarsinge 6y ago
      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.
heavenlyblue 6y ago
“PHP paid my bills” is the same argument as “NHS saved my life” in the UK
carapace 6y ago
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.
bcrosby95 6y ago
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.

SonOfLilit 6y ago

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 :-)

chrisweekly 6y ago
If you really care so much, why not simply embrace TypeScript?
- Kinrany 6y ago
  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.
  - jt2190 6y ago
    > 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-files/introduction.html https://www.typescriptlang.org/docs/handbook/declaration-fil...
    - Kinrany 6y ago
      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.)
  - derangedHorse 6y ago
    The typescript compiler can be a bit slow at times as well which dramatically lowers the developer experience when using typescript
- SonOfLilit 6y ago
  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.
z3t4 6y ago
Strong/weak and dynamic/static. JS is dynamic, but variables will always have a type, which is memory safe - which makes types strong.
- Ndymium 6y ago
  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.
  - wolco 6y ago
    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..
    - SonOfLilit 6y ago
      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.
      - deleted 6y ago
        [deleted]
      - z3t4 6y ago
        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.
kmill 6y ago
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.)
- SonOfLilit 6y ago
  Huh, what do you know. Still, this is unforgivable in my book: [] + {} == "[object Object]" {} + [] == 0
  - kmill 6y ago
    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(+[]);
    - SonOfLilit 6y ago
      I didn't realise about the second one. Thanks!
    - skykooler 6y ago
      Thanks, I never realized that the second one was parsed as a code block rather than an object!

tasuki 6y ago

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.

tarsinge 6y ago
The point is that a language can evolve so much they are not even the same language. I prefer ES2016 to Python for example.
- fastball 6y ago
  Eh, the weak typing intrinsic in JS still makes Python win out between those two.
  - wolco 6y ago
    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
    - MauranKilom 6y ago
      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.
  - tarsinge 6y ago
    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.

heavenlyblue 6y ago

“PHP paid my bills” is the same argument as “NHS saved my life” in the UK

carapace 6y ago

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.

bcrosby95 6y ago

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.