36 ms·

I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. R

I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?

clockwerx 10y ago
Oh I really do miss optional type hinting in. Theres a lot of raise ArgumentError.new unless foo.kind_of? Bar Going on in my code these days.
qwertyuiop924 10y ago
Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system. There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.
- codedokode 10y ago
  I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class. And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
  - qwertyuiop924 10y ago
    That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
    - jstimpfle 10y ago
      In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).
      - qwertyuiop924 10y ago
        It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword. JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say: var Person = function(){}; Person.prototype = {name:"bill", addr:"foo"}; var charlie = new Person(); charlie.name = "charlie"; charlie.addr = "baz"; var NewPerson = function(){}; NewPerson.prototype = charlie; var bill = new NewPerson(); This code is totally valid. bill's prototype chain looks like this: bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype Welcome to prototypical inheritance.
        deathanatos 10y ago
        > A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`. Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them. Consider your example, translated: class Person: name = 'bill' addr = 'foo' class Charlie(Person): name = 'charlie' addr = 'baz' class NewPerson(Charlie): pass bill = NewPerson()
  - josteink 10y ago
    > In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module. You should try "use strict" sometime. If you write sloppy JS, you'll find out in no time. Javascript will still have most of its warts, mind you. But some of the most obvious errors should at least be catchable.
    - codedokode 10y ago
      It doesn't help to find a misspelled property (and doesn't prevent you from dividing by zero too). You need a static typing system like TypeScript to detect such kind of bugs.
- spdionis 10y ago
  And npm doesn't even have a lock file!
vatotemking 10y ago
> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"? I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all https://www.reddit.com/r/lolphp/top/?sort=top&t=all
- codedokode 10y ago
  Try console.log([] * {}) and be surprised. At least in PHP you cannot multiply array by object. Type casting in PHP gets fixed gradually: https://wiki.php.net/rfc/invalid_strings_in_arithmetic https://wiki.php.net/rfc/invalid_strings_in_arithmetic .
  - oliverkyss 10y ago
    Why would that be surprising? NaN as a result definitely means that you cannot multiply array by object in JS either. JavaScript uses IEEE 754 special values, not exceptions on arithmetic errors (eg 1/0 returns Infinity instead of throwing). If you bother to learn the language, it doesn't surprise you.
    - happyslobro 10y ago
      The problems start when you notice that your untyped key-value store has a bunch of NaNs where you were expecting a number. At this point, all you can do is pray that those numbers weren't very important, in the grand scheme of things.
      - oliverkyss 10y ago
        So when you do calculations with important numbers, you just push the results to the store without checking them and hope for the best? NaNs can happen in any language with floats, it's just that some languages also use exceptions in some situations.

clockwerx 10y ago

Oh I really do miss optional type hinting in. Theres a lot of raise ArgumentError.new unless foo.kind_of? Bar Going on in my code these days.

qwertyuiop924 10y ago

Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system. There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.

codedokode 10y ago
I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class. And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
- qwertyuiop924 10y ago
  That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
  - jstimpfle 10y ago
    In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).
    - qwertyuiop924 10y ago
      It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword. JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say: var Person = function(){}; Person.prototype = {name:"bill", addr:"foo"}; var charlie = new Person(); charlie.name = "charlie"; charlie.addr = "baz"; var NewPerson = function(){}; NewPerson.prototype = charlie; var bill = new NewPerson(); This code is totally valid. bill's prototype chain looks like this: bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype Welcome to prototypical inheritance.
      - deathanatos 10y ago
        > A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`. Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them. Consider your example, translated: class Person: name = 'bill' addr = 'foo' class Charlie(Person): name = 'charlie' addr = 'baz' class NewPerson(Charlie): pass bill = NewPerson()
- josteink 10y ago
  > In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module. You should try "use strict" sometime. If you write sloppy JS, you'll find out in no time. Javascript will still have most of its warts, mind you. But some of the most obvious errors should at least be catchable.
  - codedokode 10y ago
    It doesn't help to find a misspelled property (and doesn't prevent you from dividing by zero too). You need a static typing system like TypeScript to detect such kind of bugs.
spdionis 10y ago
And npm doesn't even have a lock file!

vatotemking 10y ago

> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"? I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all https://www.reddit.com/r/lolphp/top/?sort=top&t=all

codedokode 10y ago
Try console.log([] * {}) and be surprised. At least in PHP you cannot multiply array by object. Type casting in PHP gets fixed gradually: https://wiki.php.net/rfc/invalid_strings_in_arithmetic https://wiki.php.net/rfc/invalid_strings_in_arithmetic .
- oliverkyss 10y ago
  Why would that be surprising? NaN as a result definitely means that you cannot multiply array by object in JS either. JavaScript uses IEEE 754 special values, not exceptions on arithmetic errors (eg 1/0 returns Infinity instead of throwing). If you bother to learn the language, it doesn't surprise you.
  - happyslobro 10y ago
    The problems start when you notice that your untyped key-value store has a bunch of NaNs where you were expecting a number. At this point, all you can do is pray that those numbers weren't very important, in the grand scheme of things.
    - oliverkyss 10y ago
      So when you do calculations with important numbers, you just push the results to the store without checking them and hope for the best? NaNs can happen in any language with floats, it's just that some languages also use exceptions in some situations.