Defining Degrees of Programming....

[AMSDOS]

I was wondering given programming covers a wide scope of languages and degrees of programming if I could come up with a Acronym which might stick - I don't know cause somewhere someone might have done the same thing 

I'm as annoying as Gary Kildall though who created CP/M cause it's debatable what it stands for! 

The mystery term I want for Programmers who have to time their programs just right is:

Spoiler: ShowHide

SHIP - Splitting Hairs In Programming or
SHIP - Serious Hardware In Programming

for those who program like that, might perfer the later! 

[Bryce]

The only programming I do or have done is embedded assembler for micro-controllers and usually for extremely time critical devices (sometimes as low as pico-seconds). In my line of business this is called a "Hard Realtime Program" HARP (Hard = missing a deadline would result in complete system failure). There are also "Firm" (Missing the target would deteriorate the quality of response/data, but not necessarily be considered a system failure) and "Soft" realtime programs for less critical systems. These are officially defined as far as I know.

Bryce.

[AMSDOS]

The only programming I do or have done is embedded assembler for micro-controllers and usually for extremely time critical devices (sometimes as low as pico-seconds). In my line of business this is called a "Hard Realtime Program" HARP (Hard = missing a deadline would result in complete system failure). There are also "Firm" (Missing the target would deteriorate the quality of response/data, but not necessarily be considered a system failure) and "Soft" realtime programs for less critical systems. These are officially defined as far as I know.

Bryce.

So in a specific sense there already is a model for defining a range of programs and how critical they are when they perform. In a sense what I was thinking when I started writing this thread was the different layers one could dive into while using 'x' language, which would then place it into a group. Theoretically it sounds good, but then you might get something which is borderline case.

Languages as some of my old computer books have it grouped into High-Level Languages, Mid-Level Languages & Low Level Languages. We all know though that the Amstrad provides all sorts of tricks in the way languages are managed. High-Level Languages like BASIC can certainly have things like Assembly at the Low Level and Assembly itself can easily be scaled at different levels. Perhaps consider a term like HEAL for "High End Assembly Language" which could be like Assembly utilising the Firmware. Of course people always dispute if "C" is really a Mid-Level Language or a High-Level Language, perhaps since that book came out (in 1983) other Mid-Level Languages have popped up which make "C" look like a High-Level Language! 

It was simply a thought I had in order if some scaling system was adopted people could specify acronyms in the subject title! 

[Bryce]

Well you are kind of mixing the terms there. High Mid and Low Level, refer to the language structure and "distance" from the hardware architecture, whereas Hard, Firm and Soft refer to the realtime performance. As far as hard realtime programming is concerned, usually only low-level languages are used, but it's not just the language you choose that's important, but also the way it's written. For example: If somebody is designing an ABS module that needs to react in hard realtime, then obviously their routines can't be busy doing something else when you slam on the brakes. Whereas if I am designing a TV, it's still realtime (firm in this case) and may even be written in the same language, but a couple of milliseconds delay might be ok if the routine is refreshing the screen instead of reacting to the input from the remote control.

Bryce.

[redbox]

obviously my routines can't be busy doing something else when you slam on the brakes

From now on I shall be thinking of your programming when I slam the brakes and the traction control light flashes on my Beemer 

[Bryce]

In that situation, I think I'd spend more time thinking about what's directly in front of me

And just so that you can sleep easy tonight, I'm not an automotive programmer. I've corrected the misleading grammar above.

Bryce.

[AMSDOS]

