Does todays hardware encourage bad code?

[MurphCID]

When I got into computers, 64 kilobytes or 128 kilobytes of RAM was the norm with either one or two 360k floppies and NO hard drives. Code had to be compact, well written (as a general rule), and optimized to run on these machines. Has the explosion of RAM and hard drive space encouraged a generation or more of coders (hackers) who can afford to be for lack of a better word...Sloppy? Is bad code a result of having too many resources to use? Did the programmers/Coders of days of yore have to be better since they had so little to work with on those early machines? Just a thought over my morning cup of wake up. Plus I was thinking about my days of reading BYTE magazine (and others) and typing in the BASIC (and other) programs from the magazine. I remember booting my PC jr (128k of ram, one 360 k drive), and loading DOS 2.1 then, removing the disk, and loading Wordstar (I love that program, wish it was still around). Then later my Zenith Z-150 8088 with 640k and TWO floppy drives.

[Portreve]

In the sense that there's bloat at *all*, my guess would be "yes".

However, there's also a trade-off between perfectly tight code and:

• Convenience (not having to reinvent the wheel)
• Standardization (let specialists write libraries)
• Modularity (external calls, thereby reducing the footprint)

As I'm not a programmer, I'm only peripherally aware of these things. For more accurate and detailed commentary, I'll leave that to the experienced code wranglers here.

The other thing to always remember is that OS architecture has greatly expanded and become increasingly complex and specialized over the decades. Coming from the world of Classic Mac OS, we're no longer in a world where two system files (System and Finder) and a small retinue of invisible driver components and firmware-based OS objects like the Macintosh Toolbox are "all there is" under the hood, with all CPU, I/O, etc. contained therein. It's a sprawling, quasi-TRON "grid" world with lots and lots of specialized components.

[gm10]

As I'm not a programmer, I'm only peripherally aware of these things. For more accurate and detailed commentary, I'll leave that to the experienced code wranglers here.

There's not really much to add, you've got a pretty good understanding of the situation.

And while I also somewhat fondly remember the times where you'd write your code in assembler for maximum optimization because every byte and every cycle counted, when having 128K of RAM was a big deal, I do not want to go back to that. It's only natural that with the complexity of the systems at the same time the layers of abstraction have increased as well.

That naturally adds some overall bloat, but it makes the whole thing more accessible. For a normal user application you do not need to know a thing about hardware programming anymore, you just need to import a library which itself imports a couple more, and after several layers of abstraction eventually a window appears on your screen.

That accessibility does not encourage bad code, but it makes it easier for bad coders to stay around. Easily confused, but not the same thing.

[mediclaser]

For me a bad code is an unoptimized code. A good code should be optimized for at least one of these:
* speed
* size
* portability

Back in the days of slow hardware and limited storage space, you could easily tell when your code needs optimization (or when a virus is present). Nowadays, you could get away with bad coding unless your code is for backend application serving thousands of client requests.

[karlchen]

Hi, mediclaser.

