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.
> 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 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.
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.
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.
No. They exist because they exist. It's a privilege that we get to appreciate them.
We can't seem to lose the notion that the universe was created for us.
When the earth is a barren ball of rock and humanity is long-gone, maybe someone out there will notice the irony in it all.
> I met a traveller from an antique land
Who said: "Two vast and trunkless legs of stone
Stand in the desert. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
'My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!'
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away."
Fair points. I'd just like to bring your attention back to the point that
"What the application does and how it behaves is all that matters."
I'm hard pressed to find a rebuttal to this, if only for the reason that implementation is the goal. No one will ask you to write an application in Python, "and who cares what it does". The very opposite is true - no one cares what it's written in as long as it's the necessary implementation.
From here I would like to address my "point" that tech stack and framework don't matter. I think that we're actually on the same page here save for some sloppy wording on my part. I concede that on a per-project basis framework and stack matter. They quite clearly do, and I agree with you.
I would still like to argue that they don't matter as much as we like to think. To use the example you gave - PHP - depending on your purpose, your required implementation, PHP is still a powerful and useful tool. It's easier to work with than many other technologies for certain kinds of solutions. At the same time, it might be a better idea to write a solution on Rails for any number of reasons. These are specific to each project. At the end of the day though, you can successfully implement any number of solutions on a great many different stacks with no great change to implementation. I can write an application and use either PHP or Rails for the backend, Angular or Backbone for the frontend framework if I have one, and for the end user there will be ultimately no difference. I can run a PostgreSQL or a MongoDB database and they won't be able to tell the difference. If this is the case then, what makes a good application? It is the people writing the code, architecting, and meeting the challenges in ways that work with the chosen frameworks and technology stacks. It seems to me that the end result, then, is reached by people and not by stacks or frameworks.
Sorry for the long reply. No harm if you don't reply to it.
> If you are a developer, you shouldn't rely on Javascript.
I'm sorry but I think he's saying something a little to the left of that. His overarching point about javascript seems to be that it adds complexity to any application - suddenly, page loading indicators and all application states must be handled intelligently by us, developers. His point here is that we already have an issue with developers working on code they don't have the experience, ability or time to understand. SPAs and anything else lead to a serious requirement for developer discipline.
I think some important points were, in my own words:
- Choosing a technology stack doesn't matter
- Choosing a framework doesn't matter
- What the application does and how it behaves is all that matters. Choose any tech stack that will do the job.
- No matter what tech stack you choose, your app will run into issues. It will need maintaining.
Like he says:
> What a good app needs is a team of dedicated people behind it. Good apps are good because talented people cared about them and pooled their skills.
- No amount of abstraction will help. If the abstraction is not understood, it will also hurt.
But please feel free to agree or disagree with me. I'd love to know what you all thought.
The real-time updates he's talking about don't require server-side processing - the google homepage switching immediately to the search view for instance - that processing can be contained within the Javascript application, and state is simply maintained against the server (and then by extension across other instances of the application).
I don't imagine he's suggesting we try the same approach where server-side processing is required.
You shouldn't have to infer anything for a new product being announced. This is shoddy marketing on HPs part and makes me feel like they have something to hide. Definitely not tempted to buy this.
I also agree that we seem to be reaching a better understanding of happiness, thought it's still very fragile and may not last.