There are some advancements of the field, but programming is still not a profession in the sense that you have the rules of profession, stick to them and you cannot do major screwups. I mean the fundamentals are there, but no agreement on the rules of profession, and very few programmers actually follow even those fundamentals.

The most important thing discovered is Test Driven Development (TDD). This is a completely different approach to coding, making sure that you don’t have to keep so many states in mind, you can easily change your code, and giving opportunity to document it in detail.

Another very important thing is Clean Code, which makes the code understandable, which is crucial for continuing development and also to have less errors.

Besides those, there are the patterns, which are some standardized solutions to usual problem types.

The tool support is also much better. IDEs can fix usual problems and do refactors for you. This is partly made possible by advancements in programming languages: they have more expressive power and converge towards being strictly typed, object oriented and functional.

There are advancements in managing the process of software development as well. Agile methodologies deal with the fact that you just cannot get a big chunk of software right at the first try, and Agile Architecture gives a method to design software in a structured manner, and also to make sure that documentation stays up to date.

I believe that we are near to discover and agree on the rules of profession. Kode Konveyor works on exactly that. We started with TDD, Clean Code, and Agile Architecture, and based on them we came up with an implementation pattern which means that a coder can meaningfully contribute to a project immediately (as opposed to the current state of the art where it will take weeks or months), and coding itself is parallellizable. This also hugely reduces the skills needed for coding, as makes design-related activities as part of other professions.

Back in 1998, Agile development wasn’t really a thing back then like it is now. We had heard about Extreme Programming (XP) back then but nobody in Scotland had adopted it. Waterfall was the main development approach. Working in small teams of 3–4 people, you’d be given a target date to release the product and you worked to get it out the door by that date, even if you had to work evenings.

As far as tools went, if you were a Microsoft man you had either Visual C++ 6 or Visual Basic 6 to choose from for Windows development. If you were a Borland man you had Delphi and C++ Builder which I liked a lot. Proper drag and drop with C++.

To develop a Windows application with Visual C++ you had the choice of using raw Win32, MFC or ATL.

MFC was a big bloated elephant that included just about everything. You had to #define WIN32_LEAN_AND_MEAN to tell it to behave itself :)

Win32 - good luck with creating dialogs and windows procedures.

ATL was a nice compromise but I think people preferred VB for forms apps.

Unlike C# and Java applications today, compiling even the smallest application in C++ would take absolutely ages (and, when I’m working with MAME these days it still takes ages) so for rapid application development people were jumping on the VB6 and Delphi wagons. The effects are still felt today - until recently, I was still occasionally dealing with legacy code (badly) written in Basic and Pascal. There’s more of it around than you might think.

20 years ago Intellisense was relatively new. Your autocomplete wasn’t as smart as it is now. The Power Pup was in Microsoft Office and we abused it really badly by making it spout expletives via OLE automation.

Code analysis tools? You had linters for C++ but they didn’t integrate into the IDE, you had to run them from command line. Resharper didn’t exist. FXCop? Nope. Visual Basic only had Option Explicit and Compile as far as quality checks go.

Unit tests weren’t a thing back then so you created test harnesses to exercise your code. (Sometimes I still do create test harnesses.)

As far as learning resources we had the Microsoft Developer Network (MSDN) which was a decent enough reference but no Stack Overflow. Usenet was a thing so we’d post questions on comp.lang.C++ . And, like Stack Overflow these days, we’d end up arguing with some incel who thinks he’s better than you because he knows intricacies of smart pointers and you don’t.

When I started, there were two or maybe three cultures. The Business culture used the largest available IBM hardware and the COBOL language (with a little PL/1 and Fortran, also some Assembler). There was also Univac hardware and a few others. You needed to know that system really well to work in it. To begin with, it used cards. Eventually terminals gave you access to your code that was originally on cards.

The Academic culture used the DEC PDP-11, for which Unix and C language were developed. Most of you are familiar with that. If you worked in this system, that is what you worked in. Because C and the Shell were insanely terse, you could work on this system using a “teletype” terminal rather than cards. I cried. Then trained my team.

There was also a small business culture with some wonky systems I worked on occasionally. One included a 1401 Autocoder emulator. Loaded from cards.

I actually worked on a system where the Unix was the development environment for the IBM COBOL system, and there was a link between them — the mainframe thought the Unix system was a card reader and printer. A Yuge Kluge but it was all ours.

Cards, oh cards. I always had a box of them in my bottom drawer in case we ran out of them. You had to know several types of keypunch machines. Univacs were the best.

And I wrote an assembler in PL/1 in grad school, on cards.

When I worked in a Univac shop, we laughed about IBM Job Control Language (JCL). When I moved to an IBM shop, I had to learn it. Not funny. More cards. Although we had terminals, what you were looking at was cards. (Under the hood, there were cards. I had to load CICS and some other deep operating system stuff, and you loaded JCL etc from a disk.)

We were brave, we conquered, but it was SLOW. Some places you could get one shot a day. You had to concentrate on getting all the diagnostics out in one shot so you could start testing and debugging. One nice thing is that you could get into your one or two languages pretty deeply, read dumps, and optimize your code. You didn’t need to learn two more languages each year. We did have some hairy utilities like SYNCSORT and some hairy disk management systems like VSAM.

Our ability to care. I don’t know if this is a universal issue, but it's been the case at some of the places I've been.

There's been press about buggy software. Apple's iOS 13 update, for example, got attention for being perhaps the buggiest in its history. It seems odd given Apple's history of quality, attention to detail, and simply that iOS has been under development for many years — the process should have been ironed out long before now.

When I was at Corel in 1995, project builds were not allowed to show compiler errors, not even warnings. Despite a project containing over a million lines of code, the build had to start and stop without a single such message. If any appeared, the relevant person(s) were contacted and the matter promptly resolved. Similar attention was paid to build breaks and runtime errors. Management was technical and quality was taken seriously. Software was still being distributed in boxes, which of course pressured vendors to get things right the first time.

One imagines a lack of skill leads to bugs — and it can, and does — but more and more I'm seeing that it's apathy. And apathy starts small:

Me: These symbols should start with an uppercase letter, as per the coding guidelines.

Dev: I guess. But it's just semantics, doesn't affect anything.

Me: Well, it affects readability.

Dev: It still reads the same. Case makes no difference.

Me: Well, that's not really the point. Why bother having standards if —

