Is newer better?

Hi Clem,

I have been involved with computers for a bit longer than you, but you bring up interesting points.

For most applications, the computer advance has produced a lot of amazing gadgets that help many people everyday.

One place I find still lagging is having a simple and intuitive way to program the computer to do what I want.

After all, typing in C code was what I did over forty years ago.  Clearly we can do better.

The same goes for testing software and systems.  Are we still constrained to doing all of the little steps our self?

The same interface that could create the software should easily be able to put only good software into the plan.

After all, how many times do we need to define a pin to a LED and then write the code for using it?

I would say that the hardware has matured much better than the software.  Mostly from the insane language wars.  It just does not matter which is best.  All that matters is that a novice user has the tools to define an idea and have code written so that the device can implement the function.

Just a thought.

DAB

Hi Clem,

I have been involved with computers for a bit longer than you, but you bring up interesting points.

For most applications, the computer advance has produced a lot of amazing gadgets that help many people everyday.

One place I find still lagging is having a simple and intuitive way to program the computer to do what I want.

After all, typing in C code was what I did over forty years ago.  Clearly we can do better.

The same goes for testing software and systems.  Are we still constrained to doing all of the little steps our self?

The same interface that could create the software should easily be able to put only good software into the plan.

After all, how many times do we need to define a pin to a LED and then write the code for using it?

I would say that the hardware has matured much better than the software.  Mostly from the insane language wars.  It just does not matter which is best.  All that matters is that a novice user has the tools to define an idea and have code written so that the device can implement the function.

Just a thought.

DAB

DAB wrote:

 

One place I find still lagging is having a simple and intuitive way to program the computer to do what I want.

After all, typing in C code was what I did over forty years ago.  Clearly we can do better.

 

...

 

I would say that the hardware has matured much better than the software.  Mostly from the insane language wars.  It just does not matter which is best.  All that matters is that a novice user has the tools to define an idea and have code written so that the device can implement the function.

At some point you have to tell the hardware what to do, and that involves some kind of language.  There are graphical languages such as the one used by CodeBug, but from what little I've seen of CodeBug it seems like you can do some simple things very nicely, but when you want to do more sophisticated things you discover the limitations of the graphical language very quickly.

IMO there is no such thing as a "best language".  What's best for one application may be terrible for another.  What's best for one person may be terrible for someone else.  Chacun a son goût.  I find some features of C like its expression syntax to be excellent.  I find other features like its control structures to be ugly, especially things like needing a break statement after each case.  My solution was to create my own languages.  I now use my GalaxC language for almost all my work.  It fits the way I think and express myself.  But this is a personal decision.

Getting back to Clem's "Is Newer Better" question, I would like to note how horribly complex device-level programming has become over the decades I've been doing this.  The first machine for which I did device-level programming was the PDP-11.  The PDP-11 Peripherals Handbook described the device registers for all DEC peripherals that could interface to a PDP-11.  It had a chapter called "Programming" which described how to write typical assembly-language programs to talk to peripherals, using both busy loops and interrupts.  The chapter was 8 pages long.

If you want to device-level programming for Linux or Windows you have to read and understand huge manuals.  You can avoid this by doing "bare metal" programming on microprocessors and microcontrollers, and some of them are pretty easy to grok.  Others require you to find your way through a 2000-page technical reference manual, which may or may not be well-written.

Most of this complexity is because it's easier to slap together complex systems instead of designing something clean and simple.  As CAR Hoare said: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

I agree.

I too started with the PDP-11 and it was fun.

I just think that after fifty years I think we can organize the hardware and software so that others can more easily combine them for applications.

I have watched as people used all of the excuses against code reuse, standardization and to some extent the issues are valid, but we still can do much better at taking the details out of the process.

Yes they may not be as fast or slick, but there are a wealth of potential being lost because it is just too hard to do.

I did not fully realize this issue until my disability took away my ability to organize complex ideas just how much more could be done to simplify the creation of applications.

Think about how many years have passed since we developed parallel processors, and yet we still do not have an effective way to quickly put applications together that can automatically take advantage of the expanded architecture.

I think it is time we took the next step and stop playing with bits and bytes and spend more time on creating useful components that can be simply put together.

DAB

Wow, I got started with assembly language on an 8080 in the late 1970s so I must be the new kid on the block ... it's been a long time since I could say that!

To me the best thing about hardware now compared to then is the level of integration you get it with modern microcontrollers. Something like a Cortex M3 based micro can be fairly easy to do the schematic design for because of the level of integration. Unfortunately they can also be much more complicated to program than the older micros because of all that integration, flexibility and operating modes they have. I try to use micros within the same family and re-use as much of my code as I can, particularly the low level code that deals with the on-chip peripherals. I'll be the first to admit that it is rarely directly re-usable but if it is 90% re-usable and saves me the learning curve with a different device then I'm that much farther ahead.

Where I'm disappointed with the tools is I would love to be able to describe the logic of what I need to do and have the source code generated. This would still make me responsible for the correctness/completeness of the logic but would save a great deal of time in implementing that logic in source code. I tend to write pseudo-C code to work through the logic and then flesh it out with real C source code, it would be wonderful to feed that pseudo code into a tool to produce the source code. That code would obviously need to run on top of some type of hardware abstraction layer to work with a variety of micros for a variety of applications but to me that lower level code is rarely where the really nasty problems are.

Mike