Hacker News Reader

> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML.

When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing.

Today, Coffeescript is a remnant of old frontends that nobody has bothered transpiling into Javascript yet, but back in the day it was a promising new development.

> it was an advancement

That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.

Coffeescript came with spreads and destructuring, and added string interpolation, just to name a few things. It also added classes and inheritance, the ?. operator, .

I suppose you could argue those are just synctatic sugar because they compiled down to ES5, in the same way you can argue that any programming language is synctatic sugar over raw machine code.

I may disagree (_heavily_) with the Pythonesque syntax Coffeescript chose, but it took a while for ES6 to be widely available, and Coffeescript made ES6 features work on most browsers without any additional effort. It's easy to take today's Javascript for granted, but the web was very different back in 2009.

In addition to this: ruby-like classes and "sane"/expected handling of this using fat arrow functions. I've worked with a few developers at the time that considered themselves pure backend/rails developers and didn't (bother to) grok the details around the way this worked in JS.

I distinctly remember lots of var that = this; in JS code back then, which wasn't required anymore when using CoffeScript.

Class sanity was the major reason I chose it for a project in the early 2010s. I was interacting with the classes in OpenLayers and being able to do so without all those footguns was very welcome.

javascript was never designed to be used like a classic OOP language, that's why jquery won, it was functional which meant it didn't fight you the way the other libraries did.

javascript is first and foremost functional no matter how hard MS and others have tried to hammer it into a more typical OOP language.

I'm not sure what you mean. You can put functions into objects, you have "this" when you call the functions, you even have prototypes. It seems to me like the language is designed to let you do OOP just fine, and the only thing that was awkward was organizing the code where you define all those functions and the constructor. So they added a sugar keyword for it.

right, it's awkward, so don't do that, be functional instead.

jquery vs mootools/scriptaculous/etc.

jquery won for a reason, it's just flat out a better experience in terms of code specifically because it uses a functional approach in its api rather than an OOP approach.

> right, it's awkward, so don't do that, be functional instead.

I feel like you're just saying that because you like functional code. I'm sure that when they've added syntax to make certain functional things easier to type, you didn't respond "it's awkward, so don't do that, write it in an entirely different way instead".

Regardless of what is "better", which tends to differ based on situation, there was no need for the awkwardness. Classes weren't bad to use, it was just that declaring them had some pointless busywork.

implicit in my responses is an assumption that you've worked extensively with jquery so you understand the syntax and how it's functional.

If you don't the only response I can have is to go learn it.

This isn't about functional being better, it's about functional being more fluid to use in javascript.

I've used it a moderate amount. But I'm not here to argue about how fluid functional code is, I'm here say that OOP works fine, and making slight changes to improve that experience is good. We don't need to actively discourage OOP by making it awkward.

Especially when you're not dealing with the DOM, sometimes objects work quite well.

The original awkwardness does not show that javascript "was never designed to be used like a classic OOP language".

Nor is it why jquery worked well.

And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP".

> And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP".

this is disingenuous and I'm ending it here. MS spent years trying, and initially failing, to get javascript to work in a more traditionally OOP way.

describing that as slight is something else.

I started off with "I'm not sure what you mean" and you have given zero examples.

I'm not being disingenuous. Other people can't read your mind. Other people aren't experts on the same things you are.

And specifically, I described the class keyword as slight.

Don't be an asshole by accusing people of things they're not doing.

do not speak with authority if you do not know.

do not try and downplay something just because you want it to be true.

"I'm not sure what you mean." isn't speaking with authority.

And I stand by saying there was no need for the awkwardness with classes.

What did I downplay? You still haven't said what they did. I can't be downplaying a thing that isn't part of the conversation.

saying the words "I'm not sure what you mean" doesn't give you a pass to speak with authority about the effort involved in getting the class keyword into javascript when you're ignorant of the history.

----

edit: But also, let me point something out.

what you're calling "awkwardness with classes" is incorrect. they were _functions_ that you could attach state to, some of that state could, itself, be callable functions. That's a large part of _why_ javascript has prototype inheritance.

javascript was primarily functional with some features that allowed a bit of OOP sprinkled in.

