Do platform independence and different paradigms deter newcomers? [closed]

Question

I'm only 18, and as such my initial ventures into programming were the usual 2000s-dominating high-level, paradigm-saturated affairs, complete with obsession with platform independence and 'good' design patterns.

However, I also toyed around with other things. Things like a BBC Micro emulator, GAS and NASM assembly language, and completely UNIX-centric non-portable C code. After playing with these, I came to the conclusion that most of these modern design patterns, 'pure' paradigms, and obsession with platform independence are a real distraction from actually writing fun code. Sure, these things are no doubt important when writing real systems. Yes, coding being 'fun' is probably a minor concern for suits, but isn't the 'fun' factor of coding what drove the best coders around, some of who then did make a lot of money, no doubt pleasing suits?

Being my age, I can't comment on the '80s. Despite that, I'll guess that there was far less debate about language-choice, platform-choice, and programming paradigms on PCs in those days. I know you could get language ROMs for things like the BBC Micro, but didn't everyone just code in BASIC and ASM regardless? I guess there was also wars about 'Spectrum vs C64', but I'll also guess that people in reality got whatever their budget allowed.

As a side note, this is why I don't think the Raspberry Pi will take off. It's not a lack of hardware that's the problem for young people today; it's the wavering stack of complexity to do basic things that were a lot simpler in the olden days. I didn't really miss the dynamic heap and language-level OOP when I was messing around on the BBC emulator, I actually felt a little freed up. Obviously that feeling wouldn't scale for a program of modern proportions, but for a small little game is was more satisfying.

Too Long to Read:

Anyway, this is what epitomizes the point I'm trying to make: from what I remember, you can draw a line on a BBC Micro with one line of code, maybe two. To do the same using C++ with the WinAPI and DirectX is a joke, the same applies to OpenGL and any portable windowing API too, albeit to a lesser extent. Even on stuff like XNA there's considerable framework stuff to sift through to do trivial stuff. Packaging is harder too; from what I gather from the old PCs, you just copied your end-result onto a tape, and let someone else run it on the same platform. Now you have to mess around with endless DLL-incompatbilities, installing missing runtimes, dealing with abstractions that aren't fast enough underneath on certain setups etc.

Has modern trains-of-thought regarding programming made an impenetrable barrier of entry for beginners?

Answer 1

The "impenetrable barrier" is a result of the growing industry/community/ecosystem and the requirements for participating in it meaningfully. It's a social thing, not a technical thing. If you want to do things the way they were in the 80s and 90s, there's nothing stopping you -- just that the end result obviously won't be competitive with modern offerings.

There are plenty of tools for beginners as well. You can get more than 80s or 90s performance drawing using something as easy as HTML5 or Flash or Silverlight.

As far as language choice goes, yeah, there is the theory that too much choice leads to paralysis, and I think that's what you're experiencing. But again, I think that's a psychological thing, not a technical thing. It is daunting to see all the options out there and to choose the right one. After a while, given no better information on the subject, you just have to choose a popular option and have faith in your decision.

Even if you do make the wrong choice, though, it's not as bad as you might think. What you learn when you learn a language is the paradigms -- not the syntax. Imperative languages are all more or less the same, OOP is more or less the same, functional is more or less the same.

So yes, there is a barrier unique to the current state of the art, yes at first sight it is daunting, but no, it's not a barrier that beginners should worry about. Frankly, most software in the 80s and 90s sucked a lot more than it does now, and that was because the whole community was in a sense a community of beginners.

Answer 2

First, there is one important thing to remember: use the correct tool for the job. If you want to do a simple operation once (like renaming a bunch of files according to some logic), you can safely ignore pretty much any rule of programming. Using a small script written in bash (or PowerShell, or Python) is more than enough.

But, if you are writing a big system together with many other programmers, all those things that you could ignore in that one-off tiny application suddenly become incredibly important. And all those rules and practices have things maintainability and correctnes in mind.

That's because your boss doesn't care whether you have fun writing the code, he cares whether your code actually does what it should and it is easy to modify in the future (by yourself or some other programmer). And all those rules strive to achive this. They can make you write boring or difficult code now. But if you follow them, your successor (which very well may be you) will thank you many times.

