5 ms·

How is computer programming different today than 20 years ago?

45 points by reallydontask 7y ago

guggle 7y ago
Hilarious post. "Since we have much faster CPUs now, numerical calculations are done in Python which is much slower than Fortran. So numerical calculations basically take the same amount of time as they did 20 years ago." I get the humor but it's also not true... if using numpy, you're essentially running C code where speed matters.
- rbanffy 7y ago
  > if using numpy, you're essentially running C code where speed matters. Two notes: 1- If using numpy properly 2- Various numpy modules use FORTRAN 77, so it's not always C code.
  - guggle 7y ago
    You're right. Still fast code though ?
    - rbanffy 7y ago
      Probably faster than C ;-)
finnjohnsen2 7y ago
Compilers are better. Once I spent two days finding a semi colon error (in Deplhi)
- rafaelvasco 7y ago
  Yeah, mostly that. That and safety and parallelism features in order to comply to today's software and user needs;
FreekNortier 7y ago
stackoverflow.com makes a big difference.
- ngcc_hk 7y ago
  Yes. Make the difference.
majewsky 7y ago
> 3 billion devices run Java. That number hasn’t changed in the last 10 years though. He hasn't heard of Android apparently.
- reallydontask 7y ago
  I think when you install Java in windows it says that java runs on 3 billion devices and has been saying so for the past 10 years or so
- jsjohnst 7y ago
  Android is arguably not “Java”, but rather “Java like”.
withinboredom 7y ago
I'd add another... 20 years ago: your boss says I want X. You wouldn't ever tell them it was impossible or hard work. You'd hack it together and bend the hardware to your will. Today: your boss says I want X. You spend a lot of time arguing if it's a necessary business function, spend a few months designing it, and then implement it in such a way that makes Fizz-Buzz Enterprise Edition look simple. To put it shortly, incredible creative hacks are looked down on, while "elegant" solutions are a must. At least that is what it looks like from my experiences.
- moretai 7y ago
  What's better?
kunglao 7y ago
Haha. Would love to hear also about: 1. We're releases and code changes as common as it is now or once you finished writing it's more less that except for bug fixes? 2. Nowadays a lot of non-technical people are also involved in the development process like product owners, project managers, scrum masters, engineering managers, etc. Was this so then? 3. Size of the teams? Was it generally smaller or larger compared to today?
- jsjohnst 7y ago
  From my personal experience: 1. Releases were less often, usually in the range of a couple releases (4-6) a year. We had dedicated bug fixing time for two weeks before a release with extensive QA. 2. Mostly the same, except scrum master (or equivalent) was usually the project manager. 3. Generally about the same size teams, but teams had total ownership over what they built. Code bases and services were never split among multiple teams.
poulsbohemian 7y ago
There was a lot more independence and respect 20 years ago. Now, much like the highlight in the article, there's a great deal of emphasis put on "team" and often cargo-cult style practices (IE: if we do these things, we'll be a high-performing team). Even as software has spread into more corners of our life and the number of developers has expanded, I don't see the professional respect that developers had 20 years ago. The infrastructure tools / documentation / pre-built parts have made our lives easier, but the number of tools and technologies we need to understand on a typical project has also exploded. We used to need to develop deep expertise - say on database management - that today gets abstracted away to AWS (this is not to say that those skills aren't still valuable and useful, just different...). There's a lot more technology-choice-by-fad today. We didn't have as many choices or the instant access and bombardment of opinions back in the day, so decisions were slower, IE: we didn't just switch out tools on a whim because it "sounded like a good idea"
downerending 7y ago
I've had a habit throughout my career of printing out small chunks of code (several pages) that were algorithmically difficult or contained significant bugs. I'd take them to the park or coffee shop and just study them, pencil check them, or just think deeply about them. For me, this is a super-power, compared to flipping around on our massive monitors. The more recent grads I work with mock me for this. Things have indeed changed.
- poulsbohemian 7y ago
  > just think deeply about them. This is one of the reasons I am making a career transition this year. I don't have the time to think about good solutions, just cheap, quickly thrown together ones. It's exhausting and doesn't feel like good work. Deep thinking is an under appreciated opportunity in our culture.
- lesservehicle 7y ago
  This is a trick that I’ve been doing since the early 2000s that I find works nearly 100% of the time. Getting the distance between yourself and the screen is liberating and being in a different setting can help spark new ideas, even if by accident.
karmakaze 7y ago
The biggest difference is probably package managers. It was common for a codebase to be 100% written in-house. Often fundamental algorithms were written per-project. I never minded the detail work, but the way we have it now is much more productive. Standard libraries give you so much to start with and package managers and github libraries make up even more. The most important ability now is critical decision making at a higher level. The other thing I really appreciate is garbage collection and static typing with type inference. We get this with good edit-compile-run ergonomics. We even have good interoperability of languages in run- or compile-time VMs. What we have today I didn't even dream of back in the day.

