I agree with you both.

Technically the source is a blueprint. But this comes down to scale.

Among other things I've worked on banking and corporate management applications. You cannot reason about the codebase at that scale. In these instances it's not possible to have a good outcome without a blueprint.

Using the building metaphor, you can get away with building a bird feeder without a blueprint. You can't get away with building a skyscraper without one. Houses, maybe. Either way, high level blueprints help everyone.

Good points - I think you need some kind of spec or something to reason about. But I don't think it needs to be complete because it is easier to iterate on software than buildings.

Taking the building metaphor, you can't clone a building locally and make changes to it, then ask another builder to review them, suggest some changes then push them out to a test environment before finally putting them into the real world. So for me, the building metaphor only goes so far but there are definitely some useful points in the article.

> you can get away with building a bird feeder without a blueprint

Definitely. But anyway, unless you have built several bird feeders or similar constructions before, your first version will probably be ugly and you'll have to iterate on it (i.e. find the right angles etc.) to make it better. What is of course fun, but costs you time.

> more money makes increasingly smug, but (beyond a certain point) doesn't make your like any more fun

That's not necessarily money's fault, and I'd point out that there are certainly rich people that don't fall into this category.

People who want to pursue happiness need the freedom to do so. Freedom to pursue happiness can be directly correlated with how much money, or wealth, is available to the person.

It's not money's fault that some people don't know how to be truly happy. Money simply affords freedom.

The problem is that with enough freedom and no idea how to be happy in it, you're going to end up in a worse place than if you didn't have the money in the first place.

Money doesn't automatically make people smug and funless (new word?). People make people smug and funless (when they have the freedom and inclination to (unintentionally(?)) do so).

I believe what he meant by money making a person increasingly smug was perhaps that (Western) society holds the expectation that the amount of money a person controls is directly proportional to their overall success or fulfilment in life. This is not always the case but it does create the expectation that a person with money should represent themselves or think of themselves as more successful. This attitude is often interpreted (often correctly) as smugness given that it is rather the opposite of humbly acknowledging the fruits of work or fortune.

Happiness means many things to many people. For some, work itself brings them joy whether or not it results in earning a great deal of money e.g. charitable work. For others it is close relationship with their family, a situation that increased wealth often worsens. Many work their entire lives without recognition or compensation to pursue art, giving up comfortable or successful lives and careers in pursuit of something that, more often than not, they are the only ones who see value in. Religious or aesthetic devotions have perhaps the longest history of eschewing wealth and what most would consider a normal life.

As a society, I think that we are beginning to understand the faults in our current model of a successful life and so we've been seeing more of a trend towards simplifying our lives to make room for these other generators of happiness. We are starting to see that the freedom of money is not the same as the freedom from money.

Good points. I've definitely noticed in my own life a pressure to act like I have money. Personally I think the Diderot effect is partly to blame.

I also agree that we seem to be reaching a better understanding of happiness, thought it's still very fragile and may not last.

I tried it once and had the same experience. I'm really just waiting to meet even a single person who uses it as their daily IDE in a work environment (or even at home - I still haven't seen that.) At that point I'll consider trying it again.

I love the concept. Just not enamoured with the execution.

I use it daily as my IDE. I find that startup time is indeed slow as a dog, but once it is up and running (and it's typically open all of the time, so startup time isn't a real issue) it runs fast enough. At certain times I notice small delays on more complex ops compared to sublime, but nothing significant. The main pro's for Atom, for me, are the way the eco-system is developing, the open-source nature of it, and I'm slightly more happy with the interface. If push came to shove though, I could be happy in either sublime or atom.

The difference in speed in these editors is so small that, if you find it's having a measurable effect on your productivity when coding, you may want to re-look at how you measure productivity or indeed how much time you're churning out code versus other development activities (thinking, planning, testing, talking).

The issue with speed in an editor isn't so much that if your editor is slow that it makes you code faster, but that if your editor pauses, it interrupts your thinking and prevents it becoming very natural and quick to use, like an extension of your mind.

So it's not so much '60 seconds of waiting for the editor in a day', as '2s delay opening that file so my brain switched to thinking about something else, slowing me down for 10+ mins'

I do use it as my daily IDE. It is MUCH slower than Sublime, but I'm trying to ride with it through its bugs and builds. I occasionally use Sublime still, and go through periods of time where I use RubyMine.

I like Atom too, but the startup time between the 2 is night and day. I also get really odd Atom behavior, especially on full screen.

I think startup time is a non-issue given how you can just leave it running in the background.

I use my text editor for a bunch of ad-hoc edits, not just working on projects, but you are right. Speed is less important than buggy behavior (I say this not as a hater, but as someone who is working in Atom all day)

I've only experienced bugs in the early days where you couldn't precisely select a character with the mouse and everything else I've experienced is usually third-party plugins. At least Atom does a great job identifying with plugins are causing issues and collects deprecations and exceptions, and those can be reported by one click. That's why I think Atom brings unique solutions to common problems and, yes, it's a bit slower, but if it becomes popular, maybe it can get a native renderer - who knows. It's too early to predict its fate! So far, given it's infancy age, I think it's done a great job!

My Atom is up and running all the time until there are new app updates, which require restarts.

Have you tried Adobe Brackets? IMO it's a lot faster + you get CSS hints from .psd files. Also you have inline editor, which is super useful.

It's still a lot slower than Sublime, but it's fine for me. (im not primarily a developer tho)