Another important things is not to follow the rules blindly. They have a reason and you should understand that, because it may not apply for your specific case.

Also, I don't think the barrier created by the rules is impenetrable, it certainly is possible to learn them, even for a newcomer. But you should also keep in mind that as a newcomer, nobody will expect that you know everyhing. But you should have an open mind and be prepared to learn.

Answer 3

Do play around, do have fun, do write bad code and learn from it!

You cannot write platform independent, paradigm-xy-using, well-patterned, well-structured, component-oriented and what-ever-all-these-gurus-say-stuff code from the beginning. You will learn to use these things one by one. Not all of them are well suited for each type of application and not all of them are good.

Answer 4

"most of these modern design patterns, 'pure' paradigms, and obsession with platform independence are a real distraction from actually writing fun code"

True.

If.

By "fun code", you mean code you could never sell and don't expect to support for very long or for very many customers.

Personal projects don't have to be portable. No reason.

If, on the other hand, you want to program professionally, where your product will be supported on many platforms by many people, it's not fun. It's work. That's why we charge money for it.

Answer 5

you can draw a line on a BBC Micro with one line of code, maybe two. To do the same using C++ with the WinAPI and DirectX is a joke, the same applies to OpenGL and any portable windowing API too

Sure, but try writing Skyrim on a BBC Micro - even if it were powerful enough, you'd be spending hundred of man-years just getting to the point where you had a simple terrain.

The point is, abstractions might make it harder to do simple stuff, but as soon as you try to do something complex, that's when the abstractions become useful.

Besides, there are still tools today that let you do simple stuff with few lines of code. If you want to draw shapes and lines, look no further than HTML5's canvas.

Answer 6

This general direction has been bugging me for quite some time as well.

Basically, most modern solutions are big pile of goo, we have 500MB drivers with fancy-pants interfaces, .NET hogs, Install Shield/MSI like setups (see MSVS for bloated example), IM software that eats 500+MB of RAM. And most libraries are super heavy as well.

I think it mostly has to do with marketing. Someone says that the technology is cool, and everyone jumps in without even thinking. Or someone decides that fancy buttons are the single best thing ever (tm), and they offset all the 200MB .NET framework downloads, startup costs and runtime overheads.

There are good examples as well though. See NSIS for example, setup used for Firefox etc. Everything is clean and nice. See WTL, a very compact, lightweight GUI library for Windows development, lovely to see a win app that gets compiled into 32KB or so.

It's just that marketing gets the lazy developers and believing product managers, and the goo keeps marching on...

Answer 7

Yes, to some degree. The barrier is higher because it is harder to code well than to code badly. In ye olden days when kids could experience the wonderment of writing really awful code in "Street" BASIC on their less-than-8 MHz PCs, a lot more people knew how to do a little programming, and a lot more had fun doing so.

However the current software education industry is no longer concerned with educating a literate population (including people who will vote on technology issues) to know a little bit about programming, but rather creating more potential employees who don't create unmaintainable unreusable junk. That just isn't a fun as:

10 LINETO X+RND(200),Y+RND(100) : GOTO 10

...on a slow PC.

Answer 8

I learned to program in the 1980's, first of all in BASIC on a TRS-80 Color Computer. And yes, I'm certain it was vastly more accessible than it is for kids today to get started with things you mention such as C++, WinAPI, DirectX, OpenGL, XNA, etc.

But the thing is, those languages, libraries and frameworks are serious tools for serious business. They have been used to make apps and games that made billions of dollars. They have been used to make the tools used for the most demanding of tasks. They are not the 21st century equivalent of BASIC on a home computer in the 80's.

What is the equivalent? I'm not sure, not having learned to program, nor taught anyone to program, in the last 25 years! Maybe it's an HTML canvas as some people have suggested. Maybe it's Python (wasn't that intended at least partially to be an educational language?). Maybe it's Visual Basic and dragging and dropping a UI layout. But I'm sure it's not jumping straight into hardcore intended-for-serious-professional-development tools and practices.