3 ms·
IMO, there was big churn 1990-2015 in people's attitudes about the right way to develop software. This manifested in lots of discussion about languages, platfor
by blt 9y ago
IMO, there was big churn 1990-2015 in people's attitudes about the right way to develop software. This manifested in lots of discussion about languages, platforms, program architectures, hardware, etc.
Since I started reading HN around 2010, I perceive that interest in these topics has decreased. There has been convergence/compromise: some static typing probably good, favor pure functions, C pointers too risky, pay attention to object layout in memory, comfort with phone apps, etc.
I think we are entering a new era when people are going to focus more on advanced applications of technology. Using technology to communicate and store/retrieve data is no longer novel. IMO, HN still has a lot of content from the previous era that feels boring. It's programming content, but not cutting edge.
Edit: not saying there is nothing interesting left to do in systems fields, but the next challenges will be things like formal verification, making massively parallel stuff easy, distributed systems as language primitives, etc.
Edit2: HN also has lots of good content in the latter category, just wish it were a larger percentage of the mix :)
- lukasLansky 9y agoFrom my point of view, we are still firmly in the "software crisis" era. We can build software with limited functionality in a reasonable time, but we are not able to grow it without hitting various kinds of complexity ceilings fairly quickly. Plenty of today's software development is just a succession of painful choices on what to leave behind in just another rewrite. Formal verification is a way to go, but given how people struggle with application of the most elementary usages of types, I am not optimistic.
- blt 9y agoI agree about the software crisis, I guess I think the solution will come from a tool set that is not yet (widely) known.
- solatic 9y agoFormal verification and other protections resulting from strong static typing are less popular probably because of their delayed gratification effects - they're seen as unnecessarily constricting in small projects and their benefits are only seen as projects are grown and maintained over long periods of time, so it's difficult to justify their use early in the project when the decision is initially made. I think that it's easier to justify rigor in traditional engineering projects (i.e. civil engineering) where project delivery dates are necessarily far off in the future - if you need to delay gratification anyway then you might as well adopt a more rigorous process. But in software engineering, where you can start delivering almost immediately, it's more difficult to get project owners and managers to see the value of rigor, especially if the project isn't yet known to have a long lifetime.
- kgwalters 9y agoI think the products were better, at least in the era 2000-2010. These days everything is bloated, slow to react, full of features that no one needs, spying on the user (product) etc. Google peaked around 2004, Windows around 2008 (or earlier).