You missed to name the most important aspect as priority number 1 when developping software:
* Security
* Speed should come second only.
I am not sure that * Size is really a very important aspect any longer.
* Portability might be nice, but portability between what? (Java made this priority #1 and sacrificed security, speed and size for it. Plus it is a resource hog in terms of memory.)

Regards,
Karl

[gm10]

You missed to name the most important aspect as priority number 1 when developping software:
* Security
* Speed should come second only.

Speed isn't even necessarily second. As with everything in life, it depends on the circumstances. If there's a choice between speed and resource usage, then for a daemon running in the background I'll likely choose the latter (within reason).

[AndyMH]

Speed, size, portability, security.

You guys missed probably the most important, time = cost!

PS I used to be a cost estimator

[MurphCID]

Is it even possible to "bare metal" program these days? I remember guys writing in assembler, pascal, C, Cobol, Fortran, and ADA. Now it seems there are so many programming languages like Python, Perl, ruby, etc. But I agree, it should be security, speed, size, and portability although that seems to be a wish more than a reality.

[smurphos]

Is it even possible to "bare metal" program these days?

Yep - NASM is in the repos - an x86 assembler / disassembler to compile assembly language directly to executable binary if writing (or hacking existing binaries) in assembler is your bag.

Add utility to your list - I don't care how secure, fast, small or portable it is if it doesn't do the job it's supposed to and I'll trade anything but security for something that gets the job I want done done.....

[catweazel]

There's not really much to add, you've got a pretty good understanding of the situation.

And while I also somewhat fondly remember the times where you'd write your code in assembler for maximum optimization because every byte and every cycle counted, when having 128K of RAM was a big deal, I do not want to go back to that. It's only natural that with the complexity of the systems at the same time the layers of abstraction have increased as well.

That naturally adds some overall bloat, but it makes the whole thing more accessible. For a normal user application you do not need to know a thing about hardware programming anymore, you just need to import a library which itself imports a couple more, and after several layers of abstraction eventually a window appears on your screen.

That accessibility does not encourage bad code, but it makes it easier for bad coders to stay around. Easily confused, but not the same thing.

I agree 99%. Back when I started coding, 4k of memory was a pipe dream.

[Faust]

...... I remember guys writing in assembler, pascal, C, Cobol, Fortran, ......

I was one of them
Been there , done that !

[Portreve]

When there was no such thing as connectivity (particularly in the sense of the Internet) security was a significantly smaller issue. As hardware has scaled up, programming best practices, particularly in the commercial software space, overall did not rise to meet the challenge, hence (for example) the virus- (and eventually malware) hellscape that's pretty much been the trademark of Windows 95, 98, NT, XP, etc.

The nice thing about modularity, particularly when combined with libre licensing, is you can have the best and brightest working on every little thing, the benefits of which are then openly accessible to everyone.

I think the bloat argument itself is countered by the practice of having centralized libraries, especially with GNU+Linux, that any program can call on. How un-bloatful is it to have "bare metal" code when you have five or six or ten instances of, for example, I/O driver code on a box? Having a best-practices-written and maintained library (API, driver, or whatever) sitting on a box which then dozens of individual programs can call on seems much more efficient to me.

[gm10]

When there was no such thing as connectivity (particularly in the sense of the Internet) security was a significantly smaller issue. As hardware has scaled up, programming best practices, particularly in the commercial software space, overall did not rise to meet the challenge, hence (for example) the virus- (and eventually malware) hellscape that's pretty much been the trademark of Windows 95, 98, NT, XP, etc.

I don't think the virus/malware issue has anything to do with connectivity and programming best practices really. The very large majority of malware at the time didn't exploit either, it was mostly what you would call social engineering these days. Including passing around shareware floppy disks with a boot sector virus. Good times.

The remote vector was just the icing on the cake of the hilariously unsecured Win95 along with its hilariously uneducated (in terms of online security) users.

Best practices came into place on the server side though - back in those days where hosters were springing up left and right you could own a good chunk of them via something as simple as the web forms they offered you. Never trust your inputs was a thing most of them had never heard of. Those were fun times. I did a lot of "unsolicited intrusion testing"...

[mediclaser]

...... I remember guys writing in assembler, pascal, C, Cobol, Fortran, ......

I was one of them
Been there , done that !

Same here. I was a student back then.
I learned Assembly by playing with the DEBUG command. There I learned how Borland made faster running programs compared to MS, because I compared the machine codes generated by their compiler+linker. I also learned how to locate, disable, and remove viruses from program files using DEBUG. I even created my own compiler that can create a *.COM program under DOS.

In my opinion, Borland would have been still here today if not for Windows.

[xenopeek]

I think with today's hardware and coding we're a lot safer than we were back in the DOS days. All those size and speed optimizations and hand coded parts in assembly didn't make for more secure code, I can tell you that. Mind that back then we ran one program at a time and didn't have always on internet connectivity.

I recall having downloading "Ralph Brown's Interrupt List" (bringing back memories for anybody else?) from some BBS and writing little programs in assembly that used internal DOS memory tables to hide my resident code into gaps at the end of memory pages and hijacked DOS interrupt handlers to run my hidden away code. Or later using undocumented processor behavior (opcodes or bugs) to make the processor misbehave and let me do things my program shouldn't have been able to. Virus scanners at the time weren't able to detect anything my program was doing. Didn't need sudo or anything. I didn't write viruses or anything, was just tinkering on my own PC with Intel's manuals and Ralph Brown's list for fun.

[cliffcoggin]

I agree 99%. Back when I started coding, 4k of memory was a pipe dream.

As an aside, is coding what was once known as programming? If so, why the change?

[xenopeek]

Yes coding is programming. As per Wikipedia:

Computer programming is the process of designing and building an executable computer program for accomplishing a specific computing task. Programming involves tasks such as analysis, generating algorithms, profiling algorithms' accuracy and resource consumption, and the implementation of algorithms in a chosen programming language (commonly referred to as coding).

[sgtor]

When there was no such thing as connectivity (particularly in the sense of the Internet) security was a significantly smaller issue. As hardware has scaled up, programming best practices, particularly in the commercial software space, overall did not rise to meet the challenge, hence (for example) the virus- (and eventually malware) hellscape that's pretty much been the trademark of Windows 95, 98, NT, XP, etc.

I don't think the virus/malware issue has anything to do with connectivity and programming best practices really. The very large majority of malware at the time didn't exploit either, it was mostly what you would call social engineering these days. Including passing around shareware floppy disks with a boot sector virus. Good times.

The remote vector was just the icing on the cake of the hilariously unsecured Win95 along with its hilariously uneducated (in terms of online security) users.

Best practices came into place on the server side though - back in those days where hosters were springing up left and right you could own a good chunk of them via something as simple as the web forms they offered you. Never trust your inputs was a thing most of them had never heard of. Those were fun times. I did a lot of "unsolicited intrusion testing"...

Those were the "good ol days" for sure, I remember them too. One of the big issue's I remember back when everyone was still on 56k dial-up and the first cable internet was introduced. What a thrill it was, always on and connected internet, if I remember correctly 10mbps, maybe it was 5mbps.

Anyway the cable company had all the subscribers on the same LAN as members of the "workgroup" workgroup. So of course clicking on network neighborhood showed you all the computers on "your" LAN with full access to everyone's shared files. And also nobody using windows back then had a firewall or a password. If I remember correctly you could see even more using a Linux computer.

[gm10]

Anyway the cable company had all the subscribers on the same LAN as members of the "workgroup" workgroup. So of course clicking on network neighborhood showed you all the computers on "your" LAN with full access to everyone's shared files.

Haha, had nearly forgotten about that, was the same all over the world. And Win95's admin shares weren't secure and easily exploited, password or not, so "shared files" really meant full remote administration access to every Win95 computer on the network by default. It's really not that long ago in the greater scale of things but it feels like a different life. Look how far we have come! Which, in the context of this topic, is probably the most pertinent thing I could say.

[catweazel]

As an aside, is coding what was once known as programming? If so, why the change?

Yes, it's the same. I don't use the word "coding" as a verb. I assume that the word is used merely due to geographical vocabulary being different.