Computer Languages you've used (and loved)

[PeterT]

Looking back over the years, there are many languages I've used and enjoyed.

Trying to list them in chronological order:

High School
APL. Originally using dialup to an IBM mainframe and then we moved to using IP Sharp.
Also some exposure to APL on an IBM 5100 portable computer.
HP basic on an HP 9830A desktop computer

University
PL/1 through a range of subsets; initially SP/k then PL/C using punched cards on an IBM/360 of some variety.
Pascal on LSI-11s using RT-11
More APL on a Burroughs 6700
COBOL
Algol
Macro-11
Lisp
Snobol
Prolog
SPSS
Fortran (various dialects)
C

Working Life
SAS
370 Assembler
Python
Perl
Awk
JCL

[Quoth]

QUBAL
ForTran (Horrible, which is why I avoided BASIC)
SC/MP Assembler (Horrible)
Z80 Assembler (Horrible, because not a Macro Assembler)
Pascal
BASIC (one project on Sinclair Spectrum)
Forth (Test systems)
78HC11 Macro Assembler used to build a Forth-like system
Westinghouse Blockware
Occam
Modula-2 (Really good and able to do concurrency in the Language. Generic Functions, Opaque Modules). It is not a flavour of Pascal.
8051 Assembler (Horrible microcontroller)
Specifications in CHiLL.
Own designed dataflow programmming language entered as a schematic. "Parts List" became modules. "Net List" became task schedule list & I/O table for modules. Implement atomic modules in anything for target CPU. Run time uses an I/O table instead of stack for parameters and returns and a fast Round Robin scheduler. On Z80 use alt register bank for scheduler.
C++
C (MS DOS compiler with horrid bugs).
Lisp & Prolog (Both languages supposedly for AI and pointless)
Java (Some real projects)
VB6 (which used properly isn't much like BASIC) Good for RAD & Prototyping and connection to SQL Servers.
VB.Net -- A failure, a bad version of C#
C#, in really MS version of Java for .Net
8086 Assembler. Stupid CPU, an 8080 on steroids without sane addressing.
Perl (Terrible)
Python (Terrible)
Oberon
PIC assembler
JAL (for PIC micro). Far better than C or BASIC or Assembler for PIC

[BetterRed]

Used in Anger - i.e. got paid to write it, and results were put to use for the intended purpose

Autocoder - Ferranti & KDF9
Algol 60 & 68
Fortran
PL/1
RTL/2
ADA
COBOL
Assemblers - various
RPG (on an LSI-11 )
C
C++

Dabbled with, or used on projects that failed to deliver

Modula-2
Smalltalk
Eiffel
GE Basic
C#

[nana77]

Can I ask how did you learned it? I mean, if you was to get a job that requires a language you didn't used, was you to get it before a job interview? (As I don't think it would be feasible to learn those in 24 hours - despite some books mentions it LOL).

I'd tried the first 4 chapter of C++ by Bjarne Stroustrup, 4 times ( ), not sure if it counts.
Anyway, I'd liked his way to present it, also mentioning that the book doesn't has to be read linear.
There is this article that might be interesting - imho:
http://harmful.cat-v.org/software/c+...it_for_you_all

