The only programing language I every developed any expertise in.

I worked with C a little where I had to slightly modify an already written program, but its cryptic syntax was definitely not my cup of tea.
Still think it was an April Fool's joke that ran amuck.

Theworst thing is becoming a master of an obsolete programming language. At one job I became very good programming in "TBOSS", which probably nobody else has heard of. But the work I did with it ran very smoothly.
The really good part is that it did motivate me to seek a better position in a somewhat different field. I moved on, never regretted it, and never looked back.

 

My first real practicle encounter with programming was early 80's working on custom CNC machines who's controller was written in assembly language, since then I have tended towards Assembly, to this day, I prefer now working with Picmicro's and still in assembly!.

 

My first real practicle encounter with programming was early 80's working on custom CNC machines who's controller was written in assembly language, since then I have tended towards Assembly, to this day, I prefer now working with Picmicro's and still in assembly!.

My current preference is still C or C-like coding. I started coding for 8080 and similar processors in assembler back in the late 70s & early 80s for embedded processors as replacements for boards full of TTL devices. This was for military applications and so (allegedly) hush-hush we weren't allowed 3rd-party tools, so there were no high-level tools available to us. We wrote assembler on A3 sheets of specially designed paper with various columns for op code, etc. and someone junior (me) transcribed that to the individual bytes which were then punched to paper tape to feed the EPROM programmer. We had access to a mainframe via a 300bd teletypewriter with tape and punch card reader and writers. I wrote a FORTRAN program to read the ASM code from manually punched cards and create the tape which massively increased throughput, even though some of the old hands said it couldn't be done. Eventually we used an 8085 IIRC with a DEC VT100 terminal and direct connection to the EPROM programmer to do it all locally. I recall the day the local INTEL rep came in to demo a full end-to-end ICE system which was a revelation albeit horribly expensive. Eventually we persuaded management to buy two of them! That introduced me to a mix of C and ASM. Even to this day, though I rarely use assembler, I still occasionally look at the code the compiler generates to see if I can do better (rarely these days, and who needs to anyway?) My current go to processor is the ESP32-S3 or for small jobs the ATtiny/AVR ranges, though recently I've used the Nordic nRF52840 devices on a couple of projects. Did some PIC work for a couple of clients, but never really got into them.

 

C or C-like coding is only cryptic if you want it to be. With experience, it's easy to make embedded code almost self documenting with good use of structures, pointers, enums, unions, descriptive variable names, etc ... that make looking at the code, 'talk' to you about what's happening. A lot of new coders have never had a good, formal data structures class that teaches the brain how to design using data.

 

C or C-like coding is only cryptic if you want it to be.

I don't want it to be.
It just is.

If the random segment of C code below isn't cryptic to those who are not experts in C,
I don't know what is:

// Function to multiply a string (representing a number)
// by an integer
void multiplyString(char num[], int factor) {
int len = strlen(num);
int carry = 0;

for (int i = len - 1; i >= 0; i--) {
int digit = num - '0';
int product = digit * factor + carry;
num = (product % 10) + '0';
carry = product / 10;
}

// Handling the carry by adding digits to the front
// of the number
while (carry) {
for (int i = strlen(num); i >= 0; i--) {
num[i + 1] = num;
}
num[0] = (carry % 10) + '0';
carry /= 10;

 

C or C-like coding is only cryptic if you want it to be. With experience, it's easy to make embedded code almost self documenting with good use of structures, pointers, enums, unions, descriptive variable names, etc ... that make looking at the code, 'talk' to you about what's happening. A lot of new coders have never had a good, formal data structures class that teaches the brain how to design using data.

NO, C language is not "cryptic", but also it is not simple. I got the book and the compliler with all the books that came with that. Learning to do useful stuff iwith"C" will take quite a lot of study end some practice. Like any other language, it does require learning what the words mean, though. And also learning the "grammar and sentence structure. SO, YOU DO NEED TO OPEN THE BOOK!!!
Of course, to those who do not know the language used here., the stuff we use here is quite "cryptic" .
CERTAINLY, cryptic is in the mind of the beholder.

 

cryptic is in the mind of the beholder

Of course.
Egyptian hieroglyphics are cryptic only until you know what the hieroglyphs mean.

But I think you will have to agree the the syntax of C is significantly more cryptic then say Python for example, if you haven't been trained in either language, but know English.

 

The way I see FL working is it uses probabilities rather than absolute values. So instead of 'temp > 50' it's the probability of the temp being in the region of, say, 50 - 75 based on where it last was and it's rate of change versus the probability of being <50 or >75. Then, based on its history it can, over time, tweak those boundaries to accommodate noise, non-linearity, etc. thus removing instability from the system.

I get why you see it that way, but no, those weights are not probabilities. They're degrees of membership in a set, and they embody (classically) the design-choice definition of a value to be used in a rule-based system.
The motivation is that sometimes, a rule-based control scheme *is* reasonable and adequate, but we write our rules to be suitable for Boolean logic -- do we run a fan when some sensor reads too high? OK, then we write something like
#define TOO_HIGHThe original work is due to Lotfi Zadeh, but I came in later during the revival due to mainly Bart Kosko. That time coincided approximately with the revival of neural networks, i.e., the mid-to-late 1980's.

 

"Fuzzy" Logic is a scheme that seems to be a whole lot of "IF, Then" decisions, the goal is for the code to not be so inflexible.
An example:" If the tanklevel is low then run the pump for a while to fill it some." Really, there is a bit more to being serious about fizzy logic, but that is a frequent example.

I concur.

The difference in use cases is just as you said. Fuzzy set memberships take values between 0 and 1, but they aren't probabilities, they're degrees to which some value belongs to some set.

I've done neural networks for a living, and Bart Kosko was reviving fuzzy logic right around the same time that back-propagation was reviving neural nets.

The fuzzy system doesn't produce huge changes in output for small changes in input, nor for small changes in the tuning parameters (set memberships). It rescues our rule-based system, because we'd been close to correct about the form of the rules, but we'll never be happy with any value we set for a hard threshold.

 

I get why you see it that way, but no, those weights are not probabilities. They're degrees of membership in a set, and they embody (classically) the design-choice definition of a value to be used in a rule-based system.

Yes, bad choice of words but I corrected myself later on...

 

I don't want it to be.
It just is.

If the random segment of C code below isn't cryptic to those who are not experts in C,
I don't know what is:

I could rewrite that in any number of languages from FORTRAN to Pascal or even Basic and it will still be cryptic. It's not the language that makes it cryptic it's the whole premise of adding digits to the string to handle the carry from each sub- multiplication. It's just bad code full stop...

 

I could rewrite that in any number of languages from FORTRAN to Pascal or even Basic and it will still be cryptic.

You are missing my point.
It's not the program structure that's cryptic, it's the program syntax.

Edit: Not knowing any of these languages, I'm pretty sure I could better understand what a Fortran or Pascal or Python coded program was doing as comparted to one in C, for which I would understand zip.

 

You are missing my point.
It's not the program structure that's cryptic, it's the program syntax.

Edit: Not knowing any of these languages, I'm pretty sure I could better understand what a Fortran or Pascal or Python coded program was doing as comparted to one in C, for which I would understand zip.

At the risk of going even further off topic.... here's a fixed and working C v the same in Python... and you're telling me you can understand the Python better?

 

I don't want it to be.
It just is.

If the random segment of C code below isn't cryptic to those who are not experts in C,
I don't know what is:

// Function to multiply a string (representing a number)
// by an integer
void multiplyString(char num[], int factor) {
int len = strlen(num);
int carry = 0;

for (int i = len - 1; i >= 0; i--) {
int digit = num - '0';
int product = digit * factor + carry;
num = (product % 10) + '0';
carry = product / 10;
}

// Handling the carry by adding digits to the front
// of the number
while (carry) {
for (int i = strlen(num); i >= 0; i--) {
num[i + 1] = num;
}
num[0] = (carry % 10) + '0';
carry /= 10;

No need to be a expert. Riding a bicycle is cryptic at first because you need to actually think about doing it. C is indeed a simple language for programmers that have ridden a language or two before. It's source code with a manual shift, clutch and no automation, it's not for everyone.

 

you're telling me you can understand the Python better?

Yes.
This


versus this, for example

 

C is indeed a simple language for programmers that have ridden a language or two before

There's the rub.

it's not for everyone

Amen.

 

Yes.
This
View attachment 367611

versus this, for example
View attachment 367612

A programmer sees a lot of unstructured programming slop in the Python versions of code that prevents ASM optimization of the source code. "Code may be slightly easier to read, but it’s at the cost of code being much more annoying to maintain."
The actual execution heart of Python script is written in the C libraries it uses, thank goodness.

 

Personally, while I agree the bit @crutschow picked out is easier, the real nub of the code is more impenetrable in Python because it uses some odd constructs... for example taking the integer part of a text string returns the number represented by the characters... which is fine if you KNOW they are numbers but what if they weren't due to a bug elsewhere.

 

Okay, I think we've sufficiency covered the subject of C.
Obviously it's a very good programming language, once you learn its cryptic syntax.
Not being an experienced programmer, in my short foray into it to modify a program, that was a significant problem for me.

 

My python implementation:

>>> def mult_str(num, fac):
...     num = int(num)
... print(num*fac)
... 
>>> mult_str("1234", 5)
6170