Dev: I'm not changing it.

The thing about apathy, though, is that it spreads:

Me: The build always shows a lot of compiler warnings.

Dev: Yeah, but the code runs. But if you care, fix it yourself.

Me: But it's not in my area, it's in yours.

Dev: Whatever. I'll file it under 'todo someday.'

And like a disease, apathy can spread to worrisome heights:

Me: This code is really byzantine.

Dev: Yeah, it's been around for years. It accumulates cruft.

Me: Okay, but it's dangerous. It's slowing down our ability to make changes, and changes will probably introduce bugs.

Dev: It's working for now. I'm not gonna touch it.

I guess it's wonderful that with high bandwidth and cloud services, vendors can ship updates anytime, even knowingly release substandard software since it can be patched over the wire later. But what began as a convenience evolved into a habit.

And this is not without harm — on top of making projects late/buggy/overexpensive, it costs us our attention to detail, our focus on quality, our unspoken contract to exchange working goods for customers' money. It erodes trust, invalidates our professionalism, and ultimately cheapens our spirit.

The less we push our projects to be great, the more we deny ourselves to be great.

I started when I was 37, way, way back. My background? Journalism, professional photographer, comedy writer. My college? and unfinished degree in Philosophy and Literature and, no English.

After running away from my country I tried cabinet making in New York. No luck. While working as a photo lab technician, I bought a TI994A home computers by Texas Instrument and promoted by, (Do you know this guy?) Bill Cosby. I started programming video games in BASIC just by following the manual, but they were too slow. So, I called Texas Instrument and they told me that Assembly Language would improve the speed of my games dramatically. The Assembly Language Kit was only 44.95. So I bought it and for the first time in my life I read a book, the Assembly Language manual, from cover to cover, without understanding one single word. The feeling was devastating but I continued working with the computer and eventually started taking courses and reading book after book.

14 years later, I was the director of software development in one of the biggest Insurance Companies. I also worked for Dow Jones, BMW, etc. After I retired, I went back to the school and got my Bachelor’s Degree in Management Information Systems at 68, and my master in science in Software Engineering at 72.

Now, back to your question. At 31, you have everything to be successful. I am 73 now, retired and can’t wait to start something new. I want to be a woodworker and in about six months I will have my shop with all the tools that I think I will need. I am also writing a book about democracy and have other projects in mind.

The Bible says that Noah was about 600 years old when God asked him to build an ark for a curious project. He was a preacher, not a construction worker and, he did it.

By comparison, at 73, am still a baby.

The code hasn’t changed much beyond a bit of melding and syntactic sugar, however the landscape of development in my opinion is remarkably different:

1. Git (and distributed VCS) in widespread usage
2. A deluge of freely available world class compilers and development tools
3. Github & friends
4. Continuous Integration via remote services
5. Distributed compilation on demand
6. Test Driven Development and the use of agile practices in development
7. Docker
8. LLVM (which can enable software plugins written in any language)
9. Editors that rival some IDEs from 20 years ago
10. More widespread JIT compilation
11. Type hinting to offer many static typing benefits to dynamically typed languages
12. Functional reactive UI frameworks

The philosophies haven’t changed, but when you read books like The Mythical Man Month and Code Complete, many of the suggestions made then are now commonly used practices supported through frameworks and innovations in language design and runtime environments.

There are also many games and applications that took months for a team to build in the 90s that can be done by a single programmer in a matter of days or weeks.

Containerization technologies such as Docker enable application logic to be self contained in an image targeting a single platform, offering its functionality via rest APIs and / or shared files.

It depends on the programmer. Bad programmers have been with us throughout history. They ignore the better techniques because they are hard to understand at first. The best programmers were 60 years ago who developed structured programming (ALGOL), type systems (Pascal), object-oriented programming (Simula, Smalltalk, Eiffel), and functional programming (McCarthy, LISP).

Unfortunately, much of that has got lost in the quagmire. C adopted structured programming syntax from ALGOL (via BCPL), but greatly compromised on SP with the wrong compromises (devolving to FORTRAN and assembler, the very things we were trying to get away from).

Those people did not understand type systems and hated and disparaged Pascal and all its successors.

C++ attempted to lift C’s game by including stronger types based around classes, but C++ compromised typing and OO in the wrong ways. Programmers miss the real points of SP and OO. Not only that but C and C++ have given programmers an arrogant attitude that understanding the computer is more important than understanding computation. This is the cart before the horse.

Functional programming so far has not had a big compromise (although C++ is working on that).

We need to get back to the foundations and principles and their clean application without compromises the devolve us to the things we were trying to avoid.

Here is what we are trying to avoid:

A Rikshaw Puller from a small city who would have hardly been in any schools shares memes to others on WhatsApp

My mamma shouts on my father (LOL) because he uses phone late till 12 AM because of Youtube. She says, “Aapka to alag hi chal rha hai, jawani fir se aa gayi hai?” - and we used to laugh.

TLDR; For the climax story, read below first. But reading whole is worth.

Hey, how does the above statements answer the question?

Ummmmm…..

This happened because of computer programming, Android became so powerful, its applications became so powerful, and here comes one of the most popular app of the decade.

WhatsApp: From a 5 year old to 80 year old uses this.

What changed, see below

———————————————————————
“YOU KEEP THE WORLD IN YOUR POCKET NOW”
———————————————————————

