Hacker Timesnew | past | comments | ask | show | jobs | submit | soaringmonchi's commentslogin

I couldn't agree more. I am doing a lot of nodejs development these days and it's usually a pain to verify that the code works the way it should. Writing a quick bunch of unit tests is very superior to loading your code in an interactive console and manually fiddling with inputs / outputs. These unit tests often break at the first refactoring and we rewrite them at that point. I'm a bit surprised that people argue that unit tests facilitate "aggressive" refactorings. Aggressive refactoring to me means architecture changes and unit tests almost never survive those. Integration testing is what ensures proper functioning in those situations for me.


Have already sent an email, but no reply, yet. I am super excited about this and would love to test it out. Docker ID: threerabbits


Sorry, but this sounds a bit short-sighted. While nobody should be sentenced to suffer severe pain for the rest of his life, just because your body isn't as capable as it used to be doesn't necessarily mean that you want to end your life. Often there will be people that you will leave behind and you certainly don't want to explain them that it's your decision to do just that.

On top of that, this is also dangerous from a social perspective where people could get a feeling that they are supposed to go once there is nothing they can contribute to society anymore.

We should rather focus on allowing making "regular" dying more dignified rather than promoting euthanasia.


I do think it should be a personal decision. Also, euthanasia is certainly not preventable (I think of a certain gentleman that took the bottom of the river approach).

I have seen a few old people live beyond their time and wait for death though. It is quite harsh and undignified. "I am just so tired and I want to go."


The only thing that annoys me with this (and many other popular posts in our field recently) is that the author talks about "magic". I believe this started with the advent of Rails where some things seemed "magical" at first due to Ruby's meta-programming features. Many writers and speakers have adopted it since.

However, there is nothing occult about software development and we shouldn't use "magic" as an excuse for not understanding or describing things thoroughly. Just imagine your doctor explaining you a surgery in these terms.

Otherwise, a very good and refreshing read.


I think its important, especially in posts like this that are targeted to beginners, that certain information be left out and not clarified (essentially making the masked parts "magic"). Otherwise, the reader is overwhelmed with information and really can't grasp the overall picture. I think this article succeeds on its goal of shedding some light on how the node event loop works at a high level, and its straightforward about its goals in that regard.

Imagine trying to explain to someone how math operations work in js, you wouldn't really want to explain how numbers are represented in the computer until you get to something that necessitates that understanding - like bit operations.

So, I'd just say it depends on your goals, if your goal is to explain precisely how every detail of something works, then yes I'd agree with you, there's no excuse for magic. But if you want to explain how a general concept works I'm fine with loads of "magic" holes you can fill in for yourself later.


The use of the term "magic" to describe spooky abstractions or odd behavior caused by referential opacity far, far predates Rails.


To be fair, the productivity gains that using Rails gets you is pretty magical.


Right, I agree with this. There's nothing magic about any of this -- ultimately it's all just software, hardware and physics.

To describe something as magic in a serious context is toxic. We're not sleight of hand performers, we're engineers. It's more helpful to state something like, "this library is complicated and the internals are beyond the scope of this post". A pointer to documentation and source code on libuv would be even better. In face, this series of articles on libuv are a great start for those who are interested: https://nikhilm.github.io/uvbook/introduction.html


If all occurrences of "this is [magic]" are treated as "this is [sufficiently complicated internally and beyond the scope of this post]," then what's the difference? The former makes for a point that's expressed more succinctly and eloquently at little real loss.


I went and looked in the Oxford English Dictionary and did not find your definition of magic there. http://www.oed.com/search?searchType=dictionary&q=magic&_sea...


Definition 2a seems related: "Producing [...] remarkable results, like those attributed to magic [...]; effecting or permitting change, success, etc., as if by magic."

Also the 'magic box'.

The Urban Dictionary (the place where I look for colloquialisms) has this definition: "with or through complexity either spurios to the contemproary context or to long to be reasonable or desired of explanation". [1]

1: http://www.urbandictionary.com/define.php?term=magic&defid=9...


This is what we like to call a "figure of speech". It means that we do not believe to be literally magic, but are using hyperbole to describe a situation where something happens and it's not immediately apparent why.


It's older than Rails, I remember the interpreter being described as magic in SICP. It was mentioned as such several times over the course of the book, and was somewhat thematic.

Until, of course, the final chapter (or was it the chapter before the final chapter), where you learned that magic isn't real.


Definitely my preferred approach. Note that you need to run 6to5 with the -e flag to try this.


I think you mean the --experimental flag. -e is for evaluate.


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

Search: