There are some interesting videos on YouTube by 'Uncle' Bob Martin on how programmers have changed.

In the early days the machines were more expensive than the people so you put experienced staff on the team who understood the problem they were trying to solve.

Now the people are the expensive part so you use cheap people with little or no experience and if possible off shore them.

You use languages that do all the hard memory management for them, generic collections instead of designing the 'right' data structure and frameworks to speed them up. Developers write new versions of the same tools rather than fix or extend the original -- I've seen Java code with four different logging libraries in it.

What really gets my goat is how everyone wants to use the latest, greatest web tools even when they aren't creating a web application, but I guess its what they were taught at University.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

At this point (having proven that I am an obstinate old fool to some) I would like to conclude my grumbling.

I labeled this thread opinionated because I was pretty sure I was going to be questioned about my choices. I certainly do not mean to put anyone - or their hard work - down. If some language or environment suits you - great. If I choose not to use it - even though you think it's wonderful - don't worry about it. I am not trying to convert anyone - and do not wish to be converted. I am happy to listen and maybe learn, but I will also speak out about how I feel.

I just don't want any headaches or unpleasantness in my work with old CPUs. That's all.

An important criterion for me is being able to recreate my development environment even if I take a break of a couple of years. Much of my tooling from a few years ago is gone. Xilinx has gone through two iterations of development tools, wiping out my ability to address low-level map files with tools I wrote. Dealing with non-free software is like that - marketing wants the new version, let's kill the old version. Dealing with free software means sifting through piles of mostly unusable code.

I do not enjoy playing sysadmin, and if maintaining a system starts using up a noticeable percentage of time or require taking days off my work, out it goes. As I get older I trust my intuition about this.

My goal here is to program like it's 1984 - using incredible hardware and avoiding awful (or otherwise impractical - as I see it) software.

And so, I will put on my happy face and try my best not to complain.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The "infrastructure" you're talking about, such as the Python ecosystem, packaging system and pip (or Node/NPM stuff), is no more "inherently flawed" than the standard C tools for the same purposes, and usually far less for most applications. The question in the end is whether you can produce a reliable application on your target platforms using those tools and what the cost of that will be compared to other tools.

For a couple of decades I've been a professional developer producing such applications, and a hobbiest programmer for much longer. Currently, Python is one of the best platforms for doing this. Using that platform doesn't guarantee that you'll produce an application meeting the kind of requirements you're asking for, but it does make it easier, if you know how to use the tools and have the desire to produce a reliable application.

Dismissing tools because you don't know how to use them and haven't seen them used well doesn't make a lot of sense to me. I'd say anybody these days who's trying to produce (relatively) simple command-line applications with a low-level language such as C instead of a higher-level language such as Python would be the one being irresponsible; given skills in both and the same number of hours to build the app you'll without question produce a much higher quality application (with fewer bugs, fewer problems with installs or breakages of installed applications, and fewer problems with differences between platforms) in Python over C.

I expect some people will remain unconvinced; all I can do is suggest spending enough time to learn a higher-level language and its ecosystem and produce an application acting the way you want it to act and with the level of reliability and failure-resistance you want, rather than assuming because other people don't know how to write a reliable application in any language, but they chose Python in which to fail, that Python is worse than C.

_________________
Curt J. Sampson - github.com/0cjs

(This feels a little bit repetitive: let's not argue. There are different viewpoints, different experiences, and different tradeoffs.)

...with many of them working for Microsoft, no doubt.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So now we have "BigEd's Law" ...

Or one way I see it, is that it's a bit like TV channels - the overall quality is proportional to 1/channels ... So when we just had "The BBC" all was well. It went downhill from then on..

(Take this with a pinch of a

Cheers,

-Gordon
(edit to fix the quoting)

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

In other words, every year, half the software engineers start with zero experience. After a short period of time, let's call it T, the amount of experience they have doubles, and continues to double thereafter

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Hmm, 2x zero_experience is ...

According to BigEd's law:

Quality_of_code = 1 / (size_of_code)

Yes, this has something...

You have not lived until you write string handling functions in RPG II on an IBM System/36. Wrote a simple RLE compression program. It ran forever. Rewrote it in S/36 Assembler and it only ran for 2 hours on print files. It bogged the system down so much it was pitiful.

Walter

Am I the only one here that uses Kowalski Assembler/simulator?

Is there some downside to it that I'm missing? I am, probably compared to most here, a novice assembly programmer, so it's possible.

For me, what's not to love!?!

Decent editor.

The real-time help window greatly accelerated my learning curve

The simulator is almost like having a real-time debugger. Super handy.

As for the actual assembler, I'm not sure (I'm a novice) what could differentiate it from others. It either works or out doesn't, right?

I have yet to explore using macros, so perhaps that's where the good and bad are divided.

Am I missing something?

It certainly has its adherents, and as you say, it works!

Two things spring to mind: it's for Windows, and it's a GUI application. So if (for example) I preferred to work on the command line, and don't use Windows, that makes it less attractive to me.

I use it quite a bit. The entire firmware for my POC units was written and assembled in the Kowalski assembler. I periodically use the simulator to test algorithms. It can't simulate the 65C816 (my targeted system) but accurately simulates the 65C02, which is enough for most of my applications.

I don't like Windows and am not a GUI-oriented sort, so I went to the trouble to learn all the keystrokes that control the editor and assembler. Less time with a hand on the mouse means more time to type in code.


The assembler's macro language is quite powerful. I extensively use it to generate 65C816 code, automate data structures, abstract API calls, etc.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If it's not the one you've already been using for all your other code, no, it's not.

Despite what folks here say, assembler syntax is a pretty easy change. On the other hand, if you spent more than an eighth of a second figuring out how to move to another location, nay, if you even had to think about how to move to another location, you're being crippled by that editor. One thinks about where one wants to be, and you are there immediately, without being able to explain what commands you used to get there. That's when you and the editor are one, and why truly efficient programmers dont' use IDEs (or only program in one language with one IDE).

_________________
Curt J. Sampson - github.com/0cjs