I'm not interested in the effort to get that particular change in, I'm asking for you to elaborate in this broad effort you're implying beyond that. If I misread you, and you're not implying something broader and that's the only change they fought for, then yes it is quite small.

To be extra direct there: I didn't say the effort was small, I said that change was small. You can have a big effort for a small change. So you definitely misread me there.

But when you talked about "hammering" it into a more OOP language, I thought you were talking about big changes or many changes.

> what you're calling "awkwardness with classes" is incorrect. they were _functions_ that you could attach state to, some of that state could, itself, be callable functions. That's a large part of _why_ javascript has prototype inheritance.

Does it matter if the "class" itself is a function or an object or something else entirely? It makes thingies that have the prototype applied and you can do .foo on.

But classes you make with the keyword are still functions, aren't they? So what's the big betrayal?

stop trying to weasel-word your way to being right, people fought MS and largely ignored them for years. There was a time when you didn't use the class keyword because it was non-portable because MS wasn't collaborating with anyone.

But more importantly, this all started because I pointed out that javascript is a functional language.

This remains true, which is why writing functional code in javascript ends up with a better experience, and that's a large part of why jquery won.

Brendan Eich, the creator of javascript, was heavily influenced by. Scheme is functional so I'm not saying anything outlandish here.

https://softwareengineering.stackexchange.com/questions/1941...

> I've never used Self myself, but I believe that JavaScript's extensive use of prototypes came from Self.

> As for Scheme's influence, you need look no further than JS's first-class functions and lexical scoping (okay, so JS doesn't implement full lexical scoping in the way Scheme does, it implements function-level scoping, but still, it's close).

Asking what you meant is not weasel wording, goddamn.

(Some of the distinctions you're making still make no sense to me because you think they're so evident you won't elaborate, but at this point it's definitely not worth the effort.)

I would argue that fat arrow functions really are nothing more than synctactic sugar. I don't know of any place where (x,y) => {} couldn't be replaced by function(x,y){}. I prefer arrow functions myself, but it's a very minor additions.

Fixing _this_ is a good point, though.

When you didn't know how this worked, CoffeScript's fat arrow functions became a life saver when attaching callbacks from inside some object you were writing that probably had an init() method to set up the handlers:

  // Doesn't work, <this> is <window>.
  document.body.addEventListener("click", function(event) { this.handleClick(event) })

vs.

  document.body.addEventListener "click", (event) => @handleClick(event)

You only needed a .bind(this) in the plain JS version, but it felt like surprisingly few people knew this back then.

Interestingly enough, the current version of CoffeeScript compiles this code into a ES6 arrow function itself, but I think back then they used bind() in the transpiled JS.

Fat arrow functions were adopted from coffee script.

IIRC it also had some different scoping rules so you didn’t need to sprinkle `bind` all over.

>by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't

This is why I created StrictYAML. A lot of the pain of changing YAML goes away if you strictly type it with a schema but you keep the readability.

Counterintuitively that also includes most indentation errors - it's much easier to zero in on the problem if the error was "expecting status code or content on line 334, got response", for instance.

That makes a lot of sense, though I'd guess that a lot of yaml-ops types wouldn't want to have to write schemas.

StrictYAML is a great initiative. On the other side of the fence I also love JSON5, for opposite reasons - it's essentially "UnstrictJSON".

JSON5 has achieved a reasonably high level of adoption (though I think it's plateaued & I don't see it ever becoming the standard way people do JSON). Would be great to at least see StrictYAML hit a similar level of adoption though - the network effect is so hard to overcome.

> why anyone ever used Coffeescript

CoffeeScript was the front runner for 'Compile to JavaScript' technology. It was the first time we could write some sane frontend code.

Of course things like TypeScript came along and now we cannot unsee what we have already seen.

TOML's sections remind me of the directory part of a filename and keys files.

For the content that belongs in a typical configuration file this or the INI style roots are probably the most human approachable formats. For anything more complex maybe a database (such as SQLite?) is preferable past application bootstrap?

Reading yaml has the enjoyment of reading a love letter where else json has the deterimental feeling of a solicitor email. For writing, yaml is like putting out the draft, you only focus on the meaning not care for else or the form, but for json it is like finishing up your thesis with hard defined structure.