[chrisjsmith]

Whilst I appreciate the effort that people put into these things, I really don't like this sudden obsession of adding another layer of abstraction over everything. Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.

[rkalla]

I was just about to type something along those lines, but then I thought for a second and realized that a lot of these insane JavaScript projects coming out may never become the next <whatever is cool with the kids>, but the technical achievements made in each of these projects inspires the NEXT group of hackers that might be working on <next awesome thing>.

So I think there is a lot of value to these hack projects even if Facebook isn't going to roll it out in it's next update.

Engineering is like art... we all look at what each other is doing, get inspired and move the entire discipline forward.

What I love about that is you never know when you are going to inspire something, not with a project, but maybe just with a particularly nice snippet of code or data model that is SO intuitive, they feel compelled to work it into something.

Equally cool, you never know when YOU will get inspired. I know I've honestly read class definitions or parser implementations that were so intuitive and elegant that I have developed a compulsion to go code something that uses the same technique because it is so pretty.

I don't know why, but I think that is what makes this line of work so great. It's technical AND artistic... and it doesn't always make practical sense ;)

[raganwald]

All problems in computer science can be solved by another level of indirection—Butler Lampson

...except for the problem of too many layers of indirection.—David Wheeler

http://en.wikipedia.org/wiki/Abstraction_layer

[ulisesroche]

It's not exactly sudden, you know. We're not using punch-cards anymore, for example. I've haven't done much debugging, since Haml/Sass/Coffeescript write better HTML/CSS/Javascript than I do, but you can always look at the compiled code if you need to.

[clintjhill]

Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.

Thank you for that. I've been looking for this concise a statement to make in debates I've had in the past.

[naz]

Agreed, we should write everything in binary

[chrisjsmith]

rephrase - un-necessary abstration.

[ehsanu1]

Then the issue becomes determining what abstractions are "necessary". The line is very blurry, and there is plenty of room for a range of reasonable positions on this matter.

While there may be some objective truth about which abstractions really are a net benefit to use, there's no easy way for us to determine it (besides deciding between binary and assembly). So arguing about it is mostly pointless. Leave each to their own preference.

[chrisjsmith]

IMHO, abstractions become apparent if needed. Abstractions should never be thought of first.

Read GEB - covers it indirectly ( http://en.wikipedia.org/wiki/G%C3%B6del%2C_Escher%2C_Bach )

[technomancy]

"Abstractions are like tacos; I don't mind a little leaking so long as they hold together till I'm done." - https://twitter.com/MarkusQ/status/86136160652496896

[uriel]

> Whilst I appreciate the effort that people put into these things, I really don't like this sudden obsession of adding another layer of abstraction over everything.

This is one of the reasons I found Google's Go so refreshing, it actually removed layers of abstraction bypassing even libc while providing a clean and portable interface to write my programs. Instead of making the stack of abstractions even higher as for example Java does, they cut it to the root.

[chrisjsmith]

Likewise. It's an excellent piece of rethinking.

Simplicity equals elegance in my mind. If I can fit the whole product/platform in my mind, I am again powerful and not just a victim of the tyranny of over-abstraction and overwhelming APIs (yes I'm looking at you Java and C#).