Interviewer: Yes, but C++ is basically a sound language..
Stroustrup: You really believe that, don’t you? Have you ever sat down and worked on a C++ project? Here’s what happens: First, I’ve put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module. Try pulling that lot together, when you have a hundred or so modules. And as for data hiding. God, I sometimes can’t help laughing when I hear about the problems companies have making their modules talk to each other. I think the word ‘synergistic’ was specially invented to twist the knife in a project manager’s ribs..
Interviewer: I have to say, I’m beginning to be quite appalled at all this. You say you did it to raise programmers' salaries? That’s obscene..
Stroustrup: Not really. Everyone has a choice. I didn’t expect the thing to get so much out of hand. Anyway, I basically succeeded. C++ is dying off now, but programmers still get high salaries - especially those poor devils who have to maintain all this crap. You do realise, it’s impossible to maintain a large C++ software module if you didn’t actually write it?
Interviewer: How come?
Stroustrup: You are out of touch, aren’t you? Remember the typedef?
Interviewer: Yes, of course..
Stroustrup: Remember how long it took to grope through the header files only to find that ‘RoofRaised’ was a double precision number? Well, imagine how long it takes to find all the implicit typedefs in all the Classes in a major project..
Interviewer: So how do you reckon you’ve succeeded?
Stroustrup: Remember the length of the average-sized ‘C’ project? About 6 months. Not nearly long enough for a guy with a wife and kids to earn enough to have a decent standard of living. Take the same project, design it in C++ and what do you get? I’ll tell you. One to two years. Isn’t that great? All that job security, just through one mistake of judgment. And another thing. The universities haven’t been teaching ‘C’ for such a long time, there’s now a shortage of decent ‘C’ programmers. Especially those who know anything about Unix systems programming. How many guys would know what to do with ‘malloc’, when they’ve used ‘new’ all these years - and never bothered to check the return code. In fact, most C++ programmers throw away their return codes. Whatever happened to good ol' ‘-1’? At least you knew you had an error, without bogging the thing down in all that ‘throw’ ‘catch’ ‘try’ stuff..
Interviewer: But, surely, inheritance does save a lot of time?
Stroustrup: Does it? Have you ever noticed the difference between a ‘C’ project plan, and a C++ project plan? The planning stage for a C++ project is three times as long. Precisely to make sure that everything which should be inherited is, and what shouldn’t isn’t. Then, they still get it wrong.. Whoever heard of memory leaks in a ‘C’ program? Now finding them is a major industry. Most companies give up, and send the product out, knowing it leaks like a sieve, simply to avoid the expense of tracking them all down..

I like the fact that on some - also very early - schools there are programming lessons, alongside maths.

[Quoth]

Some places teach a programming language. A few places teach how to program.

Your "interview" is pretty poor satire. Most of the flaws in C++ in 1987 when I was learning it were despite Stroustrup, because they were caused by AT&T's demand for backward compatibility. This resulted in supposed C++ programs that were really C programs with classes, because the code monkeys had learned programming languages and had never learned to program.

The worst 3rd level students I had for PC applications or programming had "done" it at school. The best hadn't had any exposure, so hadn't learned nonsense.

[jbjb]

Various assemblers
BCPL
C
C++
Pascal (both 'standard' and on Apollo Domain/OS, which is (was) a less bondage-and-discipline flavour of Pascal)
Lisp
Prolog
Objective-C
Swift
Go
Awk
Perl
Python (love/hate relationship with this one - I love using it, and used well it's superb for some tasks, but I've seen more terrible code written in Python than pretty much any other language).
Ruby
Basic
Java (though the 'and loved' requirement would disqualify this!)
Javascript
Erlang

No doubt there are a few others that have slipped my mind.

If hardware description languages count:
Verilog
SystemVerilog
VHDL
Ella
Hilo

Plus a few custom-designed languages.

[jbjb]

Originally Posted by Quoth

the code monkeys had learned programming languages and had never learned to program.

The worst 3rd level students I had for PC applications or programming had "done" it at school. The best hadn't had any exposure, so hadn't learned nonsense.

It's a sad truth that most aspiring programmers focus on learning languages rather than programming skills.

Most computer science graduates leave university with no clue about the craft of programming.

[jbjb]

Originally Posted by jbjb

No doubt there are a few others that have slipped my mind.

Also:
Wolfram Language (Mathematica)
Matlab
Lua
Various shell-scripting languages.

[nana77]

Originally Posted by Quoth

Some places teach a programming language. A few places teach how to program.

Your "interview" is pretty poor satire. Most of the flaws in C++ in 1987 when I was learning it were despite Stroustrup, because they were caused by AT&T's demand for backward compatibility. This resulted in supposed C++ programs that were really C programs with classes, because the code monkeys had learned programming languages and had never learned to program.

The worst 3rd level students I had for PC applications or programming had "done" it at school. The best hadn't had any exposure, so hadn't learned nonsense.

Thanks, the link wasn't correct, for the full interview's page..
I'd found it interesting, leastways.

Interviewer: Well, it’s been a few years since you changed the world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing ‘C’ and, the trouble was, they were pretty damn good at it.. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word ‘competent’ - graduates at a phenomenal rate. That’s what caused the problem..
Interviewer: Problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty..
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen..
Interviewer: That’s why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better..
Stroustrup: Exactly. Well, the same happened with ‘C’ programmers..
Interviewer: I see, but what’s the point?
Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought ‘I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things.. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity..
Interviewer: You’re kidding…?
Stroustrup: Not a bit of it. In fact, there was another problem.. Unix was written in ‘C’, which meant that any ‘C’ programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that’s what I used to do..
Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too..
[...]

