7 ms·

>>Most of the ugly parts involve interacting with the DOM, and the DOM is NOT JavaScript, and Yeah, like dealing with "this" keyword or type coercion in JS is

>>Most of the ugly parts involve interacting with the DOM, and the DOM is NOT JavaScript, and Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages

api 10y ago
Try C++ template metaprogramming or Java collections before generics.
mschuetz 10y ago
> Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages Try python. Python's handling of this/self makes javasacript look like the most amazing thing ever.
- krzyk 10y ago
  What do you mean? Could you give an example? I always regarded python self to be one of the cleanest ways to show that we have another parameter in a method.
- _ZeD_ 10y ago
  are you joking, right? in javascript you cannot ever KNOW what this refers to (is the instance of a new Thing()? is null? is "window"? is something set with .bind()? is just "the left thing before the dot before the function"? is something else?
  - Sohcahtoa82 10y ago
    Does "this" work differently in JS as it does from Python or even C++? Is it not always the object that owns the function currently being executed? If the "this" is implicit, then how can you possibly know where the variable comes from?
- tastyham 10y ago
  Eh. Python and JavaScript are very similar at the language level. They each have warts and are more expressive in certain areas, but at a high level they have the same semantics and the exact same advantages and disadvantages.
- scriptkiddy 10y ago
  Could you please explain? It's always very clear in Python what `self` refers to. Self is always an instance of the parent object of a method. Some classes can also have static class methods that can be called from the class itself instead of one of it's instances. Maybe that is where your confusion is arising?
  - StavrosK 10y ago
    Class methods don't accept a "self" argument, though. In those cases, you call it cls.
    - scriptkiddy 10y ago
      I'm aware. The `self` vs `cls` thing is convention. You can call either argument whatever you want.
  - mschuetz 10y ago
    It's not that it's confusing, rather it's unnecesarrely cumbersome because it's explicit and because you have to put it as an argument. Looking at the "most used words" [1] list of python, self is the #1 used word by far, occuring three times as often as the second most common word, "if". At this point, it's just a filler that bloats code and makes it less readable in many cases # so much text for such a little task def length(self): return math.sqrt(self.x*self.x + self.y*self.y + self.z*self.z) # better, but not quite there yet def length(self): return math.sqrt(self.x**2 + self.y**2 + self.z**2) # this would be perfect, but it's not allowed by python def length(): return math.sqrt(x*x + y*y + z*z) To be fair, javascript also forces you to explicitly specify "this" so there is no difference in that regard. What I find worse than that is that you have to specify self in the parameter list. Calling a function with 2 parameters but having to declare 3 doesn't make sense. The usuall reasoning is that "explit is always better than implicit" but I do not agree. We could take this philosophy all the way to explicitly defining all the global variables that may be used by the function in the parameter list, maybe even all the packages that this function is going to use. We don't do that for a good reason. [1] https://anvaka.github.io/common-words/#?lang=py https://anvaka.github.io/common-words/#?lang=py
cdelsolar 10y ago
use ES6, Babel, and ===
- sAbakumoff 10y ago
  ES6's arrow function might help to avoid "this" problem in some scenarios, but it does make it any better. Type coercion is a lot more than == vs ===.
BinaryIdiot 10y ago
> Yeah, like dealing with "this" keyword This can get a little confusing until you understand how context works. Then it makes sense but you know what? You don't always need to use this. In fact you can build entire applications in different ways without ever using this. And no writing without using this doesn't make your code ugly or unmanageable. There are just many ways to get the same or similar things done in JavaScript. > type coercion in JS Type coercion is ugly in any programming language. It's best to avoid it, even in JavaScript (which you can do, btw).
- giomasce 10y ago
  The problem with type coercion is when it happens without you noticing it. You cannot "avoid" it...
  - BinaryIdiot 10y ago
    Sure but this problem is inherent to any dynamic language. I find other issues far worse than simple type coercion. What about calling a function? Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. You can avoid type coercion if you understand how the language works (aka strict equality in JavaScript) but this isn't something only in JavaScript land either.
    - dozzie 10y ago
      > Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. Python will throw an error. Ruby will throw an error. Tcl will throw an error. Erlang will throw an error. I believe most of the Lisps will throw an error. What was it about "most dynamic languages"?
      - BinaryIdiot 10y ago
        > What was it about "most dynamic languages"? I should have changed my text to not say "regardless of definition" because you can do that in Python, Ruby, PHP, JavaScript, etc. Python and Ruby support it through (star)args or default parameters JavaScript supports it regardless PHP supports it regardless We can argue semantics or the fact that some of those types of errors can be caught with some subset of dynamic languages but I don't think that's useful. My only point was when comparing a dynamic language with a static language I find variable function parameters to be one of the bigger issues over type coercion. But that's just, like, my opinion.
z3t4 10y ago
this is only used with the new keyword. You can however program JS avoiding both new, prototype and this, by using "factory functions". Or avoid OOP structures altogether using a more functional paradigm.
- sAbakumoff 10y ago
  >>this is only used with the new keyword This so not true. "this" is much wider paradigm in JS.
  - z3t4 10y ago
    If the new keyword is not used, "this" will point to the global scope. You do not however have to use the new keyword when creating the built in JS objects. {} is new Object(); If you find "this" confusing you can and should avoid using it. JavaScript has many bad parts that some programmers love to use because it makes their code "elegant". It is however possible to write simple and easy to understand code by only using the good parts.
    - sAbakumoff 10y ago
      >>If the new keyword is not used, "this" will point to the global scope This is entirely incorrect information, consider a simple example: function f(){console.log(this.a);} var o={a:"c"} f.call(o) there is no "new" keyword involved, and "this" is not pointing to the global scope and there is a huge amount of other samples which I can show, but I won't. I don't have any problems with understanding "this" in JS. I just firmly believe that this is superb ugly stuff.
      - z3t4 10y ago
        That is indeed ugly stuff. Thankfully you never have to use f.call(o)
        sAbakumoff 10y ago
        I bet you never developed anything realistic with JS! The close neighbor of "call" called "apply" is a widely used tool.

api 10y ago

Try C++ template metaprogramming or Java collections before generics.

mschuetz 10y ago

> Yeah, like dealing with "this" keyword or type coercion in JS is not the ugliest thing ever in the history of Programming languages Try python. Python's handling of this/self makes javasacript look like the most amazing thing ever.

krzyk 10y ago
What do you mean? Could you give an example? I always regarded python self to be one of the cleanest ways to show that we have another parameter in a method.
_ZeD_ 10y ago
are you joking, right? in javascript you cannot ever KNOW what this refers to (is the instance of a new Thing()? is null? is "window"? is something set with .bind()? is just "the left thing before the dot before the function"? is something else?
- Sohcahtoa82 10y ago
  Does "this" work differently in JS as it does from Python or even C++? Is it not always the object that owns the function currently being executed? If the "this" is implicit, then how can you possibly know where the variable comes from?
tastyham 10y ago
Eh. Python and JavaScript are very similar at the language level. They each have warts and are more expressive in certain areas, but at a high level they have the same semantics and the exact same advantages and disadvantages.
scriptkiddy 10y ago
Could you please explain? It's always very clear in Python what `self` refers to. Self is always an instance of the parent object of a method. Some classes can also have static class methods that can be called from the class itself instead of one of it's instances. Maybe that is where your confusion is arising?
- StavrosK 10y ago
  Class methods don't accept a "self" argument, though. In those cases, you call it cls.
  - scriptkiddy 10y ago
    I'm aware. The `self` vs `cls` thing is convention. You can call either argument whatever you want.
- mschuetz 10y ago
  It's not that it's confusing, rather it's unnecesarrely cumbersome because it's explicit and because you have to put it as an argument. Looking at the "most used words" [1] list of python, self is the #1 used word by far, occuring three times as often as the second most common word, "if". At this point, it's just a filler that bloats code and makes it less readable in many cases # so much text for such a little task def length(self): return math.sqrt(self.x*self.x + self.y*self.y + self.z*self.z) # better, but not quite there yet def length(self): return math.sqrt(self.x**2 + self.y**2 + self.z**2) # this would be perfect, but it's not allowed by python def length(): return math.sqrt(x*x + y*y + z*z) To be fair, javascript also forces you to explicitly specify "this" so there is no difference in that regard. What I find worse than that is that you have to specify self in the parameter list. Calling a function with 2 parameters but having to declare 3 doesn't make sense. The usuall reasoning is that "explit is always better than implicit" but I do not agree. We could take this philosophy all the way to explicitly defining all the global variables that may be used by the function in the parameter list, maybe even all the packages that this function is going to use. We don't do that for a good reason. [1] https://anvaka.github.io/common-words/#?lang=py https://anvaka.github.io/common-words/#?lang=py

cdelsolar 10y ago

use ES6, Babel, and ===

sAbakumoff 10y ago
ES6's arrow function might help to avoid "this" problem in some scenarios, but it does make it any better. Type coercion is a lot more than == vs ===.

BinaryIdiot 10y ago

> Yeah, like dealing with "this" keyword This can get a little confusing until you understand how context works. Then it makes sense but you know what? You don't always need to use this. In fact you can build entire applications in different ways without ever using this. And no writing without using this doesn't make your code ugly or unmanageable. There are just many ways to get the same or similar things done in JavaScript. > type coercion in JS Type coercion is ugly in any programming language. It's best to avoid it, even in JavaScript (which you can do, btw).

giomasce 10y ago
The problem with type coercion is when it happens without you noticing it. You cannot "avoid" it...
- BinaryIdiot 10y ago
  Sure but this problem is inherent to any dynamic language. I find other issues far worse than simple type coercion. What about calling a function? Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. You can avoid type coercion if you understand how the language works (aka strict equality in JavaScript) but this isn't something only in JavaScript land either.
  - dozzie 10y ago
    > Most dynamic languages will let you pass in any number of parameters regardless of its definition and you may not even notice. Python will throw an error. Ruby will throw an error. Tcl will throw an error. Erlang will throw an error. I believe most of the Lisps will throw an error. What was it about "most dynamic languages"?
    - BinaryIdiot 10y ago
      > What was it about "most dynamic languages"? I should have changed my text to not say "regardless of definition" because you can do that in Python, Ruby, PHP, JavaScript, etc. Python and Ruby support it through (star)args or default parameters JavaScript supports it regardless PHP supports it regardless We can argue semantics or the fact that some of those types of errors can be caught with some subset of dynamic languages but I don't think that's useful. My only point was when comparing a dynamic language with a static language I find variable function parameters to be one of the bigger issues over type coercion. But that's just, like, my opinion.

z3t4 10y ago

this is only used with the new keyword. You can however program JS avoiding both new, prototype and this, by using "factory functions". Or avoid OOP structures altogether using a more functional paradigm.

sAbakumoff 10y ago
>>this is only used with the new keyword This so not true. "this" is much wider paradigm in JS.
- z3t4 10y ago
  If the new keyword is not used, "this" will point to the global scope. You do not however have to use the new keyword when creating the built in JS objects. {} is new Object(); If you find "this" confusing you can and should avoid using it. JavaScript has many bad parts that some programmers love to use because it makes their code "elegant". It is however possible to write simple and easy to understand code by only using the good parts.
  - sAbakumoff 10y ago
    >>If the new keyword is not used, "this" will point to the global scope This is entirely incorrect information, consider a simple example: function f(){console.log(this.a);} var o={a:"c"} f.call(o) there is no "new" keyword involved, and "this" is not pointing to the global scope and there is a huge amount of other samples which I can show, but I won't. I don't have any problems with understanding "this" in JS. I just firmly believe that this is superb ugly stuff.
    - z3t4 10y ago
      That is indeed ugly stuff. Thankfully you never have to use f.call(o)
      - sAbakumoff 10y ago
        I bet you never developed anything realistic with JS! The close neighbor of "call" called "apply" is a widely used tool.