Programming language discussions

I have shared most of the ideas that I am working on in this forum. Feel free to make whatever use of them that you can dream of.

It’s true that a working github lowers the barrier to using the ideas but I think that a lot of people will be put off by my straight C/Perl based explorations anyway. I really love pointers - you may not feel that way. If you have ever spent much time in assembly language $_ makes a great deal of sense. If you have not it may cause you to throw your laptop across the room.

I feel the same way about the python solutions that are common here.

BTW: I really thought that making white space matter was dead with cobol/fortran/RPG and that I would never every have to deal with that crud again; silly me.


Perl you say? Unfortunately I learned the standard CLI text tools, then Python, before I ever looked at Perl seriously. But I’m jealous of folks who are fluent in that language. Maybe I’ll circle back to it at a later time. I’ve had to debug and fix code written by others using Perl, but can’t at this moment produce anything really usable.

I love pointers, and the whole idea of passing references rather than data used in real-time systems. They have a place, and forced immutability (such as in Go, for example), while I get the arguments, is a little annoying. For assembly, I’ve played with programming an arduino “blink” program using embedded ‘asm’ in c++. I like the raw control of pulling all the levers of the machine, and I’m a fan of this dude here, who created a tutorial series on designing a breadboard computer using a First Principles approach, and have been enjoying the NAND-to-Tetris content.

And I’m sometimes with you on the whole whitespace thing, especially when jumping in and out of different remote systems that don’t always treat white space or line endings consistently. The Python interpreter’s pre-parser is usually pretty specific though about where you have sinned, which tends to make it more of a minor annoyance as long as indentation style has been mostly consistent throughout a module. It’s just hard to compete with the ease and speed of writing web-based APIs with Python. Most frameworks make it so that you just define your function logic, then add a decorator to specify its route, what connection type and requests it takes, then boom. API is done.

So if you haven’t done so, I’d love to see yours and anybody else’s fugly code. I’m language agnostic at the end of the day. It’s the ideas behind the code that matter to me, not the specific language used to do it. Not sharing, having all the work, time, and energy just expire without a meaningful trace, is depressing to me… and I suspect due to the anti-social nature of geniuses, it probably happens too frequently. I assert the world is worse off for it too.


Do you have, or can you point, me to a open source Linux C program that can convert a
wav file to a spectrogram?

I use audacity for that; why reinvent the wheel?

Odd that you should ask - I actually did a spectrum plot today.
We were trying to nail down a random sound coming out of a machine to know what frequency to look for.

Here is your spectrogram feature:

The front page of audacity:

I did a fast google with your question …
Google: open source C code spectrogram

… and this is one of the first hits:

Thank you @bitKing.

1 Like

That was my initial reaction too. But having been forced to use python due to its popularity in the data/analytics space, I soon got past that and it’s second nature now. The best way is to outsource white space formatting to your IDE (I use PyCharm).

I’ve never been able to enjoy R though. It may have good statistical libraries but I find it a very jarring experience as a developer.

Since I don’t have to use white-space to replace curly braces I can use white-space to communicate intent:

		if ((rbuffer[3]=='I') ||
			(rbuffer[3]=='p') ||
			(rbuffer[3]=='R') ||
			(rbuffer[3]=='S') ||
			(rbuffer[3]=='T') ||
			(rbuffer[3]=='U') ||
			(rbuffer[3]=='o') ||
			(rbuffer[3]=='t') ||
			(rbuffer[3]=='q') ||

Sorry, you can’t have this format - that’s not the “correct” way to do case statements:

switch(numcells){					//clear any errors outside of numcells range
case 1: cellerror &= 0x01;break;
case 2: cellerror &= 0x03;break;
case 3: cellerror &= 0x07;break;
case 4: cellerror &= 0x0F;break;
case 5: cellerror &= 0x1F;break;
case 6: cellerror &= 0x3F;break;
case 7: cellerror &= 0x7F;break;

How about this? Nope.

if (displayRAM[5] & (1<<6))  segmentRAM |= (1<<1);		//GROSS
if (displayRAM[7] & (1<<5))  segmentRAM |= (1<<2);		//BIN (previosly PCS)
if (displayRAM[6] & (1<<7))  segmentRAM |= (1<<3);		//kg
if (displayRAM[5] & (1<<1))  segmentRAM |= (1<<4);		//lb
if (displayRAM[6] & (1<<6))  segmentRAM |= (1<<5);		//LOAD/UNLOAD (previously PEAK)
if (displayRAM[8] & (1<<6))  segmentRAM |= (1<<6);		//TOTAL

Before you whine about defining the bit positions with define statements, my electronics engineer on this project wanted to see the bit positions clearly called out in the code that manipulated the hardware. Some twaddle about making his debugging easier.

1 Like

Its not so bad, i like it better than brackets like {[]{}(([}]])))). I use tab=4spaces and with my experience I can just “see” where the blocks of code are and how they nest. Also in python the best way to make large case statements is with a dictionary which maps from [key/condition]->callable. Large case statements in python tend to require a more verbose and organised approach than the casual C style permits.