LOL

Interviewer: I don’t believe you said that….
Stroustrup: Well, it’s been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it’s taken them a lot longer than I thought it would..

[Quoth]

Originally Posted by jbjb

Also:
Wolfram Language (Mathematica)
Matlab
Lua
Various shell-scripting languages.

I'd didn't list HDLs, because although those are "languages" and describe a design, it's not creating a program. That's my objection to Verilog; it looks too much like programming.

Similarly while Javascript is really nothing to do with Java, and that name was Netscape stupidity, it's as much a programming language as Basic or VBA, but straight HTML (or XML) isn't programming, nor is CSS; they are content description and formatting. I guess I'd include actual Postscript (but not the full PDF spec) as a kind of programming language.

A programming language is executed by a defined architecture of "processor" (which could be cogwheels and cams) and as a minimum has:

• A test with jump or skip based on a flag or boolean expression. One state can jump or skip and the other doesn't. If - Then -Else, Case/Select and all kinds of loops (While, Until, For) can be built from that.
• Assignments, which can be the result of a boolean or arithmetic expression.
• Variables
• Literal constants.

Procedures, functions, data types, scalar and vector data, mutexes, co-routines, objects, generic functions etc are higher level abstractions.

Being able to do arithmetic to addresses ought to require a special directive and be limited to a few device drivers or very low level assembler in some very simple microcontrollers that have no high level language.

[jbjb]

Originally Posted by Quoth

I'd didn't list HDLs, because although those are "languages" and describe a design, it's not creating a program.

Technically, probably not programming languages (at least by some definitions), in that they don't (necessarily) produce code to be executed by a computer, but there's much overlap in the skill sets required, and some implementations will blur the boundaries somewhat (e.g. Verilator, which will convert SystemVerilog (and others) to C++).

HDLs do require some different ways of thinking, when compared with normal programming languages (consideration of timing, heavy emphasis on parallelism, and a clear understanding of the hardware that will be generated etc. etc.), but many of the elements of the programming craft are also very relevant to HDLs.

I'd also argue that exposure to HDLs makes a better programmer, even if that programmer never actually designs any hardware. Understanding of the hardware that will run your program is one of the biggest weaknesses of most programmers, in my experience).

That's my objection to Verilog; it looks too much like programming.

Speaking as someone who spent too many years designing chips at gate level, or below ("polygon pushing"), "looking like programming" is a good thing - it raises productivity massively.

I'd argue that, in many ways, HDLs are programming languages, the only difference is that they compile to hardware rather than machine code for some processor or VM.

In terms of the way logic is expressed, I'd say something like SystemVerilog is *more* similar to a traditional programming language like C than something like Prolog is.

Similarly while Javascript is really nothing to do with Java, and that name was Netscape stupidity, it's as much a programming language as Basic or VBA

Agreed. Personally, I have no problem with Javascript (or ECMAScript). Java itself, on the other hand, annoys me enormously (just my opinion!).

A programming language is executed by a defined architecture of "processor" (which could be cogwheels and cams) and as a minimum has:

• A test with jump or skip based on a flag or boolean expression. One state can jump or skip and the other doesn't. If - Then -Else, Case/Select and all kinds of loops (While, Until, For) can be built from that.
• Assignments, which can be the result of a boolean or arithmetic expression.
• Variables
• Literal constants.

Apart from "being executed by a processor", HDLs like SystemVerilog meet all those requirements.

Being able to do arithmetic to addresses ought to require a special directive and be limited to a few device drivers or very low level assembler in some very simple microcontrollers that have no high level language.