45 points by reallydontask 7y ago

Hilarious post. "Since we have much faster CPUs now, numerical calculations are done in Python which is much slower than Fortran. So numerical calculations basically take the same amount of time as they did 20 years ago." I get the humor but it's also not true... if using numpy, you're essentially running C code where speed matters.

rbanffy 7y ago
> if using numpy, you're essentially running C code where speed matters. Two notes: 1- If using numpy properly 2- Various numpy modules use FORTRAN 77, so it's not always C code.
- guggle 7y ago
  You're right. Still fast code though ?
  - rbanffy 7y ago
    Probably faster than C ;-)

finnjohnsen2 7y ago

Compilers are better. Once I spent two days finding a semi colon error (in Deplhi)

rafaelvasco 7y ago
Yeah, mostly that. That and safety and parallelism features in order to comply to today's software and user needs;

FreekNortier 7y ago

stackoverflow.com makes a big difference.

ngcc_hk 7y ago
Yes. Make the difference.

majewsky 7y ago

> 3 billion devices run Java. That number hasn’t changed in the last 10 years though. He hasn't heard of Android apparently.

reallydontask 7y ago
I think when you install Java in windows it says that java runs on 3 billion devices and has been saying so for the past 10 years or so
jsjohnst 7y ago
Android is arguably not “Java”, but rather “Java like”.

withinboredom 7y ago

I'd add another... 20 years ago: your boss says I want X. You wouldn't ever tell them it was impossible or hard work. You'd hack it together and bend the hardware to your will. Today: your boss says I want X. You spend a lot of time arguing if it's a necessary business function, spend a few months designing it, and then implement it in such a way that makes Fizz-Buzz Enterprise Edition look simple. To put it shortly, incredible creative hacks are looked down on, while "elegant" solutions are a must. At least that is what it looks like from my experiences.

moretai 7y ago
What's better?

kunglao 7y ago

Haha. Would love to hear also about: 1. We're releases and code changes as common as it is now or once you finished writing it's more less that except for bug fixes? 2. Nowadays a lot of non-technical people are also involved in the development process like product owners, project managers, scrum masters, engineering managers, etc. Was this so then? 3. Size of the teams? Was it generally smaller or larger compared to today?

jsjohnst 7y ago
From my personal experience: 1. Releases were less often, usually in the range of a couple releases (4-6) a year. We had dedicated bug fixing time for two weeks before a release with extensive QA. 2. Mostly the same, except scrum master (or equivalent) was usually the project manager. 3. Generally about the same size teams, but teams had total ownership over what they built. Code bases and services were never split among multiple teams.

poulsbohemian 7y ago

There was a lot more independence and respect 20 years ago. Now, much like the highlight in the article, there's a great deal of emphasis put on "team" and often cargo-cult style practices (IE: if we do these things, we'll be a high-performing team). Even as software has spread into more corners of our life and the number of developers has expanded, I don't see the professional respect that developers had 20 years ago. The infrastructure tools / documentation / pre-built parts have made our lives easier, but the number of tools and technologies we need to understand on a typical project has also exploded. We used to need to develop deep expertise - say on database management - that today gets abstracted away to AWS (this is not to say that those skills aren't still valuable and useful, just different...). There's a lot more technology-choice-by-fad today. We didn't have as many choices or the instant access and bombardment of opinions back in the day, so decisions were slower, IE: we didn't just switch out tools on a whim because it "sounded like a good idea"

downerending 7y ago

I've had a habit throughout my career of printing out small chunks of code (several pages) that were algorithmically difficult or contained significant bugs. I'd take them to the park or coffee shop and just study them, pencil check them, or just think deeply about them. For me, this is a super-power, compared to flipping around on our massive monitors. The more recent grads I work with mock me for this. Things have indeed changed.

poulsbohemian 7y ago
> just think deeply about them. This is one of the reasons I am making a career transition this year. I don't have the time to think about good solutions, just cheap, quickly thrown together ones. It's exhausting and doesn't feel like good work. Deep thinking is an under appreciated opportunity in our culture.
lesservehicle 7y ago
This is a trick that I’ve been doing since the early 2000s that I find works nearly 100% of the time. Getting the distance between yourself and the screen is liberating and being in a different setting can help spark new ideas, even if by accident.

karmakaze 7y ago

The biggest difference is probably package managers. It was common for a codebase to be 100% written in-house. Often fundamental algorithms were written per-project. I never minded the detail work, but the way we have it now is much more productive. Standard libraries give you so much to start with and package managers and github libraries make up even more. The most important ability now is critical decision making at a higher level. The other thing I really appreciate is garbage collection and static typing with type inference. We get this with good edit-compile-run ergonomics. We even have good interoperability of languages in run- or compile-time VMs. What we have today I didn't even dream of back in the day.