OT: Programming Languages

My 'best' language is ALGOL. The modern equivalent is PHP which, with a bit of improvement, could be made almost as good as ALGOL

PowerBasic.

Python isn't bad; it looks a lot like Basic, except for the stupid indentation.

Agreed! All the hand-holding of later versions just get in the way.

Jeroen Belleman

What about C++?

C++ is an abberation. It completely misses the point of C, which is basically a language intended to map efficiently to the underlying hardware.

Some features of C++ are handy, but most are completely over the top. Some are downright harmful.

Jeroen Belleman

We want to time the execution of a control algorithm. One way to time it is to run it in a loop maybe 100K times and measure that with a stopwatch. But a very smart compiler might run it once, notice that nothing has changed, and skip the reruns.

It's best to bang a port pin and measure it with an oscilloscope.

We've had FPGA compilers do that sort of thing, optimize out intentional delays. One fix is to XOR signals with a level from a pin that *we* know is always low.

I think that the complexity ratio between C and C++ well exceeds ten.

Have kernel debugger, will travel. Well, now days it's had kernel debugger, would travel.

Yeah. In C, one can declare something to be "volatile", which tells the optimizer that it is not alone, that something invisible may change it.

There were some compilers this treated volatile as friendly advice, versus royal command, but those compilers were soon stamped out. But they do pop up from time to time in new products.

It took a while for compilers to handle mutual-exclusion functions/commands correctly - in most architectures, one must block interrupts for this to work correctly. It's a long story, and is a good reason to work in assembly for that.

Yes.

One would assume that there is a FPGA equivalent to volatile.

Joe Gwinn

Having just got back from a vacation I thought I'd give my input to this before looking into whether it's worthwhile getting back into sinewave oscillators.

When I first did anything serious in c, with Borland c++ 1.0, it became apparent that even if I didn't need any c++ features it was better to use a c++ compiler because I found it harder to write an incorrect program using a c++ compiler than a c compiler. Sure I had to do things like add function prototypes and be more rigorous with type declarations and other things but that helped make sure that my code was correct. And I could do things such as complex j = complex(0,1) and go from there.

Not long after that I learned Java. There are two things I like about Java. Object oriented and threads. Now I could pretty much make my own variable types and I could do class something implements runnable and have it go off and do something while the main program did something else. Much like real hardware can do any number of things in parallel. Ok you can't do operator overloading in Java but who needs that?

If I did need real (digital) hardware I could always get Cypress Warp to turn my VHDL into a 22V10 or other device. Whoever wrote Warp's ability to turn VHDL into hardware must have been a genius. Other (way more expensive) VHDL compilers would just choke on my code.

I haven't touched c for must be at least 20 years by now and I never really got into c++ except as described above.

Now if I need to code anything I'll reach for either php if it needs to be web page oriented or otherwise python.

While I'm sure it can be done, I can't imagine trying to write something like this in c

#Make a copy of the list so we can iterate over iplist and modify outlist. outlist = iplist.copy()

with open(args.blackfile) as cidrs: for ip in iplist: iptocheck = ipaddress.ip_address(ip) cidrs.seek(0) for cidr in cidrs: cidrtocheck = ipaddress.ip_network(cidr.strip()) if iptocheck in cidrtocheck: try: outlist.remove(ip) except ValueError: #Ignore the exception if it's already removed. pass break #No need to keep looking if we found it.

Writing it in python is almost like asking AI to do it (and I have sometimes found online AI code generators useful). You can have it done in a few minutes. I don't see why anyone would think python's indentation is stupid, unless they haven't used it to any real extent or haven't used notepad++

So in my case it's not possible to stick with c because I believe in using the best tool for the job. I left c behind a long time ago.

I'm not saying c shouldn't be used. Not at all. If you need a replacement for assembler then use c because that is what it was designed for.

I forget when I last use assembler. Maybe 68020 about 30 years ago.

These days I'd expect to see megabytes of code compiled from a high level language doing what could be done on a 6502 with a bit of thought.

But thinking is hard, and in any case management will say that the 6502 code isn't portable so can't be used.

Some allow a "keep" attribute to be applied to a gate or whatever. That seems to be a weak suggestion.

The other fix is to design logic that works but is too complex for any compiler to understand and optimize.

John May has come up with a much better sine wave oscillator than yours. It also has more components, and I'm not sure that all of them are strictly necessary. Getting deep enough into the design to be sure where the harmonics are coming from is going to be difficult. I think I'm getting there, but I'm not all that motivated to put in the rest of the work.

One obvious point is that a FET channel isn't a perfect resistor - as the voltage across it rises above zero it starts looking more like a constant current diode (and you can buy FET-based constant current diodes).

