999 karma · joined July 16, 2012
It has an appealing set of features, and a seemingly-promising future. One might metaphorically say that the device "sounds sweet".
Thus, the title is a play on words.
Or the author meant to write superfluous.
If you don't have either, then you'll probably end up re-implementing one or the other eventually anyway.
If you want that in JavaScript, you can have it; promises were created on the assumption that asynchronous logic is desirable as a matter of course.
That doesn't preclude other aspects of quality of course. But it does influence how they're approached. A heavily abstracted system that hurts performance is unacceptable, but there are other ways to achieve the same ends.
You might find this article interesting... http://samsaffron.com/archive/2011/03/30/How+I+learned+to+st...
Asynchronous execution isn't an unfortunate design choice to be papered over; better to make it as easy as possible to learn and work with.
> But here's the concept:
> Programmers seem to have stopped reading books. [...]
The goal from day 1 has been to foster a community that would be empowered to create something of lasting value. That doesn't preclude hand-holding... But it doesn't demand it either; whether or not that happens is up to the folks who make up the site, the folks asking and the folks answering.
In the 7+ years since that was written, many thousands of people have donated their time and knowledge to help their peers, both in the immediate sense of writing an answer to address a specific question, and in the sense of leaving artifacts for future readers with the same question.
But of course there's room for improvement. And if you're willing to step up, you can be a part of that improvement. Go find someone who lacks knowledge and gently guide them; encourage your friends to do likewise. The platform is there, empowering you to create the environment you wish to see... If you aren't doing it, that's on you.
If you wanna wage a campaign against this, then you might as well start with the term "unicorn", which is itself subtly mocking; after all, unicorns aren't rare: they are non-existent. The root term implies the same thing that bothers you about the derived -corpse: these valuations are irrational, and a reckoning will be had.
...And now the 'net is making the world small again and an awful lot of folks are realizing that they don't like being part of their society any more than their ancestors did. We got our scarlet letters and our witch hunts and our untouchables and our religious wars and it's all ruining our ability to laugh at the ancients because more and more we look at ourselves and see the same failings.
Freedom to live and work in one small area, or to do otherwise. Freedom to go where you want, when you want.
Is there a cost to that? Hell yeah. But for an awful lot of people, it's worth it.
Too many time to count, I've met someone whose car was their only significant possession, the only thing of any real value they owned outright. They'd lost or sold everything else, but the car they wouldn't part with - it wasn't just transportation, but their home, and for a few dollars in gas it was heat and a lifeline to those who could help in an emergency. I guess in NYC, they'd have been sleeping on the subway somewhere... But instead, they had freedom.
Indeed, most of the arguments made are the same that were used as justifications for DSLs a while back:
> The problem with this kind of freedom is that every bit of power you insist on have when writing in the language corresponds to power you must give up at other points of the process — when ‘consuming’ what you have written.
A good DSL lets you create, for example, business rules that are easy to maintain (for those familiar with the business) but don't prevent me from swapping out the implementation that drives them for something better on down the line.
Hopefully no one exposes him to the ocean of old Outlook clients with crufty Word-based HTML renderers out there; he might die of a heart attack. Mentioning Pine/Alpine would be cruel as well.
Google found: http://www.themodestman.com/how-to-hem-dress-pants/ which says pretty much this but makes it sound complicated somehow.
Might be a problem if you can't reach your feet, I guess.
...And more importantly, the implications for the folks buying and installing these products are a hell of a lot closer to those pertaining to VW's ECUs.
If you're gonna argue for a level playing field, it probably helps to start with teams that are playing the same game, or at least one that's reasonably similar. Right now, you're arguing that Google's bobsled team would unfairly compete with VW's baseball players, ignoring that Google fields a cricket team as well...
Over the past year or so, we've altered the mechanics of close voting to encourage fast closure and discourage gradual accumulation of votes. If you're interested in the details, see: http://meta.stackexchange.com/questions/250223/age-close-vot...
Separation of presentation and content, man. Learn it.
You're right about Disqus though. Fortunately, there's Meta SO for real discussion.
It remains the standard to which I hold all programming books I read. The author's enthusiasm and patient but never patronizing style drew me in, and the book's recognition that language and methodology are not inseparable changed how I viewed programming; the observation that design and implementation a dance rather than a handshake changed how I looked at software.
A classic worth reading even if you never intend to use Forth.
Do this a few times and you maybe start to get wise to the idea that raving about your new hangout isn't very smart if you want to continue going there on a regular basis.
For decades of trying, this is the best we've managed to do for cross-platform UIs. It ain't great, but it soundly beats the alternatives.
I haven't written any assembly in many years now, but for a good while it was still pretty important to maintain that knowledge - you never knew when you'd need to use it for a routine here or there that was just too slow or cumbersome in C. And still, long, long after that, debugging C required at least some assembly knowledge if you wanted to get home in time for supper.
And this is where I see folks getting into the weeds with stuff like Angular: if you completely forget (or never learn) the underlying platform, it's entirely too easy to get stuck when it comes to debugging or even performance issues: you know it shouldn't take 3 seconds to render the page, but if you can't look under the abstraction then you're hosed.
So eventually, you're stuck learning the whole stack anyway. And now it's not a sunk cost: you have to forget what lies beneath every time you sit down...
In other words, you're asking folks to not just learn something new, but also forget something they've perhaps invested a great deal of time and energy into already.
Sometimes, that tradeoff is worthwhile. But it's never free.
There's an automated process that confirms the request via email and starts a timer that, if not cancelled, removes the account. For accounts with a non-trivial number of posts we hold them for manual confirmation just to prevent unfortunate accidents (there's no undo - more on that next) but all it involves is an affirmative response from an email associated with the account.
The longer answer is... This is one of those very early design decisions that, in hindsight, was probably sub-optimal. Ideally, account deletion would amount to nothing more than flipping a bit on a database record, at least in the short term - if someone regretted their decision a day later, no harm done; just flip it back. But things are not ideal, and deleting an account actually purges rather a lot of information that can't easily be restored - so given that a non-trivial number of users do change their minds (especially those with a long history of activity that will be lost), it's worth everyone's time to make double-sure before hitting the big red button.
We've slowly been improving the process over the past few years, but it's still no where near ideal from anyone's perspective. I could go into more detail, but... Can sum it up with, "We're now only wasting ridiculous amounts of time on this instead of utterly insane amounts of time".
Blog posts are always fun, and certainly brighten up what is otherwise a dreadfully boring task, but... not really the best way to get action if that's all you're after.
> Programmers seem to have stopped reading books. The market for books on programming topics is miniscule compared to the number of working programmers.