[ =======> Shop the world

Buy house hold things (Ration, Daily use stuffs) from — Grofer, Big Basket..

Get a jeans, shirt, shoes, anything — Flipkart, Amazon, Myntra….

Buy home appliances, books — Flipkart, Amazon..

Chai peeni hai? - Chayoos, Chai Point, Chai-Sutta

[ =======> Pet-Pooja (Food)

No one goes to dairy for milk — Milk Basket..

Get cheeper food from the same restaurent at even 3 AM — Zomato, Swiggy..

Get healthy food from — cure.fit..

[ =======> Ghumakkad (Travel)

Want to visit local area, no need to ask auto, taxy “Bhaiya kitna lenge?” — Ola, Uber

Going alone with less money, rent a bike — Rapido, Uber Moto, Ola Bike, Dunzo

Wanna travel long distance, book a bus — Redbus, Make My Trip, Goibibo

No dhakka-mukki (hustle) in Booking window queue for reservation — IRCTC

Wanna fly high in the sky, book a flight from — Goibibo

[ =======> Be healthy

No need to ask your friends for a good doctor — Practo (In few city)

Get your medicines at your door step — 1mg, NetMeds, Pharmeasy

Get your blood test at your home — 1mg

[ =======> Games & Fun

Play game with your friends living 100 miles apart — PUBG, Counter Strike, LUDO….

Watch TV at your phone -- Hotstar, Prime Video, Netflix, Airtel TV, Jio TV, TVF

[ =======> Rishtey Naatey (Relations)

Share your feelings in society — FaceBook, Instagram, Twiter

Make videos and be a star — TikTok

[ =======> Know more

Dont ask station master if train is late, leave home late — Where is my train?

What is this? What is that? — Ask from google

Which road goes to Delhi? -- Google map

Baarish kab hogi (When it’s gonna rain) — Google Weather

Meanwhile COMPUTER PROGRAMMING be like - I am the boss

Hahahahahah….. But

KADWA SACH (Bitter Truth)

People are now at distance from heart.

Kids dont come out at evening to play in dirt becuase of PUBG,

People just whatsApp, dont meet others.

Teens now propose girls in TikTok

Social media can promote even a bad person.

Memers go into anyone’s personal life - huhhh

Keep loving everyone, dont be apart, live together, The technology is from you, you are not from technology!!!

Thanks…
Keep Loving & Keep Programming

Almost all of it. The same algorithms come back in different implementations. Those implementations are better suited, so we drop one technology for a different technology which reimplements the same algorithms.

For example, remote procedure calls were developed by 1981. It’s epitomized by client/server architecture (like Microsoft Foundation Classes) from the 1980’s mid-1990’s. At which time, the Java RPC starts redefining it with Java specific ways. Microsoft helps open it up with Web Services and we start using regular HTTP calls. However, it’s too bulky and too much overhead. So, REST is created to take more advantage of internet routing. REST with json doesn’t compress well, so Google develops ProtoBuffers, which is fast and reliable. It’s similar to the electronic data formats of the 1960s and 1970s (aka EDI). The latest craze is to machine learning with lots of data, but now security, compression, internet routing are required. That leads us into GRPC, which is the current state of the art for RPC. Conceptually, it’s identical to what was happening in the 1970’s, but it takes advantage of the change of technology since.

The implementations change, but the algorithms/design patterns remain the same.

Epilogue:

The Art of Computer Programming will have to be updated, but fundamentally every thing is right. That said, many new algorithms have and will continue to be invented. Machine Learning algorithms and Quantum Computer algorithms are clever synthesis of the old and new. If we do it right, then humans will have to do less work to update the algorithms.

Well, first of all computers were people. In WWII, people like Alan Turing worked out how to crack the Enigma code and they would laboriously work out the key for the day.

The people who were computers were WRENS (women in the Royal Navy). Maybe I should go back even earlier to say that Ada Lovelace (Lord Byron’s daughter) was the first programmer and she programmed Charles Babbage’s difference engine. This was a mechanical device (and if you are in London, you can see Babbage’s programmable machines in the Science Museum). I knew some of his descendants and Mrs Babbage managed to burn down her kitchen three times in one year - it was quite an advanced algorithm!

Anyway, back to Bletchley park (as in my icon you can see here). Actually deriving the day’s key to crack the code was difficult and time consuming and a way was needed to do it mechanically. The Polish had developed a Bombe machine, and Turing improved on it to crack the keys in a timely fashion.

This is an example of programming by hard wiring. This is not really programming as we know it now - programming by hardware, rather than by software.

“Timely fashion” is important because time is the only resource that we really care about – all other computing resources are there so we can do computations in a timely fashion. Cracking the Enigma code was important to do quickly, hence the electronic Bombe was developed. You can see this in the recent “Imitation Game” movie – I highly recommend it, as well as a visit to Bletchley Park and the National Computing Museum next door (although that has more to do with the evolution of computer hardware rather than evolution of programming).

Then at Bletchley Park, Tommy Flowers developed the Colossus machine, which was programmable. These machines were programmable by patch panel (I think, details are still sketchy on Colossus, even though you can see a reconstruction at Bletchley Park).

But programming by patch panel was slow and error prone, requiring maybe a whole day to enter a program to be run once. So a way was developed to put programs into memory and John Von Neumann put programs into the same memory as data. This has proven not to be very secure and it is a well-known ‘rule’ to keep programs and data apart (program code can then be reentrant, which is a big advantage).

Another model is to have separate memories for code and data. This is known as Harvard Architecture as opposed to Von Neumann architecture, and it avoids the “Von Neumann bottleneck” where code and data must share the same data path between memory and the processor. But the problem is predicting how much memory you need for programs and how much for data.

This problem can be avoided by introducing a 1 bit flag to distinguish – thus programs cannot overwrite program memory. This is actually much more secure (and would prevent most viruses and worms). Burroughs actually championed those ‘tagged’ architectures and they are very secure and avoid many classes of other well-known software defects (bugs).

So, the question now is, how do we get those programs in memory? First of all, the instructions were worked out and the bits toggled tediously into memory. Well it was faster than patch panels, and you could punch the programs onto tape for reuse. (Reusability has become a big topic in programming.)

Then someone had a bright idea that we could write a program that would take symbolic instruction codes and generate the bit-pattern programs themselves. But even better to form loops which required jump instructions, labels could be used and the addresses worked out by the software – called an assembler (no one seems to know why), and memory locations to store data could also be named and again addresses automatically generated. Programmers did not have to know about or manipulate memory addresses anymore – that is a BIG clue!

Linkers were then introduced so that addresses were resolved, and loaders so that programs could be loaded at different base addresses. But even they are not needed when relative addressing is used (but that was complained about as wasting CPU cycles.)

But, mathematical notation was still much clearer saying x := y + z (ok, assignment := is not a part of mathematics, which uses = for equals, something which is much different to assignment, do not confuse the two like inferior programming languages do!)… anyway x := y + z is easier than LOAD Y to R1, LOAD Z to R2, ADD R1, R2 to R3, STO X,R3 ugh! (or in a stack machine it would be much simpler but still a pain LOAD Y, LOAD Z, ADD, STO X (none of those pesky registers which are a bad idea).

So, John Backus and others invented FORTRAN (FORmula TRANslator – from mathematical formulas of course!). But then came a syntax language called BNF, for Backus-Naur (or Normal) Form. This allowed language syntax to be expressed as context-free (read simple and free from other defects of context-dependent languages) grammars. This was based on the work of Noam Chomsky (yes that Noam Chomsky who rightly believes universities should be free and not put students into self-perpetuating debt for the rest of their lives, just to feed the mind-numbing commercial system).

So, Backus and others wanted to rid the world of the curse of FORTRAN (one of those languages that confused = with assignment) and invented the most breathtaking step in programming – ALGOL. ALGOL also introduced recursion, which was forbidden in FORTRAN due to its static way of allocating local variables (in common memory and not on a stack). But already, FORTRAN had a religious and cult following and the word recursion was not allowed to be used in the original ALGOL specification so as not to scare off the FORTRAN addicts.

ALGOL was a really clean and general design, and maybe still one of the best designed languages to date. (As Tony Hoare noted, most of ALGOL’s successors were significant backwards steps.)

ALGOL was the first language (with some extensions) to be used to program a whole operating system and related system software in the Burroughs (yes them again) B5000 designed by Bob Barton and team. Barton envisaged a machine designed by programmers for programmers, not by electronics engineers so programmers had to forevermore have to work out how the hell to program the things.

Barton B5000

In the same way that ALGOL was clean and general, the B5000 was a clean and general architecture based on the concepts of ALGOL (even the FORTRAN implementation was recursive). Procedure calls were actually efficient and fast. On other systems it was recommended not to use procedure calls because they were too inefficient. Hence programmers had to bend their programs to make them work efficiently if at all. The point of Burroughs was not to do that, but to write programs logically towards the problem domain, not the machine domain.

Now remember, I said, that the only resource we are ultimately interested in is time – not CPU speed, not memory size – you only increase these to make a computation go faster. In fact, just like at Bletchley Park where they started using electronics for speed, electronic computers are only good because they are fast – blindingly fast (only quantum computers will be faster – blindingly much faster!)

Thus a lot of programming research has been into algorithms that make it possible to do certain classes of computation. These are the tractable class. The intractable class are not impossible – just we can't think of ways of doing them for reasonably-sized data sets that will complete before the life of the universe pegs out (or at least we just lose interest before we get an answer).

Now some people think we need languages that save a few processor cycles here or there – but these are irrelevant compared to electronic speed and algorithm speed. It is irrelevant because those languages sacrifice things such as security and correctness to save processor cycles (have I mentioned C yet? no, I suppose I should as one of those backward step successors to ALGOL).

Let’s go back to just before ALGOL. The principles of structured programming were worked out. Certain simple, but dangerous things were to be avoided. In control flow that was jumps and gotos. Rather we had the one entry and one exit to any structure. These structures were sequence, conditional, and loops (and recursion). These all flowed to well-known places, whereas goto could fo anywhere and result in programs that were very hard to follow. For this see Dahl, Dijkstra, and Hoare’s book “Structured Programming” ([PDF] Structured Programming, Dahl, Dijkstra, Hoare, Academic Press 1972 - Free Download PDF).

But it is not just gotos – it is also addressing and address manipulation. Remember how I said one of the significant things in assembler was that addresses were automatically handled, well true high-level languages go a step further and all memory allocation and deallocation should be done automatically and not handled by programmers. Even memory management at garbage collection should be automatically handled, so that programmers don’t have to worry about these fiddly and error-prone details. This also precludes the pointers and pointer manipulation of several languages – they are a really bad idea.

Next step – we wanted ways to organise larger programs. So we got types and objects. Objects encapsulate the program with the data (not in the above sense of program and data memory of Von Neumann and Harvard architectures). This is so operations against certain data types make sense. For instance we drink a glass of water and switch on a computer. We don’t drink a computer and switch on a glass of water – such nonsense should be disallowed by a compiler and a language specified to do so.

Objects and modules (work of David Parnas) are not only a good way to organise software but they form a mathematical way of thinking about software. Thus data is only accessed via a published interface (this is also good for concurrency and distributed computing), not via backdoors like pointers (remember I said pointers are a really bad idea – that’s because pointers ARE are REALLY BAD idea).

Now some people want integrated testing, and that is a good idea. So Test-Driven Development (TDD) is now an industry buzz word. Good for what it’s worth, but really doesn't go far enough. You want testing built right into the software and you can do that with interfaces. There are two checks we can do with interfaces – static, that is checks done by a compiler so that we don’t have to do it at run time (this is the holy grail of testing, but so far is not completely achievable). Languages use types to do this kind of checking (so you can’t drink the computer).

But we also need to fall back on dynamic tests for those we can’t statically test for, such as out of bounds access, etc. Not only do these tests help with program correctness, but with security as well. And security is the next step of program evolution because the industry is currently in crisis over this.

So, if TDD does not go far enough, what does. It is Design by Contract (DbC). This was championed by Bertrand Meyer who directly implemented it in his language Eiffel.

Design by contract - Wikipedia

Now I should also mention Smalltalk and Alan Kay, also significant steps in computing and object-oriented programming (a term that Alan Kay introduced, but he later thought message-based programming was more significant).

(Notice I have only mentioned C once, and I have save C++ until now. These are widely used languages, but they really introduce complexity that should not be there. Programming has always evolved towards simplicity. Simplicity tames complexity – complexity cannot be tamed by more complexity, that just makes the situation worse, and so you can see what I think of the languages that I reserved mentioning until the end. But a lot of people in this industry don’t understand this, and hence some languages have gone in completely the wrong direction.)

Oh, yes I get to the end and realise I have not even mentioned abstraction, so have missed one of the most important concepts. Note abstraction means simplification, not complication or obscurity (not abstract art, although abstract art is about simplification actually). Abstraction is considering detail at the correct level, but keeping detail at that level and not allowing it to higher levels. Thus as I said, assembler language originally did away with the detail of addressing – and this resulted in a whole lot of advantages. Higher-level languages do away with the detail of memory allocation and deallocation altogether. So abstraction is an essential concept in the evolution of programming – but a lot of people misunderstand it.

(Maybe this has become my longest answer ever. I’m sure I’ll revisit it and do some editing.)

My answer is a qualified "yes, coding is easier today." In fact, it's so much easier to attain a given (relatively complex) result that it's not even worth comparing the two.

In 1985 the 6 mhz IBM Personal Computer/AT was state of the art for microcomputers, as was the Apple IIe and the first incredible version of the Apple Macintosh. Most programs rendered text or simple ASCII-art style graphics. Most games were incredibly simple (think centipede, or adventure games with a picture and four choices at each step of play). It took an insane amount of work to get these results, dealing with a processor that was perhaps as slow as 1 mhz, 64 kb of RAM, an 80 column screen if you were lucky, and amazing 640 x 480 graphics.

64 kb of RAM, and for almost everyone, floppy drives at best. For significant programs, every byte had to be accounted for and carefully structured to fit the pieces you needed into the tiny RAM. When I started working on my first game - NinjaQuest (never released), I had to write my own sprite editor in assembler, and hand-animate the characters. side-scrolling had to be done very carefully to change a minimum of information on the screen. And don't even get me started on sound... All in 6502 assembler which I affectionately refer to as write-only code. BTW, the computers were around $2,000 in 1985 dollars.

(assembly code from Gamasutra: David H. Schroeder's Blog )

Today if I want to write a program, I boot up a $500 machine with a $350 4k UHD monitor. I run either Visual Studio or IntelliJ Idea, and have more than a terabyte of disk space to store the programs I write. If I want to animate things or have 3D characters, and if I'm not planning to sell the program, I can browse the internet and find some pretty decent sprites, art, pictures, and 3D models for the taking. With a couple hundred hours of effort I could put together a game with 3D characters moving around, perfect 3D sound, and have it be reasonably bug free. Thank you DirectX and OpenGL!

Suppose I wanted to build a sidescroller like NinjaQuest that I worked on for several hundred hours before I gave up. Between the tools available today and the incredible resources, I could build a better experience that looked and sounded better than I could ever have hoped in perhaps 100-200 hours. Then I could share it with the entire world over the internet.

Is coding easier today? For the things we can meaningfully compare, ABSOLUTELY. The barrier to entry is lower, the sources of information are higher quality, and there are tens of thousands of people out there who will answer your questions for fun. Your biggest problem today is, quite simply choice. So many choices of language, of environment, of platform.

Choice is, of course, a good thing. As are computers.

How has computer programming changed in the last decade?

Thanks for A2A.

Programming has changed a lot in the last decade.

Earlier (E), the major focus was on the functionality and then the importance given to the user interface.

Of late (New), the importance has been to deliver the same functionality over the different media - Phone / Tabs / Voice / Apps etc.

E - The target platforms were only a few (handful) and the developers were clearly told what was identified platforms (Mostly PC - Windows / IOS and internet based). So, the developers had a handle on the platform-based developer tools. Though browsers and their upgrades were changing, they posed little impact to the developers.

N - The platform is changing a lot. Newer models are released every now and then. The specifications change. Newer versions of OS are released and older versions are not supported for a longer period of time. Customization required for many of these platforms. So, the focus was on “delivery medium” and not core functionality !

E - Structured programming was the norm keeping in mind ease of maintenance aspect.

N - Quick and dirty releases are given more importance to keep up to the fast changing user dynamics.

E - Number of competitors were few and known. A newer version used to take a long time (1–2 years minimum) to get to the market and hence the companies had enough time to balance between Customer Experience and the desired functionality and stay competitive in the market.

N - many apps are being developed and deployed quite frequently. The competition is way too high and there is pressure among the App developers to ensure that their products meet customer expectations and beat the competition ! This means, Apps have to be developed fast and deployed soon. upgraded functionality is the norm everyday. If not upgraded, the App would be outdated !

E - Started collecting usage data. Not much analysis was done. The data was used for internal purposes and analysis. The data was analyzed by developers and analysts using tools. Any changes based on the analysis would take a minimum of few months to deploy.

N - Data has become the center point. Customer experience, Ads, rewards / awards are customized based on data. Automated data analysis (machine learning and AI) have made the decision making more intuitively and this has led to shortened cycles between the releases.

E - Presentation layers with graphs and stats were manually coded. The elements for analysis were controlled (limited) to the options provided by the developers.

N - Many tools are available which gives immediate results on data slicing and the options to analyze are currently limited by the tools and not by the features provided by the developers (100 times better than the limited features provided by the developers).

I can keep listing them but to keep the interests of the readers I am stopping here.

Good common question … let’s start with the short simple answer

Early programming was manual, tedious, and hardware-specific, requiring programmers to know their machine intimately.

Modern programming is abstract, accessible, and collaborative with tools and languages designed to make developers more productive and creative.

Let’s break it down for more detailed answer … shall we:

1. Programming Languages

• Early Days:
• Programmers used machine code (binary) or assembly language that was just one step above binary and very hardware-specific.
• Example in assembly: MOV AX, 1 ; Move the value 1 into register AX ADD AX, 2 ; Add 2 to the value in AX Imagine writing an entire program like that! It was slow, detailed work, and debugging was a nightmare.
• Later, higher-level languages like Fortran, COBOL, and Lisp emerged in the 1950s-60s. These were much closer to English and mathematical notation, making programming easier and faster.
• Modern Times:
• Today, we have powerful, user-friendly languages like Python, JavaScript, and Swift that are abstracted far away from hardware.
• A modern Python program to do the same as the example above: x = 1 x += 2 print(x) This is cleaner, easier to read, and runs on any machine without modification.

2. Development Tools

• Early Days:
• Punch cards were used to write programs. Each line of code was punched onto a separate card, and you had to run the stack through a computer to execute it.
• If you made a mistake (like dropping your cards or punching the wrong hole), you had to start over. Debugging was literal—you'd find "bugs" (like moths) stuck in relays.
• Modern Times:
• We now have IDEs (Integrated Development Environments) like Visual Studio Code, PyCharm, and Eclipse that:
• Highlight syntax errors in real time.
• Suggest code completions.
• Integrate with debugging tools and version control.
• Testing and deployment are often automated, making life much easier for developers.

3. Collaboration

• Early Days:
• Collaboration was mostly local. Programmers shared code by hand-writing it, mailing punch cards, or printing out listings.
• Code reuse was rare because programs were tightly coupled with specific hardware.
• Modern Times:
• We now have version control systems (like Git) and platforms (like GitHub) that allow global collaboration.
• Thousands of developers can contribute to open-source projects like Linux or TensorFlow.

4. Hardware and Constraints

• Early Days:
• Computers were massive, expensive, and had limited memory and processing power. You had to optimize for every byte and CPU cycle.
• Example: Early Apollo mission code was written for computers with only 64KB of memory!
• Modern Times:
• Hardware is cheap and powerful. Most developers don’t need to worry about memory management or optimization unless they’re working on specific fields like embedded systems or gaming.

5. Accessibility

• Early Days:
• Programming was exclusive to a handful of specialists who worked for governments, universities, or large corporations.
• Learning resources were scarce—no YouTube tutorials or online forums.
• Modern Times:
• Anyone with a computer can learn to program. There’s an abundance of free resources (YouTube, Coursera, Codecademy).
• Programming is taught in schools, and there are coding bootcamps for quick upskilling.

6. Paradigms

• Early Days:
• Programming was mostly procedural—step-by-step instructions.
• Object-oriented programming (OOP), functional programming, and agile development methodologies were non-existent.
• Modern Times:
• We have a variety of paradigms (OOP, functional, declarative) that make complex problems easier to solve.
• Agile, DevOps, and other methodologies streamline teamwork and development.

Final Word:

Today's programmers owe a lot to the pioneers who worked through the painstaking early days to pave the way for the user-friendly tools we enjoy now!

Go back 30 years takes us to 1991 and 40 years 1981.

By 1981, Mainframes were still king of computing and Cray computers were the fastest computers.

By 1981 the Pascal language was on the rise. SQL and Relational Databases were just getting started. Unix was still trying getting a foothold outside of academics. C compilers were found on many platforms. Motorola 68000 was core of SUN computers. FORTRAN and COBOL were still taught in colleges.

By 1981, “The Art of Computer Programming” by Donald Knuth had only published 3 volumes.

Robert Sedgwick’s “Algorithms” first edition, which used Pascal, was a year in the future at 1982.

“Fundamentals of Computer Algorithms” by Horowitz and Sahni had been published in 1978. My personal copy was a 12 printing first edition.

I will list some items from table contents:

Chapter 2: Elementary Data Structures. Stacks, queues, trees, heaps, heap stores, sets, disjoint set union, graphics, hashing

Chapter 3: Divide-and-Conquer: Binary search, Finding max and min, Mergsort, Quicksort, Selection, Strassen’s matrix Multiplication.

Chapter 4: The Greedy Method: The general method, Optimal storage on Tapes, Knapsack problem, Job sequencing with deadlines, Minimum spanning trees, Single source shortest paths.

Chapter 5: Dynamic Programming: The general method, Multistage graphics, All pairs shortest paths, Optimal binary search trees, 0/1 knapsack, Reliability design, The Traveling salesperson problem, Flow shop scheduling

Chapter 6: Basic Search and Traversal Techniques: The techniques, Code optimization, And / Or graphs, Game Trees, Biconnected components and depth first search

Chapter 7: Backtracking: The general method, The 8-queens problem, Sum of subsets, Graph coloring,, Hamiltonian cycles, Knapsack problem,.

Chapter 8: Branch-and-Bound: The method, 0/1 knapsack problem, Traveling salesperson, Efficiency considerations.

Chapter 9: Algebraic Simplifications and Transformations: The general method, Evaluation and interpolation, The fast Fourier transformation, Modular arithmetic, Even faster evaluation and interpolation.

Chapter 10: Lower Bound Theory: Comparison trees for Storting and searching, Oracles and Adversary Arguments, Techniqus for algebraic problems, Some lower bounds on parallel computation.

Chapter 11: NP-Hard and NP-Complete Problems: Basic concepts, Cook’s theorem, NP-Hard graph problems, NP-Hard scheduling problems, NP-Hard code generation problems, Some simplified NP-Hard problems.

That should be a good view of “state of the art” for a undergraduate textbook from 1978.

I suggest you also examine “The Mother of All Demos” at The Demo - Doug Engelbart Institute

This took place in 1968 on mainframes.

In the early 70’s, a programmer would keypunch his computer program using 80 column punch cards. Then he would feed his deck of cards into a card reader attached to the computer. And then he would look at his printout to determine if his program worked.

Mini-computers came into use during the 70’s with multiple terminals hung onto them.

Programming students would sign up for a time slot, and key in their BASIC programs.

The first BASIC was an interpreted programming system. While sitting at a terminal, students would run their program, make corrections, and run them again until it worked or their time slot ran out.

When the first IBM Personal Computer came out in 1981, it included a BASIC interpreter that had been written by Bill Gates. Programmers used it pretty much the same as those mini-computer systems.

It really depends on how “early" we are talking about. If you go back to the dawn of electrical computers, it was very different.

Back in the 1940s, computers were mostly analog and built in functional blocks. You would have a circuit that did the calculation you wanted then put another circuit after that to do another manipulation of the data etc… the programming of the computer was the arrangement of those functional blocks and adjustment of the analog circuit in order to accommodate your problem.

Let's say for instance you needed to multiply by 32 and then add 5, you would have a circuit that multiplied, you set it for 32. Then you connect that output to another circuit that adds and then set it for 5. In many cases, you would use patch cables to do the connecting and set some sort of dial to set the values. This type of computer could be useful in order to say compute firing angles for artillery. In many cases however, the end computer was set in hardware for that particular purpose and the end user could just alter the data. The original eneiac was a digital computer but still used the functional block connection method. Soon after however, the stored memory program came to prominence.

In function… that's not too different from what a modern processor does. A cpu may have an adder, a ring counter, etc… these are just functional blocks that the cpu sends data to by way of a demultiplexer. An instruction comes in, gets demultiplexed to a certian line that will activate a specific functional block. That demultiplexer allows a command to do the rewiring on the fly instead of having to do it by hand. Basically, you were programming in machine code by physically connecting up the machine! So, the end result would be the same, but the “programming" would take much longer. In addition, if you ran out of functional blocks on your computer, you be would need to take the intermediate result, reprogram the computer and keep going. This was fixed by the accumulator which takes the result and puts it back at the beginning for further processing.

The stored program/accumulator model or Von Neumann architecture (for the computer scientist who came up with it) allowed for more complicated programs to run and lead to the development of computer languages.

It was very different back then for programmers.

When you built a website 20 years ago, you did it with HTML and CSS. Not many other tools or libraries were used.

No social sharing.

No front-end or responsive libraries.

Also, CSS was still evolving. Each browser, including the long forgotten Netscape, handled CSS differently. So coding for all browsers was a huge pain in the ass.

Even HTML was slightly different across platforms. IE wanted stuff coded its own way. Netscape, another way. Netscape was the most popular browser after it’s release in 1994, but they disappeared as support ceased in 2008.

Chrome was not released until 2008. Hard to believe they came on the scene only 10 years ago.

Firefox was also not around 20 years ago. They didn’t release until 2004.

Anyway, even with only 2 major browser on the scene, it was a nightmare to code for both browsers.

Responsive design and mobile devices were not mainstream at all. So all websites were written for desktops or laptops. Max screen resolution was, on average, 640x480 with a few at 1024x768.

Today, there are a wealth of choices and tools for developing a rich user experience for a website.

My “style” of computer code has changed dramatically since I started coding.

I started with cards and paper tape on machine with 8K to 32K.

My “programmer time” vs “computer time” trade has dramatically changed. I don’t have to squeeze code into small memory.

When I went from programming in Assembly to Pascal, my data structures got a lot more complicated. I went from simple linear searched array to using binary look up, Hash Tables, trees, and B-Trees.

Have working as a “Systems Engineer” I saw text processing in a different light. I found that using “pattern matching” I could extract information from technical documents in PDF, MS Word, or dumps of Relational Data Bases.

I was able to find inconsistencies and error within and between this human readable documents.

The program I wrote would take 30 second on modern laptops take several megabytes of storage. I used a language I had used in the 70’s. For every second on a modern computer would have at least an hour on those old mainframes.

The level I think and program at is very different when when I started programming back in 1968.

My style continues to evolve as I program and learn more and more.

I also experiment with other languages like LISP and Prolog.

The application has changed but the language is the same, apart from that there are a couple of upgrades in bits. For e.g languages such as Python, C++, etc. are old languages and are still used by programmers. Hence the language remains the same, but its application has changed drastically.

When python was launched in the late 90s, it was used to create the user interface, but now we see that python is used for data analysis, web development, game development, Software development, etc. and the same goes for other programming languages.

In the last decade or so the popularity of these languages have also changed for e.g in 2010 Java and Java script were pretty popular languages, in 2015, the popularity rankings changed significantly, python moved in ranks to replace PHP. Notably, R is used for statistics programming, etc.

Hope this answers your question :)

Low level programming? Not that different.

Specific details differ. A modern CPU has a much more extensive, more streamlined instruction set than an early stored program computer. The programmer does not need to worry that much about memory and execution speed since modern hardware is more than adequate for most tasks, even when the code is terribly inefficient. And it is much easier to write programs using fast, reliable SSDs, hard drives and cloud storage than messing with punch cards or similar archaic storage mediums. But the basic algorithms remain the same, the basic challenges remain the same when you write code in assembler or a relatively “low-level” programming language like C. There are only so many ways you can handle an interrupt, move bytes through an I/O port, or solve a system of partial differential equations numerically.

On the other hand… application programming has become conceptually very different compared to the early days. What does a variable represent, for instance? A number? A string? An array? An object with properties and methods? How about a single variable representing an entire cloud service? A user identity? A complex application?

On a strictly technical level, of course, there is little difference between assigning a fancy name to a collection of subroutines or simply referring to them as, say, subroutine 23 on magnetic drum 7. But we think about these things differently. Instead of bits and bytes, numbers and strings, we request, say, an authentication token that authorizes our code to perform a specific action on behalf of a user, and then use this token when we generate a service request. Programmers working on application code at this level do not worry about the nitty-gitty details of how many bytes that token occupies or how the memory it uses is freed afterwards; they worry about the token’s persistence.

Another difference is that nowadays, many applications “live” in a complex, networked environment with code running in several different contexts: e.g., JavaScript code managing the UI of a Web application, server-side (e.g., PHP, C#) code performing the application logic, database queries running against records on a database server, while accessing cloud storage using yet another software interface. This is quite a change from the old school, one computer, one CPU, one user conceptual foundation that characterized personal computing decades ago, or the time-share, batch processing computer environments of mainframes.

Yet another major difference is the emphasis on security. Back in the old days, users were assumed to be people who had authorized access to the system and whose objective was to make things work. So certain bugs were… acceptable. If typing too many characters into a field crashed the application, you could just stick a note on the computer monitor saying “Don’t type more than 20 characters in field X” and that was it, at least until a new version was developed, possibly months if not years later. Today? A bug like that is readily exploited by hostile individuals, cybercriminals, you name it. Today, even a simple Web application needs to be more robust, security-wise, than highly secure military systems decades ago.

So yes, if a programmer, even an experienced programmer from, say, 1991 was transported to the present and entrusted with developing even a simple Web application, he would likely fail miserably at first. The very idea that the same PHP file contains code that runs on the server side, code that runs on the client workstation, code that runs on a database back-end, and perhaps even code that runs on a remote cloud service? It would take quite some time to digest and process these things conceptually. Meanwhile, he would have no appreciation whatsoever of the security challenges that ubiquitous Internet connectivity imposes even on simple solutions.

On the other hand, experienced present-day programmers can do things that back 30, 40 years ago we never even dreamed possible. Take the venerable Commodore-64 for instance: at the time a revolutionary machine with its reasonably capable 8-bit processor running at 1 MHz, and its whopping 64 kilobytes of memory. Now you wouldn’t expect a machine like that to run a windowing operating system or full-motion video. Yet people found ways to make it happen. Let me tell you, back in 1983 or thereabouts when I was actively working on developing games for the C64, no sane person thought something like this would ever be possible on that computer:

So yes, I daresay our profession changed a lot, even as some things remained the same.

A programmer was asked an interview question - If you had to construct a swimming pool for Mark Zuckerberg and had no budget limit to your project, describe the pool you will make?

Now this guy didn't have a clue about how swimming pools are made or what are the requirements for one. But his answer was what you can expect out of a programmer.

His answer -
Let's consider the components here - A pool, a fountain nearby, a changing room, a bar, a resting/sunbathing area, and some other stuff rich people have by their pools. Since here we are referring only the pool, I will only describe the pool. Also since Mark loves Star Wars, this would be a Star Wars themed pool.

Let's consider the pool to be rectangular with a standard size of 16ft by 32ft.
Now for lights, there will be one at every 4 ft along the perimeter. The colors of the lights will change if Mark decides to select Sith theme or a Jedi theme. On a closer look at the each of the light you will see a distinct star wars character on each of them, which will only be visible when you are close enough. The lights will also ..... **gets interrupted by the interviewer**

Interviewer - Let's move on to another question.

Programmer - But I haven't finished my answer sir....... in fact, I had barely started.

Interviewer(who was a wise man) - You don't need to, you're shortlisted for the next round.

Programming is about taking a problem (making the pool) and defining a solution to it(size of pool, lights, right down to each light) where every small detail is elaborated cause you are trying to convey it to the dumbest thing on a planet(a computer)

Edit - If you enjoyed this do check out Dipt Chaudhary's answer to Why do some computer programmers develop amazing software or new concepts, while some are stuck with basic programming work?

According to my point of view Computer programming changed this way

• Google is a little more than ten years old. But the company's most popular services have only risen to popularity over the last five to seven years. In addition to Google search, can you imagine a world without Gmail, Blogger or Picasa?
• Having the Android phone has become just another basic necessity to survive after Food, Water and Air. And if we look through your phone we have different application for different purpose. From shopping to rides all are available at one click.
• Competitive Coding has seen a sharp increase because nowadays learning any programming language has become accessible to everyone before it was only the engineering or CS students hence the level has increased.
• Recruitment on the basis of coding is at the top. Gone are the where you would be asked simple DS or algorithms…now you’d be asked to implement something ‘using’ the DS and algorithms via CODING
• Language tooling is richer today. A programming language was usually a compiler and perhaps a debugger. Today, they usually come with the linter, source code formatter, template creators, self-update ability and a list of arguments that you can use in a debate against the competing language.
• Even programming languages took a side on the debate on Tabs vs Spaces.
• Adobe Flash, which was the only way to provide some smooth interaction on the web, no longer exists, thankfully. Now we have to develop on three different platforms with entirely different programming models in order to provide the same level of interaction.
• IDEs and the programming languages are getting more and more distant from each other. 20 years ago an IDE was specifically developed for a single language, like Eclipse for Java, Visual Basic, Delphi for Pascal etc. Now, we have text editors like VS Code that can support any programming language with IDE like features.
• Code must run behind at least three levels of virtualization now. Code that runs on bare metal is unnecessarily performant.
• Cross-platform development is now a standard because of wide variety of architectures like mobile devices, cloud servers, embedded IoT systems. It was almost exclusively PCs 20 years ago

The further back you go, the less abstract it was.

Earliest computers needed custom circuits built. They were later configurable to a degree using patch cords - physical cables plugged into jack sockets.

Program source code started out on punch cards and paper tape, where you can see the physical binary pattern of commands. It was only later where that gave way to typewriter style keyboards with letters on. Today, voice input can work.

The programming languages themselves started out as primitive lists of machine-level operations. The story of languages has been to raise the abstraction level closer to how humans think about a problem. Less about how the hardware works, and more about modelling the problem at hand.

Think of it this way.

You are designing and building a machine, whether it’s mechanical or electronic, and you want it the machine to perform some specific operation (behave in a very specific way) when presented with a very specific pattern of inputs. You want it to perform a different operation when presented with a different pattern of inputs. You continue to add more operations, where each operation is effectively a reaction to a different pattern of inputs. Eventually, you have created a machine which performs several different operations, when presented with different patterns of inputs. If you then devise a way to feed a sequence of different input patterns into the machine, the machine can carry out a sequence of different operations, according to that sequence of input patterns.

The machine might be anything from a mechanical weaving loom to an electronic calculating machine.

You have a “programmable” machine. The sequence of different patterns fed into the machine is the “program” the machine will dutifully follow. Each input pattern would be considered and individual “instruction,” and the sequence of instructions make up the “program.” The machine carries out those input instructions, one at a time in sequence, effectively “running” or “executing” the program.

Each input pattern, in modern digital computer terms, is a “machine instruction.” A sequence of those machine instruction is a “program.”

In the 1830s, mathematician Charles Babbage designed a mechanical calculating machine known as the Difference Engine. Ada Lovelace — officially, Augusta Ada Byron, and later Augusta Ada King, Countess of Lovelace) — trained in mathematics and was inspired by the prototype of Babbage’s Difference Engine. Babbage had plans for a new mechanical device, the Analytical Engine, which Lovelace realized could carry out long sequences of mathematical calculations. As an example, she wrote a sequence that would calculate Bernoulli numbers. Only a small portion of the Analytical Engine was ever actually built, so Lovelace never got a chance to actually run that program on actual hardware. Lovelace passed away in 1852 at the age of 36. Nevertheless, Lovelace’s sample sequence of “instructions” for calculating Bernoulli numbers on the Analytical Engine is considered by most computing historians as the first computer program.

All of this significantly predated the arrival of the first digital computers in the 1940s. But the idea is the same. Instead of using mechanical components, electronic components were used to implement the behavior of the machine. Each machine had its own set of input patterns that it recognized to carry out specific operations. One pattern would cause the machine to add two numbers. Another pattern would cause the machine to subtract one number from another. A pattern triggering a specific operation was (and still is) referred to as a “machine language instruction.” The set of patterns recognized by the machine was (and still is) referred to as the “machine language instruction set” or “instruction set architecture.”

To this day, ever computer processor architecture has a unique machine language instruction set.

Knowing the machine language instruction set — binary sequences representing machine language instructions — a person can write a program for that machine, even if they don’t actually have the machine itself. It’s a matter of understanding how the machine is designed, and which patterns trigger which operations to occur.

Just like Ada Lovelace did back in the 1800s.

The Ada programming language, which emerged in 1983 and has evolved ever since, is named in her honor.

Harder than in 1997.

It isn't.

It's shifted in scale a bit, but even in 97 we had global scale eComnerce.

It was harder then to write a dynamic web app, with limited html, and Internet Explorer, and IIS. A database cost a ton of cash, with no open source ones available.

There was no cloud. No AWS. No tutorials on the web, because not enough people used the web. It was on an increase, but pre-broadband.

Today, we have a different set of problems. Multiple devices present a UX challenge, User numbers are higher. Expectations are higher. But we have better tools and building blocks.

Interesting. I'm not sure it has got harder, and yet it feels it sort-of has …

But it wasn't easier back then.