Depends what you're writing - if you're writing highly optimised high-performance code (maybe for DSPs, but not necessarily), or OS kernels, or memory management code (will often happen in userland code, not driver-level), or many other scenarios, address arithmetic is entirely appropriate. C has been successful for a reason! Admittedly it can go horribly wrong, but if you know what you're doing it's very powerful, so you just have to be careful about who you allow to do it. (And horrible, dangerous code can be written in any language - there's no C monopoly on that!).

[Quoth]

Originally Posted by jbjb

Depends what you're writing - if you're writing highly optimised high-performance code (maybe for DSPs, but not necessarily), or OS kernels, or memory management code (will often happen in userland code, not driver-level), or many other scenarios, address arithmetic is entirely appropriate. C has been successful for a reason! Admittedly it can go horribly wrong, but if you know what you're doing it's very powerful, so you just have to be careful about who you allow to do it. (And horrible, dangerous code can be written in any language - there's no C monopoly on that!).

No, it's not ever appropriate ever in ordinary applications. The high level language and compiler does it. Yes, obviously the final program execution does address arithmetic.

See also the stupidity of how strings / array bounds* work in most languages and 40 years after this being identified not just as a way programs crash, but a common security exploit there is still stupid programming.

Never mind the stupidity of Bobby Tables exploits in SQL.

https://m.xkcd.com/327/

If you need to do direct address arithmetic outside of a specialist (likely assembler) device driver, for performance, you have a rubbish compiler.


[* Oh such fun to write a VB6 program calling a DLL passing a string. VB6 strings are mysterious. You first have to assign a maximum length string to the VB variable or the DLL goes BANG! A proper VB string has string size at the -1th position of the array, but C, C++ or Modula-2 doesn't know that.]

[jbjb]

Originally Posted by Quoth

No, it's not ever appropriate ever in ordinary applications. The high level language and compiler does it.

Depends on what you mean by "ordinary". If you're talking about basic end-user apps, with no high-performance requirements, then maybe. Some fields will have different definitions of "ordinary", though.

Bear in mind that in C and C++, array indexing *is* memory arithmetic ("a[b]" === *(a+b)").

See also the stupidity of how strings / array bounds* work in most languages and 40 years after this being identified not just as a way programs crash, but a common security exploit there is still stupid programming.

Bounds-checking all array accesses is a serious performance hit in many circumstances.

There will always be stupid programming. One of my particular beefs is how much of current language development is aimed at making it safer for poor programmers, rather than helping expert programmers produce high performance code.

If you need to do direct address arithmetic outside of a specialist (likely assembler) device driver, for performance, you have a rubbish compiler.

No arrays in C or C++ then?

[Sarmat89]

Originally Posted by Quoth

Oh such fun to write a VB6 program calling a DLL passing a string. VB6 strings are mysterious.

Obviously you cannot pass objects of unknown size to C libraries. What's mysterious about that?

[Quoth]

Originally Posted by jbjb

Depends on what you mean by "ordinary". If you're talking about basic end-user apps, with no high-performance requirements, then maybe. Some fields will have different definitions of "ordinary", though.

Bear in mind that in C and C++, array indexing *is* memory arithmetic ("a[b]" === *(a+b)").



Bounds-checking all array accesses is a serious performance hit in many circumstances.

There will always be stupid programming. One of my particular beefs is how much of current language development is aimed at making it safer for poor programmers, rather than helping expert programmers produce high performance code.


No arrays in C or C++ then?

Who are these "expert programmers"? I understand your point and honestly I don't see much worthwhile language development or improvement in teaching in the last 30 years.

Array accessing is NOT user pointer/address arithmetic and can be done safely. You know I meant idiots dereferencing a pointer, doing arithmetic and then using the pointer. So common in 1980s C and total madness.

This is one reason why type-free languages are stupid and languages like Modula-2 that don't allow anonymous array assignments are good. In M2 if you are writing generic functions that are passed an array you can ask what the high limit is.

During development I'd have tested all parameters in any language not allowing sane user defined types. On one C project I found that all most all the already approved functions had bugs by doing that.

Compilers should have a "test" and "production" flag to turn on run time array bound checking and should always static check at compile time.


Worry about improving performance after it's working. #1 is security and #2 is accuracy. Unless you are coding 200 Ms /s DSP or a tiny micro controller managing 1MHz signals, performance is the last thing to worry about. Design anyway and pre-caculating a table outside a loop etc beats bare metal no-guard rail approach.

Also code that makes sense to read even without comments. Terse 1970s style C withy Fortran /Basic style variable names makes no sense with modern compilers. No magic numbers in the code for constants.

Aim to spend more time before coding and less time debugging.