3 ms·

I bet you really like spaghetti.

dusted 6y ago
I like clean, elegant, expressive code, just like everyone else. I don't particularly care for the attitude that because something can be used to write horribly unmaintainable messes, it must necessarily be bad and have few practical applications. No, if you get horrid unmaintainable messes it's because you're either inexperienced or a bad programmer, you may be able to hide that in layers and layers of corporate Java that adheres to every guideline, but the second anyone tries to touch it, you'll be found out anyway. I'm going to take a wild guess that you're also imbued with a similarly low opinion of PHP based on that (insightful if somewhat one-sided and flawed) article that guy wrote. In my opinion, the flexibility and elegance you can get out of exploiting, not abusing or misusing, the dynamic nature of JS, is the main appeal of the language, it's really damn fast to get stuff done, and even done in a nice and safe way, provided you have some idea what you're doing. There are terrible things that you can do in JS, and those are terrible even in the context of JS, but, what is a terrible thing to do in one language may be just fine(tm) in another, so trying to force some Java or C++ ideas onto any other language is just not a good way of going about things. Every language must be considered on its own. What is reasonable to do when writing machine code may not be reasonable in assembler, and what is reasonable in assembler may not be reasonable in C and up you go.
- yarinr 6y ago
  > const o = {}; o.prop = "something"; // oh, actually, o.prop = 5; Care to share some examples / use cases where using these language characteristics can result in better, more expressive, more readable code? (Not saying there aren't. I've been wondering about it myself and am genuinely curious) Thanks!
  - stephenr 6y ago
    I mean... let’s keep in mind we’re talking about a language and community that uses the keyword “const” to define mutable objects. Logic went out the window a long fucking time ago.
    - dragonwriter 6y ago
      > we’re talking about a language and community that uses the keyword “const” to define mutable objects. Nope they use const to define immutable references, the same way that val/var define mutable references. If you don't understand the difference between mutability of a reference and mutability of the value it refers to, JavaScript is far from the only language you’ll have a problem with.
      - stephenr 6y ago
        I understand the difference. The problem is that you can completely change the shape of the object that’s “const”, so it’s hardly fucking constant is it.
        dragonwriter 6y ago
        > I understand the difference No, you clearly don't. > The problem is that you can completely change the shape of the object that’s “const” “const” is not a feature of objects, but of the reference to a value (which may or may not be an object). You can't change the reference at all (unlike a var/let references), hence it is constant. Object immutability is orthogonal to reference immutability and is attained by Object.freeze().
        alcover 6y ago
        dragonwriter is right. In C for ex. const int* p means the value pointed at can't change, but int* const p means you can't reaffect p
- stephenr 6y ago
  TIL relying on a bunch of boilerplate “typeof o.prop” checks is “clean, elegant, expressive code”, while knowing implicitly that o.prop is always an integer is not?
  - dragonwriter 6y ago
    > TIL relying on a bunch of boilerplate “typeof o.prop” checks is “clean, elegant, expressive code”, while knowing implicitly that o.prop is always an integer is not? Clean and elegant are certainly debatable, but, yes, code that is explicit in its preconditions (whether through explicit runtime checks or explicit static declarations or other mechanism) is pretty clearly more expressive than code that relies on the developer “knowing implicitly” the same information.
    - stephenr 6y ago
      When I said knowing implicitly I was referring to for example, declaring that class `Foo` has an integer property `prop`, and function `bar` only accepts an instance of `Foo` as argument `obj`, thus `obj.prop` is always an integer. The developer doesn’t need to add typeof checks on the argument, on the property, etc. The above comments point to (a) not using classes or declared properties at all, and regardless JavaScript has no support for automatic type checks on properties or function arguments.

I like clean, elegant, expressive code, just like everyone else. I don't particularly care for the attitude that because something can be used to write horribly unmaintainable messes, it must necessarily be bad and have few practical applications. No, if you get horrid unmaintainable messes it's because you're either inexperienced or a bad programmer, you may be able to hide that in layers and layers of corporate Java that adheres to every guideline, but the second anyone tries to touch it, you'll be found out anyway. I'm going to take a wild guess that you're also imbued with a similarly low opinion of PHP based on that (insightful if somewhat one-sided and flawed) article that guy wrote. In my opinion, the flexibility and elegance you can get out of exploiting, not abusing or misusing, the dynamic nature of JS, is the main appeal of the language, it's really damn fast to get stuff done, and even done in a nice and safe way, provided you have some idea what you're doing. There are terrible things that you can do in JS, and those are terrible even in the context of JS, but, what is a terrible thing to do in one language may be just fine(tm) in another, so trying to force some Java or C++ ideas onto any other language is just not a good way of going about things. Every language must be considered on its own. What is reasonable to do when writing machine code may not be reasonable in assembler, and what is reasonable in assembler may not be reasonable in C and up you go.

yarinr 6y ago
> const o = {}; o.prop = "something"; // oh, actually, o.prop = 5; Care to share some examples / use cases where using these language characteristics can result in better, more expressive, more readable code? (Not saying there aren't. I've been wondering about it myself and am genuinely curious) Thanks!
- stephenr 6y ago
  I mean... let’s keep in mind we’re talking about a language and community that uses the keyword “const” to define mutable objects. Logic went out the window a long fucking time ago.
  - dragonwriter 6y ago
    > we’re talking about a language and community that uses the keyword “const” to define mutable objects. Nope they use const to define immutable references, the same way that val/var define mutable references. If you don't understand the difference between mutability of a reference and mutability of the value it refers to, JavaScript is far from the only language you’ll have a problem with.
    - stephenr 6y ago
      I understand the difference. The problem is that you can completely change the shape of the object that’s “const”, so it’s hardly fucking constant is it.
      - dragonwriter 6y ago
        > I understand the difference No, you clearly don't. > The problem is that you can completely change the shape of the object that’s “const” “const” is not a feature of objects, but of the reference to a value (which may or may not be an object). You can't change the reference at all (unlike a var/let references), hence it is constant. Object immutability is orthogonal to reference immutability and is attained by Object.freeze().
      - alcover 6y ago
        dragonwriter is right. In C for ex. const int* p means the value pointed at can't change, but int* const p means you can't reaffect p
stephenr 6y ago
TIL relying on a bunch of boilerplate “typeof o.prop” checks is “clean, elegant, expressive code”, while knowing implicitly that o.prop is always an integer is not?
- dragonwriter 6y ago
  > TIL relying on a bunch of boilerplate “typeof o.prop” checks is “clean, elegant, expressive code”, while knowing implicitly that o.prop is always an integer is not? Clean and elegant are certainly debatable, but, yes, code that is explicit in its preconditions (whether through explicit runtime checks or explicit static declarations or other mechanism) is pretty clearly more expressive than code that relies on the developer “knowing implicitly” the same information.
  - stephenr 6y ago
    When I said knowing implicitly I was referring to for example, declaring that class `Foo` has an integer property `prop`, and function `bar` only accepts an instance of `Foo` as argument `obj`, thus `obj.prop` is always an integer. The developer doesn’t need to add typeof checks on the argument, on the property, etc. The above comments point to (a) not using classes or declared properties at all, and regardless JavaScript has no support for automatic type checks on properties or function arguments.