In theory, if you added a second harmonic component to the FET gate drive you could make it look like a resistor over a wider range of voltage, if the phasing was close enough to right.

You've also got the point that when there's a voltage drop across the FET channel, it adds to the gate-to-channel voltage (as has been mentioned here) and you can cancel that with an in-phase fundamental component

Pretty much agree.

I prefer to write in what I call "C+", using some of the extra features of C++ but without all the insane template metaprogramming. Classes are useful for structure, and things like std::string and std::map really help simplify the higher-level operations (though it feels dirty knowing that clever one-liner is about to generate 1000's of instructions), but, as said elsewhere, there can be too much magic in other peoples code - that innocuous '}' can end up running yards of code in destructors, and you can't always trust the simple things like '+', as they may have been subverted to do all kinds of stuff.

A C++ purist would choke on my code - std::maps here and

For scripting I like bash (or sh+, to continue the nomenclature), and perl.

"If you're mostly manipulating files, use bash, if you're mostly manipulating the content of files, use perl. If you're tickling the hardware, use C[+] or asm".

I still write a lot of PIC asm, and think anyone who wants to use a HLL on a low-powered mirocontroller with less than 1K of RAM/ROM is an idiot.

javascript is nice for client-side browser code. I tend to write it like C, and won't touch any of the frameworks like node.js though.

I once wrote a FORTH compiler (or interpreter, as some people view it), and a bunch of software using it, for a specific project. A bit too write-only for my liking now.

BASIC-PLUS (the RSTS-E flavour) was my first serious high level language, but I avoided most of the brain damage by already being fluent in machine code (as in typing in the hex) and assembler. Pascal was forced on us at uni, but as a hardware / low level guy it was frustrating the you couldn't really do anything useful with it (I didn't consider writing yet another sort or factorial algorithm "useful").

COBOL sort-of pays my wages, but I couldn't write a word of it. I work on the software emulation of the ancient mainframe architecture that still runs a lot of high-value business applications.

Java, python, ruby, c#, rust and all other the modern s*it can just [go away] as far as I'm concerned - they're all non-solutions to the wrong problems.

Now where's my soldering iron...

Then we're all agreed: C++ is an abomination in the sight of the Lord and the invention of the Devil himself.

Most computing languages originate from programmers wanting to play with programming because solving real-world problems - the things we pay them to do - isn't interesting.

In academia, they need toys and things to argue about so they keep inventing languages. It's like economists who can't say "let the market work, and econ 101 is all anybody needs."

I sat in on one cs class where new languages weren't enough fun, so the prof lectured about compiler compilers, a whole new layer of abstraction.

About 30 years ago, I bought a C compiler from Microsoft. It came in a foot-cube box with thumping great manuals and umpteen discs. What a pile of s*it that turned out to be. It was *riddled* with bugs and the Microsoft 'support' people were as dense as pig s*it and didn't seem to know a thing about the product. But that didn't stop them keeping me tied up on the line racking up charges while they came up with ever more ingenious tactics of trying to cover up how vacuous they really were on the subject. I subsequently migrated to Borland and life got a hell of a lot better, thankfully.

PowerBasic is a fabulous compiler. We did one contest, an array math signal processing thing. I wrote it in PB, another guy in c. Mine ran

I used the obvious FOR loop with subscripts to scan the array. He used pointers.

c is really a PDP-11 assembler. In the early days of PDP-11 programming, everybody was fascinated with using pointers to wander up and down the world, and with pushing stuff onto the stack. It shows in c now.

Ah lex and yacc. Well if you're going to use any kind of compiler/interpreter, someone has to write it.

Does LTSpice originate from designers wanting to play with simulation because putting real parts together isn't interesting?

Managers tend to like simulation because you don't have to get your hands dirty. At least not until the design which worked fine in simulation either doesn't work at all or has some unexpected issue in reality.

The guy who wrote the PDP-11 assembler said that it was really a language processor. We built several cross-assemblers as macros within the PDP-11 assembler, including the 6800, 6802, 6803, and 68332 processors.

Amazingly, Digikey will still sell you a 68332.

It's slow and expensive to make ICs, so it makes sense to simulate first. The ICE in SPICE means "integrated circuit emphasis."

I can run a sim that steps through hundreds or thousands of cases, and run it over a weekend. A silimar set of breadboard tests might take months of hands-on bench work.

And I was never good at nonlinear control theory. Nobody is.

I do breadboard to test parts whose models can't be trusted or when models are unavailable, but we seldom breadboard complex circuits and never breadboard actual products.

I know of one giant organization that defines six iterations of a design, and uses at least that many. It takes them years to finish anything.

There can't be anyone here who doesn't already know that or who hasn't seen that video.

I'm not suggesting you should breadboard everything, that's simply not possible.