As someone who uses the commandline a lot but isn't exactly a wizard, why does this work?

globbing expression expand to all the files that match.

if a directory has 1.txt, 2.txt, and 3.txt then << rm * >> expands to "rm 1.txt 2.txt 3.txt" and is then executed.

if you have -@, 1.txt, 2.txt, and 3.txt, that expands to << rm -@ 1.txt 2.txt 3.txt >>, and that can't execute.

(if you really wanted to remove your -@ you'd do << rm -- * >> because a double-dash signals the end of command-line options.)

The * is expanded by the shell to a space-delimited list of filenames, but the shell does not adequately escape filenames that can be misinterpreted as arguments to 'rm'.

That's kind of scary — in that case I guess I should avoid creating a file named -rf.

Yes. There was an article linked from HN ages ago (at least a year) that went into mitigation techniques for these issues. As you expect, it basically became fractal, and even then still had bugs. I wish I still had the URL.

I think it may be more scary for code that allows arbitrary execution using command-line arguments. Commands like find or xargs using without defense against this would be a problem. For example, site that does something precious with your uploaded pet pictures.

Defending against this being the use of -- to signal an end of command line arguments.

That is really interesting.

Can someone knowledgeable about the shell expand on this? I don't dare test it on my machine.

Shell session to demonstrate (DO NOT DO IT IN THE DIRECTORY WITH IMPORTANT FILES):

  $ touch important
  $ chmod 400 important
  $ rm *
  override r--------  vbezhenar/staff for important? n
  $ touch -- -rf
  $ ls -l
  total 0
  -rw-r--r--  1 vbezhenar  staff  0 Mar 24 14:35 -rf
  -r--------  1 vbezhenar  staff  0 Mar 24 14:35 important
  $ rm *
  $ ls -l
  total 0
  -rw-r--r--  1 vbezhenar  staff  0 Mar 24 14:35 -rf
  $ rm -- -rf

I've not tested it, but it should expand just like anything else. The effect would broadly be that running "rm *" in the directory would recurse into subfolders without warning.

Re testing. If you follow this link - https://www.digitalocean.com/?refcode=3fc9a5a35c52 - you get $10 free credit (affiliate link I get $25 if you spend that much in future) on DigitalOcean.

You can spin up a droplet and use the online shell tool or ssh in (very easy when you've set up a cert as the droplet can have the cert setup automatically).

Then you can mess about with a droplet as much as you like, virtually speaking. Once you're done then use the control panel to destroy the droplet - it costs a few ¢ a day and if you don't have a droplet in use (which means active or paused; preserving images is cheaper but non-zero) then you don't pay anything.

Basically sign up and have a year of uptime to mess with a full install of various OS with no charge.

Make sure you don't write "rm -rf /*" in the wrong terminal!

> shell does not adequately escape filenames that can be misinterpreted as arguments to 'rm'

That sounds like a bug to me, or at least depending on suboptimal behavior.

More specifically, it is expanded on the shell

Example:

$ echo /*

/bin /boot /dev /etc /home (...)

Another checking in. Guilty as charged.

My main gripe is that because of this stupid model, it pushes a lot of the artists I would listen to away from spotify because it doesn't connect them directly with the revenue stream they should be getting from their true fans. Artists have a hard time surviving without that.

That's because the indie artists aren't looking at the big picture. They would be getting less than they hoped for from the Spotify model, but now you will likely never even hear about them. They're significantly hindering their growth potential and ability to sell concert tickets.

This. I think one issue is that the music industry pegged the price of CDs at around $18. But that was for hit maker CDs sold to mass market listeners.

But there's a separate listener: the explorer. The value of any given track is exceedingly low, but these are the people you depend on for the discovery function. Personally, I prefer that role, but the cost before Spotify was exorbitant unless you were an industry insider.

It doesn't negate the validity of wanting compensation for Spotify plays. Not being on a music service is one way to let your listeners know that the system is fucked and maybe make it change.

The system isn't fucked. Those bands used to NEVER get radio play except from the occasional college radio station that almost nobody listened to. And many of those bands never even made it that big. Now they have listeners all over the world. And if there's a decent market for their music they will get concert ticket sales. Spotify has got to be the best marketing a small band can get, and Spotify pays you for the privilege of marketing for you.

Just because situation is better doesn't mean it can't be further improved. You're considering 'No Spotify' vs 'Spotify' instead of 'Spotify' vs 'A better Spotify'.

If you think on principles, Spotify should in the long term aim for maximum customer satisfaction. This means optimizing the satisfaction per customer instead of per music play, seems to be currently done. By concentrating money on bands each user listens to each of those bands (getting more money) should theoretically improve in quality (and give Spotify more attention), increasing overall user satisfaction. It's a simple reasoning.

Never mind the fact that it's just plain wrong to assume that "those bands NEVER used to get airplay". E.g. there are a number of significant artists on the label Drag City, such as Ty Segall and White, both of which get plenty of radio play, and most of the label's catalogue is not available to stream.

Thank you. I think you're correct. It's not about making our jobs easier - it's about making a better product.

This is really the crux of it. What the heck are people complaining about?

Uh-huh..

Please re-examine the facts. An apology might be nice as well - these are real people after all.

I'm not entirely sure I understand your concern. Hearing the sound doesn't stimulate change, so whether or not we can hear it doesn't seem to matter. The crux is whether or not ultrasound also stimulates microglia production in humans, and whether or not ultrasound is irreparably harmful to the brain.