Live data from Hacker News

Coffeekup

coffeekup.org

21–30 of 69 posts

Re: Coffeekup

#22
post #4

Cute name and well executed project. But personally, Coffeescript -> Javascript -> HTML sounds way too indirect for my taste. I've seen this patter a few too many times at work now: the new frontend guy loves HAML, and he uses it on a project, and the next couple guys that help maintain it hate it and rewrite everything in straight up HTML.

While I also think this is too indirect for my taste, I'd really like to know why the maintainers hate it. Is it simply because they've never learned HAML and how to debug/maintain it? Or because it truly is a nightmare?

I'm interested because I was thinking about trying it. I've been wondering about the maintenance implications though.

Re: Coffeekup

#23

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.

> 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.

Re: Coffeekup

#24
post #6

Earlier quoted context omitted.

Agreed, we should write everything in binary

rephrase - un-necessary abstration.

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.

Re: Coffeekup

#25

I love CoffeeScript but I don't understand this. HTML / HAML / SHPAML are document languages. CoffeeScript is a programming language. An element that contains another element isn't a function. I don't see any reason to make it one. If you want a templating language, why not use one, rather than having an unnecessary 'space dash greater than' to indicate elements are contained within each other?

a markup language like html is not made of elements that containts other elements, that is just an artifact of the syntax. A tag is more like a "semantic modifier" of its argument/the thing that it contains. How is Lorem ipsum different from (italicize "Lorem ipsum") or italicize :: string -> adorned-graphic-text ?

edit: also, I think having one entire application expressed with only language (coffeescript vs html+css+javascript) is an advantage.

Re: Coffeekup

#26
This may be a bit "get off of my lawn," but I would never use this. I respect the effort put into making it work, but I have no problem writing

Re: Coffeekup

#27
post #4

Cute name and well executed project. But personally, Coffeescript -> Javascript -> HTML sounds way too indirect for my taste. I've seen this patter a few too many times at work now: the new frontend guy loves HAML, and he uses it on a project, and the next couple guys that help maintain it hate it and rewrite everything in straight up HTML.

While I also think this is too indirect for my taste, I'd really like to know why the maintainers hate it. Is it simply because they've never learned HAML and how to debug/maintain it? Or because it truly is a nightmare? I'm interested because I was thinking about trying it. I've been wondering about the maintenance implications though.

The former. The first guy that loves Haml a lot has used it on tons of projects, and knows its quirks, has his own clever tricks, etc.

Someone else comes along and has to set up a Ruby environment and learn a new syntax (for layout and templating) just to add a new element to the page. That gets frustrating really quickly.

Haml and its like are not a nightmare at all. I do appreciate the elegance of the resulting code and this offers a lot of benefits. It's just hard to get everyone to buy into it on a team.

Re: Coffeekup

#28
post #18
post #9

Looks fantastic. With the traction Coffeescript is getting I wouldn't be surprised to see it eventually execute directly inside v8 or similar, bypassing the javascript compilation altogether.

Even if V8 could do this, I'd probably continue to compile my stuff manually (it's so easy) so I wouldn't have to wait for Node / Chrome to update to the newest V8 when there is a new version of the CS compiler that I might need "now". Also it'd be the only way for me to be sure my CS is compiled by the proper compiler version.

I was more thinking coffee script development for nodejs. The browsers on a whole have only just got javascript sorted. I think it's too much to ask for native coffee script support in the browser.

Re: Coffeekup

#29

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.

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 , but the technical achievements made in each of these projects inspires the NEXT group of hackers that might be working on .

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 ;)

Re: Coffeekup

#30

I love CoffeeScript but I don't understand this. HTML / HAML / SHPAML are document languages. CoffeeScript is a programming language. An element that contains another element isn't a function. I don't see any reason to make it one. If you want a templating language, why not use one, rather than having an unnecessary 'space dash greater than' to indicate elements are contained within each other?

These are arbitrary distinctions; as Heidegger said, language is language. As long as they're Turing complete, the only difference between "programming" and "templating" (and "natural") languages are what they're used/optimized for.

Element A containing Element B can be generated by function A taking Element B.

The CoffeScript program converts a set syntax/grammar into JavaScript; but the syntax is just syntax, and its clean, smart design lends itself well for compiling code other than JavaScript, just as JSON is a useful serialization format in other langs. There are benefits in using the same syntax for representing structure, content, and presentation, as long as the concerns are still properly separated.

Post reply on HN