Python becomes the most popular language

[PKTKS]

... Btw. Python lack of closures sucks..

Did you mean to write anonymous code blocks?

Python has had (late-binding) closures for many, many years, and since Python 3, generalized setting of up values.

No..   I mean the plain and simple  use of SPACES  instead of closures  for programming..

You see...  any serious programmer will clash that stupid waste of time counting spaces and dealing with pathetic identation...

Newbies can think of this as something cool...   serious folks obviously will damn that pathetic thing..

GOTO labels still  are  -  and they have always been  -  a  very important thing..
You came from ASM step to PASCAL ... and deep serious C ...

Python is pathetic..

OK is is popular...

BUT! give a break on that...

Folks  considering  NUMERIC METHODS...  please CHECK  https://pdl.perl.org/
in the sequence go https://www.cpan.org

It is just some orders of magnitude better than numpy

Some time ago a similar issue with octave x other tools..
here

https://www.eevblog.com/forum/programming/gnu-octave-math-programming/msg3365980/#msg3365980

It just happens that PDL can overtake most of the tools out there..

PERL is a substantially better language to deal with..  it just takes time to master..

Paul

[Cerebus]

Throw some proper language in...

Code: [Select]

package main

import (
"fmt"
)

func main() {
n := 0
for i := 0; i < 100000000; i++ {
n += i
}
fmt.Println(n)
}

Compile to native arm64 / run cycle

Code: [Select]

scratch % time go run loop.go
4999999950000000
go run loop.go  0.15s user 0.12s system 94% cpu 0.284 total

Compile to native arm64 then run again

Code: [Select]

scratch % go build loop.go
scratch % time ./loop     
4999999950000000
./loop  0.06s user 0.00s system 47% cpu 0.130 total

Target

Code: [Select]

scratch % uname -a
Darwin anubis 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000 arm64

This is actually easier to write (thanks to VScode), typed so far far far easier to rationalise bits, fast compile, fast execution, builds zero dependency native binaries for any platform from any platform. Everything else can bugger off 

The problem is that go suffers from the same evil that python does, significant white space. 

cerebus@shu:~/Desktop$ cat hello.go 
package main

import "fmt"

func main() 
{
    fmt.Println("Hello, World!");
}

cerebus@shu:~/Desktop$ go run hello.go
# command-line-arguments
./hello.go:5:6: missing function body
./hello.go:6:1: syntax error: unexpected semicolon or newline before {

[bd139]

Incorrect. It enforces standard formatting. Semantically different. If you use an IDE it does that up front.

Edit: software engineers have long given up the right to not have their formatting enforced by the compiler from experience. I had 200 different opinions recently on that.

[jfiresto]

... Btw. Python lack of closures sucks..

Did you mean to write anonymous code blocks?

Python has had (late-binding) closures for many, many years, and since Python 3, generalized setting of up values.

No..   I mean the plain and simple  use of SPACES instead of closures [visible code-block begin/end tokens?]  for programming..

You see...  any serious programmer will clash that stupid waste of time counting spaces and dealing with pathetic indentation....

[My aside above.]

A language with a plain and simple way to mark code blocks? Yes, please – sign me up for that! Python is not the first language to make indentation significant, so there have long been effective tools to support that if not make life pleasant (e.g., EMACS).

[Picuino]

I have hardly had any problems with indentation and when it has ever appeared in a program, the error message from the interpreter has been obvious.
I think it's a made-up problem. I always program with correct indentation, regardless of whether the program is Python, C or other.

[bd139]

I have hardly had any problems with indentation and when it has ever appeared in a program, the error message from the interpreter has been obvious.
I think it's a made-up problem.

It has been a problem on and off for us. Usually when people use different editors and mix tabs and spaces. As always bloody humans.

[Cerebus]

Incorrect. It enforces standard formatting. Semantically different. If you use an IDE it does that up front.

Edit: software engineers have long given up the right to not have their formatting enforced by the compiler from experience. I had 200 different opinions recently on that.

Whether you chose to quibble that it's standard formatting or not, it remains that the white space is significant.  It's a shame that go made that part of the language specification, it's a little bit of passive aggressive "you will use my preferred formatting conventions if you use my language" that is semantically completely unnecessary for the language.

[bd139]

Incorrect. It enforces standard formatting. Semantically different. If you use an IDE it does that up front.

Edit: software engineers have long given up the right to not have their formatting enforced by the compiler from experience. I had 200 different opinions recently on that.

Whether you chose to quibble that it's standard formatting or not, it remains that the white space is significant.  It's a shame that go made that part of the language specification, it's a little bit of passive aggressive "you will use my preferred formatting conventions if you use my language" that is semantically completely unnecessary for the language.

You’re the sort of person I have to keep in line. The compiler is my friend here 

Actually it is necessary as well for evaluating change scope in diffs as it keeps the change subsets to functional changes and not semantic ones where someone differed in opinion on formatting during a change. It exists like this because it reduces risk of misunderstanding and malicious changes being made invisible in larger semantic changes.

Consider the old DOD standards about change scope and it makes sense.

Edit: also universal truth: Rob Pike is always right, so ner!

[Cerebus]

I have hardly had any problems with indentation and when it has ever appeared in a program, the error message from the interpreter has been obvious.
I think it's a made-up problem. I always program with correct indentation, regardless of whether the program is Python, C or other.

Well, I think we've established that you're a hobby programmer, so you generally only have to deal with your own code, or code from a project that has already sorted those problems out for you. In a professional environment, where many people can be working on the code, I've seen it cause problems, problems that quickly add up to 100s or thousands of pounds/dollars/euros worth of man hours even when you're using automated build and test pipelines that are supposed to catch most of those problems for you early and cheaply.

[mansaxel]

I have hardly had any problems with indentation and when it has ever appeared in a program, the error message from the interpreter has been obvious.
I think it's a made-up problem. I always program with correct indentation, regardless of whether the program is Python, C or other.

It is a real problem. I mostly fix other people's code to my requirements. As such I might bodge the same file in 3 different editors, on different operating systems, with terminals ranging from OS X GUI to actual VT510 terminal (my last resort console terminal in the machine room). In some of these cases editor is "ed".

Yes, I'm no primadonna brogrammer with an IDE, I slave around in the sewers where we make things the "Coders Who Talk About Trends In Frameworks and write shit webpages disguised as API's" actually work.

I think the idea of having significant white space is so utterly incompetently removed-from-reality stupid that people should be forced to read L Ron Hubbard books  for advocating it.

[Cerebus]

Incorrect. It enforces standard formatting. Semantically different. If you use an IDE it does that up front.

Edit: software engineers have long given up the right to not have their formatting enforced by the compiler from experience. I had 200 different opinions recently on that.

Whether you chose to quibble that it's standard formatting or not, it remains that the white space is significant.  It's a shame that go made that part of the language specification, it's a little bit of passive aggressive "you will use my preferred formatting conventions if you use my language" that is semantically completely unnecessary for the language.

You’re the sort of person I have to keep in line. The compiler is my friend here 

Actually it is necessary as well for evaluating change scope in diffs as it keeps the change subsets to functional changes and not semantic ones where someone differed in opinion on formatting during a change. It exists like this because it reduces risk of misunderstanding and malicious changes being made invisible in larger semantic changes.

Consider the old DOD standards about change scope and it makes sense.

Edit: also universal truth: Rob Pike is always right, so ner!

Oh, no doubt that consistent is good, but a stylistic choice that could have been a compiler switch, (--correct-bracket-format, --ugly-bracket-format) or the job of a pretty printer? Na.

[Cerebus]

I think the idea of having significant white space is so utterly incompetently removed-from-reality stupid that people should be forced to read L Ron Hubbard books  for advocating it.

Or treated in the manner Niven/Pournelle/Heinlein would advocate? 

[bd139]

Incorrect. It enforces standard formatting. Semantically different. If you use an IDE it does that up front.

Edit: software engineers have long given up the right to not have their formatting enforced by the compiler from experience. I had 200 different opinions recently on that.

Whether you chose to quibble that it's standard formatting or not, it remains that the white space is significant.  It's a shame that go made that part of the language specification, it's a little bit of passive aggressive "you will use my preferred formatting conventions if you use my language" that is semantically completely unnecessary for the language.

You’re the sort of person I have to keep in line. The compiler is my friend here 

Actually it is necessary as well for evaluating change scope in diffs as it keeps the change subsets to functional changes and not semantic ones where someone differed in opinion on formatting during a change. It exists like this because it reduces risk of misunderstanding and malicious changes being made invisible in larger semantic changes.

Consider the old DOD standards about change scope and it makes sense.

Edit: also universal truth: Rob Pike is always right, so ner!

Oh, no doubt that consistent is good, but a stylistic choice that could have been a compiler switch, (--correct-bracket-format, --ugly-bracket-format) or the job of a pretty printer? Na.

Gah no. The moment you make a flag or give a dev team an option  then it’s an instant shit show.

Actually the pretty printer is built into the IDE too. You don’t get compiler errors if you are holding your tools right.

[bd139]

I have hardly had any problems with indentation and when it has ever appeared in a program, the error message from the interpreter has been obvious.
I think it's a made-up problem. I always program with correct indentation, regardless of whether the program is Python, C or other.

It is a real problem. I mostly fix other people's code to my requirements. As such I might bodge the same file in 3 different editors, on different operating systems, with terminals ranging from OS X GUI to actual VT510 terminal (my last resort console terminal in the machine room). In some of these cases editor is "ed".

Yes, I'm no primadonna brogrammer with an IDE, I slave around in the sewers where we make things the "Coders Who Talk About Trends In Frameworks and write shit webpages disguised as API's" actually work.

I think the idea of having significant white space is so utterly incompetently removed-from-reality stupid that people should be forced to read L Ron Hubbard books  for advocating it.

White space is significant in all written languages.

Sometimes   it can be really  annoying if  done wrongly.

So enforcing a standard and consistency is more important than whether or not it exists or not.

As for brogrammers, hmm, IDEs are invariably better at presenting concerns than humans are at noticing them. As someone adept at tearing a new asshole in peoples code for a living, the IDE is a winner.

[Picuino]

Python allows indenting with mixed tabs and spaces. It even allows you to indent each different block with different combinations of spaces and tabs.

The only thing it does not allow is, for the same block, to have two lines with different indentation.

I don't think this is a very demanding requirement either.   

[Picuino]

The problem of forced indentation in Python I think is a secondary issue.

The libraries that Python has, make it a very good language for massive data handling, AI, web development, etc.

There were opinions here about JavaScript being a language with a larger number of libraries. In practice, although JavaScript has libraries for numerical analysis, AI, etc. Are the Python alternatives really used or preferred?

Use of Flask and Django vs node.js
Use of Tensorflow and PyTorch vs JavaScript alternatives.
Use of numpy and Scypy vs JavaScript alternatives.
etc.

I think that despite the many libraries that JavaScript has at the end the Python libraries are more used.

[PKTKS]

let me just put that other way...

Having a larger number of libraries out there....
does not even by chance means that these libs are good, better or even reliable.

As the discussion here points
https://www.eevblog.com/forum/programming/gnu-octave-math-programming/msg3365980/#msg3365980

OLD RELIABLE TOOLS ALREADY AVAILABLE FOR DECADES...

are just mature and the real choice for scientific use.

These  newbies libs pythonish things are just a nonsense

They just do not mean better or even usable..  just script kid stuff..

On the other hand a FULL SET OF MATURE TOOLS..
is already written in reliable languages by competent peer review.

Truth is - NOBODY ACTUALLY NEEDS THAT new newbie Python BS...
It is just bloat ware promotion of new stuff...

we do not need these..
I doubt serious folks out there will ditch the MATURE TOOLS for that.. 

Paul 

[eugene]

(and cpu usage greater than 100% is perfectly normal)

This opens a whole new world of possibilities.

[Nominal Animal]

As someone adept at tearing a new asshole in peoples code for a living, the IDE is a winner.

So you are the one putting all the holes in my code!

Kidding aside, IDE is just one more useful tool in my kit bag.  The one thing I tend to avoid is code generators, unless they can be modularised and rerun at any time without issues, but that is just my personal quirk.

[emece67]

.

[coppice]

White space is significant in all written languages.

No it isn't. Most phonetically written languages demand white space to break things up, but non-phonetic written languages, like Chinese, don't. I don't think Hangul (Korean) requires white space, and that is phonetic.

[Cerebus]

White space is significant in all written languages.

No it isn't. Most phonetically written languages demand white space to break things up, but non-phonetic written languages, like Chinese, don't. I don't think Hangul (Korean) requires white space, and that is phonetic.

And as far as programming languages go Algol68 gives not one jot about white space, as this trivial and rather ridiculous example proves:

spaced.a68:

Code: [Select]

(
INT a variable name with spaces in it := 1;
INT avariablenamewithoutspacesinit := 2;

avariablenamewithoutspacesinit := a variable name with spaces in it;
avariablenamewithspacesinit := a variable name without spaces in it;
        print (("I'm done:", avariablenamewithoutspacesinit))
)

unspaced.a68:

Code: [Select]

(INTavariablenamewithspacesinit:=1;INTavariablenamewithoutspacesinit:=2;avariablenamewithoutspacesinit:=avariablenamewithspacesinit;avariablenamewithspacesinit:=avariablenamewithoutspacesinit;print(("I'm done:",avariablenamewithoutspacesinit)))


 
cerebus@shu:~/Desktop$ a68g --clock spaced
I'm done:         +1
Genie finished in 0.00 seconds
cerebus@shu:~/Desktop$ a68g --clock unspaced
I'm done:         +1
Genie finished in 0.00 seconds
cerebus@shu:~/Desktop$ 

[coppice]

White space is significant in all written languages.

No it isn't. Most phonetically written languages demand white space to break things up, but non-phonetic written languages, like Chinese, don't. I don't think Hangul (Korean) requires white space, and that is phonetic.

And as far as programming languages go Algol68 gives not one jot about white space, as this trivial and rather ridiculous example proves:

White space is irrelevant to the compiler for many computer languages. In languages like Algol, PL/!, Coral and others requiring an awful lot of quotes around things white space is usually only relevant in literal strings. I once had to write a reformatter to make a large messed up Coral project more readable, before starting the serious work of turning an ugly ducking into a swan. Its first step was to remove all white space outside literal strings, before insert spaces and new lines, by a set of rules, to produce a clean consistent readable page.

[Cerebus]

Where that falls apart for many languages is sensitivity to additional space, many languages will reject white space within a variable name.

[coppice]

Where that falls apart for many languages is sensitivity to additional space, many languages will reject white space within a variable name.

I think things like Algol fall apart when editing, as its so damned hard to search for anything, unless you have a very specialised search tool, that most editors lack. Algol was designed before the first CRT terminal, so it probably didn't seem like much of an issue back then.

I think many early language designers had an obsession with trying to make a program read like an English essay, rather than make it read like a clean compact unambiguous mathematical notation. The latter tends to work a lot better. Even Cobol migrated from very textual to more mathematical notationy.