Author Topic: Yet another icon stepping away - Guido van Rossum, Python  (Read 12345 times)

0 Members and 1 Guest are viewing this topic.

Offline AntiProtonBoy

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: au
  • I think I passed the Voight-Kampff test.
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #25 on: August 15, 2020, 02:33:44 pm »
I don't like Python's white space indentation, though I do like go's approach...

Most IDEs or advanced text editors with go extensions/plugins run gofmt on saving. Means don't have to spend time pfaffing with white space.
You brought an apple to the table, when we're talking about oranges. Formatting in this case is not inherent to the Go language itself, rather it's a tool that is applied on code, which is basically equivalent to clang-format for C++ or C.
 
The following users thanked this post: newbrain

Offline RenThraysk

  • Regular Contributor
  • *
  • Posts: 107
  • Country: gb
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #26 on: August 15, 2020, 02:49:51 pm »
I don't like Python's white space indentation, though I do like go's approach...

Most IDEs or advanced text editors with go extensions/plugins run gofmt on saving. Means don't have to spend time pfaffing with white space.
You brought an apple to the table, when we're talking about oranges. Formatting in this case is not inherent to the Go language itself, rather it's a tool that is applied on code, which is basically equivalent to clang-format for C++ or C.

You are incorrect. Due to the nature of automatic semicolon insertion, formatting can change the meaning of go code. It probably wasn't intentional, but it does.

For example, https://play.golang.org/p/qHJOMHGooMd

« Last Edit: August 15, 2020, 02:55:33 pm by RenThraysk »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #27 on: August 15, 2020, 06:27:08 pm »
ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow. the CR / CR/LF problem is already bad enough , now we have that shit too.

Can't mix spaces and tabs for leading white space in 3, so it's entirely irrelevant.
yeah , but what if you are stuck on 2.7 because you know. radical incompatibility int he language ( libraries )
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable. any goofy line of code can redefine pi to whatever. Kind of like B.S.Johnson which made a circle where the diameter to circumference ratio is exactly 3. Then again he also is famous for making such things as explosive mixtures containing nothing else but common sand and water , or making a triangle with three right angles.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #28 on: August 17, 2020, 05:38:56 pm »

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )
...

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
...

Older still -  the default IMPLICIT INTEGER(I-N), REAL(A-H,O-Z).

I write it like that, not to imply shouting, but because the code editors of the day were not so good with lower case (eg https://twobithistory.org/2018/06/23/ibm-029-card-punch.html ).

Ooooh, FORTRAN.
 

Online jfiresto

  • Frequent Contributor
  • **
  • Posts: 868
  • Country: de
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #29 on: August 17, 2020, 06:03:27 pm »
...
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable....
Not exactly. You could attach them to a class as read-only properties/descriptors, and get them from an instance. It is probably better to say that everything is a reference, but that is nit-picking until it isn't.
« Last Edit: August 17, 2020, 06:05:04 pm by jfiresto »
-John
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #30 on: August 20, 2020, 11:49:55 am »
...
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable....
Not exactly. You could attach them to a class as read-only properties/descriptors, and get them from an instance. It is probably better to say that everything is a reference, but that is nit-picking until it isn't.
so i have to create an entire class with all associated hoopla ( instance  creation et al ) to do something that could be done using a simple keyword

const pi = 3.17
print pi


class maths_constants
  property get pi
     return 3.17
  end property
end class
print math_constants.pi


this is going the wrong way ... the less keyboard pounding i need to do the better. newer languages are supposed to make it faster and easier. not more cumbersome and elaborate. come to think of it. pi should be a baked-in constant that automatically casts to the precision of the target variable.

double x
x = pi yields 3.17+ 23 more digits
in x
x = pi
x is 3
single x

and languages really need to do away with this notion of integers and floats. there needs to be a uniform numerical type that automatically expands to the highest precision possible. i don't care about the compute time. the compiler can figure out what is the best mapping onto hardware
a= 2 , b =4, c = a+b : compiler would use unsigned integer math
a= 2 , b =4, c = a-b : compiler would use signed integer math.
a= 2 , b =4, c = b-a : compiler would use unsigned integer math since b is larger than a and thus negative number is ruled out.

tTe machine code can examine the contents of the variables , determine if they are signed or unsigned , integer or float , and decide what needs to be done. this can be done in a few instructions
No more shit like 'we tried to stuff a 32 bit number into 16 bits and all went to hell' no more need of cint ,cint16 and other stuff. you would retain those functions so you can cast when it is required for a specific purpose ( like bit twiddling in integers that drive i/o ) but a variable by default should be 'modeless' and the compiler can figure it out. unless i specifically tell it to be of a given type.
and if i tell it to be of a given type then conversion needs to be implicit.

var a,b  'modeless numbers
int x ' hard defined integer
a= 4
b = 3.14
x = a * b

' x containins 13  (4x3.14 was evaluated as float yielding 12.56. cast to integer = 13 ( rounded up )
x = round_down(a*b) . x contains 12

the compilers KNOW the type you gave , so why do yo need conversion functions ? they can figure out exactly what to do.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline ebastler

  • Super Contributor
  • ***
  • Posts: 6851
  • Country: de
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #31 on: August 20, 2020, 12:24:44 pm »
the compilers KNOW the type you gave , so why do yo need conversion functions ? they can figure out exactly what to do.

Explicit type conversion are not meant to help the compiler figure out what to do. They are meant to enable the compiler to check that you knew what you were doing.  8)
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5405
  • Country: us
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #32 on: August 20, 2020, 07:35:33 pm »
Explicit type declarations for much code (small projects, test code, personal code and many others) is kind of like a forced check to make sure your shoelaces are tied.  A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.  If it is code with safety of life consequences it is definitely worth it.  In other cases not so much.  A smart enough compiler could flag instances where the shoelaces seemed to be untied.
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 7061
  • Country: ca
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #33 on: August 20, 2020, 07:57:09 pm »
Explicit type declarations .. A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.

The whole Flir Ex thermal cameras shenanigan became available thanks to  (lack of) that.
Facebook-free life and Rigol-free shack.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #34 on: August 20, 2020, 10:22:41 pm »
Explicit type declarations for much code (small projects, test code, personal code and many others) is kind of like a forced check to make sure your shoelaces are tied.  A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.  If it is code with safety of life consequences it is definitely worth it.  In other cases not so much.  A smart enough compiler could flag instances where the shoelaces seemed to be untied.

semi-Agree. Then can we at least have upward expansion for free ? if there is no risk of loss of data : convert. And can we make a smart IDE that underlines conversions that can go bad ? if, during the coding step you do
int x
float a,b

x = a/b  : put a red squiggle under X. hover mouse and it says : warning : converting float to integer

int x,a,b
x = a/b : red squiggle
x = a\b : no squiggle. this is integer division

That would help a lot. These checks should be easy to implement in visual studio.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5405
  • Country: us
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #35 on: August 21, 2020, 04:57:40 am »
Explicit type declarations .. A good thing, and very important for those new to tying shoelaces.  And would prevent some accidents in even the most experienced shoelace users.  But with real irritation value and real costs associated.

The whole Flir Ex thermal cameras shenanigan became available thanks to  (lack of) that.

Even experienced shoelace users make mistakes.  The question isn't whether checking shoelaces is useful, but under what circumstances the cost is worth it.  Even Flir might feel that over all their code and product lines they might be ahead.  AFAIK there's is no perfect algorithm to evaluate this.  I am really not upset with anyone's answer to this, only upset with those who don't believe there is a question.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #36 on: August 21, 2020, 01:07:35 pm »
Even experienced shoelace users make mistakes.
It's 2020, can we have velcro please ?
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline Mattjd

  • Regular Contributor
  • *
  • Posts: 230
  • Country: us
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #37 on: August 22, 2020, 04:45:30 pm »
I can only hope that van Rossum's decision to step down was driven by larger underlying reasons, and that the argument over this operator was just the final straw. Throwing in the towel over a syntax dispute seems a bit childish, to be frank.

GvR stepped down because of health, age, and because core developers took to social media to complain about the new operator. He didn't like that part, instead of keeping the problem in house they made it public. I wouldn't have liked it either.



Personally, I think the operator is great and fits into python nicely. When you look at code people produce, very often people will write less lines at the cost of computation. The walrus allows people to get away with that, while increasing code speed. I don't get what the big deal is.


If you guys really want to shit a brick go check out PEP 622 for Pattern Matching ... I've got strong mixed feelings for it.

https://www.python.org/dev/peps/pep-0622/


« Last Edit: August 22, 2020, 05:22:12 pm by Mattjd »
 

Offline Mattjd

  • Regular Contributor
  • *
  • Posts: 230
  • Country: us
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #38 on: August 22, 2020, 05:14:49 pm »
...
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable....
Not exactly. You could attach them to a class as read-only properties/descriptors, and get them from an instance. It is probably better to say that everything is a reference, but that is nit-picking until it isn't.
so i have to create an entire class with all associated hoopla ( instance  creation et al ) to do something that could be done using a simple keyword

const pi = 3.17
print pi


class maths_constants
  property get pi
     return 3.17
  end property
end class
print math_constants.pi


this is going the wrong way ... the less keyboard pounding i need to do the better. newer languages are supposed to make it faster and easier. not more cumbersome and elaborate. come to think of it. pi should be a baked-in constant that automatically casts to the precision of the target variable.

double x
x = pi yields 3.17+ 23 more digits
in x
x = pi
x is 3
single x

and languages really need to do away with this notion of integers and floats. there needs to be a uniform numerical type that automatically expands to the highest precision possible. i don't care about the compute time. the compiler can figure out what is the best mapping onto hardware
a= 2 , b =4, c = a+b : compiler would use unsigned integer math
a= 2 , b =4, c = a-b : compiler would use signed integer math.
a= 2 , b =4, c = b-a : compiler would use unsigned integer math since b is larger than a and thus negative number is ruled out.

tTe machine code can examine the contents of the variables , determine if they are signed or unsigned , integer or float , and decide what needs to be done. this can be done in a few instructions
No more shit like 'we tried to stuff a 32 bit number into 16 bits and all went to hell' no more need of cint ,cint16 and other stuff. you would retain those functions so you can cast when it is required for a specific purpose ( like bit twiddling in integers that drive i/o ) but a variable by default should be 'modeless' and the compiler can figure it out. unless i specifically tell it to be of a given type.
and if i tell it to be of a given type then conversion needs to be implicit.

var a,b  'modeless numbers
int x ' hard defined integer
a= 4
b = 3.14
x = a * b

' x containins 13  (4x3.14 was evaluated as float yielding 12.56. cast to integer = 13 ( rounded up )
x = round_down(a*b) . x contains 12

the compilers KNOW the type you gave , so why do yo need conversion functions ? they can figure out exactly what to do.

I think your biggest issue is that you want to able to make things immutable, and python wasn't built with that in mind. Don't like it, then don't use it. Go write your own language.

You want constants? Here you go

Code: [Select]
In [36]: class Unit_Constant(type):
    ...:     _constant = 5
    ...:     _units = "kg"
    ...:     
    ...:     @property
    ...:     def constant(cls):
    ...:         return cls._constant
    ...:         
    ...:     def __add__(cls, other):
    ...:         return cls.constant + other
    ...:     def __str__(cls):
    ...:         return f"{cls.constant} {cls._units}"
    ...:     def __repr__(cls):
    ...:         return str(cls)
    ...:                                                                                                                               

In [37]: def make_constant(value, unit, description):
    ...:     class new_constant(metaclass=Unit_Constant):
    ...:         _constant = value
    ...:         _units = unit
    ...:         __doc__ =  f"""{description}"""
    ...:     return new_constant
    ...:                                                                                                                               
In [38]: pi = make_constant(3.14,"","circumference of circle over diameter")                                                           

In [39]: pi                                                                                                                           
Out[39]: 3.14

In [40]: e = make_constant(2.71828, "", "euler's number")                                                                             

In [41]: e                                                                                                                             
Out[41]: 2.71828

In [42]: g = make_constant(9.764, "m/s^2", "gravitational acceleration")                                                               

In [43]: g                                                                                                                             
Out[43]: 9.764 m/s^2

In[44]: help(pi)

Help on class new_constant in module __main__:

class new_constant(builtins.object)
 |  circumference of circle over diameter
 | 
 |  Data descriptors defined here:
 | 
 |  __dict__
 |      dictionary for instance variables (if defined)
 | 
 |  __weakref__
 |      list of weak references to the object (if defined)




The help() could be made better by explicitly typing out the class for each constant (which really isn't that bad) but with the class factory within that function you at least get the docstring.


Python wasnt written for this, its duck typed, and there is built in type checking because of what the language called generators. Generators generate the elements of an iterable when next() is called on that generator. I.e. instead of hardcoding out a list, you could do a generator expression and only get the items of what would be in that list as you go to access them. This is good because its fast and saves memory. The downside is that generators can only be iterated over only once. So if you wanted to check if some argument you were passing to a function was a generator, you would then expend that generator by checking it.

Its all a trade off. Don't like the features of the language and what it was written for? THEN DONT USE IT. Theres plenty of other languages.

By the sounds of all your complaining what you want is a statically typed language. Python is dynamically typed.
« Last Edit: August 22, 2020, 05:29:43 pm by Mattjd »
 

Offline Mattjd

  • Regular Contributor
  • *
  • Posts: 230
  • Country: us
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #39 on: August 22, 2020, 05:20:29 pm »
Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

A perfect language for one group will never be the perfect language for the other.

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )


Why is it so hard to discriminate when  = means 'assign' and when it means 'compare' ?
When used in conjunction with an 'if' clause : comparison , anything else : assignment. is it really that hard to figure out for a compiler ?
The same thing with semicolons. At the end of the line of code there is a CR/LF ( or LF if you are on oonix ) in the source file. There is your bloody line ending and end of statement. if, and only if, it is so long  you really must spread it over multiple lines , use a continuation character. The number of times a command needs to be split over mulitple lines is far less than single line , so it saves keyboard hammering. besides, if your statement realyl is that long : maybe split it in a few simpler statements ? A book is made from many sentences. Not just one long sentence. If you want to keep it simple and approach a wide audience : use short sentences.

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
c = a+b ' since the compiler knows the type of a and b it will resolve to float
d = int(c)   ' the int operator always returns an integer so cast d as integer.
d = 5.0 ' throw an error . i goofed up .
b = b and &hff ' throw an error b is a float
d = int(b) and &hff ' works

for all i care you can have two operators : toint and tofloat

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.


You really think this is clear?

Code: [Select]
A = 1;
B = 0;
C = A = B;

Sure, a compiler could be written to understand, but to the programmer, and other programmers reading it? = having two meanings is clear? Because it honestly looks like the person is assigning B to C. Not assigning whether A equals B to C.
 

Offline Mattjd

  • Regular Contributor
  • *
  • Posts: 230
  • Country: us
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #40 on: August 22, 2020, 05:24:04 pm »
ok. but here is the problem : how many spaces is a tab ? and do all operating systems / editors use the same convention ? THAT is the misery with using whitespace for code flow. the CR / CR/LF problem is already bad enough , now we have that shit too.

Can't mix spaces and tabs for leading white space in 3, so it's entirely irrelevant.
yeah , but what if you are stuck on 2.7 because you know. radical incompatibility int he language ( libraries )
and when are we getting constants ? It is absolutely moronic not to have immutable constants like pi , e and other special numbers. everything is variable. any goofy line of code can redefine pi to whatever. Kind of like B.S.Johnson which made a circle where the diameter to circumference ratio is exactly 3. Then again he also is famous for making such things as explosive mixtures containing nothing else but common sand and water , or making a triangle with three right angles.

Python 2.7 isn't even supported as of 2020 iirc, time to move on. The issue was realized and addressed.
 

Offline 0culus

  • Super Contributor
  • ***
  • Posts: 3032
  • Country: us
  • Electronics, RF, and TEA Hobbyist
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #41 on: August 23, 2020, 12:18:28 am »
Create a new language.
One that isn't boneheaded and does not bank on whitespace for flow control.
One that does has a parser that understands when = is an assignment and when it is a comparison.
One that doesn't need every line to be ended in a semicolon, but uses a continuation character when needed.
One that doesn't smell like C, C++ or c# or Java or quiche-eaters pascal and its derivatives.
One that doesn't look like a bunch of cryptical mathematical equations
One that is easy to understand, uses simple english keywords.

something along these lines

a = 12
b= 14
c= b-a
for x = a to b
   c = c^x
  print a,b,x,c
next x


- simple english with a small vocabulary of keywords
- smart compiler that understands syntax and knows when to assign and when to compare. no need for walrus operators or == and other shenanigans
- smart code environment that uses autocompleteand puts the closing quotes around strings and fixes many speeelling errors
- interactive debugger that lets you singlestep through a program , examine data , add or remove instructions and rerun sections of code. No continuous code, attempt to compile, fix typing errors , missing brackets and semicolons , run , crash and not know where or why or even able to see or save the data. Fire up the program. if a mistake is encountered the program stops without loss of data. the debugger tells yu the most likely cause, lets you fix the source and then attempt to continue the run with the fix in place. while in debug you can execute code interactively , examine and alter data contents and even dump the current state of program and data to disk so it can be examined later without having to rerun the entire shebang. the entire machine state, data and all, can be saved.

I'm thinking to call it something along the lines of 'Ultima' or maybe something simple and basic... like 'Basic'.

Here is one of the reasons there have been so many languages over the years.  Free electron is speaking as a user - someone who just wants to get something done.

Strongly typed languages, variable declarations, semicolon line endings, walrus operators and the like are the desires of someone who wants to make the compiler easier to write, easier (perhaps possible) to prove that the generated output represents the commands of the input.

A perfect language for one group will never be the perfect language for the other.

finally someone who understands my point of view. ( as opposed to bashing a language like 'basic' )


Why is it so hard to discriminate when  = means 'assign' and when it means 'compare' ?
When used in conjunction with an 'if' clause : comparison , anything else : assignment. is it really that hard to figure out for a compiler ?
The same thing with semicolons. At the end of the line of code there is a CR/LF ( or LF if you are on oonix ) in the source file. There is your bloody line ending and end of statement. if, and only if, it is so long  you really must spread it over multiple lines , use a continuation character. The number of times a command needs to be split over mulitple lines is far less than single line , so it saves keyboard hammering. besides, if your statement realyl is that long : maybe split it in a few simpler statements ? A book is made from many sentences. Not just one long sentence. If you want to keep it simple and approach a wide audience : use short sentences.

Basic used to have the 'LET' keyword to make assignments. Then they figured out there was no need for it because the compiler can figure it out. (historical note : BASIC is several years OLDER than C. If it could already do that that makes C a piss-poor compiler.
Same thing with creating variables. Why do i need to create a variable ?
a=4
tells the compiler create something called 'a' and stuff the number 5 in it
since computers discriminate between integers and floats we can use a modifier to 'cast' , but even then there should be no need.

a=5  ' a is integer
b = 5.0 ' a is float
c = a+b ' since the compiler knows the type of a and b it will resolve to float
d = int(c)   ' the int operator always returns an integer so cast d as integer.
d = 5.0 ' throw an error . i goofed up .
b = b and &hff ' throw an error b is a float
d = int(b) and &hff ' works

for all i care you can have two operators : toint and tofloat

It is 2020 . The compilers should be able to figure these things out without us humans needing to spoonfeed them each and every time.

OK, then come up with a compiler that can take a natural language as input, make perfect sense of it, and give you an executable. That's essentially what you're asking for. All the programming languages that I know of are operating somewhere on the Chomsky hierarchy. Wolfram Alpha sort of tries to break this barrier, but I've found that you still have to be very specific about parentheses and how you arrange things when feeding it something non-trivial.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #42 on: August 23, 2020, 05:52:58 pm »
You really think this is clear?

Code: [Select]
A = 1;
B = 0;
C = A = B;


my language would prohibit that kind of nonsense. that is bad programming . just like in c 'for' statements  with all their trickery. bad ! it is unreadable.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #43 on: August 23, 2020, 06:00:36 pm »
you still have to be very specific about parentheses and how you arrange things when feeding it something non-trivial.

parenthesis are good !. i like parenthesis. Mainly cause i hate having to figure out what things like this result to :
x = a + b * c - d /e + f

x = ((a+b) * (c-d)) / (e+f).  There. now it's clear.
 There is a programming language where you can write this actually as

x = (a+b) * (c-d)
         ________             <- underscore(s) . one or many , doesn't matter it means 'divide'
           (e+f)

Why ? because this guarantees that there is no bone headed mistakes in critical maths .
Where ? Space Shuttle flight control software. HAL/S
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline 0culus

  • Super Contributor
  • ***
  • Posts: 3032
  • Country: us
  • Electronics, RF, and TEA Hobbyist
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #44 on: August 24, 2020, 09:24:29 pm »
you still have to be very specific about parentheses and how you arrange things when feeding it something non-trivial.

parenthesis are good !. i like parenthesis. Mainly cause i hate having to figure out what things like this result to :
x = a + b * c - d /e + f

x = ((a+b) * (c-d)) / (e+f).  There. now it's clear.
 There is a programming language where you can write this actually as

x = (a+b) * (c-d)
         ________             <- underscore(s) . one or many , doesn't matter it means 'divide'
           (e+f)

Why ? because this guarantees that there is no bone headed mistakes in critical maths .
Where ? Space Shuttle flight control software. HAL/S

What?

Clearly, by the well known rules of operator precedence and associativity which most programming languages use

\$x = a + b \cdot c - d / e + f \$

is in no way the same expression as

\$x = ((a+b) \cdot (c-d)) / (e+f)\,.\$

You're just using parentheses to override the standard rules of precedence to make a different expression. There is no ambiguity here. Also, using formal language theory as your underpinning also allows your programs to be evaluated using formal methods...which goes towards the space shuttle software. The idea is the eliminate ambiguity; to do that you have to lose the subtleties of natural language. If you can't handle that, it's on you.
 

Offline boffin

  • Supporter
  • ****
  • Posts: 1027
  • Country: ca
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #45 on: August 24, 2020, 09:54:33 pm »
You really think this is clear?

Code: [Select]
A = 1;
B = 0;
C = A = B;

my language would prohibit that kind of nonsense. that is bad programming . just like in c 'for' statements  with all their trickery. bad ! it is unreadable.

How about using something else for assignment, like  perhaps :=

A := B + 1;

There were a lot of good ideas in Algol/Pascal.  It's a shame that people went to C for anything other than OS level stuff.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #46 on: August 24, 2020, 11:15:04 pm »
Clearly, by the well known rules of operator precedence and associativity which most programming languages use

\$x = a + b \cdot c - d / e + f \$

is in no way the same expression as

\$x = ((a+b) \cdot (c-d)) / (e+f)\,.\$

You're just using parentheses to override the standard rules of precedence to make a different expression.
of course i'm doing that, to make my point ! it takes time to figure out what is written there. And do your programming languages also take into account things like sqrt  and "power of" when evaluating operator precedence ?
How about stupid mistakes when coding this simple formula :
Code: [Select]
         a
x =  ------
       b x c

how do you code this ?
Code: [Select]
x = a + b - c
are you certain it works correctly both on signed and unsigned numbers ? what if c is negative ? or b is negative ?
what if i do this :
x = a - b + c

What is the result of 5 + 3 -2 -9 *8 +2 * 3 / 5 + 2 ? . let the guesswork begin ...

go read this and panic :
https://en.wikipedia.org/wiki/Order_of_operations

excel does it different from wolfram or matlab of google.

x = -3^2 is what ? -9 or 9 ? depends on the programming language  -(3^2)  or (-3)^2 ...
it gets worse : do this x = 0-3^2  and the parser produces the opposite !

That kind of stupidity needs to stop. Use the goddamn brackets. Even fucking calculators get it wrong !
Code should evaluate left to right. There is no other order than left to right , except where explicitly stated by using brackets.
Many times complex formulas get coded wrong by people who think they are expert in operator precedence and 'brackets are for wussies'

Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline 0culus

  • Super Contributor
  • ***
  • Posts: 3032
  • Country: us
  • Electronics, RF, and TEA Hobbyist
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #47 on: August 25, 2020, 02:30:20 am »
RTFM?

Really, I don't see what the problem is. If you're writing C, you refer to C's rules for precedence and associativity and write your expressions accordingly. Writing Python? Refer to the documentation and figure out what the rules are. Doesn't really matter if they are "wrong" as long as you follow the rules.

If you want to invent your own language that does what you want, that's fine, but just know that attempting the create a grand unifying standard is always a fool's errand.


 
The following users thanked this post: newbrain

Offline TK

  • Super Contributor
  • ***
  • Posts: 1722
  • Country: us
  • I am a Systems Analyst who plays with Electronics
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #48 on: August 25, 2020, 02:56:00 am »
We have for(int a=0; a<10; a++) in C/C++ for 20 years, move on.
Actually almost 50 years
 
The following users thanked this post: boffin

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: Yet another icon stepping away - Guido van Rossum, Python
« Reply #49 on: August 25, 2020, 12:20:13 pm »
RTFM?

Really, I don't see what the problem is. If you're writing C, you refer to C's rules for precedence and associativity and write your expressions accordingly. Writing Python? Refer to the documentation and figure out what the rules are. Doesn't really matter if they are "wrong" as long as you follow the rules.
what if the rules change per language ( it does) , bloody annoying ...
what if it depends on the compiler !

i always use brackets. leave nothing to some quirck.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf