Favorite programming language(s)?

If I had to limit my choice to the languages listed in The University of Cambridge's Eureka magazine, on page 21, Volume 29, it lists the SPUDSAC I computer. There it states: "Most programmingis done in Spudsac Tomatocode, which is similar to ordinary language."
That ranks up there with BEDSOCS (a 1970's simulation language that ran on an HP 2100).


It appears that there was a later version written in C that ran on PDP11:

 
First, OO and functional are almost orthogonal concepts, you can perfectly combine them. Nobody ever said OO means mutable objects, for example.

Second, the "classic" OO (which combines object-orientation with a procedural paradigm) already allows to structure your code quite nicely, while not having to abstract from the real machine "too much". You can do OOP in machine code / assembly, if you like. You won't ever find a good way to do functional programming in machine code.

Disclaimer: No judgement whatsoever involved here.
 
I thought OO was the whole raison d'etre of C++; remember "C with classes?" So now it's a functional programming language?

Early C++ where you had to use OO to even do collections was absolutely terrible. Generic programming with templates is much better.

Templates are a purely functional programming language (at compile time), one where there is just one type - types. Still, they are the best you got in C++ to get work done safely.

That is why Lisp is so much better - you have a real, complete language at compile time - Lisp.
 
Would be interesting to see examples where "casting to/from void * is required in C++.

Type erasure. You don't want your template widget to get instantiated into a different type for every thing that it handles, so you store a `void*`. Then when you need to use it you cast it back. This should be safe as it's all done by the compiler which has all of the type information.
 
From type erasure to machine code. I did a very small amount of 6502 on my VIC-20. At university it was Z80 and 6809. As an intern at IBM, 80286 and the IBM proprietary GPU in their ImageAdapter/2 (that was nice). Then not that much asm for quite a long time. In the past few years working on Valgrind I've needed to write and above all read a lot of amd64, x86 and arm64 machine code and a bit of PPC. Haven't bothered much with MIPS. Looking on the horizon is RISC-V.
 
I get most satisfaction by writing in C. Bettering up C++ for graphics programming and for web development I like the direction that JS is going in, especially addition of TypeScript.
Other languages I have looked into hasn't felt right for me in their syntax. I need some level/extent of written code to memorize. Wanted to look into Lua at one point but haven't taken time for it yet. I focus on getting fully customized for C++ and JS before looking into any new.
 
I still write a whole lot of tools for Win32 with Delphi, and even more to interact with Excel using VBA.
Coding is a perishable skill, but I still have my ASM and other libraries.
Even though heavily commented and structured, I read one app I wrote in ASM, scratched my head and wondered WTF was I thinking???
 
The motorola cpu designs, especially 68k, were some of the best available at that time, I studied microprocessor engineering as part of my degree, and all the teaching was motorola-based. They started with 6800 family chips and then progressed to 68k, and they used vmebus a lot. It was a very good engineering platform. It's a long time since I have looked at 68k systems though, which is a shame as I liked working on it. Of course the PC boom started soon after that, and my area of work headed that way.

The secret - to anyone who wrote (guided) IBM [D]OS/3{6,7}0 systems code for sysgen and some drivers for 'odd' 6-bit +parity devices, '69 to '71 - is that not only the system architecture but opcode language is very familiar. I'd not be surprised if Motorola had licenced the codes, or even designs.

After which I went bush, next computer apart from a T.I. SR-52 prog.calc in '74 was a home-made kit Signetics 2650 @2MHz in '78 (2K eeprom, 4K static RAM, later + 2* 8K RAM.

68k assembler... yum :) I did an embedded project using an exormacs dev system once, vme card stuff. So much nicer to work with than the intel junk which was segmented at the time, all that near and far crap.

In '84 3 month $job, genuine Motorola VMEbus box, I heard $10K. Owners were idiots ( or spooks! ) but I had fun.

I still would like a 68060 or such build in modern processes. What would the clock rate be? Like, on GaAs? 68k assembler was one of the first things I learned, and I still like to read it. When messing with a compiler, I check if it can generate 68k code and use that to get familiar with the language. You can read that, not like x86.

Yep.

It seems that the 68k family morphed into ColdFire https://microapl.com/Porting/ColdFire/cf_68k_diffs.html . There is also the FreeScale DragonBall family https://en.wikipedia.org/wiki/Freescale_DragonBall that was based on 68k. I think I remember the PALM handhelds used dragonball cpus. AFAIK the 68k line pretty much diverged and ended with the death of motorola semi.

And I had a Dragon 32 (6809), Oric Atmos, ZX81 (Z80), QL (68008), Tosh MSX (Z80), Jupiter Ace (Z80). The ZX81 was the first computer I actually owned.

I designed a whole medical computer using the 68K on the VME bus. The engineering director had put together what was essentially an IBM PC clone to do the same work but mine was modular in that you could upgrade the processor, memory, IO, attached devices, etc. by just pulling one small half-size card out. It wound up being (now) Bausch & Lomb's top selling product and the architecture is still in use today (in a modern form).

I loved the 68K. I was enamored by National Semiconductor's NS32000, too, but that went nowhere.
Very interesting, it sounds like an impressive piece of work :) Presumably it had pluggable specialised medical instrumentation cards as well. I wonder if you used OS/9? I remember that used to be quite popular (in the UK, anyway) on 68k vmebus systems. If they're still selling it now, it would be interesting to know what 68k-descendent CPU they have used in the current product, presumably it still uses some variant of the 68k core.

The motorola cpu designs, especially 68k, were some of the best available at that time, I studied microprocessor engineering as part of my degree, and all the teaching was motorola-based. They started with 6800 family chips and then progressed to 68k, and they used vmebus a lot. It was a very good engineering platform. It's a long time since I have looked at 68k systems though, which is a shame as I liked working on it. Of course the PC boom started soon after that, and my area of work headed that way.

I remember briefly reading about NS32000, I didn't look at it in any detail though.

Might see you mob one more time, might not. Let's hear it for nostalgia ...
 
Currently I use or play with: C, Go, k, V, Scheme, python, sh
Used or played with: C++, perl, CL, PL/I, tcl, smalltalk, postscript, Fortran, Pascal, Logo, APL, rc
Wished I had used or played with more: Algol68, Haskell, Beta, Prolog, Mesa, Icon, Simula67, Concurrent Pascal, Occam
Never had a strong desire to play with: Java, Cobol, Ruby, D, Scala, nim, j, forth, dart, ocaml, c#
Might use them in future: lua, swift, rust

Of course, my not wanting to play with some languages simply means *I* don't care enough to spend time on them regardless of their other merits (or demerits). There are far too many languages but most languages play in the same field and just minor variations.
 
I've been learning about Common Lisp for a month or so. People often talk about Lisp macros, so I knew about that feature. There are some other novel things about it as well. Here are a few examples:
  • Variables, or "bindings" as they're called, are useful in themselves apart from whatever data they may store.
  • Error handling allows you to define, at the top of the call stack, how exceptions should be handled at the bottom where they occur. I haven't explored this yet.
  • Even though it's a high-level language, the programmer can be very particular about the low-level details such as the bit widths of data and whether functions destructively modify their arguments.
  • It's a compiled language, and yet you can add or update the source code while the executable runs.
This is the video that got me interested in Common Lisp:

View: https://www.youtube.com/watch?v=mbdXeRBbgDM&t=1150s
 
I've been learning about Common Lisp for a month or so. People often talk about Lisp macros, so I knew about that feature. There are some other novel things about it as well. Here are a few examples:
  • Variables, or "bindings" as they're called, are useful in themselves apart from whatever data they may store.
  • Error handling allows you to define, at the top of the call stack, how exceptions should be handled at the bottom where they occur. I haven't explored this yet.
  • Even though it's a high-level language, the programmer can be very particular about the low-level details such as the bit widths of data and whether functions destructively modify their arguments.
  • It's a compiled language, and yet you can add or update the source code while the executable runs.
This is the video that got me interested in Common Lisp:

View: https://www.youtube.com/watch?v=mbdXeRBbgDM&t=1150s

I worked with Chris on his Clasp implementation for a couple years.
 
I just finished a project in ASM: extracting the EXIF data from a JPG header.
Parts of the header are written Big-Endian, making ASM the ideal platform for little-endian conversion.
 
Currently I use or play with: C, Go, k, V, Scheme, python, sh
Used or played with: C++, perl, CL, PL/I, tcl, smalltalk, postscript, Fortran, Pascal, Logo, APL, rc
Wished I had used or played with more: Algol68, Haskell, Beta, Prolog, Mesa, Icon, Simula67, Concurrent Pascal, Occam
Never had a strong desire to play with: Java, Cobol, Ruby, D, Scala, nim, j, forth, dart, ocaml, c#
Might use them in future: lua, swift, rust

Of course, my not wanting to play with some languages simply means *I* don't care enough to spend time on them regardless of their other merits (or demerits). There are far too many languages but most languages play in the same field and just minor variations.
Nim & F# & Sbcl are really interesting. Try it out "hello world".
 
Back
Top