Hacker News new | past | comments | ask | show | jobs | submit | more apg's comments login

...and yet.

I like good design as much as the next person. But I'm not sure what a good design even is anymore and this article isn't helping. It's throwing a lot of concepts in that "design" bucket. Are we in the midst of a "design bubble"? Are we - as in anyone who can look at a screen and make some kind of cogent value judgment - all designers now? I'm pretty sure I've never chosen to use something (keeping in the realm of software/technology) based on what it looks like over the actual content/functionality it provided. Or is content and functionality in the realm of the designer now?

And I think this statement is highly debatable: "Programmers who prefer to be given detailed requirements and push syntax into a terminal or prefer to isolate themselves from the broader product team will have decreasing value in the world of innovation and product development."

That may or may not be true, time will tell. Too many cooks spoil the soup, you know. And in time, when we are all designers, we just might want someone to competently and efficiently push that syntax into that terminal.

Now I'm off to see if I can find any old issues of Raygun in my basement.


A statement like that which is not part of the official decision are referred to as "dictum". Lower courts review higher court rulings, including dicta, and over time dicta has a way of becoming law.

Scalia is a kind of a Fourth Amendment hardliner when it comes to _the home_, so I'm actually surprised at this result. Fourth Amendment rights in so far as automobiles go have been eroding for years. Note that the concurring opinion wanted to reframe the issue such that there _was_ a reasonable expectation of privacy when it comes to automobiles (which would be a more expansive reading of Fourth Amendment rights).


This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers.

- Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at probably provides some cognitive benefit as well.

- Is there an acronym/name (ala LAMP) for the Node/MongoDB/Redis stack?


1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec...

I am writing a sizable Node app myself. In the end, you just get used to the callback style.


I am assuming that CoffeeScript should be able to add new syntax where the need arises, as the number of CoffeeScript users is probably still pretty low and able to adapt to change.

From what I can tell, CoffeeScript - and the Javascript/Node world - would really benefit from something like F#'s workflow/computation-expression syntax, which will take a fairly straight-forward readable statement and behind the scenes de-sugar the hell out of it into a bunch of closures.

http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation...

EDIT: search for "De-sugared syntax" on this page for an example.


Where is the love for [Deferreds?](http://www.sitepen.com/blog/2010/05/03/robust-promises-with-...)?

Deferreds are * Mostly monadic (creating a deferred is "return", the "then" method is "fmap" and "bind"). * Can be implemented as a library, without a separate compilation step or having to patch the runtime. * Avoids most of the CPS inversion of control madness. You can return and store promises and you can also add callbacks after the fact so code is much more flwxible. (writing sequential async loops is still annoying though)


That's correct -- because we compile to "standard" JavaScript, we're at least somewhat comfortable introducing significant changes (even to the syntax) where desirable. Even if you never get around to updating older pieces of code, all of the compiled JS continues to be fully compatible and interoperable with the newer stuff.


I think the following links are relevant for those of us that know much less than you:

I liked this article that discusses three different solutions to callbacks with different compromises: http://blog.willconant.com/post/7523275566/continuations-in-...

Jeremy discusses #350 and tamejs here: http://news.ycombinator.com/item?id=2777196

Tamejs have a great writeup about the callback spaghetti problem here: http://tamejs.org/


After reading that ticket, I think the solution is going to have to involve more than one keyword. It's curious to see that the objection is to the hideous mass of js that "defer" compiles down into. I kind of thought that was the point of CoffeeScript.


- Daniel is going to write another post detailing this. The answer is that when you combine CoffeeScript and a good async library, you can indeed get rid of that stuff.

- MoNsteR? =)


when you combine CoffeeScript and a good async library, you can indeed get rid of that stuff

My experience has been that you could only do this in few cases. Not an issue that can be worked around elegantly in libraries, you need language support. http://tamejs.org/


LNMR... um... LaMiNaR? RoMuLaN?


I just ran the letters modb-re-nojs-li through my handy word_solver and came up with some candidates: MoRN, NoRM, ModeRN, NiMRod, ReMiNd, MeRLiN, LiMNeR, NiMbLeR


I'd love for non-programming sites like http://diy.stackexchange.com/ to catch on. I feel a little queasy every my most relevant search leads me to Yahoo Answers.


Agreed on the list quality. About the second part of your comment - these works were probably all in the public domain before the great copyright lockdown of 1976 (and subsequent copyright extensions). Unfortunately "content owners" are going to find a way to extend copyright into perpetuity.

It feels like copyright law today is going where Real Property Law was circa 1600. "To content owners and the heirs of thy body in fee simple absolute... "

Edit: Don't expect to see any new works anytime soon.


Wait... Isn't scottgu running/going to run the Azure Platform?

http://www.zdnet.com/blog/microsoft/microsoft-reorg-scott-gu...


We all moved with him. All of IIS and ASP.NET works for ScottGu. In fact, all Angle Brackets are under ScottGu, myself included. Our org chart: http://www.hanselman.com/blog/content/binary/Windows-Live-Wr...


If Linux ever becomes popular on the desktop, it won't be because of Unity, that's for sure. It's a resource hog and it breaks too many established UI conventions. Unity forced me to start using the keyboard for most things.

I'll give XFCE a try. I don't want to leave Ubuntu, because I like the packages and I don't have to read a manifesto sized manual to install it or learn another package system.


UI conventions established by what? Other Linux desktop environments? Established among whom? Old-hat Linux users?

Perhaps that's not who they're targeting.


There is already a contingent of non-power users using Ubuntu. If they alienate those users then who are they really targetting? Shouldn't they worry about user retention in addition to user acquisition?


The problem is that they're targeting non-users so heavily that they're alienating the users they already have. If they never take user input to heart, they're going to wind up with no users.


>Unity forced me to start using the keyboard for most things.

That's not a good thing? I haven't used Unity yet, but might try it out just on that comment alone.


I presume he means it in a bad way, not in a good way like tiling WMs have.


Linux Mint uses Ubuntu's packages, and is still on Gnome. You might want to give it a shot.


I didn't sign up for this either (for same reason as you), and because I suspect some viral marketing at work.

My guess is that it is a version of the Flask-OAuth extension sample app, found here:

http://packages.python.org/Flask-OAuth/

Flask is really great, BTW.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: