Python becomes the most popular language

[free_electron]

chinese has most (native) speakers in the world.

 i'll stick to english and Basic. It's easily readable,  doesn't need capitalization ; or whitespace and knows when = means "compare" and when "assign".

Any programming language that needs any of the following
- ; for statement termination
- uses whitespace for function grouping
- can't understand when = means assign and when compare ( a problem that was solved in compilers as early as 1963... it's not that hard for the parser to do.)
- looks like a bunch of #$^*(@$(*$%^&(#(&$ (apl , lisp ? anyone)
- is case sensitive

should have all its source, distributables, documentation and anything involved, collected and stored on a data carrier. Said data carrier can then be Widlarized , the remains doused in gasoline and set on fire. The remaining ashes can be entombed in a cubic meter of reinforced concrete , buried 2 meters deep covered in cow dung and have some long lived , slow growing trees planted on top of that. potentially put up a sign that says : here lie the remains of some truly evil programming languages. do not dig em up. enjoy the tree instead.

[brucehoult]

You appear to have an incorrect impression of Lisp.

[Cerebus]

And a rather poor grasp of the capitalisation and punctuation rules of English. One can see why he feels the need to stick to languages that don't have any such subtleties.

[Nominal Animal]

I agree with free_electron.  It's like those eggheads who mix math with letters. Completely unnecessary.

If I need to count more than 23, I can ask my sister to lend me her 19 fingers and toes.  And beyond those, uh, 37, I can ask our kids to help, too.
Nobody need no damn letters when counting, is all I'm saying.

[Vtile]

I was amusing myself reading pros and cons for first few pages Python vs. C.

None mentioned object pascal ..ada was mentioned once. Maybe for a reason, but Pascal is as hated as Python in certain circles and still refuces to die and being as old geezer as C. XD

"University language" which became a suprime hacker (as of nerds and common person) language in age of first PCs as apple OS lang and later Turbopascal, then shifted to corporate systems with Delphi and databases and now is taking foothold on Linux and android with "write once, compile everywhere", philosophy and with option of static linking and standalone executables.

Good, diversity is great. Python is following the route of object pascal, sorry.

Ps. Can't stand the {}, would need US/UK keyboard layout to that.

[brucehoult]

Ps. Can't stand the {}, would need US/UK keyboard layout to that.

No one makes you go through contortions to find { and } on your keyboard -- you can always use ??< and ??> instead.

[Vtile]

Ps. Can't stand the {}, would need US/UK keyboard layout to that.

No one makes you go through contortions to find { and } on your keyboard -- you can always use ??< and ??> instead.

Can not remember such directives, besides even worse.

Why not just..

Const
{ : Begin;
 } : End;

[Nominal Animal]

At this point, I cannot tell who is yanking whose yarn, or even whether yanking someones yarn is a saying.  What next?

[jfiresto]

You appear to have an incorrect impression of Lisp.

On the other hand, an execution trace of a TECO program really does look like line noise - until you have hacked enough TECO. (I learned structured programming and effective commenting rewriting an EMACS in TECO-11. It was a case of sink or swim.)

[free_electron]

And a rather poor grasp of the capitalisation and punctuation rules of English. One can see why he feels the need to stick to languages that don't have any such subtleties.

It's 2022 and we still have editors that don't know where to put a . or capitalize what letter where.
if they can't be arsed to implement that, i can't be arsed to type it. why do we need uppercase/lowercase anyway ? period delineates a sentence. why do we need to fancify it further ? many languages that do not use roman alphabet do not have uppercase/lowercase.
it also doesn't sound different ( it's not like "a" sounds different from "A" ). so why do we need it ? we already have 26 letters. now you create an additional 26 that are only used as first letter of a sentence or for 'I' or honorifics like Mr . The rules controlling when and where are a collection of seemingly arbitrary nonsense.
and it's hell for writing programs. you need case sensitive and case insensitive routines. you need 'massage' user input to trap for all possible CaSeS

