3 ms·

> Is software development easier today because the gain in programming efficiency is more than the complexity of software that needs to be made? Yes and no. T

by unoti 9y ago

> Is software development easier today because the gain in programming efficiency is more than the complexity of software that needs to be made? Yes and no. The truth is both yes and no, and here is why. If we consider programming along a timeline from yesterday to today, there is unique complexity at both ends of that timeline, and unique simplicity at both ends of that timeline. Today there's extra complexity of an abundance in choice. There's also choice in documentation, which often comes in the form of blog posts which may or may be out of date. And by the time you start to get comfortable using something the new version is probably out, which happened to me with Angular 2 (you knew Angular 4 was released right?). So in many ways programming is more complex today. None of those kinda of problems existed when I was a kid programming on TRS-80 in the late 70's. There wasn't much choice of hardware, software, or much risk of getting overwhelmed by too many learning resources. Basically everything you could know about the hardware and BIOS fit in a single book that Peter Norton wrote. So yes it is more complex today. But there's complexity at the other end, too. We used to spend a lot of time trying to cram data and operations into small amounts of memory. We spent a lot of time inventing our own serialization protocols, writing lower level communication primitives that we don't think about today. The efficiency gain is more than worth the new complexity. A novice programmer today is able to accomplish a great deal more in a month than a novice programmer of way back when. For that matter, power users of today can accomplish way more than a team of programmers could back in the day for many applications. Much of the software I wrote in my first years as a professional developer can be done with spreadsheets. The trick to keeping the efficiency is to not get lost in all the choices and remember to get real work done. Change how you do things too often and you become inefficient. Change not often enough and you become obsolete and inefficient. The real efficiency gains come from working the same problem domain for a while with the same tools. You develop a bag of tricks for dealing with the kinds of problems you run into in that domain and you become very fast. Change too much and you don't. But once every problem you encounter is pretty easy it's probably time to move to a new domain.

water42 9y ago
Angular 2 to Angular 4 is not a good example of getting comfortable using something then the next version coming out. They are the same framework and it is trivial to upgrade Angular 2 to Angular 4. "Updating to 4 is as easy as updating your Angular dependencies to the latest version, and double checking if you want animations. This will work for most use cases." from https://angularjs.blogspot.com/2017/03/angular-400-now-available.html https://angularjs.blogspot.com/2017/03/angular-400-now-avail... Angular 1 to Angular 2/4 is a valid argument though.
- wwweston 9y ago
  Boy, nothing says "This upgrade is a totally backward compatible drop-in replacement for Angular 2" like not only bumping a major version number but actually skipping over the usual increment entirely. (Not that this is really substantial -- it's the history of the project that not only warrants but demands skepticism on the ease of both the upgrade and the utility and learning curve. The tone-deaf nature of the upgrade number is simply frosting on the cake.)
  - unoti 9y ago
    It's true, the nature of the changes from angular 2 to angular 4 are actually smaller and easier to deal with than some of the changes between beta release candidates. But now we're poised to be able to actually build some applications without so much infrastructure change.
  - water42 9y ago
    I agree that skepticism is important, but this is honestly really straightforward if you've been following the development and community discussion. IMO the Angular team made it rather clear why they were skipping the 3rd increment (router package was on 3 and they wanted all of the packages to be at the same increment) and that upgrading version numbers was just semantic versioning and not releasing of a new framework like Angular 1 to 2 was. There were also a few popular articles explaining that no one should be freaking out over the 2 to 4 change and a lot of discussion on HN. So at this point, a few months into Angular 4, it's simply wrong to make the comment that the OP made.
- unoti 9y ago
  You are right, but it does lead to additional complexity in terms of using available documentation and examples. A big part of the efficiencies we have today is the ability to leverage multiple libraries to get things done. I wanted to leverage Firebase, but the examples available were for Angular 1 at the time. Angular 2 support was new enough that I was blazing my own trail. RxJS was undergoing major upheaval as well. Using Redux ideas in Angular 2 (NGRX) is/was in a state of flux. Everything is in a state of change; when you find examples of how to integrate things, typically one or more of the libraries you're working with are at a slightly different level than the things you've already integrated into your codebase from the last set of examples and best practices you integrated. I'm not saying the situation is impossible, just that it introduces additional friction and difficulty compared to working with a more mature less cutting edge toolset.
Vexs 9y ago
As a new programmer with an interest in hardware, this is something I've noticed quite a lot- I was able to learn everything about C/asm as in what functions are available to me to use in a rather short amount of time, but the actual usage of it is quite a lot harder, whereas with a language like python I spend way more time learning how to do something than actually doing it, or if I want to use a database, it took me almost as long to decide which database to use as it did to implement it.

by unoti 9y ago

water42 9y ago

Angular 2 to Angular 4 is not a good example of getting comfortable using something then the next version coming out. They are the same framework and it is trivial to upgrade Angular 2 to Angular 4. "Updating to 4 is as easy as updating your Angular dependencies to the latest version, and double checking if you want animations. This will work for most use cases." from https://angularjs.blogspot.com/2017/03/angular-400-now-available.html https://angularjs.blogspot.com/2017/03/angular-400-now-avail... Angular 1 to Angular 2/4 is a valid argument though.

wwweston 9y ago
Boy, nothing says "This upgrade is a totally backward compatible drop-in replacement for Angular 2" like not only bumping a major version number but actually skipping over the usual increment entirely. (Not that this is really substantial -- it's the history of the project that not only warrants but demands skepticism on the ease of both the upgrade and the utility and learning curve. The tone-deaf nature of the upgrade number is simply frosting on the cake.)
- unoti 9y ago
  It's true, the nature of the changes from angular 2 to angular 4 are actually smaller and easier to deal with than some of the changes between beta release candidates. But now we're poised to be able to actually build some applications without so much infrastructure change.
- water42 9y ago
  I agree that skepticism is important, but this is honestly really straightforward if you've been following the development and community discussion. IMO the Angular team made it rather clear why they were skipping the 3rd increment (router package was on 3 and they wanted all of the packages to be at the same increment) and that upgrading version numbers was just semantic versioning and not releasing of a new framework like Angular 1 to 2 was. There were also a few popular articles explaining that no one should be freaking out over the 2 to 4 change and a lot of discussion on HN. So at this point, a few months into Angular 4, it's simply wrong to make the comment that the OP made.
unoti 9y ago
You are right, but it does lead to additional complexity in terms of using available documentation and examples. A big part of the efficiencies we have today is the ability to leverage multiple libraries to get things done. I wanted to leverage Firebase, but the examples available were for Angular 1 at the time. Angular 2 support was new enough that I was blazing my own trail. RxJS was undergoing major upheaval as well. Using Redux ideas in Angular 2 (NGRX) is/was in a state of flux. Everything is in a state of change; when you find examples of how to integrate things, typically one or more of the libraries you're working with are at a slightly different level than the things you've already integrated into your codebase from the last set of examples and best practices you integrated. I'm not saying the situation is impossible, just that it introduces additional friction and difficulty compared to working with a more mature less cutting edge toolset.

Vexs 9y ago

As a new programmer with an interest in hardware, this is something I've noticed quite a lot- I was able to learn everything about C/asm as in what functions are available to me to use in a rather short amount of time, but the actual usage of it is quite a lot harder, whereas with a language like python I spend way more time learning how to do something than actually doing it, or if I want to use a database, it took me almost as long to decide which database to use as it did to implement it.