Hacker News Reader

Comment by gmac | Hacker News Reader

The author has 3 main gripes: backticks to drop back to JS, the 'class' keyword, and the fat ('this'-preserving) arrow.

But these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow.

At which point you're left with, from where I'm sitting, a less noisy, more concise, more enjoyable way to program the web browser than plain JS.

View on HN

these are all features you can blithely ignore: don't use backticks, and stick to native JS prototypes and the thin arrow.

Without taking a personal stance on these features, I suggest that “You can ignore Language Feature X” is often a weak argument. If you feel X is harmful, not only must you ignore it, but you must consider all of the other developers, maintainers, and so forth who interact with your code.

You personally may not use X, but what about your team mates?

Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X?

If you really think X is a terrible idea, it’s in your best interests to discourage its existence, not just ignore it :-)

There are tools that can cover this.

You personally may not use X, but what about your team mates?

Team leads should tell team members to use automated tools for coding standards. This takes care of most of this.

Your team (of 1+) may not use X, but do you ever have to debug modules or plugins written with X?

The Node.js community has a way of dealing with non evented-friendly code. Programming as a whole would probably benefit from more things like this.

There are tools that can cover this.

I'm curious, which tools can you use for this?

There are tons of these.

Pycharm and related IDEs have Lint style tools for Javascript, for example. If your needs aren't met by existing tools, you can also roll your own. Many Lint-style programs have ways of coding your own checks.

I think we’re making the same point, namely that if “X” is harmful, simply ignoring X is insufficient, you must take active measures to avoid being “contaminated” by X.

We can debate how much effort is involved firewalling your code from X. It obviously varies depending on what precisely X is and how popular X is, but you clearly have to do more than simply “ignore” it.

We can debate how much effort is involved firewalling your code from X.

Well, this thread has brought me to the awareness that there is always going to be some effort in this regard. Whichever programming language is used makes no difference.

FWIW, I agree about tools. I’ve certainly experimented with integrating Lint-like tools into the build process. Every team ought to have coding standards they enforce, whether mechanically, by eye, or a combination of both.

Frankly his main gripe is that JS = FP, CoffeeScript = OO.

The 3 gripes you point out are mostly a consequence of Coffee choosing to do OO instead of FP & then needing hooks into JS's world to achieve this end. From the article - "CoffeeScript sees the world through OO’s eyes. When I see JavaScript, I find beauty in it’s ability to be a dynamically typed Functional programming language."

His example is known by various other names, most commonly http://www.google.com/search?q=lots+of+little+objects

He wants just 2 "objects" ( he more specifically wants unstructured objects, or plain structs ) - sammy the python & tommy the horse. Functional JS gives him just those 2. But OO CoffeeScript gives you 5, or even 6 if you count hasProp.( var Animal, Horse, Snake, sam, tom, __hasProp. )

The more dramatic way to document this behavior is to have say 100 cats & 500 rats, whoe identity is captured in an int. With FP you'll be able to happily get away with just 2 "objects" - 1 cat and 1 rat ! The int indexing will happen via a function call. With OO you will have 600 little objects plus a bunch more for the classes and the hasProp !!

Here's another one I've seen - If you get two programmers to write a paddleball - one in functional JS, and the other using Coffee OO. The Coffee one will lag pretty soon. The Coffee guy will have a Ball object & a Brick object & a Wall object & each gesture will get captured as an object as well. So when the player moves the arrow keys to move the paddle, each move's x,y coordinates will become a gesture object & then gestures are passed to the ball & the wall to determine collisions....soon you'll have 1000s of gestures & the pgm will slow down unpredictably as the gc kicks in. The functional JS guy won't create a single gesture object, he'll simply call some collision detection function directly with the x & y, so you'll see much better performance.

Ofcourse the coffee OO code will look a lot prettier than the FP one littered with curlies & function calls, but like the author says, "JavaScript’s function keyword and curly brackets aren’t ugly to me, they are useful indicators of code smells."

So pick your poison.