The same thing for programming languages that allow writing such beauties as " if x*3 == X = x*2 + X ". you need to read that 27 times before you can figure out what it actually does. such things should be prohibited. Python forces indentation supposedly for legibility. They should have tackled a lot of other things like case sensitivity. especially when programmers all follow different 'styles' some A_Function a_function AFunction aFunction .. every time you use some library you need to find out what style they implemented. ( not just in python. )
ditch that.

Simplify that crap.
and then remove the huge irritations.
when you learned programming : how many times have you been irritated when you found
- some error was cause by using = instead of == ?
- got confused if you need the x , *x or &x when learning pointers ? ( this is the biggest reason programmers are scared of pointers. they can never remember what to use when. get it wrong and all hell breaks loose)

Why do we still keep making new languages that don't solve that ?

addressof something = this   ' something resides at this location
print something ' show the contents
increment addressof something  ( no ++ -- += -= )

[brucehoult]

It's 2022 and we still have editors that don't know where to put a . or capitalize what letter where.
if they can't be arsed to implement that, i can't be arsed to type it. why do we need uppercase/lowercase anyway ? period delineates a sentence. why do we need to fancify it further ? many languages that do not use roman alphabet do not have uppercase/lowercase.
it also doesn't sound different ( it's not like "a" sounds different from "A" ). so why do we need it ? we already have 26 letters.

You might have some finite chance of changing programming languages. You've got zero of changing human languages.

The same thing for programming languages that allow writing such beauties as " if x*3 == X = x*2 + X ". you need to read that 27 times before you can figure out what it actually does. such things should be prohibited.

I'd say two reads is enough, though it's necessary to know what language you're looking at.

It's not Python because Python doesn't allow an "=" in the middle of an expression.

It's not C because C needs () around an if condition.

But, ok, let's pretend you wrote if x*3 == X = x*2 + X. So in that case I'd scan it looking for ",", "=", and "?". There is only "=", so I split the expression there into two parts:

x*3 == X
x*2 + X

In the first part the next lowest priority operator is "==" so it's (x*3) == X which, obviously, produces a boolean result.

We can stop right there, because the left hand side of an assignment must name a location, which can only be done using a name, field selector, or pointer dereference (including array access). So this is for sure illegal in C.

Maybe you meant x*3 == (X = x*2 + X)? This makes sense in C. It's an expression that returns true if and only if x and X start off with the same value, in which case at the end X will be three times its initial value. Otherwise the expression will be false and X will be ... well ... x*2 + X.

All this is rather simple if you studied C rather than just assuming you could look at it and understand it without study.

You could always fully parenthesise it, so you don't have to learn the 15 levels of operator precedence in C:

if (((x*3) == (X = ((x*2) + X)))) ...

But then you can just as easily write it as ...

(if (= (* x 3) (set X (+ (* x 2) X))) ...)

... which is exactly the same number of parens ... count 'em, 6 opening and 6 closing.

But, apparently you don't like Lisp either.

You don't like using and knowing precedence levels, and you don't like parenthesised either. What do you like?

Simplify that crap.
and then remove the huge irritations.
when you learned programming : how many times have you been irritated when you found
- some error was cause by using = instead of == ?

Probably never, as the language I learned in used := and =.

- got confused if you need the x , *x or &x when learning pointers ? ( this is the biggest reason programmers are scared of pointers. they can never remember what to use when. get it wrong and all hell breaks loose)

This isn't a problem of the syntax, it's a problem of the programmer not having a correct mental model of the computer.

That's one reason I believe students should start from assembly language -- and a simple one, not x86.

Why do we still keep making new languages that don't solve that ?

Because the true problem is almost never the syntax.

[mansaxel]

Any programming language that needs any of the following
- ; for statement termination
- uses whitespace for function grouping

Since quite a few definitions of "whitespace" contain newline, (default value of $IFS in POSIX sh comes to mind, as well as the C standard) there is a big honking problem lurking right there;  if you do not like terminating statements with semi-colon, you probably are praising the BASIC et al. convention of newline, which is a whitespace character, at least to us who have given up on punch cards as storage medium.

[PlainName]

It's 2022 and we still have editors that don't know where to put a . or capitalize what letter where.

You should get yourself an editor that works, then, or write one. Would you seriously consider using code in your products that crashes every 2 mins because the compiler is shit? No, it is you that's responsible, not your tools.

You use periods and capitals, proper spacing and paragraphs in order to communicate. Does your kit send out malformed IP packets because you can't be arsed to follow the protocol? No, you make your best effort to follow the guidelines/rules so everyone else has the best chance of realising what you are trying to get across to them.

And quite apart from that, it is in some ways similar to dress - one's first impression tends to stick, and if that impression is of a drooling slob then it's an uphill battle to convince them you are actually an intelligent and nice chap. Why would you want your communications to imply you left school at 13?

[free_electron]

You might have some finite chance of changing programming languages. You've got zero of changing human languages.

i know. I'm just cranky In all seriousness. I Find it weird that text input fields (or even programs. I'm just using the text input field here on the blog as an example) still can not properly capitalize things. They can spellcheck but capitalization is not there. (Neither is removing redundant space(s)or adjust comma position. But they can detect if you and when you make sentences that ramble on and on and where to put breaks... weird.
to give you an idea :  i started typing this reply with the following:

i know. i'm just cranky.

the edit window underlines i'm and suggests me to change to "I'm". But not a peep about "i know" which should technically be "I Know".

how weird...

I'd say two reads is enough, though it's necessary to know what language you're looking at.

And therein lies the rub.

The intent of the example is indeed to assign  x*2 + X to X and then compare X to x*3

just assuming you could look at it and understand it without study.

it should be simple enough so you don't need "study". i like verbosity over terseness. And make things non ambiguous.

You don't like using and knowing precedence levels, and you don't like parenthesised either. What do you like?

Parenthesis and simple things. The above was just an example of how i don't like it.
my ideal language would not allow for such constructions. it would need to be refactored to

b = (a*2) + b   
if a*3 = b ...

notes :
You must write the parenthesis. My language has no operator precedence and executes left to right . i do this to force readability and reduce errors. many times bugs are caused by errors against this precedence.
the IDE's auto indentation prettifies (is that even a word?) it further. The IDE also colorizes variables and keywords . An undefined variable turns red. So you immediately see if you got it wrong or still need to define it.

Right mouse click on an undefined variable shows a pulldown menu-> define in scope , define global , define as function pass-in so you get a local variable in the function , a global variable or a declaration of the variable in the function header.
of course my language doesn't do header files and all functions are global by default. No need for such nonsense as forward declaration. Right click on a variable also allows you to change type easily. there are only two base types : strings ( which are a form of array : array of byte ) and numerals. i will allow to tighten numerals to int8 int16 and so on. but by default a numeral is unlimited in length ( ideally all arithmetic should be BCD arithmetic. so the numbers themselves can be stored into "string of nibbles" )

define x as string  ' gives you a string of bytes. the keyword string is nothing but a shortcut to array of byte
define x as array of byte ' gives you also a string
define x as array of string ' pretty obvious. array is unlimited in length
define x as array of string(5) ' now string is limited in length
define x(3) as array of string(5)
define x(1970 to 2000) as array of string(5)

numbers :

define y as number '  unlimited , float bcd arithmetic packed as array of nibbles
define y as number( ' 8 digits float. this internally occupies 5 bytes.  [sign][8digits][period]
define y as number(8,3) ' 8 digit , 3 digit exponent
define y as integer( ' 8 digit no float

bcd encode nibble :
0..9  :classic numbers
A = negative sign
B = positive sign
C = period (comma)
D = (dead, infinite)
E =exponent
F = fraction

123 is encoded as B123  so requires two bytes: 0xb1 0x23
-123 is A123
123E567 is B123EEB567
-123E-567 is A123EEA567

the encoder treads exponent and mantissa as byte aligned
-12 becomes AA12
-123 is A123
-12E-99 becomes AA12EA99
-12E-9 becomes AA12EEA9

so the non-numerals can repeat to make sure we have an even number of nibbles.
define y as signed (bitcount). if i need a 128 bit number : define x as signed(128)

AD = underflow ( negative infinite)
BD = positive infinite

B1F3 = +1/3
if a result cannot be stored 'exact' it is retained as a fraction so precision is not hampered.

This isn't a problem of the syntax, it's a problem of the programmer not having a correct mental model of the computer.

no, what i meant is remembering what syntax means the contents, the address

i would use addressof or locationof ( or indexof, treat it like an array. your entire memory is a huge array of bytes)

C let's you write things like
int* x;
int *x;
int * x;

These are all interchangeable. Some programmers use one style, other different style. it confuses things.
same thing for declaration grouping. only like types can be grouped

int* x,y;

x is a pointer .. y is not ... that is confusing.
so i would flip that around to
define x as pointer to number
define y as number

if both were intended as pointers you can write
define x,y as pointer to number


anyway. unfortunately i am neither a programmer ( 99% of what i write are so called run-once programs to solve a problem, the rest is tools that are very specific to one field ) nor a good keyboard jockey ( two finger typer)
but it is fun to think about programming languages and try to remove ambiguity and make them more humanly readable.
the ideal language should need no manual other than a list of keywords. the syntax should make the language self documenting with no scope for 'interpretation' or guessing

[Siwastaja]

"i like verbosity over terseness. And make things non ambiguous."

- then goes on to suggest same symbol for assignment and comparison, and make the compiler automatically guess the correct meaning
- suggests whitespace should and shouldn't be important, at the same time

I don't complain about how difficult and wrong scalpels are, because I recognize I have no freaking idea how to perform a surgery. I'm assuming surgeons know how to do their job even if I'm not one.

Part of teamwork is to recognize your own skills and limitations, and let others do work at which you suck.

But arrogance pretty much guarantees you never learn. Thankfully, nothing prevents you from using BASIC. And come up with a pointer syntax that hides the fact you don't understand how computers work. And of course, just use BCD arithmetic!

[Cerebus]

And a rather poor grasp of the capitalisation and punctuation rules of English. One can see why he feels the need to stick to languages that don't have any such subtleties.

It's 2022 and we still have editors that don't know where to put a . or capitalize what letter where.
if they can't be arsed to implement that, i can't be arsed to type it. why do we need uppercase/lowercase anyway ? period delineates a sentence. why do we need to fancify it further ? many languages that do not use roman alphabet do not have uppercase/lowercase.
it also doesn't sound different ( it's not like "a" sounds different from "A" ). so why do we need it ? we already have 26 letters. now you create an additional 26 that are only used as first letter of a sentence or for 'I' or honorifics like Mr . The rules controlling when and where are a collection of seemingly arbitrary nonsense.
and it's hell for writing programs. you need case sensitive and case insensitive routines. you need 'massage' user input to trap for all possible CaSeS

The same thing for programming languages that allow writing such beauties as " if x*3 == X = x*2 + X ". you need to read that 27 times before you can figure out what it actually does. such things should be prohibited. Python forces indentation supposedly for legibility. They should have tackled a lot of other things like case sensitivity. especially when programmers all follow different 'styles' some A_Function a_function AFunction aFunction .. every time you use some library you need to find out what style they implemented. ( not just in python. )
ditch that.

Simplify that crap.
and then remove the huge irritations.
when you learned programming : how many times have you been irritated when you found
- some error was cause by using = instead of == ?
- got confused if you need the x , *x or &x when learning pointers ? ( this is the biggest reason programmers are scared of pointers. they can never remember what to use when. get it wrong and all hell breaks loose)

Why do we still keep making new languages that don't solve that ?

addressof something = this   ' something resides at this location
print something ' show the contents
increment addressof something  ( no ++ -- += -= )

We have all these little conventions in written English to make it able to support clear communication. So that, for instance, one can differentiate between polish and Polish (which contrary to your argument do sound different). Of course if one has failed to put one's thoughts into order first and is merely throwing words at the page, hoping some will stick, then I can see that formalism intended to foster clarity might seem superfluous to one. The argument that a computer editor won't magically divine your intentions and follow the rules for you, or that a minority of human editors (You were ambigious, see.) fail to follow the rules "so why should I" fails ab initio; if you do not understand why this is, I invite you to follow the same logic for looking both ways before crossing a road and see how far it gets you. The most important things about the conventions of English is that they make it easier to parse, demonstrated by how difficult it is to parse what you're trying to say. That reason, if nothing else, is a good enough reason to follow the rules as a courtesy to others, especially in a place where many readers do not have English as a first language.

Programming is hard, no matter what the programming language used. Requiring someone to be able to grasp and follow the formalism of a programming language is a much smaller leap than requiring them to devise a cogent, logical, correct, expression of the algorithm to be executed in the first place. That could be, if one wanted it to be, an argument for making programming languages harder so as to provide a defensive barrier in front of "programming" to protect it from people without the necessary mental agility to formulate problems and algorithms properly before attempting to impose the computerised result on other people by committing "programming". 

Doubtless you're also annoyed at mathematicians using symbology such as \$\int_{0}^{\pi}x^2 \,dx\$ because it has also rules and requires specialist understanding. In both cases this is done to allow clear unambiguous communication with the recipient of that communication, which is a computer and another mathematician respectively. The parsing abilities of computers are highly limited, to Chomsky type-2 grammars for all practical purposes, so programming languages have to be limited to those class of grammars. English is a Chomsky type-0 language and humans, unlike computers, are capable of parsing those grammars, yet still we require rules such as "start a sentence with a capital letter" and "end a sentence with a full stop" to make them easier to parse. Computers need more help in parsing than we do, which is why programming languages have rules designed to limit their grammars to the simpler Chomsky type-2 form. So railing against requirements such as formal separators between statements (even if those formal separators are white space) is pointless because there will be no way to get the computer to parse a language without those formalisms.

If you really care about this there is a way forward for you. Firstly, instead of sitting there squawking "It should be like this" you could first learn to ask questions rather than simply make demands - "Why does it have to be like this?". Then after you've learned why, you could dedicate your life to devising general parsing algorithms for Chomsky type-1 context sensitive languages and once you've created those parsing tools a whole new variety of programming languages become possible. Of course, your work will not be finished, because there will still be the Chomsky type-0 grammars to conquer as well as general artificial intelligence. After achieving which you will have have what I suspect you're really demanding "Do what I want, not what I say, and don't use the fact that you speak a completely different language to me as an excuse.". While one can do that and achieve success with people (by simply adopting the tactic of being morally unprincipled and stronger or better armed than them and shouting louder) it fails in the face of computers' lack of any concepts of pain or mortality.

[free_electron]

make the compiler automatically guess the correct meaning

That is nonsense and you know it ! it can be perfectly clear to the parser . There are many programming languages that have solved this, long ago. Same for the ;
It is not that hard.

when defining a conditional/loop statement ( if, while , until )   = means comparison
when defining a loop (for) : = means range assignment this is a mixed assign/compare
if standalone : assign

example :

if x = 3 then ... ' compare
do ...until x = y ... ' compare
while y = 0 ... ' compare
y=3 ' assign
for x = 4 to 9 ' range definition, preload x to 4(assign), 9 is terminate point (compare).

[Cerebus]

make the compiler automatically guess the correct meaning

That is nonsense and you know it ! it can be perfectly clear to the parser .

OK, show us the parse tree then, if you can.

[free_electron]

We have all these little conventions in written English to make it able to support clear communication. So that, for instance, one can differentiate between polish and Polish (which contrary to your argument do sound different).

The entire WORD sounds different. the p is still the same sound as P ! the 'o' changes infliction.

The argument that a computer editor won't magically divine your intentions and follow the rules for you

conveying someones point of view is always difficult. my gripe is that we have lots of spellcheckers but cleaning up simple things like capitalisation after a period or spaces around a comma are still not implemented.
i gave the example

i know i'm
the edit box underlines "i'm" and suggests capitalization for readability. but it overlooks the "i know" completely. i find that very puzzling. they can flag and solve one conventional error but not the others.

Programming is hard

yes. cause the computer only does as it is told. computers don't make mistakes. So we need to have languages that PREVENT mistakes. simplify, remove, one and one way only to do things.
case sensitivity of code is such an issue. many times i have used some library i found . one coding style capitalizes the first letter of a function, another style capitalizes compound words , yet another uses underscores .
example :
MyFunction
Myfunction
my_function
myfunction

if you use many different libraries that all are made with different 'style' it becomes hell to remember how a function really is named
There are programming languages (PL/1) that solve that. All of the above are the same function. An underscore is considered a 'continuation' character.  Long hex or binary number ? 0xdead_beef . Split a statement across lines ? end it in _

You gave the example of the complex mathematical equation. There are languages that actually allow you to write

Code: [Select]

     2   2
x = a + b



And very complex maths statements including integrals. They use a three line format. So you can do exponentation and fractions. The language was created specifically for people that field experts but not programming experts. ( vector maths, aerospace ). it was used for the space shuttle (HAL/S).
write the equation as a mathematician would write it.
Yes, now we have matlab but i'm talking IBM360. "long ago" ! and compiled towards early 8 and 16 bit processors ( compiled ! not interpreted !). the resulting code could execute on very primitive processors like the CDP1802 (which in itself was originally a contraption made from 74 series ttl ... speaking of which. Have you seen what a Xerox Alto could do ? they had full blown wysiwyg GUI's. that thing is made entirely out of 74xx series TTL chips clocked at MHz)

it's 2022.. where is all this fancy technology ? we have supercomputers in our smartphones that do amazingly complex things. But they can't capitalize text properly. weird...

[/code]

[free_electron]

make the compiler automatically guess the correct meaning

That is nonsense and you know it ! it can be perfectly clear to the parser .

OK, show us the parse tree then, if you can.

Look at the source for a basic compiler. Dates back to 1964. Dont' ask me : I already stated clearly i am not much of a programmer (i did give you the conditions to be followed. up to a real programmer to implement it. not my field of expertise).
But the problem has been solved. A working solution is known to exist and has been implemented in many different compilers and languages. 1964 is over 50 years ago... half a century. we went from vacuum tubes to multi-trillion-transistor ic's in that timespan. but we are still stuck with having to tell this super machine when = means assign and when compare. I find that very weird and annoying. all this compute power but the simplest of things escapes it completely.

[Cerebus]

it's 2022.. where is all this fancy technology ? we have supercomputers in our smartphones that do amazingly complex things. But they can't capitalize text properly. weird...

you seem to be completely incapable of understanding that for a computer to correctly capitalise and or punctuate text written in english one has to be able to parse it first to find the parts of speech that are being used determine what are sentences what are clauses what are parenthetical speech determine the tenses whether they are active passive or imperative or something else entirely determine whether one is speaking of polish or polish one has to determine clauses subordinate clauses differentiate between nouns and verbs and many other things if you disagree and think it can be done mechanically then name an algorithm im not even asking you to say how just name a known method that can correctly parse punctuate and capitalise this wall of undifferentiated text but if you cant then clearly you don't know what youre talking about but still insisting that it can be done while not being able to say how it can be done

[Cerebus]

make the compiler automatically guess the correct meaning

That is nonsense and you know it ! it can be perfectly clear to the parser .

OK, show us the parse tree then, if you can.

Look at the source for a basic compiler. Dates back to 1964. Dont' ask me : I already stated clearly i am not much of a programmer (i did give you the conditions to be followed. up to a real programmer to implement it. not my field of expertise).
But the problem has been solved. A working solution is known to exist and has been implemented in many different compilers and languages. 1964 is over 50 years ago... half a century. we went from vacuum tubes to multi-trillion-transistor ic's in that timespan. but we are still stuck with having to tell this super machine when = means assign and when compare. I find that very weird and annoying. all this compute power but the simplest of things escapes it completely.

So I was right, you're asking for a "do as I say" programming language and insisting it can be done while not knowing how it can be done yet gainsaying those with experience and ability who say "No, it doesn't work like that.".

[SiliconWizard]

And, as Cerebus just showed, how harder it is to read text that has no capitalisation nor punctuation.

It will never cease to amaze me how some people are completely stuck on the "typing" part of programming, which to me is completely irrelevant. If the typing effort, for any (but maybe the most trivial) software project, is significant relative to the rest, then you definitely have a problem, and it's not the language.

[Siwastaja]

free_electron, you are just kidding yourself here. Maybe let the programmers decide what they need, they know best, right?

Let's talk about languages and the difference between assignment and comparison. It's not a limitation of C, because that's exactly how it works in human languages, too. The reason is simple: they are really different things. You can't combine them.

Tarzan's a special case. He can say, "Me Tarzan, you Jane. Tarzan banana. Tarzan sex Jane" and it's easy to figure out if you know Tarzan. But Tarzan can't build an airplane. Language alone limits him.

The difference between comparison and assignment is crucial and no, it can't be reliably deduced from context, unless we are on Tarzan level.

"Get five bananas, then I'll give three to you" is different from "If I have five bananas, I'll give three to you".

But wait, there is this keyword "if". Maybe we can deduce the meaning from context, then?

"Five bananas, three bananas you" vs. "If five bananas, three bananas you". Maybe you can guess the meaning? First one is assignment, the second one is just a status check. Probably?

But no, you really can't, because this makes sense, too:

"If you get five bananas for me, then I'll give three to you."

See? There can be combinations.

And indeed, in C, this is a very usual pattern. Very handy, very recognizable if you know the basics of the language:

Code: [Select]

if( (retval = do_thing()) == 3 )
{
     do_things_with(retval);
}

See? There is an explicit assignment. Then there is comparison. Both are needed. The result of assignment is part of the condition.

You can of course design BASIC, where you add limiting rules and prevent things until you are at Tarzan level.

But that's the reason why modern-day world is pretty much enabled by C (and many other decent languages) and not BASIC.

Any half-decent programmer wants explicit over implicit.

And, quite frankly, I dismiss anyone who throws a tantrum about C's = and == operators. I learned this thing 10 years old and it took me, what, week, no, day? No, not even that. It was immediately obvious after I read it from a book. Don't waste time arguing whether it should be = and ==, or maybe := and =, or something else. This is completely trivial. The key is, these are two completely different things, and require different operators.

Exactly like referencing and dereferencing pointers. If you want pointers, that is. And you want them in a low- or mid level language, because computers do have that concept.

Similarly, I spent no time arguing about the fact that "and" is "und" in German and "och" in Swedish. You can learn this shit! Don't be a Tarzan, grow up, geez.

[dietert1]

Another demonstation of Python:
Go to Google and try to download and install tensorflow AI framework. Instead of spending more than 30 minutes trying that, get and install PyCharm (community version). Get a simple ai example, like from here:
https://github.com/meerstern/STM32F7-DISCO-AI_XOR
Install numpi and tensorflow into PyCharm and you will be training your first KERAS network after 1 or 2 hours! Of course it doesn't make a lot of sense to use that AI with a STM32 machine, but he demonstrates how to do it. Once you have that framework, you are into learning by doing. Amazing!

Regards, Dieter