Okay I understand the different relationships from what I explained earlier (which was only an example), to what your explaining. In a sense there seems to be a gap inbetween from what I mentioned with High, Mid & Low Languages, which is loosely grouping languages which at best deal with how close they talk to the machine (that's what I thought it was). The way you're defining those processes is based on timing in the hardware which would have to make it all low-level, though fast enough that even a hint of HEAL won't do! 

What I'm on about is grouping languages into Acronyms as ways of defining them.

For example:

CABP - Compiling A BASIC Program
IBP - Interpreted BASIC Program
BAML - BASIC and Machine Language

Or is that stupid?

[Bryce]

Well it's not stupid. It generally describes the type of program it is, but won't necessarily identify the performance of the actual program (although it probably should be a good indication). With that I mean: A good Basic programmer might write a program that runs smoother/faster than my pathetic attempts at Z80 assembler. So although the my program is BAML, the CABP is likely to be faster.
Also, where does it leave other languages? What about Pascal / BCPL etc. I think I would leave the B out of IBP so that they are covered too.

Bryce.

[steve]

What might be more useful would be a system of classification, a series of numerical values indicating -  performance, features, readability, efficiency.

[AMSDOS]

Well it's not stupid. It generally describes the type of program it is, but won't necessarily identify the performance of the actual program (although it probably should be a good indication). With that I mean: A good Basic programmer might write a program that runs smoother/faster than my pathetic attempts at Z80 assembler. So although the my program is BAML, the CABP is likely to be faster.
Also, where does it leave other languages? What about Pascal / BCPL etc. I think I would leave the B out of IBP so that they are covered too.

Bryce.

Ok, maybe I made bad use of the word "Degrees" in the subject line and used "Styles" instead, though the trouble with that is everyone has their own Style when it comes to programming - BASIC programs for instance can take on a different form and still behave the same, in BASIC programming tips thread I've taken some BASIC 1.1 programs and made them BASIC 1.0 compatible for example. I'm unsure I'll be likely to be looking at a Sprite Driver Routine anytime soon all done in BASIC!   

The next bit in the group scheme is where the nightmare begins. Dealing with each Interpreter/Compiler Separately is looking into the accepted styles, performance again would relate possibly to the quality of the program if it were produced from a compiler. True in some instances Interpreted programs can calculate faster than programs done from Compiler through use of Lookup tables as well, a Compilers counter measure would be to calculate using an Array.

I suppose I'm knit picking as to where the line can be drawn cause not every language would allow someone to integrate something like Assembly into it as I found out with one of the Algol Compilers last year, Pascal could also vary with that as well, though some do allow Assembly into the equation as well. I don't know a great deal about BCPL except in one of my books it suggests it's one of the descendants languages which lead to C Language, so I'm guessing it was Compiled or a Interpreted language - BCPL could perhaps be BIP for BCPL Interpreted Program if it was Interpreted or BCP for BCPL Compiled Program - or perhaps that's what their descriping it as a B Compiled Program Language? The other one I've heard of is APL for A Programming Language, though it doesn't quite define what it is cause all we know is it's A Programming Language.

What might be more useful would be a system of classification, a series of numerical values indicating -  performance, features, readability, efficiency.

I think that's where sites like Progopedia come in really handy cause they are grouping the languages into what they are and then it's looking into the specific languages within those groups. Sadly it's still in it's infancy and still needs many of those specific languages to be intergrated into it. I don't think their goal is to only really cater for the new stuff, and I'm sure they aren't covering all the technical aspects of those specific languages, though there's some signs they are dealing with performance & features to a certain degree.

[steve]

 
I think that's where sites like Progopedia come in really handy cause they are grouping the languages into what they are and then it's looking into the specific languages within those groups. Sadly it's still in it's infancy and still needs many of those specific languages to be intergrated into it. I don't think their goal is to only really cater for the new stuff, and I'm sure they aren't covering all the technical aspects of those specific languages, though there's some signs they are dealing with performance & features to a certain degree.

The system I proposed did not classify the language used, but an extra field could be added for that, it was mainly intended to illustrate how well a program did the job for which it was written.

Performance, is a measure of how well it meets real time requirements and even how much faster than real time it is.
Features, self explanatory.
Readability, how easy is it for someone to understand how the program works, so it can be maintained or enhanced.
Efficiency, is a measure of how much processor power, external code(libraries) and memory it uses, this is not measured against any particular processor or system, to give an indication of how possible it might be to port the code to another processor or system.

Additional fields could be

Processor name and minimum speed necessary to execute program at acceptable performance.
Language used.

[Bryce]

It might be of interest to you or someone else here, that Martin Richards, the guy who invented BCPL is still around and has an internet site here: http://www.cl.cam.ac.uk/~mr10/index.html  with some good information about the language, its origins and its uses.

Bryce.

[AMSDOS]

The system I proposed did not classify the language used, but an extra field could be added for that, it was mainly intended to illustrate how well a program did the job for which it was written.

Performance, is a measure of how well it meets real time requirements and even how much faster than real time it is.
Features, self explanatory.
Readability, how easy is it for someone to understand how the program works, so it can be maintained or enhanced.
Efficiency, is a measure of how much processor power, external code(libraries) and memory it uses, this is not measured against any particular processor or system, to give an indication of how possible it might be to port the code to another processor or system.

Additional fields could be

Processor name and minimum speed necessary to execute program at acceptable performance.
Language used.

I'm sorry, but I'm still a little bit confused what this means!    What's troubling me is "Performance" and "Efficiency", Performance could depend on the way a program was written - for example a BASIC program which adopts Spaghetti Programming will ultimately result in something which is worse when compared to a structured program. In efficiency you have external code (libraries) which relates to the software tool. What's bothered me with this, is I'm unsure if there are High-Level Language Compilers for the Amstrad, which will adopt a smart process of working out which segments a program is using and only including the relevant library segments for that - Turbo Pascal 3 is one example of a compiler which whacks in a whopping 7 or 8k Library into a COM File for example. When Borland released TP 4 and later for DOS, because those compilers used Units, all of a sudden EXE files were smaller than their COM file counter parts. 

It might be of interest to you or someone else here, that Martin Richards, the guy who invented BCPL is still around and has an internet site here: http://www.cl.cam.ac.uk/~mr10/index.html  with some good information about the language, its origins and its uses.

Bryce.

Hmm, he seems to be catering for the i386 and above, obviously his language must still serve some purpose cause I always thought C was a successor to it, though there still seemed to be Algol compilers coming out long after Pascal had been around. These days Algol tends to be a forgotten language! 

[steve]

I'm sorry, but I'm still a little bit confused what this means!    What's troubling me is "Performance" and "Efficiency", Performance could depend on the way a program was written - for example a BASIC program which adopts Spaghetti Programming will ultimately result in something which is worse when compared to a structured program. In efficiency you have external code (libraries) which relates to the software tool. What's bothered me with this, is I'm unsure if there are High-Level Language Compilers for the Amstrad, which will adopt a smart process of working out which segments a program is using and only including the relevant library segments for that - Turbo Pascal 3 is one example of a compiler which whacks in a whopping 7 or 8k Library into a COM File for example. When Borland released TP 4 and later for DOS, because those compilers used Units, all of a sudden EXE files were smaller than their COM file counter parts. 
 

Performance is a measure of how quickly the program achieves its specified objectives, Is it fast enough?, does it need to be faster?, does the processor have time spare to do "other things"?, - how it is written could affect the performance, giving it a lower score.
Efficiency is a measure of total program size including libraries, runtime packages, OS call functions, how much memory a program requires and speed, so if a  program uses any other code, that must be taken into account when deciding how efficient it is, it is OK to use external code, but if someone wanted to port a program to another system, they would need to port the extra code as well, It is also intended as a guide to whether programs that might use 10MB ram and an 2Ghz Core I7 processor could (for example), be rewritten to run on an 8 bit machine, if the two programs do the same job within the allotted time (performance), then the 8 bit program would be more efficient.
"Spaghetti code" relates to readability, there are programs that rely on self modifying code to meet their performance targets, this works but reduces readability, I have read that a programmer can return to a program after 6 months and have no idea how their own program works, such programs would have a low readability score.