I am not a fan of CoffeeScript for my own reasons (it doesn't offer enough for me to drop drop JS), but there is nothing stopping the author from writing his CS like so:

  move = (aDistanceOf) ->
    it = @name or "It"
    alert arguments[1] if arguments[1]
    "#{it} moved #{aDistanceOf} meters"
  
  snake =
     name: "Sammy"
  horse =
     name: "Tommy"
  
  move.call snake, 5, "Slitering"
  move.call horse, 45, "Galloping"

But really, this is just JS wearing some new clothes. The string interpolation is nice, but apart from that, you really gain nothing over the JS version.

>But really, this is just JS wearing some new clothes.

And that's not a bad thing.

If you want FP and encapsulation, you can write something like this (functionally equivalent to the OO version, unlike TFA's example)

  move = ->
    alert "#{@move_verb or "Mov"}ing..."
    alert "#{@name or "It"} moved #{@distance or 1} meters"

  snake =
     name: "Sammy"
     distance: 5
     move_verb: "Slither"

  horse =
     name: "Tommy"
     distance: 45
     move_verb: "Gallop"
  
  move.call snake
  move.call horse

Dude. Really ? You've just invented objects, but you'd rather not call it that. You have two attributes ( name & distance ) and you've made an attribute out of the method ( move_verb ?! heh heh ) as well, very clever. You are then calling a function & asking it to sort it all out. If we are going to call this FP, that's a real stretch. What objects buy you is that name,distance & move_verb are common to both snake & horse, so they should be refactored to some base class & then snake & horse should be instances of that class. But then you won't do OO, so you must encapsulate in this roundabout fashion:) I'll grant it does give you FP + encapsulation.

shiffern's example uses the same coding style you use in Clojure. It doesn't feel like stretch to call it FP. Start with a basic data structure (the object in shiffern's example would translate to a map in Clojure) and then operate on it with simple functions.

  (def snake {:name "Sammy" 
              :distance 5 
              :move-verb "Slither"})

  (def horse {:name "Tommy" 
              :distance 45 
              :move-verb "Gallop"})

  (defn move[{:keys [name distance move-verb]}]
    (println (str (or move-verb "Mov") "ing..."))
    (println (or name "It") "moved" (or distance 1) "meters")) 

  (move snake)
  (move horse)

or in scala:

    val snake = Map("name"->"Sammy", "dist"->"5m","move"->" slithers ")
    val horse = Map("name"->"Tommy", "dist"->"45m","move"->" gallops ")
    def move(m: Map[String,String]) = println( m("name") + m("move" ) + m("dist")

     scala> move (snake)
     Sammy slithers 5m
     scala> move (horse)
     Tommy gallops 45m

If FP = OO via dictionaries, then yeah, ok :))

The example given by author is very FP and not OOP, since the move function doesn't modify shared state and the only side-effect is output.

We use CoffeeScript for node.js and browser client code. I think classes more useful for control patterns, like EventEmitter in node.js, and much less for wrapping of data, as done in traditional Java/C++ -style OOP or ORM models.

I'll chip in Erlang (real production-grade code with type-specs, not a short REPL example):

    -module(animal).

    -record(animal{ 
                    name      :: string(),
                    distance  :: integer(),
                    move_verb :: string()
                  }).

    -spec move(animal()) -> ok.
    move(#animal{name=Name, distance=Distance, move_verb=MoveVerb}) -> 
      io:format("~sing... ~s moved ~b meters~n", 
                [default(MoveVerb, "Mov"), default(Name, "It"), default(Distance,1)]).

    -spec default(X::any(), Val::any()) -> any().
    default(undefined,Val) -> Val.
    default(X,        _)   -> X.

    -spec main() -> ok.
    main() ->
      Snake = #animal{name      = "Sammy",
                      distance  = 5, 
                      move_verb = "Slither"},

      Horse = #animal{name      = "Tommy", 
                      distance  = 45, 
                      move_verb = "Gallop"},

      [move(A) || A <- [Snake, Horse]],
      ok.

I'd add also that Javascript proto inheritance is more about composition than type checking, since `instanceof` has its frames problem [1].

As a result, I'm increasingly inclined to do data-structure objects and composable functions, which seems similar to Go's approach.

1 http://perfectionkills.com/instanceof-considered-harmful-or-...

Closures are a poor man's objects.

Objects are a poor man's closures.

Source: http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent. Be sure to click through to the original source thread. It's a fascinating discussion.

Well stated, and I agree 100% it is a sort of blindspot for this article. That said I agree with him on a level that CS does encourage a sort of OO band-aid approach towards functional programming and will definitely impede newcomers from embracing the power that comes with the built-in paradigm. I feel that it should not be in core, but am happy as you are to simply use what works and ignore what doesnt

Synapse creates a non-trivial Class:

https://github.com/bruth/synapse/blob/master/src/synapse.cof...

Here's the documentation, to get some context:

http://bruth.github.com/synapse/docs/#learn

Do you feel that this code would be significantly improved by using JavaScript's bare prototype pattern instead?

^ Thanks for sharing that. I hadn't heard of Synapse but its the most unobtrusive data-binding lib I've seen so far. Very cool indeed!

As far as implementation goes, it still feels "wrong" to me. I love syntactic sugar when possible, but forcing one paradigm on another without measurable benefit (aside from one's comfort/preference) just seems superfluous to me.

I would personally implement it using a modular FP pattern, you get constructors, private methods and all those juicy bits we love about OO, except we are in a completely functional state of mind.

http://answers.oreilly.com/topic/2177-how-to-use-the-module-...

I'd much rather leverage the core strength of a language than try to force it to fit my own habits/patterns. That's just me though :)

Reply on news.ycombinator.com