-
What do you think about this?
Source: https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
"October Headline: Python programming language number 1!
For the first time in more than 20 years we have a new leader of the pack: the Python programming language. The long-standing hegemony of Java and C is over. Python, which started as a simple scripting language, as an alternative to Perl, has become mature. Its ease of learning, its huge amount of libraries, and its widespread use in all kinds of domains, has made it the most popular programming language of today. Congratulations Guido van Rossum! Proficiat! -- Paul Jansen CEO TIOBE Software"
-
Python has long been the most popular language in PYPL.
PYPL (PopularitY of Programming Language): https://pypl.github.io/PYPL.html (https://pypl.github.io/PYPL.html)
Rank Language Share Trend
1 Python 29.66 % -2.1 %
2 Java 17.18 % +0.8 %
3 JavaScript 8.81 % +0.4 %
4 C# 7.3 % +1.1 %
5 C/C++ 6.48 % +0.7 %
6 PHP 5.92 % +0.1 %
7 R 4.09 % +0.2 %
8 Objective-C 2.24 % -1.2 %
9 TypeScript 1.91 % +0.1 %
10 Kotlin 1.9 % +0.3 %
Merits and demerits of language: https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4162963/#msg4162963 (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4162963/#msg4162963)
-
read that gazillion times.. ::)
I am sick of such "sums"
Folks can obviously sum decently enough to conclude pretty much 90% of everthing in use comes from C (in such not even in need to sum C++..)
Sum ANDROID (linux kernel) all AVR small gizmos - native C compiled ....
They need to teach some fancy crap which is not total POSIX safe and can run on any crap console..
BINGO! forget C/C++, PERL even lua GO and RUST ..
no to mention uncle google is making a serious sponsor to promote RUST in place of C... ::)
I am waiting this round .. RUST !!! RUST!!! ^-^
Forget C.. this is too OLD crap..
Paul
-
I started using Python almost 20 years ago to test safety PLC code. I needed to render the code and ensure its suitability.
I started by learning some Perl to get the job done, but soon some colleagues at work showed me the power and simplicity of Python and I never went back to Perl again.
I love the expressiveness of the language and its ease of reading, among the many qualities that have already been mentioned.
-
I deal with both .. being PERL mostly since 90s as it came very very earlier..
IMHO - there is not a chance in hell to compare PERL with Python.
PERL has probably an order of magnitude better and safer code (www.cpan.org (http://www.cpan.org))
Integrated very close to UNIX being POSIX compliant ...
And a hell order of magnitude better organized.
Streams PIPES and sockets are just native as in any shell.
On the other hand it takes a pretty long time to master..
And all goodies are there.. bindings to all toolkits.. Gtk,Qt/Wx Curses..
Python may be "easy" for shallow programmers.
But the lack of closures...
The odd dependency of spaces and a pretty much pathetic organized library set...
result in a messy deploy usage base where a simple "version" mismatch throw a dependency exception
Never happens that in PERL.
You can upgrade the site and things keep running .. sometimes a minor glitch.
Tried to upgrade python several times.. 90% times it fails
Requiring FULL SITE ditch and re install..
Messy pretty thing.
Never wasted more time on that.. although a lot of people like this...
usually they came from windoossss non POSIX messy rolling rocks...
Paul
-
I agree, Perl has its advantages that I do not discuss.
But what I want is to talk about Python.
-
Python has long been the most popular language in PYPL.
PYPL (PopularitY of Programming Language): https://pypl.github.io/PYPL.html
Rank Language Share Trend
1 Python 29.66 % -2.1 %
2 Java 17.18 % +0.8 %
3 JavaScript 8.81 % +0.4 %
4 C# 7.3 % +1.1 %
5 C/C++ 6.48 % +0.7 %
6 PHP 5.92 % +0.1 %
7 R 4.09 % +0.2 %
8 Objective-C 2.24 % -1.2 %
9 TypeScript 1.91 % +0.1 %
10 Kotlin 1.9 % +0.3 %
Wait a sec ...
The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google.
The more a language tutorial is searched, the more popular the language is assumed to be. It is a leading indicator. The raw data comes from Google Trends.
https://pypl.github.io/PYPL.html
I bolded the thing that concerns me about that data. But in any case the Python trend is -2.1% and the C variants are all positive. :-//
-
This is not surprising. Python has been on a steady rise for a number of years.
Now of course, a more interesting analysis would be to estimate figures depending on classes of use cases.
A general popularity index doesn't say all that much. A language becoming popular may just come from the fact its typical use cases themselves are becoming more popular.
-
I bolded the thing that concerns me about that data. But in any case the Python trend is -2.1% and the C variants are all positive. :-//
Yes. I kind of doubt the complete objectiveness of this PYPL thing anyway. What's the actual history of this project? Hasn't been Python first with their index right from the start? Is even the name starting with "Py" (while tons of projects/libraries based on Python start with "Py") just a coincidence? Yeah. :horse:
-
Maybe the most popular, but surely not the most efficient. And this is becoming a hot topic, or haven't you started talking about the CO2 footprint of software?
-
In fact, the greatest effort in the development of the Python language is now being made to try to improve its efficiency.
Its low efficiency is one of the reasons why it has not been implemented in the world of smartphones.
-
I refuse, given the choice, to use a programming language that imposes "structure" by "number of invisible characters". That is stupid on a level only challenged by "one type of invisible character is to be interpreted different than another invisible character".
Here are some hints on characters that without ambiguity can impose structure:
{} () ;
Apart from that fundamental stupidity, I'm sure Python is a nice language.
-
I refuse, given the choice, to use a programming language that imposes "structure" by "number of invisible characters". That is stupid on a level only challenged by "one type of invisible character is to be interpreted different than another invisible character".
I used to be dismissive of this kind of reasoning -- until I tried working in python.
I've used programming languages before with whitespace being significant. These were F# and haskell and they worked just fine by me. The difference with python comes to programming style. In a functional language you define functions as frequently as you define variables; variables are just nullary functions. So having a simple syntax for them is critical. Functions are generally quite small so they don't have a ton of blocks to them. But in python you program in more of a procedural style. This means large functions with lots of nested conditionals. That makes a huge difference!
That said, I just cannot get past the whole lack of static typing in python. There are some nice things there and I like the easy integration with C and C++. But without static typing it reminds me too much of javascript or perl. Oh, and it really needs a static linker; shouldn't need to run docker to deploy a program.
-
I refuse, given the choice, to use a programming language that imposes "structure" by "number of invisible characters". That is stupid on a level only challenged by "one type of invisible character is to be interpreted different than another invisible character".
Here are some hints on characters that without ambiguity can impose structure:
{} () ;
Apart from that fundamental stupidity, I'm sure Python is a nice language.
This is the primary reason I have no interest in even trying to use python.
-
Its low efficiency is one of the reasons why it has not been implemented in the world of smartphones.
It's interesting to see people trying at all costs to find new applications for an existing tool, while a more reasonable approach in engineering is finding the tools for a given application.
IMHO, this is this non-very-engineeringly approach that got Python where it is now.
We've been witnessing a similar trend with AI in general in the past decade.
-
Why would one care about 'popularity' at all?
(Not a rhetorical question, I'm genuinely puzzled, and interested in any answers.)
One obviously cares about the tools used in ones own field (and perhaps the fields that uses the tools one has), but 'popularity' (measured in this way) is exactly the wrong metric for that. It's like trying to measure short distances using the echoes generated by shouting.
Even 'project count' is near to useless, because among the numerous projects, only a few are actually useful, and the majority is – perhaps unsurprisingly – quite crappy, especially wrt. security and software engineering principles (buggy, poorly documented).
In my opinion, 'popularity' is an useless metric here. Perhaps it matters if you are desperate for any kind of programming job and don't know how to program at all yet –– but that's the only situation I can really think of where 'popularity' would matter.
-
Doesn't anyone use Basic any more?
:(
-
Python becomes the most popular accessible language
The biggest advantage of Python is its low barrier of entry. Install the tool chain and you can hammer out code in minutes.
-
:-DD
I don't care to be in the popular crowd. Counting spaces and trying to figure out if you should use 'SomeFunction' instead of 'someFunction' this week isn't for me.
-
What do you think about this?
I think the word you were looking for in the subject line was "common".
It's just awful.
I like Ruby *much* more. It's much better designed. A fraction slower than Python, but if you were looking for speed you wouldn't be in this category in the first place.
-
How to lie with statistics, chapter 11½: make sure the variable is so vaguely defined it carriers no actual meaning, but the reader will instantly provide their own definition and never notice the value is meaningless.
-
Popular is in no way the same as best. Ask the average guy to name a motorbike and they will probably say Harley, a microcontroller and they will say Arduino. Both very popular examples of the worst of their domain.
I refuse, given the choice, to use a programming language that imposes "structure" by "number of invisible characters". That is stupid on a level only challenged by "one type of invisible character is to be interpreted different than another invisible character".
Totally agree. I had to use Python recently as a scripting language within a product. (Python's good enough for scripting to be fair, it's just not a programming language.) You could use the internal textbox editor or edit in an external tool like Notepad++. One kept tabs, one converted tabs to spaces. Cue a subtle invisible run-time bug where the code looked like it would do one thing but would compile just fine and then do something else.
The fact that JavaScript is high up in the list backs up my point. That was the worst programming language (once again only suitable for scripting) until Python came along.
-
... I had to use Python recently as a scripting language within a product. (Python's good enough for scripting to be fair, it's just not a programming language.) You could use the internal textbox editor or edit in an external tool like Notepad++. One kept tabs, one converted tabs to spaces. Cue a subtle invisible run-time bug where the code looked like it would do one thing but would compile just fine and then do something else....
That was addressed in Python 3 over a decade ago. For example, I tried replacing eight spaces with a tab inside a function that is not executed during import:
~% python3 foo.py
File "foo.py", line 136
os.remove(path)
^
TabError: inconsistent use of tabs and spaces in indentation
If you can mix tab and space indentation in Python 3 and it does not complain, report that: it is a bug.
-
Maybe the most popular, but surely not the most efficient. And this is becoming a hot topic, or haven't you started talking about the CO2 footprint of software?
Nah, I wouldn't say this. An average developer could write more efficient code in python easier than in C. There are a few companies that switched to python in high frequency trading, because writing code fast and being able to react to market conditions faster makes more profit than being able to calculate a millisecond faster. And being able to use the available resources is often times more useful.
Try doing complex matrix calculations in C. Sure the same python implementation would be slower. But then you make it with Numpy, and it suddenly catches up, you can start using the video card by adding a few lines, and then it is suddenly faster, or add ray multiprocessing (few lines of code, really), and then the same code is running parallel on a distributed server farm. Try coding that in C.
Or the new popular micropython microcontrollers. I had to evaluate a sensor IC, used the Pi Pico for it. 5 minutes later, I was logging it's data on uart. If I'm given the same task in C, 2 days later I'm still struggling setting up the GCC compiler into an IDE, or struggling with vendor specific libraries, with no progress on the actual task.
-
Another potential discussion ruined by the usual suspects whining about why language x doesn't work for them because of y.
Python is a white-space delimited, dynamically but strongly typed language, if you don't like it fuck off, and go and whine elsewhere.
IMO the two points of this discussion are:
- What does "popularity" even mean for programming languages?
- What is it about Python that apparently makes it popular?
-
Another potential discussion ruined by the usual suspects whining about why language x doesn't work for them because of y.
It's not a discussion unless you discuss it.
-
Please don't get me wrong. Python is all over the place in network engineering, especially in automation which is quite complex. and most network engineers are able to cope with it despite not being software developers. Presumably they would be much less productive when writing code in C (not many are proficient in C). And that's also the big problem: tons of python code hacked together. If it's too slow then more CPU power is added.
-
this is a funky thread... :popcorn:
Python found a niche very fast..
..even being a messy identated code piled together now there are are tons of usable stuff around..
every now fan boy put stuff together fast..
Sure it is slow.. very odd "object" like stuff put together..
... And a total pain to maintain a sane site among messy version...
Agreed with everybody else that RUBY is the perfect OO choice..
One level just after PERL obviously. Elegant, organized and much much more recommended for serious use..
Nevertheless only RubyOnRails seems to be attractive..
Once you cross the OO boundary on PERL there is no way back.
But obvisouly we can not ignore the Python niche in particular all those fan boys that a re coming from the pathetic windoozee arena...
We need to live with this thing..
and to complicate things further.. obviously a strong effort was made/sponsored to replace GNU autotools with that MESON thing... sponsors succeeded on that..
GNU Autotools are PERL based and they do not run nice at all on no POSIXs like windoozee so VisualShit can not live with that.. MESON felt from the ether..
Paul
-
... I had to use Python recently as a scripting language within a product. (Python's good enough for scripting to be fair, it's just not a programming language.) You could use the internal textbox editor or edit in an external tool like Notepad++. One kept tabs, one converted tabs to spaces. Cue a subtle invisible run-time bug where the code looked like it would do one thing but would compile just fine and then do something else....
That was addressed in Python 3 over a decade ago. For example, I tried replacing eight spaces with a tab inside a function that is not executed during import:
~% python3 foo.py
File "foo.py", line 136
os.remove(path)
^
TabError: inconsistent use of tabs and spaces in indentation
If you can mix tab and space indentation in Python 3 and it does not complain, report that: it is a bug.
If I can't indent code the way I want, I consider it a serious limitation. Not being able to mix "whitespace" (which the most common definition of is space tab newline) as I wish makes me grumpy.
Mind you, there are languages where indentation is fixed for a good reason. The best example is JCL, which, if you go above a certain line length, considers next row a continuation of the long one, but that's because JCL assumes input is on punch cards, and once you hit column 71, you probably need to go on for a bit more, but the manilla is running out fast...
That, I'm certain, is the company Python hipsters seek.
-
... If I can't indent code the way I want, I consider it a serious limitation. Not being able to mix "whitespace" (which the most common definition of is space tab newline) as I wish makes me grumpy....
I would agree with that, if you could somehow get the rest of the world to use tab stops exactly like yours, but alas they do not and some will not.
Python 2 and 3 have no problem with purely tab-indented code. Just playing with it now, Python 2 appears to have no trouble with mixed tab- and space-indentation – provided you use the one true tab width ;) of exactly eight characters.
-
... If I can't indent code the way I want, I consider it a serious limitation. Not being able to mix "whitespace" (which the most common definition of is space tab newline) as I wish makes me grumpy....
I would agree with that, if you could somehow get the rest of the world to use tab stops exactly like yours, but alas they do not and some will not.
Python 2 and 3 have no problem with purely tab-indented code. Just playing with it now, Python 2 appears to have no trouble with mixed tab- and space-indentation – provided you use the one true tab width ;) of exactly eight characters.
This is just a comic nonsense joke...
WTF would a programming language (a decent one) care if I am using TAB or space or if my TAB has 8 4 or 1 char?
TAB is well defined ASCII table and never ever such stupid thing should exists in the first place..
Just nuts.
Paul
-
... If I can't indent code the way I want, I consider it a serious limitation. Not being able to mix "whitespace" (which the most common definition of is space tab newline) as I wish makes me grumpy....
I would agree with that, if you could somehow get the rest of the world to use tab stops exactly like yours, but alas they do not and some will not.
Python 2 and 3 have no problem with purely tab-indented code. Just playing with it now, Python 2 appears to have no trouble with mixed tab- and space-indentation – provided you use the one true tab width ;) of exactly eight characters.
The reason of using "whitespace" as definition is that indentation is done purely for readability reasons. (Or to prevent readability (http://www.marcomoser.it/index.php/fun/obfuscatedc)! That of course is not something desirable in production code; but the point stands.)
Formatting and structure are not to be mixed, simply because formatting is not to be trusted.
-
Since long time they be pushing python language.
All those things i look they say : python is so much better, it is the best, i only use python.
Why all the pushing ?, no wonder it is so popular.
Snakey methods.
-
I will put that in another perspective...
**ALL** sane "IT pro grade" tools can and usually do use a command line.
Obviously for the sake of automation scripting and pipeline tools.
e.g. PERL can accept the script as a whole just:
/usr/local/bin/perl -e 'while(this){dothat();othershit();blah();}' &2>$LOG >&1>device
the whole thing can be streamed pipelined and even dumped...
WTF spaces and identation would be any good there..?
All GNU tools (shells awk sed ed and others ..) of course accept such simple principle..
but not that odd eccentric python... obviously it is suited to Windooosee mentality
They pushed that way too far..
and soon they will implode XWindows adn linux into a subthing
Give me a break ::)
Paul
-
... Formatting and structure are not to be mixed, simply because formatting is not to be trusted.
Yes, but what if you could trust the formatting? Then you would have Python or something like it. I understand Python is not the first computer language to use format to define structure.
-
Since long time they be pushing python language.
All those things i look they say : python is so much better, it is the best, i only use python.
Why all the pushing ?, no wonder it is so popular.
Snakey methods.
Are we pushing?
Maybe we are just a bit enthusiastic about it. I know I was underwhelmed when I first tried it, I literally said, "Its like C but you dont have to end the line with ;". Had to learn if for the job, after really understanding it, it blew my mind. Probably that was around the time when I did my first machine learning project with it, that I never imagined doing otherwise.
And you know, people talk about good experiences. Nobody is pushing anyone. I just think people don't talk about their good times with Cobol, because they probably hanged themselves after reading someone else's code.
-
https://wiki.python.org/moin/Powerful%20Python%20One-Liners
-
I refuse, given the choice, to use a programming language that imposes "structure" by "number of invisible characters". That is stupid on a level only challenged by "one type of invisible character is to be interpreted different than another invisible character".
Here are some hints on characters that without ambiguity can impose structure:
{} () ;
Apart from that fundamental stupidity, I'm sure Python is a nice language.
This is the primary reason I have no interest in even trying to use python.
I use Python for small scripts and such, but the thing that drives me bonkers about the language is that it lets you define a variable as one type and then a bit later in the same function you can redefine the same variable as another completely-different type.
-
For the record, I recognize Python a multitude of advantages, without questioning the many disadvantages it can have. There is no perfect language for everything.
Ruby is a very similar language, but it has never had the popularity of Python. And, in my opinion, Ruby code is somewhat more difficult to maintain than Python code. That is a point that I consider important.
So the question seems to be, how has Python gotten the top spot in popularity with so many drawbacks?
-
For the record, I recognize Python a multitude of advantages, without questioning the many disadvantages it can have. There is no perfect language for everything.
Ruby is a very similar language, but it has never had the popularity of Python. And, in my opinion, Ruby code is somewhat more difficult to maintain than Python code. That is a point that I consider important.
So the question seems to be, how has Python gotten the top spot in popularity with so many drawbacks?
Easy to see..
and more or less said above...
It runs on windoozee pretty easy - while PERL and RUBY are far more difficult to setup..
PERL being almost impossible to setup unless using "ActiveState" or CYGWIN..
UC windooze is not POSIX - they tried to "sell" POSIX by 2000s and failed miserably... :palm:
required insane values from what could be deployed using *NIX. Don't even got airborne the idea
Python is simple to learn for people without a clue in advanced programming.
Several "courses" started to monetize this OO thingy Python has to make some cash..
Real world professional grade languages require a lot more time effort.. ( ASM /C/C++ PERL/AWK RUBY)
and obviously these do not run that easy (considering the extortive price of compilers ) on windoooze
Windooze is that.
BAD - COSTLY - and pretty much a lack of power grade mentality in soft and hardware + LICENSES
They just want money. Whatever it takes.
All that can be solved by switching the platform and tools..
But it takes TIME EFFORT (a lot ) and MONEY..
Python is cheap newbie stuff
No compiler no POSIX complicated system setup and sys admins...
Vanilla POPCORN
Paul
-
Python is used professionally in real world.
It is used in AI from Google to Amazon.
For representation and data management (Big data).
To create websites and services (Spotify, Netflix, Youtube, Reddit).
For scripting (it is one of the standard languages in many Linux distributions).
In science with Jupyter Notebooks (https://www.nature.com/articles/d41586-018-07196-1).
Etc.
Edit: For example this paper, Monitoring Scientific Python Usage on a Supercomputer (http://conference.scipy.org/proceedings/scipy2021/pdfs/rollin_thomas.pdf)
Abstract—In 2021, more than 30% of users at the National Energy Research
Scientific Computing Center (NERSC) used Python on the Cori supercomputer.
To determine this we have developed and open-sourced a simple, minimally in-
vasive monitoring framework that leverages standard Python features to capture
Python imports and other job data via a package called "Customs". To analyze
the data we collect via Customs, we have developed a Jupyter-based analysis
framework designed to be interactive, shareable, extensible, and publishable via
a dashboard. Our stack includes Papermill to execute parameterized notebooks,
Dask-cuDF for multi-GPU processing, and Voila to render our notebooks as
web-based dashboards. We report preliminary findings from Customs data col-
lection and analysis. This work demonstrates that our monitoring framework can
capture insightful and actionable data including top Python libraries, preferred
user software stacks, and correlated libraries, leading to a better understanding
of user behavior and affording us opportunity to make increasingly data-driven
decisions regarding Python at NERSC
-
Python found a niche very fast..
..even being a messy identated code piled together now there are are tons of usable stuff around..
every now fan boy put stuff together fast..
I think you will find the uptake of Python by the Universities had a lot to do with it gaining ground. Students for the most part push the crap they learn into the workplace when they arrive.
-
I use Python for small scripts and such,
If all you use it for are "small scripts", you may try something else. I personally use Lua.
but the thing that drives me bonkers about the language is that it lets you define a variable as one type and then a bit later in the same function you can redefine the same variable as another completely-different type.
That's what you get with dynamically-typed languages.
The problem with this is that it creates an opportunity for writing very bad code. Reusing the same variable for different purposes, in a statically-typed language, is already often seen as sloppy and undesirable, but if you can change its type on top of that, it's even worse. Of course people proponents will just tell you that while you can, you don't have to do it.
-
So the question seems to be, how has Python gotten the top spot in popularity with so many drawbacks?
That isn't a simple question to answer. How things become popular in general isn't: it's not all that predictable. That's been witnessed also with music, movie genres, fashion, and so on. Sure once a trend is there, many can piggy-back on it - while it lasts. But how it all started? There's no real magic recipe.
As I mentioned, I find interesting that there seems to be a parallel in how both Python and AI have become very popular in the last decade or so, and I'd venture that there are similar causes. And as a matter of fact, both are related as Python is used quite a bit in AI. And while this is not a *cause* per se, as I said, it's interesting how in both cases, proponents are just trying to push it very hard, trying to find more applications for the tools instead of trying to make/use tools fit for a purpose. There you have a typical marketing attitude, and not an engineering one. That's probably part of the answer. There surely was, and is, a need for a general-purpose interpreted language, and I admit most of them out there are nasty one way or another...
As I mentioned once, I doubt Python's author expected it to get so much traction when he designed the language. Python comes from the ABC language https://en.wikipedia.org/wiki/ABC_(programming_language) , designed earlier in the same institute. ABC, IMHO, was pretty horrible, and Python's syntax directly comes from it.
The idea behind significant whitespace, I guess, is that proper code formatting makes it more readable, and using "proper" formatting in a way such that improper formatting would mean broken code is certainly one way of enforcing it. Now this doesn't seem very practical (to say it gently) and is way too dangerous. Do you prefer some indentation mistake once in a while, making the code a bit less elegant, but still functional, or do you prefer the code to break in horrible ways in such a case? Yeah. Another issue is that indentation is, was, and will always be a "moving target". There are multiple ways of indenting code, which makes the Python approach even more horrible. So OK, the Python interpreter will try to spot indentation issues in your code - when they look likely bogus - but it can't be fail-safe.
-
As I mentioned, I find interesting that there seems to be a parallel in how both Python and AI have become very popular in the last decade or so, and I'd venture that there are similar causes. And as a matter of fact, both are related as Python is used quite a bit in AI. And while this is not a *cause* per se, as I said, it's interesting how in both cases, proponents are just trying to push it very hard, trying to find more applications for the tools instead of trying to make/use tools fit for a purpose. There you have a typical marketing attitude, and not an engineering one. That's probably part of the answer. There surely was, and is, a need for a general-purpose interpreted language, and I admit most of them out there are nasty one way or another...
This maybe part of it, but having worked and trained both interns and new hires, their views and ways of getting something done is heavily biased by what they did/used as students. C/C++ is not being used and taught to the same extent as Python which the universities see as a 'easier' language to teach programming concepts with. I've spoken with tutors that say 'our students found C++ too difficult'. There is also a pervasive attitude that if course XXX uses it Course YYY will also.
As a side note, I found the conversation that students finding C++ difficult meant finding something easier very revealing but that's for another topic.
-
As a side note, I found the conversation that students finding C++ difficult meant finding something easier very revealing but that's for another topic.
I do not think that needs to be such an indicator of decay as it is made out to be. If you'd had the rich landscape of libraries and the sometimes near-magic of Python at hand when you started out, would you have used C? Maybe as a personal challenge, but not else. Unless you had something that could not be made with Python.
Students will complain, and then they will learn, the hard things too. We are not getting dumber as a rule. We are mostly -- by circumstances -- allowed to get away with being what was seen as lazy.
And as for faculty "succumbing" -- is the goal a bootcamp destruction - rebuild style "education" or is the goal to get people to actually learn something and grow?
(https://fr.web.img6.acsta.net/r_654_368/newsv7/18/04/16/10/56/4035253.jpg)
(https://www.forsvarsmakten.se/ImageVault/publishedmedia/mqoxpa7ainoee4dsdt64/190624-viksza-inryck-artbat-1.jpg)
-
This maybe part of it, but having worked and trained both interns and new hires, their views and ways of getting something done is heavily biased by what they did/used as students. C/C++ is not being used and taught to the same extent as Python which the universities see as a 'easier' language to teach programming concepts with. I've spoken with tutors that say 'our students found C++ too difficult'. There is also a pervasive attitude that if course XXX uses it Course YYY will also.
As a side note, I found the conversation that students finding C++ difficult meant finding something easier very revealing but that's for another topic.
It holds TRUE.
EASIER translates to CHEAP... very cheap you can put a python thing without compiler hassle into students and newbies heads...
EXPENDABLE.. all big corps can fetch a huge asset base of newbies very cheap and expendable just doing shallow Python code thing..
Bottom line Python is CHEAP, very affordable to expendable newbies..
Easy to monetize on Academia teaching "pseudo-object-thing" more or less just the shallow surface of serious programming..
No hassle with templates .. complicated pointer and memory allocation..
Easy money with expendable newbies..
I am waiting the pile of money uncle Google spent on RUST to replace C into the kernel.
Paul
-
Other things being equal, cheap is good! One big reason ADA 95 failed to make much of an impression in the wider industry was the lack of cheap compilers and IDEs.
In the case of Python, the availability of Numpy & Matplotlib, combined with the extortionate pricing of Matlab (and the lacklustre performance/compatibility of Scilab & Octave), gave Python a big push in the field of number crunching. It's good enough, and cheap enough to become widely used, and because it's widely used, there are people around to suggest its use and help out when you get stuck. And so the snowball grows...
I have only recently started to need to use Python, and find it is Mostly Harmless. It has its own weirdnesses (why invent a whole new string-formatting scheme, FFS?), and of course the curse of Python 2/3 incompatibility (Python 2, just die already!). My favourite IDE (JetBrains) has a Python mode so I can work in a familiar environment, and it's good enough for what we are trying to achieve in the project. That's all that is needed - it doesn't have to be perfect!
-
mostly true as well..
But why re-invent the wheel using Python (for uses like numpy scipy) where PERL PDL and octave does 100x more already use proof?
PERL comes with BLAS and LAPACK bindings.. integrated in PDL command shell..
The initial step may be wider but the use of that weird Python scripts does not justify the hype on it.
Bottom line - nobody really needs Python.
It serves the gap CHEAP +EXPENDABLE - good to monetize for fast shallow purposes..
We still have to face serious use on the real scientific targets
Paul
-
One of my major concerns about python (and in general about scripting languages) is how difficult is to distribute programs made with it. Not being able to generate an executable (or a similar package to a Java .jar) using just the official tools makes it hard for users without any knowledge about computers to install and run them.
Additionally, as it does not have a proper standard like C or Ada, its semantics change too fast leading to a significant amount of breaking changes between versions. As a result, you end up having to install different versions of python to be able to execute each program
-
One of my major concerns about python (and in general about scripting languages) is how difficult is to distribute programs made with it. Not being able to generate an executable (or a similar package to a Java .jar) using just the official tools makes it hard for users without any knowledge about computers to install and run them.
Additionally, as it does not have a proper standard like C or Ada, its semantics change too fast leading to a significant amount of breaking changes between versions. As a result, you end up having to install different versions of python to be able to execute each program
TRUE.
So does JAVA. So does Python ..
And so does C++ with way too fast changes in C standards..
The STL and template became a fast mess of incompatible things..
PERL and Ruby are far more easy to deploy because they are
- clever in all aspects of POSIX structure
- far more suited to long term results instead of newbie appeals
- much more clever keeping rolling releases in MINOR not in MAJOR versions
The folks behind them are real world sys admins and developers.. not first time scripters.
C can be orders of magnitude easier to keep and deploy than C++ just by not having that way bloated standards..
Paul
-
One of my major concerns about python (and in general about scripting languages) is how difficult is to distribute programs made with it. Not being able to generate an executable (or a similar package to a Java .jar) using just the official tools makes it hard for users without any knowledge about computers to install and run them.
Additionally, as it does not have a proper standard like C or Ada, its semantics change too fast leading to a significant amount of breaking changes between versions. As a result, you end up having to install different versions of python to be able to execute each program
TRUE.
So does JAVA. So does Python ..
And so does C++ with way too fast changes in C standards..
The STL and template became a fast messy of incompatible things..
PERL and Ruby are far more easy to deploy because they are
- clever is all aspects of POSIX structure
- far more suited to long term results instead of newbie appeals
- much more clever keeping rolling releases in MINOR not in MAJOR versions
The folks behind them are real world sys admins and developers.. not first time scripters.
C can be orders of magnitude easier to keep and deploy than C++ just by not having that way bloated standards..
Paul
I think standards should focus on mature technology to improve portability. New ideas should be tested first as prototypes to check if they are actually a good idea before making a bloated standard
-
(https://forum.atheistrepublic.com/uploads/default/original/2X/0/064c615e1131eca079f8ad4aa060467933d9fd55.jpeg)
IDK, is the PIN = 3112?
The denominator seems to be just bait. :-//
(https://www.eevblog.com/forum/chat/fun-for-nerds/?action=dlattach;attach=1242212;image)
The quote is from another topic, but it's a good example for why Python becomes so popular:
Because it's easy to solve almost any problem you throw at it, and fast. :-+
It's easy to read other's code. Has a low entry bar for non software developers. Comes already installed with the major Linux distributions. Has all you need natively, and if it doesn't, then for sure there are external modules to do whatever it doesn't do natively. All you have to do is "pip install something", then write inside the code "import something". Easy to learn, easy to use, easy to write, easy to read, massive community support.
A major advantage is that it doesn't need redundant shift characters like curly brackets. That way it settles forever the formatting styles problem from C, where one can get functional code rejected for not following some code formatting conventions each software package might have established for itself only.
And also coerces beginner to properly indent code, no more loops and nested ifs written all from the beginning of the line. :phew:
-
::) And I am pretty sure some python fan boy already made an applet on ANDROID to open a a python console and solve that...
Not surprised if already there...
::) Paul eiiiiiiitaaaa
-
::) And I am pretty sure some python fan boy already made an applet on ANDROID to open a a python console and solve that...
Not surprised if already there...
::) Paul eiiiiiiitaaaa
There are already several tools to make android and iOS apps with python and apps to run Jupyter notebooks in both platforms hahaha
-
Let's not forget that windoooze now can run them all..
They transformed everybody else in subsystems..
point click and puff... windozee runs anything...
Recently an article said: "Finally LINUX malware found spreading ( inside WSL.. )" ::)
go figure.. the year of mess hell
Paul
-
... [Python] has its own weirdnesses (why invent a whole new string-formatting scheme, FFS?)....
The last time I checked, Python had five different ways to format strings, three more than when I first started using it!
EDIT: Make that four. It appears the fifth formatting scheme (https://www.python.org/dev/peps/pep-0501/), using an i- rather f-prefix is still a work in progress. (It is really just a deferred variant of the latter.)
-
This is why Python becomes the most popular:
It allows an amateur like me to illustrate a physics idea about how to look over the edge of our visible Universe with an animation produced in less than 100 lines.
#!/usr/bin/env python2.7
'''
How to look outside our observable Universe using an outpost:
-------------------------------------------------------------
- the WHITE dots are the stars
- The Pale Blue Dot is the Earth
- the GREEN circle is the obsarvable Universe, looking from Earth
- the RED dot is an outpost telescope, continuously broadcasting its view
- the RED circle is the observable Universe, looking from the outpost
- note that the circles' radius increases with time, at the speed of light, c
- note that even the observable radius keeps increasing,
with time the stars are leaving the observable circles because space expands
- note how with time, will be less and less stars to view,
even thought the stars are still shining out there,
just that they are running away faster than the speed of light
- by receiving the broadcasted view from the outpost,
we will be able to study all the stars seen by the outpost,
including the stars that otherwise will be outside of our direct reach,
but are still reachable from the outpost viewpoint
- after a while, even the outpost will run away outside our view
'''
import pygame as pg
import random
WIDTH = 1920
HEIGHT = 1080
ANIMATION_FPS = 10
WHITE = (255, 255, 255)
BLACK = (0, 0, 0)
RED = (255, 0, 0)
GREEN = (0, 255, 0)
BLUE = (0, 0, 255)
LIGHT_BLUE = (32, 64, 255)
NR_OF_STARS = 2000
INFLATION_COEF = 0.01
OBSERVABLE_START_RANGE = 200
class Dot:
def __init__(self, x=0, y=0, color=WHITE, thickness=3):
self.x = random.randrange(1, WIDTH-1)
self.y = random.randrange(1, HEIGHT-1)
self.color = color
self.thickness = thickness
self.x_now = self.x
self.y_now = self.y
def __call__(self, x, y, color, thickness):
self.x = x
self.y = y
self.color = color
self.thickness = thickness
def xy_now(self, time=0):
self.x_now = int(round(self.x * (1 + time * INFLATION_COEF)))
self.y_now = int(round(self.y * (1 + time * INFLATION_COEF)))
screen = pg.display.set_mode((WIDTH, HEIGHT))
pg.display.set_caption("Observable vs Expansion")
clock = pg.time.Clock()
light_day = 1
# populate the Universe with stars
random.seed(1)
stars = [Dot() for i in range(NR_OF_STARS)]
# add Earth to the Universe
Earth = Dot()
Earth(200, 150, LIGHT_BLUE, 10)
stars.append(Earth)
# add an Outpost to the Universe, inside the viewrange of the Earth
Outpost = Dot()
ox = Earth.x + int(round(3.0/4.0 * 2**0.5/2 * OBSERVABLE_START_RANGE))
oy = Earth.y + int(round(2.0/4.0 * 2**0.5/2 * OBSERVABLE_START_RANGE))
Outpost(ox, oy, RED, 5)
stars.append(Outpost)
# animation loop
stopped = False
while not stopped:
# Frames Per Second
clock.tick(ANIMATION_FPS)
for event in pg.event.get(): # User did something
if event.type == pg.QUIT: # If user clicked close
stopped=True # Flag that we are done so we exit this loop
# Clear the display buffer and set the screen background
screen.fill(BLACK)
for star in stars:
# Update the star positions as per today's view and draw the star
star.xy_now(light_day)
pg.draw.circle(screen, star.color, [star.x_now, star.y_now], star.thickness)
# Draw today observable ranges from Earth and from Outpost
pg.draw.circle(screen, GREEN, [Earth.x_now, Earth.y_now], OBSERVABLE_START_RANGE+light_day, 1)
pg.draw.circle(screen, RED, [Outpost.x_now, Outpost.y_now], OBSERVABLE_START_RANGE+light_day, 1)
# Display the screen buffer
pg.display.flip()
pg.image.save(screen, "frame" + str(light_day).rjust(5, '0') + ".png")
# A day passes with each frame
light_day += 1
pg.quit()
How to look over the edge of our visible Universe - Outpost simulation
https://www.youtube.com/watch?v=BjbNZ7SLzwM (https://www.youtube.com/watch?v=BjbNZ7SLzwM)
If the outpost idea is correct or not from the physics standpoint is another topic, but Python allowed to show exactly what I was picturing in my mind but couldn't describe it clear enough by words.
-
One thing I like about Python is that it has the properties that MIT considers a learning-oriented language should have.
Low floor, wide walls, high ceiling.
Low floor: easy ways for novices to get started
High ceiling: ways for them to work on increasingly sophisticated projects over time
Wide walls: multiple pathways from floor to ceiling
https://gordonbrander.com/pattern/low-floor-wide-walls-high-ceiling/
In fact I think Python is one of the best textual languages to learn to program.
How to Think Like a Computer Scientist: Learning with Python 3 (https://buildmedia.readthedocs.org/media/pdf/howtothink/latest/howtothink.pdf)
-
One of my major concerns about python (and in general about scripting languages) is how difficult is to distribute programs made with it. Not being able to generate an executable (or a similar package to a Java .jar) using just the official tools makes it hard for users without any knowledge about computers to install and run them.
Additionally, as it does not have a proper standard like C or Ada, its semantics change too fast leading to a significant amount of breaking changes between versions. As a result, you end up having to install different versions of python to be able to execute each program
TRUE.
False.
You can make a standalone executable with PyInstaller:
* https://stackoverflow.com/questions/12059509/create-a-single-executable-from-a-python-project
* https://stackoverflow.com/questions/5458048/how-can-i-make-a-python-script-standalone-executable-to-run-without-any-dependen
-
One of my major concerns about python (and in general about scripting languages) is how difficult is to distribute programs made with it. Not being able to generate an executable (or a similar package to a Java .jar) using just the official tools makes it hard for users without any knowledge about computers to install and run them.
Additionally, as it does not have a proper standard like C or Ada, its semantics change too fast leading to a significant amount of breaking changes between versions. As a result, you end up having to install different versions of python to be able to execute each program
TRUE.
False.
You can make a standalone executable with PyInstaller:
* https://stackoverflow.com/questions/12059509/create-a-single-executable-from-a-python-project
* https://stackoverflow.com/questions/5458048/how-can-i-make-a-python-script-standalone-executable-to-run-without-any-dependen
There are many third party solutions for that problem like PyInstaller or Nuitka (a python to c transpiler), but they sometimes have incompatibilities. Distributing a C program is way easier for both, the user and the developer
-
Distributing a C program is way easier for both, the user and the developer
Maybe, I quite like the C and its portability. But I've had as much trouble compiling sources in C as running Python scripts.
Neither is immediate.
Executables are more easy.
Edit:
Example: Youtube-dl for download youtube videos (developed in Python) https://github.com/ytdl-org/youtube-dl#installation
It needs Python installed, but it runs without problems with Python 3.2+ installed.
-
Distributing a C program is way easier for both, the user and the developer
Maybe, I quite like the C and its portability. But I've had as much trouble compiling sources in C as running Python scripts.
Neither is immediate.
Executables are more easy.
Edit:
Example: Youtube-dl for download youtube videos (developed in Python) https://github.com/ytdl-org/youtube-dl#installation
It needs Python installed, but it runs without problems with Python 3.2+ installed.
I think it would be great if cpython allowed to generate executables for all platforms directly. For example, it could do something similar to Godot, which adds your program and resources at the end of the executable of the interpreter. That would allow to distribute programs in a simple format for people without experience in computer programming (they usually find the shell quite scary), while keeping all the things that have made python such a widely used language
-
This is why Python becomes the most popular:
It allows an amateur like me to illustrate a physics idea about how to look over the edge of our visible Universe with an animation produced in less than 100 lines.
Note that it is not so much the Python language that allows you to do it in less than 100 lines, it is your use of the Pygame library. It doesn't stop there. Pygame would not be able to do what it does without the SDL library etc. etc:
Pygame is obviously strongly dependent on SDL and Python. It also links to and embeds several other smaller libraries. The font module relies on SDL_ttf, which is dependent on freetype. The mixer (and mixer.music) modules depend on SDL_mixer. The image module depends on SDL_image, which also can use libjpeg and libpng. The transform module has an embedded version of SDL_rotozoom for its own rotozoom function. The surfarray module requires the Python NumPy package for its multidimensional numeric arrays.
https://github.com/pygame/pygame
-
My one forced encounter with Python left me vowing never to use it again.
-
This is why Python becomes the most popular:
It allows an amateur like me to illustrate a physics idea about how to look over the edge of our visible Universe with an animation produced in less than 100 lines.
Note that it is not so much the Python language that allows you to do it in less than 100 lines, it is your use of the Pygame library. It doesn't stop there. Pygame would not be able to do what it does without the SDL library etc. etc:
Pygame is obviously strongly dependent on SDL and Python. It also links to and embeds several other smaller libraries. The font module relies on SDL_ttf, which is dependent on freetype. The mixer (and mixer.music) modules depend on SDL_mixer. The image module depends on SDL_image, which also can use libjpeg and libpng. The transform module has an embedded version of SDL_rotozoom for its own rotozoom function. The surfarray module requires the Python NumPy package for its multidimensional numeric arrays.
https://github.com/pygame/pygame
Pip and the other package managers available in the python environment have had an important impact on its popularity. They simplify using libraries and create a more integrated ecosystem. It would be nice to have something like them in the C/C++ word
-
One of my major concerns about python (and in general about scripting languages) is how difficult is to distribute programs made with it. Not being able to generate an executable (or a similar package to a Java .jar) using just the official tools makes it hard for users without any knowledge about computers to install and run them.
Additionally, as it does not have a proper standard like C or Ada, its semantics change too fast leading to a significant amount of breaking changes between versions. As a result, you end up having to install different versions of python to be able to execute each program
TRUE.
False.
You can make a standalone executable with PyInstaller:
* https://stackoverflow.com/questions/12059509/create-a-single-executable-from-a-python-project (https://stackoverflow.com/questions/12059509/create-a-single-executable-from-a-python-project)
* https://stackoverflow.com/questions/5458048/how-can-i-make-a-python-script-standalone-executable-to-run-without-any-dependen (https://stackoverflow.com/questions/5458048/how-can-i-make-a-python-script-standalone-executable-to-run-without-any-dependen)
Yep, that's another reason for people to like Python: programs and their dependencies can all be encapsulate in a single portable executable file. :-+
That's exactly what I used this weekend to "compile" a small Python program into a standalone and single file Linux executable: https://www.eevblog.com/forum/testgear/sniffing-the-metrix-mtx3283-dmm-modbus-protocol/msg3740053/#msg3740053 (https://www.eevblog.com/forum/testgear/sniffing-the-metrix-mtx3283-dmm-modbus-protocol/msg3740053/#msg3740053)
The executable is to be used from a terminal, it reads a handheld DMM Metrix MTX3283 over its optical to serial port cable adapter. The instrument uses the Modbus protocol over RS232. Used the MinimalModbus module to do that, and just to be sure some future updates won't broke the DMM reader program, packed it all in a small 8MB single file, which is compressed, standalone, executable and portable.
Though, each OS type will need the executable to be built for it, the single file is not multi-platform like Java.
Apart from PyInstaller and alike, there are non compiled tools and techniques like virtual environments, pip or miniconda that can install or reproduce all the Python development requirement on another machine, but working with those will require some discipline from the developer.
-
Why is it that, one this site, there are discussions that devolve into identity politics, and there's always an individual, or two, whose posts consist of spastic thoughts just vomited out.
-
... [Python] has its own weirdnesses (why invent a whole new string-formatting scheme, FFS?)....
The last time I checked, Python had five different ways to format strings, three more than when I first started using it!
EDIT: Make that four. It appears the fifth formatting scheme (https://www.python.org/dev/peps/pep-0501/), using an i- rather f-prefix is still a work in progress. (It is really just a deferred variant of the latter.)
% formatting is old style that is there because its what was used in python2. f-strings and str.format are new style, one evalulates immediately. The second is at call and allows you to create templates. str.format also has the benefit that it can allow positional or named templating.
i.e.
"{foo}=1".format(foo="foo") or "{}=1".format(foo). This can be done after an assignment s = "{foo}=1" ... s.format(foo=1)
Then the 4th you speak of is the actual Template module which just provides extra functionalities but isn't actually necessary.
-
I've been using Python since I started college and I'm making progress on it. .It seemed more understandable to me than other languages. :)
-
Why is it that, one this site, there are discussions that devolve into identity politics, and there's always an individual, or two, whose posts consist of spastic thoughts just vomited out.
Have you ever had a discussion in identity politics, or in plain politics, that didn't eventually devolve into spastic thoughts just vomited out?
I've found that applies to just about everything concerning opinions in general.
The opinions themselves, in my opinion (HA!), are basically worthless. What is interesting and important, is the reasons and experiences behind those opinions, because only by analyzing and comparing those, can one constructively build and rationally/logically examine ones own opinions. I do that all the time, and I've found it extremely useful and helpful in various aspects of my own life.
That's why I asked why anyone should concern themselves with programming language popularity in any way –– except possibly when learning ones first programming language, or desperately seeking employment as a programmer. I don't, but I know almost nothing about anything anyway, so I'm interested if anyone has some reasons I don't know about.
When the discussion devolves into combating opinions, I only participate when I believe the opinions are based on incorrect or non-factual or incomplete reasoning, and try to explain the issue, and ask how people think that affects their opinion. (However, I only do "technical" English, and have basically zero skill in such social subtext and niceties, so I fail English often here.) Especially opinions that differ from mine interest me, because their basis could be something I'm not aware of.
But when the opinions devolve (like in a recent Devuan thread) into "I'm a master in this, and I don't see the problems, so you must be wrong" without even checking the facts, I too get so irate I start spewing poor spastic counteropinions. Sorry about that, but we're all only human. Besides, online the bandwidth is too small to properly express the emotional content and context that would defuse/inhinit such emotive reactions and spastic outbursts. Even sarcasm and jokes are easily misunderstood.
-
Why is it that, one this site, there are discussions that devolve into identity politics, and there's always an individual, or two, whose posts consist of spastic thoughts just vomited out.
Have you ever had a discussion in identity politics, or in plain politics, that didn't eventually devolve into spastic thoughts just vomited out?
I've found that applies to just about everything concerning opinions in general.
The opinions themselves, in my opinion (HA!), are basically worthless. What is interesting and important, is the reasons and experiences behind those opinions, because only by analyzing and comparing those, can one constructively build and rationally/logically examine ones own opinions. I do that all the time, and I've found it extremely useful and helpful in various aspects of my own life.
That's why I asked why anyone should concern themselves with programming language popularity in any way –– except possibly when learning ones first programming language, or desperately seeking employment as a programmer. I don't, but I know almost nothing about anything anyway, so I'm interested if anyone has some reasons I don't know about.
When the discussion devolves into combating opinions, I only participate when I believe the opinions are based on incorrect or non-factual or incomplete reasoning, and try to explain the issue, and ask how people think that affects their opinion. (However, I only do "technical" English, and have basically zero skill in such social subtext and niceties, so I fail English often here.) Especially opinions that differ from mine interest me, because their basis could be something I'm not aware of.
But when the opinions devolve (like in a recent Devuan thread) into "I'm a master in this, and I don't see the problems, so you must be wrong" without even checking the facts, I too get so irate I start spewing poor spastic counteropinions. Sorry about that, but we're all only human. Besides, online the bandwidth is too small to properly express the emotional content and context that would defuse/inhinit such emotive reactions and spastic outbursts. Even sarcasm and jokes are easily misunderstood.
I find interesting to hear people’s opinion on programming languages, especially on those ones that are not widely used but have a strong niche application. For example, there is a strong hate towards COBOL in the academic world of computer science. However, if you talk to someone that works with it in some niche application, its ability of easily parsing complex file formats is usually pointed out as an important advantage to other language, making it a good choice for that over more general purpose languages like C. Additionally, it is not as archaic as it is usually seen, supporting OO programming.
Another example is Java. It is often criticized, but having an extensive standard library that supports making GUIs, internet connections, etc made it a good choice for cross platform programming. The same thing is happening nowadays with flutter (nobody likes having to rewrite the same application to support IOS, Android, desktop operating systems and web browsers nor using different languages for the same project).
I think those opinions can be useful to understand what can be improved. C and C++ where designed to be cross platform, yet the preference for Java and Futter for developing applications that need to run in several operating systems my show that there’s room for improvement. The same thing happens with electron apps the sacrifice performance and native GUIs to simplify development, showing that native GUIs might not be so important for the end user
-
I have known Python for almost 20 years and I am very surprised that a small macro language has reached such a level of popularity. Especially with the rapid moves of the ecosystem of programming languages.
That is what I wanted to comment on and learn from the opinions of others. I have read fanboys and haters and I think I have a more informed opinion now.
-
If it matters, I too use Python, mostly for the (graphical/windowed) user interface using Qt toolkit.
The reason there is that it lets end users tweak the user interface without having to recompile anything. All the heavy lifting is done in C; Python is surprisingly easy to interface to C libraries using pure Python, via the built-in ctypes (https://docs.python.org/3/library/ctypes.html) Python library. It makes it simple to provide one UI Python script, and for each operating system and hardware architecture a set of native C libraries doing the heavy lifting.
Python is by no means perfect. Python I/O is slow (compared to eg. C, awk, sed), and currently the most widely used interpreters only execute a single thread of Python code within the same process. For my use cases, that's okay; the GUI toolkit event loop is actually quite lightweight.
This is one case where 'popularity' matters. However, not popularity among developers, like Tiobe attempts to measure, but ease of use and gentle learning curve for end users. My reason for picking Python for this, is for end users to be able to adjust anything annoying in the UI themselves, and hopefully describe those changes upstream, so that the UI would hopefully evolve into something better, perhaps even diverge into multiple different but functionally compatible UIs. I've even looked into how to let users use completely different UIs, even let them switch the Python UI at run time without changing any settings or having to save open documents. Not just "skins", but fully customizable UIs you could select from a menu, populated from both system and user-private locations.
Also, when the UI is so easily scriptable, it makes it much easier to experiment with it. I particularly like the ID10T tests, where you observe how a (nontechnical) user tries to use the interface, when first introduced to the application. I've found such observations extremely interesting.
-
I have known Python for almost 20 years and I am very surprised that a small macro language has reached such a level of popularity. Especially with the rapid moves of the ecosystem of programming languages.
That is what I wanted to comment on and learn from the opinions of others. I have read fanboys and haters and I think I have a more informed opinion now.
Negative feedback of any kind = hater I guess. Thing is I'm just as interested in the why not's as the why's.
-
I used Tkinter once at work for developing a tool to control a testbench and it was a relatively good experience. There were many examples in forums and communicating with the board by usb was really easy. However, packaging the app was not a particularly good experience until I found Nuitka, whose developer helped me a lot by solving really quickly every problem I had and answering my questions. I highly recommend using it as it’s an awesome tool that not only is able to package everything into a single executable but, additionally, improves the performance of the program by compiling it to native code (it is a python to C transpiler).
Nevertheless, I have now switched to Godot, which is programmed in a python-like language and provides a really good experience editing the UI (I find WYSIWYG GUI building more natural than describing it using a programming language). It also supports loading libraries written in most programming languages (both, interpreted and compiled) and the program can be exported as a desktop, web and mobile application without changing almost anything
-
As a hobby programmer, I struggle each time when it comes to add a GUI to a Python program.
You made me curious about Godot, but google tells me that's a game engine, and the UI design has way too many details and parameters (https://docs.godotengine.org/en/stable/getting_started/step_by_step/ui_game_user_interface.html) to define for a normal window with buttons.
What I would like is to find a drag&drop WYSIWYG like the Forms editor that used to be in the Microsoft's VB5. You were drag and dropping windows, tabs and buttons, and a template code was automatically built for each button, and graphic elements were triggering events to be linked later with my code to be executed.
The forms editor was looking similar with this:
(http://rb.thevbzone.com/Intro_IDE1.png)
http://rb.thevbzone.com/l_intro.htm (http://rb.thevbzone.com/l_intro.htm)
Is there anything similar, drag&drop GUI forms designer for Python?
If not, what to use to create a GUI with buttons and menus for a Python code?
-
Is there anything similar, drag&drop GUI forms designer for Python?
Yes, but it depends on which windowing toolkit you want to use.
If you want to use tkinter, which is included in Python, you can use e.g VisualTK (https://visualtk.com/), an interactive web page that lets you build a simple window with buttons and text fields and such, that shows you the corresponding source code in Python.
For wxWidgets (wxPython), there are several, including wxFormBuilder (https://github.com/wxFormBuilder/wxFormBuilder). wxFormBuilder supports both code generation and XRC (https://wiki.wxpython.org/XRCTutorial) import/export.
For Qt, there is Qt Designer (https://doc.qt.io/qt-5/qtdesigner-manual.html). See here (https://build-system.fman.io/qt-designer-download) for a quick description for how it is used with Python.
For Gtk+, there is Glade (https://glade.gnome.org/). See here (https://python-gtk-3-tutorial.readthedocs.io/en/latest/builder.html) for a quick description for how it is used with Python.
Qt Designer, Glade, and wxFormBuilder create XML files describing the UI components (as .ui, .glade, and .xrc files, respectively). These files can be either embedded in your program or Python script, or loaded from an external file. (The details of connecting the events those components create to your Python methods differs a bit between the three. It's not complicated, but can be confusing, so is something I recommend reading through and understanding from the tutorials and examples, and remember if you switch between them.)
I'm not sure if FLTK has an UI designer.
All of the above do also support completely programmatic UI creation, too. In other words, at least tkinter, Qt, Gtk+, and wxWidgets support both defining the UI in separate file(s) using an XML-based format, or programmatically in your own code. I use code for simple forms using a table-like layout, and the UI XML files for more complex applications.
-
Any recommendation for the GUI toolkit du jour? What plays nicely with Matplotlib, can be easily installed using miniconda, and has Python user community 'momentum' behind it?
-
What I would like is to find a drag&drop WYSIWYG like the Forms editor that used to be in the Microsoft's VB5. You were drag and dropping windows, tabs and buttons, and a template code was automatically built for each button, and graphic elements were triggering events to be linked later with my code to be executed.
Every version of MS Visual Studio C++, C#, VB has this feature! You can use it for free.
-
As a hobby programmer, I struggle each time when it comes to add a GUI to a Python program.
You made me curious about Godot, but google tells me that's a game engine, and the UI design has way too many details and parameters (https://docs.godotengine.org/en/stable/getting_started/step_by_step/ui_game_user_interface.html) to define for a normal window with buttons.
What I would like is to find a drag&drop WYSIWYG like the Forms editor that used to be in the Microsoft's VB5. You were drag and dropping windows, tabs and buttons, and a template code was automatically built for each button, and graphic elements were triggering events to be linked later with my code to be executed.
The forms editor was looking similar with this:
(http://rb.thevbzone.com/Intro_IDE1.png)
http://rb.thevbzone.com/l_intro.htm (http://rb.thevbzone.com/l_intro.htm)
Is there anything similar, drag&drop GUI forms designer for Python?
If not, what to use to create a GUI with buttons and menus for a Python code?
For a window with just buttons Visual Basic is easier. However, Godot is really useful for developing tools that require manipulating some kind of image, as it includes most of the required functions. Most of the additional options are just used for adapting the UI to different screens in my experience, so it is easier to use than expected for a game engine. As they develop the GUI of the engine using it, I suppose that they care about making it easy to design applications with it
On the other hand, I recently read about a project called Qbasic64 which seems a good replacement for Visual Basic, although I haven’t tested it yet. Another mature alternative is Lazarus, but it uses Pascal instead of Basic. However, both are multi-window applications, which is something I’m not particularly a fan of
-
What I would like is to find a drag&drop WYSIWYG like the Forms editor that used to be in the Microsoft's VB5. You were drag and dropping windows, tabs and buttons, and a template code was automatically built for each button, and graphic elements were triggering events to be linked later with my code to be executed.
Every version of MS Visual Studio C++, C#, VB has this feature! You can use it for free.
Well, yes, but in fact no, I'm on Linux now (also VB5 compiler was not free IIRC) ... but wait, actually YES?!? :-DD
You made me curious and tried to open the oldest project I have with VB5 and a GUI. It's a TV remote, but from computer. Briefly, the GUI sends some carefully chosen numbers to a COM port, and at the com port is tied an IR Tx LED, so the TV is tricked to believe it's a genuine RC5 TV remote.
By the file dates, that was back in 2004, on a Windows XP, and guess what?!
I've tried running it today, 17 years later, and apparently it still works!
That's incredible, the exe is only 36 kiB.
And it's executing on a Linux machine! (Kubuntu 2004 LTS with WINE)
:o
-
Any recommendation for the GUI toolkit du jour? What plays nicely with Matplotlib, can be easily installed using miniconda, and has Python user community 'momentum' behind it?
Matplotlib has backends (https://matplotlib.org/stable/api/index_backend_api.html) for most windowing toolkits, including both agg and cairo subtypes for Qt, Gtk+, wxWidgets/wxPython, and tkinter (tk).
All four have lots of Python users, but in my opinion, right now (as of 2021) Python 3 + Qt 5 gives the best tools for this stuff. However, I've never been one to consider 'popularity' or 'momentum', and my opinion is weighed by my own personal preferences, and may have zero value for you because your preferences and needs likely differ.
(Python3+Qt5 does suffer from the fact that there are two separate sets of bindings, python3-pyqt5 (PyQt5) and python3-pyside2 (PySide2), and making a Python program compatible at run time with either one takes a few lines of extra Python code (a bit more if you use .ui files), and a bit of consideration how one uses the Qt5 namespaces –– Qt, QtCore, QtGui, QtWidgets, and QtSvg.)
The tkinter (tk) backend has the fewest dependencies, and is the easiest to get working.
For a fellow scientist who isn't interested in programming per se, but needs to to make better tools for themselves, I'd recommend starting with Python3 and matplotlib, and use the tk/tkinter UI built in to Python (and supported by matplotlib). Then, if and only if the UI widgets just don't cut it anymore, look into the other toolkits.
Doing a web search for "matplotlib" "tkinter" (https://duckduckgo.com/?t=ffab&q=%22matplotlib%22+%22tkinter%22&ia=web) shows lots of examples and tutorials; and the matplotlib site itself lists a few tutorials (https://matplotlib.org/stable/tutorials/index.html). One needs to trawl through to find the ones best suited for oneself. Note that matplotlib itself provides simple toolkit-agnostic widgets (https://matplotlib.org/stable/gallery/index.html#widgets) you can use if you want matplotlib to automatically use the best/first toolkit that is available!
(The textbox example (https://matplotlib.org/stable/gallery/widgets/textbox.html) does not mention, unfortunately, that one can provide a dictionary of variables and functions the textbox can utilize to the Python eval() (https://docs.python.org/3/library/functions.html#eval) function. If that dictionary contains '__builtins__':None, then built-ins like "open()" and import facilities cannot be used, only the objects in the global and local dictionaries supplied. In other words, it's rather easy to include all math (https://docs.python.org/3/library/math.html) functions (without any prefix), some named constants, and '__builtins__':None in the global dictionary, the current values of the variables in the local dictionary, and repeatedly evaluate the (possibly compiled, for speed!) expression safely in Python. A crafty person can even create their own local dictionary class object, overriding __getattr__ method, to auto-detect what variables the expression uses. Lots of options and power for not much effort!)
In all toolkits, there is a common theme: event-based programming.
Essentially, when you construct your window or windows, you pass control to the toolkit. The toolkit manages everything, and calls back to your code whenever something interesting happens. To construct a widget showing an interactive plot, you usually initially tell matplotlib which backend you want to use, and then either pass the widget matplotlib should draw into, or create a "canvas" or figure in matplotlib, and display that in some interactive widget. Understanding this model, and accepting "loss of full control" by passing the control to the widget toolkit, seems to be the biggest issue among those new to this kind of programming, in my experience!
-
Well, yes, but in fact no, I'm on Linux now (also VB5 compiler was not free IIRC) ... but wait, actually YES?!? :-DD
You made me curious and tried to open the oldest project I have with VB5 and a GUI. It's a TV remote, but from computer. Briefly, the GUI sends some carefully chosen numbers to a COM port, and at the com port is tied an IR Tx LED, so the TV is tricked to believe it's a genuine RC5 TV remote.
By the file dates, that was back in 2004, on a Windows XP, and guess what?!
I've tried running it today, 17 years later, and apparently it still works!
That's incredible, the exe is only 36 kiB.
And it's executing on a Linux machine! (Kubuntu 2004 LTS with WINE)
Cool ;D
I think that the VB development tools will work too on Linux/Wine.
And there is the Mono project which ports .NET to Linux.
-
Is there anything similar, drag&drop GUI forms designer for Python?
Yes, but it depends on which windowing toolkit you want to use.
If you want to use tkinter, which is included in Python, you can use e.g VisualTK (https://visualtk.com/), an interactive web page that lets you build a simple window with buttons and text fields and such, that shows you the corresponding source code in Python.
For wxWidgets (wxPython), there are several, including wxFormBuilder (https://github.com/wxFormBuilder/wxFormBuilder). wxFormBuilder supports both code generation and XRC (https://wiki.wxpython.org/XRCTutorial) import/export.
For Qt, there is Qt Designer (https://doc.qt.io/qt-5/qtdesigner-manual.html). See here (https://build-system.fman.io/qt-designer-download) for a quick description for how it is used with Python.
For Gtk+, there is Glade (https://glade.gnome.org/). See here (https://python-gtk-3-tutorial.readthedocs.io/en/latest/builder.html) for a quick description for how it is used with Python.
That was very helpful, thank you. :-+
Gave to each option a brief look and settled to start with Qt (PyQt5 + Qt5 Designer), mainly because I am using KDE Plasma which is based on Qt5, and because Qt Designer was included (found it installed already on my Kubuntu 20.04), but also because there is a commercial version of Qt Designer, so more hopes to be better maintained.
Tkinter seemed tempting, too, as included by default with Python. Thought the link to a cloud designer excluded that editor (very nice editor, but web based and that's a showstopper, all tools must be locally and able to work offline indefinitely). Looked for other offline tkinter GUI editors and only found apparently dead projects, with last update 5-10 years ago on sourceforge.
wxWidgets seemed complicated to me, and Gtk+ is the one used with Gnome AFAIK, but I like KDE more, so for now Qt5 it is, and it looks clean and easy to use (well, for a 'Hello World' complexity level they all look great, will see how well it goes for a slightly more complicated project).
So yeah, having fun with some PyQt5 and Qt 5 Designer this weekend, thanks! :)
-
My feeling is that Python is the 21st century ‘BASIC’
Easy to teach, convenient, and s-l-o-w.
the next language will be ‘Opinion’ - everybody has one, but it has limited application.
-
My feeling is that Python is the 21st century ‘BASIC’
Easy to teach, convenient, and s-l-o-w....
I think if you get a chance to use it much, you will find it, alone, is fast enough for a tolerable few things, and if it is not, it is still good for quick prototypes that reduce a project's total costs. At least that has been our experience.
-
My feeling is that Python is the 21st century ‘BASIC’
Easy to teach, convenient, and s-l-o-w....
I think if you get a chance to use it much, you will find it, alone, is fast enough for a tolerable few things, and if it is not, it is still good for quick prototypes that reduce a project's total costs. At least that has been our experience.
It’s also good for automating tasks that require coordinating several programs. For example, Salome uses it for allowing the user automating generating cad models, simulating them using different solvers and, finally, generating the required graphs. Scripting doesn’t need to be that fast to be useful
-
Or the new popular micropython microcontrollers. I had to evaluate a sensor IC, used the Pi Pico for it. 5 minutes later, I was logging it's data on uart. If I'm given the same task in C, 2 days later I'm still struggling setting up the GCC compiler into an IDE, or struggling with vendor specific libraries, with no progress on the actual task.
That has nothing to do with the language, everything with the infrastructure.
In the first case RPi dev has done the work for you.
Same goes for an arduino, you could evaluate the sensor in 5 minutes.
I myself have already for ten years my own kind of boards based on stm8 with c compiler and different small boards with standard peripherals like rs232/rs485 interface.
In my SVN I have for each board an minimal config project that I copy, rename and am up and running in 2 minutes to start coding for any sensor IN C.
You just need what you got and I do see the easyness of Python for testcode, quick demos, proof of concepts etc. I use it myself for all ethernet protocols just because C can be quite some overhead (unless you already have it).
So the result of a language becoming more popular is that more OS SW will be available and humankind as a whole can profit by that.
And most important, any language that lowers the barrier for new people to start coding and enjoying is a win-win IMO.
-
My feeling is that Python is the 21st century ‘BASIC’
Easy to teach, convenient, and s-l-o-w.
Slow in what way?
It has always been fast enough in all the applications in which I have used it.
For my, C it is slow because it takes a long time to program a script or a list handling or pattern recognition routines.
Total time = Programming time + Execution time
If it takes you three hours to make a program in c and half an hour to make the same program in Python and you are going to execute it 100 times with an execution time of 10 seconds for C and 20 seconds for Python, which one takes longer?
C total time: 11800 seconds
Python total time: 3800 seconds
do you see what I mean?
Edit:
Furthermore, I have not included the software maintenance time in the equation, which can be 10 times greater than the programming time, and in that field Python has a lot of advantage.
-
Total time = Programming time + Execution time
If it takes you three hours to make a program in c and half an hour to make the same program in Python and you are going to execute it 100 times with an execution time of 10 seconds for C and 20 seconds for Python, which one takes longer?
Development time vs. run time ... totally irrelevant comparison - apples and oranges. :palm:
-
If you have studied some economics you will know what are fixed costs and variable costs.
https://en.wikipedia.org/wiki/Fixed_cost
We are talking about time, not oranges neither apples.
-
My feeling is that Python is the 21st century ‘BASIC’
Easy to teach, convenient, and s-l-o-w.
the next language will be ‘Opinion’ - everybody has one, but it has limited application.
I still use bash and awk for my simple scripts. It works ok, and if bash is not the right
tool or too slow, i write a simple C command line program in half an hour to do the job.
Regarding speed:
It depends mainly on the programmers skill and on the runtime libraries and not on the
language.
There was a small competition a few months ago to solve a simple text processing problem:
https://www.mikrocontroller.net/topic/517864 (https://www.mikrocontroller.net/topic/517864)
Results are (sorted by Megabytes/second):
[0]$ cat run_WIN10_50kLines_500Bytes_20210610.log
test_foobar_lua2.lua Lua PeakWorkingSet=3.0 Seconds=39.71 MB/sec=28
test_mikro77_hash.gawk Gawk PeakWorkingSet=2.8 Seconds=34.29 MB/sec=33
test_mh_python3.py Python3 PeakWorkingSet=11.0 Seconds=14.89 MB/sec=76
test_hans.exe CPP PeakWorkingSet=2.8 Seconds=11.41 MB/sec=99
test_mikro77_n2.exe CPP PeakWorkingSet=2.8 Seconds=9.36 MB/sec=120
test_roger.exe CPP PeakWorkingSet=2.8 Seconds=7.84 MB/sec=144
test_mikro77_hash.exe CPP PeakWorkingSet=2.8 Seconds=7.24 MB/sec=156
test_heinzel.exe CPP PeakWorkingSet=2.7 Seconds=7.17 MB/sec=157
test_heinzel2.exe CPP PeakWorkingSet=2.7 Seconds=7.18 MB/sec=157
test_mh_yalu_python3.py Python3 PeakWorkingSet=1103.1 Seconds=7.04 MB/sec=160
test_mikro77_sort.exe CPP PeakWorkingSet=2.8 Seconds=6.98 MB/sec=162
test_philipp_strtok_fw.exe C PeakWorkingSet=11.1 Seconds=4.99 MB/sec=226
test_foobar3.exe C PeakWorkingSet=2.4 Seconds=4.65 MB/sec=242
test_philipp_strtok.exe C PeakWorkingSet=98.0 Seconds=4.40 MB/sec=256
test_philipp_strtok2.exe C PeakWorkingSet=10.2 Seconds=4.27 MB/sec=264
test_csharp_roger.exe C# PeakWorkingSet=21.6 Seconds=4.13 MB/sec=273
test_foobar2.exe C PeakWorkingSet=2.5 Seconds=4.06 MB/sec=278
test_jemand_rust.exe Rust PeakWorkingSet=6.7 Seconds=3.07 MB/sec=368
test_mikro77_hash.pl Perl PeakWorkingSet=6.9 Seconds=2.73 MB/sec=413
test_native_n2.exe C PeakWorkingSet=2.5 Seconds=0.67 MB/sec=1678
test_native_hash.exe C PeakWorkingSet=2.5 Seconds=0.41 MB/sec=2743
Perl and Python are both faster than C++ for large data fields (500 Bytes).
This was due the fact that the C++ native libraries are rather slow on Windows,
and Python and Perl have both good performing dictionaries (hash tables).
Note that the fast Python program needs a lot more RAM than the other programs.
If the data field is smaller (10 Bytes), the picture changes a lot becuause of
the larger overhead for each data field of the scripting languages:
[0]$ cat run_Win10_1000kLines_10Bytes_20210526.log
test_foobar_lua2.sh Lua Bytes=272 Seconds=23.05 MB/sec=21.5
test_hans.exe CPP Bytes=33792 Seconds=16.31 MB/sec=30.4
test_mikro77_hash.pl Perl Bytes=470 Seconds=13.77 MB/sec=36.0
test_mikro77_hash.gawk Gawk Bytes=184 Seconds=12.26 MB/sec=40.5
test_jemand_rust.exe Rust Bytes=1084416 Seconds=10.30 MB/sec=48.2
test_heinzel2.exe CPP Bytes=25600 Seconds=10.19 MB/sec=48.7
test_heinzel.exe CPP Bytes=25600 Seconds=10.10 MB/sec=49.1
test_mikro77_sort.exe CPP Bytes=34304 Seconds=8.27 MB/sec=60.0
test_mh_yalu_python3.sh Python3 Bytes=534 Seconds=8.05 MB/sec=61.6
test_philipp_strtok.exe C Bytes=10752 Seconds=7.88 MB/sec=62.9
test_roger.exe CPP Bytes=27136 Seconds=6.98 MB/sec=71.1
test_roger.exe CPP Bytes=27136 Seconds=6.94 MB/sec=71.5
test_mikro77_hash.exe CPP Bytes=29696 Seconds=6.39 MB/sec=77.6
test_mikro77_n2.exe CPP Bytes=25600 Seconds=5.81 MB/sec=85.4
test_foobar3.exe C Bytes=10240 Seconds=5.24 MB/sec=94.7
test_foobar2.exe C Bytes=10752 Seconds=4.93 MB/sec=100.6
test_csharp_roger.exe C# Bytes=127488 Seconds=4.07 MB/sec=121.9
test_native_n2.exe C,N^2 Bytes=15872 Seconds=2.03 MB/sec=244.3
test_native_hash.exe C,Simple Bytes=15872 Seconds=0.83 MB/sec=597.6
-
If you have studied some economics you will know what are fixed costs and variable costs.
https://en.wikipedia.org/wiki/Fixed_cost
We are talking about time, not oranges neither apples.
.. and you are going to execute it 100 times with an execution time of 10 seconds for C and 20 seconds for Python, which one takes longer?
:-DD
If you need the application to tun in 10 seconds for the required purpose, then Python will not even be acceptable no matter how much time it cuts from the development.
My goodness ... ::)
-
If you need the application to tun in 10 seconds for the required purpose, then Python will not even be acceptable no matter how much time it cuts from the development.
If you do not worry about the development time, it will be because you are not the one who should develop it or the one who should pay for it.
I would prefer that you give me arguments and not many laughs without major explanations. Do you have arguments to support your idea?
-
If you need the application to tun in 10 seconds for the required purpose, then Python will not even be acceptable no matter how much time it cuts from the development.
If you do not worry about the development time, it will be because you are not the one who should develop it or the one who should pay for it.
I would prefer that you give me arguments and not many laughs without major explanations. Do you have arguments to support your idea?
Here again without the entirely applicable laughing:
If you need the application to run in 10 seconds for the required purpose, then Python will not even be acceptable if the code takes 20 seconds execution time no matter how much time it cuts from the development.
Now if you cannot understand a simple requirement restriction such as that then I'll be happy to let others explain it.
-
I use Python to render my static web page with Sphinx (https://www.sphinx-doc.org/en/master/).
Normally it takes Sphinx between 5 and 10 seconds to render the new changes introduced in the web page, which takes me several minutes to write, perhaps hours. For me, those 5 or 10 seconds that I have to wait are not too long and saving 3 or 4 seconds would mean nothing.
Also with Python I can better understand the software and make the changes I need, without having to recompile the application.
I know of very few C applications that serve this purpose and I do know many in Python, Ruby or other scripting languajes (https://jamstack.org/generators/). Scripting languages may seem slow to some programmers, but they are fast enough for their purpose and very fast when you have to make changes or enhancements to the software.
-
I use Python to render my static web page
I would not recommend using C for webdevelopment no.
You are in some sort of domain where C does not fit so you should not use it.
But in for instance embedded applications on small microcontrollers you have all kind of restrictions like RAM size, time constraints, responsiveness to interrupts and tens more.
In those applications C is still king and python is used for other tasks like QT GUI where it does not matter when a user presses a button 20ms later the response is seen instead of 10ms.
So you are looking at it from your domain where C has no place and then think that is the whole world.
In a medium sized car there are more than 100 microcontrollers most running C. In an average house there are more than 80 microcontrollers in domestic devices most running C. Perhaps there is more than web dev ;)
-
I program microcontrollers in C too. And in assembler code in certain cases.
But now, we are talking about the speed of Python. SL4P says that Python is so s-l-o-w:
My feeling is that Python is the 21st century ‘BASIC’
Easy to teach, convenient, and s-l-o-w.
Python may be slower than C in runtime, but that's not a problem because in the total time spent in the program, Python turns out faster than C and is the reason why so many programs run in Python instead of C (for example the renders of web pages)
And in most cases the time spent on Python runtime is negligible.
-
Scripting doesn’t need to be that fast to be useful
Anything that is faster than manually rearranging Excel is useful. The impact of scripting mundane tasks that people do the "emulate paper way" is immense and there is a lot that remains the old way.
-
Some time ago I made a small macro to occupy a disk space that can be freed later in case the disk becomes full. 6GB of space that cannot be compressed. It can be done with many languages, but knowing Python did not complicate me more.
python -c "import random; fo=open('volume.txt', 'wb'); d = bytearray(random.getrandbits(8) for _ in range(1024*1024)); [fo.write(d) for i in range(1024*6)]; fo.close()"
It may be slower than C (1 minute of runtime), but why do I want more speed in a one-time routine?
Edit:
I know. You can do similar work with
dd bs=1024 count=6000000 </dev/urandom >volume.txt
It is only one example of multiple works that need low time programming, not at runtime.
Developing time matters.
-
Performs poorly here..
https://www.youtube.com/watch?v=D3h62rgewZM (https://www.youtube.com/watch?v=D3h62rgewZM)
-
So silly. You pick the tool for the job. Or do you use your screwdriver to clean your toilet?
If you do numerical computation in Python, you use numpy or scipy, which provide interfaces to efficient native libraries (written in C/C++/Fortran).
If you try to write say a linear algebra library in pure Python, it will be slow. So don't do that.
The main reason I use Python and not Ruby or Lua is that Python is so damned easy to interface to native libraries using either the built-in ctypes (https://docs.python.org/3/library/ctypes.html) module, or python-gi (PyGObject (https://pygobject.readthedocs.io/en/latest/)) for GObject-based libraries (with "gir", gobject introspection data). All you need is some *Python* code, and you can interface to just about any native library you want.
For example, with the gir1.2-gtk-3.0 (.typelib files describing Gtk+-3.0 library interfaces, language-independent not specific to Python) and python3-gi Debian packages, you only need
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
to get access to Gtk+ 3.0 from Python; and e.g.
win = Gtk.Window(title="Example Window")
win.show()
win.connect("destroy", Gtk.main_quit)
Gtk.main()
to create an empty application window.
Very little of the above is actually Python code: the lines containing gi runs a little bit of Python code to set up stuff, but most of it is in the C library (_gi.cpython*-linux-gnu.so in Linux). So, when running that sort of stuff, it does not matter if Python is slow, because you end up running very little Python code for normal tasks, with all the work done in native libraries. That is why I like Python for the stuff I use it for.
If I had to use Python for everything, for stuff like pseudorandom number generation using my own functions, it'd feel like cleaning toilets with a toothbush. I'd rather give up computing and become a woodworker or something.
-
Scripting doesn’t need to be that fast to be useful
Anything that is faster than manually rearranging Excel is useful. The impact of scripting mundane tasks that people do the "emulate paper way" is immense and there is a lot that remains the old way.
And at the same time, it is way easier to debug than excel formulas, which makes it really useful for automating complex calculations
-
Or do you use your screwdriver to clean your toilet?
Be honest. We've all had to at least once at some point.
-
Very little of the above is actually Python code: the lines containing gi runs a little bit of Python code to set up stuff, but most of it is in the C library (_gi.cpython*-linux-gnu.so in Linux). So, when running that sort of stuff, it does not matter if Python is slow, because you end up running very little Python code for normal tasks, with all the work done in native libraries. That is why I like Python for the stuff I use it for.
What I like is that I can change a few lines in some script, for cosmetic reasons or a simple tweak without having to locate the exact source and trying to figure out the whole build tool chain.
-
Or do you use your screwdriver to clean your toilet?
Be honest. We've all had to at least once at some point.
I have a poo stick for that that does not scratch the enamel. TMI? :P
I do use a flathead screwdriver occasionally to open the sort of plastic enclosures that have tabs that need to be pushed in for it to open, but either that's the proper tool (in electrical stuff, those tabs are designed to be pushed in with a flathead screwdriver), or the proper tool is so similar it's the nearest approximation without the proper tool. See, I did think carefully about the analog, even if it is a lame duck!
What I like is that I can change a few lines in some script, for cosmetic reasons or a simple tweak without having to locate the exact source and trying to figure out the whole build tool chain.
That's exactly why I like having the UI in Python with the actual work done in a native library, like I said. And even when the work is sooper seecret proprietary stuff, it is safe to license the UI code more loosely, allowing users to fix and experiment with it.
Using just an external .ui/.glade XML description for the interface widgets does not tend to really work for this. Typically, the bugs do not occur in the widget definitions/specs, but in the event handlers, and possibly setup code, like overriding style sheets based on display resolution, and such.
So, I do find it important to expose the UI even handler code too, not just the widget hierarchy.
This kind of use (in both our cases) is not really tied to Python per se, really; it's just that right now, Python seems to be best suited for this stuff overall, considering both development (ease of interfacing, portability across OSes, availability and maintenance of bindings to native libraries – provided by said libraries, not by Python developers) and use (not too slow, gentle learning curve for non-programmers). Definitely not optimal, just overall best suited for now. Yet, popularity among developers (topic of this thread) doesn't actually matter.
I do keep a lazy eye out for the newer languages, though, exactly because you never know when something better pops up, and is worthy of experimentation, perhaps help, and eventually adoption as the "new Basic". In my view, that's exactly what happened to Python, and it wasn't a step backwards.
-
Last monday I developed a program to compare text files. The algorithm is a bit complex for me, so I implemented in Python just to study how to correctly design it, and I ended up with less than 100 lines of Python code in a couple of days, spending 2 hours per day, so 4-5 hours in total to complete it.
When I then translated in C, I ended up with more than 900 lines of code, and I spend much more time, at least 5 days due to bugs and things that are "built-in" with Python but not in C.
As benefit the C-version of the code is something like 10X faster than the python version, and consume a quarter of ram.
But now there is a problem: the source of Python version is much easier to read and understood by my colleagues than the C version, so they first look at the Python version, and they consider it *THE* source of reference, and I think that I am in trouble now :o
-
Last monday I developed a program to compare text files. The algorithm is a bit complex for me, so I implemented in Python just to study how to correctly design it, and I ended up with less than 100 lines of Python code in a couple of days, spending 2 hours per day, so 4-5 hours in total to complete it.
When I then translated in C, I ended up with more than 900 lines of code, and I spend much more time, at least 5 days due to bugs and things that are "built-in" with Python but not in C.
As benefit the C-version of the code is something like 10X faster than the python version, and consume a quarter of ram.
But now there is a problem: the source of Python version is much easier to read and understood by my colleagues than the C version, so they first look at the Python version, and they consider it *THE* source of reference, and I think that I am in trouble now :o
Sometimes the C standard library feels too small. Being small can be useful for portability, but having to use another library (or develop your own function) just to be able to multiply vectors is sometimes a bit annoying. It is something so common that it could be handled by the compiler
-
Last monday I developed a program to compare text files. The algorithm is a bit complex for me, so I implemented in Python just to study how to correctly design it, and I ended up with less than 100 lines of Python code in a couple of days, spending 2 hours per day, so 4-5 hours in total to complete it.
When I then translated in C, I ended up with more than 900 lines of code, and I spend much more time, at least 5 days due to bugs and things that are "built-in" with Python but not in C.
As benefit the C-version of the code is something like 10X faster than the python version, and consume a quarter of ram.
But now there is a problem: the source of Python version is much easier to read and understood by my colleagues than the C version, so they first look at the Python version, and they consider it *THE* source of reference, and I think that I am in trouble now :o
No just write your own library , mimicking the python function calls and you're fine.
If that is what you want is a nother thing. But that is the main problem with external libraries, you never know how much overhead you take with you.
Also the biggest problem with newbies in small embedded applications, you just don't want to use a float or you get bloat.
-
Performs poorly here..
https://www.youtube.com/watch?v=D3h62rgewZM (https://www.youtube.com/watch?v=D3h62rgewZM)
I’ve been following these videos and the results of languages that aren’t C or C++ have sometimes been affected by under-optimizations caused by the influence of being the developer unfamiliar with them. For example, Ada performed really bad compared to Pascal, but someone at comp.lang.ada seemed to have gotten a 5x performance improvement by carefully tuning the implementation (using types that could be accessed faster, etc)
-
As benefit the C-version of the code is something like 10X faster than the python version, and consume a quarter of ram.
Great example! The point is that you can do both, C and python, know the differences and therefore are able to decide which one is the better solution for a given problem. Someone who learns just one programming language can't do that - he is locked in.
-
Performs poorly here..
Because his code is written to be slow.
It is obvious code that is ported from C without fully understanding all the features of the language.
He doesn't even use list comprehension.
If you follow the github link he provided it leads here:
https://github.com/davepl/Primes/tree/drag-race/PrimePython/solution_3
So an actual python programmer rewrote it. If you look at this benchmark, C was ~2500, python ~1500, bigger better.
I will argue that even the new code with numpy is inefficient, there seems to be a lot of inefficient 1 line function calls, and the data structure is weird. But it is kept that way to keep the code reminiscent to the original. If you write this code from scratch you wouldn't write it this way.
Bad code, 350K views. :palm:
-
Last monday I developed a program to compare text files.
Even in C, there are multiple ways to read lines from a stream (as in C stream: a file, pipe, socket, character device, or similar).
Most learn to do this kind of low-level stuff with fgets(), opendir(), readdir(), closedir(), but for Linux and other POSIXy systems, that's the wrong approach. (Limited line lengths, and directory traversal prone to issues if the directory tree is modified during traversal.)
One gets much better results with POSIX getline() (https://man7.org/linux/man-pages/man3/getline.3.html)/getdelim() (https://man7.org/linux/man-pages/man3/getdelim.3.html), nftw() (https://man7.org/linux/man-pages/man3/nftw.3.html), scandir() (https://man7.org/linux/man-pages/man3/scandir.3.html), and glob() (https://man7.org/linux/man-pages/man3/glob.3.html); and the fts functions (https://man7.org/linux/man-pages/man3/fts.3.html) that originated in 4.4BSD, but are nowadays available in many standard C libraries, including in Linux. With these, you get dynamic line length support and the most robust filesystem traversal. (With getdelim(&line, &size, '\0', stream) you can read nul-delimited streams; especially useful for handling file names and paths provided by a subprocess or utility, similar to e.g. find ... -print0 and xargs -0 utilities.)
When random access to each line is required, it is more efficient to read or memory-map the entire file into a continuous chunk of memory (via <unistd.h> open()/read()/close(), or more portably using <stdio.h> fopen()/fread()/fclose() (I've shown an example here (https://stackoverflow.com/a/44894946/17202676)); then separately terminate and trim each line, storing a pointer to each line in a separate array. This ensures the data remains continuous in memory, and that data locality can really help cache behaviour when doing e.g. diff-type work. (Personally, I use the actual diff utility to do diffs, though, and read the output via a pipe or a socket.)
Yet, all of that pales when considering the effect of properly choosing the algorithm one implements.
My favourite example (I've described at least three times on these forums already) is the traditional sort utility implementation in C.
The task is to read a source file, and output the lines in sorted order (ascending or descending, depending on command-line options).
The first question an implementer should ask, is whether the utility will be used in background processes, or by humans, because the two have different definitions of "efficiency". In processes running on the background, only when the machine is otherwise idle, you want to minimize the CPU time used and memory needed to accomplish the task. For human tools, you want to minimize the wall clock time used.
In a background task utility, you'd read the file or memory-map it, allocate and create an array of pointers to each line, then sort the array of pointers using a suitable sorting function, and finally emit the lines in the sorted order.
To minimize the wall clock time used by a sort utility, you trade a bit of CPU time used, to accomplish the task in shorter elapsed real world time. You do this by realizing that I/O, reading the data from the storage, is the main cause of latency; real-world delay, when no "work" is done. So, instead of reading the file, you read it line by line, and each line you obtain, you stick into a self-sorting data structure. I use a binary heap, because the code is simple, and it yields a very efficient data structure for this even in the worst cases. (For uniform random input, each addition involves approximately e≃2.718 swaps in the tree (in the percolate stage after insertion.)
Effectively, when the last line is read, the lines are already in sorted order, and can be output immediately. Since the binary heap (or whatever data structure you use) will use slightly more CPU time than an offline sort function, you end up using more CPU time; but that CPU time is used while the process would otherwise be waiting for data to arrive from the storage, so the real-world time taken by the entire process is shorter.
This kind of complete change in approach is easier in higher-level scripting languages like Python, Ruby, or Lua, because there is less code, and therefore less "inertia"; less perceived 'cost' of considering doing something different, just to see if it works better. Converting code from one language to another usually yields poor results, because every one has their "native" approach, their own paradigm, as to how things are done; "how things oughta look like". So don't do that either.
(I've mentioned I write a LOT of C code. Most of that is because I experiment with stuff, just to see if they work better. I don't always do it just for my own interest of for technical interest; I've also looked at e.g. what should a linear algebra library API look like in pure C, to let beginners in C write efficient code. In my observations on unsuspecting victims test users, I found that using a scripting language with lightweight but efficient bindings to the native library yields better results, unless the point is to help them become better programmers as opposed to just enhancing their workflow with customized tools.)
For the above sort utility, I haven't checked how a Python version would look like, because as I said, Python I/O is relatively slow, so it isn't the proper language for implementing this. For scripting text files/streams, I often reach for sed, gawk, or mawk, if there isn't a command-line tool already available to do the job. (mawk tends to be faster than gawk, when you do not need the GNU awk extensions.) Some of the utilities, like diff, implement surprisingly efficient algorithms, and are hard to beat in terms of speed and efficiency; others (like sort) are more geared towards multifunction use, and can easily be beaten in specific scenarious using specific comparison metrics.
-
Oh duck I write long posts. Sorry. :-[
-
I remember a time when you tried to save up to a bit to free up as much memory as possible and make good use of it.
Today such efforts are pointless because memory has been reduced in price by a factor of 1,000,000.
The same goes for the efficiency of the algorithms. In many cases it is irrelevant whether a user-initiated file comparison takes 0.2 seconds or 0.02 seconds. The user will not notice the difference.
That is the reason why many web pages are served by PHP or Python. Speed does not matter so much as ease and flexibility in software development.
Last monday I developed a program to compare text files.
...
As benefit the C-version of the code is something like 10X faster than the python version, and consume a quarter of ram.
How long does Python take to do an average comparison between files?
-
Yet, all of that pales when considering the effect of properly choosing the algorithm one implements.
In chapter 7 of his 1986 book Programming Pearls* (ISBN 0-201-10331-1) Jon Bentley of Bell Labs gives a wonderful example. The problem is:
Given a vector X of N real numbers, find the maximum sum of any contiguous subvector of the input (the numbers in X may be positive, negative, or zero)
Jon describes four algorithms of increasing subtlety and deviousness. The slowest is O(N^3), the fastest is O(N). The fastest algorithm, implemented in Tandy BASIC on on Radio Shack TRS-80 model III, was pitted against the slowest, written in hand-tuned Cray FORTRAN on a Cray-1. For values of N (i.e. the length of the vector) above a couple of thousand, the TRS-80 was faster.
* The book is a collection of reprints from Jon's column in Communications of the ACM
-
I remember a time when you tried to save up to a bit to free up as much memory as possible and make good use of it.
Today such efforts are pointless because memory has been reduced in price by a factor of 1,000,000.
The same goes for the efficiency of the algorithms. In many cases it is irrelevant whether a user-initiated file comparison takes 0.2 seconds or 0.02 seconds. The user will not notice the difference.
That is the reason why many web pages are served by PHP or Python. Speed does not matter so much as ease and flexibility in software development.
Last monday I developed a program to compare text files.
...
As benefit the C-version of the code is something like 10X faster than the python version, and consume a quarter of ram.
How long does Python take to do an average comparison between files?
Try it yourself:
import filecmp
print(filecmp.cmp("file1.txt", "file2.txt", shallow=True))
-
When I've created some new hardware with PC interface (serial, usb, ethernet..), Python is the perfect fit for doing a demo program to demonstrate hardware interfacing for the software guys. I don't care if they are developing their GUI stuff in C#, Visual C++, Delphi...whatever, they all find Python readable and I rarely get asked interface questions.
-
How long does Python take to do an average comparison between files?
on 200Mbyte of files, we are talking about 12 minutes vs 40-50 minutes.
-
Oh duck I write long posts. Sorry. :-[
it's always useful, an it's always a pleasure :-+
Just, when posts are long, I save them in a draft-clipboard (it's a x11 program, like "x-stickers") to carefully read them later at home ;D
-
Oh duck I write long posts. Sorry. :-[
it's always useful, an it's always a pleasure :-+
Just, when posts are long, I save them in a draft-clipboard (it's a x11 program, like "x-stickers") to carefully read them later at home ;D
Well, that's what you should probably do when writing such long posts actually...
I just wrote a longish post about the RP2040 a couple minutes ago. And lost ALL its content upon the unfortunate press of a key. No amount of CTRL-Z or back/forward got me my text back. I just gave up, not feeling like rewriting it all. Seeing how Nominal Animal has the patience of writing such long posts, I'm wondering if that has already happened to him, or if he writes his posts first in a text editor... Losing a whole detailed post upon the press of a single key with no way to get it back is pretty infuriating. |O ;D
-
And lost ALL its content upon the unfortunate press of a key
I'm sorry to hear, I know how frustrating is because it happened to me too.
I recently designed a couple of web application programs and for one of them I also implemented a java-script helper which formats things correctly (list, arrays, url, pics, ...) and every second automatically selects and copies to the clipboard all text in the text-area
Not perfect, and it's just a small step, but it has already saved my day in a couple of unfortunate button presses.
The x11-sticker program is much more useful, and I really use it as stickers to keep notes of things.
-
I do have a new empty text document in Pluma (text editor I use for plain text, including programming short snippets) always within a single keystroke (and a single-character alias, g, in my shell).
I started doing that when I started writing complex MathJax answers at math.stackexchange.com; sometimes the post editor would just stop rendering the MathJax correctly (after a syntax error, usually), and copying the text to an editor, then canceling the post and reopening a new one, and posting the text back, resolves the issues.
Indeed, if in SMF (as is used here) the Preview button used POST instead of AJAX, it would mean that a copy of the last preview would be in cache, and would be recoverable by simply going back one page in history. Of course, it would be slower and more I/O on the server, as the rest of the page would be reloaded as well.
If I was prone to keystrokes that caused me to lose valuable content, I'd probably make a browser extension or X11/Wayland utility to copy the contents of the currently focused widget in the currently focused application to a helper buffer, like DiTBho described. Much like a screenshot utility, but only for the text content of the currently active text box or other widget. A browser extension would be simpler, and could use a time-based on-disk cache.
-
I do have a new empty text document in Pluma (text editor I use for plain text, including programming short snippets) always within a single keystroke (and a single-character alias, g, in my shell).
I use Pluma for light scripting also. I've got a dark theme and it highlights code and shows line numbers. It the one that annoys me the least. It doesn't seem to like -really- big log files.
-
And lost ALL its content upon the unfortunate press of a key.
If your browser is a FireFox clone (maybe Chrome also, but I don't use it so don't know) there is an addon for this:
https://addons.mozilla.org/en-GB/firefox/addon/textarea-cache/
Sits on your toolbar or wherever and just caches textarea doobreys in the background. If you have an upset you pop it open and paste the stuff into the now blank box. Simples.
-
How long does Python take to do an average comparison between files?
on 200Mbyte of files, we are talking about 12 minutes vs 40-50 minutes.
12 minutes? Do you know why it takes so long? What sort of system are you running on?
I just did a text compare of 2551 text files (656 MBytes total) using a commercial file comparison program (Beyond Compare) and it took 13 seconds. 1899 of the files contained differences. I believe the software was developed using Delphi. One reason for the difference might be that Delphi is particularly good at string manipulation as the core string processing libraries are written in assembler.
-
I do have a new empty text document in Pluma (text editor I use for plain text, including programming short snippets) always within a single keystroke (and a single-character alias, g, in my shell).
I use Pluma for light scripting also. I've got a dark theme and it highlights code and shows line numbers. It the one that annoys me the least. It doesn't seem to like -really- big log files.
From the old bad days when I did DNS administration for a country code top level domain i ${EDITOR}, I can tell that GNU emacs is pretty fast, while nvi is not. I did persist in using nvi, though, because it is line oriented, and therefore eminently suited to data like the zone file format. Actually it was opening the file that was the problem; once in memory/mmap it was fairly snappy.
I still use vi for nearly all system-close editing (where a line-oriented approach is prevalent), except really small jobs on the console, where it is beneficial to see shell history; then "ed" (which is the the standard editor!) wins. Longer pieces of code end up in Emacs (I run Aquamacs on OS X). Another exception is TEX writing, which thanks to AUCTEX packages also is best done in Emacs. I've made a template in LATEX that emulates the company-mandated M$Word standard document, with a few extensions of my own, so I quickly can generate text that in appearance, as usual for TEX derivates, surpasses everything made in Word. And it does not mess up the table of contents, one is not tempted to "just make the font bigger" to create a section header, it does not jump around in margins. It simply works.
Edit: If I'm in the sad position of having to use a Linux system, especially Ubuntu (which is Zulu for "I can't install Devuan") the first things that happen are the complete eradication of nano and vim, after which nvi and ed are installed.
-
Edit: If I'm in the sad position of having to use a Linux system, especially Ubuntu (which is Zulu for "I can't install Devuan") the first things that happen are the complete eradication of nano and vim, after which nvi and ed are installed.
Up until the early 90's ED was the only editor installed and allowed to be used on the systems I worked on. Once we moved to screen editors, I preferred Vi over EMACS simply because VI was always available and EMACS mostly was not. These days my editor of choice is VIM. I'm curious as to what advantage you see NVI has over VI? NVI was a implementation of VI.
-
I'm not anti vim or vi or emacs. I'll use vim at a pinch if I've done something horrendous.
I like Pluma cos it has a dark theme which I like and it highlights text and if you ask it nicely, the appropriate source. But yeah vim with green on black as long as it's big and contrast-y, I'm a happy guy.
edit: what I tried to say in the above sentences is I would really like to like full IDEs. But they wind up annoying me. The one aesthetic thing I wanna tweak is not possible. So back to text editor.
-
Edit: If I'm in the sad position of having to use a Linux system, especially Ubuntu (which is Zulu for "I can't install Devuan") the first things that happen are the complete eradication of nano and vim, after which nvi and ed are installed.
Up until the early 90's ED was the only editor installed and allowed to be used on the systems I worked on. Once we moved to screen editors, I preferred Vi over EMACS simply because VI was always available and EMACS mostly was not. These days my editor of choice is VIM. I'm curious as to what advantage you see NVI has over VI? NVI was a implementation of VI.
I only want a "vi", I do not want something that has closet dreams of becoming Emacs. Therefore "vim" goes to the bit bucket. And "nano" is a text file destroyer that I've hated since last century. It breaks lines in files without being asked to. That and that alone is enough to evict it by force.
-
And lost ALL its content upon the unfortunate press of a key.
If your browser is a FireFox clone (maybe Chrome also, but I don't use it so don't know) there is an addon for this:
https://addons.mozilla.org/en-GB/firefox/addon/textarea-cache/
Sits on your toolbar or wherever and just caches textarea doobreys in the background. If you have an upset you pop it open and paste the stuff into the now blank box. Simples.
WOW, this somehow operates like my java-script text editor, but it's much more comfortable this way :D
-
I only want a "vi", I do not want something that has closet dreams of becoming Emacs. Therefore "vim" goes to the bit bucket.
Yes, I understand where your are coming from. VIM keeps growing mostly with stuff nobody actually uses. But I've got used to syntax highlighting and ctags in vim so it would be a hard switch back to vi.
-
Performs poorly here..
Because his code is written to be slow.
It is obvious code that is ported from C without fully understanding all the features of the language.
He doesn't even use list comprehension.
I had a direct demonstration of this just yesterday.
A friend/colleague of mine was struggling with some data analysis task in Pyhton - he's a learner in both.
The code he wrote was taking hours to complete, and he asked me for some guidance.
I'm not an expert in either subject matter, but as soon as I saw his code I told him: "You have a number of explicit nested for loops. Turn them into list comprehension and slicing, check the library (pandas) for some smart indexing".
Twelve hours to a couple of minutes.
-
I had a direct demonstration of this just yesterday.
A friend/colleague of mine was struggling with some data analysis task in Pyhton - he's a learner in both.
The code he wrote was taking hours to complete, and he asked me for some guidance.
I'm not an expert in either subject matter, but as soon as I saw his code I told him: "You have a number of explicit nested for loops. Turn them into list comprehension and slicing, check the library (pandas) for some smart indexing".
Twelve hours to a couple of minutes.
The thing is, in a "real" programming language it doesn't matter whether you use a built in construct such as foreach in a container, or write it out explicitly yourself -- the speed will be the same either way (assuming the same algorithm).
It's still good to have things such as foreach and iterators and list comprehensions and array slicing in a real programming language, but it's notational convenience only -- less text to write, less to read. In Python / Ruby / Perl it's critical to use that built in high level stuff as much as possible.
-
I had a direct demonstration of this just yesterday.
A friend/colleague of mine was struggling with some data analysis task in Pyhton - he's a learner in both.
The code he wrote was taking hours to complete, and he asked me for some guidance.
I'm not an expert in either subject matter, but as soon as I saw his code I told him: "You have a number of explicit nested for loops. Turn them into list comprehension and slicing, check the library (pandas) for some smart indexing".
Twelve hours to a couple of minutes.
The thing is, in a "real" programming language it doesn't matter whether you use a built in construct such as foreach in a container, or write it out explicitly yourself -- the speed will be the same either way (assuming the same algorithm).
It's still good to have things such as foreach and iterators and list comprehensions and array slicing in a real programming language, but it's notational convenience only -- less text to write, less to read. In Python / Ruby / Perl it's critical to use that built in high level stuff as much as possible.
I'm sorry, but but what you are saying is bullshit, and goes against basic principles of computer science.
Saying that "No matter what sort of data structure I choose, the program will be fast" is fundamentally wrong, just try to find some data in a binary tree vs an array.
-
Saying that "No matter what sort of data structure I choose, the program will be fast"
He didn't say that, did he? Looked to me like he said that using foreach is basically the same as typing it out explicitly (that is, a[0]=1, a[1]=2, etc) when it comes to speed.
-
According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).
Many times the problem is not the speed but the management of 80% of the code, very extensive and prone to maintenance difficulties. That's where Python stands out and is better than C.
-
Many times the problem is not the speed but the management of 80% of the code, very extensive and prone to maintenance difficulties. That's where Python stands out and is better than C.
Really? Python better for maintenance? Maybe that is true, but I would certainly like to see a reasonable study proving that point. Because I'm not so convinced at this point.
-
There are many programmers who think this way. But it's just an opinion, I don't know of any study to prove it.
Edit:
Some interesting links
https://www.stxnext.com/python-vs-other-programming-languages/ (https://www.stxnext.com/python-vs-other-programming-languages/)
https://hilton.org.uk/blog/maintenance-expressive-languages (https://hilton.org.uk/blog/maintenance-expressive-languages)
https://www.forbes.com/sites/forbestechcouncil/2020/04/10/reducing-maintenance-costs-with-functional-programming/?sh=36cee59bf643 (https://www.forbes.com/sites/forbestechcouncil/2020/04/10/reducing-maintenance-costs-with-functional-programming/?sh=36cee59bf643)
-
I agree that maintenance is a serious problem, but:
My own observations indicate that most developers are much more interested in creating new stuff than in maintaining stuff, including stuff they themselves created, regardless of the programming language used. Because more capable developers are in high demand, they can simply switch to more interesting stuff, and let others deal with the maintenance.
The problem is, new developers do not usually have the understanding of the projects to deal with design problems. They do catch simpler bugs – stuff like off-by-one errors, typos, edits that miss a related expression or two – but when they become experienced enough to deal with design problems, they already can choose to move to creating new stuff instead.
I do not know if the programming languages differ in the bug complexity or amount of bugs that new developers can handle. (That is, I personally cannot tell if they do differ in this.)
In some ways it seems likely that languages with shallower learning curve might let new developers fix more stuff, but I do not know if bugs in different languages are similar in complexity. In Python and in Perl, the most efficient expressions use their own notation and paradigms, and are unlikely to be fully understood and easily manipulated by the newest programmers; in analogous terms, I'd say it is just as likely for their developers to just move to new projects from maintaining/fixing existing stuff earlier along the learning curve.
I wonder if those who hire programmers have learned to check how long the developers have actively maintained the projects they showcase as their own, as opposed to just dumped it on the web as an example of their development skills and passed on to other stuff? That is, whether they even care about bugs in their own code, or just want to create new stuff and leave the tedious maintenance and bug-fixing to other people?
-
According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
That's true if you write all the code in the same language (or at least similarly efficient languages).
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).
Let's try a thought experiment.
We have some task written in C (or Java or C#) that takes 10 seconds to run:
8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain
We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:
8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part
Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.
I sure hope it's a LOT easier to maintain to make it worth it.
Or, it had better be more like 99%/1% in the C version, not 80%/20%.
(Of course 108 seconds is better than the 500 seconds it would take if you wrote it all in Python ... but 10 seconds is even better)
-
According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
That's true if you write all the code in the same language (or at least similarly efficient languages).
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).
Let's try a thought experiment.
We have some task written in C (or Java or C#) that takes 10 seconds to run:
8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain
We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:
8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part
Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.
I sure hope it's a LOT easier to maintain to make it worth it.
Or, it had better be more like 99%/1% in the C version, not 80%/20%.
Yes Bruce, but it depends on the deployment. If it finds it's way into the hands of normies like me, whilst, yes, C is preferable, a python script with low bandwidth in the grand scheme of things can be adjusted easily without having to figure out what the dev was smoking with the whole C tool chain.
-
I'm sorry, but but what you are saying is bullshit, and goes against basic principles of computer science.
Saying that "No matter what sort of data structure I choose, the program will be fast" is fundamentally wrong, just try to find some data in a binary tree vs an array.
No, I'm assuming the same data structure/algorithm in both cases. Just written by you vs written by whoever wrote the Python interpreter or external C library.
-
Yes Bruce, but it depends on the deployment. If it finds it's way into the hands of normies like me, whilst, yes, C is preferable, a python script with low bandwidth in the grand scheme of things can be adjusted easily without having to figure out what the dev was smoking with the whole C tool chain.
If you find C dangerous, Java and C# are just as n00b safe as Python, but run within a factor of 2 of C. Probably within a factor of 1.2 much of the time.
-
Yes Bruce, but it depends on the deployment. If it finds it's way into the hands of normies like me, whilst, yes, C is preferable, a python script with low bandwidth in the grand scheme of things can be adjusted easily without having to figure out what the dev was smoking with the whole C tool chain.
If you find C dangerous, Java and C# are just as n00b safe as Python, but run within a factor of 2 of C. Probably within a factor of 1.2 much of the time.
Whilst I don't get to code anywhere near as much as I'd like, no I don't find C dangerous for my own purposes.
But when trying to play the part as a distro package maintainer, I'm not going to re-write the whole thing back into C just because the person who wrote some wrapper chose the wrong language. I'm putting it to you that they did indeed choose the right language because of the included high level stuff that does the heavy lifting but the simple little tweaks such as wonky file locations can be made without having to upset the whole apple cart.
I realise embedded is a different kettle of fish.
-
Why is it that, one this site, there are discussions that devolve into identity politics, and there's always an individual, or two, whose posts consist of spastic thoughts just vomited out.
Have you ever had a discussion in identity politics, or in plain politics, that didn't eventually devolve into spastic thoughts just vomited out?
I've found that applies to just about everything concerning opinions in general.
The opinions themselves, in my opinion (HA!), are basically worthless. What is interesting and important, is the reasons and experiences behind those opinions, because only by analyzing and comparing those, can one constructively build and rationally/logically examine ones own opinions. I do that all the time, and I've found it extremely useful and helpful in various aspects of my own life.
That's why I asked why anyone should concern themselves with programming language popularity in any way –– except possibly when learning ones first programming language, or desperately seeking employment as a programmer. I don't, but I know almost nothing about anything anyway, so I'm interested if anyone has some reasons I don't know about.
When the discussion devolves into combating opinions, I only participate when I believe the opinions are based on incorrect or non-factual or incomplete reasoning, and try to explain the issue, and ask how people think that affects their opinion. (However, I only do "technical" English, and have basically zero skill in such social subtext and niceties, so I fail English often here.) Especially opinions that differ from mine interest me, because their basis could be something I'm not aware of.
But when the opinions devolve (like in a recent Devuan thread) into "I'm a master in this, and I don't see the problems, so you must be wrong" without even checking the facts, I too get so irate I start spewing poor spastic counteropinions. Sorry about that, but we're all only human. Besides, online the bandwidth is too small to properly express the emotional content and context that would defuse/inhinit such emotive reactions and spastic outbursts. Even sarcasm and jokes are easily misunderstood.
For what its worth, I wasn't talking about you
-
According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
That's true if you write all the code in the same language (or at least similarly efficient languages).
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).
Let's try a thought experiment.
We have some task written in C (or Java or C#) that takes 10 seconds to run:
8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain
We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:
8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part
Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.
I sure hope it's a LOT easier to maintain to make it worth it.
Or, it had better be more like 99%/1% in the C version, not 80%/20%.
(Of course 108 seconds is better than the 500 seconds it would take if you wrote it all in Python ... but 10 seconds is even better)
You're grossly over estimating speed differences. There's plenty of examples floating around of people writing some numerical routine in pure C/C++ and it being slower than numpy because said person doesn't know how to write the code to squeeze every bit of optimization from the compiler.
Edit: I don't even understand what you are arguing here. Its like you're completely ignoring that fact that for super hot spots in the code you can write C/C++ and use it directly in the python code.
People don't write python for speed, they write python for the user interface experience. The speed comes from writing stuff in C/C++
-
If there's one thing I've learned as a drive-by coder, optimization in code is never where you expect it to need to be.
-
- far more suited to long term results instead of newbie appeals
These don't have to be exclusive. The long term result of Perl's obtuseness and Python's newbie appeal will be Perl becoming ever more niche and losing ever more ground to Python, it being more suited in the abstract of a world filled with Perl specialists helps Perl little in the real world to prevent this.
In the end the increasing speed of computers was going to make scripting ever more important, a scripting language would end up on top eventually and this is a winner take all world.
-
According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
That's true if you write all the code in the same language (or at least similarly efficient languages).
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).
Let's try a thought experiment.
We have some task written in C (or Java or C#) that takes 10 seconds to run:
8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain
We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:
8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part
Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.
I sure hope it's a LOT easier to maintain to make it worth it.
Or, it had better be more like 99%/1% in the C version, not 80%/20%.
(Of course 108 seconds is better than the 500 seconds it would take if you wrote it all in Python ... but 10 seconds is even better)
You're grossly over estimating speed differences.
No, that's accurate. If you write the same algorithm the same way in C and Python then the Python is about 50 times slower. That's well-established e.g. see
https://www.youtube.com/watch?v=D3h62rgewZM (https://www.youtube.com/watch?v=D3h62rgewZM)
People argue he's not using idiomatic Python and THAT'S MY POINT. Python has a huge penalty for Just Writing Code instead of using the built-in high level abstractions (that were written by someone else, in C).
There's plenty of examples floating around of people writing some numerical routine in pure C/C++ and it being slower than numpy because said person doesn't know how to write the code to squeeze every bit of optimization from the compiler.
That just means the person writing the C/C++ doesn't know as much about numerical programming as the person who wrote numpy. Numpy can't be faster than C because numpy *is* C. Using an appropriate algorithm and coding is of course important, and if you're not competent to write that yourself then you should use a library.
Numerical libraries are also available in C. NAG, LINPAK, BLAS etc have been around for many decades. Hell -- you can use numpy from a C program too, if you want to.
People using numpy are probably somewhere around 99.99% of the executed operations are in numpy, 0.01% in Python. That's very far from 80/20.
Edit: I don't even understand what you are arguing here. Its like you're completely ignoring that fact that for super hot spots in the code you can write C/C++ and use it directly in the python code.
How can I be ignoring it, when that's exactly the whole thing I'm talking about?
-
... People don't write python for speed, they write python for the user interface experience. The speed comes from writing stuff in C/C++....
I have a question. I am never short of problems that need solving. I write in Python, and other high level languages, to solve a problem more thoroughly and faster, so that I can move on to the next one. Is that what you mean by the user interface experience?
-
... People don't write python for speed, they write python for the user interface experience. The speed comes from writing stuff in C/C++....
I have a question. I am never short of problems that need solving. I write in Python, and other high level languages, to solve a problem more thoroughly and faster, so that I can move on to the next one. Is that what you mean by the user interface experience?
It simply means that for your workload, the compute time is small compared to the problem formulation time, making time-to-solution more dependent on "write fast" than "compute fast".
With the speed of modern computers taken into consideration (anything built the last 20 years excluding microcontrollers) this is the situation for nearly all of the problems people experience in their professional lives. The exceptions are few, and include things like high energy physics, fluid dynamics, some graphics work, and of course the utterly insane practice of proof-of-work pyramid schemes.
My impression is that most CPU time these days is spent waiting, computing things to be drawn on screen, and drawing them. This means that interpreted languages are not nearly enough that much of a problem. I usually write in awk because what I do tends to center around line-oriented text files that need transformation and some math. Also interpreted, but without the completely opaque jungle of add-ons that are curl|sudo bash -installed.
-
Thank you for the explanation. I did guess your gist.
-
According to Pareto's law, 80% of the code only takes 20% of the execution time, while 20% of the code takes 80% of the execution time.
Normally you should only optimize 20% of the code to gain a lot of speed.
That's true if you write all the code in the same language (or at least similarly efficient languages).
In Python this 20% of the code can already be optimized with external libraries, sometimes written in C (like numpy).
Let's try a thought experiment.
We have some task written in C (or Java or C#) that takes 10 seconds to run:
8 seconds: the important 20% of the code
2 seconds: the "unimportant" 80% of the code that you want to be easy to maintain
We rewrite 80% of the code in Python. Python runs 50 times slower than C. Now we have:
8 seconds: the important 20% of the code (still in C)
100 seconds: the Python part
Total runtime just went from 10 seconds to 108 seconds. The Python code is taking 92.6% of the time.
I sure hope it's a LOT easier to maintain to make it worth it.
Or, it had better be more like 99%/1% in the C version, not 80%/20%.
(Of course 108 seconds is better than the 500 seconds it would take if you wrote it all in Python ... but 10 seconds is even better)
You're grossly over estimating speed differences.
No, that's accurate. If you write the same algorithm the same way in C and Python then the Python is about 50 times slower. That's well-established e.g. see
https://www.youtube.com/watch?v=D3h62rgewZM (https://www.youtube.com/watch?v=D3h62rgewZM)
People argue he's not using idiomatic Python and THAT'S MY POINT. Python has a huge penalty for Just Writing Code instead of using the built-in high level abstractions (that were written by someone else, in C).
There's plenty of examples floating around of people writing some numerical routine in pure C/C++ and it being slower than numpy because said person doesn't know how to write the code to squeeze every bit of optimization from the compiler.
That just means the person writing the C/C++ doesn't know as much about numerical programming as the person who wrote numpy. Numpy can't be faster than C because numpy *is* C. Using an appropriate algorithm and coding is of course important, and if you're not competent to write that yourself then you should use a library.
Numerical libraries are also available in C. NAG, LINPAK, BLAS etc have been around for many decades. Hell -- you can use numpy from a C program too, if you want to.
People using numpy are probably somewhere around 99.99% of the executed operations are in numpy, 0.01% in Python. That's very far from 80/20.
Edit: I don't even understand what you are arguing here. Its like you're completely ignoring that fact that for super hot spots in the code you can write C/C++ and use it directly in the python code.
How can I be ignoring it, when that's exactly the whole thing I'm talking about?
The same thing could happen in the other direction. Copying an idiomatic python algorithm to C might result in inefficient code (that’s one of the problems of Nuitka). Speed comparison should be done with the most efficient implementation of the algorithm for each language (not different algorithms) to provide useful results. A good example of this is the Ada implementation, as one of its inefficiencies is a consequence of the chosen types for the variables (due to the number of operations required to read and write them) instead of the actual algorithm
-
...
Python runs 50 times slower than C.
...
Not that much. two to ten times slower.
Edit:
It depends on the type of program you are doing.
But even with a 50 to 1 difference, it is still better in many cases to program in Python. That is why it is programmed in Python, not because programmers do not know how to program in C!
I am trying to find out why Python is so popular. If you show me that there are no reasons for Python to be popular, that is against reality!
-
Why is Google using Python on its Youtube service?
Is Google Against Speed? I do not believe it.
Doesn't Google know the advantages of C? I do not believe it
The question remains why Python has become such a popular language, the first one.
-
...
Python runs 50 times slower than C.
...
Not that much. two to ten times slower.
Edit:
It depends on the type of program you are doing.
But even with a 50 to 1 difference, it is still better in many cases to program in Python. That is why it is programmed in Python, not because programmers do not know how to program in C!
It can be much more than that. In the video referenced above, it was found that running that same algorithm, counting the number of primes below one million, the number of iterations done in five seconds was:
25: Python
2651: C# (106x faster)
7436: C++ (297x faster)
-
I am trying to find out why Python is so popular.
I haven't read it myself but I suspect there will be a number of clues and possible answers to your question in this book:
https://www.amazon.com.au/Hit-Makers-Science-Popularity-Distraction/dp/110198032X (https://www.amazon.com.au/Hit-Makers-Science-Popularity-Distraction/dp/110198032X)
Alternatively, try this article:
https://betterexplained.com/articles/logical-fallacy-popularity-is-not-quality/ (https://betterexplained.com/articles/logical-fallacy-popularity-is-not-quality/)
-
Why is Google using Python on its Youtube service?
I do not know. Did you attempt to ask Google why? What did they tell you?
Is Google Against Speed? I do not believe it.
I do not know. Did you attempt to ask Google? What was the answer?
Doesn't Google know the advantages of C? I do not believe it
I do not know. Did you attempt to ask Google? What was the answer? You don't have answers from Google but you certainly do tell us what you believe. And I do believe that you believe it.
The question remains why Python has become such a popular language, the first one.
OK so we have a question that remains, which means we don't have the answer.
I already pointed out to you here -
https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg3732397/#msg3732397 (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg3732397/#msg3732397)
The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google.
The more a language tutorial is searched, the more popular the language is assumed to be. It is a leading indicator. The raw data comes from Google Trends.
https://pypl.github.io/PYPL.html (https://pypl.github.io/PYPL.html)
Also from something recently referenced in this thread but now is gone (did someone edit their post?) -
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
What is the definition of "popular"?
1.
liked, admired, or enjoyed by many people or by a particular person or group.
"she was one of the most popular girls in the school"
2.
(of cultural activities or products) intended for or suited to the taste, understanding, or means of the general public rather than specialists or intellectuals.
"the popular press"
definition from Oxford languages/Google
You need to be very careful when drawing conclusions from something that appears to be popular to something that is better. That's what you are attempting to do, go from "it's popular" to "it's better". For example, if tutorials for something are searched more for thing A than for thing B, does that mean thing A is better? No. It might be, but what are some other reasons that might happen? It might be that thing A is harder to learn, which is why the tutorials are being searched more than the other thing. It might be that thing A is much newer and people want to learn it, meanwhile thing B has been around for a long time and people already understand it, so less tutorials are searched. I can think of other reasons as well - none of which have anything to do with thing "A" being "better" than thing "B"
I wouldn't even go so far as saying a thing that has the most searches for tutorials is popular, looking at the definition. It might be that a lot of students hate the thing, but they are required to learn it because it's being taught more these days. Why might it be taught more these days? That's a question, and I don't know the answer (if that is true). I can speculate as well as anyone here, but it wouldn't mean squat.
Note: I do not have any dislike for any particular programming language, but I do dislike drawing wrong conclusions.
-
I am trying to find out why Python is so popular. If you show me that there are no reasons for Python to be popular, that is against reality!
From my point of view, it is a combination of being a language designed to teach beginners (it is a batteries included language with dynamic types that handles many complexities for you) and a similar sintaxis to matlab with a good integration with c libraries (that made it appealing to programmers that wanted a free substitute to matlab). In addition to that, its module system and pip make using third party libraries as easy as using the C standard library, which is a great advantage. As a result, it is appealing for beginners because it is used for building real applications in fields with a lot of hype like machine learning, which was the problem of other beginner friendly languages like basic (it was seen as a toy language, despite being used for building many internal programs due to its lack of use in fashionable applications)
Being popular also means that there are many forums where people can ask questions and that many programs offer a python api for automating their use
-
People argue he's not using idiomatic Python and THAT'S MY POINT. Python has a huge penalty for Just Writing Code instead of using the built-in high level abstractions (that were written by someone else, in C).
Yes, and that point actually applies to much more than just speed.
Python as a programming language is rather questionable - to say the least. Of course that would take quite a while to get into details, and some may not agree.
But point is, at least from the majority of Python uses I've seen - so admittedly that's partly subjective - people using Python usually do it not particularly for the merits of the language itself, but for the enormous pile of existing libraries that you can find for about any purpose. And this can be perfectly seen in this thread as well.
Python is not the only language that became popular thanks to available "libraries" rather than the core language itself, by the way. This is one of the most common way of making a language popular. (Of course there must always be a trigger - libraries do not appear all at once by magic - but this is sort of a feedback loop).
-
... Python as a programming language is rather questionable - to say the least. Of course that would take quite a while to get into details, and some may not agree....
Yes, some may and some may not agree. Out of curiosity, and nothing more than that, do you prefer C++?
-
People argue he's not using idiomatic Python and THAT'S MY POINT.
Also my own perennial issue with programmers that expect their experience and knowledge in one programming language and environment to be directly applicable in another. (Instead of "idiomatic language", I just call it the paradigm.)
The good thing about high-level languages like Python, Ruby, and even awk, is that instead of the basic imperative operations (loops and conditionals), you can directly skip into event-based programming and algorithms. For example, dictionaries (noting that in awk, all arrays are dictionaries) provide an efficient tool for generating graphs and disjoint sets. Then, describing these as abstractions involving quite interesting lower-level code implementing them, showing that by choosing the tool used, the programmer can choose at which level of complexity to work on the problem, and what the tradeoffs are, the programmers hopefully learn that a single programming language is not 'best', and that each programming language has their paradigm, their own idiomatic style, that lets one solve problems most efficiently using that language.
Numerical libraries are also available in C. NAG, LINPAK, BLAS etc have been around for many decades. Hell -- you can use numpy from a C program too, if you want to.
People using numpy are probably somewhere around 99.99% of the executed operations are in numpy, 0.01% in Python. That's very far from 80/20.
Exactly.
Until recently, I experimented a lot with a linear algebra library interface that I hoped would let scientists write the code in C instead of Python, Matlab, Octave, and such tools. (The reason why in C, is complicated and boils down to running distributed code in clusters, using MPI to communicate between instances. However, in the past few years, I believe mpi4py (packaged in Debian-derivatives as python3-mpi4py and in RHEL-derivatives as python3-mpi4py-mpich or python3-mpi4py-openmpi) has become quite acceptable, as outlined in this ieee article (https://ieeexplore.ieee.org/document/9439927).)
Basically, both matrices and views to matrices were indistinguishable, as data was stored in separate refcounted (or GC'd) structures, allowing one to have vectors and even transposes to the same matrix without issues in single-treaded code. It works, and is a nice C interface. However, it really gains nothing compared to using idiomatic Numpy/Scipy or Matlab/Octave stuff. All it does is make the linear algebra code implemented in C a bit simpler/cleaner compared to GSL, Intel core math library, AMD core math library, BLAS, LAPACK, et cetera.
Right now, for a scientist doing numerical calculations using NumPy/SciPy, I see no reason why they could not do distributed processing in a cluster using mpi4py as well, exactly because 1) the CPU time used to run Python is a tiny fraction of the whole, and 2) it is not difficult to teach/learn the patterns and algorithms that lead to efficient distributed code. Of course, without such guidance, the Python code they generate is likely completely crap; but so is self-taught C, in most cases.
Looking back, this seems so obvious now.
-
People argue he's not using idiomatic Python and THAT'S MY POINT. Python has a huge penalty for Just Writing Code instead of using the built-in high level abstractions (that were written by someone else, in C).
Maybe they argue, because that's how you use python. If you want a chart, you use matplotlib. If you want data science, you import pandas. If you want to calculate something fast, you import numpy, cuda or ray or opencv.
I dont get your arguments. Nobody is going to write code the way it is in that Youtube video, or how you are saying, because it is slower to write and slower to run. And counterintuitive.
And any speed argument for pure computational script is kinda useless. If I need to calculate something fast in python, I can always import ray, change maybe 3 lines in the code, and then run it distributed on a server park. Or import any of the libraries that make it run on video cards, 1000x faster than your best C implementation. It can utilize power you can never dream of, just because doing the same thing in C is hilariously complicated.
-
The good thing about high-level languages like Python, Ruby, and even awk, is that instead of the basic imperative operations (loops and conditionals), you can directly skip into event-based programming and algorithms. For example, dictionaries (noting that in awk, all arrays are dictionaries) provide an efficient tool for generating graphs and disjoint sets. Then, describing these as abstractions involving quite interesting lower-level code implementing them, showing that by choosing the tool used, the programmer can choose at which level of complexity to work on the problem, and what the tradeoffs are, the programmers hopefully learn that a single programming language is not 'best', and that each programming language has their paradigm, their own idiomatic style, that lets one solve problems most efficiently using that language.
But there is great fun to be had in playing with languages and using them to solve any problem, especially so classes of problems that are decidedly unsuited to that particular language, as most often used.
Right now, for a scientist doing numerical calculations using NumPy/SciPy, I see no reason why they could not do distributed processing in a cluster using mpi4py as well, exactly because 1) the CPU time used to run Python is a tiny fraction of the whole, and 2) it is not difficult to teach/learn the patterns and algorithms that lead to efficient distributed code. Of course, without such guidance, the Python code they generate is likely completely crap; but so is self-taught C, in most cases.
Looking back, this seems so obvious now.
I once worked at a computing centre where one of the compute clustres essentially was a speed test of Perl and the AFS client...
-
But there is great fun to be had in playing with languages and using them to solve any problem, especially so classes of problems that are decidedly unsuited to that particular language, as most often used.
Well, having fun is having fun, and as long as nobody gets harmed (say, get hoisted to maintain the result because someone found it and decided to actually use it and then left for greener pastures), it is just fun.
Sometimes, I check out some of the submissions to IOCCC (https://www.ioccc.org/), just for fun. But if when I see that kind of code in real life, it makes me die a little inside.
I once worked at a computing centre where one of the compute clustres essentially was a speed test of Perl and the AFS client...
CERN still uses a lot of Java, including in distributed computing. Compared to running Perl, that's an ouchie, in my opinion.
-
Comparing speed of C and Python with equal algoritm:
import time
def eratostenes(n):
nums = [1 for i in range(n+1)]
nums[0] = nums[1] = 0
for i in range(2, n+1):
if nums[i]:
x = i * i
if x > n:
break
for j in range(x, n+1, i):
nums[j] = 0
return nums
def main():
timeit = time.time()
for i in range(1000):
nums = eratostenes(1000000)
timeit = time.time() - timeit
print('time =', timeit)
main()
130 Seconds
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
char *eratosthenes(unsigned long n) {
char *nums, *p;
unsigned long i, x;
/* Initialize */
nums = malloc(n + 1);
p = nums;
*p++ = 0;
*p++ = 0;
for(i=2; i<=n; i++)
*p++ = 1;
/* Find primes */
for(i=2; i<=n; i++) {
if(nums[i] == 1) {
x = i*i;
if (x > n)
break;
while(x<=n) {
nums[x] = 0;
x += i;
}
}
}
return nums;
}
int main() {
char *nums;
int i;
clock_t timeit;
timeit = clock();
for(i=0; i<1000; i++) {
nums = eratosthenes(1000000);
free(nums);
}
timeit = clock() - timeit;
printf("time = %f\n", (float)(timeit) / CLOCKS_PER_SEC);
}
2.36 Seconds
Relationship = 130/2.36 = 55 : 1
-
You know.. most uses for Python is not just sitting there crunching primes. I remember Video games used to be written in C and the tricky bits were in ASM.
How hard is it to shim in a bit 'o C when the going gets tough? Srs. Q.
-
Most code in gaming is incorporating user input and updating gamestate at some glacial pace with the engine handling rendering, pathfinding and physics. Pathing conflicts and collisions simply handled non-iteratively on the next tick. Game logic can generally be done in a script language no problem, computers keep getting faster but 60 Hz stays the same.
Mostly C# and Unrealscript though, not Python.
-
But point is, at least from the majority of Python uses I've seen - so admittedly that's partly subjective - people using Python usually do it not particularly for the merits of the language itself, but for the enormous pile of existing libraries that you can find for about any purpose. And this can be perfectly seen in this thread as well.
True; I just don't think it is a serious drawback, because it is a tool that works for such purposes.
In fact, I consider it a serious positive compared to say Ruby and Lua; especially because it is easy to do in Python for my own libraries, including those not specially designed for any kind of Python interfacing.
Python is not the only language that became popular thanks to available "libraries" rather than the core language itself, by the way. This is one of the most common way of making a language popular. (Of course there must always be a trigger - libraries do not appear all at once by magic - but this is sort of a feedback loop).
For Python, the trick is that you don't need to do any kind of changes to the libraries; the interfacing only requires Python code, which really is revolutionary among programming languages.
It is kinda funny that such a technical detail, which has almost nothing to do with the language itself, has been such crucial factor in its success.
-
Quicksort algorithm over long long numbers:
import random
import time
def partition(values, left, right, pivotidx):
pivot = values[pivotidx]
values[right], values[pivotidx] = values[pivotidx], values[right]
storeidx = left
for idx in range(left, right):
if values[idx] < pivot:
values[idx], values[storeidx] = values[storeidx], values[idx]
storeidx += 1
values[storeidx], values[right] = values[right], values[storeidx]
return storeidx
def _doquicksort(values, left, right):
if right > left:
pivotidx = (left+right)//2
pivotidx = partition(values, left, right, pivotidx)
_doquicksort(values, left, pivotidx)
_doquicksort(values, pivotidx + 1, right)
return values
def quicksort(nums):
return _doquicksort(nums, 0, len(nums) - 1)
def main():
nums = [random.getrandbits(64) for i in range(1000000)]
timeit = time.time()
nums = quicksort(nums)
timeit = time.time() - timeit
print('time =', timeit)
main()
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#define ARRAYSIZE 1000000
long partition(long long *values, long left, long right, long pivotidx) {
long long temp, pivot;
long storeidx, idx;
pivot = values[pivotidx];
temp = values[right];
values[right] = values[pivotidx];
values[pivotidx] = temp;
storeidx = left;
for(idx = left; idx<right; idx++) {
if (values[idx] < pivot) {
temp = values[idx];
values[idx] = values[storeidx];
values[storeidx] = temp;
storeidx++;
}
}
temp = values[storeidx];
values[storeidx] = values[right];
values[right] = temp;
return storeidx;
}
long long *_doquicksort(long long *values, long left, long right) {
long pivotidx;
if (right > left) {
pivotidx = (left + right) / 2;
pivotidx = partition(values, left, right, pivotidx);
_doquicksort(values, left, pivotidx);
_doquicksort(values, pivotidx + 1, right);
}
return values;
}
long long *quicksort(long long *nums) {
return _doquicksort(nums, 0, ARRAYSIZE-1);
}
int main() {
long i;
clock_t timeit;
long long *nums;
nums = malloc(sizeof(long long)*(ARRAYSIZE+1));
for(i=0; i<ARRAYSIZE; i++) {
nums[i] = (long long)rand();
}
timeit = clock();
nums = quicksort(nums);
timeit = clock() - timeit;
printf("time = %f\n", (float)(timeit) / CLOCKS_PER_SEC);
}
Python Time = 3.5579
C Time = 0.2170
Relationship = 3.5579 / 0.2170 = 16.4 : 1
-
Well, having fun is having fun
just for fun I tried to write a relativistic wave equation version of Erwin Schrödinger's equation (simplified), but gave up because it was too "serious" to be a hobby and I prefer to write some funny sentence to a Youtuber who talks about physics, until just for fun she pointed out a dude who actually made the point about the Dirac's particle physics equation.
- (my common operative field) For an electrical Engineer, electrons are irrelevant, what matters is current and voltage
- (what I made for fun) For Solid State Device Physic Engineer, current and voltage are not enough and electrons are not irrelevant, what matters is potential holes, and you use the Erwin Schrödinger's equation to describe them
- (what she replied for her personal fun) For an high-energy Physics, potential holes are not enough and you want to describe a particle that follows Fermi–Dirac statistics and generally has half odd integer spin, so you talk about spin, "fermion particles" as "excitations of a quantum field" (what?), and you use the Dirac's particle physics equation to describe them
So the point is what is fun?
An extraordinarily impressive increase in complexity that made the whole thing look like an episode of the television series "Big Bang Theory" ;D
-
Comparing speed of C and Python with equal algoritm:
But the python code doesn't look like this.
It looks like this:
import timeit
timeit.timeit("list(sympy.sieve.primerange(0, 1000000))", setup="import sympy", number =1000)
Two lines of code, same algorithm, 8.23 seconds to run.
There are differences between the languages. One is that python will do garbage collection after every for cycle. Or you can write your code properly, and then it runs fast, and you actually didn't need to think about how to code, just what to code.
-
Quicksort algorithm over long long numbers:
Python Time = 3.5579
C Time = 0.2170
Relationship = 3.5579 / 0.2170 = 16.4 : 1
I think you may be mostly measuring startup time there. Try with a bigger array, or do it multiple times.
-
So the point is what is fun?
An extraordinarily impressive increase in complexity that made the whole thing look like an episode of the television series "Big Bang Theory" ;D
I feel a bit responsible but not guilty here :-DD and I'd like to simply point out that doing something "the wrong way" deliberately can be fun, and as Nominal Animal pointed out, that is until people who are not in on the joke take it seriously and deploy it in production... :scared:
-
I am sick of such "sums"
Agreed.
Forget C.. this is too OLD crap..
Rust can at least bootstrap itself, Python can't. Anyway, without C, neither of the two would exist. Every language has its purpose.
-
Quicksort algorithm over long long numbers:
Python Time = 3.5579
C Time = 0.2170
Relationship = 3.5579 / 0.2170 = 16.4 : 1
I think you may be mostly measuring startup time there. Try with a bigger array, or do it multiple times.
Array of 10000000 numbers:
Python: 46.36
C: 5.95
Relation: 7.8
-
Let’s look back a few years…
Assembly code without much optimisation…
MSBASIC was fine on 8-bitters, running at 4MHz or less - through the late 70s and 80s for many of us, until CBASIC and PASCAL rolled along, and we could do 80% more with 20% extra coding effort, then Java and some others stumbled into the shot.
Easy to write, but inefficient.
C already had an audience, then C++, and C# arrived.
They all matured, and diverged as ‘web applications’, and ‘the cloud’ started to show up.
(Client-Server anyone)
HTML and then Python arrived to make GUIs and single-user applications a bit easier to write, but luckily, computers had increased their hardware performance by more than 100x - sadly the code ran at effectively the same speed, you could write code that appeared the same speed to the single user, but occupied 80% of the system resources to do it!
Luckily disk and I/O evolved in parallel, along with coprocessors - to pick up the data flow bottlenecks
About now, we should consider that here we are in 2021, with 8-bit 16MHz embedded processors that are quite capable of keeping up with 3GHz, 64-bit processors on simple control projects. Other hardware in the mid point can do the same, better.
Sure there are other benefits, but when they’re programmed with Oranges to Oranges, it becomes abundantly clear why ‘system’ programmers use the ‘harder’ languages than the easy to teach ‘application’ tools.
-
Quicksort algorithm over long long numbers:
Python Time = 3.5579
C Time = 0.2170
Relationship = 3.5579 / 0.2170 = 16.4 : 1
I think you may be mostly measuring startup time there. Try with a bigger array, or do it multiple times.
Array of 10000000 numbers:
Python: 46.36
C: 5.95
Relation: 7.8
Very strange.
I tried your code with N = 10 million
M1 Mac arm64
0.736 C
30.895 Python
2990wx Threadripper amd64
0.816 C
43.380 Python
SiFive FU740 1.5 GHz riscv64
4.700 C
584.804 Python
That's ratios of 41.97, 53.16, and 124.43.
The C was compiled with -O1 on all. The C program used 80 MB of RAM, as expected, the Python used variously 800 MB, 700 MB, and 560 MB of RAM.
-
I have used GCC from MinGW without options
Edit: Have you changed the size of the array in the C code?
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#define ARRAYSIZE 10000000
long partition(long long *values, long left, long right, long pivotidx) {
long long temp, pivot;
long storeidx, idx;
pivot = values[pivotidx];
temp = values[right];
values[right] = values[pivotidx];
values[pivotidx] = temp;
storeidx = left;
for(idx = left; idx<right; idx++) {
if (values[idx] < pivot) {
temp = values[idx];
values[idx] = values[storeidx];
values[storeidx] = temp;
storeidx++;
}
}
temp = values[storeidx];
values[storeidx] = values[right];
values[right] = temp;
return storeidx;
}
long long *_doquicksort(long long *values, long left, long right) {
long pivotidx;
if (right > left) {
pivotidx = (left + right) / 2;
pivotidx = partition(values, left, right, pivotidx);
_doquicksort(values, left, pivotidx);
_doquicksort(values, pivotidx + 1, right);
}
return values;
}
long long *quicksort(long long *nums) {
return _doquicksort(nums, 0, ARRAYSIZE-1);
}
int main() {
long i;
clock_t timeit;
long long *nums;
nums = malloc(sizeof(long long)*(ARRAYSIZE+1));
for(i=0; i<ARRAYSIZE; i++) {
nums[i] = (long long)rand();
}
timeit = clock();
nums = quicksort(nums);
timeit = clock() - timeit;
printf("time = %f\n", (float)(timeit) / CLOCKS_PER_SEC);
}
-
With -O1 option my new time is:
Python: 46.36 Seconds
C: 2.247 Seconds
New ratio: 20.6
-
I have used GCC from MinGW without options
GCC without options is -O0 which is pessimised -- every variable is loaded from RAM in every statement, and the result stored back. Thus totally wasting the 16 or 32 perfectly good registers your CPU has.
Edit: Have you changed the size of the array in the C code?
Yes, to 10 million.
-
I have just installed newer version of mingw64 and I compile the program with -O1 option:
Python Time: 46.36
C time: 1.67
New ratio: 27.8 : 1
-
I have tested pure Python sort program just for fun:
import random
import time
import numpy as np
def main():
nums = np.random.randint(0, 1024*1024*1024, (1, 10000000), dtype='int64')
timeit = time.time()
nums.sort()
timeit = time.time() - timeit
print('time =', timeit)
main()
Python time = 0.776 seconds
-
I never used Python until some weeks ago. The problem was: about 3000 wrong gif files. Those are test protocols and they indicated a wrong firmware revision. Impossible to correct all those gif files by hand (unreliable). Impossible to setup a C++ application like i usually do (time consumption).
Searching the web for help i found a Python image library that could paste into a gif image and save the change back to the file. Then i had to learn how to search a directory for all gif files in Python and prepare a small gif with the correct revision number to patch into all those files. It had to be the same color model as the protocol files to change, otherwise the image library failed to paste correctly. Also i learned how to restore the last modification date/time of the original gif files. The whole procedure was finished after 3 or 4 hours and everybody was happy.
Still i will prefer C++ for project work. To me Python appears somewhat like Arduino: Maybe useful but you can't know in advance.
Regards, Dieter
-
Once you have tried Python you will use it again.
There are many tasks like what you have just done in the ordinary life of a programmer, where Python solves the problem for you.
-
Once you have tried Python you will use it again.
Now that is just silly.
Python is only a tool among tools. Saying that Python is something everybody should try because they will find it useful, is like saying everybody should be confident handling explosives, because you can do so much with explosives: everything from woodcutting and emergency signaling to demolition.
A case in point: If you often reach for numpy to do statistical number-crunching in Python, you should take a look at R (https://www.r-project.org/) instead. If you do numerical linear algebra, consider Matlab or Octave. If you do symbolic algebra (sympy), consider Maxima/wxMaxima or Sagemath instead. And so on.
Do not let yourself be blinded and mentally bound by a comfortable tool. That way lies silliness: you become a hammer-wielder, who sees all problems as nails.
-
Once you have tried Python you will use it again.
Now that is just silly.
Python is only a tool among tools. Saying that Python is something everybody should try because they will find it useful, is like saying everybody should be confident handling explosives, because you can do so much with explosives: everything from woodcutting and emergency signaling to demolition....
Perhaps the wording was a little silly, but the sentiment is not. I might have written: once you have tried Python, you may very well find yourself using it again. It has served me well over the last decade and a half. I have found, that like C, Python wears well.
It is funny you should mention explosives. I was chatting with a neighbor, some months back, about his grandmother who had lived through the German hyperinflation and the terrible destruction of the Second World War. My neighbor said she was unflappable and prepared for any and every possible contingency. Among the things she kept on hand were some commonly available materials for making explosives. You never know when those might come in handy.
-
It's just very subjective.
I have tried Python and would certainly not want to use it again. To each their own. Not saying it's not useful and the go-to tool for many; not saying that *you* or anyone else should not use it; just that it's certainly not a universal fact.
And I agree with Nominal Animal about using the "right" tool instead of trying to use Python for just everything. Almost anything for math stuff, for instance, can be done better and more comfortably with tons of dedicated tools.
-
I might have written: once you have tried Python, you may very well find yourself using it again.
Me fail English often, but to me that is has a completely different sentiment. The silly one was an assertion of usefulness for all, yours expresses possible utility (and uses a form that typically indicates you personally have found it useful).
I too have found Python useful for a number of use cases, but I also know cow-orkers who never touch those use cases, and computer users (developers in some sense, say writing translations and such) that do not know Python and suffer no handicap for it.
Among the things she kept on hand were some commonly available materials for making explosives. You never know when those might come in handy.
My dad had blasters permits since I was a kid. I consider explosives and firearms just another set of tools, and was taught the basic safety practices at around preschool age, just in case. He preferred slower, safer tools (like the expansion of water when it turns to ice to split large rocks), but explosives are surprisingly useful in non-urban environments –– if used appropriately.
-
I never used Python until some weeks ago. The problem was: about 3000 wrong gif files. Those are test protocols and they indicated a wrong firmware revision. Impossible to correct all those gif files by hand (unreliable). Impossible to setup a C++ application like i usually do (time consumption).
Searching the web for help i found a Python image library that could paste into a gif image and save the change back to the file. Then i had to learn how to search a directory for all gif files in Python and prepare a small gif with the correct revision number to patch into all those files. It had to be the same color model as the protocol files to change, otherwise the image library failed to paste correctly. Also i learned how to restore the last modification date/time of the original gif files. The whole procedure was finished after 3 or 4 hours and everybody was happy.
Still i will prefer C++ for project work. To me Python appears somewhat like Arduino: Maybe useful but you can't know in advance.
Regards, Dieter
This is a typical example where Python shines, jobs that are run few times or only once, but they're worth putting effort into because the alternative is to be a Windows user and do it by clicking in a GUI 3000 times. I do these all the time, and in shell or awk. For picture manipulation it usually ends up being a wrapper around ImageMagick or similar. If I'm posting pictures on here I usually write a one-liner calling "convert" from the ImageMagick suite, like so:
convert -strip -quality 60 DSC_0938.JPG usual_suspect.jpeg
-
.
-
Quicksort algorithm over long long numbers:
Again with this? This is not how you sort in python.
You sort in python with .sorted()
You dont write code, others wrote it already.
I really dont know what you are trying to prove here, other than your own ignorance on how to use the language.
-
I have just installed newer version of mingw64 and I compile the program with -O1 option:
Python Time: 46.36
C time: 1.67
New ratio: 27.8 : 1
That's getting more like it. But I still don't understand why your C program is so slow. I didn't change your code at all (except one million to ten million).
I don't know why you used "long long" as the data type. There's a serious danger that some machines may give 128 bits for that, not 64 bits as you want. Maybe mingw64 is doing that? I did check on all three of my machines, and it was 64 bit, but it's a risk. If you want a specific size then you should use int64_t or uint64_t.
Maybe try putting near the start of your program:
printf("sizeof(long long) = %ld\n", sizeof(long long));
Also, I noticed you're using rand() which returns an int (32 bits on all my machines), not random() which returns a long (64 bits on all my machines).
-
Quicksort algorithm over long long numbers:
Again with this? This is not how you sort in python.
You sort in python with .sorted()
You dont write code, others wrote it already.
I really dont know what you are trying to prove here, other than your own ignorance on how to use the language.
Some people do things where others have already beaten down a path through the jungle.
Others *are* the people beating down the path.
I often find myself as one of the latter.
I appreciate the notational convenience of things such as list comprehensions and built-in sort functions, but I FAR PREFER to use a language where I can do things the explicit way if I want to and it performs the same. I want a language I can *write* the library in.
-
I have tried Python and would certainly not want to use it again.
Python for math seems to be mandatory. I have different feelings and opinions, but it's practically irrelevant, I have to follow the hype, otherwise there are neither libraries nor tools :-//
-
Once you have tried Python you will use it again.
Now that is just silly.
Python is only a tool among tools.
No, Python is not only other tool. Is more popular than the other tools.
Just silly is having a simple, useful, free, ubiquitous and popular tool and not wanting to use it.
I recognize that there are many more tools and that many being specialized are more prepared for what they do. But I'm not a specialist in all those subjects and I don't need to learn R when I want to do a few statistics, or use Octave for number crunching. And of course I don't want to pay for Matlab.
I also usually use imagemagick and bash for certain tasks. Knowing Python does not make me leave out all the other tools.
I have also programmed in Awk but it was before I knew Python. Awk may be shorter to type, but only in simple tasks and I don't want to keep so many tools in my head for sporadic use.
-
Quicksort algorithm over long long numbers:
Again with this? This is not how you sort in python.
You sort in python with .sorted()
You dont write code, others wrote it already.
I really dont know what you are trying to prove here, other than your own ignorance on how to use the language.
Some people do things where others have already beaten down a path through the jungle.
Others *are* the people beating down the path.
I often find myself as one of the latter.
I appreciate the notational convenience of things such as list comprehensions and built-in sort functions, but I FAR PREFER to use a language where I can do things the explicit way if I want to and it performs the same. I want a language I can *write* the library in.
These things are not explicitly typed by python developers, because it is pointless and error prone.
If you want to use your time useful, then join the python core development team. You get to program in C and develop these menial tasks by hand. Other than posting here, saying: " Look it is slow for things that you are not meant to do".
What's next? Implicit matrix multiplication, instead of writing "a*b", and "hey look it is slower than C"?
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
But despite that, there is an ever-increasing growth of interpreted languages vs. compiled languages.
Perhaps the increased speed of computers and a need for greater flexibility in programming aid in this change.
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
But despite that, there is an ever-increasing growth of interpreted languages vs. compiled languages.
Perhaps the increased speed of computers and a need for greater flexibility in programming aid in this change.
Some languages can be interpreted and compiled offering the best of both worlds. In fact there’s a C++ interpreter developed by CERN
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
But despite that, there is an ever-increasing growth of interpreted languages vs. compiled languages.
Perhaps the increased speed of computers and a need for greater flexibility in programming aid in this change.
Some languages can be interpreted and compiled offering the best of both worlds. In fact there’s a C++ interpreter developed by CERN
just saying:
Numba translates Python functions to optimized machine code at runtime using the industry-standard LLVM compiler library. Numba-compiled numerical algorithms in Python can approach the speeds of C or FORTRAN.
You don't need to replace the Python interpreter, run a separate compilation step, or even have a C/C++ compiler installed. Just apply one of the Numba decorators to your Python function, and Numba does the rest.
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
But despite that, there is an ever-increasing growth of interpreted languages vs. compiled languages.
Perhaps the increased speed of computers and a need for greater flexibility in programming aid in this change.
Some languages can be interpreted and compiled offering the best of both worlds. In fact there’s a C++ interpreter developed by CERN
just saying:
Numba translates Python functions to optimized machine code at runtime using the industry-standard LLVM compiler library. Numba-compiled numerical algorithms in Python can approach the speeds of C or FORTRAN.
You don't need to replace the Python interpreter, run a separate compilation step, or even have a C/C++ compiler installed. Just apply one of the Numba decorators to your Python function, and Numba does the rest.
I have to try numba. It seems a great tool
I’ve used Nuitka in the past for compiling python to machine code, which is great but it can’t be used with jupyter notebooks
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
The real answer is: it depends. If you are going to put an algorithm together from scratch using basic Python language constructs then it will be slower. If you use Python as a conduit to push data between blocks of native binary code (libraries), then it will be just as fast (or maybe even faster if the creator of the library used some neat optimising tricks).
.
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
But despite that, there is an ever-increasing growth of interpreted languages vs. compiled languages.
Perhaps the increased speed of computers and a need for greater flexibility in programming aid in this change.
Some languages can be interpreted and compiled offering the best of both worlds. In fact there’s a C++ interpreter developed by CERN
just saying:
Numba translates Python functions to optimized machine code at runtime using the industry-standard LLVM compiler library. Numba-compiled numerical algorithms in Python can approach the speeds of C or FORTRAN.
You don't need to replace the Python interpreter, run a separate compilation step, or even have a C/C++ compiler installed. Just apply one of the Numba decorators to your Python function, and Numba does the rest.
I have to try numba. It seems a great tool
I’ve used Nuitka in the past for compiling python to machine code, which is great but it can’t be used with jupyter notebooks
The basic concept is that you use functions available in numpy arrays for example
When you write the Numba orerators, you will fix the variable type. So when you call A+B it doesn't have to look up which types of A and B is, just uses the "int" A+B for example. And doesn't check for NaN for example.
It varies how much it speeds up the code. I never found a real use case for it, the added code complexity and error messages made the entire process cumbersome. I rather wait for the computer to finish calculations.
That being said the longest I had to wait for python to finish computing was maybe 30 minutes. Machine learning in torch. Good luck writing that in C.
-
If you want to use your time useful, then join the python core development team. You get to program in C and develop these menial tasks by hand.
I joined the core RISC-V ISA development team. The Python development team will have to make do without me.
Other than posting here, saying: " Look it is slow for things that you are not meant to do".
Not meant to do? According to who?
If the Python designers didn't want us to use assignment statements with arithmetic, ifs and loops, and array and structure access ... then why did they provide them?
-
Ok, Python is an interpreted language and therefore it is slower than C. Everybody agree with that.
But despite that, there is an ever-increasing growth of interpreted languages vs. compiled languages.
Perhaps the increased speed of computers and a need for greater flexibility in programming aid in this change.
Some languages can be interpreted and compiled offering the best of both worlds. In fact there’s a C++ interpreter developed by CERN
just saying:
Numba translates Python functions to optimized machine code at runtime using the industry-standard LLVM compiler library. Numba-compiled numerical algorithms in Python can approach the speeds of C or FORTRAN.
You don't need to replace the Python interpreter, run a separate compilation step, or even have a C/C++ compiler installed. Just apply one of the Numba decorators to your Python function, and Numba does the rest.
I have to try numba. It seems a great tool
I’ve used Nuitka in the past for compiling python to machine code, which is great but it can’t be used with jupyter notebooks
The basic concept is that you use functions available in numpy arrays for example
When you write the Numba orerators, you will fix the variable type. So when you call A+B it doesn't have to look up which types of A and B is, just uses the "int" A+B for example. And doesn't check for NaN for example.
It varies how much it speeds up the code. I never found a real use case for it, the added code complexity and error messages made the entire process cumbersome. I rather wait for the computer to finish calculations.
That being said the longest I had to wait for python to finish computing was maybe 30 minutes. Machine learning in torch. Good luck writing that in C.
It seems quite interesting for implementing circuit optimization programs. I normally use matlab for that and I was considering switching to julia or Ada (probably the last one due to its memory management capabilities, which is one of the major problems we usually have), but it is nice to know another alternative
-
No, Python is not only other tool. Is more popular than the other tools.
Why do you believe popularity matters?
-
I think being the most popular of all languages must be for some reasons.
That is precisely what I want to know with this thread.
-
Once you have tried Python you will use it again.
Now that is just silly.
Python is only a tool among tools.
No, Python is not only other tool. Is more popular than the other tools.
That doesn't mean anything here. In what context, for what purpose, compared to what other tools? And what does popularity even mean? (As we have already pointed out.)
Just silly is having a simple, useful, free, ubiquitous and popular tool and not wanting to use it.
Uh. That's the silliest and boderline propagandist claim I've ever read.
As someone said, if all you have is a hammer, you'll see nails everywhere.
I'll add to this that if all you see are hammers, you'll tend to ignore any other existing tool whatever they are and whoever uses them.
So, who are you exactly to tell us what we should or should not be using?
-
I am not saying that you should use Python. I do not gain or lose anything with it. Python is not a trademark of a commercial company is just open source. Nobody makes money advertising Python and I think Python is sold alone.
What I'm saying is that I think once you use Python, it's such a useful tool, that you tend to keep using it. That is what has happened to me and that is why I think it will happen to others.
I know and use many other tools, but now we are not talking about them.
In this case you seem annoying that Python is a good tool. Why?
Edit:
I am expressing my opinion without offending anyone. You are not just giving your opinion but you are making a personal attack. Does it bother you that others give their opinion freely?
-
I think being the most popular of all languages must be for some reasons.
That is precisely what I want to know with this thread.
That something is popular has everything to do with humans and marketing, and very little to nothing to do with technical merit.
If it were otherwise, advertisements and branding would be a complete waste of money. From the commercial business world, we can immediately see the opposite is true: you can make almost anything popular by branding and marketing. This applies to scientists, engineers, and developers just as much as it does to everyone else: just go look at the Test Equipment forum here for examples.
The same is blatantly obvious at even Q&A sites like StackOverflow and StackExchange network, where popularity, and verifiable correctness of answers, are only very loosely coupled. Often, the most popular answer is not the correct one.
In the world of humans, image and appearance rules; the content and character is most often irrelevant.
-
That is the case for example of VHS vs Beta video. In the end, the worst of the two formats won.
But in this case it is not a trademark and there is no advertisements. It is counterintuitive for an interpreted language to reach such popularity in a world where speed is so prized.
Most users of programming languages are knowledgeable and smart people who simply do not get carried away simply by popularity reasons to use a language.
My case is not an example because I am an occasional, non-professional user of Python. But there are many professional teams using this language for reasons that go beyond Microsoft or other brand advertising.
Edit:
https://medium.com/@trungluongquang/why-python-is-popular-despite-being-super-slow-83a8320412a9
-
As already mentioned, Perl has better libraries and fewer incompatibilities. Ruby outperforms Python in several ways. All of them are Open Source, however only one reaches first place in popularity.
It may be due to the support of the language by Google. But Google has chosen Python years ago for reasons other than ads or popularity.
Because Python is an Open Source project, it does not belong to any company, like Linux.
-
But in this case it is not a trademark and there is no advertisements.
You don't think the numerous blog posts and Youtube videos are not marketing?
They are not paid advertisements, but they most definitely have the effect of marketing. Whether such marketing is designed and intentional, doesn't matter: the effect on humans is still the same.
And no, I did definitely not refer to paid marketing. I was thinking of those who prefer to work with humans and for humans, doing e.g. Youtube videos, blog posts, tech articles, and so on, who find gentle-learning-curve languages like Python enticing: easy to learn for not-so-technical people, but powerful enough to get stuff done.
It is counterintuitive for an interpreted language to reach such popularity in a world where speed is so prized.
You have that completely wrong.
Humans appreciate effortlessness much more than they appreciate speed or efficiency.
Indeed, those who appreciate anything besides effortlessness are called nerds, gearheads, adrenaline addicts, et cetera.
There are entire programming languages developed for nothing but code golf (https://en.wikipedia.org/wiki/Code_golf), but almost nothing devoted to making the most efficient and fast programming language possible. (Rust, Julia, Go are dedicated to make them as expressive and powerful as possible for humans to use; i.e. as effortless as possible, not as efficient or as fast as possible: the latter are just secondary goals, implemented only when not in conflict with the first.) This alone proves your intuition wrong.
I'm not saying that there is anything wrong in being this kind of a human; I definitely am myself. I highly value effortlessness, and only do otherwise in things I like doing, and in things I consider my (social, contractual, or self-assumed) responsibility. I just believe that being frank/direct and honest about it yields the best results overall, and does the least amount of harm.
Most users of programming languages are knowledgeable and smart people who simply do not get carried away simply by popularity reasons to use a language.
Um. Where do you live? Wakanda? Heaven? La-la-land?
Most users of programming languages are near-idiots swayed by passing fads, in my experience over the last three decades. Vast majority, like the rest of humanity, is prone to magical thinking (https://en.wikipedia.org/wiki/Magical_thinking).
"Getting carried away simply by ..." is, in my definition, extremely typical of all programmers; indeed, of all humans who like doing what they do. Myself most definitely included!
Do note that I am one of the ones who said they do use Python, and even recommend it for others for specific use cases (where I've found it useful); I have no issue with Python. I do believe I, in general terms, recognize both its strengths and its weaknesses.
My goal here is to 1) show that using these metrics, 'popularity' is irrelevant, no matter how emotionally important it might feel; or shown a counterexample and learn more myself; and 2) that Python is a tool that is well suited for some tasks, and not so well suited for others; and the true strength lies in recognizing the two cases, and in picking a tool that is best suited for the task at hand and the humans involved.
-
It is counterintuitive for an interpreted language to reach such popularity in a world where speed is so prized.
You have that completely wrong.
Humans appreciate effortlessness much more than they appreciate speed or efficiency.
Yep. Actually, almost the opposite of efficiency has been witnessed in computing for the last few decades.
https://en.wikipedia.org/wiki/Wirth%27s_law
Most users of programming languages are near-idiots swayed by passing fads, in my experience over the last three decades. Vast majority, like the rest of humanity, is prone to magical thinking (https://en.wikipedia.org/wiki/Magical_thinking).
That's right. Which is why for many, the relationship they have with technology looks more like worshipping than engineering.
The very idea that "if I use this one tool that everyone else seems to be using for almost everything, then my project can't fail" is magical thinking.
-
It is counterintuitive for an interpreted language to reach such popularity in a world where speed is so prized.
You have that completely wrong.
Humans appreciate effortlessness much more than they appreciate speed or efficiency.
Yep. Actually, almost the opposite of efficiency has been witnessed in computing for the last few decades.
https://en.wikipedia.org/wiki/Wirth%27s_law
I once read a review about Electron js in which the author stated that thanks to that technology we were able to develop software that makes 2021 computers perform like hardware made before 2010
-
I think being the most popular of all languages must be for some reasons.
That is precisely what I want to know with this thread.
I'm interested in knowing why you want to know? Why is it important to you? What does it matter to you if something is popular?
Mandarin Chinese is the most popular of all spoken languages in the world. Are you interested in learning Mandarin Chinese? If not, why not?
If you think about your possible answers to those questions you might begin to understand why others do not share your enthusiasm for Python.
-
I think being the most popular of all languages must be for some reasons.
That is precisely what I want to know with this thread.
I'm interested in knowing why you want to know? Why is it important to you? What does it matter to you if something is popular?
Mandarin Chinese is the most popular of all spoken languages in the world. Are you interested in learning Mandarin Chinese? If not, why not?
Not a bad example.
Mandarin Chinese has the largest number of native speakers of any language, by a large margin (921 million vs 370 million for English). But English has about 20% more users who *can* speak it (1.348 vs 1.120 billion), and with a much greater geographical spread.
English is useful in many many more situations and places.
Personally, I find Russian the next most interesting language. It's officially the 8th most commonly-spoken language, but in practical terms it's 5th equal with Arabic, Bengali, French, and Portuguese. I would think it's top three (with English and Chinese) for people doing scientific and engineering work.
English is the native language of people in 23% of the Earth's land area. Russian is next at 11%. Chinese is only 6%, behind Arabic, French, Spanish, and Portuguese.
-
Beyond that, as I think I said earlier, the dynamics of popularity in general is something that is very hard to fully understand, even harder to predict. It's not restricted to programming tools. Same for music, any kind of trend, brand new products that didn't exist before, etc. Some things succeed, some miserably fail.
Sure once something starts getting popular, it's just a matter of a feedback loop to keep it going, which is the point we've been at with Python for a numbers of years now. But what really starts it, and likewise, what can end it, is still relatively mysterious in many ways. The inherent merits of the thing in question is often only marginal in the equation.
So, while *fully* understanding why some programming language has become popular is a lost cause, believing that the answer lies in its inherent technical merits (and trying to back up this impression every occasion one gets) is, in most cases, wrong. IMHO.
-
I'm at the opinion that Python's success is only partly related just to the language itself.
The whole Python ecosystem - where you'll easily find a package for nearly everything with reasonable quality, mostly good documentation that's well integrated - is unprecedented IMHO and substantially adding to it's popularity
-
Perl has better libraries
It's not on the same scale any more. You can argue in some niches Perl is better, but it's been vastly superseded in breadth.
Ruby outperforms Python in several ways.
With almost no use at all outside its niche, where its fast becoming a legacy language (used by some giants though, so it will stick around for a long long time)
User base and popularity create network effects. Even if a large percentage of the created code is trash, if it pulls in enough people some of it won't be. If it pulls in enough people, enough of the code will be useful that you can only ignore it at your own economic detriment. Hell, Node.JS has some niche frameworks which simply don't exist in other languages and would take ages to recreate. Sometimes getting over your distaste for a language is best for your pocketbook.
-
I'm at the opinion that Python's success is only partly related just to the language itself.
The whole Python ecosystem - where you'll easily find a package for nearly everything with reasonable quality, mostly good documentation that's well integrated - is unprecedented IMHO and substantially adding to it's popularity
I don't think it's either unprecedented or unique.
Perl was there first with a huge library of code for doing almost anything, and easy package manager.
Javascript has I think probably a larger code ecosystem. The package management is about as good. With "Node" you can use JS on the command line. And with Node using v8 to run the JavaScript you get a superb JIT compiler that is many times faster than Python.
Javascript started off pretty crappy but has improved a lot, and you have a choice of improved versions that are compatible with each other e.g. Coffeescript and TypeScript (with type declarations).
-
Just for fun, I converted that sort program to Javascript. Mostly this was just taking the C version, removing all the types, and sprinkling in the odd "function" or "var" keyword and changing rand() to Math.random() and so forth.
On my x86 Linux machine I get:
0.816 gcc -O qsort.c -o qsort
1.415 Javascript
1.760 gcc qsort.c -o qsort
43.380 Python
So that's pretty fast -- faster than people who use C without turning on the optimiser get -- but it is every bit as dynamicy and scripty as Python.
And it's programmed in the C explicit step-by-step way that you're apparently not supposed to do in Python, not using built in higher level things that Javascript does actually have too.
Note that the Javascript time INCLUDES the time to parse the program and compile it to machine code. That's about another 0.040 seconds for the C version.
Here's qsort.js:
const ARRAYSIZE = 10000000;
function partition(values, left, right, pivotidx) {
let pivot = values[pivotidx];
var temp = values[right];
values[right] = values[pivotidx];
values[pivotidx] = temp;
var storeidx = left;
for(var idx = left; idx<right; idx++) {
if (values[idx] < pivot) {
temp = values[idx];
values[idx] = values[storeidx];
values[storeidx] = temp;
storeidx++;
}
}
temp = values[storeidx];
values[storeidx] = values[right];
values[right] = temp;
return storeidx;
}
function _doquicksort(values, left, right) {
if (right > left) {
var pivotidx = Math.trunc((left + right) / 2);
pivotidx = partition(values, left, right, pivotidx);
_doquicksort(values, left, pivotidx);
_doquicksort(values, pivotidx + 1, right);
}
return values;
}
function quicksort(nums) {
return _doquicksort(nums, 0, ARRAYSIZE-1);
}
var nums = [];
for(var i=0; i<ARRAYSIZE; i++) {
nums[i] = Math.random();
}
var timeit = Date.now();
nums = quicksort(nums);
timeit = Date.now() - timeit;
console.log("time = %f\n", timeit/1000);
And running it...
bruce@rip:~/programs/qsort$ node qsort.js
time = 1.415
-
I am waiting for 3.11 when the apparently 2x speed up is supposed to be occuring
https://m.slashdot.org/story/385526
-
I just changed the array initialisation to...
nums = Math.trunc(Math.random() * ARRAYSIZE);
... to use integers like the other programs instead of floating point.
No other changes.
This reduced the runtime from 1.415 to 1.301, so that's 8.8% faster.
-
I am waiting for 3.11 when the apparently 2x speed up is supposed to be occuring
https://m.slashdot.org/story/385526
Yeah, 3.11 was finally half-usable!
(there should be a win3.11 logo here)
(https://lh3.googleusercontent.com/proxy/PPD8KNvPdeTgxGvPXp5EJ9sHldBdVDETn8b6tL4hu5zZG1beHCeIQCRn7zjjw7_rB_lRD9cV5eatQj9PLvCk2ig)
(Sorry, had to. Remembering hurts me too. Some digit strings with punctuation won't rinse from my mind, not even with bleach.. )
-
Yeah, 3.11 was finally half-usable!
(Sorry, had to. Remembering hurts me too. Some digit strings with punctuation won't rinse from my mind, not even with bleach.. )
NT 3.51 (Build 1057) was the first version of Windows I was prepared to use. It was quite decent, and actually had some advantages over MacOS of the time, unlike Windows 3.0, 3.11, 95, and (barf) 98. It performed quite well on a Pentium Pro 200. I worked on some MVC apps on it using VC++.
Unfortunately, I also had to use Visual SourceSafe, which was just awful.
-
Just for fun, I converted that sort program to Javascript. Mostly this was just taking the C version, removing all the types, and sprinkling in the odd "function" or "var" keyword and changing rand() to Math.random() and so forth.
On my x86 Linux machine I get:
0.816 gcc -O qsort.c -o qsort
1.415 Javascript
1.760 gcc qsort.c -o qsort
43.380 Python
So that's pretty fast -- faster than people who use C without turning on the optimiser get -- but it is every bit as dynamicy and scripty as Python.
And it's programmed in the C explicit step-by-step way that you're apparently not supposed to do in Python, not using built in higher level things that Javascript does actually have too.
Note that the Javascript time INCLUDES the time to parse the program and compile it to machine code. That's about another 0.040 seconds for the C version.
Here's qsort.js:
const ARRAYSIZE = 10000000;
function partition(values, left, right, pivotidx) {
let pivot = values[pivotidx];
var temp = values[right];
values[right] = values[pivotidx];
values[pivotidx] = temp;
var storeidx = left;
for(var idx = left; idx<right; idx++) {
if (values[idx] < pivot) {
temp = values[idx];
values[idx] = values[storeidx];
values[storeidx] = temp;
storeidx++;
}
}
temp = values[storeidx];
values[storeidx] = values[right];
values[right] = temp;
return storeidx;
}
function _doquicksort(values, left, right) {
if (right > left) {
var pivotidx = Math.trunc((left + right) / 2);
pivotidx = partition(values, left, right, pivotidx);
_doquicksort(values, left, pivotidx);
_doquicksort(values, pivotidx + 1, right);
}
return values;
}
function quicksort(nums) {
return _doquicksort(nums, 0, ARRAYSIZE-1);
}
var nums = [];
for(var i=0; i<ARRAYSIZE; i++) {
nums[i] = Math.random();
}
var timeit = Date.now();
nums = quicksort(nums);
timeit = Date.now() - timeit;
console.log("time = %f\n", timeit/1000);
And running it...
bruce@rip:~/programs/qsort$ node qsort.js
time = 1.415
As far as I know cpython does not have jit compilation, which is one of the causes why the explicit way is so slow (the other one is probably implemented directly in c). However, using numba or Pypy might improve your results
-
Just for fun, I converted that sort program to Javascript. Mostly this was just taking the C version, removing all the types, and sprinkling in the odd "function" or "var" keyword and changing rand() to Math.random() and so forth.
On my x86 Linux machine I get:
0.816 gcc -O qsort.c -o qsort
1.415 Javascript
1.760 gcc qsort.c -o qsort
43.380 Python
So that's pretty fast -- faster than people who use C without turning on the optimiser get -- but it is every bit as dynamicy and scripty as Python.
And it's programmed in the C explicit step-by-step way that you're apparently not supposed to do in Python, not using built in higher level things that Javascript does actually have too.
Note that the Javascript time INCLUDES the time to parse the program and compile it to machine code. That's about another 0.040 seconds for the C version.
Here's qsort.js:
const ARRAYSIZE = 10000000;
function partition(values, left, right, pivotidx) {
let pivot = values[pivotidx];
var temp = values[right];
values[right] = values[pivotidx];
values[pivotidx] = temp;
var storeidx = left;
for(var idx = left; idx<right; idx++) {
if (values[idx] < pivot) {
temp = values[idx];
values[idx] = values[storeidx];
values[storeidx] = temp;
storeidx++;
}
}
temp = values[storeidx];
values[storeidx] = values[right];
values[right] = temp;
return storeidx;
}
function _doquicksort(values, left, right) {
if (right > left) {
var pivotidx = Math.trunc((left + right) / 2);
pivotidx = partition(values, left, right, pivotidx);
_doquicksort(values, left, pivotidx);
_doquicksort(values, pivotidx + 1, right);
}
return values;
}
function quicksort(nums) {
return _doquicksort(nums, 0, ARRAYSIZE-1);
}
var nums = [];
for(var i=0; i<ARRAYSIZE; i++) {
nums[i] = Math.random();
}
var timeit = Date.now();
nums = quicksort(nums);
timeit = Date.now() - timeit;
console.log("time = %f\n", timeit/1000);
And running it...
bruce@rip:~/programs/qsort$ node qsort.js
time = 1.415
import numpy as np
import time
numpy.random.seed(0)
nums = np.random.randint(np.iinfo(np.int64).min, np.iinfo(np.int64).max,size = 1000000,dtype = 'int64')
timeit = time.time()
nums = nums.sort()
timeit = time.time() - timeit
print('time =', timeit)
time = 0.11429095268249512
Conclusion: Python is faster than C if you know what you are doing.
-
time = 0.11429095268249512
Conclusion: Python is faster than C if you know what you are doing.
Number 1: you didn't program in Python, you used someone's C library. You might with as much logic say that bash is faster than C because you typed "python sort_using_numpy.py" to run it.
Number 2: the ridiculous result that numpy was 7 times faster than C [1] should have clued you in to the fact that the other programs are sorting ten times more data than you are.
[1] admittedly we don't know how fast your computer is because you didn't present a C result but it can't be much faster than my AMD Zen x86 and M1 ARM Mac, which are pretty close in performance.
-
time = 0.11429095268249512
Conclusion: Python is faster than C if you know what you are doing.
Number 1: you didn't program in Python, you used someone's C library. You might with as much logic say that bash is faster than C because you typed "python sort_using_numpy.py" to run it.
Number 2: the ridiculous result that numpy was 7 times faster than C [1] should have clued you in to the fact that the other programs are sorting ten times more data than you are.
[1] admittedly we don't know how fast your computer is because you didn't present a C result but it can't be much faster than my AMD Zen x86 and M1 ARM Mac, which are pretty close in performance.
1) Ok, run it with 10 times data, 1.1 sec. maybe you should just point out that I missed a 0 compared to your intentionally badly written
2) I'm done talking to you, because you sir are a rude ... and I don't see a reason to continue any discussion, because you turned this into an echo chamber.
-
I am waiting for 3.11 when the apparently 2x speed up is supposed to be occuring
https://m.slashdot.org/story/385526
If there was one thing that could express what is wrong with Python on a higher level, that would be this announcement.
"Microsoft Funds a Team with Guido van Rossum to Double the Speed of Python ."
:popcorn:
-
Yep! I was gradually warming up to putting my prejudice aside and taking a running jump at Python, but the Microsoft link has undone one of my shoelaces.
-
1) Ok, run it with 10 times data, 1.1 sec. maybe you should just point out that I missed a 0 compared to your intentionally badly written
1) it's not my code, it's Picuino's. I have merely run it, and made a trivial conversion from C to Javascript without fixing or commenting on the goodness or otherwise of the code, because that was not germane to the discussion. It gets the job done.
2) putting important constants at the start of the program is generally considered best practice, and Picuino did that.
3) it seems numpy takes about 85% of the time of fairly non-optimal code written in one of the worst programming languages ever imposed on the world (sorry Brendan, you know it's true). That doesn't seem something to be proud of. I could probably make a couple of trivial modifications to Picuino's code to speed it up by most of the 15% difference.
4) numpy and other libraries offer a notational advantage -- you don't have to write so much code yourself. This is valuable IF they contain what you need. If not then .. boom .. glass jaw, and you're back to slow Python.
2) I'm done talking to you, because you sir are a rude ... and I don't see a reason to continue any discussion, because you turned this into an echo chamber.
The feeling, sir, is mutual. You were the one who started talking in an insulting way. Do you enjoy getting it back? Apparently not. I am polite with people who are polite to me.
-
pySerial ... people prefer to use it instead of making good C code to handle the serial-line.
As result, you find pySerial even for embedded things. That's no good.
-
Funny you should mention that. I purchased a hardware product which has a front end written in python running on the PC. Seemed to be OK and I put down the odd glitch of strange data to the product I was using this to test. But then I used exactly the same product, in exactly the same way, with exactly the same python install on a much slower PC, and blow me if the thing was throwing glitches all over the place. Seems like serial over USB needed a quad core CPU just to not have dropped data.
-
Yeah, but look how easy it is to do it with Python! :popcorn:
-
Just posting this for anyone who may be interested. Runtime: 1hr.
The Worst Programming Language Ever (Mark Rendle, 2014)
There's something good you can say about every programming language. But that's no fun. Instead, let's take the worst features of all the languages we know, and put them together to create an abomination with the worst syntax, the worst semantics, the worst foot-guns and the worst runtime behaviour in recorded history. Let's make a language so bad it would make people run screaming to Visual Basic for Applications.
https://www.youtube.com/watch?v=2mnYf7L7Amw (https://www.youtube.com/watch?v=2mnYf7L7Amw)
-
import serial
import sys
ourSerial = serial.Serial()
ourSerial.port = '/dev/ttyS0'
ourSerial.baudrate = 9600
ourSerial.bytesize = serial.EIGHTBITS
ourSerial.parity = serial.PARITY_NONE
ourSerial.stopbits = serial.STOPBITS_ONE
ourSerial.xonxoff = False
ourSerial.rtscts = False
ourSerial.dsrdtr = False
ourSerial.open()
ourSerial.flushInput()
ourSerial.flushOutput()
with open (sys.argv[1]) as fil:
for li in fil:
ourSerial.write(li)
ourSerial.flush()
fil.close()
9600-8-1-none
like this :D
-
Relevant part seems to be:
while counter1 < sleep_timer.get():
sleep_reading.set(ser.readline(2).hex())
if round((int(sleep_reading.get(),16)*LSB)/float(sense_resistor.get()),6) < 500 \
and round((int(sleep_reading.get(),16)*LSB)/float(sense_resistor.get()),6) != 0.0:
si.append(round((int(sleep_reading.get(),16)*LSB)/float(sense_resistor.get()),6))
sleep_file.write(str(round((int(sleep_reading.get(),16)*LSB)/float(sense_resistor.get()),6)))
sleep_file.write('\n')
Seems to be rather a lot of floating point stuff inbetween serial port reads. But since I currently don't do python it could be something else.
-
Just for fun, I converted that sort program to Javascript. Mostly this was just taking the C version, removing all the types, and sprinkling in the odd "function" or "var" keyword and changing rand() to Math.random() and so forth.
On my x86 Linux machine I get:
0.816 gcc -O qsort.c -o qsort
1.415 Javascript
1.760 gcc qsort.c -o qsort
43.380 Python
So that's pretty fast -- faster than people who use C without turning on the optimiser get -- but it is every bit as dynamicy and scripty as Python.
I reworked the Javascript a little to use a better (my opinion) partition function, and also to only use the recursive partitioning if the partition size was greater than 40, and then do an insertion sort cleanup at the end.
0.82: improved Javascript
1.02: improved Javascript, without insertion sort cleanup
6:41:59.48: improved Javascript, insertion sort without recursive partitioning first
Note that the Javascript time is now almost identical to the optimised C time (with a slightly worse partitioning algorithm). And 34% faster than the 1.1 seconds reported for numpy's built in sort function -- assuming comparable machines, which we don't know. My x86 Linux machine is a three year old (August 2018) Zen 1+ with only 4.2 GHz maximum clock so it's quite likely the machine numpy was run on was as fast or faster.
I'm actually shocked the Javascript is as fast as it is. It's not just a convenient high level scripting language for gluing together libraries other people have written, these days it's good enough to *write* the libraries in too.
The improved Javascript:
const ARRAYSIZE = 10000000;
function partition(nums, left, right) {
let pivot = nums[Math.trunc((left + right) / 2)];
var i = left-1, j = right+1;
while (1) {
var iv, jv;
do { iv = nums[++i] } while (iv < pivot);
do { jv = nums[--j] } while (jv > pivot);
if (i >= j) break;
nums[i] = jv;
nums[j] = iv;
}
return j;
}
function _doquicksort(nums, left, right) {
if ((right - left) > 40) {
let pivotidx = partition(nums, left, right);
_doquicksort(nums, left, pivotidx);
_doquicksort(nums, pivotidx + 1, right);
}
}
function _doinsertionsort(nums, size) {
for (var i=1; i<size; ++i) {
var vi = nums[i], j = i-1;
for (; j>=0; --j) {
let vj = nums[j];
if (vj <= vi) break;
nums[j+1] = vj;
}
nums[j+1] = vi;
}
}
function quicksort(nums, size) {
_doquicksort(nums, 0, size-1);
_doinsertionsort(nums, size);
}
function checkSorted(nums, size) {
for (var i=1; i<size; ++i) {
if (nums[i] > nums[i+1])
console.log("Items %d and %d not sorted: %d %d\n", i, i+1, nums[i], nums[i+1]);
}
}
var nums = [];
for(var i=0; i<ARRAYSIZE; i++) {
nums[i] = Math.trunc(Math.random() * ARRAYSIZE);
}
var timeit = Date.now();
quicksort(nums, ARRAYSIZE);
timeit = Date.now() - timeit;
console.log("time = %f\n", timeit/1000);
checkSorted(nums, ARRAYSIZE);
-
I've so many times had annoying troubles with python-serial (pyserial) and similar, that I nowadays recommend using nonblocking I/O (O_NONBLOCK when opening the device, preferably with O_CLOEXEC so as to not leak the descriptor to child processes), using termios to set the character device to pure 8-bit raw mode.
Python3 does have termios support built-in (see pydoc3 termios), and you'll need to use the built-in fcntl and select modules too (see pydoc3 fcntl and pydoc3 select) to implement non-blocking I/O, so it's not impossible; but, I do prefer doing it in C anyway.
For USB Serial in a Python application, it can make sense to use two Python threads instead, one for writing, and another for reading, both blocking (not non-blocking), optionally using a third thread for the coordination between the two; and communicating with the UI using Queues (one per direction). This is thread-safe, and since the threads are almost always in a blocking I/O call, the fact that the current Python interpreter only executes one thread of Python code at a time, is perfectly acceptable.
For simple Graphical User Interfaces controlling an USB Serial microcontroller widget with a native USB interface developed in the Arduino, like a Teensy, this works perfectly. The serial interface can be implemented separately for each OS (in Python), and for Linux and POSIX-type OSes, the basic threaded 2/3 worker model works very well and allows completely asynchronous interface to the device, while being so simple that even a completely new programmer can get it right.
(Again, note that in Linux, this involves only packages available in package management, so when distributed as a standard package (with sensible library version requirements!), there are no dependency issues; it Just Works.)
The completely asynchronous interface means that instead of the traditional query-response ping-pong approach, the host and the device has essentially two separate data streams that do not need to interact at all: one from the host to the device, and the other from the device to the host. Given a native USB interface, the MCU can almost always support multiple endpoints, so that you can have for example a dedicated data streams and a dedicated control stream. (I'd like to switch to bulk USB transfers, but thus far haven't found a way for really new programmers to grasp all of that as easily as USB Serial.) A common one is a gamepad or joystick, keyboard, and USB Serial.
Because Human Interface Devices (HID) do not require OS drivers or privileges, for low-bandwidth applications (much less than 64000 bytes per second, 1ms latency per message) HID is a superior choice, as it completely avoids the OS driver support mess, and Just Works.
Even the communications protocol between the application and the microcontroller then uses the event-based approach. If you have queries and responses, you'll associate each with an identifier, so that more than one thing can be under work at the same time, and there is no specific order to things, as they are identified by the identifier and can occur in whatever order. This can help a lot with latencies and delays, and can boost the achievable throughput –– say, for a data acquisition device where there is lots of data flowing in to the host, and only occasionally some control commands to the device –– avoiding the annoying "glitches" (drops in data) during command parsing. You know, useful stuff, and not at all difficult to grasp when you have your mind open and are willing to learn new stuff.
Whether the interface to such a device is implemented in Python or in C, even when the user interface was in Python, is a bigger picture question. If the device is not tightly coupled to the software, and the vendor doesn't mind the clients developing new applications for the device, then a pure Python implementation makes sense.
If the device and the software are tightly coupled together and both the device and the processing of the data to/from the device involve Top Sekrit Sauce, then C or C++ makes a lot more sense.
When interfacing with Python, I do prefer to use C and not C++, because the runtime dependencies are so much simpler for C. In Linux, for example, basically all dynamically linked executables, no matter what programming language they use, have a runtime dependency on the standard C library. So, if one limits oneself to C only, the dependencies are minimized. Others prefer the power of expression and approaches in C++, and consider the added dependencies worth the packaging effort.
As this shows once again, I don't personally use Python for its language features or its libraries, but because it has a gentle learning curve for new programmers and allows them to do modifications without a development environment, and because it is so easy to interface to native libraries, having only to write Python code for the interface; and because its nature as a scripting language provides a perfect licensing separation for more complex licensing schemes. AIUI, all other widely used scripting languages like Ruby and Lua do require additional native code for efficient bindings.
-
I am waiting for 3.11 when the apparently 2x speed up is supposed to be occuring
https://m.slashdot.org/story/385526
Yeah, 3.11 was finally half-usable!
(there should be a win3.11 logo here)
(https://lh3.googleusercontent.com/proxy/PPD8KNvPdeTgxGvPXp5EJ9sHldBdVDETn8b6tL4hu5zZG1beHCeIQCRn7zjjw7_rB_lRD9cV5eatQj9PLvCk2ig)
(Sorry, had to. Remembering hurts me too. Some digit strings with punctuation won't rinse from my mind, not even with bleach.. )
Oh don't worry about it, I'm not old enough to have experienced that let alone remember it 😂
-
"October Headline: Python programming language number 1!
Can confirm Python as the most full of nice surprises (thought it's more about its modules this time), but here's the full tale, true story:
- was upset about the user interface changes after Firefox ESR upgraded, and that they let no way to revert the UI
- tried about a week for alternative browsers, there are not many options left, by the way
- then one dude on another forum wrote this:
Any other browsers I should consider for a KDE/Qt5 desktop with a big monitor and a mouse?
(idea) You can create own browser.
These are two random tutorials from the internet, just to show the idea, I didn't check if they are correct, but I experimented in the past.
qt https://techvidvan.com/tutorials/create-web-browser-python-pyqt/ (https://techvidvan.com/tutorials/create-web-browser-python-pyqt/)
webkit https://pythonprogramminglanguage.com/webkit-browser/ (https://pythonprogramminglanguage.com/webkit-browser/)
Well, I wouldn't believe but it's that easy indeed! ???
A DIY web browser in Python v1:
# [url]https://pythonprogramminglanguage.com/webkit-browser/[/url]
#!/usr/bin/python
from PyQt5.QtCore import *
from PyQt5.QtWidgets import *
# from PyQt5.QtWebKitWidgets import * # was deprecated, now it is called QtWebEngineWidgets, pip install PyQtWebEngine
# from PyQt5.QtWebEngineWidgets import *
from PyQt5.QtWebEngineWidgets import QWebEngineView as QWebView
from PyQt5.QtGui import *
import sip
import sys
class tabdemo(QMainWindow):
def __init__(self):
super(tabdemo, self).__init__()
self.setAttribute(Qt.WA_DeleteOnClose)
self.tabs = QTabWidget()
self.tabs.setTabsClosable(True)
self.tabs.tabCloseRequested.connect(self.closeTab)
self.tab1 = QWidget()
self.tabWebView = []
self.lNameLine = []
self.tabs.addTab(self.tab1,"New Tab")
self.tab1UI(self.tab1)
self.setWindowTitle("PyQt [url]https://pythonprogramminglanguage.com[/url]")
self.setCentralWidget(self.tabs)
self.showMaximized()
QShortcut(QKeySequence("Ctrl+T"), self, self.addTab)
def addTab(self):
tab = QWidget()
self.tabs.addTab(tab,"New Tab")
self.tab1UI(tab)
index = self.tabs.currentIndex()
self.tabs.setCurrentIndex( index + 1 )
#self.tabWebView[self.tabs.currentIndex()].load( QUrl('about:blank'))
def goBack(self):
index = self.tabs.currentIndex()
self.tabWebView[index].back()
def goNext(self):
index = self.tabs.currentIndex()
self.tabWebView[index].forward()
def goRefresh(self):
index = self.tabs.currentIndex()
self.tabWebView[index].reload()
def changePage(self):
index = self.tabs.currentIndex()
pageTitle = self.sender().title()[:15]
self.tabs.setTabText(index, pageTitle);
self.lNameLine[self.tabs.currentIndex()].setText(self.sender().url().url())
def load_started(self):
return
def tab1UI(self,tabName):
webView = QWebView()
backButton = QPushButton("")
backIcon = QIcon()
backIcon.addPixmap(QPixmap("back.svg"))
backButton.setIcon(backIcon)
backButton.setFlat(True)
nextButton = QPushButton("")
nextIcon = QIcon()
nextIcon.addPixmap(QPixmap("next.svg"))
nextButton.setIcon(nextIcon)
nextButton.setFlat(True)
refreshButton = QPushButton("")
refreshIcon = QIcon()
refreshIcon.addPixmap(QPixmap("refresh.svg"))
refreshButton.setIcon(refreshIcon)
refreshButton.setFlat(True)
backButton.clicked.connect(self.goBack)
nextButton.clicked.connect(self.goNext)
refreshButton.clicked.connect(self.goRefresh)
self.newTabButton = QPushButton("+")
self.destroyTabButton = QPushButton("-")
self.tabWidget = QTabWidget()
nameLine = QLineEdit()
nameLine.returnPressed.connect(self.requestUri)
tabGrid = QGridLayout()
tabGrid.setContentsMargins(0,0,0,0)
navigationFrame = QWidget()
navigationFrame.setMaximumHeight(32)
navigationGrid = QGridLayout(navigationFrame)
navigationGrid.setSpacing(0)
navigationGrid.setContentsMargins(0,0,0,0)
navigationGrid.addWidget(backButton,0,1)
navigationGrid.addWidget(nextButton,0,2)
navigationGrid.addWidget(refreshButton,0,3)
navigationGrid.addWidget(nameLine,0,4)
tabGrid.addWidget(navigationFrame)
webView = QWebView()
htmlhead = "<head><style>body{ background-color: #fff; }</style></head><body></body>";
webView.setHtml(htmlhead)
#webView.loadProgress.connect(self.loading)
webView.loadFinished.connect(self.changePage)
frame = QFrame()
frame.setFrameStyle(QFrame.Panel)
gridLayout = QGridLayout(frame);
#gridLayout.setObjectName(QStringLiteral("gridLayout"));
gridLayout.setContentsMargins(0, 0, 0, 0);
gridLayout.addWidget(webView, 0, 0, 1, 1);
frame.setLayout(gridLayout)
self.tabWebView.append(webView)
self.tabWidget.setCurrentWidget(webView)
self.lNameLine.append(nameLine)
tabGrid.addWidget(frame)
tabName.setLayout(tabGrid)
def tab2UI(self):
vbox = QVBoxLayout()
tbl1 = QTableWidget()
tbl1.setRowCount(5)
tbl1.setColumnCount(5)
vbox.addWidget(tbl1)
tbl1.setItem(0, 0, QTableWidgetItem("1")) # row, col
self.tab2.setLayout(vbox)
def requestUri(self):
if self.tabs.currentIndex() != -1:
urlText = self.lNameLine[self.tabs.currentIndex()].text()
##########################
# no protocol?
if 'http' not in urlText:
self.lNameLine[self.tabs.currentIndex()].setText( 'https://' + urlText)
url = QUrl(self.lNameLine[self.tabs.currentIndex()].text())
print(self.tabs.currentIndex())
if url.isValid():
self.tabWebView[self.tabs.currentIndex()].load(url)
else:
print("Url not valid")
else:
print("No tabs open, open one first.")
def closeTab(self,tabId):
print(tabId)
del self.lNameLine[tabId]
del self.tabWebView[tabId]
self.tabs.removeTab(tabId)
def main():
app = QApplication(sys.argv)
ex = tabdemo()
ex.show()
sys.exit(app.exec_())
if __name__ == '__main__':
main()
A DIY web browser in Python v2:
import sys
#importing Widgtes
from PyQt5.QtWidgets import *
#importing Engine Widgets
from PyQt5.QtWebEngineWidgets import *
#importing QtCore to use Qurl
from PyQt5.QtCore import *
#main window class (to create a window)-sub class of QMainWindow class
class Window(QMainWindow):
#defining constructor function
def __init__(self):
#creating connnection with parent class constructor
super(Window,self).__init__()
#---------------------adding browser-------------------
self.browser = QWebEngineView()
#setting url for browser, you can use any other url also
self.browser.setUrl(QUrl('[url]https://duckduckgo.com/'[/url]))
#to display the search engine on our browser
self.setCentralWidget(self.browser)
#-------------------full screen mode------------------
#to display browser in full screen mode, you may comment below line if you don't want to open your browser in full screen mode
self.showMaximized()
#----------------------navbar-------------------------
#creating a navigation bar for the browser
navbar = QToolBar()
#adding created navbar
self.addToolBar(navbar)
#-----------------prev Button-----------------
#creating prev button
prevBtn = QAction('Prev',self)
#when triggered set connection
prevBtn.triggered.connect(self.browser.back)
# adding prev button to the navbar
navbar.addAction(prevBtn)
#-----------------next Button---------------
nextBtn = QAction('Next',self)
nextBtn.triggered.connect(self.browser.forward)
navbar.addAction(nextBtn)
#-----------refresh Button--------------------
refreshBtn = QAction('Refresh',self)
refreshBtn.triggered.connect(self.browser.reload)
navbar.addAction(refreshBtn)
#-----------home button----------------------
homeBtn = QAction('Home',self)
#when triggered call home method
homeBtn.triggered.connect(self.home)
navbar.addAction(homeBtn)
#---------------------search bar---------------------------------
#to maintain a single line
self.searchBar = QLineEdit()
#when someone presses return(enter) call loadUrl method
self.searchBar.returnPressed.connect(self.loadUrl)
#adding created seach bar to navbar
navbar.addWidget(self.searchBar)
#if url in the searchBar is changed then call updateUrl method
self.browser.urlChanged.connect(self.updateUrl)
#method to navigate back to home page
def home(self):
self.browser.setUrl(QUrl('[url]https://duckduckgo.com/'[/url]))
#method to load the required url
def loadUrl(self):
#fetching entered url from searchBar
url = self.searchBar.text()
#loading url
self.browser.setUrl(QUrl(url))
#method to update the url
def updateUrl(self, url):
#changing the content(text) of searchBar
self.searchBar.setText(url.toString())
MyApp = QApplication(sys.argv)
#setting application name
QApplication.setApplicationName('A 100 lines DIY Web Browser :o)')
#creating window
window = Window()
#executing created app
MyApp.exec_()
Both working! :D
The second one fits in 100 lines, comments and empty ones included.
(https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/?action=dlattach;attach=1320206;image)
For the second link, PyQtWebEngine must be used instead (pip install PyQtWebEngine), QtWebKitWidgets is now deprecated in PyQt5: https://stackoverflow.com/questions/37876987/cannot-import-qtwebkitwidgets-in-pyqt5 (https://stackoverflow.com/questions/37876987/cannot-import-qtwebkitwidgets-in-pyqt5)
It's strange to creepy that it somehow deals with cookies, and was able to remember a forum login after closing the python browser and running the .py file again. :o
-
It's strange to creepy that it somehow deals with cookies, and was able to remember a forum login
Perhaps because it's a skin on Webkit, which is Apple's browser engine?
-
Might be, will have to look into that if I'll use the module for real.
I've noticed later today that the login remembering is not permanent, after a while it forgot the login, maybe it's somehow related with how EEVblog deals with logins (and so far I didn't test the login for other web places).
-
Tiobe Index (https://www.tiobe.com/tiobe-index/) for November 2021:
(https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/?action=dlattach;attach=1320302;image)
-
I don't believe the 8th place is realistic for assembly as a nowadays programming language, not even if we add microcontrollers and ARM together with PC as a single "assembly language". IMO it is rather on the 80th place or so, certainly not in the top 10.
-
Tiobe Index (https://www.tiobe.com/tiobe-index/) for November 2021:
My bolding -
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
-
Does anyone know of another good index for programming languages that measures usage or another interesting parameter?
-
Top Highly Paid Programming Languages:
https://lvivity.com/top-highly-paid-programming-languages (https://lvivity.com/top-highly-paid-programming-languages)
https://analyticsindiamag.com/top-11-languages-which-can-fetch-you-good-salary-in-2020/ (https://analyticsindiamag.com/top-11-languages-which-can-fetch-you-good-salary-in-2020/)
https://www.codeplatoon.org/best-paying-most-in-demand-programming-languages-2020/ (https://www.codeplatoon.org/best-paying-most-in-demand-programming-languages-2020/)
https://content.techgig.com/24-highest-paying-programming-languages-for-developers/articleshow/76243434.cms (https://content.techgig.com/24-highest-paying-programming-languages-for-developers/articleshow/76243434.cms)
It varies too much depending on the website.
-
Does anyone know of another good index for programming languages that measures usage or another interesting parameter?
Language usage in GitHub projects: https://madnight.github.io/githut/#/pull_requests/2021/3
A similar statistic can also be found in: https://githut.info/
-
Maybe pull requests are related to developers having to fix previous fixes regularly :)
https://madnight.github.io/githut/#/issues/2021/3
There, could either be that python is very popular, thus creating lots of projects, or it's easier to make mistakes and attract issue reports.
-
While any popularity index is questionable per se, and TIOBE is no exception, at least it gets its data from a number of different sources. Using a single one will always be more biased.
It's fun to see that the #1 language on github is Javascript. Although I would take even this with a pinch of salt, given how github projects are classified in terms of languages. (Would be nice to know how they aggregated the numbers in this index: because while each project individually shows a list of languages it uses with a % - projects are attributed a main language (automatically?) and I've found that in practice it was often misleading.)
-
Does anyone know of another good index for programming languages that measures usage or another interesting parameter?
Language usage in GitHub projects: https://madnight.github.io/githut/#/pull_requests/2021/3
A similar statistic can also be found in: https://githut.info/
Be aware that a source of bias in those figures is that github mostly hosts open and free software.
That means that the part of the programming world that doesn't want to share won't be well represented. So for example, I can't see Ada at all but I can see Smalltalk - my instinct is that there is much more Ada written every year than Smalltalk but it is written in places that mandate Ada and are very much unminded to share their code outside of 4 very well guarded walls.
-
Just posting this here, since that time of the year is about to come around again. Discuss in groups :popcorn:
https://www.r-bloggers.com/2018/12/advent-of-code-most-popular-languages/ (https://www.r-bloggers.com/2018/12/advent-of-code-most-popular-languages/)
Sign up for 2021 and improve the statistics for your favorite language!
https://adventofcode.com/2021/about (https://adventofcode.com/2021/about)
-
Just posting this here, since that time of the year is about to come around again. Discuss in groups :popcorn:
https://www.r-bloggers.com/2018/12/advent-of-code-most-popular-languages/ (https://www.r-bloggers.com/2018/12/advent-of-code-most-popular-languages/)
Sign up for 2021 and improve the statistics for your favorite language!
https://adventofcode.com/2021/about (https://adventofcode.com/2021/about)
With python being so much ahead of PHP and Javascript, hopefully we see it being integrated to web browsers in the future.
It would be so great to generate .html files with python code executed in them.
-
Transcrypt. (https://www.transcrypt.org/)
-
"
TIOBE Index for January 2022 (https://www.tiobe.com/tiobe-index/)
January Headline: Python Programming Language of the Year 2021
Python has won the prestigious TIOBE Programming Language of the Year award. Congratulations! This is the second time in a row. The award is given to the programming language that has gained the highest increase in ratings in one year. C# was on its way to get the title for the first time in history, but Python surpassed C# in the last month.
Python started at position #3 of the TIOBE index at the beginning of 2021 and left both Java and C behind to become the number one of the TIOBE index. But Python's popularity didn't stop there. It is currently more than 1 percent ahead of the rest. Java's all time record of 26.49% ratings in 2001 is still far away, but Python has it all to become the de facto standard programming language for many domains. There are no signs that Python's triumphal march will stop soon.
Are there any serious contenders for Python? Any new and shiny languages that might compete in the future? If we look at the promising languages of the last few years, we see the following changes in 2021: Swift from #13 to #10, Go from #14 to #13, Rust from #26 to #26, Julia from #23 to #28, Kotlin from #40 to #29, Dart from #25 to #37, and TypeScript from #42 to #49. So, except may be for Swift and Go, we don't expect any new languages entering the top 5 or even the top 3 any time soon.
"
-
ucpython on graphic calculators is a mode hype but it's practically a bad idea because it's less usable than basic
-
ucpython on graphic calculators is a mode hype but it's practically a bad idea because it's less usable than basic
Python in general, and its derivatives in particular, are a mode hype. =)
The language HP used for the HP Prime is a reasonable one for this purpose. It comes from the HP Basic that was first introduced in the HP38G and then made it in the HP39gII before hitting the Prime.
-
I have tried Python and would certainly not want to use it again.
Python for math seems to be mandatory. I have different feelings and opinions, but it's practically irrelevant, I have to follow the hype, otherwise there are neither libraries nor tools :-//
If it has the libraries and tools you need maybe it's not hype and other people need those too?
-
If it has the libraries and tools you need maybe it's not hype and other people need those too?
Or maybe everyone is just following the hype, because they fear that by doing otherwise, they'll stand out or drop out somehow?
I do not know, though. I use Python. I also used to do a lot of PHP backend programming, back in the day when PHP used to be an order of magnitude more horrible than today (magic_quotes_gpc stuff in particular). One uses the tools that are available.
The fact that some tools are widely used, does not make them crappy or non-hyped; only popular. And we do know that popularity has nothing to do with quality, and everything with branding and public relations: hype.
-
- my instinct is that there is much more Ada written every year than Smalltalk but it is written in places that mandate Ada and are very much unminded to share their code outside of 4 very well guarded walls.
I think you mean 5 walls :)
-
Or maybe everyone is just following the hype, because they fear that by doing otherwise, they'll stand out or drop out somehow?
Perhaps there should be a Tulip award.
-
I also used to do a lot of PHP backend programming, back in the day when PHP used to be an order of magnitude more horrible than today
An horrible example: PHPBB (a forum template) is written in PHP.
PHP + dynamic pages = you are certainly in troubles ----> the best you can do is to *sanitize* all the input fields
What do you use to *debug* PHP?
I am randomly programming web-things in PHP, for the new year: I'd like to replace PHP with Ruby (on Rails) ;D
-
If it has the libraries and tools you need maybe it's not hype and other people need those too?
There is a strong campaign to promote Python, it seems that a product like a graphing calculator is not a good product if it doesn't support Python.
- "This graphing calculator is Python powered"
- "It offers the power of Python on your finger tips"
- "Python makes everybody a math person"
- "...
(words are futile, just see it has an Python icon printed on the box)
Tested on
- Casio fx9860giii graphic calculator
- Numworks 2020
No matter if
- 1: you cannot *edit* a script on your calculator, and you need to connect to a PC to do it; what's the sense of this?!? if I need a computer to edit a python script, well ... I would run the script on the computer, not on the calculator
- 2: even if you somehow get a script loaded, well .. they python environment is completely separated to the calculator environment ... as if you had two calculators in one product, but completely separated and unable to communicate and interact (for example, you cannot use Python to calculate a table, and pass it to the Plot module because the Plot(x,y) module cannot import anything from the Python module, and the Python module cannot export anything to other modules): and again, what is the sense here?!?
"Python makes everybody a math person" ... umm, so if a calculator doesn't support Python ... then it doesn't make the user a math person.
That's the core of the new hype!
-
And at the end of the day CPUs run machine code. >:D Another interesting point is that soft devs arguing about which programming language might be the best often treat CPUs as a magic black box. But all the different CPU architectures, designs and add-ons have an impact on what can be done with a specific CPU. We should consider the whole package!
-
What do you use to *debug* PHP?
To debug PHP, you replace it with something better.
To debug code written in PHP, you use Very Careful Eyeballs, Mark II.
(Mark II are the suspicious/paranoid ones; the Mark I are the bright creative ones that were used to write the code. To switch between the two, I use Sleep in between.)
It's not just sanitizing inputs (don't forget the CGI environment variables, and things like "../" in client-supplied URLs and paths), but making sure that whenever (temporary) files are uploaded to the server, they are not immediately accessible (published on the web tree), because that allows script drops and other nasties; and that before moving a file from that temporary storage to visible storage, it too is verified to be non-script content.
One thing that makes debugging PHP harder than other scripting languages is that while you can run the PHP interpreter from the command line, it is not the same one used for web pages (regardless of whether you use mod_php or php-as-fastcgi); even the configuration files are different. Essentially, for PHP development, you have to setup a (local) web server that only you can access.
At least Python uses the same interpreter (if run as CGI or fastcgi), and with a bit of fiddling, you can set up a "debug harness" that runs the scripts exactly as they would as a cgi/fastcgi script. The downside is that Python pushes hard for its own WSGI interface, which can be annoying. (And the "on Rails" part is why I haven't delved too far into Ruby, either. I want a frigging language that does not try to force its favourite web framework on me, dammit! I do my own minimal, lightweight ones, please and thank you.)
In general, if the Unix owner and group of the scripts and published files were different to the owner and group running the script interpreter, you could set up checks that no user uploaded content would ever be executed as a script, eliminating basically all script drop attacks (but still leaving JavaScript-based cross-site scripting risks). However, no web hotel (Plesk, CPanel, etc.) currently provides more than one account for a web site; you need a virtual server to do even such trivial security enhancement. And this applies to all scripting languages, not just PHP. The reason so many developers do not want this, is that it also means the code cannot upgrade itself anymore either, the user (or automated facility on the host) has to do it from the owner account instead. Oh, the horror.
-
even though less frequent used today..
Apache mod_perl has some PERL tidbits hard to replace w/any other alternative...
even faster than fcgi builds
Paul
-
Apache mod_perl has some PERL tidbits hard to replace w/any other alternative...
And some downsides, like running the interpreter in the same process as the Apache server itself. I actually use fastcgi for security features and not speed/efficiency at all; executing scripts using a dedicated account, different to the filesystem owner/group. For the same reason, I preferred to avoid mod_php too, and use the fastcgi-enabled PHP interpreter binary instead.
Most recently, I've looked at using my own Python3 code as the fastcgi dispatcher daemon (on a vhost basis). That way, the dispatcher could load e.g. the navigation information and other commonly used data from Python before any requests arrive, and fork the interpreter process (keeping all that useful Python data, removing any security-sensitive data) for each page request. I will probably do that with one of the other scripting languages, when I encounter one I like enough.
As to Perl itself, I have PTSD from having to try and maintain an installation of a horrible Perl web groupware, before the turn of the century. I know it is completely my own fault and not Perl's fault, since anyone can write such horrible stuff in any language, but I just can't touch Perl anymore.
I did learn from that though: I never started relying on any similarly horrible PHP code, and instead always wrote the most critical parts myself. I knew that if I'd have to keep some horrible PHP project usable, I'd soon be turned off PHP the same way.
Consider it a personal oddity of mine, or perhaps a battle wound... :-//
-
an installation of a horrible Perl web groupware
We need names!
-
an installation of a horrible Perl web groupware
We need names!
From memory there were several abominations that might fit that description.
-
an installation of a horrible Perl web groupware
We need names!
I don't wanna, because I actually like the authors, and I don't want them get pissed at me.
-
And at the end of the day CPUs run machine code. >:D Another interesting point is that soft devs arguing about which programming language might be the best often treat CPUs as a magic black box. But all the different CPU architectures, designs and add-ons have an impact on what can be done with a specific CPU. We should consider the whole package!
The difference between Instruction Sets surviving in 2022 is pretty minor. One of them is much harder to implement well than than others -- but the companies using that one have a lot of money from their historical near-monopoly.
It matters a bit how wide memory addresses and ALUs are, and whether or not there is an FPU and (these days) SIMD.
But all this pales compared to the efficiency of programming languages.
A RISC-V CPU you design yourself in a weekend and implement in an FPGA runs C code roughly as quickly as the fastest Intel or AMD CPU that had billions of dollars spent on it runs Python.
-
an installation of a horrible Perl web groupware
We need names!
I don't wanna, because I actually like the authors, and I don't want them get pissed at me.
Fair.
Actually, I've never been burned by Perl. Speaks mostly about my inexperience of course.
Still, I've produced working systems that use Perl, mostly making up for lacking functions in other stuff.
-
Still, I've produced working systems that use Perl, mostly making up for lacking functions in other stuff.
Yup; there is quite a lot of perfectly okay Perl code out there.
Typically, the pain-inducing features of a codebase are when there is no proper structure and organization, and instead code gets copied around, and occasionally modified –– the exact wrong kind of code reuse. Without proper comments and documentation, and without any modular or organized approach, the interdependencies in the code quickly become so complicated, that "code spaghetti" becomes an apt description.
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
-
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
That is true for any language, even. =)
-
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
That is true for any language, even. =)
Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.
At the simple end, in languages like Basic spaghetti code doesn't really differ that much from ordinary code; I do not think I could describe how "beautiful basic" would differ from "spaghetti basic" at all.
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me. :-//
-
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me. :-//
Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.
-
What do you use to *debug* PHP?
A very strong degausser on the storage media. That should teach it.
-
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me. :-//
Hungarian notation (https://en.wikipedia.org/wiki/Hungarian_notation) was invented by an actual Hungarian, Charles Simonyi (https://en.wikipedia.org/wiki/Charles_Simonyi), originally at Xerox PARC, later of Microsoft.
-
What do you use to *debug* PHP?
A very strong degausser on the storage media. That should teach it.
That's the problem with these newfangled SSDs. A degausser won't work. I suggest a flamethrower.
-
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me. :-//
Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.
I mentioned it, of course, because of Perl sigils ($ for scalars, @ for arrays, and % for hashes, & for subroutines, and * for typeglobs).
I thought about this for a while, and I think that the variable name represents the purpose of the variable for me in my mind at the abstract level, and having the type or form associated with the name hinders my ability to keep to the abstract level, and drags my feeble mind to the implementation level where I worry about such implementation details. Essentially, it makes it more difficult for me to bounce between complexity levels; me being not capable of encompassing huge complex structures at once at multiple different complexity levels... I'm certain that for others the sigils (and even Systems Hungarian type prefixes) help them in other ways, and see this as a stupid limitation, but this is my only mind I have to work with, and I just have to deal with its weaknesses the best I can.
What do you use to *debug* PHP?
A very strong degausser on the storage media. That should teach it.
What about PHP code that is rock solid? Granted, that stuff is basically write-only code.
"This is absolutely paranoid" is something I have heard from more than one person reading my PHP code. Several times, weeks or months after putting the code into production, a coworker has heard of a new Apache attack pattern, and emails me in panic, just to get a reply from me pointing out which part of my paranoid filter completely defuses that particular attack.
I used to giggle and cackle to myself with glee, when looking at Apache log files full of failed access attempts with some part of the query being ../../../../windows/system/cmd.exe, query strings containing %00, and similar shenanigans.. Like I said earlier, my PHP code sanitized even the CGI environment variables. Usually, I convert raw and urlencoded Western European non-ASCII letters (including ÅÄÖØÆåäöøæ) to their closest ASCII 'equivalents', then filter stuff like consecutive . and / out (eliminating any such consecutive pairs, ./ and /. altogether), and finally filter out all non-safe characters out. The end result is that no path shenanigans can pass through, no matter what you try.
But, it wasn't fun writing it in PHP, because PHP has overlapping orthogonal interfaces doing the exact same thing (both OO and non-OO imperative), and it was basically impossible to see how the language developers envisioned it being used properly. Especially during the efforts of making PHP easier for non-programmers to use "safely" –– things like magic quote support ––, one had to actively fight against idiocy, to make things secure. One could trust nothing, and really needed to be paranoid, or the PHP devs helpful attempts would bite one in the ass, hard. At least Python has PEPs, for what they're worth.
(And I cannot tell you how often I had to endure the question, "Are you sure this is necessary? Couldn't we just do simpler-but-less-secure-method?". Still makes me sad and depressed getting asked that, actually.)
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me. :-//
Hungarian notation (https://en.wikipedia.org/wiki/Hungarian_notation) was invented by an actual Hungarian, Charles Simonyi (https://en.wikipedia.org/wiki/Charles_Simonyi), originally at Xerox PARC, later of Microsoft.
By 'that', I was referring to my severe dislike, not to Systems Hungarian.
That is, I don't know where my severe dislike of Systems Hungarian stems from. I do know how and where Systems Hungarian came about.
Apologies for being unclear; me fail English :-[
-
What do you use to *debug* PHP?
A very strong degausser on the storage media. That should teach it.
That's the problem with these newfangled SSDs. A degausser won't work. I suggest a flamethrower.
I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.
https://youtu.be/5uxsFglz2ig
but I thought that a degausser would be more classique.
-
I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.
I don't think my "explosion containment pie dish" (per BigClive) could handle thermite, though. Darned stuff burns through everything.
Perhaps an industrial shredder?
-
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
That is true for any language, even. =)
Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.
That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.
SLOW DOWN!
It's a heck of a lot easier to read and understand a regular expression than to read and understand C or BASIC or COBOL code that recognises the same pattern -- let alone assembly language code.
-
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me. :-//
Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.
I mentioned it, of course, because of Perl sigils ($ for scalars, @ for arrays, and % for hashes, & for subroutines, and * for typeglobs).
That's not the type of the variable, it's the namespace.
It's just like "foo" vs "struct foo" in C. "foo" is from the namespace of runtime values, "struct foo" is from the namespace of types.
Or like the difference between "foo" and "(function foo)" in Common Lisp where there are different namespaces for variables and functions. This is mostly transparent because Lisp knows that in (a b c) "a" is in the function namespace while "b" and "c" are in the variables namespace, but from time to time you want to store a reference to a function in a variable or pass it as an argument, and then later you want to use the value in that variable as a function to call.
(defun square (x) (* x x))
(square 9)
=> 81
(set 'foo (function square))
(funcall foo (13))
=> 169
Perl just has a lot more namespaces than the other languages, and less ability to implicitly know which namespace you mean just from context.
Note that Perl *does* know implicitly that you want to access the value of the function namespace and call the function &foo when you just write foo(13), so you only have to write the & in the same kind of situation that you use (function foo) in Lisp.
I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.
-
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
That is true for any language, even. =)
Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.
That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.
I disagree, because modifying a complex regular expression is completely different to understanding one.
As an overly simplified example, consider the regular expression /ab*c/. This matches any substring starting with a, ending with c, and containing only zero or more b in between. Because of a change elsewhere, we now need to change this expression so that it matches those substrings, but also the ones that start with ac followed by zero or more d after, matching the longest matching substring of course. Do you modify the expression, or do you rewrite it?
By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.
SLOW DOWN!
That I do agree with.
Perhaps I chose the term, "write-only", poorly. I only now realize that it is typically used to refer to code that is too difficult to understand and is better just rewritten to achieve the same result. Here, I meant it in the sense that when the syntax is concise and efficient enough, even small changes are "better" (more reliably and in less time) implemented by rewriting the expression instead of modifying it.
Granted, finite state machines tend to be so complex that to maintain one, one usually relies on external documentation for it, describing the states and their relationships; so that modifying the code depends much more about understanding the state machine the code represents, and very little on understanding exactly how the code implements the state machine. (Basically, understanding just the states that are affected by the change is enough.)
For most regular expressions (excepting the monsters like the one that verifies valid email addresses) one can build the model in ones mind from the regular expression easier than one can build it from the corresponding C, BASIC, or COBOL code, yes.
All those are inferior to actually properly documenting the finite state machine properly in the first place –– even as the separate patterns that the regular expression can match, say using augmented Backus-Naur form as described in RFC 2234 (https://www.rfc-editor.org/rfc/rfc2234). Because most developers will have to read RFCs at some point, and aBNF is the most commonly used form in them, it makes for a suitable format in my opinion.
I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.
Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?
I am well aware of Perl general documentation (https://www.perl.org/docs.html) and perldoc.perl.org (https://perldoc.perl.org/), and very recently reread some of the tutorials to refresh my memory. I have been very clear that I do not consider my own hangups with Perl the fault of the language. >:(
-
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
That is true for any language, even. =)
Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.
That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.
I disagree, because modifying a complex regular expression is completely different to understanding one.
As an overly simplified example, consider the regular expression /ab*c/. This matches any substring starting with a, ending with c, and containing only zero or more b in between. Because of a change elsewhere, we now need to change this expression so that it matches those substrings, but also the ones that start with ac followed by zero or more d after, matching the longest matching substring of course. Do you modify the expression, or do you rewrite it?
Is there something wrong with inserting "|acd*" at the end (or "acd*|" at the beginning? Seems fairly straightforward, and the NDA->DFA conversion will factor out the common "a" for you.
If a and/or c are at all complex you can factor them out in very much the same way as in BNF.
For example ... oh, I don't know ...
if ($ARGV[0] =~
/^(?&fpconst)$
(?(DEFINE)
(?<osg>[-+]?) # optional sign
(?<int>\d++) # integer
(?<dec>\.(?&int)?) # decimal fraction
(?<fpconst>(?&osg)\ * ( (?&int)(?&dec)? | (?&dec) )(?: [eE](?&osg)(?&int) )?)
)/x
){
print "yes\n";
} else {
print "no\n";
}
$ perl isfp.pl 123
yes
$ perl isfp.pl 123e
no
$ perl isfp.pl 123e4
yes
$ perl isfp.pl 123.e4
yes
$ perl isfp.pl 123.34e4
yes
$ perl isfp.pl 123.
yes
By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.
Fair enough but as you yourself said, that's not what is usually meant by "write-only".
I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.
Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?
Nope, it's about me. I try not to be ambiguous about insulting someone, or do it by accident.
-
By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.
Fair enough but as you yourself said, that's not what is usually meant by "write-only".
Righty-o. I wonder what term I should use for this, because it is actually a situation I encounter relatively often (say, once a month at least).
I do unit test both the old form and the new form of whatever function or structure or thing is involved. I don't do rewrites because I'm not arsed to fully understand the existing code; I only do it when I do have a better form, and verify it indeed is better (using whatever definition of "better" is appropriate in each particular case).
Oh, and I do relatively often find out that the idea I had actually does not yield a better solution. When that happens, I document it, and use the original.
This is a large part of why I have done so many (at least a couple of thousand) "unit test cases" (mostly programming, some math): Theory is nice and good and useful, but practical reality rules.
I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.
Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?
Nope, it's about me. I try not to be ambiguous about insulting someone, or do it by accident.
Ah; thank you. Good to hear.
I do not do veiled insults at all, but I do often fail in English, and end up inadvertently offending people (like yourself, if you happen to remember). Online, it is difficult to tell.
I am rather sensitive about this in this topic, because I am the only one who openly admits that they dislike a specific programming language because of a purely personal, subjective reason, and not due to some rational reason. Those who have said they refuse to use Python because it uses whitespace indentation to denote code structures, have simply claimed they do so because "Python is stupid" and similar variants. To me, being honest in this way is not admitting a weakness, because those underlying reasons are what sway – and should sway – those without much experience reading this thread. Everyone has an opinion, but the important things are the reasons behind those opinions, because they are the only way to rationally evaluate the merits of each opinion. However, this kind of honesty is often taken as a sign of weakness, usually worthy of denigration.
I did jump the keyboard, though: if I had stopped to consider the author, I would have realized it was not intended as an insult. Apologies.
-
(https://www.eevblog.com/forum/chat/fun-for-nerds/?action=dlattach;attach=1390871;image)
That is why namespaces are good.
;D
-
I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.
I don't think my "explosion containment pie dish" (per BigClive) could handle thermite, though. Darned stuff burns through everything.
Perhaps an industrial shredder?
Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town. Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.
-
Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town. Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.
A hot torch is easier. Just burn the thin coating off the aluminium platter, and twist it into a pretzel. Assuming fume extraction is available, of course. Then the bit carrying parts literally do not exist anymore.
Actually, recovering data from a physically malformed platter is nigh impossible, so just taking out the platters and hammering or otherwise taking your frustration out on them a bit is more than enough.
Plus, the magnets are quite fun to play with, and when taken apart, the boards and spindle magnetics can be put in e-waste, and the cast aluminium parts in metal recycling.
-
Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town. Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.
A hot torch is easier. Just burn the thin coating off the aluminium platter, and twist it into a pretzel. Assuming fume extraction is available, of course. Then the bit carrying parts literally do not exist anymore.
Actually, recovering data from a physically malformed platter is nigh impossible, so just taking out the platters and hammering or otherwise taking your frustration out on them a bit is more than enough.
Plus, the magnets are quite fun to play with, and when taken apart, the boards and spindle magnetics can be put in e-waste, and the cast aluminium parts in metal recycling.
As always, these things depend on your "threat model", your value as a target and how much someone is prepared to pay to recover that data. I know people who have worked on networks of international importance, from domain registries to ISP/peering/telco networks ranging from "never heard of them" to household names who would be tempting targets both for criminals and three letter agencies. While lowly techies may not be of themselves particularly interesting, their credentials can get you places that people would pay big money to get to and at that point "nigh impossible" can change to "recoverable with enough money, a clean room, a tunnelling SEM and time". If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?
-
at that point "nigh impossible" can change to "recoverable with enough money, a clean room, a tunnelling SEM and time".
That "nigh impossible" was based on the physics of the situation, and not current technological capabilities.
Each platter is basically an aluminium disc with a suitable thin Magik Sauce coating. The coating exhibits one of the magnetoresistive effects: although it is a thin membrane or layer, at the atomic level it can be grouped into small cells with each cell having their own magnetic field.
(By measuring the exact magnetic field in each such cell using superconducting magnets in low temperatures, one can give a surprisingly reliable statistic on the possible states of this particular "bit". Each write affects a relatively constant change in the magnetic field, so "past data" can often be uncovered from the current magnetic field, by comparing the magnetic field strength and direction among all such cells on that particular platter. But, I'm just a physicist, and know of this in theory; the guys who design this stuff could describe it much better. In the "cost does not matter" world, they do have access to cryogenic cooling with amazingly sensitive and precise magnetic sensors using superconducting materials, and reading e.g. a platter cut in two dozen pieces but otherwise intact is not a problem, that much I do know.)
The potential energy involved in that magnetic field is small. Enough heat, and the increased motion of the atoms in the storage membrane will randomize the magnetic fields. Physically deforming the platter also randomizes the magnetic fields in the deformed region. (Chiefly, instead of somewhat clear cell boundaries, you get very soft transitions.) Trying to re-form the surface back to semi-planar just worsens it, so does delaminating the layer from the aluminium substrate, because the aluminium actually forms the base lattice that helps keep the magnetic cells in place.
However, I stand by my suggestion of using an simple, cheap acetylene/propane torch, and simply burn off the data layer completely. The atoms whose spins contained the data are then impossible to gather, much less put back together. Plus, it is fun. The fumes you get, however, can be quite, quite toxic (who knows exactly what they use as dopants here?). Hence, fume extraction and activated carbon filtering is kinda-sorta a must.
-
If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?
Exactly. The true professionals do not bother with your used hardware, they turn one of the workers instead. There is always someone greedy enough, in too much debt, or with secrets to hide. I suspect the higher ups are easier than the actual line workers to turn, though.
This is why 'wet work' (human-to-human) is so much more effective than technological monitoring.
-
If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?
I once happened to run tcpdump on the WiFi at a RIPE meeting. That was educational. Telnetting to the jumphost and THEN using SSH to log on to the core router does not help if I'm listening in on the first hop... :palm:
-
There seems to be a project to speed up CPython by a factor of x2 to x5 in the next few years.
https://github.com/faster-cpython (https://github.com/faster-cpython)
Presentation of Guido van Rossum (May 2021): https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf (https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf)
Edit:
https://faster-cpython.readthedocs.io/ (https://faster-cpython.readthedocs.io/)
https://www.theregister.com/2021/05/13/guido_van_rossum_cpython_3_11/ (https://www.theregister.com/2021/05/13/guido_van_rossum_cpython_3_11/)
-
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.
-
You appear to have an incorrect impression of Lisp.
-
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.
-
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.
-
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.
-
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.
-
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;
-
At this point, I cannot tell who is yanking whose yarn, or even whether yanking someones yarn is a saying. What next? :-/O
-
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.)
-
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 ++ -- += -= )
-
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.
-
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.
-
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?
-
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) ' 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) ' 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
-
"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!
-
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.
-
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).
-
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.
-
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
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]
-
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.
-
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
-
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.".
-
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. :popcorn:
-
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:
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.
-
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 (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
-
Snip
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.
Actually Tarzan did build (or actually hire someone to) him a zeppelin from unobtainium material similar to titanium he found from forbitten temple. Then he did fly in the pole of the earth with that ship, where he did find a hole to inside the earth where were a second world he and other did fly to explore.
Tldr; Read your Tarzan before making a poor examples. XD
-
if( (retval = do_thing()) == 3 )
{
do_things_with(retval);
}
so what does that do ?
do_thing() returns a number that gets compared to 3 , so that should yield a boolean that in turn gets stuffed in retval
the "if" clause only executes if retval is 'true'
So you are always calling "do_things_with" passing a boolean that is high.
assuming my analysis is right :why not simply write
if (dothing ==3) do_things_with(true);
what am i missing ? or what is not being explained ?
-edit-. crud missed the brackets. see what just happened ?
refactor that to
retval == do_dothing
if retval ==3 do_things_with (retval)
or even better ( since it only works if retval is 3 )
if do_thing ==3 do_things_with(3)
or even better
case x==dothing()
3: do_things_with (x)
endcase
As for the whole tarzan thing. i am talking programming languages. They can discriminate between assign and compare. There are languages that can do it ( the apparently hated basic can do it. PL/1 or PL/I can do it, other languages can do it too. )
it is not a "go to the store to buy an egg. if they have bread , bring two" problem .... two eggs if they have bread , one if they don't have bread / one egg and possibly 2 bread loaves.
For the occasional programmer these are annoying little details. i can't remember how many times i have been chasing a bug in a c program i wrote that turned out to be a =/== issue. or having to fix the missing ; or }. or having to remember when i need the {} , when i can drop them and where i need the ; and where not ( now i just put them whether required or not. )
Having a good ide that cleans up that stuff is extremely important for me. There is nothing more annoying to sit there waiting for a program to compile and after 5 minutes compilation aborts cause a ; is missing ...
i work differently. i want a language that matches my operating mode. interactive debugging. stop at error, let me examine/alter contents and code and tell it where to continue (or what to redo).
-
... and if the condition isn't == 3, but, say > 3, then your "replace-it-by-copypasted literal" strategy and "switch-case" strategy both break. In programming, the right question to ask is not "can I just make this work, with these exact values"; no, it's "what is the correct general pattern of doing this". Let the compiler work out the optimizations, let the compiler internally "copypaste" the literal "3". You as a programmer - communicate the intent.
Syntax isn't important. The important thing is to recognize what the correct underlying action is, and describe it with the language. In English, this could be: "If you have more than five bananas, give me all of your bananas except two which you can keep."
You can't describe this with a huge switch-case lookup table containing all possible numbers of bananas, or gazillion if-elses, either. You need to detect the pattern of checking the number of bananas, and using variables and arithmetic. Here, assignments and comparisons are both needed, are different operations, and they can be combined with checking. Both in English, and in C. You can of course add limitations; in English you can say "no sentences longer than 5 words". In BASIC you can say, no assignments inside IF clauses. If you forbid it, and everybody knows it's forbidden, then the compiler can assume the intent and is right 100% of the time.
But is this a good limitation?
The example I gave is very typical in C codebases and the reason is simple: it communicates the right intent - store value and act based on that value -, it removes copypasting variable names or values.
Short-circuiting && and || are similar. If you just know the rules, they are powerful communication tools.
To really inexperienced programmers, these may feel like obfuscations and tricks or "hacks", I understand that. But the solution, really, is in learning, not in limiting the tools.
You can always dumb down the language, and you end up with BASIC. BASIC is Turing complete, meaning it can implement any program C can. But so is Brainfuck.
Too "basic" languages make programs appear longer, slower to write, slower to read, harder to understand. Higher-level languages require more initial learning (more syntax, more rules...), but then allows doing more complex, more advanced programs without wasting time working around the limitations. And quite frankly, C is, by modern standards, quite primitive. If you limit its power in any way, trying to make it "easier" for complete beginners, it becomes pretty much unusable.
We don't need more beginner-friendly languages. We need beginners who are ready to invest some time in learning. Mistakes are OK. Arrogance is the problem.
I'm thinking about the effort spent in school, learning the grammatical rules of German (aus bei mit nach seit von zu, durich für gegen ohne um) and Swedish, without much use for either language because we communicate in English anyway. Compared to that, languages like C or Python are orders of magnitude easier to learn, even if you learn the whole standard by heart! Seeing how important programming is in modern societies, I'm surprised people want completely effortless learning, but are ready to spend years and years in learning human languages, even just for fun.
-
We don't need more beginner-friendly languages. We need beginners who are ready to invest some time in learning.
Absolutely.
-
.
-
Hi,
Can someone give me advice about what graphical tool to use in order to create GUIs in Python? I mean, I'm aware of Tk, wxPython, Qt and other frameworks, but what I'm looking for is a graphical tool where I design the appearance of the GUI I want to get and the tool generates the Python skeleton for it (using any of the previous Tk, wx...).
Some time ago I used Boa Constructor (that relied upon wxPython), but seems abandonware now.
Is there any (free, active, relying in some framework with near-to-native appearance) graphical tool for that?
Thanks & regards.
Maybe QtCreator, e.g. here (https://wiki.qt.io/Qt_for_Python_UiFiles) and here (https://stackoverflow.com/questions/24100602/developing-python-applications-in-qt-creator).
-
Short-circuiting && and || are similar. If you just know the rules, they are powerful communication tools.
To really inexperienced programmers, these may feel like obfuscations and tricks or "hacks", I understand that. But the solution, really, is in learning, not in limiting the tools.
If I'm not terribly wrong that mnemonic for crowbaring logic chains (for speed gain) is language specific. There is no such mnemonic in ie. relay programs. People tend to go religious about C(++) and it is kind of odd. The most disturbing part is that (internet) world is so biased almost as religion to C (..and derivatives) ...and it is not a new thing.
Also most of the programming languages are super simple to learn, C-lang does have a handfull of reserved words, few symbols a few clouse rules, a few data IO rules and a few prImitive data types. What actually is the hard part is the standard libraries and especially beyond std.libs., which many times do not follow a common logic between each other (again not language specific). Also in some languages like C the toolchains are more than pita. Ie. with Python what GUI toolkit to use.
Then there is the whole systems knowledge layer, this is what professional PC / Osystem programmers seems to take as granded as part of language (all the POSIX etc. talk). While actually this doesn't relate logically to programming language at all (outside maybe assembly), it is part of scope and systems knowledge (OS vs baremetal for example). Also the so much toted memory management and heap talk do drop to this systems category more or less (ie. Stack based CPUs).
Also programming language independent of hardware or implementation (as a common way to describe intented actions and information) there is major difference to natural languages, while natural language have one and only one target, other human, the programming language do have always two targets machine and human. This is one of many reasons why the programming languages do not resemble an essay of natural language and that is also reason almost none is writing assembly and there is still search for the sweetspot between natural and machine language.
Then there is whole world of hybrid programming languages for machines ie. graphic languages (compare to full natural languages ie. which blind or deaf communities use), which can be much much more expressive than ie. C, ie. for complex logic networks.
If one knows only C all problems do look memory management. ...I took liberty to this custom proverb, since also hammers come in multitude of shapes and which many are used to something else than nails.
Just my .50cents, who do not agree is free to do so.
-
If one knows only C all problems do look memory management.
Not for those of us who use the Boehm GC library in our C programs :-)
Also, I've never seen anyone more obsessed with memory management than Rust programmers.
-
Also, I've never seen anyone more obsessed with memory management than Rust programmers.
To be fair, that's kind of the point of Rust.
-
Also, I've never seen anyone more obsessed with memory management than Rust programmers.
To be fair, that's kind of the point of Rust.
Yes. Peculiar kind of self-flagellation.
Modern C++ is just about as bad with unique_ptr and shared_ptr littering the code everywhere.
There are times to think about memory management, and there are times to think about what you're actually trying to achieve, and they shouldn't be intertwined everywhere like a vine choking an apple tree.
-
I write mostly C and spend maybe 3.14% of time thinking about memory management. Sure, it's a thing in C, but if it seems overwhelming, you are likely doing something wrong.
Of course there are some very specific challenging edge cases where memory management needs more thought than that, but then again, for those a pre-engineered one-size-fits-all solution wouldn't be suitable. With power and control, comes capability.
With Python, this is all uninteresting because Python is all about running code written by others in C, so memory management is also taken care of, in C. But as always with code written by others, you are limited to the functionality of that code.
-
With Python, this is all uninteresting because Python is all about running code written by others in C, so memory management is also taken care of, in C. But as always with code written by others, you are limited to the functionality of that code.
That is so when you use numpy or other similar package.
But this is not the case in web applications or other similar ones, which make intensive use of Python code.
-
With Python, this is all uninteresting because Python is all about running code written by others in C, so memory management is also taken care of, in C. But as always with code written by others, you are limited to the functionality of that code.
That is so when you use numpy or other similar package.
But this is not the case in web applications or other similar ones, which make intensive use of Python code.
Which then is interpreted, by code written in C...
-
Which then is interpreted, by code written in C...
Yes, the key here is that the Python part needs to be as high-level as possible; in other words, utilizing the "C parts" as much as possible.
This is wise; it's co-operation, some bright-minded people made good libraries, and you can leverage this work in higher level language. It's like using a switch mode regulator IC, say one with internal compensation and all. You don't need to know how it works, just instantiate the chip from Digikey, copy the datasheet example and modify whenever needed.
This isn't usually a problem, until one day you need something new and special that can't be combined solely out of large building blocks. Sometimes people try to build large programs "from scratch" in Python, i.e., something with completely home-made algorithms, IO, etc. Poor performance may become as a real surprise to those who have read "Python is not slow" articles, benchmarking typical code relying on libraries as much as possible.
-
C is fast, but Python is not slow. Neither is PHP.
This forum is written in PHP and web speed matters. Why hasn't the forum been programmed in c?
Because in this case what matters is the speed and flexibility of development, and interpreted languages win in that field.
-
Don't really need to eek out latency and CPU savings for the average php forum or WordPress website. It's not a relevant cost.
Though I think say reddit could have saved a lot of money going with Go or Java in reduced server cost, instead of using Python. Maybe even C# though it would reduce the pool of developers with many years of relevant experience, which would be a huge problem for HR.
-
C is fast, but Python is not slow. Neither is PHP.
This forum is written in PHP and web speed matters. Why hasn't the forum been programmed in c?
Because in this case what matters is the speed and flexibility of development, and interpreted languages win in that field.
... as long as throwing more CPU power and RAM at Python/PHP/etc is cheaper than writing code in C. However, IT's CO2 footprint is becoming a topic. ;)
-
... as long as throwing more CPU power and RAM at Python/PHP/etc is cheaper than writing code in C. However, IT's CO2 footprint is becoming a topic. ;)
That's why it seems that Python is trying to be faster in the next versions, but I haven't been able to find much news about that.
Edit:
https://www.infoworld.com/article/3618691/pythons-creators-unveil-speedup-plans-for-python.html (https://www.infoworld.com/article/3618691/pythons-creators-unveil-speedup-plans-for-python.html)
https://github.com/markshannon/faster-cpython/blob/master/plan.md (https://github.com/markshannon/faster-cpython/blob/master/plan.md)
-
C is fast, but Python is not slow.
Yes, yes it is.
#include <stdio.h>
int main (int argc, char const *argv[])
{
int x;
printf ("starting\n");
for (int i = 0; i < 1000000; i++)
x = x + 1;
printf ("stopping\n");
return 0;
}
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
print ("starting");
x = 1
for i in range(1000000):
x = x + 1
print ("stopping");
We run both twice to ensure that they are on an even footing, not needing to service page faults for runtime binaries and the like (this will be to Python's advantage, it has a large runtime to load before it can do anything).
cerebus@shu:~/Desktop$ gcc -O0 -o Loop Loop.c <- note optimisation turned off
cerebus@shu:~/Desktop$ ./Loop
starting
stopping
cerebus@shu:~/Desktop$ time ./Loop
starting
stopping
real 0m0.007s
user 0m0.004s
sys 0m0.002s
cerebus@shu:~/Desktop$ ./Loop.py
starting
stopping
cerebus@shu:~/Desktop$ time ./Loop.py
starting
stopping
real 0m0.130s
user 0m0.113s
sys 0m0.012s
cerebus@shu:~/Desktop$
C - 4ms, Python - 113ms. Python manages a mere 3.5% of the performance of C for the most trivial task possible.
One can make many claims for Python but "not slow" is not one of them. I have nothing against Python*, when used appropriately. I've made plenty of money out of writing Python for other people and would do so again if Python is appropriate for the task at hand. I've used Python to hack out SCPI control and graphing programs for my own electronics messing about and will do so again.
I'm fine with using Python when it's the right tool to choose. What I'm not fine with is making stupid claims like "not slow" just to support a fanboy position. Professionals choose the appropriate tool for the job at hand. If one needs speed one does not choose Python. Just because a lot of bodgers have put screws in with a hammer is not an excuse to not use a screwdriver. Similarly just because a bunch of people who should have known better have done something in a particular programming language where another would have been more appropriate is not an excuse to repeat the mistake.
Almost invariably the people who get hung up on advocating some particular programming language for every task under the sun, and make excuses (or simply deny) its faults only know that language. When all you have is a hammer, everything looks like a nail.
*Except for the dumb "space is significant" thing. That sin can never be forgiven.
-
I reckon you might get around 5% of the performance of C if you were to stick the Python code inside a function rather than execute globally. Given that present day hardware is about four orders of magnitude faster than what we used throw at problems, some find Python is not all that slow.
-
C - 4ms, Python - 113ms. Python manages a mere 3.5% of the performance of C for the most trivial task possible.
113 milliseconds is not slow. At least for me.
Edit:
I also don't consider slow the 10 seconds it can take for the Python-Sphinx (https://www.sphinx-doc.org/en/master/) code to generate my web page with the changes introduced during half an hour of typing.
With a program written in C, the web generation might take 0.5 seconds instead of 10 seconds, but who cares? 10 seconds is not slow for me.
Also I don't know of any popular static website generator written in C, as flexible as Sphinx.
-
C - 4ms, Python - 113ms. Python manages a mere 3.5% of the performance of C for the most trivial task possible.
113 milliseconds is not slow. At least for me.
Edit:
I also don't consider slow the 10 seconds it can take for the Python-Sphinx (https://www.sphinx-doc.org/en/master/) code to generate my web page with the changes introduced during half an hour of typing.
With a program written in C, the web generation might take 0.5 seconds instead of 10 seconds, but who cares? 10 seconds is not slow for me.
Also I don't know of any popular static website generator written in C, as flexible as Sphinx.
This here above is the fanboy speaking.
What matters not to you matters a lot to someone else. And, yes, I've spent much more than 113ms to write this (OTOH it took barely 4ms to realise you missed the point, by 1.6 km) so 113ms might be not much. And for a program you spend 2 minutes writing and 113ms executing, ONCE, it really is nothing. If OTOH you spend 20 minutes writing it in C, those 4ms can be a blessing because you might need to run that bit of code ${BIGNUM} * 106 times. And Cerebus wrote all that. And you ignored it. So who am I fooling, thinking I'll get through to you?
Also, the "spaces are significant" is a mortal sin. 1000 times over. (Præterea censeo, Carthaginem esse delendam.)
-
C - 4ms, Python - 113ms. Python manages a mere 3.5% of the performance of C for the most trivial task possible.
113 milliseconds is not slow. At least for me.
Edit:
I also don't consider slow the 10 seconds it can take for the Python-Sphinx (https://www.sphinx-doc.org/en/master/) code to generate my web page with the changes introduced during half an hour of typing.
With a program written in C, the web generation might take 0.5 seconds instead of 10 seconds, but who cares? 10 seconds is not slow for me.
Also I don't know of any popular static website generator written in C, as flexible as Sphinx.
We can take it them that you drive a car that does gallons per mile rather than miles per gallon then can we? The 113 milliseconds is just the simplest, most trivial demonstration of the wastefulness and inefficiency of Python, it's not meant to be a metric of how long a user is sitting waiting for as you know full well. That one can get more than 20 times as much done in the same time in C (or Rust* or Swift or Go) as one can in Python, or get the same amount done for more than 20 times less use of resources, is most definitely an indication that Python is slow. Just because you throw computing resources at it to make it tolerable does not stop it from being intrinsically slow.
*
fn main() {
let mut x = 0;
println!("starting");
for _i in 0..999999
{
x = x + 1;
}
println!("stopping");
}
cerebus@shu:~/Desktop/Rust_temp/loop$ time ./target/release/loop
starting
stopping
real 0m0.261s
user 0m0.001s
sys 0m0.002s
I suspect Rust is being 'clever', the debug version takes 30ms.
-
So all high speed trains are slow because a hypersonic rocket is 20 times faster than a high speed train?
That reasoning is a fallacy. High-speed trains travel 20 times slower than a rocket, but that doesn't make them slow, they're still very fast.
Therefore I still argue that Python is not slow. C code can be 20 times faster, but that just means that C is very fast, not that Python is slow.
-
There's a huge cost difference between running an online shop with one server or 20. And slow online shops also lose revenue.
-
Yes, but eCommerce platforms still use interpreted languages like PHP.
In most cases, a single server is enough to provide service quickly.
This forum is a user intensive use case and works on PHP, a "slow" interpreted language, which is not so slow after all.
3094 Guests and 303 Users at this time!
-
So all high speed trains are slow because a hypersonic rocket is 20 times faster than a high speed train?
That reasoning is a fallacy. High-speed trains travel 20 times slower than a rocket, but that doesn't make them slow, they're still very fast.
Therefore I still argue that Python is not slow. C code can be 20 times faster, but that just means that C is very fast, not that Python is slow.
So your thesis is that a computer that runs like someone has poured treacle in it is not slow, it is actually fast, and we should refine our notions of fast on any particular piece of hardware as the speed that Python runs at and anything capable of running at something near the speed of the hardware as really, really fast. OK, good luck with that.
-
So all high speed trains are slow because a hypersonic rocket is 20 times faster than a high speed train?
That reasoning is a fallacy. High-speed trains travel 20 times slower than a rocket, but that doesn't make them slow, they're still very fast.
Therefore I still argue that Python is not slow. C code can be 20 times faster, but that just means that C is very fast, not that Python is slow.
So your thesis is that a computer that runs like someone has poured treacle in it is not slow, it is actually fast, and we should refine our notions of fast on any particular piece of hardware as the speed that Python runs at and anything capable of running at something near the speed of the hardware as really, really fast. OK, good luck with that.
How much time was to compile the C code?
-
So all high speed trains are slow because a hypersonic rocket is 20 times faster than a high speed train?
That reasoning is a fallacy. High-speed trains travel 20 times slower than a rocket, but that doesn't make them slow, they're still very fast.
Therefore I still argue that Python is not slow. C code can be 20 times faster, but that just means that C is very fast, not that Python is slow.
So your thesis is that a computer that runs like someone has poured treacle in it is not slow, it is actually fast, and we should refine our notions of fast on any particular piece of hardware as the speed that Python runs at and anything capable of running at something near the speed of the hardware as really, really fast. OK, good luck with that.
How much time was to compile the C code?
cerebus@shu:~/Desktop$ time gcc -O0 -o Loop Loop.c
real 0m0.086s
user 0m0.043s
sys 0m0.034s
-
#include <stdio.h>
int main (int argc, char const *argv[])
{
int x;
printf ("starting\n");
for (int i = 0; i < 1000000; i++)
x = x + 1;
printf ("stopping\n");
return 0;
}
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
print ("starting");
x = 1
for i in range(1000000):
x = x + 1
print ("stopping");
We run both twice to ensure that they are on an even footing, not needing to service page faults for runtime binaries and the like (this will be to Python's advantage, it has a large runtime to load before it can do anything).
(...)
C - 4ms, Python - 113ms. Python manages a mere 3.5% of the performance of C for the most trivial task possible.
That C is a lot faster than Python comes as no surprise (except maybe for the most extreme fanboys)? But what may bite them even more is that... even Lua is much faster than Python:
Test.lua
function Test()
print("starting")
x = 1
for i = 1, 1000000 do
x = x + 1
end
print("stopping")
end
Test()
(x is a global variable here for Lua - and that's less efficient than using local variables...)
time lua Test.lua
starting
stopping
real 0m0,021s
user 0m0,020s
sys 0m0,001s
If I declare x as a local variable:
starting
stopping
real 0m0,009s
user 0m0,008s
sys 0m0,000s
::)
-
time lua Test.lua
starting
stopping
real 0m0,021s
user 0m0,020s
sys 0m0,001s
If I declare x as a local variable:
starting
stopping
real 0m0,009s
user 0m0,008s
sys 0m0,000s
::)
Ah, but you could have used one of them specially fast computers rather than the steam powered 2018 i7-8850H driven MacBook that I was using. ;)
I like it because it's a "Coffee Lake". That's got to be a proper programmer's processor, right?
-
The example I gave was run on a headless Linux box which is not my main workstation, and fine but not a beast by any means.
For a fair comparison though, I ran the Python code on the same machine:
starting
stopping
real 0m0,141s
user 0m0,109s
sys 0m0,012s
-
Youtube works with Python. Not lua, nor PHP, much less in C.
Goggle believes that Python is fast enough to support that language.
-
Youtube works with Python.
Just |O.
This is exactly what Python fanboyism is all about. If something, such as Youtube, contains a line of Python, the whole thing "runs on Python".
Do you really think your Youtube experience is enabled by Python interpreter going through gazillion of Python code lines to implement the whole of Youtube?
Exactly the same as "Python is the AI language", when you configure a few input vectors on a python script and call a complete NN implementation (which is actually made in C, C++, assembly, OpenCL, CUDA, VHDL, Verilog, whatever combination thereof).
Python's actual role is to instantiate large modules, libraries. This avoids performance limitations. And also avoids working with the language in low level, when the language really isn't tailored for low level stuff. Try to learn this, and you'll sound less :palm:.
I know Python fanboys hate Python being called just a scripting language, but there's a grain of truth here. No one would implement a PCB CAD packege in Matlab/Octave code. Python is actually very close to that. It's an "intermediate" language which glues together pre-engineered modules. Highly useful, but not a full application development language. Yet a very good replacement for many simple use cases which would have been BASH scripts or written in BASIC.
Cerebus' simple demonstration is exactly to show you can't write responsive software low-level in Python. You are not even supposed to, no one in their right mind would do that. It's surprising some people apparently need that demonstrated and still don't get the point. You can read pretty much the same from every half-decent Python tutorial: let the libraries do the work. No, 100ms is not acceptable if it is, for example, a response time to a keyboard keypress while writing. And sluggish text editing fields on web apps is a real thing today.
But if you want to really know how Youtube works, there is quite a bit of learning involved. It's a huge infrastructure to make the cat video appear on your screen, and at least 90% of it is written in C, by very knowledgeable people, over many decades. The whole Internet works almost solely based on Unix/POSIX/C, like it or not.
This is, BTW, also why "Python becomes the most popular language". Also, if you count people who build cars, and people who drive cars, you will see driving cars is way more popular than building them. Yet, if you claim that you driving a car is the same thing as you building one, this is where you go wrong. Your experience is completely enabled by the work of others. Which is all good, enjoy it.
-
I'm kinda repeating what Siwastaja wrote above, but I think it is worth repeating.
Youtube works with Python. Not lua, nor PHP, much less in C.
Goggle believes that Python is fast enough to support that language.
You cannot infer qualitative statements from popularity, other than popularity.
I do bet Youtube/Alphabet uses Python for the same reason I do: it is good enough for the business and glue logic that the majority of their developers produce.
Anything critical, a very small but very good group of developers will implement in C optimized for their hardware architectures.
It also works well as a focusing mechanism. They employ a lot of mathematically-oriented data scientists. Let them develop and test their algorithms in some very high-level language. Then, when it works, have them document the algorithm (something like an annotated peer-reviewed article; I have no idea what they actually use – I'm just describing what I would do). Then, let them work on the next algorithm. Have that small dedicated team turn the proof-of-concept Python idea and algorithm description into a C library, with a native Python interface. You save three ways: cheaper mathematicians (by not being limited to the ones that can do both math and program), cheaper key developers (by not being limited to the ones that can also do math), easier management (by pulling the plug if the algorithm developer cannot even demonstrate it in Python in a reasonable timeframe; thus limiting sunken costs per idea).
Really, Python is simply very, very easy to interface to native libraries written in C; easier than any other scripting language I know. It also has a gentle learning curve compared to e.g. Perl, similar to say PHP (but without the confusing dichotomies PHP has, like whether it is an OO or non-OO scripting language). This makes it a very good candidate for this kind of use cases.
(To repeat, I use Python to implement user interfaces using e.g. Qt, with all the heavy computation and work done in native compiled C code. This lets even end users tweak the user interface, without requiring any kind of development environment, while allowing me or the vendor keep the proprietary stuff in the binary-only libraries.
On web servers, the Python code does relatively little processing; most of it is business logic, and connecting data sources to templating libraries and such. For example, the code I use for securing/fixing URLs before they're mapped to physical or virtual filesystem paths, uses regular expressions – which obviously use a very efficient native regular expression engine, and is not implemented in high-level Python, and is therefore quite efficient. I do take care of documenting well what the regular expressions need to achieve and why.)
Edit: The reason I use plain pure C and not Python in the PulseAudio Volume Meter (https://www.eevblog.com/forum/programming/pulseaudio-volume-meter-would-like-to-add-vu-ticks/) (in a nearby thread here), is that there just isn't enough glue logic there to make it useful to have a Python-based UI. The actual interface to draw the VU bars (or however you want to visualize it) in C is a simple Gtk-Cairo one, which is very easy to tweak (if correctly modularized, i.e. the cranky bits like maxima decay done elsewhere), from just an example by even a beginner in C. There just isn't any use or need for Python there. It would just unnecessarily waste CPU power, without anything useful in return.
-
I do not deny that, it seems to me that you have misunderstood me. I have developed applications in other languages (Javascript, Java, C, ladder, VisualBasic, assembler, etc)
And each one is valid for its field of application.
When using Python, heavy use is made of libraries for low-level work, but program logic is more effectively developed in high level Python.
Pareto's law says that 20% of the code will take 80% of the execution time and that code is better off written in C, but high level program logic code is much better off written in Python.
Many of you sound like C fanboys and don't seem to understand why Python is so popular and widely used. It's not just a fad, it's widely used for good performance reasons. Execution speed is no longer the only important variable. At least not with current hardware. The speed and ease of software development is more important.
Edit: I agree with Nominal Animal
-
Except that 20% of the code won't be in C and 80% in Python, in a given project. It just doesn't work that way. The "plumbing" takes a lot of work, while successful high-level code does seemingly a lot with small number of LoC, that's the whole point. If it's taking 80% of the code, then you are doing something seriously wrong.
You might be surprised how many C code lines is actually involved when you write a 100-LoC Python piece. It's easily in millions. Not 80-20.
It's just that most of that plumbing is hidden from you.
A very simple project might be Python alone, or a project which seemingly does a lot, but the work is done by libraries.
Any complex piece of software (PCB EDA or Youtube), and the percentage of Python falls towards zero, and it should be this way. Use Python where it shines. Number of LoC is small exactly because it is quick and easy to write as you say!
-
... Any complex piece of software (PCB EDA or Youtube), and the percentage of Python falls towards zero, and it should be this way. Use Python where it shines. Number of LoC is small exactly because it is quick and easy to write as you say!
I am just trying to unpack that last thought. Wouldn't it make more sense to write more LOC in the language that is quick and easy to write, and less in one the one that is more tedious? The opposite tastes of technical masochism. There must be other reason(s) that support your argument, for example, exploiting existing, well tested code that predates the popularity of Python.
-
... Any complex piece of software (PCB EDA or Youtube), and the percentage of Python falls towards zero, and it should be this way. Use Python where it shines. Number of LoC is small exactly because it is quick and easy to write as you say!
I am just trying to unpack that last thought. Wouldn't it make more sense to write more LOC in the language that is quick and easy to write, and less in one the one that is more tedious? The opposite tastes of technical masochism. There must be other reason(s) that support your argument, for example, exploiting existing, well tested code that predates the popularity of Python.
No, it's the opposite way:
Complex low-level interactions can only be written in low-level languages, and they end up complex, because the actual thing they are dealing with, is complex. Someone's got to flip those bits!
Think about all the details that go in modern video compression, for example. They need to deal with every pixel, and gigabytes of datastreams. And then do the same to draw these pixels on screen.
Thanks to all that complexity hidden away, now the high-level implementation can use a very high-level language, and it ends up doing a lot using just a few lines of code visible, in that high-level language: videoPlayer.load("videofile")
It's not masochism, it's the reality. Trying to do the opposite, write complex low-level implementations in Python, is not only actual masochism, it also just does not work, not only because the language lacks the low level constructs, but also because of two-three orders of magnitude of performance penalty.
The key to understand this is that languages are only tools, they do not define the problems. The actual problems are what they are, they are layered (i.e., someone has to manufacture the electric drill, but you don't need to do that in order to use the drill to manufacture a coffee table), sometimes complex, sometimes easy, and easy languages are picked to solve easy problems!
-
... Any complex piece of software (PCB EDA or Youtube), and the percentage of Python falls towards zero, and it should be this way. Use Python where it shines. Number of LoC is small exactly because it is quick and easy to write as you say!
I am just trying to unpack that last thought. Wouldn't it make more sense to write more LOC in the language that is quick and easy to write, and less in one the one that is more tedious? The opposite tastes of technical masochism. There must be other reason(s) that support your argument, for example, exploiting existing, well tested code that predates the popularity of Python.
There is no technical reason for a language that is quick and easy to write code in to have to run slowly.
Examples of languages that are both productive to write in, and also run very nearly as fast as C, include Common Lisp, Dylan, and Julia. Oh, and these days, Javascript.
-
Yes, but eCommerce platforms still use interpreted languages like PHP.
In most cases, a single server is enough to provide service quickly.
I'd call that wishful thinking. I see so many small and large online shops with discouraging response times - it sucks. Web 2.0 is driven by scripting languages, add tracking and tons of bloat, and it moves like molasses. Even with FTTH you only get WorldWideWait. It seems that users have forgotten how fast websites can be, even with dynamic content.
This forum is a user intensive use case and works on PHP, a "slow" interpreted language, which is not so slow after all.
3094 Guests and 303 Users at this time!
I bet most of the 3k+ users would love it when this forum would have a 20 times lower response time. The whole issue is about scaling. A single user wouldn't complain about 200ms vs. 10ms. But with many users at the same time the 200ms become 2s or more. So you have to find a compromise between how many users a server can serve with an acceptable response time and the cost of running that server (while hopefully making some money). Ten times more users would be a significant benefit. What is less expensive for you? Running 20 servers with fiddleware or running two servers (one for resiliency) with optimized software? Or maybe you want to run 10 servers with optimized software and outperform your competitors by an order of magnitude?
-
Sure, most of the 3k+ users would love it when this forum would have a 20 times lower response time.
But, after all, this forum is based on SMF, written in PHP. And there is no news that David plans to switch to another faster platform.
Edit: And note that for me there are no speed problems in the forum.
-
I did quickly slab together that 'for loop' thing, this time with GUI in freepascal with LCL, got something like 16ms for 5M iterations inside IDE and and all the debug data with this really poor web-book laptop.
[attach=1]
Anyhow, I do like Python, but not for speed.
-
As N. Animal repeatedly says, popularity is not proof of anything else than popularity.
Pretty much everybody agrees that PHP is pure horror and nothing else. Yet is is and stays popular. And it seems to "work". Many horrific contraptions "work", it's not surprising.
You need to look far into history of things and put it all in perspective, including many non-technical reasons, to see why PHP, for example, is popular.
I still remember the time the PHP came, the selling argument was the ease of getting started. You just wrote some simplistic code, variables from the URL came automatically into variables in your code, and just upload the php file on the server and access it! It got the job done.
But just getting the job done is the wrong metric. It needs to be done right, too. Like you should not coat still wet concrete with vinyl flooring as it will cause massive chemical emission issues after a few years.
PHP is a prime example what happens when developers use "ease of getting started" as the most important metric. It makes me feel sad how people still use this argument when it comes to STM32Cube for example, or whatever. Don't do this to yourself. It hurts in the long run. Ease of getting started is important in small hobby projects, but its importance gradually falls off as the level of seriousness goes up.
PHP maybe felt good at first, but it has since caused unimaginable amount of human suffering and misery, and it still does that. But this is all hidden from people who just use software written in PHP. Those who need to maintain it suffer PTSD. And those who suffer from stolen personal data as a result of gaping security holes, are actual victims, too.
Luckily, Python causes much less pain than PHP.
-
Meh, most of the misery "caused" by PHP was actually caused by SQL. But plaintext API's with escape sequences are Unix so beyond criticism.
-
Meh, most of the misery "caused" by PHP was actually caused by SQL. But plaintext API's with escape sequences are Unix so beyond criticism.
?
No, most of the misery caused by PHP was the tool (the PHP interpreter) trying to do the developers' work for them, and guess when escape sequences were needed and when not, and do it automagically (magic quotes (https://en.wikipedia.org/wiki/Magic_quotes)).
I also do not understand the claim about plaintext Application Programming Interfaces. Plain text is traditionally used in two ways in Unix: for configuration data (as opposed to binary registries or databases), and as the lowest common denominator for interprocess communication.
While tools like the command-line sqlite3 interpreter do use escape sequences, none of the API DB libraries have had such limitations. Even if you were to use the command-line interpreter to access a database, a sane approach would be to do any escaping required at that interface layer. Exposing transport details to upper layers is definitely not Unix.
In other words, there is NOTHING Unix about PHP using a pure text interface to databases. It was just the simplest way the PHP developers could implement it. They knew that passing variables separately would have been better and safer; it just wasn't what they wanted. And that makes the misery caused PHP's own damn fault.
-
And of course if we are pedantic, note the difference between the PHP language, its built-in libraries, and the whole PHP framework including server configurations.
The language specification itself is crappy, too, many historical layers of poor design, different styles of naming conventions etc. But that's manageable. It's not that C's standard library is logical or safe, either. (Python does libraries better, that's why it can be used at truly high level.)
When you combine the crappy base PHP language, varieties of server configurations which make the same piece of code perform differently, the handy "register_globals" thing and magic quotes enabled (these are history, now, of course), and shoddy SQL practices, this all forms the well-known disaster.
Many people, me included, just call all that "PHP" short-hand. Actual use of PHP the language is more of a red flag, than directly responsible for all the horror we attach to the name.
-
Magic quotes is actually a very relevant example of the "don't reinvent the wheel!!" discussion in the Microcontrollers subforum.
The whole point is, security is hard, security is complex, so you don't want to roll your own implementation, right?
An existing implementation must be good, right?
"help [prevent] code written by beginners from being dangerous" was the specified rationale. Sounds right? Anybody who does not use Magic quotes and rolls their own instead must be an idiot, right?
But the history shows what really happened.
Never blindly trust work by others, especially if the track record is poor.
-
It seems that criticizing is easier than explaining the reasons why things work.
It is also more exciting and more satisfying to criticize something than to try to explain reality.
Now PHP has had its moment of criticism.
I'm not going to be the one to support the use of PHP, because I don't think it's a good language.
But, after all, PHP is still used in more than 80% of dynamic websites. That is a fact and it can be criticized or it can be explained by the benefits of interpreted languages, which are real, despite their slower speed compared with compiled ones.
Edit: PHP popularity has dropped below 80% of websites.
https://en.wikipedia.org/wiki/PHP#Popularity_and_usage_statistics
https://w3techs.com/technologies/details/pl-php
-
When you combine the crappy base PHP language, varieties of server configurations which make the same piece of code perform differently, the handy "register_globals" thing and magic quotes enabled (these are history, now, of course), and shoddy SQL practices, this all forms the well-known disaster.
Many people, me included, just call all that "PHP" short-hand. Actual use of PHP the language is more of a red flag, than directly responsible for all the horror we attach to the name.
Yep, agreed. PHP is one of the languages that if one wants to write a security-sensitive tool to do something, you need to make sure the language/environment (interpreter, libraries, and configuration combined) is not and does not do anything stupid: development in PHP is basically fighting against PHP, instead of working with PHP, using the shorthand Siwastaja described.
Contrast that to Python. Not any language features, but the entire environment, and things like the Python PEP index (https://www.python.org/dev/peps/). Just by reading the PEPs that are relevant to whatever one is working on in Python, you can delve deep into the developers mind as to how they intended that sort of expressions to be done in Python. This is useful. Take a minute to read through PEP 572 -- Assignment Expressions (https://www.python.org/dev/peps/pep-0572/), and you immediately learn what kinds of patterns cause unnecessary slowdown in Python, and how to write better Python code. Or, if you are writing a Python interface, and wondering how to add type hints, read PEP 484 -- Type Hints (https://www.python.org/dev/peps/pep-0484/), and you'll not only understand how, but also why.
One reason Dylan and Julia are not that widely used among the Linux community –– that is, 'used' in the sense as in 'implementing tools or applications' –– is that they are not packaged for Linux distributions, unlike e.g. Rust. You might say that the binary installers (and the sources for the 'open source zealots') are sufficient, but they aren't as, uh, effortless, as native packages. This effortless-ness is a key part in the popularity of the language. (Note: I am not saying this is a good or a bad thing. I am only trying to describe how things happen.) In my own experience, across say three decades, it looks like this effortlessness (or whatever you want to call the combined ease of use with minimal risk and high availability of reliable information) is much bigger factor in the popularity than technical quality is.
Circling back to the topic of this thread, you could summarize my own opinion that 1) Python is sufficiently effortless (in the abovementioned sense) to use in many environments to make it a valid easy choice, with 2) lacking any show-stopper flaws like in PHP (at least in the past had), which makes it both useful and popular. (This is in my use cases and in my opinion based on using Python in actual real-world utilities and applications; others opinions, and my own, will vary as times and needs change.)
It is not Python is particularly good; it is more that it is not so bad that one needs, or has a reason to find, something/anything better. It is sufficient for the task.
If someone argues some other scripting language over Python, any counterarguments I might have would necessarily revolve around one or both of the above two points. The moment something that fulfills both points at least as well, I'm very likely to switch myself.
All that said, it is interesting to see how different other peoples' metrics/measuring sticks are when comparing programming languages.
(That said, I definitely have completely different ones wrt. compiled languages and scripting languages, because I use them for very different use cases.)
-
People were still screwing up SQL input sanitation in every language used on the Web at the time. PHP wasn't special, just popular.
Sometimes security is hard, sometimes unquestionable traditions made it hard. C, null terminated strings and escape sequences in general outside of corruption resistant transmission protocols should have been ditched decades ago for sensitive code facing untrusted inputs. It would have prevented far more misery than PHP ever caused.
All strings should have had length, all operators should have been coded separately from data/text strings and the editors should have just color coded it and hidden and handled the minutia. Plain text was a mistake (for HTML, XML etc too).
-
It seems that criticizing is easier than explaining the reasons why things work.
It is also more exciting and more satisfying to criticize something than to try to explain reality.
Now PHP has had its moment of criticism.
I'm not going to be the one to support the use of PHP, because I don't think it's a good language.
But, after all, PHP is still used in more than 80% of dynamic websites.
You keep falling into that fallacy that popularity proves anything else than popularity. Or rather, I don't understand what your point is. You are agreeing that PHP sucks. We both also know how popular it is. So?
In the Real World, it's completely normal that things just happen. The reasons can be historically interesting, but hugely complicated, and often totally non-technical.
People have become rich by being in the right place at the right time. Or won in lottery. And yes, they prefer to write the history in such a way proving they are business geniuses, or whatever.
PHP is popular because PHP is popular. It's as simple as that. It's called traction. Why I say such an obvious thing? Because hear this out: if PHP didn't exist in the first place, we would just have something else, instead, similarly popular. That makes PHP, per se, in itself, totally irrelevant! And chances are high the alternative would work better. It's of course possible it would be even worse, but there are physical limits to that. If something does not get the job done at all, then it won't stay popular.
But it isn't always this way. If something is truly well designed and well performing, and it also happens to get the necessary traction, it will shape the world into a much better place than if we have to work around crappy solutions. PHP gets the job done, but that is literally the minimum base level, and all the wasted time working with it is removed from more fruitful work.
-
I started programming like a hobbyist in in my teens with Microsoft Basic interpreted on a CPM machine with two floppies. That was a great pain. Slow and difficult to develop, but with all the glamor and excitement of the discovery of computing.
When I later discovered compiled languages (first Turbopascal and later C) it was a blast. Both for its great speed and for the ease of implementing large programs thanks to structured programming.
But I was still missing a good tool to work with texts. The Internet was in its infancy, Google did not exist and it was not easy to learn like it is now. At that time awk was a revelation for me. An interpreted language, easy to debug and with enormous power when working with text strings and files. It is not a language for large programs, but it was good for simple calculation scripts and text handling.
Later, working with PLCs, the possibility of compiling program descriptions in ladder language came to my mind. I saw it done at Siemens with Excel spreadsheets to generate the base of the PLC programs. But Excel seemed very limited to me.
At that time I met Python and it was another great discovery for me. Like a very vitaminized awk.
I first used Python to validate PLC structured text (similar to Pascal) that resulted from compiling a block diagram. That allowed me to find the bugs in the block diagram that made the emergency stops work.
Python worked simply for a complex job such as interpreting Pascal-like code to find its bugs.
From then on I did not stop using compiled languages, but I recognized the great advantage of having Python, interpreted free language (not like the first turbopascal and c compilers I had) so versatile with which to do jobs that in C would have taken 10 times more work.
I have the point of view of someone who has been missing this tool (Python) for many years and who finally discovered it after going through many languages with limitations that Python does not have.
Of course, when programming a microcontroller, I do it in C. I know that micropython exists, but I haven't used it and it doesn't bother me because microcontrollers don't have to perform the tasks for which Python is specialized.
The language that I am now hoping to find is one similar to the first basic of my beginnings, to be able to debug with an interpreted language that weighs little, small microcontrollers of about 8k-16k flash.
Regards.
-
... I have the point of view of someone who has been missing this tool (Python) for many years and who finally discovered it after going through many languages with limitations that Python does not have....
Having had to use a few too many half-baked fourth generation languages, I was happy to see Python finally become popular. Python has its ad hoc, historical warts, but I still find it the most agreeable high level language so far.
-
Speed is important to me, but I've used interpreters running at a few hundred cycles per second (Microsoft-Basic) on a Z80 4 MHz machine. Then the world of PLCs where a 10ms response is fast and only several thousand instructions per second are interpreted. The same with microcontrollers. A typical 8-bit PIC runs at just 16MIPS in machine code.
I fully understand what it means when someone says that Python is slow, but I also think that there is a lack of perspective when it comes to assessing its speed and to say that a loop of 10,000,000 iterations per second is slow, is to misunderstand what slow means.
Regards.
-
I fully understand what it means when someone says that Python is slow, but I also think that there is a lack of perspective when it comes to assessing its speed and to say that a loop of 10,000,000 iterations per second is slow, is to misunderstand what slow means.
Seems to me you are all arguing the same thing from opposite ends. On the one hand Python is slow compared to alternatives, but is fast enough for the particular purpose. On the other hand, since some purpose doesn't require the speed of alternatives, Python is fast. Just different viewpoints and ways of saying the same thing.
-
Speed just relates to what you can do. In itself, it is also uninteresting. Cars and airplanes enable you to go to places where you wouldn't go otherwise, at all.
If you want to draw graphics on a 4K display, or decompress a full-HD cat video, this just needs the enormous speed of modern computers in full. If you slow it down by two orders of magnitude, then you can do the state-of-the-art things of 1980's/early 1990's on a modern PC. That's the difference.
But quite obviously, many things we do on our computers were already doable in 1970's hardware. In such cases, any amount of execution speed penalty does not matter.
This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you. This should be obvious, but it clearly always isn't.
To say you wrote a video player in Python equals to saying you walked from Sydney to New York, because you walked into the airplane. The performance of this simple walking operation does not matter, because the real work is done elsewhere, and hidden from you.
-
Nonono this is just turning to poo throwing real programmer vs. The world fight. 😆
I wonder how many that claims python as scripting language and something where you only do some minor call logic for libraries that are written with 'The Allmighty', are actually rolling their own compiler and libraries to avoid being scriptkiddies with 'The Allmighty'... xD
Tldr; So much fucked up logic as in nerd talks we used to do in age of 10.
-
Didn't understand any of that cynical outburst. I'm sure many of us can discuss things without throwing poo. I hope the best for you.
How many are writing libraries? Um, quite many? It's completely normal software practice.
-
Scripting languages are great for automating tasks, testing an idea or as a quick way to write some code. But they are not meant for high demand processing, because they don't scale as well as compiled languages. It's like using a 3D printer at home vs. injection moulding. You can do 10000 plastic parts with your inexpensive 3D printer. It works but it will need a very long time. Or you go for the more expensive moulding form and get the 10000 parts quite fast. On the other hand, you wouldn't use injection moulding for a single part, but your 3D printer is the right tool for that. It's about using the best solution for a given problem. Unfortunately these basics are ignored more and more. And that's the reason why we have to deal with crawling slow websites, people claiming that X is the best programming language ever and other stupidities.
-
If you want to draw graphics on a 4K display, or decompress a full-HD cat video, this just needs the enormous speed of modern computers in full. If you slow it down by two orders of magnitude, then you can do the state-of-the-art things of 1980's/early 1990's on a modern PC. That's the difference.
Exactly! We would't try to write an H.265 decoder in python. But in C, or better in silicon. I don't want to run a cluster of 10 PCs just to be able to watch a cat video in 4k.
-
The language specification itself is crappy, too, many historical layers of poor design,
It's the historical curse of interpreted languages produced by semi-competent 'designers'. One thing they all seem to have in common is parsing by an ad-hoc, non-recurvive, version of recursive descent. Often the language isn't designed as such, but cobbled together as they go along. It can be instructive to try and write a grammar for one of that class of languages; you'll quickly find yourself in a mire of special cases and one offs, with a noticeable lack of any kind of regular structure. This is because the language was never designed as such, there was never a specification for the language, just a bunch of ideas and an implementation. If such a language gains popularity, and finds itself in need of a proper implementation, eventually some poor sod has to reverse engineer all that has come before them into an actual specification and then try to reimplement it with a standard set of compiler tooling, or at least a hand-written recursive descent parser (probably with lots of hacks based on heuristics).
Every programmer has their own pet ideas on what would/will make a good programming language. If you are ever tempted to try and make your own more than a pipedream, then please, please, start by trying to write a formal grammar for it and feeding it into lex/yacc (or equivalent tooling of your own choice) and seeing if you can even produce a parsable language. If that doesn't stop you in your tracks then you might be about to produce something usable (you might not as well) but at least you won't be producing something that is pure nightmare from day one.
-
I wonder how many that claims python as scripting language and something where you only do some minor call logic for libraries that are written with 'The Allmighty', are actually rolling their own compiler and libraries to avoid being scriptkiddies with 'The Allmighty'... xD
If you are referring to me, I'm using "scripting language" as purely a technical term for an interpreted language, as opposed to a compiled language.
There is no qualitative aspect involved.
It definitely has nothing to do with the term "script kiddie". Which itself has basically nothing to do with writing interpreted code, and instead describes someone who downloads scripts and uses them without knowing how they work.
To me, a "script" is something that is easy to maintain, modify and adapt, without requiring any development tools (like a compiler). The run time environment, the interpreter and any other run-time requirements like libraries, suffice. I use "script" solely as a technical term without any negative connotations. Just because something is a script, does not mean it is of lesser value or utility or complexity than a program; to me it only means it is run using an interpreter directly from its source, instead of requiring a separate compilation step.
-
To me, a "script" is something that is easy to maintain, modify and adapt, without requiring any development tools (like a compiler). The run time environment, the interpreter and any other run-time requirements like libraries, suffice. I use "script" solely as a technical term without any negative connotations. Just because something is a script, does not mean it is of lesser value or utility or complexity than a program; to me it only means it is run using an interpreter directly from its source, instead of requiring a separate compilation step.
Some of the most valuable programs I have written, in terms of saved man-hours, and thus saved actual hard cash money have been "scripts", mostly csh. I can't put a figure on it, but I would not be surprised if the total in aggregate came to millions of pounds/dollars/whatever, but certainly we're talking multiple 100s of thousands.
If we extend "scripts" to code written in Python then we're definitely there as the last Python project I was on was expected to save a few hundred thousand euros a year. It won't because the organisation it was written for is the kind of large organisation that immediately finds another way to be inefficient and piss money away. But the task it was intended to undertake will now be trivial and cheap, whereas before it was slow, expensive, complex, and (most importantly) risky.
-
This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you. This should be obvious, but it clearly always isn't.
Yes, it is obvious to me.
I have never said that it makes sense to develop a video decompressor in Python. It's something absurd.
When I celebrate that Python is so popular because it is a language that has helped me on many occasions, several forum users appear explaining all the drawbacks and problems of Python to show that it is a language that is worth almost nothing.
Ok, everyone has their opinion and is respectable. But don't get me wrong. I only appreciate Python to the extent that it has served me on many occasions. And I think the same thing has happened to many other users.
If now the Tiobe index has recognized Python as a very popular language and Python has served you well, I think it's time to congratulate yourself for it. And perhaps wonder why it has been like this or, also, why I am happy about it.
I think I'm going to create another thread called "Why i don't like Python and why it's a lousy language", so that those who disagree can elaborate. The topic of this thread is why Python is popular not why Python shouldn't be popular.
Edit:
Perhaps I should change the original question and ask "Who is happy that Python is so popular and why?"
(only for Python fans) ;)
-
When I celebrate that Python is so popular because it is a language that has helped me on many occasions, several forum users appear explaining all the drawbacks and problems of Python to show that it is a language that is worth almost nothing.
This is where we differ. You have emotional attachment to Python, making your communication about it unclear (like the comments about Youtube). Me, on the other hand, I have no emotional feelings about Python at all, in any way, good or bad.
This makes you misinterpret my comments which are just based on facts, not opinions since I don't have strong opinions related to Python, with the sole purpose of letting people gain more understanding. Most non-trivial computing tasks require heavy some lifting, and in Python programs, it's the preferred way to let existing C library code handle that. This is just a fact, regardless of whether you notice it. I spell it out because it's good to know if you want to understand how things work.
Now I understand your mere purpose of discussion is to celebrate your Python fanboyism, and you are not interested in factual discussion. Nothing wrong with that since I have nothing against Python fanboys. Go for it.
I have mostly decent experience on projects written in Python, but I also see some problems, which kind of balances to neutral opinion about it.
-
I've made my pro-Python position clear from the start. But being a fan is not being a fanboy, which is derogatory.
I am not against the opinions that may be held against Python. I'm the first one that I would like it to be faster and I've already commented that I'm glad Guido finally intends to speed up the language.
What I think you explain on many occasions are facts about Python and sometimes against and I'm glad for that, it can serve to put things in their place. But I also notice an emotional attachment against me for being a Python fan.
I'm not against you explaining the facts, I'm against you misunderstanding me and accusing me of being a fanboy.
-
Oh, I'm sorry for being derogatory. I sometimes have that tendency on the interwebz. I'm really not against you, I just felt like some comments in particular were pretty simple-minded (and this is not to mean that you are simple-minded; no, just the few comments) and wanted to correct them, but I can see now that I don't need to sound so condescending to do that.
This "pro-programming language" scene is just very weird to me. I have always used them as tools, maybe even have some weird love-hate relationship (not with Python, though, it's neutral to me), but never pro- or con- just because of the language. In the end, they are tools and suit certain jobs.
-
Python is a tool for me too. But we all have love-hate relationships with our tools.
I hated BASIC because of its many limitations and slow speed.
I have never come to hate C, on the contrary it allowed me to free myself from the assembler and I appreciate it very much for that, although sometimes it drives me crazy when debugging.
Programming in Python gives me good feelings that no other language achieves, I can only put the but of being an interpreted language and therefore not valid for small microcontrollers or for low level, but for that I have C. This makes me bias towards Python, as you can see and I do not hide.
Edit: Is like drive a car. Many people love to drive and some love internal combustion engines, others love electric motors and others don't care because it is nothing more than a means of transport.
-
This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you.
You can get the best of both worlds by using a language that allows you to write code as quickly and sloppily as Python to get your algorithm right, and then improve the most critical code IN THE SAME LANGUAGE to get C-like speed by doing things such as adding declarations, not by re-writing the whole thing.
-
This is all artificial talk, because you can get best of the both worlds. Write performance critical pieces of software in languages such as C, and use Python whenever the libraries (written in C) are available to do the heavy lifting for you.
You can get the best of both worlds by using a language that allows you to write code as quickly and sloppily as Python to get your algorithm right, and then improve the most critical code IN THE SAME LANGUAGE to get C-like speed by doing things such as adding declarations, not by re-writing the whole thing.
Is there such an interpreted language right now?
(Note that it is not Siwastaja, only myself, that needs the language to be interpreted. Thus, this is not a counter-question, this is a new question that just happens to fit into the discussion at this point. I am the one that uses Python3+Qt5 for user interfaces, with all proprietary and high-performance code in native dynamic libraries, implemented in C.)
The only one that I know of, Julia, seems to be directed at research, and Windows/MacOS desktop users. In particular, there does not seem to be a sane maintained Qt interface package at all; I could find two Python-derived ones, and a MacOS-only package. Even the GObject Introspection (https://juliapackages.com/packages/gi) Julia Package seems to be incomplete and unmaintained; it would immediately provide interfaces for tens of dozens of useful, well-known, trusted libraries available in standard Linux distributions.
There does seem to be one for Gtk+ 3.0 (https://juliapackages.com/p/gtk), so anyone using Python+Gtk+3 should consider the Julia alternative. Of course, since no major distribution (especially Debian) have Julia package(s), installation will require executing a binary with superuser privileges from julialang.org, which is not something I personally can vouch for (compared to e.g. installing a Debian package from the official repositories).
I fully agree that Julia is such a language, in theory. (I particularly love its native/C interface capabilities.) In practice, however, the lack of native Linux packages and a maintained Qt interface, does mean one cannot currently use Julia as a practical replacement for Python3+Qt5.
I also use Python for server-side scripting. As to using Julia for server-side scripting, I really worry about the security implications of its precompilation mechanism. I have not yet investigated this thoroughly, but especially in an environment where server-side scripts are run as dedicated user accounts with a shared home directory, controlling such precompilation is paramount. (For Python, there is the -B command-line option and PYTHONDONTWRITEBYTECODE environment variable that can be used to avoid "precompilation"/bytecode file generation issues. For HTML templates and similar, the Python exec() (https://docs.python.org/3/library/functions.html#exec) interface provides a way to limit "untrusted" code access to specified variables, objects, and even limit the availability of standard library functions, including import.)
In other words, to me it looks like the Julia language developers are really not interested in this kind of use cases at all (including multi-user security and privilege separation techniques), and are instead directed at research and Windows/MacOS single-user desktop users, rather than cross-platform and server-side uses.
This look, of course, is only very superficial, and I could easily be wrong. I probably am wrong. You seem to have much more experience in it than I do; do you disagree with my – admittedly superficial! – observations above? Was there some other interpreted language you were thinking of?
The reason I post this, is that language features and theoretical capabilities are one thing; practical use cases and patterns are another thing. Neither thing alone is sufficient to determine what language is most appropriate for a given task: one must consider all things, using whatever weighing pattern one deems most appropriate. For myself, even superior excellence in one thing does not override deficiencies in another. I am not looking for "the best language"; I am looking for the tool with the least drawbacks instead. (Except for a few purely personal quirks, of course, like my avoidance of Perl purely for non-technical personal reasons.)
For myself, I hope I've made it clear that Python language is not the main reason I use it. I do not think it is anything exceptional; it just avoids many of the pitfalls I had to work around in PHP, and has a gentler learning curve than Perl. It is the practical use cases, especially portability and ease of use that determine when I use Python; with everything proprietary and anything requiring computational efficiency provided as native binary dynamic libraries, implemented in C. (I avoid C++ here, to keep dependencies and Python interfacing as simple as possible.)
Julia comes very close. To replace Python3+Qt5 in normal application development, all I'd need is Debian packaging and native/non-PySide Qt5 support. (If it cannot be provided as a Debian package, an application is not worth much in Debian-derived Linux distributions.) To use as a server-side scripting language, some investigation and perhaps development first with precompilation and privilege separation seems necessary, to avoid exploits using precompilation or runtime access to Julia package repositories. As it is, I cannot trust Julia as a server-side scripting language.
-
I didn't know that ↓
~$ python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 1234
>>> b = 1234
>>> a is b
False
>>> a = 123
>>> b = 123
>>> a is b
True
;D
-
I didn't know that ↓
~$ python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 1234
>>> b = 1234
>>> a is b
False
>>> a = 123
>>> b = 123
>>> a is b
True
;D
Cause you are asking about memory locations, which is not intended. You have to use ==. It's like comparing pointers in C.
-
I didn't intend to check if the values are equal, and anyways, that doesn't explain why 123 and 1234 behaves differently.
It's funny how 1234 is not automatically interned, but 123 is.
https://stackoverflow.com/questions/13650293/understanding-pythons-is-operator
Python is allowed to automatically intern any immutable types, but not required to do so. Different implementations will intern different values.
CPython (the implementation you're using if you don't know which implementation you're using) auto-interns small integers and some special singletons like False, but not strings (or large integers, or small tuples, or anything else).
-
I didn't intend to check if the values are equal, and anyways, that doesn't explain why 123 and 1234 behaves differently.
It's funny how 1234 is not automatically interned, but 123 is.
https://stackoverflow.com/questions/13650293/understanding-pythons-is-operator
Python is allowed to automatically intern any immutable types, but not required to do so. Different implementations will intern different values.
CPython (the implementation you're using if you don't know which implementation you're using) auto-interns small integers and some special singletons like False, but not strings (or large integers, or small tuples, or anything else).
Which kind of undermines the whole point of interning in the first place. One wonders what kind of wooly thinking is involved in implementing something which one can't then rely on. Either identical values should have an is relationship or they shouldn't, they most certainly shouldn't have an is relationship for some subset of values and not for others, what bloody use is that? Even crazier is to only implement interning in the cases where it won't imbue some performance advantage and to not implement it in the cases where it will offer a performance advantage. It's like a cargo cult version of interning which offers neither dependability nor improved performance but just exists because someone has heard that 'interning' is good and thinks that having it will magically also cause the thing that has it in name only to be 'good'. Crazy.
-
This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.
In this case, one expects that creating objects a and b results in two different objects. Now it's fully understandable if the programming language does not expose the concept of "object identity" to the programmer, at all, but Python chooses to expose it, and offer a keyword to check if the objects are the same. Yet, it's illogical and unexpected that two objects may be combined to become one, with another's name being just an alias to the same object. The fact that this sometimes happens and sometimes not, based on such hilarious decision making process like the magnitude of the stored value, is just a one more funny detail but not that important in itself. The takeaway is to understand that objects may be combined, and the code should not rely on objects not being combined.
Probably if you have problems with this, it's an indicator you should be working in C, instead. I like low-level control, which is why I also like C. It has a few massive footguns, but after you learn those, you get no ugly surprises, while higher level languages always tend to give ugly low-level surprises if you just assume they are easy and not learn them properly.
-
This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.
No I think you've got that the wrong way around. The idea here is that it is exposing an interface that ought to be high level, but is actually low level and you have to understand the low level [implementation specific] behaviour to use it.
The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.
-
Yes, the low level "leaks" into high level.
Here, you really should do without thinking about the identity of the objects, at all. If you have to do it, you have already lost due to optimizations like this happening.
-
I tend to the notion that Python is for pragmatists.
-
What's even stranger is the range of integers for which a is b: [-5 to +256] inclusive. ???
-
What's even stranger is the range of integers for which a is b: [-5 to +256] inclusive. ???
I'm not going to scribble bit patterns and work out what is going on, but I will note that in Smalltalk implementations small integers are represented in a fashion that allows one to have a word hold a pointer to an Integer (which is a fully fledged object) or contain a restricted range of integers that don't occupy a full word. The bits 'stolen' to mark the type vary depending on platform and on some platforms (SPARC, SOAR) allow one to let the hardware sort out whether to call an object method or just do the arithmetic in the ALU (which understands tagged arithmetic). I'd guess it's some similar scheme that 'steals' a (few) bit(s) from a pointer as a type marker.
-
This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.
No I think you've got that the wrong way around. The idea here is that it is exposing an interface that ought to be high level, but is actually low level and you have to understand the low level [implementation specific] behaviour to use it.
The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.
It would probably be slower, and then you would bitch about that instead of this.
-
This demonstrates the usual issue in almost all high-level languages: they do have constructs which seem like lower level, but these mechanisms are not reliable or predictable.
No I think you've got that the wrong way around. The idea here is that it is exposing an interface that ought to be high level, but is actually low level and you have to understand the low level [implementation specific] behaviour to use it.
The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.
It would probably be slower, and then you would bitch about that instead of this.
Eh? What I, and RoGeorge, are bitching about is the lack of consistency and coherence. Those are rather important to being able to write a correct program that functions correctly. Why implement a feature if you can't reliably use it? What's difficult to grasp about that?
-
The high level idea is that an immutable entity, let's say the number 1, is always the same entity. So if you have two variables that refer to the entity that is what they do (in an abstract sense), they don't store values, they currently refer to the entity [and you're supposed to know nothing of the concrete implementation, of the idea of values being represented by bit patterns stored in words or bytes, or pointers to words or bytes storing bit patterns]. That's the high level abstraction that is being presented, an attempt to present things in their set-theoretic representation. If that's what one wants to do, fine do it. But don't have window dressing that says you're doing that and then in fact present a god awful mish-mash of an abstract model and physical implementation that can't be treated as the abstract model that you pretend you're presenting.
The reality, of course, is that the is test is only practically useful for mutable objects (for example, in a singleton unit test), and because there is no real world practical use case for the test with immutable objects, Python devs do not care. (Or, in other words, they implemented the test for all objects, since it is useful for mutable ones; and simply avoided making any exceptions for immutable objects.)
In other words, I think you are lambasting a detail that is not useful in practice, and only has meaning to theorists. If you don't mind, could you show me wrong, and describe a pattern where this test is actually useful when applied to immutable objects? One where the objects need to be immutable, and it is not just an arbitrary choice?
I do hope we're not kicking Python just because some of its implementation offends impractical theorists? If we start down that road, we need to kick the Linux kernel, too; after all, it is monolithic.
-
...
It would probably be slower, and then you would bitch about that instead of this.
Eh? What I, and RoGeorge, are bitching about ...
Please don't drag me into this, not bitching, in fact I'm having a lot of fun, me just trying to become a Python comedian. ;D
Found out about immutable integers only this morning. I would have never thought. And it was from a topic where somebody was asking about the strip() function. Yeah, so about the stripping function:
\[\star \ \star \ \star \]
Music: Tito & Tarantula - After Dark
The clip is from the movie "From Dusk Till Dawn (1996)"
https://www.youtube.com/watch?v=y1Kn51pMm5o (https://www.youtube.com/watch?v=y1Kn51pMm5o)
- Never trust a Python stripper!
- Why?
$ python3
Python 3.8.12 (default, Jan 2 2022, 01:12:07)
[Clang 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c on freebsd13
Type "help", "copyright", "credits" or "license" for more information.
>>> girl = "Dana"
>>> girl.strip("all clothes")
'Dan'
;D
P.S. In the movie she's not trustable for a different reason.
-
lambasting a detail that is not useful in practice
I thought about this and figured it might be a problem if you were collecting objects and wanted to remove duplicates. It's conceivable that two different objects could contain the same data, but they are not duplicates of an object.
But then I figured if you doing this you would embed an ID in each object so you wouldn't be using the objects (arbitrary) address as an ID. But... maybe you're not a programming guru (just got here via Arduino hacking or something) - wouldn't that then mean the language is too sharp for mere mortals to use? That's the kind of argument against using C or other low-level languages: they are too easy to cut yourself badly enough to require stitches.
[Edit: surely not needed but just in case - it's the 'royal' you, nothing personal :)]
-
I thought about this and figured it might be a problem if you were collecting objects and wanted to remove duplicates.
That's exactly how one would make sure in an unit test that a singleton object really is a singleton. I just don't see any use case wrt. immutable objects; for those, all uses I can think of, equivalence check (logical equality) works; remembering that Python is a language with automatic garbage collection.
I want this discussion to be clear about which complaints are personal, theoretical, or practical, because the distinction is useful to those who are deciding whether Python is a good fit for their particular use case.
[Also, please note that I am asking Cerebus, because I could be wrong here. It is always a possibility. And although I stated it as if a fact, it is only my understanding of the reason why it is so in Python right now, since it is how many if not most Python details get agreed upon; see PEPs (https://www.python.org/dev/peps/).)
-
What's even stranger is the range of integers for which a is b: [-5 to +256] inclusive. ???
I'm not going to scribble bit patterns and work out what is going on, but I will note that in Smalltalk implementations small integers are represented in a fashion that allows one to have a word hold a pointer to an Integer (which is a fully fledged object) or contain a restricted range of integers that don't occupy a full word. The bits 'stolen' to mark the type vary depending on platform and on some platforms (SPARC, SOAR) allow one to let the hardware sort out whether to call an object method or just do the arithmetic in the ALU (which understands tagged arithmetic). I'd guess it's some similar scheme that 'steals' a (few) bit(s) from a pointer as a type marker.
I expect RoGeorge is aware of such schemes, and that (on a 32 bit machine) they normally give you fast "machine" integers in the range -1073741824..1073741823 or possibly -536870912..536870911.
It's really really hard to imagine an implementation of tagged objects in which a range of -5..256 makes sense. That needs 9 bits to represent, with 250 unused values. What would you do with those?
It doesn't make any sense for traditional tagged objects. It doesn't even make any sense for NAN-boxing where the fundamental type is IEEE floating point (usually double precision), and "small" integers, characters, booleans, and pointers are hidden inside the mantissa bits of NaN values.
-
I thought about this and figured it might be a problem if you were collecting objects and wanted to remove duplicates.
That's exactly how one would make sure in an unit test that a singleton object really is a singleton. I just don't see any use case wrt. immutable objects; for those, all uses I can think of, equivalence check (logical equality) works; remembering that Python is a language with automatic garbage collection.
I want this discussion to be clear about which complaints are personal, theoretical, or practical, because the distinction is useful to those who are deciding whether Python is a good fit for their particular use case.
[Also, please note that I am asking Cerebus, because I could be wrong here. It is always a possibility. And although I stated it as if a fact, it is only my understanding of the reason why it is so in Python right now, since it is how many if not most Python details get agreed upon; see PEPs (https://www.python.org/dev/peps/).)
Wrong person to ask as I'm not a Python language lawyer. My take on it is simply one of disliking the inconsistent behaviour. Philosophically, when you assign an integer to a variable in Python you bind the variable to the immutable integer object that has that particular value (obviously in implementation terms you just store an integer value somewhere) so two identical integers (identical values as we'd normally say if we were discussing, say, C) should return True for an is. In CPython* they don't, which is inconsistent. Thusly:
Python 2.7.17 (default, Dec 23 2019, 21:25:34)
[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 is 1
True
>>> 1024 is 1024
True
>>> 1000000 is 1000000
True
>>> a = 1
>>> b = 1
>>> a is b
True
>>> a = 1000000
>>> b = 1000000
>>> a is b
False
>>> quit()
(I used Python 2 rather than 3 because 3 gives a warning message if you put 'is' between literals which clouds the issue. You still get the same results.)
In practical terms the whole thing probably isn't a problem, I can't think of a single place where I've used 'is' in a generic function in real Python code. But there's a bit of me that says that if there's an inconsistency lurking, then somewhere there's a programmer who is going to get bitten by it. In fact it's more likely to nobble a 'pure' Python programmer who actually writes their Python in Python (that is follows the philosophical precepts of Python when writing their Python), whereas I like most people with prior programming experience tend to bring my baggage with me, so I'm not really writing Python, I'm writing C, or Smalltalk, or FORTRAN, in Python.
*I haven't tried it in other than CPython, there's every possibility that it's different in one of the other implementations.
-
It's really really hard to imagine an implementation of tagged objects in which a range of -5..256 makes sense.
Prexactly, that's why I didn't feel like fiddling with bits - I could sense a headache in the making if I tried. :)
-
Philosophically, when you assign an integer to a variable in Python you bind the variable to the immutable integer object that has that particular value (obviously in implementation terms you just store an integer value somewhere) so two identical integers (identical values as we'd normally say if we were discussing, say, C) should return True for an is. In CPython* they don't, which is inconsistent.
Where this philosophy stems from, I do not understand. It sounds nothing like what I've read at python.org. It sounds more like information theoretical model someone thought up.
For example, the is (https://docs.python.org/3/reference/expressions.html#is) operator is described in terms of object identity, which in turn is defined in terms of id() (https://docs.python.org/3/library/functions.html#id) built-in function, which is described thus:
Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.
When describing Python's data model (https://docs.python.org/3/reference/datamodel.html#objects-values-and-types),
Objects are Python’s abstraction for data. All data in a Python program is represented by objects or by relations between objects. (In a sense, and in conformance to Von Neumann’s model of a “stored program computer”, code is also represented by objects.)
Every object has an identity, a type and a value. An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. The ‘is’ operator compares the identity of two objects; the id() function returns an integer representing its identity.
My problem is twofold, and is about this philosophy (or programming paradigm) you described. One, I cannot see any practical use for it, compared to say how Python documents its objects and their identity. Two, I do not see how you have determined that the philosophy applies to Python, because nothing in the official documentation I've seen event hints that way.
Like I wrote above, I use Python because it is practical for certain cases, not because of any intrinsic excellence. I fear that you are applying a philosophy described by theorists, that does not lead to any practical use patterns. As such, such philophies are useless in my opinion. Because it does matter to you, I am interested in knowing why. Unless it's just me failing English again, and you're actually agreeing with Siwastaja.
My take on it is simply one of disliking the inconsistent behaviour.
This I can fully appreciate; and I agree. It is annoying –– I would say even suspicious! –– that the documentation lies: that in fact, some immutable objects (integers between -5 and 256, inclusive, for Python 3.6.9 on x86-64 in Linux at least) do not actually have an unique identity when using CPython Python interpreter.
As a pure difference observed between official documentation and observable behaviour, like Siwastaja wrote in reply #400 (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4002445/#msg4002445), this is illogical and unexpected. Like I said earlier, it seems obvious to me that this is only allowed (for those integer objects) because the developers believe nobody will notice it in practice. That kind of purely practical examination is how Python has evolved thus far.
-
Every object has an identity, a type and a value. An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. The ‘is’ operator compares the identity of two objects; the id() function returns an integer representing its identity.
My problem is twofold, and is about this philosophy (or programming paradigm) you described. One, I cannot see any practical use for it, compared to say how Python documents its objects and their identity. Two, I do not see how you have determined that the philosophy applies to Python, because nothing in the official documentation I've seen event hints that way.
The description is mine alone, not drawn from anything more than my gleanings of various things I've learned or read about the language over the years. You've just reiterated it there: "Every object has ..." - that is a philosophical statement. This is philosophy as in the "this is how we want to look at things" sense of philosophy, not the "how many angels can dance on the head of a pin" variety. I'm not suggesting that there's a manifesto anywhere, just that from observation Python has a certain philosophy, as does C, COBOL, Pascal etc.
As to what practical use that philosophy has? Well, it is what moulds the language. You must have encountered discussions that include a phrase like "What would be the most pythonic way to do it?". The very existence of the word is indicative that there is a philosophy of Python (that encompasses everything from the design of the language to coding styles), and if anything that the existence of a philosophy of Python is more important to some people than it is to aficionados of [most*] other programming languages because someone coined the word and it gained currency.
Or you can flip that on its head and say that if a new programming language doesn't have a philosophy then what is the point of having the new language? If it does all the same things, in the same ways, as existing programming languages, just with different syntax then it brings nothing new to the table.
Finally examining the philosophy (in the general sense) of the type systems of programming languages is in itself important in the same way that Russell examining the philosophy of mathematics was important. As you know, Russell discovered problems with, and solutions to the problems of, the very foundations of mathematics. Instinctively I feel we are in Russell territory here asking the question "In the light of these inconsistencies, is the Python type system well formed?" with, at least on my behalf, a sneaking suspicion that the answer might be "no" . Now, as I know I'm not in the least qualified to discuss Russell's logic that's where I'm going to leave it.
This I can fully appreciate; and I agree. It is annoying –– I would say even suspicious! –– that the documentation lies: that in fact, some immutable objects (integers between -5 and 256, inclusive, for Python 3.6.9 on x86-64 in Linux at least) do not actually have an unique identity when using CPython Python interpreter.
As a pure difference observed between official documentation and observable behaviour, like Siwastaja wrote in reply #400 (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4002445/#msg4002445), this is illogical and unexpected. Like I said earlier, it seems obvious to me that this is only allowed (for those integer objects) because the developers believe nobody will notice it in practice. That kind of purely practical examination is how Python has evolved thus far.
You're more than entitled to take that position. It's just for me that "purely practical" stepping around the issue feels rather like cleaning the floor by sweeping the dust up, and then putting it underneath the carpet. It will niggle and moreover it make me wonder "What other things might we have missed? Will they be gotchas with practical importance?". It's a bit like Gödel, Russell and the underpinnings of mathematics (perhaps with a little sprinkle of Turing), for all practical purposes it all worked before they got their hands on it, but now we how to make some bits work better, and perhaps most importantly, we now know where it can't work.
*I've noticed that several of the more recent programming languages tend to attract these neologisms. e.g. Rustaceans for "rust programmers".
-
... What other things might we have missed? Will they be gotchas with practical importance?...
Every language seems to have its gotcha's. If you know one that does not, I am all ears. The question I ask is: how often will I be bitten? With Python it has been about once every thousands of hours of exploratory, original programming. That is easily the best record of the languages I have used – and one reason I use Python.
The last two gotchas were with exec. Both were respectively and sympathetically heard and then understandably reclassified as documentation bugs. Fixing them would have been hard and there is only so much the developers can do. Perhaps that should read fixing one of them was hard, as I can not replicate a gotcha using more recent versions of Python. (Both issues remain open.)
For comparison, I seem to get bitten about once an hour when I do Windows programming. That might explain why I do little of it. Perhaps the issue is I am a poor cut and paste programmer.
-
I prefer the strongly typed languages.
At least then the compiler throws it out if I made a mistake.
Add 1 to 1 and getting 11 because the compiler thought the the types were a string and not numbers isnt good.
I got on with Python OK but took a while to get used to the code indentation after 20 years of curly brackets.
-
I prefer the strongly typed languages.
At least then the compiler throws it out if I made a mistake.
*Some* limited kinds of mistakes.
Add 1 to 1 and getting 11 because the compiler thought the the types were a string and not numbers isnt good.
Type - instead of + by accident, or > instead of >= and no compiler will help you.
-
Oh how I hate this damn machine,
I wish that they would sell it!
It never does quite what I want,
but only what I tell it
(anon)
-
Strong (manual) typing is one way of communicating explicit intent to the compiler. The problem with assumptions is, they are prone to go wrong, and then you need to understand how the assumptions are made, actually increasing the mental load when the whole purpose of automation was to decrease it. Unless you somehow manage such "small details" out of your mind and just happen to get it right.
Therefore, I agree with explicit typing, and I find "easy" languages with automatic typing more difficult to use. I did struggle with PHP typing after having some years of limited experience in C++ and C, even though the automatic type system was supposedly "easier".
I would like to see even more explicit control and writing down assumptions in formal ways; for example, add ranges to variables in C (pretty much like Ada/VHDL does).
-
As to what practical use that philosophy has? Well, it is what moulds the language. You must have encountered discussions that include a phrase like "What would be the most pythonic way to do it?". The very existence of the word is indicative that there is a philosophy of Python (that encompasses everything from the design of the language to coding styles), and if anything that the existence of a philosophy of Python is more important to some people than it is to aficionados of [most*] other programming languages because someone coined the word and it gained currency.
Or you can flip that on its head and say that if a new programming language doesn't have a philosophy then what is the point of having the new language? If it does all the same things, in the same ways, as existing programming languages, just with different syntax then it brings nothing new to the table.
Ah, now I understand. As I've said before, I don't like Python because it has nice features, I like it because it has fewer/milder practical downsides than the alternatives.
Similarly, instead of an underlying philosophy as you described, I consider programming languages' based on their practical approach to problem solving and their patterns (which I call their 'programming paradigm'). In my opinion, the difference between philosophy and paradigm is analogous to the difference between models and patterns, or the difference between asking why and how. (Or, how there is Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy), and then there is POSIX (https://en.wikipedia.org/wiki/POSIX) – not just the extensions to the C standard library, but things like sockets, signals, timers, et cetera.)
In a perfect programming language, both would be well formed and described... but what we have at hand, especially Python, is more like a set of compromises.
Finally examining the philosophy (in the general sense) of the type systems of programming languages is in itself important in the same way that Russell examining the philosophy of mathematics was important. As you know, Russell discovered problems with, and solutions to the problems of, the very foundations of mathematics. Instinctively I feel we are in Russell territory here asking the question "In the light of these inconsistencies, is the Python type system well formed?" with, at least on my behalf, a sneaking suspicion that the answer might be "no" . Now, as I know I'm not in the least qualified to discuss Russell's logic that's where I'm going to leave it.
I understand, and definitely do not disagree. Perhaps my stance here could be summarised as "True; but the programming languages we currently have are just practical tools full of compromises and less than optimal design choices, their philosophies full of elephant-sized holes, so I do not think analysis at that level is appropriate yet."
You're more than entitled to take that position. It's just for me that "purely practical" stepping around the issue feels rather like cleaning the floor by sweeping the dust up, and then putting it underneath the carpet. It will niggle and moreover it make me wonder "What other things might we have missed? Will they be gotchas with practical importance?". It's a bit like Gödel, Russell and the underpinnings of mathematics (perhaps with a little sprinkle of Turing), for all practical purposes it all worked before they got their hands on it, but now we how to make some bits work better, and perhaps most importantly, we now know where it can't work.
I can definitely appreciate that. To me, the situation is more like an earthen floor, sweeping of which for dust is impractical, and see concentrating on the larger debris and unwanted dirt more appropriate for now. I would love to have a proper floor (programming language with solid underpinnings), but I do not have the, uh, engineering experience in floors?, to construct one myself; so, I have resigned to work with what I have, and help develop better stuff in other, more limited scopes first. (Like embedded C patterns (https://www.eevblog.com/forum/programming/constructing-short-c-strings-in-limited-or-constrained-situations/) or a replacement for the C standard library (https://www.eevblog.com/forum/programming/replacement-for-c-standard-library-your-wishlist/). Or how to make web based services more secure by leveraging the Unix/POSIX kernel-provided privilege separation mechanisms (process user and groups) and so on, using Python (or any other scripting language) on the backend.)
(Apologies for stretching the analogy so far ::).)
In systems programming, my attitude shows clearest in that I insist that whenever a program detects an error when dealing with my data, I want it to tell it to me, the user whose data that is. I care much less whether the program can deal with the error or can work around it –– that would be nice, but much less important to me. I never trust tools like computers or computer programs the way I trust mathematics, so I am always 'suspicious'. With Python, I use it for user interface stuff and server-side backend (HTML) processing, which both are at best a "best effort" scheme, without any true guarantees of successful functionality; with much, much heavier emphasis on things like data security, privilege separation/escalation models, and so on.
-
I can definitely appreciate that. To me, the situation is more like an earthen floor, sweeping of which for dust is impractical, and see concentrating on the larger debris and unwanted dirt more appropriate for now. I would love to have a proper floor (programming language with solid underpinnings), but I do not have the, uh, engineering experience in floors?, to construct one myself; so, I have resigned to work with what I have, and help develop better stuff in other, more limited scopes first. (Like embedded C patterns (https://www.eevblog.com/forum/programming/constructing-short-c-strings-in-limited-or-constrained-situations/) or a replacement for the C standard library (https://www.eevblog.com/forum/programming/replacement-for-c-standard-library-your-wishlist/). Or how to make web based services more secure by leveraging the Unix/POSIX kernel-provided privilege separation mechanisms (process user and groups) and so on, using Python (or any other scripting language) on the backend.)
(Apologies for stretching the analogy so far ::).)
So, to completely round off the analogy - "Python programmer, him live in mud hut!". :)
One final thought on this, and then I think we have all had enough of it. This particular oddity, where something has apparent behaviour that can be silently altered by the specific values being dealt with could be called hidden or covert behaviour. It's pretty obvious that covert behaviour is exactly the kind of thing that can be used to create and exploit security holes.
You could have a chunk of software that would pass peer review based on its overt behaviour, but conceals a deliberate vulnerability based on its covert behaviour. Not straightforward or simple, but doable. It's that kind of possibility that has been subconsciously niggling at me and saying "This is bad, worse than the trivial quirk it appears to be.". It gives you something that looks right, but is in fact wrong, and that's all you need to sneak something through a code review.
Just to demonstrate that Python gets used in places where it could have serious consequences we only have to look at the last Python gig I had. We were writing what was planned to go on and become the core network orchestration tool for a very large telco in Python. We configured routing/switching fabrics, we configured load balancers, we configured firewalls. If you could plant an exploit in this it could give you access to reconfigure core networking equipment in any way it liked, certainly in a way that could bypass protections between the core network and the Internet, or just bring the core network to a dead halt that would take weeks to recover from. Precisely because of this we were very security oriented, parameter validation left, right and centre, peer review twice (code review and security review) for every bit of code. Nevertheless I could have smuggled a vulnerability based on this quirk through all that, had I (a) wished to, (b) known of this quirk at the time.
-
Type - instead of + by accident, or > instead of >= and no compiler will help you.
If you do VHDL most of the time, and occasionally drop down into C, you might have done something like this and wondered why it didn't work:
if( foo /= bar) {
doSomething();
}
and of course this one is very exciting:
if( foo /= 0) {
doWeEvenGetHere();
}
-
Therefore, I agree with explicit typing, and I find "easy" languages with automatic typing more difficult to use. I did struggle with PHP typing after having some years of limited experience in C++ and C, even though the automatic type system was supposedly "easier".
I find it very annoying to read other people's code in languages where functions are declared with just a list of names of arguments, with no indication of what actual type is expected. Comments aren't enough, and of course aren't always present.
I don't much care whether the type declaration is a concrete type, or a base class, or a protocol/interface.
Often just knowing the argument types is enough for both the reader and the compiler to figure out the types of local variables in the function, so I don't mind so much if those aren't explicit.
I would like to see even more explicit control and writing down assumptions in formal ways; for example, add ranges to variables in C (pretty much like Ada/VHDL does).
Pascal has of course had this since 1970.
type ASCII_digit = 48..57;
var digit_char: array[ASCII_digit] of char;
It's bounds-checked too.
(Yes, yes, there's the chr() function ... this is just an example)
-
Energy Efficiency across Programming Languages
How Do Energy, Time, and Memory Relate?
https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
-
Looks like Javascript is the greener programming language. ;D
I'm tempted to call bollocks on such a study. They started with half page of emails and visit cards, and to quote their conclusion:
In this paper, we first present an analysis and comparison of
the energy efficiency of 27 well-known software languages
from the popular software repository The Computer Lan-
guage Benchmarks Game. We are able to show which were the
most energy efficient software languages, execution types,
and paradigms across 10 different benchmark problems.
Look how many stuffing/emphasizing words are there:
"we first present" - make it "we present"
"an analysis and comparison of" - either "analysis" or "comparison" would be enough
"27 well-known software languages" - remove well-known
"from the popular software repository" - popular
"We are able to show" - glad they weren't unable, "We show"
"10 different benchmark problems" - 10 benchmarks
"So", "basically" such wording put me off of considering their research. :-\
-
Expression is just a pretty wrapper - the content matters! That study doesn't reveal anything new, it simply confirms old programming basics. Anything interpreted is fine for tasks rarely performed but sucks when run all the time. One can ignore the greybeards but no new and fancy programming language will change that. Instead of improving programming some 'geniuses' create another new language which is meant to change things, but actually it doesn't. It's just another new language. Better learn to deal with memory management and security than wasting resources on yet another fancy language. It's easy to become a script kiddy, but hard to become a software developer.
-
It's easy to become a script kiddy, but hard to become a software developer.
Indeed.
-
Expression is just a pretty wrapper - the content matters! That study doesn't reveal anything new, it simply confirms old programming basics. Anything interpreted is fine for tasks rarely performed but sucks when run all the time. One can ignore the greybeards but no new and fancy programming language will change that. Instead of improving programming some 'geniuses' create another new language which is meant to change things, but actually it doesn't. It's just another new language. Better learn to deal with memory management and security than wasting resources on yet another fancy language. It's easy to become a script kiddy, but hard to become a software developer.
Well put.
This is also exactly why I personally am not interested in creating a new programming language, and instead concentrate on making small useful incremental changes instead. Like pushing some of the useful POSIX C library interfaces onto C learners, like using getline() instead of fgets(), nftw() instead of opendir()/readdir()/closedir(), and so on. The biggest being trying to find out what kind of programming interfaces (replacing the standard C library) would make C an even better systems programming language, noting that basically all C compilers support compiling freestanding code, i.e. not using the standard C library, so in a very real sense it is just a different library interfacing to OS services, as well as useful structures and algorithms.
Also, using the imperfect but somewhat useful tools available right now, including Python 3 and C, to implement applications in a way that makes long-term maintenance easy, but fulfills "business requirements" regarding proprietary source code as well. I'm not looking for "the Best", just using the tools that have the least drawbacks in a given scenario.
-
Tiobe April headline.
Python replacing Matlab?
"April Headline: MATLAB about to drop out of the top 20
Good old MATLAB is about to drop out of the top 20 for the first time in more than 10 years. The MATLAB programming language is mainly used in the numerical analysis domain. It is often combined with Simulink models, which are from the same MathWorks company. Although MATLAB has a biannual release cycle, the language doesn't evolve that much. And since MATLAB licenses are rather expensive, alternatives are catching up quickly now. Its main competitors are Python (currently number 1) and Julia (moving from position 32 to position 26 this month). --Paul Jansen CEO TIOBE Software "
-
Yeah. :D
https://www.youtube.com/watch?v=YnL9vAFphmE (https://www.youtube.com/watch?v=YnL9vAFphmE)
-
Its main competitors are Python (currently number 1) and Julia (moving from position 32 to position 26 this month).
And R, Shirley?
-
Python is a slow, confused mess. It's REALLY slow. Introducing Python to people saying "It's easy to learn" is NOT a good reason for them to learn it. Using whitespace to demarcate program flow, is, well, laughable. Having X number of incompatible versions across Y number of platforms... ugh. STOP it. Google used Java for Android because "Developers will already know Java" (or words to that effect) - yeah - the same logic applies with Python - because something is EASIER, that is not a decent reason to teach it as the mascot language for an OS. Raspberry Pi chose it as the pivotal part of their "Let's recreate the BBC Micro, and the 80s bedroom coder" spiel, too :palm: ... yeaaaah... so taking that into account is enough to make me want to stay as far away from it as possible.
Programming IS HARD. You only get out of something what you're willing to put into it. ASM is hard, C is hard, but they run SOOOOOOOOO fast, and having huge amounts of RAM and multiple cores and fast disks is NOT a good reason to be lazy.
Let's see what Dave Plummer has to say - you know - the chap who wrote the WGA (XP licencing) code, and the Task Manager - I trust his viewpoint:
https://www.youtube.com/watch?v=D3h62rgewZM (https://www.youtube.com/watch?v=D3h62rgewZM)
-
I refuse, given the choice, to use a programming language that imposes "structure" by "number of invisible characters". That is stupid on a level only challenged by "one type of invisible character is to be interpreted different than another invisible character".
Here are some hints on characters that without ambiguity can impose structure:
{} () ;
Apart from that fundamental stupidity, I'm sure Python is a nice language.
Abso-bloomin-lutely. It's idiotic. I read this a few weeks ago, makes a LOT of points that resonate with me: https://www.hackerfactor.com/blog/index.php?/archives/825-8-Reasons-Python-Sucks.html (https://www.hackerfactor.com/blog/index.php?/archives/825-8-Reasons-Python-Sucks.html)
-
Executive summary: Python is the Windows of programming languages. >:D
-
Programming IS HARD. You only get out of something what you're willing to put into it. ASM is hard, C is hard, but they run SOOOOOOOOO fast, and having huge amounts of RAM and multiple cores and fast disks is NOT a good reason to be lazy.
I hear you :o
I have been working since May 2001 on an integration between a-tile-Windows Manager and some sort of exposure tool, and guess what? I have to *remove* tons and tons of bloody python scripts because there is a thin C layer and everything else is written in Python, which, not only is slow on a 400Mhz machine, but it's also a mess to compile and install with an embedded-diet profile.
Ultimately, computing is getting more frustrating with more and more lazy dudes hanging around, I don't know why those guys have to play with electronic and computer science instead of watching a manga, cooking, doing something else :-//
-
computing is getting more frustrating with more and more lazy dudes hanging around
I think they serve a purpose in pushing the frontiers. Sure, the result may not be production ready but they achieve things that possibly wouldn't happen for a long time otherwise. Often, some things aren't invented because they don't seem possible or sensible, whereas those lazy dudes creating stuff by just snapping together lots of other stuff show that things can work, and when you get to use them they are useful (if still not necessarily sensible). Just knowing something can be done often allows it to be done 'properly' and better.
-
those lazy dudes creating stuff by just snapping together lots of other stuff show that things can work, and when you get to use them they are useful (if still not necessarily sensible). Just knowing something can be done often allows it to be done 'properly' and better.
yes, good point, you are absolutely right, in fact now I know that the MacOS functionality "expose" can *somehow* be implemented even for a tile-windows-manage on Linux, which is the the great news of the whole story.
It's a great news :D
Just ... no one has even thought of a design, there is not even a draft of design, and it's like someone wakes up in the morning and puts a lot of other things together ... which is nice, but also a problem when you have to think about
- error handling, there is nothing in their scripts, the code simply hangs
- code test
- maintainability of the code
I cannot simply re-implement their Python-scripts in C, first I have to think about the skeleton, and other sensible inner stuff like error-propagation, which is why I haven't yet completed the project.
It's probably all a matter of time: designing robust and reliable software takes a lot of time, and those dudes just don't like (they can't?) spend so much time on the dev-console.
-
I think you are confusing the purpose of an interpreted language (Python, PHP, Matlab, Lua, etc) with the purpose of a compiled language (C, ASM). Both have their niche and are not directly comparable.
Although Python is often used as a scripting language, it is also used for large, difficult to program and complex programs.
Nor should a script be confused with a program with more than 1000 lines of code.
Examples:
https://github.com/django/django/tree/main/django
https://github.com/matplotlib/matplotlib
-
Tiobe April headline.
Python replacing Matlab?
"April Headline: MATLAB about to drop out of the top 20
Good old MATLAB is about to drop out of the top 20 for the first time in more than 10 years. The MATLAB programming language is mainly used in the numerical analysis domain. It is often combined with Simulink models, which are from the same MathWorks company. Although MATLAB has a biannual release cycle, the language doesn't evolve that much. And since MATLAB licenses are rather expensive, alternatives are catching up quickly now. Its main competitors are Python (currently number 1) and Julia (moving from position 32 to position 26 this month). --Paul Jansen CEO TIOBE Software "
The issue I proposed above is that Python (and Julia and R) are probably replacing Matlab.
In my opinion a good replacement for simulink would still be missing for Python to take the cake.
-
Executive summary: Python is the Windows of programming languages. >:D
Perhaps this is true in terms of popularity.
But it is definitely not true in terms of licensing. Python is free and open-source.
-
Its main competitors are Python (currently number 1) and Julia (moving from position 32 to position 26 this month).
And R, Shirley?
For years I have been using Octave as an affordable (free) replacement for Matlab. Thanks you GNU.
I can't speak directly to the popularity of Matlab, but if it's waning that is likely due to very high cost.
Meanwhile, Python is not too slow when most of the work is done by compiled libraries like NumPy. I know several physicists that can program in C but choose to code simulations in Python. They use large math libraries, some of which are available for both C and Python. They report that the Python code runs almost as fast as C code, but requires much less of their time to write. I'm in no position to tell them they should be programming in asm.
Meanwhile, I know enough Python to use it without ever using it. I do use Octave for some numerical code, especially data analysis. Ain't nobody got time to duplicate NumPy or Matlab (Octave) matrix stuff by hand. I do know one guy that insists on writing his own pixel level image processing code in C, but he's too old to learn anything new.
-
Meanwhile, Python is not too slow when most of the work is done by compiled libraries like NumPy. I know several physicists that can program in C but choose to code simulations in Python. They use large math libraries, some of which are available for both C and Python. They report that the Python code runs almost as fast as C code, but requires much less of their time to write. I'm in no position to tell them they should be programming in asm.
To be precise, Python is slow, but in many valid use cases it does not matter (affect the overall run time much), because all the hard work is done in compiled machine code, and only the glue logic –– or in my case, user interface event handlers –– runs in the Python interpreter.
In other words, in these kinds of workloads, only a fraction of the CPU time used, is used in interpreting Python code, and the vast majority is spent running compiled machine code.
There are a lot of physics problems that boil down to relatively simple linear algebra, plus transformations. Since most of the run time is in all cases taken by the linear algebra routines in BLAS or LAPACK (or their Intel MKL or AMD ACML optimized implementations), what matters more is how much time and effort is needed for the glue logic. Not so much because of time taken per se, but because of the cognitive load and error probability.
I do know one guy that insists on writing his own pixel level image processing code in C, but he's too old to learn anything new.
Hey! >:( So do I! On microcontrollers, that is, interfacing to small ILI9341 and similar display modules. It's fun. Reminds me of the early nineties, creating all sorts of pixel effects...
-
I do know one guy that insists on writing his own pixel level image processing code in C, but he's too old to learn anything new.
Hey! >:( So do I! On microcontrollers, that is, interfacing to small ILI9341 and similar display modules. It's fun. Reminds me of the early nineties, creating all sorts of pixel effects...
I get that. This particular application uses a monochrome camera to capture an image that contains a bunch of bubbles, some of which are fluorescing, some not. The software runs on an embedded Raspberry Pi. It needs to identify the bubbles, determine the size of each, characterize any defects, then characterize the degree to which it is fluorescing.
The customer provided sample code using OpenCV that worked perfectly and could easily be used on the quad core RPI. But, this particular person is afraid to use C++ classes in their C programs. I explained that using them does not require a complete change in programming paradigm; he just needs to think of classes as structs that hold functions as well as data. No, he's sure his hand coded C routines are faster.
As long as everyone is having fun.
-
No, he's sure his hand coded C routines are faster.
Yeah, that is silly. I don't think it is an age thing, though; I think it is a "this is my favourite hammer, and I love it; all problems are nails, and suggesting otherwise is an affront to my person" thing.
I do sometimes write specialized functions in inline assembly (typically using GCC/Clang extended assembly), but whenever I do so, I also have a plain C or "naïve" implementation of the same function also. It is necessary for unit testing, but it also makes the code easier to maintain and to port to different architectures. Simply put, it is an optimization thing.
(For a few years now, I haven't needed to write inline assembly for SIMD functions, as the intrinsics (<intrin.h> etc.) and built-ins that GCC and Clang provide, suffice to write equally performant code in C/C++. The key is to not target the absolute optimum, but a way that never behaves horribly bad: aim to avoid the pitfalls, not towards an unreachable 'optimum'. One can get surprisingly good results that way.)
As long as everyone is having fun.
Well, you (and I assume your employer) definitely aren't, so it's not working in this particular case. It is not okay to have fun on somebody elses cost.
-
Executive summary: Python is the Windows of programming languages. >:D
Perhaps this is true in terms of popularity.
But it is definitely not true in terms of licensing. Python is free and open-source.
The whole "FOSS" baloney is meaningless, people parrot it like it's magic sauce.
I'd rather pay for a product that WORKS, than have a "community" (hah!) of freetards that shrug and say " :-// It's free, you're free to fix it and modify the source code" - yeuccch. I'd rather a CLOSED system that is working because the company behind it are motivated to fix it due to it being a paid product, company image, shareholders etc. Money is a GIGANTIC motivator.
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
We need open specifications and diverse implementations (some free, some paid, whatever...). A bit like the RISC-V ISA. Especially for general-purpose languages.
Languages plagued with being indistinguishable from their reference (and most often, only) implementation are unfortunately common with the more "modern" languages. We can list a few: Python, Rust, Swift, Go, ... Java was also one, and even though I think there are some alternative implementations, the reference one is still king AFAIK.
That is problematic on a number of levels that would take some time to elaborate on. One is that, whether the implementation is "free" (beware of licensing details though) or not, that still "locks you in" in some way.
-
The whole "FOSS" baloney is meaningless, people parrot it like it's magic sauce.
I'd rather pay for a product that WORKS, than have a "community" (hah!) of freetards that shrug and say " :-// It's free, you're free to fix it and modify the source code" - yeuccch. I'd rather a CLOSED system that is working because the company behind it are motivated to fix it due to it being a paid product, company image, shareholders etc. Money is a GIGANTIC motivator.
I suspect that everyone prefers things that work over things that don't. The great thing about the world we live in is that each of us can choose for ourselves which tools we use - or use whatever our employer wants us to use. We can buy commercial products and rightly feel good about. Or we can find other solutions.
I feel no compulsion to justify the choices that I've made (unless someone specifically asks) but neither has anyone here tried to influence your decisions. So what exactly are you ranting about?
-
So what exactly are you ranting about?
It is what he does. As treez couldn't help but thank, eti can only rant :)
-
Executive summary: Python is the Windows of programming languages. >:D
Perhaps this is true in terms of popularity.
But it is definitely not true in terms of licensing. Python is free and open-source.
The whole "FOSS" baloney is meaningless, people parrot it like it's magic sauce.
The irony that we can only read your "enlightened" opinions because they have been posted on a platform that relies entirely on FOSS is no doubt completely lost on you.
-
Ha! Good point.
I challenge anyone to go a full day without making use of something running a linux kernel. (Which brings us full circle back to Nominal's comment RE: Python and MS Windows.)
-
It’s a bit like the evolution of cars and drivers through the 80s…
Yes, you can be a driver without knowing anything about cars or engines.
or, you can study and understand the car and it’s mechanisms - and be a driver.
One of these two people will be a better operator of the car in unexpected situations, and can explain driving a lot better to their children, friends and others.
-
One of these two people will be a better operator of the car in unexpected situations, and can explain driving a lot better to their children, friends and others.
The problem I most often see in this kind of discussion, is more analogous to people discussing car behaviour on slick ice, when a long-haul trucker having a 40-year career in the Australian outback ridicules the entire discussion as fantasy because they certainly never had to deal with ice on asphalt, so it is impossible for it to occur to anyone else.
This is extremely common with those who have a long history in Windows use and no other OS experience, and with those who expect the vendor to provide a solution path for every conceivable problem. In particular, they will ridicule the Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy), and ignore any arguments showing how it is still the most effective paradigm in e.g. high-performance computing, because it just doesn't fit their personal experience. They will demand frameworks and cathedrals instead of modular libraries, because they find the responsibilities associated with freedom scary or difficult. Similarly, they often make claims about various software licenses and international intellectual property law, based on something they believe (having perhaps heard it thirdhand at a coffee shop before), and if their opinion is shown to be bullshit, start spouting how only lawyers should be allowed to discuss this stuff online. Qt licensing is a particular sore spot.
In short, it is better to just ignore the rants. It's not like they're going to respond rationally anyway.
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.
I also dislike languages that are too inexpressive or too low performance to usefully implement the majority of their own libraries. It is possible to design high level expressive features in ways that don't force low performance implementation.
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.
This.
Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. :palm:
It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.
This.
Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. :palm:
It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.
To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.
Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.
This.
Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. :palm:
It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.
To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.
Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?
You have a point but it is actually in reverse: because mentality of ephemerality (sorry!) is the reason why they don't care. Old is shit and is there to be thrown away. There cannot be any merity given to the old, no compatibility or any kind of confession that old version was pretty damn good and these few things had to be fixed to make it perfect. You NEED to throw away and do it from the scratch..
And that brings the second point: What makes you think that software intellectual types consider it it a TOOL as you explain it. Software "tools" are measured by different merits. They will wax poetic about all kinds of theoretical concepts the new "tool" or language supports. Actual practicality, usability or productivity is not really a priority...
-
Not an expert. But I like python. It helped me a lot for Raspberry Pi based embedded system engineering projects.
-
I also dislike languages that are too inexpressive or too low performance to usefully implement the majority of their own libraries.
Yes, this is actually an interesting discussion in itself. Also true for the compilers.
Many general-purpose languages used to have their compilers and libraries written in their own language. Compilers are then bootstrapped in some way.
That is becoming rare these days. Sure you can say that for interpreted languages, this would probably not be practical. But interestingly enough, that's not just true for interpreted languages. Many newer programming languages have their compilers (and sometimes libraries) written in another language.
Even if the language never got popular, one seminal example IMO is Modula-3. Everything was written in Modula-3, from the compiler to tools to libraries, and the set of libraries was known to be of high quality. You can have a look at the project, which is seeing some revival lately: https://github.com/modula3/cm3
-
Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?
This is actually a concerning trend that is plaguing the software industry in general, and has become the new norm, out of so-called productivity.
So it's not surprising at all that languages promoting this behavior are part of the trend, and have become very popular, backed by large corporations.
-
From what I’ve seen over the last few years, it looks like Python is the 21st century BASIC.
I’ve used both, but honestly, like many languages both have strong points for quick application development, but are almost delusional for system or anything near-real-time or mission-critical.
I doubt you’d find any critical life support system in either. They may exist, but I’d bet they’re not ‘certified’ or ‘verified’ by any responsible authority.
-
Money is a GIGANTIC motivator.
I agree about the motivator, but since you'll make more money by ignoring the bugs rather than paying programmers to fix them, the notion that closed source software somehow is better is pretty silly. It is made to a price, and it's more important that it got features than it is that it is fault-free. Sells better that way.
The highest quality operating systems are either extremely expensive (AIX et al) or free, like all the large BSD systems. Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.
-
Another powerful motivator is the need for something that does not exist commercially. Obviously there's a lot of crap available for free. Nobody ever disputed that. But I frequently find myself using open source software that was developed by the people that use it. They developed it because they need it and were not satisfied with commercial options.
OpenFOAM is a good example of that. Researchers at Imperial College in London wanted a flexible and powerful tool for computational fluid dynamics. They created what would become OpenFoam. It was sold commercially briefly, but quickly was made open source and it continues to be developed and maintained entirely by people that use it. The project is overseen by the OpenFOAM Foundation, but improvements and features are added by people that need them. It works along with a set of other high quality open source tools for meshing and pre- and post-processing and is becoming the tool of choice for a growing number of researchers in CFD, even when commercial tools are available.
Another example is Blender. It was originally developed by an animation studio for internal use but was eventually made open source. Today it is used almost universally by everyone producing animation or realistic graphics. This includes game programmers and major movie productions. It is maintained entirely by people that need a high quality and powerful tool. No programmers are being paid by yearly license and support fees.
-
Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.
But but but... Linux, and especially systemd, is free. Therefore, by your argument, systemd must be better.
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.
This.
Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. :palm:
It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.
To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.
Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?
Where it comes to Python, I have to agree with this. Over the years I have tried to install some Python based software but ran into many incompatibilities between versions and OS. Initially I had the impression that Python was easely portable and maintainable but the opposite is true. It is even worse compared to the DLL hell that plagued the older Windows versions. IMHO it is better to write an application in C++ using Qt or WxWidgets and link it statically to have a fighting chance of being able to install & run an application next year compared to using Python.
If you want to distribute a Python application, you have to hand-out pre-configured VM images.
Bottom line: Python is great to tinker a script together but it absolutely sucks for writing applications (unless you want to keep sinking money into software that is essentially finished).
-
Well, as far as I've seen over the years, every such promise of instant portability and "runs everywhere" has fallen short. Java is a prime example, not just Python. The same shit largely applies. If you don't embed your own, known to work with your app-JVM, chances are that users won't be able to run it properly, or will encounter various bugs.
-
Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.
But but but... Linux, and especially systemd, is free. Therefore, by your argument, systemd must be better.
You troll! :-DD
No, Price / Quality relationship is a quite non-linear equation. That is about as much as we can say.
Anyway, I just took a peek at some Python code (desperately trying to get back to topic.), this time for Home Assistant to check the ARP table in a router. My observations:
- Yes, the code is readable, but that is because all things that do something are strings for the interactive HMI (Human-Machine-Interface, the command line used to configure and troubleshoot the router) sent via a SSH connection emulation library. Basically a screen-scraper, the most fragile way of interprocess communication short of rumours.
- The approach chosen when fetching information is very simply put "monkey see, monkey do"; the code emulates what I'd do to go look manually. It is a cute but immature first step.
- The approach to adaptation to the network setup further is a very QnD one, no provision is made for anything beyond the most simple out-of-the-box, click-next-next-next-OK-reboot setup of a network. This is no fault of Python, it is the usual case of assumptions made to give impressions of Magic. Most common in IOT and media servers, but not unheard of in other auto-configuring software systems.
- The proper way to get the ARP table out of a network element when machine is talking to machine is either the classic SNMP or the more modern NetConf/YANG model.
- There are Python libs for this too, but they're not used. Probably too much understanding of problem required.
Fast and wrong, Internet of Shit style. Not impressed.
Simply because it is easy to write does not mean it is easy to get right.
-
Fast and wrong, Internet of Shit style.
It must the new hipster hype.
Internet of smart things but in Fast and wrong Shit style.
It greatly sucks, but they are earning a lot of money on that *educational* internet of shit because it's supposed to *teach* something ... as you well summarized, the problem here is the fast and wrong shitty approach.
And Python has certainly been overused for the purpose.
-
I have been using Sphinx in a Windows environment for years and have never had any compatibility problems with either the Sphinx package or any of the dependencies, which are updated automatically with pip. I have had no problems with older installed versions of Python or when upgrading Python to newer versions.
I'm not saying there aren't problems with other packages, but I've never had problems with Sphinx.
https://www.sphinx-doc.org/en/master/ (https://www.sphinx-doc.org/en/master/)
-
In other cases I have seen recommended managers like conda to avoid inconsistencies between Python packages.
https://docs.conda.io/en/latest/
-
If you're having incompatibility issues with python you are
1.) Using a code from a bad project who isn't specifying their dependencies.
2.) Aren't familiar with how the various environment specification systems work and are blaming that instead of learning how to use the provided tools.
What do you individuals do in lower level languages for dependency management?
-
If you're having incompatibility issues with python you are
1.) Using a code from a bad project who isn't specifying their dependencies.
2.) Aren't familiar with how the various environment specification systems work and are blaming that instead of learning how to use the provided tools.
You are stepping over one very important point here: from what I have been experiencing is that Python library / component developers are not making their software backwards compatible with 'older' OS versions. They assume you always upgrade to the latest & greatest which just isn't going to work in an engineering environment. Updating a system with a bunch of software packages installed can easely take a fulltime week of work for preparation & execution and still runs the risk of breaking functionality. There really needs to be a good reason to invest that amount of time (return on investment)!
So Python developers can specify the dependancies of their software just fine but the Python libraries simply won't install. IMHO Python is a dead end where it comes to commercial / professional application development. Look at Kicad for example which no longer runs on Windows 7 because the newer Python libraries don't support Windows 7. I'm having similar issues when trying to run Python software on Linux. That is just stupid. In contrast: When I compile a C++ program that uses the WxWidgets framework, it will run on any Windows version from Windows 95 to Windows 10 (and likely Windows 11) without needing to install any external libraries. That makes life a whole lot easier for my customers.
-
To complain that an OS which has officially reached its End of Life isn't support by a language and furthermore the open source community driving it, is quite ridiculous to say the least.
There's nothing stopping you from finding older versions of python and 3rd party packages that work on the older and End of Life OS'es, the source code for real building the wheel or conda package isn't just disappearing.
It seems like you want the latest and greatest python but not the OS? Seems hypocritical. Is there not an older version of Kicad to be used that is Windows 7 compatible?
Lastly if you are sending out software to 3rd parties you are most likely going to compile the python into a .exe which will include all the necessary 3rd party libraries, etc. This may not work how I think it does, and it wont in fact run on a old OS (hence your Kicad example).
Regardless I really don't see the complaint here.
EDIT:
Seems like we're perfectly capable with literally compiling python to work different OSes
https://pyoxidizer.readthedocs.io/en/stable/pyoxidizer_comparisons.html
You just have to use the correct executable creating library and include the necessary DLLs.
https://stackoverflow.com/questions/14747788/py2app-compile-app-for-older-mac-versions
Put in an issue with Kicad, or build it yourself. https://github.com/KiCad
-
Regardless I really don't see the complaint here.
I guess you have never tried to actually use a computer then; otherwise you'd actually understand the problem. You completely missed / ignored the point about how difficult and time consuming it is in the real world to update a working system (with dozens of software packages installed) to a newer OS. On top of that, there is quite a bit of engineering software out there that doesn't work on newer OSses. Xilinx -for example- has taken a couple of years before they published a version of their ISE 14.7 software suite that can run on Windows 10.
-
To complain that an OS which has officially reached its End of Life isn't support by a language and furthermore the open source community driving it, is quite ridiculous to say the least.
Windows 7 ESU runs until January next year. Another fact is that a lot of special applications are running on older OS versions because of different reasons, such like certifications (e.g. medical imaging) or expensive legacy hardware (industrial or scientific stuff).
-
Linux does not stand a chance, especially not since the Lennart started to get his code in distributions.
But but but... Linux, and especially systemd, is free. Therefore, by your argument, systemd must be better.
You troll! :-DD
No, Price / Quality relationship is a quite non-linear equation. That is about as much as we can say.
Anyway, I just took a peek at some Python code (desperately trying to get back to topic.), this time for Home Assistant to check the ARP table in a router. My observations:
- Yes, the code is readable, but that is because all things that do something are strings for the interactive HMI (Human-Machine-Interface, the command line used to configure and troubleshoot the router) sent via a SSH connection emulation library. Basically a screen-scraper, the most fragile way of interprocess communication short of rumours.
- The approach chosen when fetching information is very simply put "monkey see, monkey do"; the code emulates what I'd do to go look manually. It is a cute but immature first step.
- The approach to adaptation to the network setup further is a very QnD one, no provision is made for anything beyond the most simple out-of-the-box, click-next-next-next-OK-reboot setup of a network. This is no fault of Python, it is the usual case of assumptions made to give impressions of Magic. Most common in IOT and media servers, but not unheard of in other auto-configuring software systems.
- The proper way to get the ARP table out of a network element when machine is talking to machine is either the classic SNMP or the more modern NetConf/YANG model.
- There are Python libs for this too, but they're not used. Probably too much understanding of problem required.
Fast and wrong, Internet of Shit style. Not impressed.
Simply because it is easy to write does not mean it is easy to get right.
I'm not really sure why you think this has anything to do with Python. Taking the 'wrong' high-level approach to the problem is a language-agnostic issue, and if anyone is to 'blame' for it, it's the software developer not the language developer.
Specifically though, Home Assistant as far as I know doesn't provide anything native to 'check the ARP table in a router', and I'm not quite sure what the use case for this would be in that application in the first place. So you're talking about some random dude's third-party addon to a piece of software that happens to be written in Python but is not associated with the Python team. It's also in the name - Home Assistant is for use in homes, and most home networking equipment doesn't implement SNMP, let alone netconf. Finally, HA does in fact include an SNMP poller in core.
I don't think this is a fair assessment.
-
I'm not really sure why you think this has anything to do with Python. Taking the 'wrong' high-level approach to the problem is a language-agnostic issue, and if anyone is to 'blame' for it, it's the software developer not the language developer.
Specifically though, Home Assistant as far as I know doesn't provide anything native to 'check the ARP table in a router', and I'm not quite sure what the use case for this would be in that application in the first place. So you're talking about some random dude's third-party addon to a piece of software that happens to be written in Python but is not associated with the Python team. It's also in the name - Home Assistant is for use in homes, and most home networking equipment doesn't implement SNMP, let alone netconf. Finally, HA does in fact include an SNMP poller in core.
I don't think this is a fair assessment.
Oh, there's some merit to the observation that bad coding will prevail regardless of language. Anything I write is testament to that.
OTOH, Python shows up a bit more often than others in those situations. I think we need to test this observation against time; for it is always so that the language du jour attracts morons.
On a side note; if there's a SNMP poller in HA, why oh why did they not use it?
-
the language du jour attracts morons.
True, because most human beings are morons in the first place. (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population. I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)
Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?
Or more generally, when looking at how programming languages are used and can be used – for example, to evaluate which language(s) one should consider for some particular project – should one consider all extant projects, or only a subset of projects? (Well, only a subset, obviously, as there is too much code available already for all of it to be considered; but which subset? Which subsets should obviously be discarded?) What metric to use for comparison?
This might be considered a philosophical question, but I don't want to touch those with a ten-foot pole excluding a match and some gasoline. Instead, I am interested in the purely practical aspect, say a software designer/architect with a new product as a goal. (One has to consider what kind of developers are available, what kind of skill levels the team can afford, and so on.) Or, say a hobbyist, considering which language to learn to create specific kinds of programs.
As I've ranted and explained sufficiently already, "popularity" is definitely not a metric I consider useful. Also, I don't think the worst examples should be considered at all. I think that it is important to consider only software that is widely used, or generally accepted as "acceptable quality".
-
OTOH, Python shows up a bit more often than others in those situations. I think we need to test this observation against time; for it is always so that the language du jour attracts morons.
I really think you need some sort of citation if you're going to make that claim. But it also stands to reason that the most popular language is also the most commonly misused, it will be the one that most beginners tend toward, and just by numbers will have the largest quantity of bad examples, and the most visibility. Some languages really do tend towards bad implementation because they make correct implementation hard (see PHP), but I would really take issue with claiming that of Python. The language is quite sane, doesn't really hinder good design, and doesn't provide an excessive amount of footguns.
I would also say that basically by definition, the most popular language can't be the 'language du jour' which implies relative newness, which isn't true of Python, it's been entrenched in its segment for a long time now. I'd say this applies more to Golang or Rust at this point.
On a side note; if there's a SNMP poller in HA, why oh why did they not use it?
Presumably the target device did not implement SNMP or they wanted to use an alternative method for some reason (more functionality? a device-specific alternative to the universal SNMP?). Assuming you want to do presence detection, it's built-in, just point it at the ARP OID: https://www.home-assistant.io/integrations/snmp/#precense-detection (https://www.home-assistant.io/integrations/snmp/#precense-detection) . I do find with HA that finding the best integration for a given task is not always trivial...
-
the language du jour attracts morons.
True, because most human beings are morons in the first place. (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population. I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)
Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?
I don't think so. I've seen poor programming in every language I have come across.
-
On a side note; if there's a SNMP poller in HA, why oh why did they not use it?
Presumably the target device did not implement SNMP or they wanted to use an alternative method for some reason (more functionality? a device-specific alternative to the universal SNMP?). Assuming you want to do presence detection, it's built-in, just point it at the ARP OID: https://www.home-assistant.io/integrations/snmp/#precense-detection (https://www.home-assistant.io/integrations/snmp/#precense-detection) . I do find with HA that finding the best integration for a given task is not always trivial...
Indeed.
My only gripe is this
https://www.youtube.com/watch?v=YnL9vAFphmE (https://www.youtube.com/watch?v=YnL9vAFphmE)
...more specifically when he puts a ruler up against the screen. I hate the lack of proper structure. Programming languages that distinguish between space and tab need to be taken out and shot.
-
Looking at that table and keyboard tells me he isn't a software developer, more likely a marketing guy.
-
.
-
the language du jour attracts morons.
True, because most human beings are morons in the first place. (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population. I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)
Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?
I don't think so. I've seen poor programming in every language I have come across.
I agree.
For example, I don't think PHP is a "bad language" because there is so much insecure and inefficient PHP code out there; I think it is a "bad language" because it is quite difficult to write robust, reliable, secure, and maintainable PHP code. I've been paid to do that in the past. It feels like fighting against the language, not with the language.
I wonder if a programming language based upon repetition, habit, instincts and emotions can be devised so to enable morons to do fruitful work.
I do not believe so, because habit, instincts and emotions are easy to model and automate.
Consider, for example, human traffic behaviour. While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models. This means that rather than hiring morons as traffic directors, we are better off using sensible algorithms in traffic lights instead.
What we can do, is make any new programming language intuitive. This involves having a consistent "world view" towards programming problems and situations, a paradigm if you will, that a human can adopt. Then, the programmer (language user) will approach problems and solutions the same way the language designer did, and intuitively find the tools, without knowing those tools beforehand. (Because a single paradigm will never be the best one for all problems, we'll always need more than one programming language.) In simple terms, assuming a good paradigm, such a programming language makes it easy to write robust, efficient, maintainable code.
(I for one really like the Python pydoc interface, which examines the code itself and documentation strings (comments) in it, to produce an useful synopsis of the classes and interfaces the code implements. It does not replace proper documentation, but it does make it easy to check things. With minimum effort, you can get most of the documentation done.)
I don't think there is much use for morons outside the human-interface (service) industry in any post-industrial societies, I'm afraid.
-
the language du jour attracts morons.
True, because most human beings are morons in the first place. (In the olden days 'moron' had a specific meaning, which only applied to about 2% of the population. I define the term as "unable, unwilling, or reluctant to apply logical or rational thinking in ordinary everyday situations, and relying on repetition, habit, instincts, or emotions instead".)
Which leads to a genuine question: should we even consider the moron-written code when comparing practical uses of programming languages?
I don't think so. I've seen poor programming in every language I have come across.
Exactly. Every Turing-complete language is also necessarily Turd-complete
-
Consider, for example, human traffic behaviour. While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models. This means that rather than hiring morons as traffic directors, we are better off using sensible algorithms in traffic lights instead.
I my experience, instead, they hire morons to write cretinous algorithms..
-
Consider, for example, human traffic behaviour. While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models. This means that rather than hiring morons as traffic directors, we are better off using sensible algorithms in traffic lights instead.
I my experience, instead, they hire morons to write cretinous algorithms..
Sure, but that's a management problem. As in, those who hire morons are themselves even worse morons. (Usually very happy to waste other peoples' money, too.)
-
from what I have been experiencing is that Python library / component developers are not making their software backwards compatible with 'older' OS versions. They assume you always upgrade to the latest & greatest which just isn't going to work in an engineering environment. Updating a system with a bunch of software packages installed can easily take a full-time week of work for preparation & execution and still runs the risk of breaking functionality.
Yes, this is exactly * THE * problem I have with Gentoo / Linux where the package manager (emerge + portage) is written in Python, and stops at * EVERY * major update.
This is also the reason why Python-update-xxx and Python-fix-xxx were developed. But they do not prevent anything, they simply try to repair the damage and are not always successful.
On Catalyst where you build a stage3 from source, Python is so problematic that it always takes a couple of weeks of full-time work to avoid future disasters.
-
While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.
Kind of. There have been instances where traffic flow has improved when lights at a junction are out of commission, and one place in London (I think) improved 'traffic calming' measures by removing all lights and road markings. It would be interesting to know if those situations were modelled or if no-one thought they might achieve anything so were never examined. If they were modelled then either someone has an axe to grind or the models were crap :)
-
While it is very difficult to predict what a single driver might do at any point in time, we can model traffic (be it automobiles, or even pedestrians) very accurately, with high predictive power, with rather simple models.
Kind of. There have been instances where traffic flow has improved when lights at a junction are out of commission, and one place in London (I think) improved 'traffic calming' measures by removing all lights and road markings. It would be interesting to know if those situations were modelled or if no-one thought they might achieve anything so were never examined. If they were modelled then either someone has an axe to grind or the models were crap :)
As far as I understand, they are rarely modelled fairly. Typically, there is a mid-level boss that forces the designers to do silly choices, like ensuring a specific street has a green flow, even if it means severe congestion elsewhere, since that happens to be the street that boss uses to commute. The rest of the system is worked around such arbitrary priority assignments.
Only when the traffic patterns become so congested the municipal/city politicians/paper-pushers start worrying about losing their jobs because of it, are the actual known models applied with inputs/parameters based on actual real-world data without such "tweaking". Then, you also see things like multi-lane junctions converted to roundabouts. (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint, and reduce the number of accidents compared to junctions (https://en.wikipedia.org/wiki/Roundabout#Safety).) This is why I wrote can be modelled, and not are modelled.
When people talk about "algorithms" –– especially so when it is about social media filtering ––, what they actually usually mean is "algorithms that have been perverted by humans arbitrarily tweaking the control parameters to achieve arbitrary personally-preferred results". Never forget this.
The place where I learned to understand this, was in materials physics and chemistry simulations, using "classical" (non-quantum-mechanical) potentials and force field models. You see, you can define a form for such a potential or force field based on atom properties, and then fit the parameters to achieve desired bulk or surface properties (matching actual physical measurements). It is typical to consider a model that gives good surface (or bulk) properties, while the bulk (or surface) properties are off by an order of magnitude, "pretty good".
All practical algorithms have such tunables. For traffic control, there are many; the estimated traffic density being the most important one. You only need to tweak those a little bit to get exactly the effects you want. Since the models are run in simulations, the effects of small tweaks can be experimented on, until one gets the results one wants. If you think it is in traffic designers' best interests to optimize the overall pattern and ignore the personal preferences of the people who evaluate their work and pay their wages, you are woefully naïve.
And that is what is wrong in today's world, where both the algorithms and the parameters supplied to them are secret: those who apply them (and very often having tweaked the parameters from the actual existing data to skew the end result to something they want) can lie to people and say that "it wasn't me; it's just the algorithm :-//".
Remember: the output of basically all models and algorithms is dictated by its inputs (tunable parameters). To get good results, those inputs must be chosen fairly, too.
-
This should explain why GPUs are so weird with PCIe and none of them(1) is made with a clean design :o :o :o
(1) Radeon { 5450, 6450, 7470, RX 6700 XT }
-
This is why I wrote can be modelled, and not are modelled.
OK :)
-
Then, you also see things like multi-lane junctions converted to roundabouts. (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint
Love roundabouts. They are everywhere here in New Zealand, from ones barely bigger than a dinner plate in suburbs (SO MUCH better than #$%^ 4-way stop signs) to one big enough to put an international-quality cricket ground in the middle of it.
Roundabouts give very low latency when traffic is light, but scale to pretty high traffic levels too.
Here's one near where I used to live in Wellington (viewed from a McDonalds):
https://www.youtube.com/watch?v=eiOOTo11G9I (https://www.youtube.com/watch?v=eiOOTo11G9I)
-
Maybe I was too ranty above. My point is, we do have good models and algorithms, but they do need to be set up with proper fair inputs and parameters to produce fair results. Currently, especially in social media, people seem to accept the insane notion that it is the algorithm that makes decisions; that's not true. It is the humans that set up the algorithms and their inputs. Even fuzzy logic and expert systems ("AI", neural networks) that are trained with input; selecting the training input is what determines the outcome.
Circling back to programming languages' "quality": just like we cannot qualify algorithms based on results with skewed inputs and parameters, we cannot evaluate languages based on worst examples.
Instead, we do need to look at what is possible. However, we cannot only look at the best examples, because that would be like qualifying algorithms and models based on results that are due to excellent inputs and parameters –– perhaps due to luck; with programming languages, perhaps due to extreme effort!
Because so many of us are morons –– I'm not even sure whether I'm a moron myself; I certainly seem to act so at times >:( (using my own definition above) ––, I claim we need to look at how easy or how hard it is to write robust, maintainable, and relatively efficient code.
I do not believe a programming language should attempt to stop morons from writing horrible code; I'd be perfectly happy if it only made that harder than writing sensible code. Help and hint, perhaps even guide; but not enforce.
So, let's circle back to Python in particular.
I've described my own opinion already in this thread, but to summarize, even though it has its downsides (version incompatibility from 2 to 3, slow I/O due to treating "strings" differently than "bytes", structural whitespace, and so on), I feel I can work with it just fine. I do not need to fight against it. It is certainly easier to write robust web service or backend code in Python than it is in PHP. Many of the reasons I use Python and not better existing languages is that in the cases where I need an interpreted language like Python, those other languages have unrelated practical side issues – like not being as easily available, perhaps not being available at all (say, most web hosting services).
Thus, the reason I feel I can work with it just fine has at least as much to do with how the interpreter is packaged and available, its configuration (minimal, compared to e.g. PHP), and other such features, than it has to do with the programming language itself.
-
Then, you also see things like multi-lane junctions converted to roundabouts. (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint
Love roundabouts. They are everywhere here in New Zealand, from ones barely bigger than a dinner plate in suburbs (SO MUCH better than #$%^ 4-way stop signs) to one big enough to put an international-quality cricket ground in the middle of it.
Roundabouts give very low latency when traffic is light, but scale to pretty high traffic levels too.
The biggest problem I have with roundabouts is that a fair share of drivers has what I call 'roundabout anxiety' and those drivers severly hamper traffic flow.
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France. And ofcourse there is the one where the Arc du Triomphe sits in the middle.
-
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.
Ha! They've got nothing on us Brits, towhit the infamous "magic roundabout" in Hemel Hempstead:
(https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.ytimg.com%2Fvi%2FNHVF1rnUKHw%2Fmaxresdefault.jpg&f=1&nofb=1)
I used to work in Hemel Hempstead and the roundabout is in fact much easier to negotiate from a driver's view than it looks to be from an aerial view.
Swindon has one too:
(https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Falchetron.com%2Fcdn%2Fmagic-roundabout-hemel-hempstead-ba1a2f1e-09f3-485a-9447-e44bd5b0711-resize-750.jpeg&f=1&nofb=1)
-
The biggest problem I have with roundabouts is that a fair share of drivers has what I call 'roundabout anxiety' and those drivers severly hamper traffic flow.
Yeah, I have witnessed senile drivers get completely mentally stuck in a roundabout, suddenly braking to a complete stop to "give way" for someone entering the roundabout, has happened more than once. This is of course because roundabouts were nonexistent when they learnt driving, and old people tend to revert back to what they learned when still young. This problem fixes itself with time, though.
-
Then, you also see things like multi-lane junctions converted to roundabouts. (Love or hate modern roundabouts, they are proven to increase traffic flow in the same footprint
Love roundabouts. They are everywhere here in New Zealand, from ones barely bigger than a dinner plate in suburbs (SO MUCH better than #$%^ 4-way stop signs) to one big enough to put an international-quality cricket ground in the middle of it.
Roundabouts give very low latency when traffic is light, but scale to pretty high traffic levels too.
The biggest problem I have with roundabouts is that a fair share of drivers has what I call 'roundabout anxiety' and those drivers severly hamper traffic flow.
These happen, but a lot less frequently in places where roundabouts are common. You can see a few of those in the video I posted.
You do need to have confidence in getting off the mark and accelerating quickly to roundabout speed (typically 15-30 km/h, 10-20 mph) and into the gap you just spotted. Completely doable with a small engine and manual transmission (1st will be fast enough), but easier for sure with a bigger engine and/or automatic.
You also need to trust in only having to look for traffic on the right (on the left in USA/Europe) -- and also of course that traffic in front of you isn't stopped. Still, much much easier than trying to get onto a busy road from a side road or driveway and spot gaps arriving from both left and right at the same time.
-
... I have witnessed senile drivers get completely mentally stuck in a roundabout, suddenly braking to a complete stop to "give way" for someone entering the roundabout, has happened more than once....
For some German roundabouts – specifically, any that do not have yield signs at the entrances – you are supposed to yield in the roundabout. A local supermarket has such an unsigned roundabout in their parking lot and not everyone remembers the law, still, is yield to the right.
Roundabouts are more naturally suited to driving on the left side of road.
-
For some German roundabouts – specifically, any that do not have yield signs at the entrances – you are supposed to yield in the roundabout.
In roundabouts in Vanuatu vehicles in the roundabout have to give way to vehicles entering the roundabout. This seems exceptionally weird.
Roundabouts are more naturally suited to driving on the left side of road.
I don't understand that. If all rules are mirror-imaged then everything works exactly as well (or not).
-
You also need to trust in only having to look for traffic on the right (on the left in USA/Europe) -- and also of course that traffic in front of you isn't stopped. Still, much much easier than trying to get onto a busy road from a side road or driveway and spot gaps arriving from both left and right at the same time.
That "trust" can be a pitfall, you can't trust other people to be following the rules, as this little video demonstrates:
https://www.youtube.com/watch?v=D3ZZnpcibDc (https://www.youtube.com/watch?v=D3ZZnpcibDc)
Although that's an extreme example it's illustrative of a common problem, if you're not prepared for people making poor emerges in front of you, and prepared to hold back if necessary to avoid them, you'll have issues. However, if you pick the correct lane, take good observations on your approach, adjust your speed to fit into oncoming gaps on the roundabout where possible, and remain prepared to deal with people with poor emerge and lane skills while on the roundabout, you can flow over roundabouts and never stop moving; they are in fact easier than junctions and keep the traffic flowing better once you've got the correct technique.
-
I've had something like that happen to me.
I was also on a motorcycle, on a multiple lane roundabout. I was already on the roundabout, in the innermost lane, when a car came around the corner in my lane going the wrong way. I was leaned well over and going ... probably above the speed limit. Somehow I managed to jump a pretty substantial kerb onto a footpath in the center of the roundabout. Not even quite sure how I did that. I think I fundamentally managed to pretty much stop but it was apparent that the car wasn't going to, so I got out of its way.
-
... I have witnessed senile drivers get completely mentally stuck in a roundabout, suddenly braking to a complete stop to "give way" for someone entering the roundabout, has happened more than once....
For some German roundabouts – specifically, any that do not have yield signs at the entrances – you are supposed to yield in the roundabout. A local supermarket has such an unsigned roundabout in their parking lot and not everyone remembers the law, still, is yield to the right.
That is a problem with roundabouts indeed. At the basis a roundabout is a one way street laid out in a circle and who needs to give way is up to who designs the roundabout but without signage, the basic traffic rules apply. But there are a lot of roundabouts that overrule that so you need to keep your eyes open for the signage.
BTW: In the NL you can also encounter roudabouts which have a bi-directional cycling lane around them to make matters more interesting.
Roundabouts are more naturally suited to driving on the left side of road.
That is nonsense; it doesn't matter. Whether clockwise or counter-clockwise, driving in a circle is the same.
You also need to trust in only having to look for traffic on the right (on the left in USA/Europe) -- and also of course that traffic in front of you isn't stopped. Still, much much easier than trying to get onto a busy road from a side road or driveway and spot gaps arriving from both left and right at the same time.
That "trust" can be a pitfall, you can't trust other people to be following the rules, as this little video demonstrates:
Although that's an extreme example it's illustrative of a common problem, if you're not prepared for people making poor emerges in front of you, and prepared to hold back if necessary to avoid them, you'll have issues.
That is very true. Participating in traffic means being able to deal well with mistakes that other people make and hope other people can correct for the mistakes you make. Never think you have seen all the weird crap that can happen in traffic; there are always people creative enough to surprise you.
-
Thus: As a traffic planner, how much weight would you place on public preference versus traffic flow and accidents, when designing new roads and intersections?
I think it is well known that humans overall are creatures of habit and such, and not very rational or logical in their personal preferences.
Which, in my understanding, means that "popularity" is only useful metric for entertainment and such, not for important stuff like traffic and programming languages.
-
I can speak to British traffic planners following "received wisdom" rather than common sense. It is an article of faith for British traffic planners that if you deliberately reduce visibility at the approach to a hazard drivers will both be more cautious and reduce their speeds on approach. Five minutes spent observing in the real world would show anyone that this is not true. So we get junctions engineered to be, in fact, less safe in the name of making them more safe. I guess the programming language designer's version of this is to reduce the incidence of type errors by doing away with types.
-
In Finland, all politics is data-driven. As in, if statistics or gathered data shows that a political decision was less than desirable, the data gathering will be immediately stopped and statistics un-gathered. If a third party later shows that the decision was less than desirable, it is straightforward and effective to claim that "nobody could have predicted this", because those who did predict it, had been labeled "conspiracy theorists" and "foil hatters" already.
The most free news in the world, indeed: we're just the best closing our eyes from observable facts.
This is to say, human idiocy is infinite, and rational and logical thought requires effort. Even when a logical, rational, proven better options exist, it is usually still an uphill battle to try and change the inertia of past decisions and established social "norms": this is what it is to be human.
I do find it interesting (and somewhat disconcerting) how many of the "best" software projects are driven by benevolent dictators, instead of any kind of democratic processes. There are enough important counterexamples (C, Debian, Apache) that I don't think it is anything inherent, but more a combination of issues we haven't dealt with yet.
Considering all that, I'm not sure how I feel about "Python becoming the most popular language". There is something definitely sinister in that to me, even though I write Python code very often; if not daily, nearly so anyway.
-
In Finland, all politics is data-driven. As in, if statistics or gathered data shows that a political decision was less than desirable, the data gathering will be immediately stopped and statistics un-gathered.
So, uh... data-driven backwards. :-DD
It's not much better elsewhere...
Considering all that, I'm not sure how I feel about "Python becoming the most popular language". There is something definitely sinister in that to me, even though I write Python code very often; if not daily, nearly so anyway.
Fortunately for me, I don't use Python. But I find the trend sinister as well.
But it's somewhat as sinister as the trend that is making machine learning the alpha and omega of computing these days, as though there was nothing else anymore, no other approach worth mentioning, and no problem that couldn't be solved with it.
But is it all a sign of human "idiocy", or ultimately just a sign of greed?
-
I don't find it sinister that a particular language is the most popular. In fact it is inevitable, some language MUST be the first in popularity. Until recently it was C and Java. Now it's Python.
Given that I particularly like the Python language, I think this popularity is an advantage and can be used to improve its libraries, frameworks and other tools.
As for changes in the language itself, I also miss less version changes in the Python language. C has very few changes and you can program today perfectly well in the C99 standard of 23 years ago and there is nothing wrong with that.
-
But it's somewhat as sinister as the trend that is making machine learning the alpha and omega of computing these days, as though there was nothing else anymore, no other approach worth mentioning, and no problem that couldn't be solved with it.
The worst thing about the current "ML" fad is that it is totally infeasible to understand why the computer came up with any particular answer. The algorithm was not designed by anyone, it was "trained" until it seemed to work.
"Computer says 'NO'" becomes totally unassailable.
I guess some regard this as the best thing about it.
-
As for changes in the language itself, I also miss less version changes in the Python language. C has very few changes and you can program today perfectly well in the C99 standard of 23 years ago and there is nothing wrong with that.
Maybe that is what is keeping C alive for all this time. PHP is also a language that severly breaks backwards compatibility with new versions. I get the reasoning (must be suitable for idiots to make safe web applications) but it would be so much nicer if it was possible to keep existing code running. More professional languages like C, VHDL, Verilog, etc have the possibility to tell the compiler which language version to use so old code can still be compiled succesfully.
-
In fact it is inevitable, some language MUST be the first in popularity. Until recently it was C and Java. Now it's Python.
FWIW the most popular video on YouTube is Baby Shark Dance. Go figure. ;)
-
In fact it is inevitable, some language MUST be the first in popularity. Until recently it was C and Java. Now it's Python.
FWIW the most popular video on YouTube is Baby Shark Dance. Go figure. ;)
;D
Evaluation of popularity is ridden with pitfalls and biases anyway. But behind the popularity index, there's a very real fact: there's an increasing number of "developers" knowing Python on the market, and an alarmingly decreasing number of developers knowing other languages, so for any work for which Python is not appropriate (and yes, there's still a lot of stuff that can't be done with Python, despite what some would like to think), good luck finding candidates these days...
-
In the end it doesn't matter whether a language is the most popular or is actually in second or third place.
What is important in this case is the undisputed rise in popularity of Python (an interpreted language) to the top ranks of popularity.
The fact that Python is slower than other languages is another reason that makes its rise in popularity even more surprising.
In fact, I believe that if it had not been Python it would have been another interpreted language that would have reached the top positions. And that's a major change in the way software is developed.
The advantages of interpreted software make it much more effective in some cases. Web development is one such paradigmatic case.
-
https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages
at Stack Overflow joins programming languages with markup languages such as HTML and the popularity of the different languages looks like this:
-
You also need to trust in only having to look for traffic on the right (on the left in USA/Europe) -- and also of course that traffic in front of you isn't stopped. Still, much much easier than trying to get onto a busy road from a side road or driveway and spot gaps arriving from both left and right at the same time.
That "trust" can be a pitfall, you can't trust other people to be following the rules, as this little video demonstrates:
I said this before, and I say it again:
If someone decides to buy a Peugeot, you take their drivers license and throw it in the shredder. They are clearly not interested in cars, driving, safety or reliability, and they lack common sense and shouldn't be allowed on the road.
-
I say this once, and once only.
If someone decides to use Windows and pay Microsoft for a license, you need to crush their fingers so that they won't be able to touch any computer, ever.
That decision shows they are not interested in the long-term interests of the human race, and instead are driven by instinct, habit, social pressure, and advertisements only.
See, how superlative language becomes horrible, when you switch things you don't like with things you do like? Food for thought, innit.
-
The advantages of interpreted software
What do you see those as? To me, a major issue is that the first time to code gets to be parsed is when it's about to be run for real. With compiled languages, the code may be crap but all of it has to compile before you can run it.
-
If someone decides to buy a Peugeot, you take their drivers license and throw it in the shredder. They are clearly not interested in cars, driving, safety or reliability, and they lack common sense and shouldn't be allowed on the road.
Got any other brand opinions?
I endorse the contents of this video, even if (as I do) you live in a slightly different country to JOhn (and eevblog): https://www.youtube.com/watch?v=tHdZMQnq9xE (https://www.youtube.com/watch?v=tHdZMQnq9xE)
-
I say this once, and once only.
If someone decides to use Windows and pay Microsoft for a license, you need to crush their fingers so that they won't be able to touch any computer, ever.
That decision shows they are not interested in the long-term interests of the human race, and instead are driven by instinct, habit, social pressure, and advertisements only.
See, how superlative language becomes horrible, when you switch things you don't like with things you do like? Food for thought, innit.
Nah, what you are saying is bullshit.
-
The advantages of interpreted software
What do you see those as? To me, a major issue is that the first time to code gets to be parsed is when it's about to be run for real. With compiled languages, the code may be crap but all of it has to compile before you can run it.
For me, the main advantage of interpreted languages is their speed of development. You can make changes and test them immediately, without waiting for the compilation to complete.
Also you can run command line commands to test how the program works without the need for compilations.
In the microcontroller realm, in addition to having to wait for the compilation to complete you have the problem of having to load the compiled hexadecimal into the micro. When you want to make small changes and test immediately that causes quite a time expenditure. With an interpreted language like LUA, Basic or FORTH, command line testing is immediate.
Once you have tested the algorithm and when you see that it works well, you can transfer it to C language, which is faster in execution.
-
What is important in this case is the undisputed rise in popularity of Python (an interpreted language) to the top ranks of popularity.
The fact that Python is slower than other languages is another reason that makes its rise in popularity even more surprising.
I'm not surprised. It's way many humans tick. And at the same time many of the developers coding in Python support a green future. ;D
The advantages of interpreted software make it much more effective in some cases. Web development is one such paradigmatic case.
They are great for automation and one-off tasks. But if you need to scale up things for many users or tons of data they suck badly because of their poor performance.
-
They are great for automation and one-off tasks. But if you need to scale up things for many users or tons of data they suck badly because of their poor performance.
Although performance can be an issue, the suckiest thing (if there is such a word) in that context is usually maintainability. Scripting friendly languages tend to attract coders and coding styles that are poor in maintainability terms. This has been true of 95% of "other people's code" that I've had to deal with over the years that has been written in one of the scripting friendly languages whereas it's probably only 70% for 'mainstream' programming languages.
-
I said this before, and I say it again:
If someone decides to buy a Peugeot, you take their drivers license and throw it in the shredder. They are clearly not interested in cars, driving, safety or reliability, and they lack common sense and shouldn't be allowed on the road.
It's interesting how culturally dependent such ideas are; here, no one would ever label a Peugeot driver like that. In fact, I'd say getting a Peugeot would be the most neutral action imaginable, communicating boringly modest amount of interest in cars, driving, safety, reliability, and common sense.
Here, the symbol for not being able to drive at all, and not having any interest in fixing that, seems to be a Nissan Qashqai, specifically white color. And then, I'm sure this doesn't apply where you live, at all, so I don't make a post like yours about it.
-
Here, the symbol for not being able to drive at all, and not having any interest in fixing that, seems to be a Nissan Qashqai, specifically white color. And then, I'm sure this doesn't apply where you live, at all, so I don't make a post like yours about it.
Here, in Brit land, those always make me laugh. There is a certain upper class British accent that mangles the pronunciation of quite common words - "trousers" becomes "tryzzers", "fine" becomes "fyne" and so on. One word which will be important shortly is "cow", pronounced "kai" by this type. The sons and daughters of that class often end up in "bullshit jobs" such as Marketing and PR. The Qashqai not only would be promoted professionally by the sort I'm talking about, but also they seem to be the target market.
When ever I see a Qashqai I think of the way that the kind of accent I've mentioned would mangle the pronunciation of the words "cash cow", which is an English idiom for a product that just keeps the money rolling in (cf German Milch Cow). I can hear one of the upper class muppets gushing in a marketing meeting they're having to decide the name for the car: "O Giles, I love it! It'll be an absolute cash kai!", "Oh, how spiffing, let's call it the Cash Kai. We'll have to change the spelling to get a trademark. How about usings Qs?". It's either that, or someone with a normal English accent mocking the people who are the target market for the vehicle.
-
Nah, what you are saying is bullshit.
Because it was just a reflection what you said, you mean, what you yourself wrote is bullshit? Weird, but I guess I have to agree with you there.
-
Nah, what you are saying is bullshit.
Because it was just a reflection what you said, you mean, what you yourself wrote is bullshit? Weird, but I guess I have to agree with you there.
Well, buying a car from a French (or Italian) brand is asking for trouble >:D
-
I say this once, and once only.
If someone decides to use Windows and pay Microsoft for a license, you need to crush their fingers so that they won't be able to touch any computer, ever.
That decision shows they are not interested in the long-term interests of the human race, and instead are driven by instinct, habit, social pressure, and advertisements only.
See, how superlative language becomes horrible, when you switch things you don't like with things you do like? Food for thought, innit.
Nah, what you are saying is bullshit.
So then you do understand!
-
Nah, what you are saying is bullshit.
Because it was just a reflection what you said, you mean, what you yourself wrote is bullshit? Weird, but I guess I have to agree with you there.
Nah, yours is just baseless fanboy-ism. Its also quite juvenile.
-
I said this before, and I say it again:
If someone decides to buy a Peugeot, you take their drivers license and throw it in the shredder. They are clearly not interested in cars, driving, safety or reliability, and they lack common sense and shouldn't be allowed on the road.
It's interesting how culturally dependent such ideas are; here, no one would ever label a Peugeot driver like that. In fact, I'd say getting a Peugeot would be the most neutral action imaginable, communicating boringly modest amount of interest in cars, driving, safety, reliability, and common sense.
Here, the symbol for not being able to drive at all, and not having any interest in fixing that, seems to be a Nissan Qashqai, specifically white color. And then, I'm sure this doesn't apply where you live, at all, so I don't make a post like yours about it.
It's universal:
https://www.youtube.com/watch?v=9TnGjq9mWSI (https://www.youtube.com/watch?v=9TnGjq9mWSI)
BTW they have the same shitbox in the video than the roundabout guy.
-
I said this before, and I say it again:
If someone decides to buy a Peugeot, you take their drivers license and throw it in the shredder. They are clearly not interested in cars, driving, safety or reliability, and they lack common sense and shouldn't be allowed on the road.
It's interesting how culturally dependent such ideas are; here, no one would ever label a Peugeot driver like that. In fact, I'd say getting a Peugeot would be the most neutral action imaginable, communicating boringly modest amount of interest in cars, driving, safety, reliability, and common sense.
Here, the symbol for not being able to drive at all, and not having any interest in fixing that, seems to be a Nissan Qashqai, specifically white color. And then, I'm sure this doesn't apply where you live, at all, so I don't make a post like yours about it.
It's universal:
https://www.youtube.com/watch?v=9TnGjq9mWSI (https://www.youtube.com/watch?v=9TnGjq9mWSI)
BTW they have the same shitbox in the video than the roundabout guy.
Your evidence against the Peugeot is a Top Gear segment, not a show to be taken seriously or they'd have had Leonard JK Setright hosting instead of Jeremy "Double Denim" Clarkson, and your powers of observation extend to labelling the woman driving a Peugeot as a man. Hmm, not wholly convincing...
-
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.
Oh really. I don't think I've ever seen any. Could you please show us pictures, as you apparently know France better than I do.
Or maybe you want to tell us what you mean by "shaped like the Audi logo", because to me this logo is four intertwined rings, and I can't fathom how a roundabout shaped like this would be like.
And ofcourse there is the one where the Arc du Triomphe sits in the middle.
This is a very large roundabout and rather tricky at peak hours when you're not used to it (first time I took it was a bit scary). But I don't know how else this could have been done over there without butchering the whole area.
Roundabouts are a nice way of making intersections much safer without the need to add traffic lights where they would make traffic much less fluid.
But I still don't know what this all has to do with Python.
-
Roundabouts are a nice way of making intersections much safer ... but I still don't know what this all has to do with Python.
That is left as an exercise for the reader?
-
Your evidence against the Peugeot is a Top Gear segment, not a show to be taken seriously or they'd have had Leonard JK Setright hosting instead of Jeremy "Double Denim" Clarkson, and your powers of observation extend to labelling the woman driving a Peugeot as a man. Hmm, not wholly convincing...
I'm sorry, but the amount of boneheaded, plain wrong opinionated comments in this thread, I thought everyone was expecting this.
Seriously, I haven't read a single comment for four pages which would be about python, and before that, it was "I have a lot of free time, so let's shit on python together, because it must be bad, even though I don't use it."
-
Your evidence against the Peugeot is a Top Gear segment, not a show to be taken seriously or they'd have had Leonard JK Setright hosting instead of Jeremy "Double Denim" Clarkson
While I have read many fine car and motorcycle reviews from LJK, there is one minor obstacle to having him host a TV show...
"‘Often perplexing and too often dangerous,’ was how I judged most French cars other than Citroen’s in the 1960s and early ‘70s but I was so pleasantly surprised as to be almost enchanted by the Peugeot 305 I also developed a soft spot for the Peugeot 505, which was never known at its best in Britain because its best variant, powered by the lightweight V6 Douvrin engine, was never imported."
-
Roundabouts are a nice way of making intersections much safer without the need to add traffic lights where they would make traffic much less fluid.
We have roundabouts with traffic lights :-//
-
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.
Oh really. I don't think I've ever seen any. Could you please show us pictures, as you apparently know France better than I do.
Or maybe you want to tell us what you mean by "shaped like the Audi logo", because to me this logo is four intertwined rings, and I can't fathom how a roundabout shaped like this would be like.
From the top of my head: Nantes on some entry road where Google maps takes us. But I've seen them in other places as well in France but don't ask where precisely; it is very possible I move through France more than you do and I can't remember all the roads I travel on ;D
-
Your evidence against the Peugeot is a Top Gear segment, not a show to be taken seriously or they'd have had Leonard JK Setright hosting instead of Jeremy "Double Denim" Clarkson
While I have read many fine car and motorcycle reviews from LJK, there is one minor obstacle to having him host a TV show...
Top Gear has been around a long time and Clarkson was one of the presenters as far back as 1988. Setright didn't take his current job of full time daisy pusher-upper until 2005, so there's every possibility that he could have had the job, but the idea that the BBC might employ a Top Gear presenter with actual in-depth knowledge and a sense of humour that tended towards 'brut' rather than a clown is clearly farcical.
-
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.
Ha! They've got nothing on us Brits, towhit the infamous "magic roundabout" in Hemel Hempstead:
https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.ytimg.com%2Fvi%2FNHVF1rnUKHw%2Fmaxresdefault.jpg&f=1&nofb=1
I used to work in Hemel Hempstead and the roundabout is in fact much easier to negotiate from a driver's view than it looks to be from an aerial view.
Swindon has one too:
https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Falchetron.com%2Fcdn%2Fmagic-roundabout-hemel-hempstead-ba1a2f1e-09f3-485a-9447-e44bd5b0711-resize-750.jpeg&f=1&nofb=1
There's one of those outside Heathrow, too:
(https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fblog.passmefast.co.uk%2Fimages%2Fhatton-cross-magic-roundabout.jpg&f=1&nofb=1)
I was not amused.
-
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.
Oh really. I don't think I've ever seen any. Could you please show us pictures, as you apparently know France better than I do.
Or maybe you want to tell us what you mean by "shaped like the Audi logo", because to me this logo is four intertwined rings, and I can't fathom how a roundabout shaped like this would be like.
From the top of my head: Nantes on some entry road where Google maps takes us. But I've seen them in other places as well in France but don't ask where precisely; it is very possible I move through France more than you do and I can't remember all the roads I travel on ;D
If it's on Google maps, surely you can post a google map picture of it then?
-
The French are very creative; you can find a fair amount of roundabouts that are shaped like the Audi logo in France.
Oh really. I don't think I've ever seen any. Could you please show us pictures, as you apparently know France better than I do.
Or maybe you want to tell us what you mean by "shaped like the Audi logo", because to me this logo is four intertwined rings, and I can't fathom how a roundabout shaped like this would be like.
From the top of my head: Nantes on some entry road where Google maps takes us. But I've seen them in other places as well in France but don't ask where precisely; it is very possible I move through France more than you do and I can't remember all the roads I travel on ;D
If it's on Google maps, surely you can post a google map picture of it then?
Any quick glance across that area shows they are very liberal with roundabouts and have no issues with joining them directly together:
https://goo.gl/maps/AgZVfnybpzgriDx19
(bonus crossover!)
The highways are also using roundabouts for their interchanges, sometimes incorporating cloverleaves with roundabout. So quite unusual, but still no overlapping roundabout.
We have roundabouts with traffic lights :-//
2 overlapped roundabouts with traffic lights, branching trams, 4 traffic lanes + bicycle lane:
https://goo.gl/maps/8hs7N1A7rEvPek9Z8
Wikipedia is a little out of date with its map: https://en.wikipedia.org/wiki/Haymarket_roundabout
-
Well, sure there are many roundabouts. But I can't see any Audi logo. Maybe some weed would help seeing that, though. =)
Otherwise, I fail to see what would be weird about that, if you have a complex area with many intersections, you're bound to have roundabouts leading to other roundabouts.
The one type of roundabout that I don't like, and that are fortunately rare, are the oblong ones. Sometimes used when there are two intersections, too close to one another to put two separate roundabouts. Those are very annoying. Rare though.
-
Your evidence against the Peugeot is a Top Gear segment, not a show to be taken seriously or they'd have had Leonard JK Setright hosting instead of Jeremy "Double Denim" Clarkson
While I have read many fine car and motorcycle reviews from LJK, there is one minor obstacle to having him host a TV show...
Top Gear has been around a long time and Clarkson was one of the presenters as far back as 1988. Setright didn't take his current job of full time daisy pusher-upper until 2005, so there's every possibility that he could have had the job, but the idea that the BBC might employ a Top Gear presenter with actual in-depth knowledge and a sense of humour that tended towards 'brut' rather than a clown is clearly farcical.
If, for one, don't mind Chris Harris. Viki and Tiff were also rather good in the 1987-2001 time frame.
-
Nah, what you are saying is bullshit.
Because it was just a reflection what you said, you mean, what you yourself wrote is bullshit? Weird, but I guess I have to agree with you there.
Nah, yours is just baseless fanboy-ism. Its also quite juvenile.
"When caught spewing bullshit, just attack the person who pointed it out."
In case you didn't catch it, I neither believe owning a Peugeot to be a sign of a bad driver, nor do I think there is anything wrong in using Windows.
(Don't let Tux fool ya. It's my mascot, not my idol. I'm the "theory is nice and all, but practical reality rules" kind of dude.)
Seriously, I haven't read a single comment for four pages which would be about python, and before that, it was "I have a lot of free time, so let's shit on python together, because it must be bad, even though I don't use it."
You must be quite a selective reader, then.
Three pages back, I again raised the question of whether "popularity" is something anyone should consider wrt. programming languages, especially Python (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4143157/#msg4143157). nctnico and emece67 commented on that, which I replied to (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4143157/#msg4143157); that is, that we cannot design a programming language that could cater to "bad programmers" (as in, hold their hands and help them not write shitty code).
It was my unfortunate selection of human traffic patterns as an example, that started the automotive tangent. There, my point was that we do have good algorithms and models we can apply to effectively model traffic; but it is a human problem –– as in, those who do this work do not supply fair inputs to get fair results, but let all sort of ancillary politics and popularity considerations to skew their design, and thus skewing the results.
(This also had a short tangent into algorithms, and that even when using neural networks, it is the input and control parameters to those networks that determine the outputs, not the "algorithm" itself; the "algorithm" really is like the car, with the inputs and control parameters or training material the driver.)
Your own post on Peugeot being a car brand that only those who should not drive own, is a perfect example of why I believe Python's increased popularity to be sinister. (If you care to check out my previous posts in this thread, you'll see that I am actually a proponent of Python, and write Python code almost daily.) That sort of thing rarely happens because of technical features; it is almost always more a social thing.
All this does tie into the topic – "Python becomes the most popular language" –, and exactly how that matters.
I do find the discussion interesting, because the wildly different viewpoints cover the topic much better than a single person ever could.
Granted, the actual development experience and problems encountered are more practical, and therefore useful to a wider audience; but just because you cannot see how the tangents tie into the original subject does not mean they do not. I can see the connections quite clearly, and because I'm not particularly bright or socially adept, the majority of others reading or participating in this thread likely do so too.
If you don't grok the discussion, perhaps it would be better to just lurk or stay away, than to try and stop it or derail it, eh? :-//
-
Nah, what you are saying is bullshit.
Because it was just a reflection what you said, you mean, what you yourself wrote is bullshit? Weird, but I guess I have to agree with you there.
Nah, yours is just baseless fanboy-ism. Its also quite juvenile.
"When caught spewing bullshit, just attack the person who pointed it out."
In case you didn't catch it, I neither believe owning a Peugeot to be a sign of a bad driver, nor do I think there is anything wrong in using Windows.
(Don't let Tux fool ya. It's my mascot, not my idol. I'm the "theory is nice and all, but practical reality rules" kind of dude.)
Seriously, I haven't read a single comment for four pages which would be about python, and before that, it was "I have a lot of free time, so let's shit on python together, because it must be bad, even though I don't use it."
You must be quite a selective reader, then.
Three pages back, I again raised the question of whether "popularity" is something anyone should consider wrt. programming languages, especially Python (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4143157/#msg4143157). nctnico and emece67 commented on that, which I replied to (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4143157/#msg4143157); that is, that we cannot design a programming language that could cater to "bad programmers" (as in, hold their hands and help them not write shitty code).
It was my unfortunate selection of human traffic patterns as an example, that started the automotive tangent. There, my point was that we do have good algorithms and models we can apply to effectively model traffic; but it is a human problem –– as in, those who do this work do not supply fair inputs to get fair results, but let all sort of ancillary politics and popularity considerations to skew their design, and thus skewing the results.
(This also had a short tangent into algorithms, and that even when using neural networks, it is the input and control parameters to those networks that determine the outputs, not the "algorithm" itself; the "algorithm" really is like the car, with the inputs and control parameters or training material the driver.)
Your own post on Peugeot being a car brand that only those who should not drive own, is a perfect example of why I believe Python's increased popularity to be sinister. (If you care to check out my previous posts in this thread, you'll see that I am actually a proponent of Python, and write Python code almost daily.) That sort of thing rarely happens because of technical features; it is almost always more a social thing.
All this does tie into the topic – "Python becomes the most popular language" –, and exactly how that matters.
I do find the discussion interesting, because the wildly different viewpoints cover the topic much better than a single person ever could.
Granted, the actual development experience and problems encountered are more practical, and therefore useful to a wider audience; but just because you cannot see how the tangents tie into the original subject does not mean they do not. I can see the connections quite clearly, and because I'm not particularly bright or socially adept, the majority of others reading or participating in this thread likely do so too.
If you don't grok the discussion, perhaps it would be better to just lurk or stay away, than to try and stop it or derail it, eh? :-//
I think we are victim of double Poe's law.
I didn't write that everyone is here for dissing python.
I certainly don't like the discussion which is going the way: Python is popular, because people are idiots.
-
I certainly don't like the discussion which is going the way: Python is popular, because people are idiots.
That's just the currently most prevalent conclusion, because nobody has provided a better one.
Sure, there have been some members who do claim that popularity is indicative of fitness/usefulness/quality, but the tangential threadlets show that if we look at humanity on the whole, that does not tend to be the case: popularity has its own mechanisms, and is basically orthogonal to usefulness/quality. There is a reason why marketing and branding works.
I could draw a parallel here to systemd and how it has affected Linux distributions in a negative way. It was promoted primarily via social and commercial (primarily inside RedHat, now IBM) means, and not its technical prowess. It since started metastasizing and gathering weakly related and even unrelated projects under its own project umbrella. And as a project, systemd is definitely not interested in software engineering or software quality; only in popularity and achieving a dominant position.
A lot of people do not mind, but I do: there is a reason why Unix philosophy (https://en.wikipedia.org/wiki/Unix_philosophy), modular design (https://en.wikipedia.org/wiki/Modular_design), and the KISS principle (https://en.wikipedia.org/wiki/KISS_principle) work in software design and engineering; and discarding those principles just to become more popular –– dominant –– is a bad deal. (Just go read Debian discussions about adding user choice, and how adamantly systemd-umbrella-projects oppose that. "Dominant" is very applicable there.)
Instead, consider the reasons why Python is becoming more popular. Popularity itself is not good or bad; we need to examine why it is happening to form a rational opinion of the situation.
I use Python on the server back-end, but not because Python as a language is well suited for that task; because in practice, it is better than the other practical alternatives: PHP, Perl, and Ruby. If back-end developers are satisfied with Python (or the other languages), why would anyone put any resources into developing something better?
I also use Python for user interfaces. Because Python has a very nice Foreign Function Interface – I can interface my Python code to native dynamic libraries by only writing some glue code in Python –, I can use one of several widget toolkits to implement the user interface, and let my end users even modify it if they want, without having to expose any of my sekrit sauce (which I provide in a separately-licensed machine code dynamic libraries). However, Python I/O is rather slow, and the way it insists on separating strings (str type) and byte sequences (bytes type) is definitely not optimal. There are other features that others consider less than optimal. In any case, if UI developers are satisfied with Python, why would anyone put any resources into developing something better?
I do not have enough experience in teaching programming (quantitatively, as in I haven't taught enough students to have a representative sample), to know whether Python being increasingly used as an introductory programming language. I know it is definitely better than Java or Borland C, which are still very widely used in education, but I believe teaching a variety of programming languages instead of concentrating on one is a better approach.
I definitely do not want Python to gain a dominant status. As an interpreted language, it revealed very important features (like how to do the interfacing to native machine code libraries right), but is very far from the best we can achieve, if we just keep at it.
And thus, the complexity in the topic reveals itself.
I'm hoping that the quick automotive detour jolts some other member's mind, that because of the detour, they describe an useful observation about Python (and programming languages in general) and the changes in popularity thereof, that would otherwise have left unsaid. A linear discussion is not an exploration of the subject; but at least to me, the value of this thread is exactly in its exploration of the reasons for the increased popularity of Python.
-
I don't think Python's popularity is due to its good features. But for a language to reach that level of popularity it is necessary that it has a minimum of good features.
The increase in popularity of Python I relate it to a greater interest in interpreted languages, because of the advantages of programming in Python to speed up the development of new applications, new features and maintenance, compared to other compiled languages.
There is also a feedback effect. The more popular a language is, the more support it receives for developing tools, libraries, tutorials, etc. This makes it even more popular.
-
I don't think Python's popularity is due to its good features. But for a language to reach that level of popularity it is necessary that it has a minimum of good features.
The increase in popularity of Python I relate it to a greater interest in interpreted languages, because of the advantages of programming in Python to speed up the development of new applications, new features and maintenance, compared to other compiled languages.
There is also a feedback effect. The more popular a language is, the more support it receives for developing tools, libraries, tutorials, etc. This makes it even more popular.
In that light I would say that deployability and standarisation of Python need much more attention. C and C++ for example are governed by standards so their implementations aren't moving targets.
-
In this regard, unfortunately, Python participates in the modern fashion of apps to renew themselves continuously or die.
Why is Apple obsessed with updates on the App Store? (https://medium.com/enrique-dans/why-is-apple-obsessed-with-updates-on-the-app-store-88858c7b1435)
Apple App Store appears to be widely removing outdated apps (https://www.theverge.com/2022/4/23/23038870/apple-app-store-widely-remove-outdated-apps-developers)
And that behavior, for a language like Python (which I consider already established) is a mistake. Hopefully developers will realize that the supposed advantages of making so many changes do not outweigh the disadvantages caused by incompatibilities.
-
I know that there are a lot of large, professional-level Python projects out there. But, in terms of number of applications, most Python code is simple stuff, often written by beginners. For that purpose it is sort of the Arduino for programming in that it's easy to learn and there are a huge number of easy to use libraries available that do all the hard work. Is it possible that all of those hobbyists are being counted when it's said that Python is the most popular?
Of course, the fact that the code is often platform independent (without the need for recompiling) helps a lot.
-
(https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fblog.passmefast.co.uk%2Fimages%2Fhatton-cross-magic-roundabout.jpg&f=1&nofb=1)
I was not amused.
Clearly the designers went off the rails when they decided that going around in either direction was a good idea. That seems to defeat the purpose of a round about.
-
Is it possible that all of those hobbyists are being counted when it's said that Python is the most popular?
I thought the same thing some time ago. Until I saw this statistic from stack overflow that provides only the data from professionals:
https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages
-
.
-
I think the same for a college level.
In the other side, for children from kindergarten to high school, the best language invented so far is Scratch. Developed by the MIT Media Lab's Lifelong Kindergarten group (LLK) and based on Google's blockly.
https://scratch.mit.edu/projects/editor/
-
IMHO Python is one of the easiest languages for casual programmers and for beginners. I'm not only talking about the language syntax, but being also interpreted is a plus for a newbie. What other language will any use at school? Bash :phew: ? Perl :wtf: ? Java :blah: ? C++ |O ? Maybe Lua is the only contender in such category. In some way Python is the new Basic.
One nice thing about Python in a teaching environment is that it has pretty good support for most programming paradigms. It can be a common thread from scripts to procedural, to OO, to functional programming concepts and can be a comfortable home from beginner to expert. It's also an 'easy' entry point to more high-level concepts like AI/ML, data processing, etc. When I went to college, a lot of time was spent teaching Scheme or Java or whatever else I've now forgotten about just to have an environment to explore a fundamental concept, which wastes at least half the semester on 'boilerplate'. There are other languages that have this property, but Python was one of the first to do it well, and as a popular language is a marketable skill for schools to teach in its own right, though the primary goal of a computer science education is not to teach languages. Alongside C/C++ for data structures and systems, it's all you need.
-
The increase in popularity of Python I relate it to a greater interest in interpreted languages, because of the advantages of programming in Python to speed up the development of new applications, new features and maintenance, compared to other compiled languages.
IMHO Python is one of the easiest languages for casual programmers and for beginners. I'm not only talking about the language syntax, but being also interpreted is a plus for a newbie. What other language will any use at school? Bash :phew: ? Perl :wtf: ? Java :blah: ? C++ |O ? Maybe Lua is the only contender in such category. In some way Python is the new Basic.
If you want something very simple, Lua is very lightweight, much simpler to learn than Python, and is actually sane. It's also much faster.
"Popularity" of Python is actually the right metric for it. Popularity in general usually feeds itself (until it eventually goes out of fashion, and that can be brutal... I'm curious to see what will happen with Python specifically.) So, it's popular because... it's popular. =) The ecosystem is the major point IMO. People use it because you can find tons of libraries and modules with which you can achieve stuff with just a few lines of code. Not because it's a particularly simple nor elegant language.
-
Lua is currently ranked number 19 in popularity according to TIOBE, which is not bad at all.
Being so light is also a big advantage. But that itself is a disadvantage by not providing even a minimal standard library.
-
And what about array limits?
This Lua code:
array = {"Hello", "world"}
for i = 1, 5 do
print(array[i])
end
returns:
Hello
world
nil
nil
nil
I don't think this is a good example for an introductory programming course.
-
It's better than a seg fault.
-
Yes, but worst than Python return.
array = ['Hello', 'world']
for i in range(5):
print(array[i])
Return:
Hello
world
Traceback (most recent call last):
File "<pyshell#6>", line 2, in <module>
print(array[i])
IndexError: list index out of range
-
But, if you want a null return, is very easy to achieve:
array = ['Hello', 'world']
for i in range(5):
try:
print(array[i])
except:
print(None)
Return:
Hello
world
None
None
None
-
Clearly the designers went off the rails when they decided that going around in either direction was a good idea. That seems to defeat the purpose of a round about.
If road designers are blatantly confusing drivers, they look bad. So, they find roundabout ways to achieve the same goal.
-
Picuino, can you elaborate on what's the problem?
And, Lua doesn't have "arrays" in fact. It only has tables, which are collections of key-value pairs. Tables can loosely act as arrays if they only contain items without an associated key, in which case they get assigned a numeric index. But they still operate as tables.
Accessing an item that doesn't exist in a table yields 'nil', which basically means an object that doesn't exist. Seems consistent to me. Actually, this model looks more sane to me for beginners than the low-level, C-like arrays, which you always can learn about later on once your have your bases covered.
Lua has metatables too, so you can override the indexing function for a given table, and do some fun (or interesting) stuff. You can for instance define tables that will not return 'nil' when accessing an item that doesn't exist, but will do something else entirely. Pretty powerful.
Oh, and otherwise, you have iterators, so you can access tables in a more elegant way than directly indexing them.
-
Picuino, can you elaborate on what's the problem?
Not much, really.
They are two equally valid points of view.
I see it from the point of view of teaching how important it is not to exceed the limits of an array. The array is the structure most used by other lower level languages that any programmer will later have to learn. Dictionaries (tables) are a different concept and Python distinguishes them well, which for me is an advantage when teaching the different types of data that exist.
-
Oh, and otherwise, you have iterators, so you can access tables in a more elegant way than directly indexing them.
Both Lua and Python, but this way you can't get out of the array.
-
About Lua: I'm surprised it doesn't get that much traction nowadays. I like it far better compared to Python and it is very easy to integrate Lua in applications in order to add scripting.
-
About Lua: I'm surprised it doesn't get that much traction nowadays. I like it far better compared to Python and it is very easy to integrate Lua in applications in order to add scripting.
Lua certainly shines for scripting. Its such a lightweight add on.
-
About Lua: I'm surprised it doesn't get that much traction nowadays. I like it far better compared to Python and it is very easy to integrate Lua in applications in order to add scripting.
It's pretty easy to integrate in applications indeed, and the bonus is that you can allocate several instances of the Lua interpreter in the same app, whereas I'm not even sure this is possible with Python.
But popularity? Again a complex and intricate matter. Lua comes from a uni in Brazil, and I have no doubt they teach Lua over there.
-
Picuino, can you elaborate on what's the problem?
Not much, really.
They are two equally valid points of view.
I see it from the point of view of teaching how important it is not to exceed the limits of an array. The array is the structure most used by other lower level languages that any programmer will later have to learn. Dictionaries (tables) are a different concept and Python distinguishes them well, which for me is an advantage when teaching the different types of data that exist.
That is debatable to no end. I quite like the unified data collection type in Lua, with which again you can actually implement any data structure you like. This is not restrictive.
Whether accessing an non-existing item returns nil or causes an exception/crash is not a sign of a good implementation per se or what should really be done.
Generalizing data collection is not a bad thing IMO. Beginners certainly do not need to make a difference. What matters is whether the data collection is ordered or not, and this is the key point. Key-value pairs in Lua tables are NOT ordered, but keyless values are assigned a numeric, increasing index, and are ordered. This is really all you need to know. The rest is pretty low-level, and if/when you need to learn about more low-level structures, you can do that later. I'm not sure starting with them is that good of an idea.
Note that print() in Lua will print 'nil' for nil values, but using nil values in arithmetic/string/whatever operation will usually yield an exception too. So if there is an invalid item access, you'll get an exception at some point, unless you explicitely deal with that in the code.
Now you can implement "arrays" that would act as you expect, using metatables. That'd actually be an interesting first exercise for learning about metatables.
function NewArray(A)
A = A or {}
return setmetatable(A, { __index = function (Table, Key) error("Out of Bounds!", 2) end })
end
A = NewArray({"Hello", "world"})
for i = 1, 5 do
print(A[i])
end
-
About Lua: I'm surprised it doesn't get that much traction nowadays. I like it far better compared to Python and it is very easy to integrate Lua in applications in order to add scripting.
It's pretty easy to integrate in applications indeed, and the bonus is that you can allocate several instances of the Lua interpreter in the same app, whereas I'm not even sure this is possible with Python.
I've seen Lua scripting being used in things like VoIP server applications, where every call has a Lua script running. So, it seems to do a good job when you have a quite a large number of concurrent instances.
-
The only reason that I have ever even heard of Lua is because it's the scripting language used in FEMM. I leaarned to use it to get some work done. To that end, I found it easy to learn and capable enough to do what I needed to do. I have always had the vague impression that that sort of thing is exactly what Lua was designed for.
How is comparing Lua to Python to C at all productive without context? I think Picuino is supplying his context when he talks about using Python as a learning tool. I can easily see how it would be well suited for teaching programming concepts without getting distracted by programming details. OTOH, a large fraction of my coding time is spent writing firmware for microcontrollers. There C seems a much more natural fit. Both C and Python win!!!
-
Yes, but worst than Python return.
array = ['Hello', 'world']
for i in range(5):
print(array[i])
Return:
Hello
world
Traceback (most recent call last):
File "<pyshell#6>", line 2, in <module>
print(array[i])
IndexError: list index out of range
Cause this isn't the pythonic way.
array = ['Hello', 'world']
for x in array:
print(x)
See how much easier it is? If you really really need the index, you enumearte it.
-
One possible enumerated version in Python being
array = [ 'hello', 'world' ]
for x in range(len(array)):
print("array[{key}] = '{value}'".format(key=x, value=array[x]))
which outputs
array[0] = 'hello'
array[1] = 'world'
As to Lua, I still need to experiment more with LGI (https://github.com/pavouk/lgi/) and LQT (https://github.com/lqt5/lqt). The former provides GObject introspection bindings for Lua (and thus one can use e.g. Gtk+ and WebKit in Lua with that, the same way one can use them in Python); the latter provides Lua to Qt5 bindings. (I'm not interested in microbenchmarking, though. What matters to me, is finding out any drawbacks and downsides; the types of situations or problems they have performance or other issues with.)
I do love how embeddable Lua is to an application, but I do have some reservations and prejudices about the abstract stack model that Lua uses to exchange data with non-Lua code. For some things, such an interface works really well; I just have trouble fitting the model to streaming data and concurrent processing with Lua and non-Lua code. (I'm not saying it cannot be done, I'm only describing the limitations of my current understanding, hopefully explaining why I haven't used Lua more.)
-
It's as contrived as example gets, but I would
array = ['hello','world']
for index,value in enumerate(array):
print(f'array[{index}] = {value}')
-
Cause this isn't the pythonic way.
array = ['Hello', 'world']
for x in array:
print(x)
See how much easier it is? If you really really need the index, you enumearte it.
... as a few unix shells do also support for a long time. We should educate software developers to write good code instead of promoting some programming languages to be more fool-proof.
-
The Pythonic way is:
array = ['Hello', 'world']
print(' '.join(array))
But I wanted to show the problem that occurs with out-of-range indexes.
-
... as a few unix shells do also support for a long time. We should educate software developers to write good code instead of promoting some programming languages to be more fool-proof.
I agree with the Python philosophy that says "Errors should never pass silently. Unless explicitly silenced."
The Zen of Python: https://peps.python.org/pep-0020/
https://en.wikipedia.org/wiki/Poka-yoke
-
New from Anaconda: Python in the Browser
News from PyCon US 2022.
https://www.anaconda.com/blog/pyscript-python-in-the-browser (https://www.anaconda.com/blog/pyscript-python-in-the-browser)
https://pyscript.net/ (https://pyscript.net/)
https://pyscript.net/examples/ (https://pyscript.net/examples/)
-
We should educate software developers to write good code instead of promoting some programming languages to be more fool-proof.
Yup, because chasing fool-proof is a fool's errand (https://en.wikipedia.org/wiki/Fool's_errand).
Let me switch to POSIX C for an example. The way to read unlimited-length lines in POSIX C from input (a FILE pointer) is
size_t size = 0;
char *line = NULL;
ssize_t len;
while (1) {
len = getline(&line, &size, input);
if (len <= 0)
break;
/* The line is in 'line'. It is a dynamically allocated buffer,
with 'size' chars currently allocated for it.
It has 'len' chars in it, followed by a nul char '\n'. */
}
free(line);
line = NULL;
size = 0;
if (ferror(input) || !feof(input)) {
/* Error reading input stream! */
}
Getting C programmers use this dynamically allocated approach (with getline() (https://www.man7.org/linux/man-pages/man3/getline.3.html)) allocating or reallocating the line buffer (like realloc() (https://www.man7.org/linux/man-pages/man3/realloc.3.html)) whenever necessary, in my experience has been the first step towards sane dynamic memory use patterns.
The second step is to drop examples with opendir()/readdir()/closedir() like the turd they are, and help them use nftw() (https://www.man7.org/linux/man-pages/man3/nftw.3.html), scandir() (https://www.man7.org/linux/man-pages/man3/scandir.3.html), and glob() (https://www.man7.org/linux/man-pages/man3/glob.3.html) for example.
If they've been introduced to function pointers, one can whet their appetite by showing a practical example of how to do run-time plugins using e.g. scandir() or glob(), dlopen() (https://www.man7.org/linux/man-pages/man3/dlopen.3.html), and dlsym() (https://www.man7.org/linux/man-pages/man3/dlsym.3.html).
Along the basic trail, you can show as tangential nuggets or goals almost (but not quite) in reach right now, in the form of powerful but simple implementations without the common pitfalls.
Getting back to Python, the learning curve, especially the "I must suck before I get nice results" part, is much gentler.
The question "how do I do X" is no longer hard at all; it is getting the general understanding to the level that the real question, "how do I do X so that Y", is even asked.
With "harder" languages, the learners understanding of the entire logic of programming grows as they learn their first programming language. But with fast and easy languages, you can get nice results by copying a thirty-line example off the web.
I can definitely see why so many are interested in developing a programming language that would be best suited to be the first programming language; so that its structures and properties themselves supported building a working intuitive model of what programming itself is.
Unfortunately, that means that that language would really be only useful to learn the cognitive basics of programming, and would have to then learn one or more "proper" languages to acquire a marketable skill. To me, that's a good tradeoff, because knowing more than one programming language seem to be almost a prerequisite of being any good at it at all (statistically speaking). Others hate the idea, and instead look for a Single Language to Rule Them All.
-
...
Getting back to Python, the learning curve, especially the "I must suck before I get nice results" part, is much gentler.... I can definitely see why so many are interested in developing a programming language that would be best suited to be the first programming language; so that its structures and properties themselves supported building a working intuitive model of what programming itself is.
Unfortunately, that means that that language would really be only useful to learn the cognitive basics of programming, and would have to then learn one or more "proper" languages to acquire a marketable skill....
In what ways and why is Python not "proper"? Using Lisp as a benchmark, the big thing it does not encourage (on purpose) is using the language to rewrite itself. Python is full of simple, useful ideas that once learned make it a pleasantly "low friction", high level language. But to understand and exploit those ideas you may have to abandon some features or design patterns that Python does not need or in ways has superseded.
-
Actually Python is a good language to start learning programming and it is also a very requested language in the market.
I know of no other real language that is equally well suited to both objectives.
-
Cause this isn't the pythonic way.
array = ['Hello', 'world']
for x in array:
print(x)
See how much easier it is? If you really really need the index, you enumearte it.
... as a few unix shells do also support for a long time. We should educate software developers to write good code instead of promoting some programming languages to be more fool-proof.
The point is that "for" in python is a foreach. And forcing it to an enumeration and indexing is using methods that are for a different language.
First thing that you learn in programming is to use a language and it's features, and not misuse it. In C you learn what are the side effects of operators, and why you never program with those in mind.
The same way there is pythonic ways to solve problems, and there are ways that were brought in from C. The issue is that if you take some C code, remove the semicolons and curly brackets, it would more or less run as python code. But that's not how the language is supposed to be used. I have a very simple test, if someone understands the difference. Just ask them to write "hello word" into a file. If their answer doesn't start with "with" they don't get the language, at all, they just want to write the same code they always do in python.
-
...
Getting back to Python, the learning curve, especially the "I must suck before I get nice results" part, is much gentler.... I can definitely see why so many are interested in developing a programming language that would be best suited to be the first programming language; so that its structures and properties themselves supported building a working intuitive model of what programming itself is.
Unfortunately, that means that that language would really be only useful to learn the cognitive basics of programming, and would have to then learn one or more "proper" languages to acquire a marketable skill....
In what ways and why is Python not "proper"? Using Lisp as a benchmark, the big thing it does not encourage (on purpose) is using the language to rewrite itself. Python is full of simple, useful ideas that once learned make it a pleasantly "low friction", high level language. But to understand and exploit those ideas you may have to abandon some features or design patterns that Python does not need or in ways has superseded.
By that language, I was referring to the educational languages that are designed to build up the understanding of programming in general as the learner learns the language, not Python.
I do fear that Python is "too easy", in the sense that typical programming exercises I've seen are too easy (just a couple of lines, easily memorized instead of understood and integrated). I haven't evaluated any courses that teach Python as the first programming language, so I could easily be wrong.
The risk in being too easy is in that the learners may never build the understanding necessary to apply the language in problem solving. In the best case, I believe problem solving itself should be taught in parallel (or maybe even prior) to programming languages.
Perhaps a course that concentrates on using Python to solve actual problems, ignoring the typical examples and exercises one usually sees, would avoid the pitfalls.
I mean, one of my favourite C examples is a simplified sort command, starting from the choice of whether you read all input lines and sort them, or whether you read each input line into a self-sorting data structure like a binary heap (min-heap if sorting ascending, max-heap if descending). In Python, sorting lines from instream ascending unless reversed is true and outputting them to outstream is just
outstream.write(''.join(sorted([line for line in instream], reverse=reversed)))
The other side of the coin in ease of use is that choices are made for you, and that hides the fact that there ever was a choice to be made.
-
To paraphrase Bob Widlar, every idiot can program. ;D
Elegant, robust, readable and maintainable code is another thing entirely.
-
Actually Python is a good language to start learning programming and it is also a very requested language in the market.
I know of no other real language that is equally well suited to both objectives.
Back in the old days Pascal was the language used to teach programming. But people also got stuck with that and started using Pascal for real applications. >:D
To paraphrase Bob Widlar, every idiot can program. ;D
Elegant, robust, readable and maintainable code is another thing entirely.
Very true! I always say it takes 10 years to learn how to program properly after finishing school/university.
-
Very true! I always say it takes 10 years to learn how to program properly after finishing school/university.
Not really. It takes 3 or 4 years for the talented to get good, and the rest never will.
-
To paraphrase Bob Widlar, every idiot can program. ;D
Elegant, robust, readable and maintainable code is another thing entirely.
Quite! When the language is so high level that traditional exercises become single-liners, how do you teach new programmers about elegant, robust, readable and maintainable code at all?
(I mean this as a true question that I do not know the answer to, and occasionally ponder about.)
My own use cases of Python are such that all the interesting and important choices and algorithms are done elsewhere, in somewhat "hidden" code (that I often describe simply as "the engine" (or "the engine underneath"), with the express intent that the exposed, user-modifiable Python code is simple "business logic" that does not require any programming skill. The use of interpreted language with human-readable, human-modifiable code without any toolchain or explicit tooling, is a careful design choice.
(Well, for the server side web stuff I do, the choice of Python is basically made between what web hosting providers support and provide, not what is theoretically possible or what programming language is best suited for the task. Dictated by exigencies, if you will.)
-
A Python-related practical issue right now: CVE-2022-29799 (https://securityonline.info/cve-2022-29799-cve-2022-29800-linux-privilege-escalation-vulnerability/) directory traversal issue in networkd-dispatcher, which is written in Python. A rather simple TOCTOU (time-of-check to time-of-use) (https://en.wikipedia.org/wiki/TOCTOU) bug with security implications.
In Linux, in security sensitive applications where each component (directory or symlink) along the path to the target file needs to be checked for access rights, this is straightforward to solve using openat() (https://www.man7.org/linux/man-pages/man2/openat.2.html) and an extra file descriptor per directory along the path, up to the point when the target file or directory is opened, when the previous temporary descriptors are closed. This is rock solid, and cannot be confused or tricked by renaming or replacing any component during the traversal; there is no race window, no timing holes at all. The only downside is the temporary use of a limited resource (file descriptors); a common limit currently is at most 1024 open descriptors per process, and can be trivially raised for privileged processes.
How the hell do you teach someone to do this properly in Python? I am not sure myself. To me, it seems like something that a Python module (perhaps os.path or pathlib) should provide, as a "security-sensitive open() variant" with maybe a callback to check each path component after it has been opened, not something one should open-code in Python.
(For my own web service back ends, I use a different security model, where only the access mode to the target directory and target file are relevant; the intermediate path components are not examined. This does enforce a more tree-like security model, where access can become only more restricted, not less, when going deeper into the filesystem hierarchy. It does shift a lot of the responsibility to the system administrator, though, so it has to be setup correctly from the get go, to be truly secure.)
-
I'll just leave a single data point here point about Python.
My son is not a programmer by vocation or choice, but recently graduated* in Economics with a master thesis about GANs and asset pricing.
He did his work with the help of the usual tools: jupyter notebooks, tensorflow, google colab.
He was able to quickly put together the needed application, generate graphs and animations, experiment with data and algorithms etc. etc.
Could have done the same work in C/C++/C# or other languages?
Undoubtedly, I trust he could have pulled it off.
Would the extra amount of effort be warranted?
I don't believe it in the least.
As many have said, the heavy lifting is done by non-python code someone else wrote, but the availability of powerful libraries and the ease of stringing them together and experimenting is absolutely a strong point of Python and of course, a case of positive feedback: the more it's used, the more libraries you can find, a bit like that other thing, Arduino (where 90% of the libs are crap, though).
*Magna cum laude, from a very famous Italian Uni, in time, while working full time and with tuition fees waived due to academic results. Bear with me for playing proud parent. ;D
-
.
-
For decades C and Java have been the most popular languages, with no rival. Suddenly that position is taken over by the almost newcomer Python.
An important aspect of this change in the popularity list is the grief that this means for some programmers, who must go through the five classic stages to accept the new situation.
Denial, Anger, Bargaining, Depression and Acceptance (https://en.wikipedia.org/wiki/Five_stages_of_grief#Stages_of_grief)
I think it is important to recognize and respect the feelings of others. Besides being a tolerant behavior, it is very practical to understand other people with other opinions.
Some opinions I've read I think are trying to deny the popularity of Python.
Others respond with a phrase that is not really an answer "Python is popular because people are dumb". I wonder if that same answer would be given by them in the case of having to explain the popularity of C during all these previous years.
In other cases I sincerely believe that they don't know/use Python and simply give opinions based on prejudice.
Anyway, regardless, I agree with Nominal Animal that by reading the whole thread it is possible to extract a much broader point of view than just one person can provide, about the possible reasons for Python's popularity.
-
... When the language is so high level that traditional exercises become single-liners, how do you teach new programmers about elegant, robust, readable and maintainable code at all?...
By doing original programming at an equally high level. Elegant, robust, readable and maintainable code does not vanish above a certain level of abstraction.
-
For decades C and Java have been the most popular languages, with no rival. Suddenly that position is taken over by the almost newcomer Python.
An important aspect of this change in the popularity list is the grief that this means for some programmers, who must go through the five classic stages to accept the new situation.
Denial, Anger, Bargaining, Depression and Acceptance (https://en.wikipedia.org/wiki/Five_stages_of_grief#Stages_of_grief)
I think it is important to recognize and respect the feelings of others. Besides being a tolerant behavior, it is very practical to understand other people with other opinions.
Some opinions I've read I think are trying to deny the popularity of Python.
Others respond with a phrase that is not really an answer "Python is popular because people are dumb". I wonder if that same answer would be given by them in the case of having to explain the popularity of C during all these previous years.
In other cases I sincerely believe that they don't know/use Python and simply give opinions based on prejudice.
Anyway, regardless, I agree with Nominal Animal that by reading the whole thread it is possible to extract a much broader point of view than just one person can provide, about the possible reasons for Python's popularity.
I'm afraid that your own prejudices show here. You're seemingly reacting to criticism of your personal favourite and then projecting your feelings of hurt onto people who, in your mind, have had their personal favourites knocked off the top spots. The truth is that professional programmers of any experience don't give a damn for the popularity of their personal favourite programming languages. I've been a professional programmer since the 1970s, my personal favourites, Smalltalk 80 and Algol 68, have never even been in the top 10 of any popularity contest and it bothers me not one jot. A professional only cares that the language they use for any given project is appropriate to it. Learning to use a new language for a specific project is trivial if you're seasoned and is not the insurmountable barrier that it seems to the novice who only has reasonable facility with one or a very few tools.
I suspect that much of Python's popularity can be explained by fashion (to which the computing world is far from immune) and the rest by "If all you have is a hammer then everything looks like a nail". In the 80s and 90s many real world projects were produced in Pascal largely because that was what people had learned. That did not, and still doesn't, make Pascal a good automatic first choice of language for a project. Proof, if it is needed, that Pascal was a popularity related fad is its near total disappearance from the modern landscape. Notable also is that its grown up cousin, Modula 2, which was much more suitable for production programming and very easily learned by Pascal programmers didn't even get a "look in". Fashions change, the contents of the heads of fresh graduates change, and now Pascal is nowhere to be seen. Look back at the 1987 version of the 'most popular' programming languages and Lisp and Prolog take second and third place, driven by the first wave of AI as the current fashion; try and tell me that wasn't "fashion over good sense".
Like it or not, popularity has nothing to do with any notion of 'goodness', either in being "good at its job" or "a good fit for a job". If popularity contests found the best solutions then elections would find the best politicians, and we know that they don't; heck they don't even manage to find the least worst politicians in most cases. Pinning the overall effectiveness of a programming language to popularity is foolish, constantly returning to that popularity as an argument in its favour compounds the foolishness.
And on that note, I have to go and vote in the local elections here in the UK and futilely register my disapproval of the current incumbents by claiming to support someone else.
-
I'm afraid that your own prejudices show here. You're seemingly reacting to criticism of your personal favourite and then projecting your feelings of hurt onto people who, in your mind, have had their personal favourites knocked off the top spots. The truth is that professional programmers of any experience don't give a damn for the popularity of their personal favourite programming languages. I've been a professional programmer since the 1970s, my personal favourites, Smalltalk 80 and Algol 68, have never even been in the top 10 of any popularity contest and it bothers me not one jot. A professional only cares that the language they use for any given project is appropriate to it. Learning to use a new language for a specific project is trivial if you're seasoned and is not the insurmountable barrier that it seems to the novice who only has reasonable facility with one or a very few tools.
What bothers me is not the criticism of my favorite language (which is not Python, if I had to choose I would prefer C). What I don't like is this tendency to only criticize what is bad about the language, sometimes with very biased or unrealistic arguments. That doesn't help me to learn anything.
On the other hand it is not true that professional programmers don't care about popularity. They do care about it in many ways. Some positive (more support for their preferred language) and some negative (for example that there are many neophytes doing bad code and discrediting the professionals).
Proof, if it is needed, that Pascal was a popularity related fad is its near total disappearance from the modern landscape. Notable also is that its grown up cousin, Modula 2, which was much more suitable for production programming and very easily learned by Pascal programmers didn't even get a "look in". Fashions change, the contents of the heads of fresh graduates change, and now Pascal is nowhere to be seen. Look back at the 1987 version of the 'most popular' programming languages and Lisp and Prolog take second and third place, driven by the first wave of AI as the current fashion; try and tell me that wasn't "fashion over good sense".
Pascal is another of my favorite languages. In fact it was the first structured language I learned (before C) because it was taught at the university at the time to start learning to program.. For me it was a great discovery and a great teaching with which I learned to structure data and code.
Still today Delphi/Object Pascal is ranked 12th in popularity in the Tiobe index, and ADA (another similar language I learned in those years) is ranked 29th.
They are still alive and I am not surprised since they have many virtues.
In the PLC world Pascal (a similar language) is the standard (IEC 61131-3) for structured programming.
https://en.wikipedia.org/wiki/Structured_text
-
Like it or not, popularity has nothing to do with any notion of 'goodness', either in being "good at its job" or "a good fit for a job". If popularity contests found the best solutions then elections would find the best politicians, and we know that they don't; heck they don't even manage to find the least worst politicians in most cases. Pinning the overall effectiveness of a programming language to popularity is foolish, constantly returning to that popularity as an argument in its favour compounds the foolishness.
I wouldn't mind starting a thread about the advantages and disadvantages of Python, but unfortunately the news I started this thread with is the rise for the first time in 20 years to the top spot in popularity of a language that wasn't C or Java, it was Python.
You may give little importance to popularity, but it is an important metric of how much a language is used and how much support it receives.
The big companies behind this surge in popularity are no fools. They have supported this language for compelling reasons. That's my view.
-
I'll just leave a single data point here point about Python.
My son is not a programmer by vocation or choice, but recently graduated* in Economics with a master thesis about GANs and asset pricing.
He did his work with the help of the usual tools: jupyter notebooks, tensorflow, google colab.
Of course. That's one of the reasons why Python has gotten so popular.
I've heard they even introduced programming courses in Python in art schools.
While the times and the language itself are very different, the comparison with BASIC that some have made is relevant. Python has helped bring programming back to the masses, just like BASIC did a few decades ago. While I personally think some other languages might have been better for this purpose, we can't deny that it's working. As "home computers" disappeared and the personal computer appeared, BASIC also mostly disappeared - somewhere in the early 90's. For two good decades, nothing replaced it and the "masses" lost interest in programming. And even non-programmers in professional, scientific settings didn't know how to program anymore and had to hire software engineers. So, Python has brought this back.
So, it covers needs that were just not met. It doesn't "replace" other languages, and I don't think it should. That's probably where "popular" is misleading. It's not that C or whatever is being replaced by Python, it's mostly that a lot more people are now programming than ever before, using Python.
-
I'll just leave a single data point here point about Python.
My son is not a programmer by vocation or choice, but recently graduated* in Economics with a master thesis about GANs and asset pricing.
He did his work with the help of the usual tools: jupyter notebooks, tensorflow, google colab.
Of course. That's one of the reasons why Python has gotten so popular.
I've heard they even introduced programming courses in Python in art schools.
While the times and the language itself are very different, the comparison with BASIC that some have made is relevant. Python has helped bring programming back to the masses, just like BASIC did a few decades ago.
So, it covers needs that were just not met. It doesn't "replace" other languages, and I don't think it should. That's probably where "popular" is misleading. It's not that C or whatever is being replaced by Python, it's mostly that a lot more people are now programming than ever before, using Python.
I think popular is somewhat misleading indeed. To me it seems Python is used to partly replace Excel and add automation to making calculations. After all, Python allows to interface to outside things far more easely compared to Excel and it has a much lower threshold compared to Matlab / Labview / statistics packages. A researcher can easely create a Python script that collects data from a bunch of test equipment and do analysis on the data. At one of my previous jobs one of my tasks was to process data that was collected during experiments into data that could be read into a statistics package by a researcher. Nowadays a researcher can do without the statistics package AND do the data pre-processing as well using Python.
From my point of view Python is great for one-off programs that need to run in a very controlled environment (OS version, Python version, library verions). However I'm holding on to my opinion that Python is not the ideal choice for software that needs to be distributed and maintained long term. The core of Python is too much a moving target.
-
Learning to use a new language for a specific project is trivial if you're seasoned and is not the insurmountable barrier that it seems to the novice who only has reasonable facility with one or a very few tools.
Learning enough to solve a problem in the way you would have in some other language you have experience with is trivial, sure. Learn the syntax for basic flow control a few I/O functions and you can do a lot. Learning to use the language in idiomatic fashion, understand the full elegance - or inelegance - of the tools it provides, and be able to write concise, good code? I don't think so. That takes many hours in front of the terminal, and there's not much of a substitute for it.
I actually think this is responsible for a lot of the hate Python is getting here. Complaints about significant whitespace and such are so :palm:. Use the language for a few hours and let yourself put aside your hate, and you will forget about this entirely. Likewise, Python isn't getting any credit here at all for its elegant sugar, and I would hazard that many of those bleating about whitespace have no idea what a dict comprehension is. It's a bit of a catch-22 that you can't really fairly evaluate a language until you've actually used it in anger for a while.
I suspect that much of Python's popularity can be explained by fashion (to which the computing world is far from immune) and the rest by "If all you have is a hammer then everything looks like a nail". In the 80s and 90s many real world projects were produced in Pascal largely because that was what people had learned. That did not, and still doesn't, make Pascal a good automatic first choice of language for a project. Proof, if it is needed, that Pascal was a popularity related fad is its near total disappearance from the modern landscape. Notable also is that its grown up cousin, Modula 2, which was much more suitable for production programming and very easily learned by Pascal programmers didn't even get a "look in". Fashions change, the contents of the heads of fresh graduates change, and now Pascal is nowhere to be seen. Look back at the 1987 version of the 'most popular' programming languages and Lisp and Prolog take second and third place, driven by the first wave of AI as the current fashion; try and tell me that wasn't "fashion over good sense".
Other than C, it's hard to think of a language whose popularity you wouldn't explain away as 'fashion', and C has a long list of its own shortcomings. Technology moves pretty quickly, and programming languages aren't really an exception. Good or bad, something staying at the top of the popularity list for decades is going to be the exception, not the rule, and the sort of pejorative tone you seem to be taking here that this is a bad thing is a bit absurd to me. Why should programmers not be taking advantage of the state of the art?
If we compare like-for-like, Python has mostly displaced languages like Perl (which I would say was the closest competitor, with the CPAN libraries and ubiquity), PHP and bash. It is a vast improvement on any of those, and I will fight anyone that tries to argue otherwise. The concept of scripting languages isn't going anywhere.
-
If we compare like-for-like, Python has mostly displaced languages like Perl (which I would say was the closest competitor, with the CPAN libraries and ubiquity), PHP and bash. It is a vast improvement on any of those, and I will fight anyone that tries to argue otherwise. The concept of scripting languages isn't going anywhere.
I like Ruby much more than Python. Unfortunately it hasn't gotten the same mindshare outside of a couple of web frameworks.
Modern Javascript is also better than Python, especially TypeScript. With v8 it also runs far far more quickly. It's for general scripting, not only in the browser. There are a huge number of libraries available in npm.
-
There is a general opinion that speed of execution is a fundamental parameter.
I believe that the increase in the use of Python is due precisely to the lesser importance of execution speed and the greater importance of the speed of development of both new programs and modifications of already created programs. This is where Python stands out by far.
Its ease of programming is not only something that neophytes take advantage of. It is a feature that professionals also take advantage of.
-
Given equal speed of development, speed of execution matters.
Ruby and JavaScript are about as productive as Python.
-
Ruby is better.. elegant and with closures.. java sucks.. dog slow
Java was meant as a browser sort of engine
Btw. Python lack of closures sucks..
Paul
-
... 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.
-
If we compare like-for-like, Python has mostly displaced languages like Perl (which I would say was the closest competitor, with the CPAN libraries and ubiquity), PHP and bash. It is a vast improvement on any of those, and I will fight anyone that tries to argue otherwise. The concept of scripting languages isn't going anywhere.
I like Ruby much more than Python. Unfortunately it hasn't gotten the same mindshare outside of a couple of web frameworks.
Modern Javascript is also better than Python, especially TypeScript. With v8 it also runs far far more quickly. It's for general scripting, not only in the browser. There are a huge number of libraries available in npm.
Ruby was very fashionable for a few years, you couldn't move for newly written things in Ruby, especially Ruby on Rails. It got mindshare, but it was transitory. There's no good reason for this, Ruby, as you suggest, was a much better general purpose language than several that have displaced it.
People who haven't kicked about for a good few years tend to discount the effect of fashions in computing. Anybody remember when 4GLs were the next big thing, the first time around that AI was going to be in everything, or more recently, blockchain (which is just another fancy name for a Merkle tree).
-
If we compare like-for-like, Python has mostly displaced languages like Perl (which I would say was the closest competitor, with the CPAN libraries and ubiquity), PHP and bash.
:-DD
"displaced ... bash" - I don't think so. You put /usr/bin/python in place of /bin/bash in your /etc/passwd entry and let us know how you get on, if you ever recover from doing so.
-
Given equal speed of development, speed of execution matters.
Ruby and JavaScript are about as productive as Python.
I think Python is more productive because of the large number of libraries it has. There is no comparison.
Also the code is more maintainable in Python.
-
Given equal speed of development, speed of execution matters.
Ruby and JavaScript are about as productive as Python.
I think Python is more productive because of the large number of libraries it has. There is no comparison.
Python's PyPI has about 350,000 packages.
JavaScript's npm has about 1.3 MILLION packages.
I think you don't know what you're talking about when it comes to non-Python languages.
Also the code is more maintainable in Python.
Very much a matter of opinion.
-
JavaScript's npm has about 1.3 MILLION packages.
0.3 MILLION useful packages
1.0 MILLION rewrites of the above in someones 'favourite incompatible api strategy of the month'
;D
-
As far as I can see JavaScript has libraries like Tensorflow for AI, libraries for web development, etc.
I didn't know JavaScript had such a lot of possibilities. I had always kept the language in the web page environment.
How to run JavaScript in command line?
-
How to run JavaScript in command line?
Install node.
Mac-mini:~ bruce$ echo 't=0;for (i=0; i<100000000; ++i) t+=i; console.log(t)' | time node
4999999950000000
0.86 real 0.76 user 0.03 sys
Mac-mini:~ bruce$ (echo 't=0'; echo 'for i in range(100000000): t+=i'; echo 'print t') | time python
4999999950000000
10.97 real 5.62 user 2.69 sys
Javascript doesn't have a nice range() function like Python, so I tried building one:
const range = (x,y) => (function*(){
while (x < y) yield x++;
})();
let t = 0;
for (let i of range(1,100000000)) t += i;
console.log(t);
As you'd expect, it's a bit slower because of building an abstraction in the scripting language itself, not in the C implementation ...
Mac-mini:programs bruce$ time node speed.js
4999999950000000
real 0m2.503s
user 0m2.231s
sys 0m0.069s
But still four times faster than Python.
-
But the "correct" way to do it would be
~$ echo 't=0;for (i=0; i<100000000; ++i) t+=i; console.log(t)' | time node
4999999950000000
2.01user 0.14system 0:01.70elapsed 126%CPU (0avgtext+0avgdata 40276maxresident)k
1968inputs+0outputs (15major+3370minor)pagefaults 0swaps
~$ (echo 'print(sum(range(100000000)))') | time python3
4999999950000000
1.89user 0.00system 0:01.90elapsed 99%CPU (0avgtext+0avgdata 9408maxresident)k
0inputs+0outputs (0major+1137minor)pagefaults 0swaps
Edit: Or a bit faster
~$ echo 'import numpy as np; print(np.sum(np.arange(100000000)))' | time python3
4999999950000000
0.27user 0.59system 0:00.87elapsed 99%CPU (0avgtext+0avgdata 807240maxresident)k
0inputs+0outputs (0major+102682minor)pagefaults 0swaps
-
.
-
Oooh been away too long. I love these threads. Popcorn at the ready :popcorn:
Python is absolutely fine for most things. If what you're doing is slow then you either should have written it in another language or screwed up the implementation.
Personally I mostly write Go now, which has certain advantages to it in the doing lots of things at the same department, but the time to market on Python, which is usually the marker of ROI, is by far the lowest of any platform I've had to work with.
-
What a relief! One more Python fan. ;D
-
Edit: Or a bit faster
~$ echo 'import numpy as np; print(np.sum(np.arange(100000000)))' | time python3
4999999950000000
0.27user 0.59system 0:00.87elapsed 99%CPU (0avgtext+0avgdata 807240maxresident)k
0inputs+0outputs (0major+102682minor)pagefaults 0swaps
Let's see if JavaScript has the same libraries for parsing and manipulating large amounts of data ...
Perhaps this? https://github.com/nicolaspanel/numjs
-
Let's see if JavaScript has the same libraries for parsing and manipulating large amounts of data ...
It does, but it'll take 500 hours to resolve the npm dependency chart and install several pieces of malware in the process...
-
But the "correct" way to do it would be
~$ echo 't=0;for (i=0; i<100000000; ++i) t+=i; console.log(t)' | time node
4999999950000000
2.01user 0.14system 0:01.70elapsed 126%CPU (0avgtext+0avgdata 40276maxresident)k
1968inputs+0outputs (15major+3370minor)pagefaults 0swaps
~$ (echo 'print(sum(range(100000000)))') | time python3
4999999950000000
1.89user 0.00system 0:01.90elapsed 99%CPU (0avgtext+0avgdata 9408maxresident)k
0inputs+0outputs (0major+1137minor)pagefaults 0swaps
Edit: Or a bit faster
~$ echo 'import numpy as np; print(np.sum(np.arange(100000000)))' | time python3
4999999950000000
0.27user 0.59system 0:00.87elapsed 99%CPU (0avgtext+0avgdata 807240maxresident)k
0inputs+0outputs (0major+102682minor)pagefaults 0swaps
You could argue that you should always know what is "the Pythonic way" and always do that.
But I like languages where even if you do things the wrong way, the long-winded way, build up everything yourself from first principles rather than knowing the right library or function to use ... it's still damned fast.
Interestingly, if I use Python more like the JavaScript then it's actually a bit faster:
Mac-mini:programs bruce$ (echo 't=0;i=0'; echo 'while i<100000000: t+=i;i+=1'; echo 'print t') | time python
4999999950000000
6.75 real 6.30 user 0.09 sys
Suggesting that the Python range() is not a generator like the one I built in JavaScript, but actually creates an array.
I also find it annoying that (as far as I know) there is absolutely no way to put the Python on a single line.
Well, ok, turns out you can tell echo (at least some versions) to allow embedding newlines:
$ echo -e 't=0;i=0\nwhile i<100000000: t+=i;i+=1\nprint t' | time python
4999999950000000
7.31 real 6.55 user 0.11 sys
-
Edit: Or a bit faster
~$ echo 'import numpy as np; print(np.sum(np.arange(100000000)))' | time python3
4999999950000000
0.27user 0.59system 0:00.87elapsed 99%CPU (0avgtext+0avgdata 807240maxresident)k
0inputs+0outputs (0major+102682minor)pagefaults 0swaps
numpy is cool and all, but I feel like I've seen it somewhere before, but more concisely...
# numpy
a = np.array( [[1,1], [0,1]] )
b = np.array( [[2,0], [3,4]] )
# elementwise product
a * b
NB. J
a =. 1 1 ,: 0 1
b =. 2 0 ,: 3 4
a * b
# numpy - matrix product
np.dot(a, b)
NB. J - matrix product
a +/ . * b
# numpy - uniform pseudo random
a = np.random.random( (2,3) )
NB. J - uniform pseudo random
a =. ? 2 3 $ 0
# numpy - sum all array elements - implicit ravel
a.sum(a)
NB. J - sum all array elements - explicit ravel
+/ , a
# numpy
b = np.arange(12).reshape(3,4)
# sum of each column
b.sum(axis=0)
# min of each row
b.min(axis=1)
# cumulative sum along each row
b.cumsum(axis=1)
# transpose
b.T
NB. J
b =. 3 4 $ i. 12
NB. sum of each column
+/ b
NB. min of each row
<./"1 b
NB. cumulative sum along each row
+/\"0 1 b
NB. transpose
|: b
Not to mention the 60 year old version of this that used hieroglyphics on a special keyboard.
-
... Suggesting that the Python range() is not a generator like the one I built in JavaScript, but actually creates an array....
In Python 2, range() returns a list and xrange() returns an iterable [object].
In Python 3, range() returns an iterable as that is what most usually want.
-
Edit: Or a bit faster
~$ echo 'import numpy as np; print(np.sum(np.arange(100000000)))' | time python3
4999999950000000
0.27user 0.59system 0:00.87elapsed 99%CPU (0avgtext+0avgdata 807240maxresident)k
0inputs+0outputs (0major+102682minor)pagefaults 0swaps
Or you could use the language everybody complains about being slow:
> /usr/bin/time raku -e "say [+] ^100000000"
4999999950000000
0.14user 0.02system 0:00.13elapsed 123%CPU (0avgtext+0avgdata 115768maxresident)k
0inputs+0outputs (0major+6745minor)pagefaults 0swaps
and most of that time is raku startup (one of the places where it is slow):
> /usr/bin/time raku -e ""
0.13user 0.00system 0:00.11elapsed 121%CPU (0avgtext+0avgdata 112340maxresident)k
0inputs+0outputs (0major+6023minor)pagefaults 0swaps
(and cpu usage greater than 100% is perfectly normal)
-
.
-
Throw some proper language in...
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
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
scratch % go build loop.go
scratch % time ./loop
4999999950000000
./loop 0.06s user 0.00s system 47% cpu 0.130 total
Target
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 :-DD
-
Edit: Or a bit faster
~$ echo 'import numpy as np; print(np.sum(np.arange(100000000)))' | time python3
4999999950000000
0.27user 0.59system 0:00.87elapsed 99%CPU (0avgtext+0avgdata 807240maxresident)k
0inputs+0outputs (0major+102682minor)pagefaults 0swaps
Fun fact: NumPy is mosty C. >:D
-
Well python is basically a way to cheaply glue bits of C together so yeah.
-
... 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/ (https://pdl.perl.org/)
in the sequence go https://www.cpan.org (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 (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
-
Throw some proper language in...
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
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
scratch % go build loop.go
scratch % time ./loop
4999999950000000
./loop 0.06s user 0.00s system 47% cpu 0.130 total
Target
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 :-DD
The problem is that go suffers from the same evil that python does, significant white space. >:D
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 {
-
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.
-
... 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).
-
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.
-
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.
-
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. >:D 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.
-
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. >:D 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 :-DD
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!
-
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.
-
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.
-
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. >:D 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 :-DD
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.
-
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? >:D
-
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. >:D 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 :-DD
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.
-
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.
-
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. :-//
-
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.
-
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 (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 ???
-
(and cpu usage greater than 100% is perfectly normal)
This opens a whole new world of possibilities.
-
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.
-
.
-
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.
-
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:
(
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:
(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$
-
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.
-
Where that falls apart for many languages is sensitivity to additional space, many languages will reject white space within a variable name.
-
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.
-
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.
Amazing number of successful languages with no phonetic basis. Hmm.
We can throw art and a bit of psychology in here too. Negative space has contrast and meaning too.
And sometimes you can use it to take the piss
-
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.
Amazing number of successful languages with no phonetic basis. Hmm.
I'm not sure any surviving writing languages have no phonetic basis. If you show me a Chinese character I don't know I can take a guess at roughly how to say it, and be in the ballpark about half the time. However, I'll guess a Cantonese pronunciation, which might be quite different from the Mandarin, Korean or multiple Japanese readings of the same character. Of course, every spoken language has a strong phonetic basis. Each one has its own limited set of phonemes it recycles in different patterns to make a large vocabulary with a distinctive audible character for that language. Some languages even have multiple phoneme sets used in different areas - e.g. US English has a different phoneme set from the English spoken everywhere else. That's why most US voice recognition systems generally do quite well over a wide range of US regional accents, but work poorly for English speakers from other countries.
-
Ironically, Algol68 is, of classic 3rd generation languages, the one closest to being an algebraic formalism; almost everything is an expression that delivers a value, even declarations. Its orthogonality is unchallenged in that generation of languages.
If one has problems searching for something in a program written in a language like algol one needs either a better editor or better discipline. Given that modern IDEs (and even compilers) will even try to correct your spelling of a misnamed variable I think it's a null concern.
e.g.
int main (int argc, char const *argv[])
{
int a_variable;
a_varaible = 1;
return 0;
}
cerebus@shu:~/Desktop$ cc -o Mispelling Mispelling.c
Mispelling.c:5:5: error: use of undeclared identifier 'a_varaible'; did you mean 'a_variable'?
a_varaible = 1;
^~~~~~~~~~
a_variable
Mispelling.c:3:9: note: 'a_variable' declared here
int a_variable;
^
1 error generated.
-
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.
Yes, you nit-picker! With the exceptions mentioned. But, "whitespace" encompasses at least three characters, space, tab and newline (if we're limiting ourselves to the 7-bit ASCII subset of UTF-8, which is reasonable to most code). I'm a bit on the fence with the newline (depends on language), but I'm firmly of the opinion that one space or 20, one tab or two, all these must count as "whitespace" syntactically.
If the compiler cares beyond that, it is broken. Or written by an idiot.
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.
Yes, yes, and yes. I understand all this. But undistinguishable characters carrying meaning, no.
-
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:
(
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:
(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$
Those semicolons are just whitespaces with the pen down >:D
Edit: I've actually come to the conclusion that Algol 68 is retarded there.
I mean imagine the shenanigans where "experts exchange" and "expert sex change" evaluate to the same identifier :-//
-
Ironically, Algol68 is, of classic 3rd generation languages, the one closest to being an algebraic formalism; almost everything is an expression that delivers a value, even declarations. Its orthogonality is unchallenged in that generation of languages.
If one has problems searching for something in a program written in a language like algol one needs either a better editor or better discipline. Given that modern IDEs (and even compilers) will even try to correct your spelling of a misnamed variable I think it's a null concern.
e.g.
int main (int argc, char const *argv[])
{
int a_variable;
a_varaible = 1;
return 0;
}
cerebus@shu:~/Desktop$ cc -o Mispelling Mispelling.c
Mispelling.c:5:5: error: use of undeclared identifier 'a_varaible'; did you mean 'a_variable'?
a_varaible = 1;
^~~~~~~~~~
a_variable
Mispelling.c:3:9: note: 'a_variable' declared here
int a_variable;
^
1 error generated.
The compilers are getting pretty helpful. Editors not so much. The compiler is only being helpful because its looking for anomalies. If it flagged everything that was similar but not identical, you'd get a useless flood of reports. Having had a LOT of trouble comparing Unicode strings that can take numerous forms, I'd like to keep my life simple by making objects have only a single distinct form.
-
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.
Yes, you nit-picker! With the exceptions mentioned. But, "whitespace" encompasses at least three characters, space, tab and newline (if we're limiting ourselves to the 7-bit ASCII subset of UTF-8, which is reasonable to most code). I'm a bit on the fence with the newline (depends on language), but I'm firmly of the opinion that one space or 20, one tab or two, all these must count as "whitespace" syntactically.
If the compiler cares beyond that, it is broken. Or written by an idiot.
That was really my point though. All this is down to semantics and we took those semantics from written languages because there is parity, so whitespace is both important and unimportant depending on the context of the usage even if it has no obvious functional value. In written languages, we use leading spaces to define blocks, indentation to define quotes and subtexts etc so there is contextual functional value.
If you then throw humans at it, you're going to get this happen at least once. It did, with Python and YAML. And it works reasonably well.
The only inexcusable things that we did as a species was conflate the issue by introducing the tabulation meta-character which is about as well defined as an amorphous blob of dog poop stuck to your shoe and entirely invisible in situ. The abstract conversions between that and spaces are a war crime and drove much polarising thought around language design.
Now when I write a lexical analyser, which I do occasionally, it will as a rule consume insignificant whitespace as part of the language specification. Scopes will be defined as curly braces too. But that's not because it's semantically better but because it's a hell of a lot easier to write a simple parser stack if you actually hint it in some way.
We don't use whitespace as a rule, not because we can't or shouldn't, but because our historical compilers are stupid and the programmers were lazy. I know I am both :-DD
-
Came here to say that I find it nearly comical that there are professional programmers, proficient in multiple languages, that feel the use of white space for flow control is a deal breaker.
C'mon you guys. The recent thread about tabs vs spaces highlighted how oddly important this is to some of you, but every editor and IDE that I use makes consistent indenting effortless. Tab to go up one level and shift-tab to go down. Every one of those editors will insert spaces instead of tab characters if that's what you want, but that's nearly immaterial.
Considering that moving between the different languages always requires some degree of shift in thinking, the degree of passion seen about this particular detail is amazing. Programming languages are, by design, just a bunch of rules. Coding is an exercise in getting the job done using the rules at hand. None of this is news, nor is it news that different programmers prefer different sets of rules, or that different problems are better suited to different sets of rules. But the fact that so many programmers cling tightly to the idea that the rules should not EVER dictate how the code is arranged on the computer screen is baffling.
-
Came here to say that I find it nearly comical that there are professional programmers, proficient in multiple languages, that feel the use of white space for flow control is a deal breaker.
I don't think any of the professionals have said that it's "a deal breaker", just that it's a dumb idea. If you've had to deal with people hunting around the keyboard for the "any" key then you rapidly come to appreciate how important it is to favour the explicit over the implicit and the visible over the invisible. Indenting as flow control is invisibly implicit and hence inherently dangerous.
-
Came here to say that I find it nearly comical that there are professional programmers, proficient in multiple languages, that feel the use of white space for flow control is a deal breaker.
I don't think any of the professionals have said that it's "a deal breaker", just that it's a dumb idea. If you've had to deal with people hunting around the keyboard for the "any" key then you rapidly come to appreciate how important it is to favour the explicit over the implicit and the visible over the invisible. Indenting as flow control is invisibly implicit and hence inherently dangerous.
Hey I quite like it. My C is indented too...
-
IDLE by default transforms tabs into 4 spaces. Any editor can be configured to do the same and it is the Python standard.
You can do other indentations, and you'll have to deal with whatever problems that brings you....
https://peps.python.org/pep-0008/
Indentation: Use 4 spaces per indentation level.
Tabs or Spaces? Spaces are the preferred indentation method.
Any work team must define this to start working. In this case the Python team already gives you the preferred solution. Although you can change it if you want...
-
Throw some proper language in...
Better throw some real programming language in...
LDR R0, =100000000
EORS R1, R1
EORS R2, R2
SUBS R0, #1
loop
ADDS R1, R0
ADCS R2, #0
SUBS R0, #1
BNE loop
But 6.25 s to get correct result in R2:R1 = 0x0011c37934e58f80 (Cortex-M4@80 MHz).
Oh ho ho, here's some fun :-)
adding_arm.s:
.SYNTAX UNIFIED
.GLOBL main,printf
.THUMB_FUNC
main:
LDR R0, =100000000
EORS R1, R1
EORS R2, R2
SUBS R0, #1
loop:
ADDS R2, R0
ADCS R1, #0
SUBS R0, #1
BNE loop
LDR R0, =msg
B printf
msg:
.ASCIZ "%08x%08x\n"
adding_riscv.s
.GLOBL main,printf
main:
LI a0, 100000000
LI a1, 0
LI a2, 0
ADDI a0, a0, -1
loop:
ADD a2, a2, a0
SLTU a3, a2, a0
ADD a1, a1, a3
ADDI a0, a0, -1
BNEZ a0, loop
LA a0, msg
J printf
msg:
.ASCIZ "%08x%08x\n"
$ arm-linux-gnueabihf-gcc adding_arm.s -o adding_arm -static
$ time qemu-arm ./adding_arm
0011c37934e58f80
real 0m0.304s
user 0m0.304s
sys 0m0.000s
$
$ riscv64-unknown-elf-gcc adding_riscv.s -o adding_riscv -march=rv32ic -mabi=ilp32
$ time qemu-riscv32 adding_riscv
0011c37934e58f80
real 0m0.242s
user 0m0.238s
sys 0m0.004s
Who needs steeeekin' condition codes?
For the curious, the generated code:
000103e8 <main>:
103e8: 4808 ldr r0, [pc, #32] ; (1040c <msg+0xc>)
103ea: 4049 eors r1, r1
103ec: 4052 eors r2, r2
103ee: 3801 subs r0, #1
000103f0 <loop>:
103f0: 1812 adds r2, r2, r0
103f2: f151 0100 adcs.w r1, r1, #0
103f6: 3801 subs r0, #1
103f8: d1fa bne.n 103f0 <loop>
103fa: 4805 ldr r0, [pc, #20] ; (10410 <msg+0x10>)
103fc: f004 b956 b.w 146ac <_IO_printf>
00010400 <msg>:
10400: 78383025 .word 0x78383025
10404: 78383025 .word 0x78383025
10408: 0000000a .word 0x0000000a
1040c: 05f5e100 .word 0x05f5e100
10410: 00010400 .word 0x00010400
00010144 <main>:
10144: 05f5e537 lui a0,0x5f5e
10148: 10050513 addi a0,a0,256
1014c: 4581 li a1,0
1014e: 4601 li a2,0
10150: 157d addi a0,a0,-1
00010152 <loop>:
10152: 962a add a2,a2,a0
10154: 00a636b3 sltu a3,a2,a0
10158: 95b6 add a1,a1,a3
1015a: 157d addi a0,a0,-1
1015c: f97d bnez a0,10152 <loop>
1015e: 00000517 auipc a0,0x0
10162: 00c50513 addi a0,a0,12 # 1016a <msg>
10166: 1f60006f j 1035c <printf>
0001016a <msg>:
1016a: 3025
1016c: 7838
1016e: 3025
10170: 7838
10172: 000a
Thumb2: 44 bytes (as A32 it's 60 bytes)
RISC-V: 48 bytes
-
Throw some proper language in...
Better throw some real programming language in...
Yes.
+/⍳99999999
-
Came here to say that I find it nearly comical that there are professional programmers, proficient in multiple languages, that feel the use of white space for flow control is a deal breaker.
Say, you are a professional bus driver.
The bus has a feature than instead of steering wheel, you have this steering knob which you need to crank up to go left, and down to go right. The knob can also turn freely in every direction, and if you accidentally turn it left, full brakes will be applied, so you better be careful not to do it.
You can totally get used to it if you want, but almost every other bus uses steering wheel.
Is this a deal breaker?
Some design choices just are atrociously stupid. You can accept to work around them, of course, but don't be surprised if some find them deal breakers.
-
That was really my point though. All this is down to semantics and we took those semantics from written languages because there is parity, so whitespace is both important and unimportant depending on the context of the usage even if it has no obvious functional value. In written languages, we use leading spaces to define blocks, indentation to define quotes and subtexts etc so there is contextual functional value.
And no typographer would make the structure of the text dependent on small amounts of whitespace. It is not good form.
If you then throw humans at it, you're going to get this happen at least once. It did, with Python and YAML. And it works reasonably well.
The only inexcusable things that we did as a species was conflate the issue by introducing the tabulation meta-character which is about as well defined as an amorphous blob of dog poop stuck to your shoe and entirely invisible in situ. The abstract conversions between that and spaces are a war crime and drove much polarising thought around language design.
The only sensible solution is to treat it like it looks to the naked eye, as whitespace. Further significance (count, character code et c.) must be disregarded.
Now when I write a lexical analyser, which I do occasionally, it will as a rule consume insignificant whitespace as part of the language specification. Scopes will be defined as curly braces too. But that's not because it's semantically better but because it's a hell of a lot easier to write a simple parser stack if you actually hint it in some way.
We don't use whitespace as a rule, not because we can't or shouldn't, but because our historical compilers are stupid and the programmers were lazy. I know I am both :-DD
I am a simple parser; also both dumb and lazy. Therefore I humbly suggest the use of curly braces.
-
There are many of us who quite like the way Python takes into account the identation to separate blocks.
I think it's an elegant way to use identation, which everyone should do in any program, to get rid of annoying curly braces.
Anyway, there is no need to criticize Python to justify not using it. Almost anyone can decide whether to go into Python programming or decide to go into something else.
-
.
-
There are many of us who quite like the way Python takes into account the identation to separate blocks.
I think it's an elegant way to use identation, which everyone should do in any program, to get rid of annoying curly braces.
I use indentation to give the source some structure, but just a few spaces per block/step. Too many spaces would make the source harder to manage, at least for me. And I try to avoid tabs. If you write some complex code and use large indentations you would need an extra wide monitor or two to be able to see what you're doing - very unergonomic. However, I like curly braces and I will keep using them. This is the result of my personal experience of learning many (not just a few) programming languages over the years.
-
There are many of us who quite like the way Python takes into account the identation to separate blocks.
I think it's an elegant way to use identation, which everyone should do in any program, to get rid of annoying curly braces.
I use indentation to give the source some structure, but just a few spaces per block/step. Too many spaces would make the source harder to manage, at least for me. And I try to avoid tabs. If you write some complex code and use large indentations you would need an extra wide monitor or two to be able to see what you're doing - very unergonomic. However, I like curly braces and I will keep using them. This is the result of my personal experience of learning many (not just a few) programming languages over the years.
If you're getting too deep with indentation you probably should be creating more functions and calling them instead.
ALL my code is 1-2 levels deep in a function max, regardless of language. As complicated as it gets is a switch wrapped in a loop for a state machine and those are slowly moving into dispatch / function pointer tables.
-
Let's go on a bit of a tangent, then, related to blocks delimiters. (Python and Makefiles use indentation and not delimiters; and Makefiles' one is even more annoying, because it does distinguish between tab and space as the first character in indentation. I avoid that mess by using four spaces per indentation level in Python, and only a single tab in Makefiles.)
It seems that those who dislike indentation, prefer braces AKA curly brackets, { and } as the block delimiters. These are used in many languages (C, C++, Java, Javascript, Awk, CSS, Tex/LaTeX/MathJax) which makes them familiar to many. Are there any better suggestions?
Some languages (note I'm using 'languages' as the superset of 'programming languages', 'domain-specific languages', and 'markup languages' here) use different delimiters. The most different being the way XML has each block start paired with a corresponding end block, <tag ... >...</tag>; and later versions of Fortran's do/for/while/etc. paired with an end with an optional block type (i.e.end do,end for, etc.) The XML one has proven problematic for humans (especially since things like <a>...[/url] are typical human "errors"), leading to abandonment of XHTML in current HTML version, HTML5.
I've mentioned before in other threads that I myself like a variant of LaTeX, but with escape sequences that ensure the block structure characters do not occur anywhere else in the stream. For example, if { begins a block, | separates sibling blocks, } ends a block, and \ precedes an escape sequence, I'd prefer \/, \(, \), and \! to escape \ { } | in the content, correspondingly. It may not be a good idea for a programming language, because code must be maintainable and therefore easy for humans to understand at a glance; but for markup languages, it beats the shit out of XML and others in parser speed, efficiency, and possibilities (which include parsing the stream backwards), with just a couple of characters worth of buffering either way.
It is also notable that both ASCII and Unicode include dedicated control characters (and dedicated control glyphs in Unicode, in addition to the ASCII ones). Should we at some point switch from plain ASCII source code formats, into structured formats where the editor displays the code in whatever format the programmer wants – be that whitespace-indented or brace delimited or something more funky – and just uses a markup language underneath?
-
Interesting. I actually wrote a programming language inside Microsoft Word a few years back for document automation using VSTO. That was fully structured without ASCII and used nested document placeholders with expressions and a relatively powerful scheme-like meta-language. This was entirely processed server-side to generate PDFs for printing and mail outs for large financial companies. It allowed "normal users" to write documents programmatically. This was an extremely well received bit of tech that pushed the company into the market leading position overnight.
-
If you're getting too deep with indentation you probably should be creating more functions and calling them instead.
ALL my code is 1-2 levels deep in a function max, regardless of language. As complicated as it gets is a switch wrapped in a loop for a state machine and those are slowly moving into dispatch / function pointer tables.
That would be just two nested if-else? And yes, I already write a lot of functions. But in some situations an additional function would make things more cumbersome, waste ressources, or make an algorithm hard to comprehend.
-
I don't particularly like or dislike the enforced indentations. I wish they would have enforced a single way to do it though. Either exactly four spaces, a good compromise between easy to distinguish level and things falling off the screen to the right. Or a single tab character per indentation level, and let people choose themselves in their editor setting how it is displayed. Or something different, as long as it was absolute, universal and no exceptions.. And yes, the common advise is that you shouldn't nest very deep or very long code blocks anyway. Make more and more powerful abstractions instead.
I have no strong preference for python in general. It gives me the possibility to write efficient high level scripts, with a lot of power from tons of libraries. I understand there are other languages which provides this as well, perl being the one I've put the most effort towards. Perl has some nifty features to it, but the page long cartoon swear dialog just doesn't appeal to my code comprehension skills.
By the way, I didn't know until recently that you are "allowed" to
for word in ['hello','world]: print(word)on a single line, as long as it is a single line. That's just seems like an unnecessary exception to me.
-
There are many of us who quite like the way Python takes into account the identation to separate blocks.
I think it's an elegant way to use identation, which everyone should do in any program, to get rid of annoying curly braces.
They're only annoying if you have difficulty comprehending the idea of
unit_sequence ::= unit_sequence ";" unit
| unit
unit :: = "{" unit_sequence "}"
| ...
the equivalent to discarding bracketing to indicate compound statements in written English would be to discard full stops and initial capitals on sentences and to then require a specific sequence of spacing to indicate the starts and ends of sentences it is doable but as you can see discarding just that element of punctuation makes written English harder to read I really don't get why some people are so frightened by a balanced brace or seven then again judging from the way some people write on here the idea of paragraphs sentences and restricting a paragraph to exploring a single idea are alien concepts of course the group that has most difficulty with the ideas in English are young children while they learn to marshal their thoughts and get to grips with the rules of writing whether that is an analogy for the people who are bothered by annoying braces or merely a stand alone observation I do not know
-
I don't particularly like or dislike the enforced indentations. I wish they would have enforced a single way to do it though. Either exactly four spaces, a good compromise between easy to distinguish level and things falling off the screen to the right. Or a single tab character per indentation level, and let people choose themselves in their editor setting how it is displayed. Or something different, as long as it was absolute, universal and no exceptions.
The first thing any team using python professionally does is (1) pick a rule for indentation that everybody uses (2) enforces it with pylint and check-in/build pipeline rules. The second thing they do is learn to use 'blame' in git to find the buggers who can't stick to the rules and/or find creative ways of circumventing the enforcement mechanisms.
-
So, continuing the above metaphor, some might argue that open and close braces are training wheels for learning how to logically indent. I am just joking. Either braced or brace-less works for me.
-
Let's go on a bit of a tangent, then, related to blocks delimiters. (Python and Makefiles use indentation and not delimiters; and Makefiles' one is even more annoying, because it does distinguish between tab and space as the first character in indentation. I avoid that mess by using four spaces per indentation level in Python, and only a single tab in Makefiles.)
It seems that those who dislike indentation, prefer braces AKA curly brackets, { and } as the block delimiters. These are used in many languages (C, C++, Java, Javascript, Awk, CSS, Tex/LaTeX/MathJax) which makes them familiar to many. Are there any better suggestions?
Again, one of personal favourites come to the fore, Algol68. As well as BEGIN and END for blocks (which isn't, and wasn't then, unique) it also has IF ... THEN ... ELSE ... FI, DO ... OD, CASE ... IN ... ESAC to make "unitary clauses" from "serial clauses". The great advantage here is the additional information provided to both the programmer and the compiler as to what kind of block is being closed.
void junk(void)
{
for (i = 1; i <11; i++)
{
switch (i)
{
...
}
}
}
Has a crowd of undifferentiated closing braces (which relies on indenting for easy human comprehension), whereas in:
PROC junk = (VOID) VOID:
BEGIN
FOR i FROM 1 TO 10
DO
CASE i IN
...
ESAC
OD
END
it is immediately obvious which type of clause each closing 'brace' is closing.
Also, I don't think anybody dislikes indentation per se, merely the reliance on indentation for semantics.
-
So, continuing the above metaphor, some might argue that open and close braces are training wheels for learning how to logically indent. I am just joking. Either braced or brace-less works for me.
Another bit of English that people have difficulty with in here is the difference between analogy, metaphor, simile, allegory and literalism. >:D
Edit: And don't get me started on litotes ...
-
Also, I don't think anybody dislikes indentation per se, merely the reliance on indentation for semantics.
This.
-
This is a flame war similar/analogous to the war between spaces and tabs. Just as futile and endless.
Does anyone really believe that Python should be less popular for using meaningful indentation?
Well, they are wrong. Python is popular, very popular, and I don't think indentation has had much to do against it. Rather, it may have been a factor in its favor.
-
.
-
I have proposed several pages earlier to compare Python's library system with that of other languages (JavaScript in particular).
Someone, now I don't remember who, argued that Python libraries were not mature and settled.
On the other hand it has been argued that JavaScript has many more libraries than Python, but the number is not the most important thing. Are JavaScript libraries really better? It's not a language particularly dear to me, but if it turns out to have better libraries I'll give it a try.
-
This is a flame war similar/analogous to the war between spaces and tabs. Just as futile and endless.
Does anyone really believe that Python should be less popular for using meaningful indentation?
Well, they are wrong. Python is popular, very popular, and I don't think indentation has had much to do against it. Rather, it may have been a factor in its favor.
Again the fixation on "popular". If popular is the touchstone, then the McDonalds' burger is the best food in the world both in terms of gastronomy and nutritional value, except that we know it isn't. Why can you not get it into your head that discussing the merits and demerits of a programming language cannot be judged by popularity. Should we start to judge all-time musical talent by who currently tops the Billboard 100, no. Only dyed-in-the-wool Harry Styles fans would take a contrary position to that "no".
At this point it really is difficult to judge your position as anything other than unalloyed fanboyism, I can't think of one point that counts as a demerit in python's case that you've been prepared to concede. Even categorising what has largely been a balanced and reasonable discussion as "a flame war" lends credence to categorising your allegiance to python as wholehearted and brooking no criticism - a "fanboy" position if ever there was one. You just keep repeatedly coming back to the "popular == best" position.
-
Again the fixation on "popular". If popular is the touchstone, then the McDonalds' burger is the best food in the world both in terms of gastronomy and nutritional value, except that we know it isn't.
I remember when COBOL was the most popular language by far. It was never popular with me. I had nothing against it, but I never did the kind of work where it excelled. Any meaningful assessment of computer language popularity has to include "for doing xxxx". Otherwise the most popular language is mostly about which type of development work is hot this week.
-
Again the fixation on "popular". If popular is the touchstone, then the McDonalds' burger is the best food in the world both in terms of gastronomy and nutritional value, except that we know it isn't. Why can you not get it into your head that discussing the merits and demerits of a programming language cannot be judged by popularity. Should we start to judge all-time musical talent by who currently tops the Billboard 100, no. Only dyed-in-the-wool Harry Styles fans would take a contrary position to that "no".
At this point it really is difficult to judge your position as anything other than unalloyed fanboyism, I can't think of one point that counts as a demerit in python's case that you've been prepared to concede. Even categorising what has largely been a balanced and reasonable discussion as "a flame war" lends credence to categorising your allegiance to python as wholehearted and brooking no criticism - a "fanboy" position if ever there was one. You just keep repeatedly coming back to the "popular == best" position.
I like Python's indentation system and others don't. Is it really a merit or demerit of the language? only tangentially, I don't consider it such an important factor.
If you don't like the term flame war, why are you writing in a way that could be construed as flaming?
I admit that I like Python. from there to fanboyism is a long way. Others should admit that they are Python haters.
I have admitted before and on several occasions that this discussion serves me to learn more about this language I like (Python) and I learn both its merits and demerits. Both the things I like about the language and the things others don't like (sometimes the same things).
This gives me a broader opinion about the language and I think many others as well.
As for the equation "popular" equals "best" I agree that this is not the case on many (most) occasions.
In particular, programming languages have applications for which they are good and applications for which they are not. It would be foolish to try to program an operating system with Python any more than you would program a web manager in C.
My proposal is that in programming languages, popularity (number of programmers using it) does have some relation to its relative merit.
C has been for years in that position and it will not be precisely because of its demerits.
But I don't want to make a flame war out of this opinion, so I will try not to defend my opinion in order to do my bit to avoid it.
To get back to the interesting part, if I would like to address the merits or demerits of the Python library system compared to those of other languages.
-
I can't think of one point that counts as a demerit in python's case that you've been prepared to concede.
Here you have it. I am going to start a summary and expand on it.
Merits and demerits of Python:
Speed:
Python imperative programming are slow. 50 times slower than C. (demerit)
Python can do very fast computations thanks to its libraries, such as numpy (merit)
Python has functional programming, faster than imperative programming (merit)
Code blocks and indentation
Python uses colons and indentation to separate blocks.
This is a merit for some people and a demerit for others.
Easy of programming
Python is very easy to program.
It is a good language to start learning programming. (merit)
This leads to a lot of code written by bad programmers. (demerit)
Code maintainability
Python helps to make code easily maintainable in the long term. (merit)
Libraries
Python has a large number of libraries (>300000).
Many for Artificial Intelligence, Big Data processing, Scientific, Web development. (merit)
Security issues relating the big number of libraries and dependencies (demerit)
Language updates
Frequent language updates that keep it up to date. (merit)
Frequent changes that are no longer compatible with previous versions (demerit)
Documentation and help
Python has many good free and paid manuals. (merit)
Python has a large, very active community of programmers from which help is readily available. (merit)
Multiplatform
Python is multiplatform and runs on Unix, Windows and Mac. Recently in a web client as well. (merit)
Cross-platform libraries present certain problems (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4168792/#msg4168792) (demerit)
-
If you don't like the term flame war, why are you writing in a way that could be construed as flaming?
Casting mild criticism as "flaming" is characteristic of someone who (1) is very sensitive to criticism of the mildest sort, (2) has never been flamed or they'd know it for what it is. It's also a poor debating technique as it's characterising the person as being somehow "nasty" to you as a way to discount their arguments when in fact they're not.
As for the equation "popular" equals "best" I agree that this is not the case on many (most) occasions.
If you agree with that then, why, oh why, oh why, do you keep coming back to discounting whatever the last argument made was with words to the effect "but python is popular, very popular"? If you admit it to be a futile [non-]argument, why keep making it?
-
The great advantage here is the additional information provided to both the programmer and the compiler as to what kind of block is being closed.
Is it an advantage? (I am undecided either way myself.)
For HTML, dedicated end blocks are an issue with human-written markup, since they are often erroneous.
Perhaps a compiler should be more strict than a browser, but then again, many programmers disable compiler warnings because they feel there are too many false positives there.
For Bash and POSIX shells, which have a somewhat similar blocking syntax (do...done, if...then...elseif...then...else...fi, and so on), I do not see any advantage of having a specific end-of-block compared to just a closing brace; and I do use Bash/Dash a lot. (When editing dense code, I first copy it and spread it out with correct indentation, do the edits, then compact it back again, replacing the original. Perhaps others pride themselves in working directly on the dense code? To me, reducing the likelihood of me making a typo or a thinko is more important.)
-
If you agree with that then, why, oh why, oh why, do you keep coming back to discounting whatever the last argument made was with words to the effect "but python is popular, very popular"? If you admit it to be a futile [non-]argument, why keep making it?
Because I agree that the popularity of C, Python, Java, etc. stems in part from their merits as languages. But I don't want to continue with that argument, which I can see is not well received.
-
If you don't like the term flame war, why are you writing in a way that could be construed as flaming?
Casting mild criticism as "flaming" is characteristic of someone who (1) is very sensitive to criticism of the mildest sort, (2) has never been flamed or they'd know it for what it is. It's also a poor debating technique as it's characterising the person as being somehow "nasty" to you as a way to discount their arguments when in fact they're not.
I don't dismiss your arguments, I read all of them with interest.
But there are sentences that are not arguments and try to be offensive. I don't consider myself a Python fanboy, but I'm not going to change my mind no matter how much you argue if my arguments seem better to me.
I also understand perfectly well that for many it is better to use tabs and for others spaces. No one is right and everyone is right.
The fact that I prefer spaces does not make me a fanboy of them and I understand that others have equally valid reasons for preferring tabs.
Arguing about that can be considered a flame war or a holy war. In any case there comes a time when all the arguments are exposed and there is no more to be gained by talking about it.
That's the reason I was trying to get back to a productive discussion about Python libraries.
-
The great advantage here is the additional information provided to both the programmer and the compiler as to what kind of block is being closed.
Is it an advantage? (I am undecided either way myself.)
Well I've certainly found myself, after making substantial edits to a chunk of code (both my own, and others') that uses the curly brace for everything, with a bunch of the little buggers all crowded together needing re-indenting to make sense of them, or been uncertain which "}" belongs to which "{" when trying to excise some code out of the middle of something for refactoring or simplification (easy if you're using an editor that allows block folding, hard if you're trying to edit a Jupiter firewall configuration with nothing more than SSH to your name).
For HTML, dedicated end blocks are an issue with human-written markup, since they are often erroneous.
Perhaps a compiler should be more strict than a browser, but then again, many programmers disable compiler warnings because they feel there are too many false positives there.
For Bash and POSIX shells, which have a somewhat similar blocking syntax (do...done, if...then...elseif...then...else...fi, and so on), I do not see any advantage of having a specific end-of-block compared to just a closing brace; and I do use Bash/Dash a lot. (When editing dense code, I first copy it and spread it out with correct indentation, do the edits, then compact it back again, replacing the original. Perhaps others pride themselves in working directly on the dense code? To me, reducing the likelihood of me making a typo or a thinko is more important.)
I personally tend to write with a higher proportion of whitespace to code than anyone else I know, I like my code to look tidy and structured as well as be it, and I still find the absence of cues as to what "{" belongs to what "}" a poor second to explicit types of ending tags. I end up putting a lot of "} // if (<whatever>)" and the like at the ends of anything significant.
-
Libraries
Python has a large number of libraries (>300000).
Many for Artificial Intelligence, Big Data processing, Scientific, Web development.
At the same time it's also a drawback security-wise if you have to rely on several libs to be secure. This is a problem in general, not just for Python. For example, keeping a web CMS, forum or whatever framework with plenty of plugins safe is hard work as new security issues in the frameworks or plugins are detected all the time. Simply follow security related lists and you'll see how much can go wrong. A typical real world scenario is that a bad security bug is found in WordPress plugin X and someone adds that to his scanning bot to automatically seize control of WordPress instances running that specific vulnerable plugin. In a short time the bad guy controls 30k WordPress instances.
-
If you agree with that then, why, oh why, oh why, do you keep coming back to discounting whatever the last argument made was with words to the effect "but python is popular, very popular"? If you admit it to be a futile [non-]argument, why keep making it?
Because I agree that the popularity of C, Python, Java, etc. stems in part from their merits as languages. But I don't want to continue with that argument, which I can see is not well received.
Seeing as I’ve had a couple of Sunday afternoon beers I’ll kick off here. I am with you on this.
To note the discussions on here are mostly prejudice from bitter folk akin to slashdot circa 1999, primarily from academic backgrounds at best. Few have worked on large or complicated products and codebases.
I just did a monumentally long time (with some gaps) in the fintech market and it’s all Python, Java and C (and now some Go). Plus some sick fucks using C#. The market demand is insane for python developers and the reason is because of the language’s merits which are clarity, ubiquity and scope.
This thread and it’s participants represent 0.0001% of reality. Shrug and move on. And with that I’m moving on (and with no irony updating my eBay scraping python scripts running in AWS Lambda).
My next job will probably be python because really it’s the language least likely to hold me down and teabag me. C++ and JavaScript being the diametric opposite side of the fence.
-
Thats the disadvantage of using some popular frameworks/platforms.. Obscure ones may be better in that respect..
-
But it's running in circles: many of us have patiently pointed out that popularity and intrinsic merit had usually little to do with one another.
Analyzing the reasons why some language is popular is always interesting, but if you want to do it in a scientific manner, as any scientific study, you shouldn't come up with a preconceived idea of why this is so.
(To be fair though, "popularity" is essentially a sociologic matter, and while many these days are trying to pretend sociology is actually a science, well. Sure. :popcorn: )
Another point is judging "popularity" by basically how much people talk about some topic online (which is the main way TIOBE and such work) is flawed. The reasons people talk about something might be very different from one topic to another. The reasons why C has been "popular" for a long time may be pretty different form the reasons why Python has become popular. One telling example of this is, why C has been #1 or #2 for many years in TIOBE and the like, it did absolutely not tell you that that's the language for which there were the most developers in the world. It's been hard to find C developers for at the least one decade if not two, despite the language being classified "popular" in various popularity indices.
As to Python, if it works for you as a tool, that is perfectly fine. If you know its strong and weak points and use it accordingly, it's even better.
Now for those who would assume Python is a modern tool just because it's trendy, its inception dates back to the 80s actually, and it itself was inspired by the ABC language, from which it borrowed much of its syntax (yes, the one that is a bit controversial.) It was more or less meant to make code look like pseudo-code. The idea is old stuff already. Not saying that old is bad necessarily, just that those thinking that's part of what makes it a modern language, uh, nah.
-
Libraries
Python has a large number of libraries (>300000).
Many for Artificial Intelligence, Big Data processing, Scientific, Web development.
At the same time it's also a drawback security-wise if you have to rely on several libs to be secure. This is a problem in general, not just for Python. For example, keeping a web CMS, forum or whatever framework with plenty of plugins safe is hard work as new security issues in the frameworks or plugins are detected all the time. Simply follow security related lists and you'll see how much can go wrong. A typical real world scenario is that a bad security bug is found in WordPress plugin X and someone adds that to his scanning bot to automatically seize control of WordPress instances running that specific vulnerable plugin. In a short time the bad guy controls 30k WordPress instances.
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
Or do you have a problem that can be encountered when installing libraries such as numpy and its dependencies?
-
If you don't like the term flame war, why are you writing in a way that could be construed as flaming?
Casting mild criticism as "flaming" is characteristic of someone who (1) is very sensitive to criticism of the mildest sort, (2) has never been flamed or they'd know it for what it is. It's also a poor debating technique as it's characterising the person as being somehow "nasty" to you as a way to discount their arguments when in fact they're not.
I don't dismiss your arguments, I read all of them with interest.
But there are sentences that are not arguments and try to be offensive. I don't consider myself a Python fanboy, but I'm not going to change my mind no matter how much you argue if my arguments seem better to me.
Trust me, if I was trying to be offensive you'd know it. However, that is not my style unless provoked beyond my tolerance. Fanboy is not, in and of itself, offensive, merely descriptive and was intended as such, you're being way too sensitive. Check out the dictionary definition if you don't believe me "s boy or man who is an extremely or overly enthusiastic fan of someone or something" (Mirriam-Webster). If it was generally received as pejorative they would say so, cf "asshole - usually vulgar : a stupid, annoying, or detestable person" (also Mirriam-Webster).
-
For me it is offensive in the sense that I am impervious to arguments because I don't understand them or I don't want to understand them. It's as if you prefer tabs and you call someone who prefers spaces a fanboy because they don't want to think like you.
I am a person very little attached to militancy. And I also love to change my mind when I am really convinced that something is different from what I thought.
I find that science and technology are prone to these types of changes of opinion and I like that.
Throughout this discussion I've seen some loopholes in Python that I didn't know about (such as its inconsistency in newer versions that aren't backwards compatible)
-
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
-
I hope it doesn't happen like Excel.
Excel: Why using Microsoft's tool caused Covid-19 results to be lost
https://www.bbc.com/news/technology-54423988 (https://www.bbc.com/news/technology-54423988)
Excel autocorrect errors still plague genetic research, raising concerns over scientific rigour
https://theconversation.com/excel-autocorrect-errors-still-plague-genetic-research-raising-concerns-over-scientific-rigour-166554 (https://theconversation.com/excel-autocorrect-errors-still-plague-genetic-research-raising-concerns-over-scientific-rigour-166554)
An alarming number of scientific papers contain Excel errors
https://www.washingtonpost.com/news/wonk/wp/2016/08/26/an-alarming-number-of-scientific-papers-contain-excel-errors/ (https://www.washingtonpost.com/news/wonk/wp/2016/08/26/an-alarming-number-of-scientific-papers-contain-excel-errors/)
Excel has ruined thousands of scientific investigations: six tips to prevent it from happening to you too
https://thenewstrace.com/excel-has-ruined-thousands-of-scientific-investigations-six-tips-to-prevent-it-from-happening-to-you-too/229595/ (https://thenewstrace.com/excel-has-ruined-thousands-of-scientific-investigations-six-tips-to-prevent-it-from-happening-to-you-too/229595/)
-
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
-
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
Most security problems come from a reality of complex systems that explains a huge number of problems that don't get caught before deployment: Its much easier to understand how something complex works, than how it fails. If you've ever worked on failure mode and effect analysis (FMEA) this comes into stark relief.
-
If you don't like the term flame war, why are you writing in a way that could be construed as flaming?
Casting mild criticism as "flaming" is characteristic of someone who (1) is very sensitive to criticism of the mildest sort, (2) has never been flamed or they'd know it for what it is. It's also a poor debating technique as it's characterising the person as being somehow "nasty" to you as a way to discount their arguments when in fact they're not.
I don't dismiss your arguments, I read all of them with interest.
But there are sentences that are not arguments and try to be offensive. I don't consider myself a Python fanboy, but I'm not going to change my mind no matter how much you argue if my arguments seem better to me.
Trust me, if I was trying to be offensive you'd know it. However, that is not my style unless provoked beyond my tolerance. Fanboy is not, in and of itself, offensive, merely descriptive and was intended as such, you're being way too sensitive. Check out the dictionary definition if you don't believe me "s boy or man who is an extremely or overly enthusiastic fan of someone or something" (Mirriam-Webster). If it was generally received as pejorative they would say so, cf "asshole - usually vulgar : a stupid, annoying, or detestable person" (also Mirriam-Webster).
I think you need to introspect a little there. Fanboy is wholly contextual and the context was carefully applied in your comment. It was verging on a personal attack against OP from a third person perspective.
We should be respectful of each other's arguments. It's fine to chuck the odd comedic point around but when the thread diverges into semantic discussions about how points are taken, then there's a line crossed somewhere. An I know that is ironic.
tl;dr: lets be better people about this and keep on topic because the topic is really interesting.
I didn't come back here to watch someone with a valid perspective get chased away or watch the moderati descend.
-
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
Oh there's a lot of python out there in a 'web framework' rôle, it's just that you don't see it because it's being used for RESTful interfaces and microservices. As far as the security of that goes I'll just say that the last job of that ilk that I worked on we spent a lot of time worrying about supply chain attacks and putting mitigations into place like not just 'pip install'-ing stuff and getting a random version of a dependency from a random place - we staged everything very carefully so that we'd know exactly what version of everything we had and where it came from. 'Modern' ecosystems, whether they be python, javascript or whatever are rife with opportunities for supply chain attacks.
-
I think you need to introspect a little there. Fanboy is wholly contextual and the context was carefully applied in your comment. It was verging on a personal attack against OP from a third person perspective.
As I've said, it wasn't intended pejoratively, in fact I was trying not to do that while still calling it as I see it, hence "fanboyism" (-ism implying the behaviour not the person) not "<pejorative adjective> fanboy". Like you say, context, and the context was: "[given your repeated returning to appeal to "popularity"] At this point it really is difficult to judge your position as anything other than unalloyed fanboyism". I don't think that verges on a personal attack because if I did I wouldn't have said it. If "fanboyism" offends substitute "uncritical personal judgement of a thing as the best while offering scant argument in its favour except that it's popular".
Anyway, let's be clear. No personal attacks intended.
-
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
It's both. As I've already said, I'm acutely aware of the potential for supply side attacks and you could characterise that as a procedural problem, but it's one comes bundled into the tools that you use because with imported libraries and frameworks you're exposing yourself to the procedural weaknesses of the people who build them.
This leads to an irony of its own. I've always been wary of the "not invented here" phenomenon and the tendency of architects/programmers to love to build their own worse version of tools that can be had for free or relatively little money. (And have had to fight tooth and nail with people who are desperate to roll-their-own, thereby busting budgets, deadlines and introducing brand new bugs all of their own.) But with imported tools comes imported risks and opacity and I sometimes find myself thinking "Wouldn't it be safer to run up our own [relatively limited] version of this tool?". It's usually at that point that I realise that what I really need is a good stiff drink.
-
PyPI security pitfalls and steps towards a secure Python ecosystem
https://www.activestate.com/blog/pypi-security-pitfalls-and-steps-towards-a-secure-python-ecosystem/ (https://www.activestate.com/blog/pypi-security-pitfalls-and-steps-towards-a-secure-python-ecosystem/)
About half of Python libraries in PyPI may have security issues, boffins say
https://www.theregister.com/2021/07/28/python_pypi_security/ (https://www.theregister.com/2021/07/28/python_pypi_security/)
The security risks of pip and PyPI
https://carles-garcia.net/python/python_pip/ (https://carles-garcia.net/python/python_pip/)
-
I imagine this applies only to web development (Django, Flask) How is Python compared to ubiquitous PHP? It seems to me that Python code tends to be more secure, considering that neither is entirely secure.
I can't answer that question. We have to wait until more Python is used for web frameworks. And we shouldn't assume anything regarding their security. There can be nasty surprises, as seen many times in the past. Also, it applies to anything, not just web stuff. Of course, it's less an issue for some data modeling run on a single PC, than something networked.
90% of the security problems are not framework or language related but procedural and poor architectural decisions leaking through into the final product.
It's both. As I've already said, I'm acutely aware of the potential for supply side attacks and you could characterise that as a procedural problem, but it's one comes bundled into the tools that you use because with imported libraries and frameworks you're exposing yourself to the procedural weaknesses of the people who build them.
This leads to an irony of its own. I've always been wary of the "not invented here" phenomenon and the tendency of architects/programmers to love to build their own worse version of tools that can be had for free or relatively little money. (And have had to fight tooth and nail with people who are desperate to roll-their-own, thereby busting budgets, deadlines and introducing brand new bugs all of their own.) But with imported tools comes imported risks and opacity and I sometimes find myself thinking "Wouldn't it be safer to run up our own [relatively limited] version of this tool?". It's usually at that point that I realise that what I really need is a good stiff drink.
This is why I am currently unemployed. I don't want to be responsible for it any more :-DD
-
Let's go on a bit of a tangent, then, related to blocks delimiters. (Python and Makefiles use indentation and not delimiters; and Makefiles' one is even more annoying, because it does distinguish between tab and space as the first character in indentation. I avoid that mess by using four spaces per indentation level in Python, and only a single tab in Makefiles.)
It seems that those who dislike indentation, prefer braces AKA curly brackets, { and } as the block delimiters. These are used in many languages (C, C++, Java, Javascript, Awk, CSS, Tex/LaTeX/MathJax) which makes them familiar to many. Are there any better suggestions?
Again, one of personal favourites come to the fore, Algol68. As well as BEGIN and END for blocks (which isn't, and wasn't then, unique) it also has IF ... THEN ... ELSE ... FI, DO ... OD, CASE ... IN ... ESAC to make "unitary clauses" from "serial clauses". The great advantage here is the additional information provided to both the programmer and the compiler as to what kind of block is being closed.
void junk(void)
{
for (i = 1; i <11; i++)
{
switch (i)
{
...
}
}
}
Has a crowd of undifferentiated closing braces (which relies on indenting for easy human comprehension), whereas in:
PROC junk = (VOID) VOID:
BEGIN
FOR i FROM 1 TO 10
DO
CASE i IN
...
ESAC
OD
END
it is immediately obvious which type of clause each closing 'brace' is closing.
Also, I don't think anybody dislikes indentation per se, merely the reliance on indentation for semantics.
We can do even better with BASIC. Yes, we can say something good about basic
for i = 1 to 10
next i
I like the idea of (optionally) having the start and end of any block marked with a tag. Just as an example, nested loops might be tagged "outer" and "inner." The same tags could be used elsewhere in the program, but if one end of a block has a tag, then there must be a matching tag at the other end.
It's a little bit interesting that some types of errors could be caught at compile time that wouldn't be caught in other languages. It's scary that C will let you write overlapping for() loops. Obviously it interprets the code in a way that you did not intend, which is to say that it's your own fault if you actually try to make overlapping for() loops. You can't expect a compiler to identify stupidity. This compiler could.
(It may or may not be interesting that overlapping for() loops are not possible in Python.)
-
Suppose Python offered an optional syntax where blocks where delimited by '{' and '}' instead of the current way. Would that cause a shift in opinion?
It think a simple script (written in Python) could convert source files back and forth between the two styles, so anyone could be writing Python my new style in an hour.
-
Suppose Python offered an optional syntax where blocks where delimited by '{' and '}' instead of the current way. Would that cause a shift in opinion?
It think a simple script (written in Python) could convert source files back and forth between the two styles, so anyone could be writing Python my new style in an hour.
One word.
exec()
An even worse feature in a language than significant whitespace.
-
exec()
The fact that a construct exists doesn't mean it should be used, other than in weird edge cases. Much like goto i suppose. For completely different reasons, but still.
-
exec()
The fact that a construct exists doesn't mean it should be used, other than in weird edge cases. Much like goto i suppose. For completely different reasons, but still.
Goto isn't a "weird edge case". If you want something more comparable to exec() in weirdness and danger, how about setjmp()/longjmp()?
-
Suppose Python offered an optional syntax where blocks where delimited by '{' and '}' instead of the current way. Would that cause a shift in opinion?
It think a simple script (written in Python) could convert source files back and forth between the two styles, so anyone could be writing Python my new style in an hour.
SHORT ANSWER ? NO.
Long answer... no.. Python is what it is.. a pathetic space based ident oriented newbie thingy..
RUBY is FAR way better.. you can do a simple direct one liner ... (like any POSIX tool )
while stream = STDIN.gets ; stream = stream.strip ; if (stream =~ /fubar/) then puts stream ; end ; end
and use a real Object oriented elegant script tool..
in long terms:
- PHP is FAR way better than JAVA or JS
- RUBY is FAR WAY better than Python... really better..
- PERL is way above them all as the real de facto POSIX tool..
For serious programming any replacement for real de facto C/C++ should be PASCAL.
Modern Object Oriented Pascal now can do things like
generic function Add<T>(aArg1, aArg2: T): T;
begin
Result := aArg1 + aArg2;
end;
SomeStr := specialize Add<String>('Hello', 'World');
SomeInt := specialize Add<LongInt>(2, 5);
And fancy tricks like
operator + (const D2,D1:TDate):longint;
operator - (const T2,T1:TTime):longint;
there is absolute no need for odd ducks...
Paul
-
I genuinely don't think anyone in this thread lives in the real world or deals with real products or real development teams or has built any significant software infrastructure on any of the tools they are commenting on. There is so much disparity the contents and reality here it's unreal.
-
I genuinely don't think anyone in this thread lives in the real world or deals with real products or real development teams or has built any significant software infrastructure on any of the tools they are commenting on. There is so much disparity the contents and reality here it's unreal.
The mileage vary... a lot..
By real .. or team.. it enumerates...
IF GOOGLE... GO or RUST.. are the hype .. you apply the job..
IF anything SYSTEMD related... Python.. that thing is the limp dick tool...
IF anything academic or de facto programming C/C++ ... FORTRAN for the gray beards..
PASCAL for entry level
EMBED? that no doubt is LUA...
POVs are BIASED
MONEY flows today into newbie distros.. totally systemd/Python biased..
(PS btw - that *** is not related with serious scopes)
Paul
-
Realistically most people start at the problem and work back to the solution with the skills and experience available on the market. Most of that is attention and interest based if anyone likes it or not. Knowing what is realistic is the exact opposite of bias.
As for limp dick, perhaps you should crank the maturity up a little bit and look at the market. I just finished a long term position at a very large fintech who's core business was developed with a limp dick tool. As with limp dicks, it's how you use it that counts :)
Europe/US/Asia markets look like this:
Embedded -> C
Desktop -> C++/C#/JavaScript(Electron)
Web -> JavaScript/Python/Go/Java/C#
Back end / data processing -> Python/Java/C#/Go mostly
HPC -> C++
Mobile -> Java/Swift
No Pascal, Lua, PHP, Rust...
Python features a lot because it's a fairly powerful language out the box, easy to deploy and manage, has good market penetration, reasonable documentation and allows people to solve problems quickly and efficiency. When applying the trifecta of compromises, it comes out pretty much in the middle.
-
I lived countless HYPES "market" things...
by 80s by 90s... by 2000s...
NOVELTY has the place... but serious stuff always surface... sooner or later.
Seriously .. Python , GO and RUST are just the "moment" hype ..
There is absolute nothing better on any of these tools..
If you (like me) lived 3 or 4 decades the HYPE IT "market" ... you know...
FORTRAN and SQL and C and PERL will not vanish or change any time soon
No matter how popular or hype are the others..
I saw countless others go and vanish... by 80...90...00...
Paul
-
Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.
Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems. People love C so much there is focus in rewriting core system utilities in other languages now.
The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on :-DD.
Some things do stay. Python is one. I first used it as the workflow descriptor DSL in CoCreate WorkManager from HP circa 1998...
-
Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.
Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems.
The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on :-DD
I don't see dead anyway...
If you ought to use OCTAVE you will be using modern FORTRAN..
If you will use MAXIMA you will use LISP like it or not...
If you are using a *NIX distro.. you are using PERL in autoconf and dozen other tools..
and you just can not replace that overnight..
Market IT "JOBS" exploit HYPE novelty solutions...
The fact remains. almost 90% we use is C based
no matter how much newbie folks like Python scripts...
It is not going to change.. it will just surface again ahead...
Paul
-
Market IT jobs, which is a very loose term, solve real business problems. That's what builds value, increases attention and provides development effort.
Things are already changing. Large vendors are building their own compiler infrastructure and languages to support the future. We now have Rust, Swift, Go etc as safe systems programming languages and a layer of scripting languages available. There have been various experimental operating systems which do not have C as a basis at all as well.
And we already have Python interpreters written in Rust available as an example of where this is going.
It's a lot to replace but it doesn't take a lot to replace it when the tools are there.
Edit: some dickhead built powershell as well. That's now not to do things.
-
not a simple change....
It is a complete AGENDA
The amount of money invested in trying to replace widespread C with RUST comes with (obviously) an undisclosed agenda...
By late 80/90s the incredible popular and widespread DELPHI could be swear the future of IT...
by late 90s MS imploded the heads .. hired key devels.. and made their own ### crappy..
thanks to hired ex-delphi devels..
nothing really new .. big pockets AGENDAS will prevail...
but the serious stuff will not vanish that easy
btw.. embed means interpreter not embed gizmos (ASM/C based)
Paul
-
Uh yeah. All those buffer overflows, CVEs and crying users are the agenda...
It's a warzone out there and you don't go in to a war with a 1960s tank.
Delphi was never an option. It was a commercial product, closed source, poor development ecosystem and targeting. People were tired of navigating licensing and compiler purchases by then which created the entire open source ecosystem really.
Edit: Note taken on embedded interpreters. Usually we use python :-DD
-
Uh yeah. All those buffer overflows, CVEs and crying users are the agenda...
It's a warzone out there and you don't go in to a war with a 1960s tank.
Edit: Note taken on embedded interpreters. Usually we use python :-DD
They will be replaced by a whole new list of new and improved BUGs...
Paul
PS> LUA was meant to be embed ... by design
Python.... well it has been hacked for RPI and stuff...
-
They will be replaced by a whole new list of new and improved BUGs...
Paul
Correct. That we can agree on :)
That's an opportunity not a problem.
As for Lua, until indices start at 0, I invoke Knuth.
-
a decade later you will check again..
^-^ ^-^ ^-^
-
a decade later you will check again..
^-^ ^-^ ^-^
Yes but this is a winner.
First time you go through the cycle it's hard and takes you 5 days to do a job
Second time you go through the cycle it's easier and takes you 3 days to do a job but you still charge for 5.
Third time you go through the cycle it's even easier and takes you 1 day to do a job but you still charge for 5.
This is how I paid my house off, charging 25 days for 5 days of work :)
-
They will be replaced by a whole new list of new and improved BUGs...
Programmers will forever be fallible and will always produce code with bugs. The idea of newer tools is to ensure those bugs are less security critical, getting away from the 'buffer overflow...here you go...have root access' kinda thing. Hence rust code coming to your kernel soon.
-
They will be replaced by a whole new list of new and improved BUGs...
Programmers will forever be fallible and will always produce code with bugs. The idea of newer tools is to ensure those bugs are less security critical, getting away from the 'buffer overflow...here you go...have root access' kinda thing. Hence rust code coming to your kernel soon.
Exactly this.
If we can nail that and supply chain attacks I might sleep again...
-
Perl is completely fucking DEAD.
No it's not. It's a ZOMBIE. The thing with dead things is that they're in the ground and can't hurt you. Zombies on the other hand...
-
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
"""
May Headline: C# gains most ranking points
If we compare the current TIOBE index rankings to 1 year ago (May 2021), C# is gaining most popular of all programming languages by far. Its rankings has increased almost 2% for the last 12 months. C# is one of the most mature programming languages in existence, supporting many modern programming paradigms. Until recently, its only disadvantage was that its Linux support was questionable, but this is changing rapidly the last couple of years. So chances are high that C# might enter the TIOBE index top 3 by replacing C. Another serious contender for this top 3 position is C++. Its long term trend, boosted by C++20, is definitely upward. -- Paul Jansen CEO TIOBE Software
"""
The Times They Are A-Changin'
-
Perl is completely fucking DEAD.
No it's not. It's a ZOMBIE. The thing with dead things is that they're in the ground and can't hurt you. Zombies on the other hand...
That’s actually a surprisingly fair description :-DD
-
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
"""
May Headline: C# gains most ranking points
If we compare the current TIOBE index rankings to 1 year ago (May 2021), C# is gaining most popular of all programming languages by far. Its rankings has increased almost 2% for the last 12 months. C# is one of the most mature programming languages in existence, supporting many modern programming paradigms. Until recently, its only disadvantage was that its Linux support was questionable, but this is changing rapidly the last couple of years. So chances are high that C# might enter the TIOBE index top 3 by replacing C. Another serious contender for this top 3 position is C++. Its long term trend, boosted by C++20, is definitely upward. -- Paul Jansen CEO TIOBE Software
"""
The Times They Are A-Changin'
I’m not sure this is actually true. Every org I see who have long term c# involvement are exiting the platform at the moment. I’m not even biased here - I’ve been using it since day one and rather like it. But Microsoft’s stewardship of the platform is a schizophrenic rollercoaster of pain and deprecation and everyone is as tired of that as me now.
-
I'm not a big fan of Microsoft or the standards it promotes, so I hope it is as you say.
Anyway, C seems to be in decline because of the push of other languages. And some of them, like Rust, intend to replace C in applications like systems programming.
-
Flash Player support has long since been discontinued. Unfortunately I have several tutorials in the web with this technology. They are old, but I didn't want to do without them yet.
Thanks to Ruffle (https://ruffle.rs/) an emulator written in Rust that runs in the browser through the use of WebAssembly, I have been able to keep the Flash Player tutorials active.
Of course the world is moving towards open standards and the move from Flash Player to HTML5 is yet another example.
Although C# is a standard, it is supported by Microsoft, which has a long history of abandoning its technologies (such as VB6, which is still in use).
One of the things I like about Python is precisely that it is a free and open software language.
-
Anyway, C seems to be in decline because of the push of other languages.
Might that be because of the high-spec hardware available at cheap prices? C is jolly good where things are a bit resource-constrained. Anything from a PIC32 down would warrant it to get the best, but nowadays people think nothing of shoving a RPi in to flash an LED, so bloaty stuff isn't a problem. For instance, Python and similar are no doubt capable and don't use much memory, but they want an entire proper OS to come along as well. For a Pi that's fine; for an ATTiny not so hot.
Perhaps C will be relegated, as assembler once was, to just doing the really low level libraries, and most code (which would include most libraries too) would be done in the popular stuff.
-
Anyway, C seems to be in decline because of the push of other languages. And some of them, like Rust, intend to replace C in applications like systems programming.
C isn't in decline. Its still doing the things it has always done, and to a similar extent. Rust might change that, but we'll have to wait and see, The whole software market is growing, and C is not the ideal tool for a lot of where it is growing.
-
Anyway, C seems to be in decline because of the push of other languages. And some of them, like Rust, intend to replace C in applications like systems programming.
C isn't in decline. Its still doing the things it has always done, and to a similar extent. Rust might change that, but we'll have to wait and see, The whole software market is growing, and C is not the ideal tool for a lot of where it is growing.
Indeed.
I doubt RUST will wide replace C unless the very specific niche (AGENDA) of the sponsors..
The folks living in the systemd wonderland. .. are not used to install software the safe way..
Real life is that AUTCONF and AUTOMAKE are 100% based on PERL modules..
You just will not compile a distro without them...
so.. calling that dead is more likely coming from a dead brain...
I will just post a shot of my package manager.. written in PERL::Curses...
It shows how Autoconf and Automake PERL modules are INDISPENSABLE for a safe workstation..
A bunch of folks are insanely eager to push MESON to replace them
Soon or later they will see how hard things can fail because the decades of functionality Autoconf provide just can not be replaced that easy..
It is just impossible to compile a distro without PERL...
a lot of folks are trying to change this .. a decade or so...
Paul
-
automake and autoconf are a monumental shit show that need to go away.
Go was very careful to avoid this sort of external tool mess with its toolchain. I can cross build to any platform and target from any platform and target with that and it handles external dependencies properly.
To note I have written a lot of Perl. It's horrible and dangerous.
-
automake and autoconf are a monumental shit show that need to go away.
That was kind of inevitable if you consider the long period over which they evolved. Now the needs are better understood much cleaner schemes are possible.
Go was very careful to avoid this sort of external tool mess with its toolchain. I can cross build to any platform and target from any platform and target with that and it handles external dependencies properly.
That kinda misses the point. How is my project using a dozen languages, including stuff from 30 years ago, going to be able to benefit from that? Something more generic is needed.
-
automake and autoconf are a monumental shit show that need to go away.
That was kind of inevitable if you consider the long period over which they evolved. Now the needs are better understood much cleaner schemes are possible.
Not really. They originally existed because the compilers and make implementations were different on each platform. So the objective was to glue whatever you could together with Perl and M4 and then leverage the unholy shit crock to puke out builds for your software strewn with ifdefs all over the place. I spent most of 1999 undoing one of these turds...
That problem was mostly resolved, apart from all the infernal GCC extensions out there. At least clang seems to pretend to notice them...
Go was very careful to avoid this sort of external tool mess with its toolchain. I can cross build to any platform and target from any platform and target with that and it handles external dependencies properly.
That kinda misses the point. How is my project using a dozen languages, including stuff from 30 years ago, going to be able to benefit from that? Something more generic is needed.
Well the last thing I worked on had 46 million lines of a mix of C#, Python, Go and Java as well as a chunk of C++ from the 1990s and more SQL that I've ever seen so that's sort of turd I'm experienced at rolling around. Oh and 10 million lines of c++ and C# desktop app to boot. The answer is not providing a generic solution, because all that does is compromise every language and platform. The correct answer is to silo out each native build stack and simplify it then do integration later, preferably loosely coupled in some way. At a C level, keep a well defined interface and dload bits of it in. At a platform level, ESB / services model.
COM/DCOM was pretty good at this even if everyone hated it but your resident enterprise architect didn't give a shit because his job was to make everyone equally unhappy :-DD
-
Well the last thing I worked on had 46 million lines of a mix of C#, Python, Go and Java as well as a chunk of C++ from the 1990s and more SQL that I've ever seen so that's sort of turd I'm experienced at rolling around. Oh and 10 million lines of c++ and C# desktop app to boot. The answer is not providing a generic solution, because all that does is compromise every language and platform. The correct answer is to silo out each native build stack and simplify it then do integration later, preferably loosely coupled in some way. At a C level, keep a well defined interface and dload bits of it in. At a platform level, ESB / services model.
I don't want to hear your sad story. Anyone who has done enough software development has a catalogue of messy tales to tell. :)
-
Well the last thing I worked on had 46 million lines of a mix of C#, Python, Go and Java as well as a chunk of C++ from the 1990s and more SQL that I've ever seen so that's sort of turd I'm experienced at rolling around. Oh and 10 million lines of c++ and C# desktop app to boot. The answer is not providing a generic solution, because all that does is compromise every language and platform. The correct answer is to silo out each native build stack and simplify it then do integration later, preferably loosely coupled in some way. At a C level, keep a well defined interface and dload bits of it in. At a platform level, ESB / services model.
I don't want to hear your sad story. Anyone who has done enough software development has a catalogue of messy tales to tell. :)
Perhaps I could have more elegantly said that the point is you solve language and integration problems through composition, not through consolidation. Thus autoconf and automake are creating a problem not solving it.
-
the point is you solve language and integration problems through composition, not through consolidation.
Modularity, not frameworks.
Composability, not monolithic integrated designs.
You design and specify the interfaces, and allow any implementation that implements the agreed upon interfaces and behaviour.
Yes. But that's not how software is developed nowadays. Most projects aggregate into something that can be shipped, that's all.
In modular designs, correctly tracking and fulfilling dependencies is key. Interpreted languages like Python can do much more logic when choosing which dynamic library to load, than lower-level systems programming languages like C that rely on the system dynamic loader.
If we consider portable binaries say across x86-64 ELF systems using SYSV ABI (Linux, BSDs, etc.), the optimum case would be if we could provide a dynamic linking 'hint' or 'script' file, a sort of a shell script type of thing, that could specify the paths/files to the dynamic libraries based on the current run-time environment, mixing both system-provided and application-provided libraries as needed. This has been tried many times before, of course –– one I don't really like is GNU libtool (https://www.gnu.org/software/libtool/) ––, but the one approach that seems to work best is to use a launcher script to set up environment variables defining those paths. The downside with the script approach is that it cannot really deal with individual libraries, unless you use a dedicated library directory you populate with symlinks. Checking and populating that in a script or loader program does incur a bit of a startup latency, though.
These are the kinds of problems that are more important to me than which language does a trivial loop the fastest. I can implement whatever I need in whatever language I have available, but I'd like it to be modular and maintainable: reinventing the wheel again and again is dull, and only good for those who like the job security as wheel reinventors.
-
Real life is that AUTCONF and AUTOMAKE are 100% based on PERL modules..
You just will not compile a distro without them...
100%? Except for the bits that rely on m4, bash and awk. Heck, you even have a screenshot of your 1980's style package manager showing scads of m4 files. If you're going to pontificate, try to get your facts straight.
Anyway I'm with BD, Autoconf and Automake are horrible. Better than having nothing, but sorely in need of consigning to the shitcan. Cmake can do anything Autoconf and Automake can do and does it better (I have to confess to personally not liking Cmake, but that is pure arbitrary personal taste and doesn't detract from the fact that it is a massive improvement over Autoconf and friends.)
-
Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.
Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems. People love C so much there is focus in rewriting core system utilities in other languages now.
The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on :-DD.
Some things do stay. Python is one. I first used it as the workflow descriptor DSL in CoCreate WorkManager from HP circa 1998...
I make a point of writing the very few utilities that are interactive web sites I make in Perl, simply because it's "mature". No kiddiez will ever understand it. :-DD Also, and more importantly, my brain stopped understanding web programming circa 1999. Everything after that is just incomprehensible and bizarre reinventions of GUI's that would have been better as thick desktop apps... Or done in something like curses.
I did, once, include a 3-line snippet of js in a CGI page I built, to get a "print this page" function. I admit that. Took a lot of googling.
Also, I need Perl because my music player, a Squeezebox, requires it if I'm not to turn it into a tool of the music industry that can't play my local music collection.
Fortran is happily trudging along in HPC, but I suppose you're right about C++.
My colleagues are all over Python so I suppose I'll have to learn it to fix their programs.
-
Fortran is mostly DEAD.
Fortran is happily trudging along in HPC, but I suppose you're right about C++.
Yep. I think bd139 is being a bit blinkered. It amazes me to see how much Fortran is still relevant if you look at the right areas to see it. They are still updating the spec.
-
Fortran is mostly DEAD.
Fortran is happily trudging along in HPC, but I suppose you're right about C++.
Yep. I think bd139 is being a bit blinkered. It amazes me to see how much Fortran is still relevant if you look at the right areas to see it. They are still updating the spec.
I'm certainly not saying that Fortran is not used at all. If we look at the 99.9% of computational requirements, it doesn't factor in and there isn't exactly a massive queue of people waiting to write it now which is a commercial risk. Much like COBOL and JCL for example, they are being replaced because maintenance is the largest operational expenditure of a technical decision over a decade cycle.
Yeah. I've been doing this professionally for 25 years. As an amateur about 38 years now.
Perl is completely fucking DEAD. Fortran is mostly DEAD. Mainframes are breathing their last breaths. C is dead outside embedded and systems programming because of the security focus of modern systems. People love C so much there is focus in rewriting core system utilities in other languages now.
The only inevitability is change, you're right. But that's a good thing because it keeps me in pocket as I've bothered to keep up with the times and don't call anything limp dicked I can make some coin on :-DD.
Some things do stay. Python is one. I first used it as the workflow descriptor DSL in CoCreate WorkManager from HP circa 1998...
I make a point of writing the very few utilities that are interactive web sites I make in Perl, simply because it's "mature". No kiddiez will ever understand it. :-DD Also, and more importantly, my brain stopped understanding web programming circa 1999. Everything after that is just incomprehensible and bizarre reinventions of GUI's that would have been better as thick desktop apps... Or done in something like curses.
I did, once, include a 3-line snippet of js in a CGI page I built, to get a "print this page" function. I admit that. Took a lot of googling.
Also, I need Perl because my music player, a Squeezebox, requires it if I'm not to turn it into a tool of the music industry that can't play my local music collection.
Fortran is happily trudging along in HPC, but I suppose you're right about C++.
My colleagues are all over Python so I suppose I'll have to learn it to fix their programs.
I will admit that I am no fan of the world-wide web. I've done my time writing complex UIs in HTML/CSS/JS and it's quite frankly horrible. I do understand it fairly well (to the point of being fairly competent with React) but yes, I'm with you there.
Apple get GUI implementation fairly correct with Swift/SwiftUI I found. That's bearable and worth investing in if you are a Mac and iOS user. XAML/WPF and C# was also fairly nice although it was like pissing on an ant out of a moving train with the platform churn. I still have a fairly large WPF app out there in the wild at the moment.
Python will take you a few hours to learn. It's worth it. Some of the things other languages do feel horrible fairly quickly.
Stuff like this is fun, with a semi functional nature...
import math
def gen():
for x in range(1, 10):
yield x * x
a = gen()
b = list(map(lambda x: math.sqrt(x), a))
print(b)
-
I'm certainly not saying that Fortran is not used at all. If we look at the 99.9% of computational requirements, it doesn't factor in and there isn't exactly a massive queue of people waiting to write it now which is a commercial risk. Much like COBOL and JCL for example, they are being replaced because maintenance is the largest operational expenditure of a technical decision over a decade cycle.
JCL and COBOL are only being maintained. Lots of new HPC code is being written right now in Fortran. It feels like a step into history when you come across this.
-
Real life is that AUTCONF and AUTOMAKE are 100% based on PERL modules..
You just will not compile a distro without them...
100%? Except for the bits that rely on m4, bash and awk. Heck, you even have a screenshot of your 1980's style package manager showing scads of m4 files. If you're going to pontificate, try to get your facts straight.
100%.. That is correct - reason being is that you can not remove these modules. The functionality will be compromised and you have a broken system.
If you ever compile your own distro you will see that some nasty problems arise from circular dependency In other words.. You need a full working console before widget gizmos..
Reason that my package manager was designed smart enough to live with that odds.
It is a system wide daemon. It works very light on any workstation here..
I am free to use any interface I want.. I have a half dozen..
The daemon is written in PERL as well and can bind socks or direct INET
- Console is used as far as the build has Curses interface
- PERL::Curses is used from this point up to having full GTK support
- then PERL::GTK is used - they are independent but require the build steps..
It has a builtin HTML browser (GTK based) and POD Viewer (native) with full PERL site log...
by this way I can manage package downloads and repos just fine inside the package build system
I am considering writing a full TVIsion/SQLite interface for that..
Just like my BENCH INVENTORY .. I like TVision simple fast and functional
so i am free to deploy a light 32 bit or dedicated 64bit server with proper package management..
so far so good it works for my needs
Shots attached
Paul
-
the point is you solve language and integration problems through composition, not through consolidation.
(..)
In modular designs, correctly tracking and fulfilling dependencies is key. Interpreted languages like Python can do much more logic when choosing which dynamic library to load, than lower-level systems programming languages like C that rely on the system dynamic loader.
If we consider portable binaries say across x86-64 ELF systems using SYSV ABI (Linux, BSDs, etc.), the optimum case would be if we could provide a dynamic linking 'hint' or 'script' file, a sort of a shell script type of thing, that could specify the paths/files to the dynamic libraries based on the current run-time environment, mixing both system-provided and application-provided libraries as needed.
(.)
The big problem here is that PYTHON unlike other POSIX tools can not do one liner redirection and tests the proper way... like decades peer reviewed GNU Automake can..
https://venomlinux.org/ and https://voidlinux.org/ both use the same modified script based AUTO BUILD system and both need to follow the Autoconf dependency on PERL Make and a goo reliable POSIX shell (BASH)..
Hardly you can escape that circular ... in particular other platforms free from these nasty systemd schemas. ( other NIXES)..
Paul
PS> for newcomers it may seem just a matter or reinventing the wheel with Python.. that will fall short as soon as POSIX implementations on other *NIX flavors hit these bad Python interfaces...
-
I'm not sure exactly what you mean by that to be honest.
Regarding nasty Unixes, I'm actually sitting writing this on a certified UNIX which doesn't have systemd :-DD
-
I mean for example FreeBSD OpenBSD and a half dozen others BSD flavors..
I can no longer issue opinion on (for example) AIX, HP-UX and some others..
because last time I used them was on 80 to 90s early years..
I changed my SCO to Slackware around 93/ to 95 when complete ditched all old stuff.
Since then only (Li)NIX variants..
The bottom line is that Autconf and all GNU build system was meant as cross platform
and they do work very reliable in all of them..
You can run autoconf and be confident it will produce a sane configure && make asset build
I agree.. Autoconf looks intimidating but it does the cross platform job like no other
I am still to see a better one..
And I have seen some dozens... no other build system is as portable as GNU autotools
Paul
-
I had some serious problems with portability of autoconf back pre 1.0 days on Solaris. Took me a month to get it working. There's probably some usenet postings of me being somewhat critical of the whole thing still :)
It's not intimidating, it's just a horrible solution that probably should have gone away by now.
As for portability, there are only a few fairly well normalised targets these days. It's not the Unix wars. Linux, Windows, MacOS, possibly a BSD or two and that's about it. The buy eyed monster is only windows now (not OSF1 :-DD) :(
-
I had some serious problems with portability of autoconf back pre 1.0 days on Solaris. Took me a month to get it working. There's probably some usenet postings of me being somewhat critical of the whole thing still :)
Yeah, that matches my experience. For quite a long time my personal kit was mostly Solaris based and more than anything else that pushed me to move away from it was the hell of trying to get quite standard 3rd party packages to build cleanly without days of tweaking, and the principal culprit in that was autoconf et al. I still have 3 SPARC machines and one SPARC motherboard sitting in a pile gathering dust.
-
Yes this is also my opinion.
Autoconf is intimidating.
Autoconf is very steep to learn
Autoconf is no newbie friendly
What to expect ... Autoconf was made to support several dozen variants and systems.
Across decades of fixes and peer review...
But it does the job and it has not even a close replacement so far..
All those "alternatives" fall short sooner or later.
Autoconf is really hard to deal - but it works
Paul
-
What you call fixes and peer review I call shitty hacks :-DD
-
The bottom line is that Autconf and all GNU build system was meant as cross platform
and they do work very reliable in all of them..
I was known as The Solaris Man before Larry bought them and turned The Old SUN evil. I spent the better part of the early 00s trying to compile GNU software on Solaris, using the Autoconf shite, not seldom using the Sun compilers. To call that festering pile of optimistic programming that is Autoconf "reliable" is a true Baghdad Bob moment in my book. Then, it also does not work.
In a world when people are upset at the "enormous differences" between RPN and APT for X86_64 Linux, it's of course a practical illusion that Autoconf appears to work for the bizarre subset of shit linuxen people run.
Add in a BSD using clang on ARM and it breaks. Run a /bin/sh that isn't bash and it breaks.
-
I like Ruby much more than Python. Unfortunately it hasn't gotten the same mindshare outside of a couple of web frameworks.
I will admit I haven't used it much, mostly secondary exposure through Chef and Puppet, but it feels very much like Perl++ to me. Powerful and with lots of sugar, but inscrutable to non-experts, and prone to unmaintainable IOCCC-style code. I'm not too surprised that Python won that popularity battle, it is much more approachable. It's part of the reason I have been moving things over to Salt instead, which is Python-based.
Modern Javascript is also better than Python, especially TypeScript. With v8 it also runs far far more quickly. It's for general scripting, not only in the browser. There are a huge number of libraries available in npm.
JavaScript is a tough one to pin down for sure, but I'm not sure I'd call it 'better' than Python on too many axes (though certainly some, popularity and performance included). Moreso than even Python, its popularity isn't based much on its merits (it was pretty awful when it became popular), but its ubiquity and special status as the universal Web language. From that comes its huge benefit for server-side programming, which is code reuse and developer flexibility. It's only relatively recently (wrt. Python, anyway) that it's been a viable language for anything else, and it does have rather a lot of warts. But as you say, along with its popularity comes great performance, a large amount of good libraries, lots of available talent, and lots of tools like TypeScript to make the language and working with it a little less... awkward. I do think that as a core language for outside-the-browser use it doesn't offer a great showing against Python; the interpreter is not nearly as ubiquitous, the language is warty and doesn't have much sugar without preprocessing, its type system (or lack thereof) sucks, the system interface isn't great, the included library isn't as comprehensive...
"displaced ... bash" - I don't think so. You put /usr/bin/python in place of /bin/bash in your /etc/passwd entry and let us know how you get on, if you ever recover from doing so.
I did not say 'replaced' for a reason, and wasn't talking about interactive OS shells when I said it, either. Aside from very small scripts, what you once may have turned to bash (or Perl) for, the vast majority of times these days you'd probably choose Python, and this is the trend in most nixy OSes for small system tools too; I am sure that bash has lost popularity in favour of Python for scripting in the past decade.
-
What you call fixes and peer review I call shitty hacks :-DD
You have not compiled a full distro recently...
I have a half dozen packs segfaulting with MESON while they compile and run perfectly with autoconf..
It is not that simple
-
The bottom line is that Autconf and all GNU build system was meant as cross platform
and they do work very reliable in all of them..
I was known as The Solaris Man before Larry bought them and turned The Old SUN evil. I spent the better part of the early 00s trying to compile GNU software on Solaris, using the Autoconf shite, not seldom using the Sun compilers. To call that festering pile of optimistic programming that is Autoconf "reliable" is a true Baghdad Bob moment in my book. Then, it also does not work.
(..)
As far as SOLARIS is concerned... we have some sort of OUT_OF_THE_SPECTRUM "product(s)"
Sun came down the hill across the 90s.. 00s.. 10s... up to the point where it does not even counts.
There is no surprise.. they could not position themselves when SCO sunk...
They could not position themselves when GNU tools arise on the Linux and BSD arena..
and they could not position themselves today as well.
Considering Automake tools are GNU based and Sun insisted way too long in not following the GNU best practices... nobody really consider porting Automake scripts for Sun...
Automake is not simple to deal and requires a considerable cumulative tidbits..
At the moment who really cares about SOLARIS while deploying OpenBSD FreeBSD TrueNAS or some of the 100 available LINUX... nobody cares...
bottom line .. you can not compile BSD or LINUX without Autoconf at the first step.
MESON has been a pot of glued hacks trying to force Python into everybody throats..
Some packs are still unreliable having both MESON and Autoconf...
and so far.. reliable is Autoconf..
At this point nobody really cares porting Autoconf macros to SOLARIS..
it just makes no sense
Paul
-
Sun came down the hill across the 90s.. 00s.. 10s... up to the point where it does not even counts.
I used Sun stuff a lot in the 90s. A SPARCStation ELC (33 MHz, 64 MB RAM, CPU built in to a 1152x900 mono screen) was my first personally owned *nix machine, bought for $50 or so from a university that was moving on to more powerful machines. I taught myself *nix going through all the binaries, everything in /etc including the init/runlevel stuff. Stood me in good stead for some consulting jobs right afterwards. Learned emacs on that machine, haven't used anything else seriously since.
The last time I used Solaris was in a job for a telephone exchange add-on ("IN" -- Intelligent Network) company in 2002-2003. Their old legacy machines were HP/UX, the current production stuff was Sun, all the devs wrote and tested everything on Linux first -- and Linux had valgrind, which was used extensively. My work PC then was an Athlon XP 1800+
-
The bottom line is that Autconf and all GNU build system was meant as cross platform
and they do work very reliable in all of them..
I was known as The Solaris Man before Larry bought them and turned The Old SUN evil. I spent the better part of the early 00s trying to compile GNU software on Solaris, using the Autoconf shite, not seldom using the Sun compilers. To call that festering pile of optimistic programming that is Autoconf "reliable" is a true Baghdad Bob moment in my book. Then, it also does not work.
(..)
As far as SOLARIS is concerned... we have some sort of OUT_OF_THE_SPECTRUM "product(s)"
Sun came down the hill across the 90s.. 00s.. 10s... up to the point where it does not even counts.
Autoconf sucked even when Solaris and Sparc was a major platform. It's always sucked.
-
Autoconf sucked even when Solaris and Sparc was a major platform. It's always sucked.
It is TRUE.. i can not agree more...
But.. it still is the primary and best tool to have the job done..
For anything concerning GNU and a wide spectrum of tools based on it..
What to expect... it still is a several decades old tool with fixes and thousand reviews...
We live with it..
Re inventing the wheel may be a FIASCO.. ( as the ISC consortium learned the hard way...)
Paul
-
A major point of the above autotools discussion relevant to Python is that whatever you do, you want the language base libraries to be the same across all systems, for the code to be portable.
If C hadn't fragmented, no autoconf+automake would have ever been needed. After all, their main purpose is to discover the installed libraries and their system-specific quirks for the code to compile and run correctly.
The way OS-specific interfaces are exposed in Python via the os (https://docs.python.org/3/library/os.html) built-in module isn't exactly optimal, though. If each OS family was exposed via a submodule (say, os.posix, os.linux, os.bsd, os.macos, os.windows, etc.), then it would be possible to write OS dependent Python that could still be run on another system via a compatibility module (that probably would have application-specific runtime tunables to deal with the completely different interfaces and their assumptions on different OSes).
-
If C hadn't fragmented, no autoconf+automake would have ever been needed. After all, their main purpose is to discover the installed libraries and their system-specific quirks for the code to compile and run correctly.
that is no longer just about C
I have just upgraded my OCTAVE site this week to latest version....
Marvelous job was done by the folks crafting a very good Autoconf set for that...
OCTAVE now requires a full and wide set of system libs... in particular.. BLAS and LAPACK (otherwise it won't even configure.. ).. and both BLAS and LAPACK are compiled in FORTRAN and sustain -lgfortran dependency..
bottom line that a sane group of tests (including binutils for ELF formats) should be done to check if mixing all these inter-compiled libs will actually dlopen() themselves when glued..
OCTAVE compiled fine .. took a long long time with more than 8cores dedicated to link the whole thing..
Thanks to Autoconf... no segfaults...
We barely could rely that sort of redirection tests to some Pythonish "os.module"...
Paul
-
I was known as The Solaris Man before Larry bought them and turned The Old SUN evil. I spent the better part of the early 00s trying to compile GNU software on Solaris, using the Autoconf shite, not seldom using the Sun compilers. To call that festering pile of optimistic programming that is Autoconf "reliable" is a true Baghdad Bob moment in my book. Then, it also does not work.
The first thing I did on Solaris machines was to install bash and the GNU soft dev essentials. With this setup I had rarely any problems with autoconf or compiling in general.
-
both BLAS and LAPACK are compiled in FORTRAN and sustain -lgfortran dependency..
There are actually multiple implementations providing the exact same API (and ABI), from Goto to OpenBLAS to Intel MKL and AMD OCL.
Not all of them are written in Fortran, nor do all of them even have Fortran bindings.
We barely could rely that sort of redirection tests to some Pythonish "os.module"...
Bullshit, because existing Python code that does not rely on non-builtin modules runs absolutely fine on all architectures. That is proof that it can be done. It is the contributed Python modules that rely on specific native libraries that makes things difficult.
Moreover, the fact that you can use native Qt 5 libraries using the same Python code using PyQt5, PySide2, or GIR bindings –– the first two using SIP and the latter using GObject introspection files to generate the Python bindings –– with something like a fifty-line module shim (that selects the interface to be used at runtime, depending on what is available, optionally controlled by an environment variable) –– shows that it is also practically possible; it is just a matter of the Python modules being uniform and available on all OSes also, without their own dependency hells.
You could ask "Why, then, do so many Python projects suffer from dependency hell?". This is what my post above dug into. Because the base library doesn't modularise OS features properly, many developers don't bother to do it either. (I am drawing a somewhat tenuous relationship here, but I believe it is true: it just isn't something Python developers want to consider at all.) Hell, most external Python modules don't even bother to state their library versions and dependencies!
That is a problem that an interpreted programming language could and should solve better.
If you want to provide an "universal Linux binary" using any interpreted language like Python, it is easiest to do so via a dynamically linked interpreter that uses a fixed directory for all its libraries, that directory being populated by symlinks to either system libraries or the versions provided along with the binary itself, whichever is newer or preferred by the user. You could even have a run-time configurator utility to manage those. (However, that has security implications re. system-wide vs. per-user installations, and the interpreter/binaries being able to modify themselves, making this approach one of those which basically requires a dedicated user and group for such an application. Very doable, but it is a complex subject that requires quite a lot of experience to do right, which explains why it is so often done wrong.)
I often write POSIX C exactly because of this. The subset and superset of C implemented is closer to what I need, so that the code I write does not need autotools to be compilable and runnable across basically all POSIXy systems (Linux, Android, MacOS, BSDs, Unixes with a POSIXy C library). What does annoy me, however, is that as long as I use the standard C library in Linux, I cannot get at the really nifty features provided by the Linux kernel for my Linux-only code, like per-task credentials (user and group). (The C library in Linux uses a realtime signal across all threads in the process to synchronize those in userspace.)
(I have written simple shell scripts to emulate basic ./configure functionality to modify an included Makefile fragment setting the directory paths and such. It is not necessary to run it, but if someone wants to modify how the binary is compiled and installed, they can do so either via that script or by modifying the configuration Makefile snippet. All explained in the traditional INSTALL text file.)
As someone having used Linux from Scratch extensively a decade or two ago, I'm very familiar with using autotools. However, I do not like to write code that requires autotools to be compiled myself. For similar reasons, I don't like CMake much either. In other words, I am happy that autoconf and automake and CMake exist as they can often fix these issues without worries; that on my systems running GNU-derived build tools they almost always Just Work. However, I am decidedly not happy that autoconf and automake are needed in the first place.
-
both BLAS and LAPACK are compiled in FORTRAN and sustain -lgfortran dependency..
There are actually multiple implementations providing the exact same API (and ABI), from Goto to OpenBLAS to Intel MKL and AMD OCL.
Not all of them are written in Fortran, nor do all of them even have Fortran bindings.
Exactly . that boils down to the point
http://www.netlib.org/blas/ (http://www.netlib.org/blas/)
http://www.netlib.org/lapack/ (http://www.netlib.org/lapack/)
You should probably want to integrate Fortran77 subroutines designed to solve large scale eigenvalue problems with both.. soo....... a base system will end up with a mixture of libs like this one now..
http://www.caam.rice.edu/software/ARPACK/ (http://www.caam.rice.edu/software/ARPACK/)
libarpack.so.2 => /lib/libarpack.so.2 (0xb4549000)
libblas.so => /lib/libblas.so (0xb7e57000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb3df9000)
libcrypto.so.1.1 => /usr/local/ssl/lib/libcrypto.so.1.1 (0xb37ec000)
libcurl.so.4 => /lib/libcurl.so.4 (0xb4596000)
libfftw3.so.3 => /lib/libfftw3.so.3 (0xb5121000)
libfftw3_threads.so.3 => /lib/libfftw3_threads.so.3 (0xb527c000)
libfftw3f.so.3 => /lib/libfftw3f.so.3 (0xb4fc9000)
libfftw3f_threads.so.3 => /lib/libfftw3f_threads.so.3 (0xb511a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb748a000)
libgfortran.so.5 => /lib/libgfortran.so.5 (0xb74ed000)
libgomp.so.1 => /lib/libgomp.so.1 (0xb56de000)
libgsasl.so.7 => /lib/libgsasl.so.7 (0xb3b30000)
liblapacke.so => /lib/liblapacke.so (0xb77ec000)
libncursesw.so.6 => /lib/libncursesw.so.6 (0xb444e000)
liboctave.so.8 => /usr/lib/octave/6.4.0/liboctave.so.8 (0xb5950000)
liboctinterp.so.9 => /usr/lib/octave/6.4.0/liboctinterp.so.9 (0xb6aec000)
libquadmath.so.0 => /lib/libquadmath.so.0 (0xb73e2000)
libssl.so.1.1 => /usr/local/ssl/lib/libssl.so.1.1 (0xb3a99000)
libtmglib.so => /lib/libtmglib.so (0xb732f000)
I hope the folks on octave devel keep Autoconf because it worked perfect out of the box
Paul
-
libarpack.so.2 => /lib/libarpack.so.2 (0xb4549000)
libblas.so => /lib/libblas.so (0xb7e57000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb3df9000)
libcrypto.so.1.1 => /usr/local/ssl/lib/libcrypto.so.1.1 (0xb37ec000)
libcurl.so.4 => /lib/libcurl.so.4 (0xb4596000)
libfftw3.so.3 => /lib/libfftw3.so.3 (0xb5121000)
libfftw3_threads.so.3 => /lib/libfftw3_threads.so.3 (0xb527c000)
libfftw3f.so.3 => /lib/libfftw3f.so.3 (0xb4fc9000)
libfftw3f_threads.so.3 => /lib/libfftw3f_threads.so.3 (0xb511a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb748a000)
libgfortran.so.5 => /lib/libgfortran.so.5 (0xb74ed000)
libgomp.so.1 => /lib/libgomp.so.1 (0xb56de000)
libgsasl.so.7 => /lib/libgsasl.so.7 (0xb3b30000)
liblapacke.so => /lib/liblapacke.so (0xb77ec000)
libncursesw.so.6 => /lib/libncursesw.so.6 (0xb444e000)
liboctave.so.8 => /usr/lib/octave/6.4.0/liboctave.so.8 (0xb5950000)
liboctinterp.so.9 => /usr/lib/octave/6.4.0/liboctinterp.so.9 (0xb6aec000)
libquadmath.so.0 => /lib/libquadmath.so.0 (0xb73e2000)
libssl.so.1.1 => /usr/local/ssl/lib/libssl.so.1.1 (0xb3a99000)
libtmglib.so => /lib/libtmglib.so (0xb732f000)
Many of those are just the fortran bindings to the underlying libraries (libarpack, libfftw3f, libfftw3f_threads, libgfortran), and Fortran is not intrinsically faster than C (just easier to write efficient code for, especially when one wishes to use array slicing and such). Unless you do write (some parts of) your application in Fortran, there is no benefit in having the Fortran bindings.
(I've read and written quite a lot of Fortran 95 code myself; molecular dynamics simulations for HPC clusters. It is definitely easier to teach a Physicist/Chemist to write acceptable HPC code in Fortran than it is to teach them to do the same in C. In either case it will be ugly and basically unmaintainable code, though.)
I hope the folks on octave devel keep Autoconf because it worked perfect out of the box
I hope so too. It's not like we have anything better, really. Some may argue CMake is better, but meh; I've not used both in enough different architectures and operating systems to say either way, and definitely porting an application from one to the other is not worth the effort.
I consider autotools a practical example of why it is so important that base libraries do not differ between OSes and architectures, and that OS-specific extensions/quirks are properly modularised. Python does it half-way: its core has annoying parts that could have been better, but one can live with it. It is the external Python libraries and their dependencies that are the problem in Python. For autotools, initially the purpose was to handle the differences between the standard C implementations and extensions, and it just sorta grew from there, to cover other libraries via test cases as well. Autotools should not be needed[/i], if the library interfaces are properly modularised and versioned. We can't change C because there is so much existing code already, but when new languages are developed, it is something that definitely should be considered – but currently is not.
-
That's what I've come to write so far.
Merits and demerits of Python:
Speed:
Python imperative programming are slow. 50 times slower than C. (demerit)
Python can do very fast computations thanks to its libraries, such as numpy (merit)
Python has functional programming, faster than imperative programming (merit)
Code blocks and indentation
Python uses colons and indentation to separate blocks.
This is a merit for some people and a demerit for others.
Easy of programming
Python is very easy to program.
It is a good language to start learning programming. (merit)
This leads to a lot of code written by bad programmers. (demerit)
Code maintainability
Python helps to make code easily maintainable in the long term. (merit)
Libraries
Python has a large number of libraries (>300000).
Many for Artificial Intelligence, Big Data processing, Scientific, Web development. (merit)
Security issues relating the big number of libraries and dependencies (demerit)
Language updates
Frequent language updates that keep it up to date. (merit)
Frequent changes that are no longer compatible with previous versions (demerit)
Documentation and help
Python has many good free and paid manuals. (merit)
Python has a large, very active community of programmers from which help is readily available. (merit)
Multiplatform
Python is multiplatform and runs on Unix, Windows and Mac. Recently in a web client as well. (merit)
Cross-platform libraries present certain problems (https://www.eevblog.com/forum/programming/python-becomes-the-most-popular-language/msg4168792/#msg4168792) (demerit)
-
Easy of programming
Python is very easy to program.
It is a good language to start learning programming. (merit)
This leads to a lot of code written by bad programmers. (demerit)
I've heard this as a complaint about Python before and I've always had a hard time getting my head around it. (I know that Picuino is not introducing the idea hear, simply repeating it.)
It would seem that the only alternative is that no beginning programmers should be allowed to actually code anything until they've proven themselves to be a "good programmer." Obviously, that would be silly.
So what is the complaint really about? Is it just "good" programmers grousing, or is it believed that a programming language could exist that is easy for beginners to learn and somehow prevents them from being "bad." I expect that the truth is neither of those...
-
It would seem that the only alternative is that no beginning programmers should be allowed to actually code anything until they've proven themselves to be a "good programmer." Obviously, that would be silly.
Well, kind of. A beginner of assembly programming would either give up or learn some hard lessons quite quickly. By the time they can string together a decently-sized application their code is likely to be decent. So there you have someone who really wants to be a programmer, and has made the mistakes to achieve that end.
OTOH, someone running off a couple of lines of BASIC in Word is probably wanting to be an author, and so long as the code seems to achieve what they are wanting to achieve, they're happy. And, apparently, a programmer.
I think the comments aimed at the likes of beginning Python programmers is that it's too easy not to make the mistakes that let you progress as a competent programmer. Stuff like cohesion and coupling, which seem unimportant when you're just gluing together some libraries. So when they write some slightly harder stuff it's the modern equivalent of spaghetti code. They need to fail a few times before sharing, perhaps, but it's too easy to share as well now!
Personally I have no idea about Python or programmers of same (the above is what I perceive to be the argument). However, I have looked at Arduino code, which I think is seen similarly, and not been overly impressed. Often, there is little to no error recovery - the stuff works great so long as nothing goes wrong! There is undoutedly excellent code, both Arduino and Python, it's just that there is also a quite high percentage of not so good code, because it's easy to write stuff that kind of works. And to share same.
-
I think the comments aimed at the likes of beginning Python programmers is that it's too easy not to make the mistakes that let you progress as a competent programmer. Stuff like cohesion and coupling, which seem unimportant when you're just gluing together some libraries. So when they write some slightly harder stuff it's the modern equivalent of spaghetti code. They need to fail a few times before sharing, perhaps, but it's too easy to share as well now!
Personally I have no idea about Python or programmers of same (the above is what I perceive to be the argument). However, I have looked at Arduino code, which I think is seen similarly, and not been overly impressed. Often, there is little to no error recovery - the stuff works great so long as nothing goes wrong! There is undoutedly excellent code, both Arduino and Python, it's just that there is also a quite high percentage of not so good code, because it's easy to write stuff that kind of works. And to share same.
Unfortunately, while I think I can mostly agree with the interpretation of what's going on here, I think it's just another angle on the 'language safety' issue, which is a lot closer to something we can objectively compare between languages. It's hard to get code working in assembly for many of the same reasons that it's hard to write safe assembly even if your architectural decisions are good - there are a metric shedload of footguns, and you have to do lots of fiddly but critically important bits by hand. It means that beginner-level code will probably never see the light of day because they will give up, but it also means that experts have far more places to go wrong, and even the best programmers aren't always perfect, so while the code might be 'better', it's also far more likely to be dangerous or have weird bugs that crash the program for obscure reasons.
It's interesting that you mention error handling (and the kind of related input validation), because this is probably the biggest problem with 'amateur' code in 'hard' languages like C or assembly that works fine. It's good enough to work reliably, but bad enough to give remote shell access to anyone who bothers to try, or trash your directory if you give a weird filename or suchlike. It might not be ideal to let every exception bubble up all the way to the user, but it's more error handling than many C programs have, and is usually safe. Error recovery is a separate issue and is hard in every language 8)
Personally, I think that even if there's tons of 'bad' code written in Python, it's a much better situation than if that same code were all in 'good' assembly (ignoring that that's totally impractical, in real terms), because it's very unlikely that Python code is going to do something dangerous, most likely it will just be inefficient, which is not really a big deal. It will also be much easier to give a basic code review or debug.
-
Interesting diversion on the thread. No programs are perfect but some languages allow several more layers of imperfection. Most of the newly conceived languages have one less layer of imperfection: no memory management, forced non-stupid error handling, better concurrency primitives.
On exceptions...
Recently I tripped over a wonderful bit of code, in C# in a HTTP integration service. In the resource controller it caught every exception thrown and returned an HTTP 400 code (bad request). This was expected for about 80% of the cases, of course the tested ones, but when the upstream integration failed and returned a simple Exception instance, it caught that and returned a 400 too. Of course that didn't drop to the global error handler which would have logged the context, exported the error rate through the logging metrics, kick prometheus into action and trigger an SLO violation and incident. Nope it just sat there swallowing errors until someone wondered why their shit had stopped working and called support.
There's probably a thousand places this is happening on that product and no one would know until the client phoned up.
-
Personally, I think that even if there's tons of 'bad' code written in Python, it's a much better situation than if that same code were all in 'good' assembly (ignoring that that's totally impractical, in real terms), because it's very unlikely that Python code is going to do something dangerous, most likely it will just be inefficient, which is not really a big deal.
Well, I agree it's better but for a different reason - the state of the art progresses much faster if you have more shoulders to stand on, even if they aren't the strongest. Often, just knowing something can be done allows you to do it better, whereas previously it may never have occurred to try.
-
Personally, I think that even if there's tons of 'bad' code written in Python, it's a much better situation than if that same code were all in 'good' assembly (ignoring that that's totally impractical, in real terms), because it's very unlikely that Python code is going to do something dangerous, most likely it will just be inefficient, which is not really a big deal.
Well, I agree it's better but for a different reason - the state of the art progresses much faster if you have more shoulders to stand on, even if they aren't the strongest. Often, just knowing something can be done allows you to do it better, whereas previously it may never have occurred to try.
it just happens that the real de facto good code in what matters... most...
(Scientific apps, Numeric algos, fully tested and decades reviewed libs.. )
they are already written, fully stressed tested, and optimized and ported...
It just happens they are written in C and FORTRAN mostly. Several reasons
All reasons boils down to a very steady RATIONALE.
Nobody needs to re-write them. Unless obviously these newbies...
It would take a decade to acquaint these several decades tools..
it seems cheap easy to jump start to Pythonish... look ma I can code Python
Paul
-
A typical real world scenario is that a bad security bug is found in WordPress plugin X and someone adds that to his scanning bot to automatically seize control of WordPress instances running that specific vulnerable plugin. In a short time the bad guy controls 30k WordPress instances.
Here we go: Massive WordPress JavaScript Injection Campaign Redirects to Ads (https://blog.sucuri.net/2022/05/massive-wordpress-javascript-injection-campaign-redirects-to-ads.html)
-
I will debug Python, C++, C#, Java, Bash, Rust and even Javascript, in it's many self inflicted framework mutations. But it will be a very cold day in hell if I find myself touching LUA.
-
Personally, I think that even if there's tons of 'bad' code written in Python, it's a much better situation than if that same code were all in 'good' assembly (ignoring that that's totally impractical, in real terms), because it's very unlikely that Python code is going to do something dangerous, most likely it will just be inefficient, which is not really a big deal.
Well, I agree it's better but for a different reason - the state of the art progresses much faster if you have more shoulders to stand on, even if they aren't the strongest. Often, just knowing something can be done allows you to do it better, whereas previously it may never have occurred to try.
it just happens that the real de facto good code in what matters... most...
(Scientific apps, Numeric algos, fully tested and decades reviewed libs.. )
they are already written, fully stressed tested, and optimized and ported...
It just happens they are written in C and FORTRAN mostly. Several reasons
All reasons boils down to a very steady RATIONALE.
Nobody needs to re-write them. Unless obviously these newbies...
It would take a decade to acquaint these several decades tools..
it seems cheap easy to jump start to Pythonish... look ma I can code Python
Paul
I’m regularly finding bus sized holes in off the shelf C.
In fact I’m responsible for a couple of mid level CVEs :-DD
Stuff does need to be rewritten.
-
Personally, I think that even if there's tons of 'bad' code written in Python, it's a much better situation than if that same code were all in 'good' assembly (ignoring that that's totally impractical, in real terms), because it's very unlikely that Python code is going to do something dangerous, most likely it will just be inefficient, which is not really a big deal.
Well, I agree it's better but for a different reason - the state of the art progresses much faster if you have more shoulders to stand on, even if they aren't the strongest. Often, just knowing something can be done allows you to do it better, whereas previously it may never have occurred to try.
it just happens that the real de facto good code in what matters... most...
(Scientific apps, Numeric algos, fully tested and decades reviewed libs.. )
they are already written, fully stressed tested, and optimized and ported...
It just happens they are written in C and FORTRAN mostly. Several reasons
All reasons boils down to a very steady RATIONALE.
Nobody needs to re-write them. Unless obviously these newbies...
It would take a decade to acquaint these several decades tools..
it seems cheap easy to jump start to Pythonish... look ma I can code Python
Paul
I’m regularly finding bus sized holes in off the shelf C.
In fact I’m responsible for a couple of mid level CVEs :-DD
Stuff does need to be rewritten.
Rewritten means new bugs and new security issues.
It's my impression that programmers are not getting smarter, on the contrary...
It's astonishing to see that, today, programmers don't check input and assume many things.
Also because their bosses don't give them the time to carefully think and test.
-
In fact I’m responsible for a couple of mid level CVEs
I'm sure you didn't mean it the way it sounds! :-DD
-
Knowing @bd139 by repute, I wouldn’t be surprised if he did!
-
That was intentional and can be interpreted both ways simultaneously :popcorn:
-
As a general thought regarding programming languages, and not specific to Python (although it definitely is concerned), I have a problem with languages that are tightly coupled with their implementation. This is wrong on many levels.
Yes, this is annoying, especially when they feel free to make seriously incompatible changes between versions so that old programs don't work on new versions.
This.
Even if there is a use_version_x param or whatever, nobody seems to use it. And then to build a interpreter that -could- deal with it at worst with a noisy warning but instead fatal errors out. :palm:
It's as though they resurrected all the worst bits of winword *.doc obsolete versioning, DLL hell and syntax stupidity like it's some kind of competition or homage to MS. If the next version of Python shows up with a floating paper clip, I'm gunna do backflips.
To be fair to Python, this business of producing a new version of the programming language itself every few weeks/months/each-year is not a Python exclusive "feature". Most of the new kid on the block programming languages do this, and to my mind it is an insane way to go about producing tools. Would anyone produce mechanical tools that had a new version every few months which required you to use, say, a version 4.3 screwdriver to insert/remove a version 4.3 screw? No one would try to do this with actual physical tools to a bunch of burly hammer wielding men for fear of serious bodily damage.
Moreover, the practice leads to a sense that everything is ephemeral, everything is in beta, nothing is built to last, nothing has passed the test of time, so why should you bother to produce anything stable, long lived and itself capable of passing the test of time with these tools?
Where it comes to Python, I have to agree with this. Over the years I have tried to install some Python based software but ran into many incompatibilities between versions and OS. Initially I had the impression that Python was easely portable and maintainable but the opposite is true. It is even worse compared to the DLL hell that plagued the older Windows versions. IMHO it is better to write an application in C++ using Qt or WxWidgets and link it statically to have a fighting chance of being able to install & run an application next year compared to using Python.
If you want to distribute a Python application, you have to hand-out pre-configured VM images.
Bottom line: Python is great to tinker a script together but it absolutely sucks for writing applications (unless you want to keep sinking money into software that is essentially finished).
It was so nice to find a program backthen written with delphi, that just did run without any dll frameworks nor heavy installers .. most of the time they still run as back then.
-
IMHO it is better to write an application in C++ using Qt or WxWidgets and link it statically to have a fighting chance of being able to install & run an application next year compared to using Python.
It was so nice to find a program backthen written with delphi, that just did run without any dll frameworks nor heavy installers .. most of the time they still run as back then.
I wonder if it would be useful to show how to create a dynamically linked application that can use either system libraries, or specific versions of the dynamic libraries provided with the software itself. (I can only show an example on Linux, and maybe BSDs and Macs, since they too use ELF binaries.)
Let me sketch the basic idea, since it is rather simple.
Let's say your binary is at /path/bin/appname. It is actually a shell script that sets up the environment variables for the dynamic linker, and then executes (replaces itself with) the actual application binary, /path/bin/appname.bin. This is already very common in Unix/Linux/POSIX/BSD environment: for example, /usr/bin/firefox is a shell script that does exec /usr/lib/firefox/firefox.
You have a full set of dynamic libraries provided with the app installed in say /path/lib/appname/app.libs/, and a full set of symlinks to either system libraries or provided versions in say /path/lib/appname/lib/. The dynamic linker is instructed to only use that directory, /path/lib/appname.lib/, for the dynamic libraries.
The shell script also verifies that none of the dynamic libraries is dangling. (They shouldn't be, as they should be symlinked to the backwards-compatible version of the library, typically the major version.) If it finds any, it just reports that the operating system environment has changed; one way is to launch a helper app that can report (and fix) the dangling symlinks (by pointing them to the provided versions of the dynamic libraries – changing the symlinks is usually a privileged operation on these OSes). That helper app would run exclusively on top of the app-provided libraries, of course.
In essence, each application has a set of symlinks to the dynamic libraries it uses, and a launcher script that tells the dynamic library to use that directory for the dynamic libraries.
At install time, you do need logic that looks at the standard dynamic libraries already installed on the OS, and either heuristically determines (and lets the user override) for each library file whether the OS-provided one or the app-provided one is used; typically just based on the library minor version number.
In Linux, one can use ldd to list the dynamic libraries needed by an application (although you may need to run it recursively to find all the dependencies, since it is perfectly normal for a dynamic library to have other dynamic libraries as dependencies), so you don't actually need to do anything in the C/C++ source code. It is just a matter of determining the full set of dynamic libraries needed.
With Python it is slightly more involved, because the interpreter itself has one set of dependencies, and the modules and scripts another set that are only accessed if actually used.
This kind of app should be self-contained if necessary, but also able to use (bug-fixed) versions of libraries when desired without recompiling.
-
So like windows?
-
The problem with all the bloat hidden in libraries is, it is like brushing all the crap under the carpet. It is still there.
Then you need to choose between truly dynamic or practically static linking. Truly dynamic, you end up with all the pain of managing dependencies and getting the right versions, and for some weird reason I don't fully understand, all automated attempts to manage the dependencies sometimes fail. Another option is to provide the right library versions with the app, either statically linked, or just zipped together so they are "dynamically" loaded but practically static, per app. But this reveals the true amount of bloat, and suddenly a trivial app is 500 megabytes of crap to be downloaded. But at least it works. Hopefully.
-
I think apple have a reasonable solution to this. The apps arrive in bundles which you just drop in the Applications directory. Each bundle is a directory which contains all the resources required to run it. The ABI and API is stable on the OS and the responsibilities of each actor are well defined. The bundles contain one “universal” binary which contains native compiled output for ARM and x86-64.
The current mess we have, which isn’t that bad on Linux really, is mostly API churn on poorly defined crap like the desktop environments and toolkits. The core is very stable.
Sort of the same with windows which has hundreds of different versions of each DLL where they forgot to do the thinking bit before defining a persistent API.
I will say I like Go though. Everything static. This has been the least painful thing for me to deploy anywhere in the last 30 odd years of doing it. Binary might be 30 megs but the heap is tiny!
-
That's fine but most proprietary stuff needs to work on more than one platform so Linuxisms need to go away.
-
I think apple have a reasonable solution to this. The apps arrive in bundles which you just drop in the Applications directory. Each bundle is a directory which contains all the resources required to run it. The ABI and API is stable on the OS and the responsibilities of each actor are well defined. The bundles contain one “universal” binary which contains native compiled output for ARM and x86-64.
Two points:
Stable-ish API, in that you specify a minimum system API version that you're happy to use when you build a native macOS binary application.
The application bundle doesn't have to be a native macOS binary application. As long as the 'binary' is in the right place in the application bundle directory it can be a script and with macOS also being Unix you can use the classic hash bang mechanism to use a script interpreter of choice, allowing you to package anything as a macOS bundle with a little ingenuity. I have seen Python applications, complete with bundled Python interpreter and libraries distributed as macOS application bundles. CrossOver (a commercial repackaging of the wine Windows emulator) uses macOS application bundles to repackage Windows applications into macOS application bundles making running an emulated Windows application look just like you're starting a native application (the resemblance often falls apart immediately after this point of course).
-
So like windows?
None of the applications I used ever did that. They included the dynamic libraries they needed, and if you wanted to change one, you had to replace the file in the application directory.
So, no, nothing like Windows.
That's fine but most proprietary stuff needs to work on more than one platform so Linuxisms need to go away.
No, not everything needs to run on Windows. Works absolutely fine everywhere else.
Really, some days I think it is Windows that needs to go away. (Because it always needs special coddling, always being the odd one out.)
-
I really thing Windows should stay. It should however be tidied up.
But linux, BSD and macOS work slightly differently as well.
-
But linux, BSD and macOS work slightly differently as well.
If you write service/daemon code, they are surprisingly similar. POSIX.1-2008 interfaces in particular are quite portable across these. Usually, the kind of code I write works on all three as-is, except when I design a daemon around some Linux-specific feature. When someone wants to port them to Windows, there is usually some kind of wonkyness that would be easiest to fix by modifying the perfectly working code and use a slightly inferior choice instead. But if there is an incompatibility in BSD or MacOS, it is usually a trivial fix (and I don't mean peppering the code with #if defined(__APPLE__) && defined(__MACH__) (https://sourceforge.net/p/predef/wiki/OperatingSystems/) ... #else ... #endif stuff).
Just my personal experience, though.
But GUI toolkits, enumerating devices, notifications and other non-GUI events, those indeed are a pain even between Linux, BSD, and macOS.
-
The problem is that eventually you end up with autoconf which no one deserves :-DD
I prefer languages and toolchains that are platform agnostic. So Python, Go, .Net, Java generally have much more longevity than native APIs.
Although I'm currently working on something in Swift and SwiftUI because the Qt version of the software doesn't work properly on Macs. It's just completely different and a very comfortable place to be.
-
The problem is that eventually you end up with autoconf which no one deserves :-DD
Eww, no, I meant actual source-level compatibility. No autoconf, no build time tests. Just portable code, with usually no OS-specific stuff.
(And when there is any, I like to separate that stuff into os-specific files, with the common file pulling the correct one based on preprocessor macros. So no configuration either at build time. But easy to change to use OS_name macros set at build time based on uname -o if not preset via a shell or environment variable. Just a plain Makefile to compile suffices.)
I prefer languages and toolchains that are platform agnostic. So Python, Go, .Net, Java generally have much more longevity than native APIs.
Well, POSIX.1-2008 (https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/idx/functions.html) is as old as Python 3 is, without any API changes up to current POSIX.1-2017 (https://pubs.opengroup.org/onlinepubs/9699919799/idx/functions.html), and very compatible with its earlier versions (including Single UNIX Specification) back to 1997 or earlier. (The SUS roots link POSIX back to BSD, although since then, POSIX has added quite a lot of useful stuff. In practice, current BSDs, macOS, and Linux C libraries provide pretty much all of POSIX.1-2017.)
(Anyone writing code for these OSes and using opendir()/readdir()/closedir() instead of glob()/scandir()/nftw() or fts_{open,read,children,set,close}() is not doing their job properly, for example.)
And if you write in C instead of C++, you'll use Gtk, with Gtk 3 released in Feb 2011, although I'd consider 3.8 (Mar 2013) the first stable version. It does have some annoying deprecations in later 3.x versions, and although 3.22 (Sep 2016) was supposed to be the latest version (with only bug fixes, no new features added as minor revisions; latest is 3.22.30)), a 3.24 was released in Sep 2018 (with latest revision, 3.24.34, released in May 2022 thus far).
While the widgets did change from Gtk 2 to 3, it wasn't a painful change for me, although some other developers I know did find it very annoying to deal with.
Thus, based on my personal experience with these, I do disagree.
-
The problem is that eventually you end up with autoconf which no one deserves :-DD
While the widgets did change from Gtk 2 to 3, it wasn't a painful change for me, although some other developers I know did find it very annoying to deal with.
It is an enormous and over bloated overhead just for cosmetic changes introduced by Gtk3
So there is no really much advantage on it.. sounds exactly like MS wonder world..
upgrade just for upgrade
And... considering AUTOTOOLS.. just look the recent AVRDUDE shift from a messy bad implemented autotools made by folks wo a clue on it.. using a very competent done CMAKE by some clever folk
AVRDUDE now uses a VERY VERY VERY well done cmake template..
nobody is forced to use a veteran master tool like autoconf..
... however... competent tools like OCTAVE running on multiple *NIX and mainframes are likely to use it
Paul
-
I don't know any magical solution to this library dependency crap. The only mitigation that I can think of is to limit dependencies to the strict minimum, which is unfortunately the exact opposite of what is being done.
As to bundling all required shared libraries with every application, that's a mitigation for getting a working piece of software, but that's even more storage bloat. Shared libraries were supposed to save storage (and in some cases, RAM too) space. If they don't, then they are basically getting absurd.
Python doesn't solve anything much here: you have to distribute the whole sheband (the version of Python you validated your software against, the right libraries, etc) in a bundle as well. Otherwise users are very likely to end-up with a non-working piece of shit outside of your own R&D department. Talk about bloat.
Sure the non-binary approach alleviates this to an extent - just let the user recompile the application for their given environment, with some version requirements for the libraries being used. Of course this doesn't scale - you'll be stuck with a very narrow pool of users using this approach.
In fact, this is one of the main reasons Linux has not taken off on the desktop, much more so than the desktop environments themselves. The difficulty for third parties to distribute software in a binary form, compared to commercial OSs.
-
(..)
As to bundling all required shared libraries with every application, that's a mitigation for getting a working piece of software, but that's even more storage bloat. Shared libraries were supposed to save storage (and in some cases, RAM too) space. If they don't, then they are basically getting absurd.
(.)
This **IS** what most (if not all) apps do for the MS so called compatibilty
It is either a complete mess of DLLs hell ..
or a self contained duplicated bundle of already compiled libs.. (kinda LD_LIBRARY_PATH in reverse)
The DLL mess in MS is know to be an insane and over bloated solution...
although it works it can barely be called like that.
Paul
-
Tiobe Index.
"August Headline: Python going through the roof
Python seems to be unstoppable. The scripting language gained another 2% this month. It is now at an all time high of 15.42% market share. It is hard to find a field of programming in which Python is not used extensively nowadays. The only exception is (safety-critical) embedded systems because of Python being dynamically typed and too slow. That is why the performant languages C and C++ are gaining popularity as well at the moment. If we look at the rest of the TIOBE index, not that much happened last month. Swift and PHP swapped places again at position 10, Rust is getting close to the top 20, Kotlin is back in the top 30, and the new Google language Carbon enters the TIOBE index at position 192. -- Paul Jansen CEO TIOBE Software"
-
It is a good moment to teach Computer Science, with Python as first programming language, in Secondary School.
-
They do that here :-+
-
Oh great, a whole generation who think that indentation = semantics. :(
-
I think it’s more a generation who can solve problems without getting pissy :-DD
-
And also with a lot of patience. :=\
I'm indifferent on Python, but compared to C it is slow. For the FPGA reversing I'm doing the code for the open source tools is written in Python and I used it to do some preliminary work, but boy it takes it time when you need to process millions of bits. So I switched back to C in a heartbeat. :)
-
Not getting pissy, taking the piss possibly, but not getting pissy. :)
I really don't think that Python is a good starting place as an instructional language, too many idiosyncrasies, way too many ways of doing things and it's quite hard to reveal how to do things in "layers" as students grasp concepts one by one.
The older 'instructional' languages are probably badly suited to educating people for the future - they were all designed with building up to using full second or third generation programming languages. That I think would poorly serve current students. Sure, they need the concepts that second and third generation languages use, but the older 'instructional' languages completely omit features that are de rigueur for modern languages. Perhaps it's time for a new 'instructional' language.
The "indentation as semantics" is a serious point however. It's a terrible feature for an instructional language because (1) only 1 popular language works that way resulting in (2) crashing and burning when you hit a language that doesn't work that way. All of us who have habitually indented languages with classical block semantics 'get' the Python indentation thing immediately. Some of us may not like it, but we get it. If all you knew was the Python "indentation as semantics" approach where would you be when faced with a language that doesn't work that way? Very confused for quite a while I suspect.
-
It’s a bit of a straw man that. It’s not an instructional language. You can use it as one if you choose.
I mean it could have semantic braces instead like the C-like languages. That left us in the domain of non memory safety C, bonkers JavaScript, general fucking shit show PHP and industrial scale misadventure and the main reason we’ve never been visited by an alien race C++ . Those are, well someone more mired with idiosyncrasies as I think I alluded to.
l ask you a question; have you ever done a 3-way merge on 7,000 Java files? Then you’ll know why braces aren’t necessarily the best idea out there. The test suite checks semantic errors in python. In Java the compiler twangs your ball sack for an hour asking you to inject squiggles not because it needs to be told what is semantic and what isn’t.
The real problems in the world are far greater than semantic whitespace which might not be a bad idea after all.
-
It is a good moment to teach Computer Science, with Python as first programming language, in Secondary School.
In which case, that should be definitely not be called Computer Science, but rather Programming courses. And I'll be fine with that.
-
... If all you knew was the Python "indentation as semantics" approach where would you be when faced with a language that doesn't work that way? Very confused for quite a while I suspect.
I might believe that except Python's syntax is pragmatic not dogmatic. Real Python code often relaxes the "off-side rule".
-
It’s a bit of a straw man that. It’s not an instructional language. You can use it as one if you choose.
Erm, no it's not a strawman because I never said that it was an instructional language. I merely opined that to use it in place of an instructional language was probably not a great idea.
There's quite a body of experience from the world of education that suggests that specifically designed beginner instruction languages are a good thingTM. It's instructive (pun unintentional, but I'll take credit for it) that Smalltalk came of the the Learning Research Group at Xerox' Palo Alto Research Labs from an effort to make a programming language that could be taught at infant school level.
They actually succeeded in teaching 6 year olds to program using it. Remember that's about when you start to learn to read and write the language that you've grown up with, language that will be parsed with a whole human brain for syntax and semantics, not the pathetic fussy brain of a literal computer. It's quite an achievement to have got six year old to write any code that actually works.
I mean it could have semantic braces instead like the C-like languages. That left us in the domain of non memory safety C, bonkers JavaScript, general fucking shit show PHP and industrial scale misadventure and the main reason we’ve never been visited by an alien race C++ . Those are, well someone more mired with idiosyncrasies as I think I alluded to.
l ask you a question; have you ever done a 3-way merge on 7,000 Java files? Then you’ll know why braces aren’t necessarily the best idea out there. The test suite checks semantic errors in python. In Java the compiler twangs your ball sack for an hour asking you to inject squiggles not because it needs to be told what is semantic and what isn’t.
The real problems in the world are far greater than semantic whitespace which might not be a bad idea after all.
You seem hung up on braces. Bad experience with orthodontistry? :) A litany of the failures of assorted programming languages is really neither here nor there, nor is getting yourself into the situation where you even need to contemplate the idea of doing a three-way merge of 7,000 source files**. I'd opine that none of them are particularly good, and especially they're none of them particularly good as an introduction to programming. Far, far, too many introductory courses to programming are introductory courses to programming in language x rather than courses in programming per se.
Of relevance is my own introduction to programming. It was at a one week residential summer school in 1974 as a test subject for the "Computer Education in Schools" syllabus that ICL cooked up at the behest of the government of the day. They produced their own programming language 'CESIL*' which was 'assembler made easy' which they taught in the first half of the week, and they taught BASIC in the second half of the week. I spent the next year helping one of the math's teachers at school teach that course, taught myself FORTRAN and COBOL, and took a commercial job as a junior programmer in 1976 where I was bashing out COBOL for a software house that serviced the Merchant Banks of the day. So that approach clearly had some merit as far as the computer industry of the time was concerned.
The question is what would make a good introductory language now? It certainly isn't assembler-lite like CESIL was, but neither is it a language like Python that throws in everything including the kitchen sink and has idiosyncrasies that make it non-representative of programming languages as a whole.
* Computer Education in Schools Introductory Language
** To paraphrase Lady Bracknell "To have to do a three-way merge of one source file is unfortunate; to have to merge 7,000 of them smacks of carelessness."
-
IMHO Pascal is still pretty good at forcing people to think about the structure of a program before starting to code. Python is just scribbles on a napkin that you code in a real programming language later on.
-
I'm indifferent on Python, but compared to C it is slow. For the FPGA reversing I'm doing the code for the open source tools is written in Python and I used it to do some preliminary work, but boy it takes it time when you need to process millions of bits. So I switched back to C in a heartbeat. :)
It's getting better :popcorn:
https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython
-
.
-
CPython 3.11 is on average 25% faster than CPython 3.10 when measured with the pyperformance benchmark suite,
and compiled with GCC on Ubuntu Linux. Depending on your workload, the speedup could be up to 10-60% faster.
Which means still 20 times slower than C/C++...
-
CPython 3.11 is on average 25% faster than CPython 3.10 when measured with the pyperformance benchmark suite,
and compiled with GCC on Ubuntu Linux. Depending on your workload, the speedup could be up to 10-60% faster.
Which means still 20 times slower than C/C++...
...but with 100x faster development cycle than C/C++.
That means Python is great for initial dev/experiments and perhaps production if it's fast "enough" or the critical bits are written in C/C++. But, yawn, this is age old argument repeated a thousand times here already, I must be bored at work or I wouldn't even have posted this. I guess Python helped me finish my work early :P
-
We have to wait a few years to see how this Python hype evolves. Kids start learning Python in school now. Will Windows 13 be written in Python? But please don't complain if the greybeards will remind you later 'we told you so'. >:D
-
...but with 100x faster development cycle than C/C++.
But only when you are up to speed with Python :-DD
And when you are experienced enough with both it might not make a difference in which language you write.
-
IMHO Pascal is still pretty good at forcing people to think about the structure of a program before starting to code.
Pascal, or derivatives like Turbo Pascal? Turbo Pascal makes you focus on structure. Real Pascal makes you focus on working around all the basic things it doesn't have, like word length control and logical operations.
-
...but with 100x faster development cycle than C/C++.
But only when you are up to speed with Python :-DD
... and not up to speed with the C++ standard library, which contains all that useful stuff such as expandable arrays and trees and hash tables and algorithms such as sorting and so forth.
It's possible Java and separately JavaScript might lie somewhere between the development time of C++ and Python -- Java closer to C++, and JavaScript closer to Python, and bot run maybe 20% slower than C++, not 20x slower.
And when you are experienced enough with both it might not make a difference in which language you write.
I would think if you know both well, the difference would be no more than 2x, and maybe quite a bit less than that.
C++ compilation time is not significant on reasonable sized programs on modern computers. Any difference is purely in convenience of libraries and the amount of typing needed.
-
It's possible Java and separately JavaScript might lie somewhere between the development time of C++ and Python -- Java closer to C++, and JavaScript closer to Python, and bot run maybe 20% slower than C++, not 20x slower.
I don't agree. I ported a library from pure C to pure Python and for sure it's 20 times slower.
The lib provides an api to write ADC samples to a file in a certain format and it also applies some scaling to all samples.
Other people wrote a Python wrapper around the C library because in pure Python it was terribly slow.
Both those people and me did the speed comparison and the speed difference is huge (at least 20x).
There's a reason why Python (and Numpy as well) is written in pure C...
-
I ported a library from pure C to pure Python and for sure it's 20 times slower.
Not sure why you did this :-//, but overall - a terrible idea, at least cover in cython with a minimalistic porting and let it's available to Python world
-
We have to wait a few years to see how this Python hype evolves. Kids start learning Python in school now. Will Windows 13 be written in Python? But please don't complain if the greybeards will remind you later 'we told you so'. >:D
I for one think that Python has too many "flaws" and is knowing too much "hype" not to eventually get phased out.
When and how, I do not know. It will have to be replaced by something else of similar nature - a language easy to use for a very wide range of people including a lot of non-software developers.
I ported a library from pure C to pure Python and for sure it's 20 times slower.
Not sure why you did this :-//,
Me neither, but the only "valid" reason I see is that Karel would have been missioned to do this by his boss, or a customer. Doing that from your own will doesn't seem very plausible, so that must come from some order you can't decline. :-DD
-
This is an electronics forum, which is one of the areas where Python is not as widely used due to its speed. This is very noticeable in the comments, always obsessed with speed, as if speed were the only parameter of importance.
-
We have to wait a few years to see how this Python hype evolves. Kids start learning Python in school now. Will Windows 13 be written in Python? But please don't complain if the greybeards will remind you later 'we told you so'. >:D
I for one think that Python has too many "flaws" and is knowing too much "hype" not to eventually get phased out.
When and how, I do not know. It will have to be replaced by something else of similar nature - a language easy to use for a very wide range of people including a lot of non-software developers.
I agree. For starters such a language will need to be governed by some form of a standard committee to ensure prolonged compatibility where it comes to the language syntax and libraries. Python is too much of a moving target to be useful for commercial software development.
-
Python is too much of a moving target to be useful for commercial software development.
I don't think that is true at all.
There are many big tech firms successfully using Python, I won't list them here as they are so easy to find. Indeed that is a big part of the momentum Python has, no doubt many contributions (https://www.zdnet.com/article/programming-languages-python-just-got-a-boost-from-facebooks-meta/) coming from there. However, I think it tends to be more server side, web tech stuff rather than desktop apps. Dropbox is the only hugely popular desktop app I can think of.
-
This is an electronics forum, which is one of the areas where Python is not as widely used due to its speed. This is very noticeable in the comments, always obsessed with speed, as if speed were the only parameter of importance.
Yeah, only the
- ERP system for the production
- the product testing automation
- release scripts for the FW
- and the HW
- all the machine learning
is running on python where I work. The backend and the website hosting not yet because hiring JS developers is still easier.
Python might be slow, but while people who never actually used it write these highly opinionated long posts, that it's bad because -insert reason here-, using the same time we just write scripts that gets the job done.
-
Server side is always a highly constrained / defined environment. For desktop use the picture is entirely different; Python is a huge PITA for desktop software distribution.
-
Your previous comment stated 'commercial use', seems that you specifically meant desktop commercial apps.
I agree somewhat with that, desktop app distribution is not slick, like java :rant:.
-
It's possible Java and separately JavaScript might lie somewhere between the development time of C++ and Python -- Java closer to C++, and JavaScript closer to Python, and bot run maybe 20% slower than C++, not 20x slower.
I don't agree. I ported a library from pure C to pure Python and for sure it's 20 times slower.
So, in fact, you are agreeing with me.
-
This is an electronics forum, which is one of the areas where Python is not as widely used due to its speed. This is very noticeable in the comments, always obsessed with speed, as if speed were the only parameter of importance.
Of course speed is not the only parameter of importance. No one claims that. But it *is* important. For any given application there is "fast enough" and "not fast enough" and C is on the correct side of that line more often than Python is.
Many things are fine running on Python on a 4 GHz processor, but they'd be just as fine running in C on a 200 MHz processor. Those are a lot cheaper, and use a lot less energy.
-
Forget speed for a moment, what about efficiency? Quite how much physical power do you use if you choose to do identical tasks in native Python (or anything equally inefficient) rather than a typical 3GL? How many more servers do you need to handle your workload? How much more air-con to keep them happy?
The limiting factor in new data centre builds at the moment increasingly seems to be local electricity capacity. Even if you're minded to ignore the environmental impact of rolling out data centres at the rate we are at the moment, pure cost and the fact that it's becoming harder and harder to find somewhere where it's practicable to build one are going to make efficiency a more important consideration again.
-
Yep, software devs have been spoiled by abundant and relatively cheap, while increasingly powerful hardware for a few decades now, but if the trend shifts back toward more efficient programming, it will be for energy efficiency reasons, and you can bet your ass that this is going to be a definite concern soon enough. Heck, energy efficiency already IS a huge concern, and if software is more or less "left alone" for now, it's only because there is considerable commercial pressure and so we're just closing our eyes just because it's convenient. It may not last forever. (Or if it does, that means we're definitely even more stupid and greedy than I thought.)
-
.
-
Python might be slow, but while people who never actually used it write these highly opinionated long posts, that it's bad because -insert reason here-, using the same time we just write scripts that gets the job done....
I admit I was a little slow getting around to using Python (to rescue some colleagues' embedded system project in 2007 that would have failed had I not chosen Python). I would, however, say that what you write has been true since the mid-1990s. A related issue is Python can be so accommodating that many never learn to use it as a high level language.
EDIT: changed "Another issue ..." to "A related issue ..."
-
if the trend shifts back toward more efficient programming, it will be for energy efficiency reasons
If Python fails to meet the "runtime performance or efficiency" requirements, write those parts in C.
If C fails to meet the "development time performance or efficiency" requirements, write those parts in Python.
Netflix has been using Python (https://netflixtechblog.com/python-at-netflix-bba45dae649e) for years but my guess is they don't using for the streaming code. In fact, they have an eye on alternatives to come in the near future (https://towardsdatascience.com/why-python-is-not-the-programming-language-of-the-future-30ddc5339b66).
But right now, it's horses for courses, where a combination of Thoroughbreds (https://en.wikipedia.org/wiki/Thoroughbred) and Clydesdales (https://en.wikipedia.org/wiki/Clydesdale_horse) makes a powerful team.
-
Watched a good video today about the Linux package manager, Nala.
It's a python wrapper for APT but it presents the information much cleaner. A perfect application for python. I did chuckle watching when the guy had to apt install 5000+ python depends along with the program.
-
if the trend shifts back toward more efficient programming, it will be for energy efficiency reasons
If Python fails to meet the "runtime performance or efficiency" requirements, write those parts in C.
If C fails to meet the "development time performance or efficiency" requirements, write those parts in Python.
It is notoriously hard to know in advance exactly which parts of a non-trivial application will be the actual bottleneck. If you guess wrong then you have to re-write Python code into C, or you spent time writing something in C initially when you didn't have to.
And the Python:C interface is not zero-friction, it has to be designed, so moving it up or down the software stack later has quite some cost.
I prefer to develop in a single language that I can write just as quickly as Python, but that runs much faster by default, and within a very small percentage of the speed of C with a little incremental work such as adding explicit type declarations or turning selected low level functions (or parts of a call tree) into macro / inline-only / template. WITHOUT extensive re-write to do it.
For the past 20 years my language of choice for this has been Dylan, a language designed by Apple in the early 90s to replace all their use of C++, SmallTalk, and Lisp. Before that, the best option was Common Lisp (and in fact that is more viable than ever now). The modern "new" language implementing the same ideas (mostly) is Julia, although Swift is gradually getting closer and closer too.
-
Dylan looks very interesting but it is not even among TIOBE's top 100 languages.
I generally find Python is "low-friction" but once in a while, you have to play with a bit to discover a simple solution, probably because it has developed organically over many years to address many common problems. Sometimes your problem is not so common.
Parts of Python are showing signs of senescence. I needed to create a custom importer to tweak some DSL code so that it will compile. I looked at using importlib, but it appears to still be a work in progress. As of Python 3.10, it has over 7000 words of documentation, 12 supporting PEPs and 20 deprecated objects.
-
Dylan looks very interesting but it is not even among TIOBE's top 100 languages.
It's somewhat close to death :-(
In the mid to late 90s there were three major implementations:
1) Apple for MacOS. They went so far as announcing at WWDC that they were replacing C++ with Dylan throughout their code, and handing out CDs with a beta version of an IDE and compiler. Sadly, Dylan was one of the first things to get "Steve'd" when Apple was (for other reasons) losing billions of dollars per quarter and couldn't afford long term projects, no matter how promising.
2) CMU for Unix, specifically HP-UX. (PA-RISC "Snakes" was the best CPU around at the time)
3) Harlequin, a commercial vendor of Lisp, Smalltalk, Standard ML (and Haskell?), for Windows.
By 1998 the CMU people had graduated and moved on to other things. Fortunately they officially open-sourced (MIT license) what they had done, and I became part of a group (Dylan Hackers) that picked up and continued their work. Their compiler, "d2c", is as the name suggests a compiler that outputs very ASM-like C code. We very quickly ported it to work on x86 and PowerPC Linux, and to MacOS. It's very portable, I've used it myself on SPARC and MIPS and RISC-V.
d2c is still my favourite, because it is easy to interface to C (it generates C!), and its object representation doesn't steal any bits from machine pointers or integers, or float/double.
In 1999 Harlequin was bought by Global Graphics, who wanted them only for their PostScript interpreter. They shut down or spun off everything else. The Harlequin Dylan team managed to get the rights to the Windows IDE and compiler and libraries which, at the time, had something like 100 person-years of work in it (30 years in the "MPS" memory-manager / garbage collector alone). They formed a company, Functional Objects, and released Functional Developer (for Windows) in 2000. At first they were trying to sell it, and then later made it free and tried to make money with consulting and support. Eventually they simply turned all the code and rights over to the Dylan Hackers open source project, where it became the main focus of work.
Activity has trailed off, and I stopped being heavily involved when I switched my attention to RISC-V. But there continue to be releases with the most recent one being at the end of 2020. OpenDylan (nee Harlequin Dylan, nee Functional Developer) has gained an LLVM back end instead of x86 Windows native code generator, and from LLVM you can output webasm if you want.
You can actually play with Dylan in your web browser: https://play.opendylan.org/
Try the following:
define method fib (n :: <integer>)
if (n < 2) n else fib(n - 1) + fib(n - 2) end
end;
format-out("%d", fib(39));
For me that takes 1.47 seconds to compile and run and output 63245986. (I usually use fib(40) for benchmarks, but there seems to be a maximum CPU usage on the web server)
The equivalent Python takes 15.8 seconds on my M1 Mac. In C compile and run takes 0.53 with -O0 or 0.40 with -O2.
I don't actually know what server the Dylan playground is running on, but clearly it's closer to C than to Python.
You can make the Dylan code equivalent to Python by removing the type declaration on the function argument.
define method fib (n)
if (n < 2) n else fib(n - 1) + fib(n - 2) end
end;
This makes it run more slowly. Sadly, the Playground time limit makes me drop it to fib(37), which prints 24157817 in 1.3 seconds. Python on my M1 Mac uses 6.4 seconds for that, C 0.26 (compile AND run).
A local install of OpenDylan will of course run faster and not have the CPU time limit!
Dylan, alone of these languages (but like Common Lisp or Julia), lets you write this function in a completely different way:
define method fib (n == 0) 0 end;
define method fib (n == 1) 1 end;
define method fib (n)
fib(n - 1) + fib(n - 2)
end;
The online playground runs this for fib(37) in 1.3 seconds -- no detectable speed difference at all for the abstraction.
But now Dylan has another trick!
define open generic fib(n);
define method fib (n == 0) 0 end;
define method fib (n == 1) 1 end;
define method fib (n)
let res = fib(n - 1) + fib(n - 2);
add-method(fib, method(n == n) res end);
res
end;
format-out("%d", fib(37));
This still outputs fib(37) = 24157817 in 1.3 seconds.
BUT ... now we can do fib(89) = 1779979416004714189 in still 1.3 seconds.
Try that with the recursive C or Python code and you'll be there a very very long time. I've tried to estimate, and I think the C code (with -O2) would take about 350 years.
-
It is notoriously hard to know in advance exactly which parts of a non-trivial application will be the actual bottleneck. If you guess wrong then you have to re-write Python code into C, or you spent time writing something in C initially when you didn't have to.
It's not black and white, there is a grey area, but closer to Python rather than C
[attach=1][attach=2]
-
cython got you a speedup of 4.3x.
C gets you *another* factor of 10 to 20 speedup
As demonstrated in my post immediately before yours, Dylan code looks like Python (and is as fast/easy to write), but runs much much closer to C speed than cython does.
On my x86 Linux machine (1st gen ThreadRipper):
24.2 Python 3.9
5.1 Dylan with no declarations, base cases handled by virtual function dispatch (separate method declarations)
4.8 Dylan with no declarations (same style as Python)
1.3 Dylan with fib argument declared as <integer>
1.0 Javascript with no declarations (see below)
0.75 C without -O
0.7 Dylan with fib return value also declared as <integer>
0.5 C with -O1
0.2 C with -O2
The JavaScript source code:
function fib(n) {
return n < 2 ? n : fib(n-1) + fib(n-2);
}
console.log(fib(40));
Running the Javascript:
$ time node fib.js
102334155
real 0m1.034s
user 0m1.031s
sys 0m0.004s
-
PHP, Matlab and other interpreted languages would be missing in the comparison. The obvious conclusion is that interpreted languages should not be used because, in all cases, they can be replaced by much faster compiled languages.
The reality is that, surprisingly, interpreted languages are still used extensively.
-
In the field of teaching/learning, interpreted languages have the advantage of being much faster in the trial and error cycle that is so didactic when learning a new language or when learning to program.
In the case of block programming, Scratch is the most popular. Based on Javascript, it has been ranked 35th on Tiobe for several months. Not bad for a language aimed at children learning programming. But in the case of text languages, I prefer Python to Arduino's C++.
-
In the field of teaching/learning, interpreted languages have the advantage of being much faster in the trial and error cycle that is so didactic when learning a new language or when learning to program.
That hasn't been true for student-sized programs written in C/C++. Pascal or similar since ... I was going to say since Linux on an original Pentium, but really, it's since Turbo Pascal 1.0 on a Z80. Or THINK Pascal / THINK C on a Mac Plus.
-
This still outputs fib(37) = 24157817 in 1.3 seconds.
BUT ... now we can do fib(89) = 1779979416004714189 in still 1.3 seconds.
What?? How does that work.. Staring at the code and can't figure it out.
-
This still outputs fib(37) = 24157817 in 1.3 seconds.
BUT ... now we can do fib(89) = 1779979416004714189 in still 1.3 seconds.
What?? How does that work.. Staring at the code and can't figure it out.
Ah, someone didn't just skip over... :-)
It dynamically adds new methods to the fib() generic function (virtual function in C++ terms).
It's like doing this in Python, except what is being added to the dictionary are functions (closures) not just the answer:
fibs = {}
def fib(n):
if n in fibs:
return fibs[n]
if n in {0, 1}:
return n
res = fib(n-1) + fib(n-2)
fibs[n] = res
return res
print (fib(89))
-
In the field of teaching/learning, interpreted languages have the advantage of being much faster in the trial and error cycle that is so didactic when learning a new language or when learning to program.
That hasn't been true for student-sized programs written in C/C++. Pascal or similar since ... I was going to say since Linux on an original Pentium, but really, it's since Turbo Pascal 1.0 on a Z80. Or THINK Pascal / THINK C on a Mac Plus.
Yep.
Now, the interactive nature of interpreted languages still makes them... not necessarily "faster" for development, but more... interactive. Yeah.
So if you're constantly "trying" things, cutting the modify/save/compile cycle, even if it's pretty short, seems more convenient for some - in particular beginners.
Thing is, it does promote a pretty "tinkery" approach to programming, which is definitely not how one should properly *learn* some new skill IMHO, at least if it's in any serious way.
That's pretty much what happened with BASIC. We know how that goes.
It's "learning" as if you were a fly, just flying around your target in all directions until you finally hit your goal and move on.
But it's precisely the strength of languages such as Python: they appeal to non-programmers, which opens a gigantic "market". So many of its users are precisely people who do *not* want to learn programming in a sane way. They just want to get some results - even if they don't quite grasp how they got there, who cares, if they get stuck they'll just flood online forums.
-
It's like doing this in Python, except what is being added to the dictionary are functions (closures) not just the answer:
Ah, got it! That's clever..
For that particular function, it's possible to memoize results, rather than methods, and get a boost:
$ cc -O2 ~/tmp/fib.c -o /tmp/fib && /tmp/fib 45
recursive, result: 1134903170, time: 3.408709 sec
memoised , result: 1134903170, time: 0.000003 sec
Source:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
static unsigned long fib(unsigned long n) {
return n < 2 ? n : fib(n - 1) + fib(n - 2);
}
static unsigned long fib2(unsigned long n) {
static unsigned long tab[100];
if (tab[n]) return tab[n];
tab[n] = fib(n);
return tab[n];
}
static void measure_time(const char *msg, unsigned long (*fn)(unsigned long),
unsigned long n) {
clock_t start = clock();
unsigned long result = fn(n);
clock_t duration = clock() - start;
printf("%s, result: %lu, time: %.6f sec\n", msg, result,
(double) duration / CLOCKS_PER_SEC);
}
int main(int argc, char *argv[]) {
unsigned long n = 1;
if (argc > 1) n = strtoul(argv[1], NULL, 0);
measure_time("recursive", fib, n);
measure_time("memoised ", fib2, n);
return 0;
}
-
It's like doing this in Python, except what is being added to the dictionary are functions (closures) not just the answer:
Ah, got it! That's clever..
For that particular function, it's possible to memoize results, rather than methods, and get a boost:
Right, except the code you present can't possibly work. fib2() needs to recursively call itself, not fib().
In Dylan you get full virtual function dispatch on the newly-added methods, and in a way that is more powerful than in C++. You can dispatch based on the most specific subclass (as in C+, Java, Python etc), or on various derived types such as singleton() (as seen in my code there), ranges of values, unions of different types. AND the virtual dispatch is done using ALL arguments of the method, not just the first one.
-
The question is what would make a good introductory language now? It certainly isn't assembler-lite like CESIL was, but neither is it a language like Python that throws in everything including the kitchen sink and has idiosyncrasies that make it non-representative of programming languages as a whole.
I'm really not convinced that this idea that Python is fundamentally a bad language for introducing Computer Science holds because it 'throws in everything'. The argument seems to be that 1. rigour and 2. lack of alternatives contributes to a language's success as a teaching language. In other words, a language that forces your hand into doing things 'properly', because there simply is no other way. I'm not sure this is actually good for learning the underlying 'whys', though, and actually understanding the fundamental concepts that a computer science education is trying to give you.
What it also means, more practically, is that such a language will have a narrow scope - it might be suitable for object-oriented programming, but not functional programming, and so on, because that would offer too many choices and the flexibility to do stupid things that don't make sense. This leads to a lot of time and energy wasted on learning the syntax and boilerplate associated with the 'appropriate' language for the given topic, rather than the actual computer science you're there to learn. Instead of computer science, you spend a lot of time learning a handful of languages poorly, and precious little learning concepts (ie. 'programming' and not 'computer science'). In fact, you make this point yourself ('too many introductory courses to programming are introductory courses to programming in language x'), so I am surprised that you don't see that the alternative to this is a flexible language like Python that includes the constructs necessary for any sort of programming.
I believe that such an education, like any other, should be guided by a teacher, who can introduce the computer science concepts in a natural progressive fashion, while providing feedback and guidance based on the students' choices. Python lends itself well to this approach, as it is flexible enough to support almost any computer science concept, and with a simple and easy to learn syntax that can carry a student from a grade-school one-line Hello World through the vast majority of computer science outside of systems programming. Sure 'Pythonic' code is fairly idiosyncratic due to some 'unique' language features - like idiomatic code in any language - but you don't have to teach that style (and the reasoning behind it). At least until the fundamentals are well understood, at which point it becomes a marketable skill in one of the most popular languages currently in use, and not just a 'toy' you used to learn like most teaching languages have been or likely will be.
I'm sure Python is not the best choice to teach each branch of computer science, but it is fairly decent for most of them, and certainly for important fundamentals like data structures, OO, functional etc, and is actually useful and used in the real-world too. And as someone who had to struggle to stay awake through the first half of courses being 'learn basic Java' or 'learn basic Scheme' or 'learn basic Perl' before I could actually get anything useful out of them, I think it would be a vast improvement on the way I was taught 15 years ago to have a nice linear progression through these concepts using the same language with the same syntax that doesn't burn half the course's instruction time and a lot of student effort in solving basic syntax problems that are decided not computer science related.
They actually succeeded in teaching 6 year olds to program using it. Remember that's about when you start to learn to read and write the language that you've grown up with, language that will be parsed with a whole human brain for syntax and semantics, not the pathetic fussy brain of a literal computer. It's quite an achievement to have got six year old to write any code that actually works.
I don't know about you, but I find simple Smalltalk quite a bit more inscrutable than Python, so I'd wager you can teach those same 6-year-olds basic Python too. However, I don't think 6-year-olds are a good judge of a language for teaching computer science, which is about high-level conceptual ideas and not making the computer do something. To get a reasonably good sense of what programming is about, before formal computer science, Scratch is much better suited, and completely obviates the need for 'syntax' as we know it.
-
Simply to show the convenience of it. The cache decorator takes away the step of implementing it yourself each time. It also takes away the need to understand how it works. You learn to work on the abstracted level not in the nitty gritty details. Horses for courses.
import functools
@functools.cache
def fib(n):
return n if n<2 else fib(n-1)+fib(n-2)
for n in range(100):
print(fib(n))
And yes, we all know there is a closed form for the fibonacci numbers, before anyone goes smart-ass =)
And I'm on the fence about the python ternary syntax...
-
The question is what would make a good introductory language now? It certainly isn't assembler-lite like CESIL was, but neither is it a language like Python that throws in everything including the kitchen sink and has idiosyncrasies that make it non-representative of programming languages as a whole.
I'm really not convinced that this idea that Python is fundamentally a bad language for introducing Computer Science holds because it 'throws in everything'. The argument seems to be that 1. rigour and 2. lack of alternatives contributes to a language's success as a teaching language. In other words, a language that forces your hand into doing things 'properly', because there simply is no other way. I'm not sure this is actually good for learning the underlying 'whys', though, and actually understanding the fundamental concepts that a computer science education is trying to give you.
My objections to Python:
- the syntax. The most minor of my complaints, but I want it out of the way
- there is toooooo much language to learn. Too many constructs, too many rules. You spend more time learning the language than learning how to use it. Sure, Java and C++ and almost everything else is worse. Scheme, assembly language, and Logo are better. Maybe SmallTalk is better too, but it's weird. Maybe Forth or Postscript.
- there is too much that is magical, that you can't see how it works. Arrays, dictionaries, strings ... all that stuff.
- anyone who learns with Python is going to come out of it with no idea what a pointer is. No idea about memory management using heaps or stacks.
- you can't replicate the magical stuff, make your own version of it. In some cases you can, but it will to 50x slower than what is built-in.
- in general, Python is a language for gluing other people's libraries together, not for writing the libraries. OK, that might be what a lot of people spend their working lives doing, but someone has to know how to write the libraries. And I think that should be anyone with "Computer Science" in the title of their degree. The pure library users can learn that at a trade school, not at a Computer Science degree in a proper university. Or in that one CS paper that people in other subjects have to do.
I think assembly language is good to start with. Not an extremely complex one such as x86_64 or armv8 with manuals several thousand pages thick. And not something like CESIL. I had to look that up. It's got 14 instructions; an implied accumulator register; as many named (6 char names) variables as you want (implicitly declared); simple I/O and arithmetic; an unconditional jump; branch if negative and branch if zero; named labels with the same naming rules as variables (no way to tell them apart visually). No arrays, no strings (except string literals you can only print), no pointers or concept of a memory array, no subroutines.
I think RISC-V RV32I is an excellent intermediate position. Only 37 instructions, and only half a dozen instruction types in 4 binary instruction formats, as load & JAL share format with ALU immediate and store shares format with conditional branch. You can write *any* kind of program in it. multiply and divide and floating point need library functions, but you can write your own and if you do a good job they can be as good/fast as the standard ones.
Perhaps more importantly, you can tell gcc or llvm to compile any C or C++ (or Rust, ...) program to RV32I, which makes it very easy to incrementally move to another language once you get more advanced, see how things are compiled without getting surprised by instructions you haven't learned etc.
As small as it is, I did an experiment a few weeks ago where I tried to subset RV32I to the bare minimum. I got it down to the 10 most common instructions which can emulate any of the missing instructions efficiently -- no more than 3 or 4 needed. And the missing instructions are mostly relatively rare, statically and dynamically.
I hand-translated a compiled version of my Primes benchmark to this 10 instruction subset, and the code expanded by less than 30% -- and the execution time by much less than that.
You could start people programming using this 10 instruction subset that can be learned in half an hour (5 minutes for the bright ones).
And it does *everything*. Registers and RAM. Pointers and arrays and structs. Stacks and recursive function calls. Objects and virtual functions. You just need to provide some library for I/O and maybe for malloc/free (or implement your own). You can run the resulting programs on emulators or on real, cheap, hardware at full native speeds.
GCC and LLVM could be taught how to use only these instructions. I don't know how easy it would be to get that upstreamed. Maybe too hard.
As the inconvenience of their lack is felt, the missing RV32I instructions can be emulated with a very simple macro facility with I think probably just one dedicated temporary register reserved for it.
My earlier message:
https://www.eevblog.com/forum/microcontrollers/what-is-the-right-way-to-learn-programming/msg4328953/#msg4328953 (https://www.eevblog.com/forum/microcontrollers/what-is-the-right-way-to-learn-programming/msg4328953/#msg4328953)
NB. one of those 10 instructions, NAND, is not in fact a RISC-V instruction. I wanted to get rid of AND/OR/XOR, at least temporarily. They can all be synthesised with 2-4 NANDs, as seen in any digital logic textbook. NAND could be replaced a bit less conveniently by ANDN (x & ~y), which *is* a RISC-V instruction, in the B extension. You'd have to keep -1 in a register semi-permanently (e.g. load it once in the prolog of any function that needs bitwise instructions) to get a NOT(x) operation by ANDN(-1,x). And NAND(x,y) = ANDN(-1,ANDN(x,ANDN(-1,y))).
What it also means, more practically, is that such a language will have a narrow scope - it might be suitable for object-oriented programming, but not functional programming, and so on, because that would offer too many choices and the flexibility to do stupid things that don't make sense. This leads to a lot of time and energy wasted on learning the syntax and boilerplate associated with the 'appropriate' language for the given topic, rather than the actual computer science you're there to learn. Instead of computer science, you spend a lot of time learning a handful of languages poorly, and precious little learning concepts (ie. 'programming' and not 'computer science'). In fact, you make this point yourself ('too many introductory courses to programming are introductory courses to programming in language x'),
I agree with all of that.
so I am surprised that you don't see that the alternative to this is a flexible language like Python that includes the constructs necessary for any sort of programming.
Or assembly language :-)
It would be good to have an assembler with a macro language at least capable of making pseudo-instructions and also boilerplate for assigning register names to local variables and saving callee-save registers in a function prologue (and restoring them at the end). Being able to declare structs and fields in them is helpful too.
IBM mainframes had a really good assembler. Apple copied a lot of it in the MPW assembler in the late 80s, which was capable of implementing Object-Pascal and C++ classes (and subclassing library functions) and virtual functions using macros.
You don't want to take it too far, or you've just reintroduced a lot of complexity to learn. But something a little more than EQU would be nice. Just to ease implementing reasonably complex algorithms and data structures in asm and so postpone moving to C a little.
I believe that such an education, like any other, should be guided by a teacher, who can introduce the computer science concepts in a natural progressive fashion, while providing feedback and guidance based on the students' choices.
Absolutely. Entirely self-guided learning tends to head off in bad directions.
-
https://www.youtube.com/watch?v=RfWGJS7rckk
(https://www.youtube.com/watch?v=RfWGJS7rckk)
So John Carmack weights in, and say that the best language is what you are already using.
"You just can't do a loop... reformat it to some vector operation" - this guy get's it. numpy array, list comprehension, and so on. There are so many tools provided to you to write good performing code.
And people "cobble together things that nobody on earth could do 10 years ago"
-
Judging from some opinions I've encountered, one of the leading deciders are whether the person thinks programming being the art form itself, or merely the tool to get their job done. The former typically aren't rooting hard for Python.
Another thing that would have made me rich if I got that famous penny every time I hear it, is how everyone who claims to be a programmer of any kind must know all memory, stack, heap etc. management inside out. While I don't deny that as general knowledge of your industry these would be something to ignore completely, I fail to see how literally every programmer would need to be familiar with these in order to be worth your pay. You are unlikely be writing C-style programs in Python or similar environment anyway, so I fail to see the point how it would improve your practices.
-
I fail to see how literally every programmer would need to be familiar with these in order to be worth your pay.
In order to be able to decide what is the best tool for the job.
But if your boss decides that for you, that's a different situation...
-
Judging from some opinions I've encountered, one of the leading deciders are whether the person thinks programming being the art form itself, or merely the tool to get their job done. The former typically aren't rooting hard for Python.
Another thing that would have made me rich if I got that famous penny every time I hear it, is how everyone who claims to be a programmer of any kind must know all memory, stack, heap etc. management inside out. While I don't deny that as general knowledge of your industry these would be something to ignore completely, I fail to see how literally every programmer would need to be familiar with these in order to be worth your pay. You are unlikely be writing C-style programs in Python or similar environment anyway, so I fail to see the point how it would improve your practices.
IMHO you should turn this around: does what you need to implement in software require manipulating memory / hardware at a low level? If the answer is no, then you don't need to bother at all. A problem can only exist if there is an actual problem.
What is a universally good skill to have IMHO is being able to structure a piece of software in a way that it is extendable and malleable so it can be easely modified to support future requirements.
-
IMHO you should turn this around: does what you need to implement in software require manipulating memory / hardware at a low level? If the answer is no, then you don't need to bother at all. A problem can only exist if there is an actual problem.
In order to answer that question, you need to understand how hardware, compilers and languages work.
Apparently, not many programmers have a deep insight about what happens under the hood, hence the increasing hardware requirements of "modern" software.
So, the question is, do you want to write efficient software that can be used in performance critical applications? If not, use whatever you like.
-
Just a heads-up if you're working with floating point subnormals: Someone’s Been Messing With My Subnormals! (https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html). It involves compiler options and a 10 years old gcc bug report.
-
Extending ELS Offering to
Python 2.7 for EL7/EL9
Organizations moving to get ahead of the end of support of Python 2.7 beyond EL7 by mid-2024 timelines need to extend their own product lifecycle and support. Tuxcare ELS for Python is your backport bridge provider.
https://tuxcare.com/extended-lifecycle-support/python
-
Apparently, not many programmers have a deep insight about what happens under the hood, hence the increasing hardware requirements of "modern" software.
The average most number of software devs 8) think believe aware that:
- processing power is infinity
- memory and storage are unlimited
- network latency (what is it?) is zero
-
I'm messing around with Machine Learning (for no good reason other than curiosity) and Python is the way to go. There are magnificent libraries for AI and they're all free and reasonably well documented. Yes, it's slower than molasses but it is really easy for a newcomer to experiment with Deep Neural Networks.
I don't care for the syntax but the part I really object to is not knowing the size, shape or contents of a variable. MyVar can be a string in one part of the program and an int32 a few lines later. Heck, it could become a matrix of much higher dimension and I might not even know from glancing at the code.
I'm really old; I like Fortran prior to the 2003 version that added objects. We went to the Moon with Fortran IV and that was always good enough for me. I started using Fortran IV in 1970 (it was introduced in 1962) and I'm ok with the later versions like Fortran 77 and Fortran 2000.
Fortran 90 has built-in parallel computing as part of the language. That's nice because Nvidia uses Fortran for CUDA programming. Why? Maybe because a lot of the underlying libraries originated in Fortran - like BLAS (Basic Linear Algebra System). Or, maybe because the physics world and other scientific communities still use it.
And Pascal is prettier than any other language. As a learning language, it is excellent. Particularly when coupled with the book "Algorithms + Data Structures = Programs" by Niklaus Wirth.
But Python it is! The libraries are so plentiful and competent that it just makes sense if you're not in a hurry.
-
I've got nothing against Python specifically, but if programming turns into some sort of "black box magic", this pesky brain of mine won't retain much of the knowledge.
In fact, this video sums it up pretty much perfectly:
https://youtu.be/m4-HM_sCvtQ
(I still don't know that "public static void main string args" by heart LOL)
Destiny brought me to C somehow, and while I needed a little break at some point, learning that language (for the most part) came with a largely deeper understanding of computers. So whenever some of my shitty code doesn't work, I have to dig deep enough to figure out exactly why it doesn't work.
And now I'm considering taking a 8048 uC from my junk parts and build some sort of "development" board so that I can mess with assembly a little and truly understand what the hardware does.
It's almost like I already know lean code, bare metal and low-level shit are my thing. 8)
-
Apparently, not many programmers have a deep insight about what happens under the hood, hence the increasing hardware requirements of "modern" software.
The average most number of software devs 8) think believe aware that:
- processing power is infinity
- memory and storage are unlimited
- network latency (what is it?) is zero
- all monitors have the same size & resolution
-
The average most number of software devs 8) think believe aware that:
- processing power is infinity
- memory and storage are unlimited
- network latency (what is it?) is zero
AKA The Cloud. ;D
-
Well, software development is one of the rare activities which are not told to become "frugal" these days. That's fascinating.
-
It's official. I'm depressed now that my carefully and meticulously acquired C, C++ skills are on the line.
Being close to France, I will spend my heard earned money on some whine today while I make up a plan for the future.
Some options:
-Apply for the fire brigade. Smoke is smoke and fire is fire.
-Become a priest. The bible didn't change in 2022 years. No discussion about that and brewing beer and making cheese is not that bad.
-Start to design tube amplifiers with ancient noisy resistors because they are good.
-Cleanup my workbench after 22 years of intensive use. That will take an other 22 years.
-Create polls on programming languages and ask embedded system programmers which language they use. Very unexpectedly C dug itself out of a slump and became the most popular programming language known to man.
I feel better now.
Tools are tools. Use the tool appropriate for the requirement.
-
Python is slow, inefficient, interpreted code. C/C++ skills are not on the line. Unless, of course, the lazy ignorant generation winds up making key decisions...then it's a crapshoot.
-
Python is slow, inefficient, interpreted code....
CPython compiles Python source code into byte code, and then executes the byte code in a virtual machine. Has anyone implemented the CPython virtual machine in hardware?
-
https://www.embarcadero.com/free-tools/delphivcl-python-module/free-download (https://www.embarcadero.com/free-tools/delphivcl-python-module/free-download)
https://youtu.be/NP9QKsKsSVg (https://youtu.be/NP9QKsKsSVg)
-
Python is slow, inefficient, interpreted code....
CPython compiles Python source code into byte code, and then executes the byte code in a virtual machine. Has anyone implemented the CPython virtual machine in hardware?
FPGA accelerated python could be an interesting experiment. Does anybody know if python byte code is consistent between CPython versions?
-
FPGA accelerated python could be an interesting experiment. Does anybody know if python byte code is consistent between CPython versions?
The bytecode isn't intended to be stable, and is considered an implementation detail (ie. it is part of CPython, not the Python Language). So while I'm not sure how stable it has been in practice (my guess would be 'not very'), it wouldn't be a good idea to target hardware at it as anything other than a curiosity.
-
Python 2.7 is stable. 8)
-
Python 2.7 is stable. 8)
It's as stable as Windows XP. So you're not supposed to use it. ;D
-
Python is slow, inefficient, interpreted code. C/C++ skills are not on the line. Unless, of course, the lazy ignorant generation winds up making key decisions...then it's a crapshoot.
Of course they aren't. There will still be demand for C long after Python has died. I could bet on that.
Sure there is *proportionally* less demand, but for higher-paid jobs and a lot less competition. Up to you to choose kind of a niche or to compete with potentially millions of Python "developers", a fraction of which will code for $5/hr.
-
There will still be demand for C long after Python has died. I could bet on that.
That's a big call, man. I wonder what you'd be prepared to bet. Your left ball?
-
tarfile module CVE-2007-4559:
- https://nvd.nist.gov/vuln/detail/CVE-2007-4559 (https://nvd.nist.gov/vuln/detail/CVE-2007-4559)
- https://www.trellix.com/en-us/about/newsroom/stories/threat-labs/tarfile-exploiting-the-world.html (https://www.trellix.com/en-us/about/newsroom/stories/threat-labs/tarfile-exploiting-the-world.html)
- https://github.com/python/cpython/issues/45385 (https://github.com/python/cpython/issues/45385)
Known for 15 years, but wasn't fixed.
-
It is only insecure if you run extractall() with an untrusted tar file.
It is like running eval() on a string supplied to you by a random user.
Python is powerful and lets you shoot yourself in the foot like any other language.
Just don't do it.
https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall
"Warning: Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with "/" or filenames with two dots "..". "
-
Popular != best
It's good enough for toy projects, until you need some realtime firmware writing for a Mars lander probe
-
It is funny that you should mention that. My first Python project was the firmware for a deep sea lander probe. The group I introduced Python to have since become big fans and its use is now widespread in their field.
-
And it is still not given in our highschools.
Instead they give 3 hrs a week Dutch , English and even French and German, which the last two could better be replaced with Mandarin, Hindi or Spanish if you want to learn a global language ;)
-
The group I introduced Python to have since become big fans and its use is now widespread in their field.
Are they your competitors?
[Just in case: I'm kidding ^-^]
-
The group I introduced Python to have since become big fans and its use is now widespread in their field.
Are they your competitors?
Well, on the next project, my colleagues used to tease me about my enthusiasm for Python. :) It has been a few years, so that has faded to a gentle glow.
-
It is funny that you should mention that. My first Python project was the firmware for a deep sea lander probe. The group I introduced Python to have since become big fans and its use is now widespread in their field.
You mean: the firmware was a Python interpreter than ran Python scripts that you wrote. Python is indeed popular among people who find low-level language too difficult.
-
Use your own words; don't change mine.
-
Python is indeed popular among people who find low-level language too difficult.
It's also popular among low-level language experts, who realise that micropython can be excellent tool for quickly creating devices with high-level functionality, either for test purposes or even deployment in some scenarios.
-
This thread is full of such good reasoning:
Popular does not equal best
Python is popular
So Python is not the best
Could someone tell me what is wrong with this 'supposed' syllogism?
One more
Baby Shark Dance is the most popular song on Youtube.
This song is pretty bad (?)
Then popular things are bad
Then Python is bad.
And so on ad nauseam. Doesn't anyone know how to get a syllogism right?
-
This thread isn't even about Python.
It's just a bunch of engineers (in a virtual pub) arguing over which tools are worth the effort to carry around in their (virtual) toolbox (aka brain).
Like most pub arguments there is lots of finger wagging/bad words/bullshit and in the end no conclusion. But we passed the time and had fun.
-
But we passed the time and had fun.
:popcorn:
-
1. Most popular is bad.
2. According to RedMonk (https://redmonk.com/sogrady/2022/03/28/language-rankings-1-22/) Python is not the most popular language.
Then Python is the best language ever.
:popcorn:
-
Another very good syllogism:
Popularity is independent of quality.
Python is very popular.
Then Python has bad quality.
-
Of course, my implicit reasoning doesn't work either.
Python is popular.
Popular means good quality. (?)
Then Python has good quality.
-
This thread is full of such good reasoning:
Popular does not equal best
Python is popular
So Python is not the best
Could someone tell me what is wrong with this 'supposed' syllogism?
I can tell you what's wrong. Your logic is flawed. Your conclusion is not supported by the premises. This thread is, I guess, about Python being popular. Nobody denies that. Some have pointed out that popular does not mean the best. The conclusion is something that you reached. Along with your two other flawed syllogisms.
Many people do indeed use Python. Myself included. You can't draw any further conclusions.
-
The fact that McDonald's is so popular can be studied and many conclusions can be drawn from it.
It was the beginning of a lot of fast food chains that eventually changed even the 'artisanal' form of meat production into industrial production.
It also introduced the concept of standard quality in a food establishment (not only in canned foods).
I don't claim that Python is the best language (that doesn't exist by any means) or a high quality language. But it does seem to me (and this is just my opinion) that behind this popularity there are certain points where Python is doing things right. And is managing to provide solutions to certain problems that other languages do not.
I don't know what the solution to this is. When I raised the issue I was struck by the sharp rise in popularity and I guess it is due to something (I do not think it's just a random question).
I do not assume that it is a question of quality or capacity or speed.
Sure Python has weaknesses, but I fail to see what highlighting such weaknesses over and over again adds to the debate.
One thing I am sure of: Python has not risen in popularity because of its weaknesses.
-
Quality is not in the language, it is in the programmer who uses it.
Even when the language is somewhat flawed a good programmer can make it work, by knowing the flaws and work around them.
When to use a certain language depends on your needs for certain aspects of a language or the environment you are working in. When developing interactive websites the logical choices are php or asp combined with html, css and javascript.
For an embedded real time system C/C++ is the logical choice for most.
Python has its use in all sorts of fields, just like all the other languages out there, but as with everything else it is as good as the weakest link. A bad programmer, will create bad code, no matter which language is used.
-
The fact that McDonald's is so popular can be studied and many conclusions can be drawn from it.
No conclusions can be drawn from McDonald's being popular. You have to introduce more information to draw any conclusions. That is the "study" part. I think you need to work on your syllogisms.
-
Another interesting issue is how interpreted languages have risen enormously over compiled languages in the last decades.
I also think this has some logic underneath it. And Python gets swept up in this general trend favoring interpreted languages.
-
Quality is not in the language, it is in the programmer who uses it.
Even when the language is somewhat flawed a good programmer can make it work, by knowing the flaws and work around them.
When to use a certain language depends on your needs for certain aspects of a language or the environment you are working in. When developing interactive websites the logical choices are php or asp combined with html, css and javascript.
For an embedded real time system C/C++ is the logical choice for most.
Python has its use in all sorts of fields, just like all the other languages out there, but as with everything else it is as good as the weakest link. A bad programmer, will create bad code, no matter which language is used.
But there are languages that favor good programming. Linus Torvalds has commented on occasions that he does not want C++ programmers in the Linux kernel at all because of the problems this could create in bad programming.
https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-a-terrible-language-2248b839bee3 (https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-a-terrible-language-2248b839bee3)
And now a step is being taken to make Rust one of the kernel languages precisely because it encourages safer programming.
https://www.theregister.com/2022/06/23/linus_torvalds_rust_linux_kernel/ (https://www.theregister.com/2022/06/23/linus_torvalds_rust_linux_kernel/)
-
Python has its use in all sorts of fields, just like all the other languages out there, but as with everything else it is as good as the weakest link. A bad programmer, will create bad code, no matter which language is used.
But still, with Python it is the interpreter that halts in case of a problem. A poorly written C program will happily continue with a bad pointer. The latter is why I favour C++; you can largely avoid using pointers.
-
Another interesting issue is how interpreted languages have risen enormously over compiled languages in the last decades.
I also think this has some logic underneath it. And Python gets swept up in this general trend favoring interpreted languages.
There is a certain trend toward JIT ( just in time ) and now AOT ( ahead of time ) runtimes. The demands of cross platform and cross OS development means the code behind is often just built to an intermediate language ( IL ) with some bloated API to connect the ten lines of 'hello world' text to the target OS. Python is no exception to this trend. C# and Java are now cross platform framework heaven, and hell. The only issue for the developer is keeping up with the latest framework - are you and expert in QPython, PyCharm or Jetbrains yet? Once a new framework is announced, all bets are off just how long the existing codebase can remain supported. Everyone else wants to race at full speed into the future, which is probably why Github is such a code graveyard.
-
But still, with Python it is the interpreter that halts in case of a problem.
Isn't there some way for the interpreter to raise a fault instead? Last thing you want on embedded kit is a console prompt waiting for input.
And.. does the interpreter pre-interpret your code to make sure it's all actual code? At least with a compiler, you might program a hyperspace jump but it will be an actual valid jump when the code runs :)
-
What Arduino did for hardware Python Did for languages :scared:
The illusion that everything is easy, just using other people's codes/libraries, without knowing precisely what's behind the scene.
-
Arduino was designed to make it easy for non-technical people to use a prototyping board.
But Python is used in many applications by technical people who are well versed in different programming languages. It is a professional tool.
-
Arduino was designed to make it easy for non-technical people to use a prototyping board.
Python was designed to make it easy for non-programmers to use a programming language.
:popcorn:
-
Python is designed to optimize programming time instead of optimizing execution time. To achieve that, the language has been made to be simple, easy to learn and easy to use. But that does not mean that it is oriented only to neophytes (as is Arduino).
https://blog.dropbox.com/topics/work-culture/-the-mind-at-work--guido-van-rossum-on-how-python-makes-thinking
-
Twenty some years ago, the idea was Python fits your brain (https://www.linuxjournal.com/article/4731).
-
Use your own words; don't change mine.
You actually reported my post and managed to have it removed? I didn't think the eevblog was that lame :-DD
-
I didn't think the eevblog was that lame :-DD
"fixed that for you", "lame" ... it seems to me you'd be more comfortable at Twatter, Snipthat, Fakebook, Inthatgran, Tiptap, or other like-minded social media, then.
A quick "Apologies; won't happen again, MikeK." would have been the proper answer here. We all make mistakes, but only some seem to be able to be human enough to admit and apologise.
-
Come on now. You obviously read it, since you can quote it. It was an exceptionally mild poke of fun at his rather condescending tone against those "not competent enough persons to reach the excellence of low level programmer". I really thought this crowd could handle that...
-
It was an exceptionally mild poke of fun
Indeed, it was pretty tame, but I am sure the problem was that you chose to make the joke by changing his quote. That's a big no-no under any circumstance because someone not au fait with the original would think that he really wrote that.
-
Come on now. You obviously read it, since you can quote it. It was an exceptionally mild poke of fun at his rather condescending tone against those "not competent enough persons to reach the excellence of low level programmer". I really thought this crowd could handle that...
Is it really that hard for you to admit you've made a mistake? According to your posting history, it is.
Being unwilling or unable to admit your own mistakes is one of the most despicable human behaviours I know of. Condescending tone is a mild irritant in comparison.
-
I'll stand by my opinion in this case. I'm always equally willing to argue my point as accepting when I'm wrong. This however is a matter of opinion, without a right/wrong answer.
He got excessively hurt in the b from me turning his words against him, ratted off to mommy to cover it up, who had it removed on a technicality. It was more than obvious that and which parts of his quote that was changed by me. I haven't read the fine print, but if there happens to be an explicit rule against that, so be it. I accept, not respect, the decision by the moderators to remove the post. That's all that's in my power, which I fully accept. With that said my general experience of forums is that the ones more open and allowing are more lively and fun to hang around. I had (mistakenly?) got the image that the eevblog was one of those.
If you've already got the impression that I'm a prick. I'll leave this matter on that note confirming the image.
-
I would actually like to apologize in advance, if, in fact, it wasn't him who reported the post. That was a somewhat rash assumption by me. In which case I was actual technical wrong.
-
If you've already got the impression that I'm a prick. I'll leave this matter on that note confirming the image.
My impressions are irrelevant; all that matters is how you interact with others.
I may be too touchy about the behaviour you seemed to exhibit, because it has been a big part of why I've left many Q&A sites. There, many of those who have "high score" ("reputation") ignore any errors they made as long as it does not impact their "reputation"; and when it does, they simply delete the answer.
The reason this is utterly despicable to me is how often it ends up misleading those looking for help. It is an understandable human error, but when those trying to learn are involved, it is a very serious problem that undermines everyone elses good-faith efforts, muddying everything into a mess.
The thing I keep repeating here and elsewhere, is that ones opinions do not matter, but the things – facts, observations, thoughts, and even beliefs – behind those opinions are interesting, because unlike opinions, they can be evaluated for relevance and applicability to the situation, problem, or question at hand.
In this thread, I've been on both sides. I do use Python, especially when implementing UIs (Python3 + Qt5, currently), because it gives me a perfect demarcation line between things that all end-users, even nontechnical users, should feel free to play with and modify (this being the UI), while putting any actually important secret sauce in a binary dynamic library. I myself am more of a systems programmer, with C being my currently preferred language, but I can develop software in about a dozen languages, and have done some embedded development too (including freestanding C/C++).
So, I'm not your opponent, just another member here who wants to point out some things that you should find useful.
I could say I will not form any kind of impression of you until I see how this pans out, really, because everyone makes errors, and what matters is how they behave when one is pointed out to them.
Your earlier posts, like #850, were on point, but the post where you tried to be funny and modified what MikeK wrote fell flat. Sometimes it works, sometimes it doesn't. I've done it myself, I believe, although I do think only to agree/emphasize, not to invert like you did; the inversion is easy to perceive as quite hostile. When things fall flat, the correct –– as in works with humans, not as in "politically correct" –– response is "oops, that fell flat. Sorry, I was trying to be funny" or something to that effect, not to try and paint the target as someone who "ratted off to mommy".
This is the core of my point to you. It is just that one of my own flaws is excessive verbosity. (It is not an affectation; I'm working to cut the excesses down.)
Basically, I'm saying you're digging yourself deeper into a hole for no sensible reason. Or just to shield your own emotions or mental picture of yourself (as in, "what I wrote was funny, you guys are just ganging up on me because you've no sense of humor"). I'm not ragging on you here, I am telling you what every one of us does, unless we train ourselves or consciously do otherwise; and we must, if we want to interact effectively, without censoring ourselves like we were walking on eggshells all the time. We are social animals, after all. Remember, your facial expressions or other cues are not transmitted in written text, so it is unreasonable to assume others will read what you write the same way. When that happens, you correct the error, and move on.
-
Had to write a custom BOM plugin for KiCad in Python lately. No choice, Python is the only option for KiCad plugins.
I didn't particularly enjoy that, but I made it. :-DD
-
Hope you wore gloves and brushed your teeth afterwards.
-
I've done it myself, I believe, although I do think only to agree/emphasize
This something I do on occasions, too.
But, as above, it is important to me that any alteration in a quote is marked as such, and the forum SW here allows that:
[quote author=Nominal Animal, emphasis by newbrain...
-
The way I use Python is to simply call library functions in the proper order. I have been playing with Deep Learning and there is darn little programming required. All of the functionality is provided by libraries that are, more often than not, written in C/C++ for speed. I don't care how the libraries are written, I just want to know the calling parameters and the results for the myriad functions.
Here is a sample that has not a single 'if' statement - it's just a long list of function calls. It is the classic 'Digit Recognition' script for the real 'Hello World' of Deep Learning.
from tensorflow import keras
from tensorflow.keras import layers
from tensorflow.keras.datasets import mnist
(train_images, train_labels),(test_images,test_labels) = mnist.load_data()
model = keras.Sequential([layers.Dense(512,activation = "relu"),
layers.Dense(10, activation="softmax")
])
model.compile(optimizer="rmsprop",
loss ="sparse_categorical_crossentropy",
metrics =["accuracy"])
train_images = train_images.reshape((60000, 28*28))
train_images = train_images.astype("float32") / 255
test_images = test_images.reshape((10000,28*28))
test_images = test_images.astype ("float32") / 255
model.fit(train_images, train_labels, epochs = 5, batch_size = 128)
print("\nRunning test data\n")
test_loss, test_acc = model.evaluate(test_images, test_labels)
print("\n")
FWIW, this simple model achieves 98% accuracy using the MNIST hand written digits dataset - about average. Some of the samples are so badly formed that even a human is going to have a problem with recognition. Just look at some of the '4's and '9's or that dead-bug 8.
https://towardsdatascience.com/going-beyond-99-mnist-handwritten-digits-recognition-cfff96337392
I get about 99% accuracy with the MATLAB approach. Pretty good results.
Here's the point: There is not a single conditional branch in the entire script. It executes top to bottom in strict order. No decision logic at all. Second, there are a lot of Python users doing just this type of thing. Making function calls to libraries written in C by the actual wizards of coding.
Python may be popular because of the libraries. There are many high quality libraries that allow a Data Analytics researcher to do work without all the pain of coding gradient descent on an N dimensional space for very large values of N. It may also be pretty simple to force the execution to use the GPU when available and this speeds thing up quite a bit. My MATLAB digit recognition program runs in 13 seconds on a CPU and 5 seconds on a GPU. Now scale the problem up to weeks instead of seconds. And I didn't have to write the library! And, yes, weeks of run-time for training isn't unusual. I have read where the Tesla self-driving AI takes 70,000 GPU hours to train. Fortunately, GPUs are cheap at that scale - what's a few million $ for a server farm?
https://developer.nvidia.com/how-to-cuda-python
I think Python is a pretty good language when used in its own niche sandbox. It will never replace Fortran, of course, but other languages have also tried and failed.
BTW, there's a reason that Nvidia provides a Fortran CUDA compiler. It has to do with the fact that parallel computing is built into the language. They also provide a C++ compiler...
-
Python is also popular in areas where Fortran was traditionally used (intensive computing).
https://conference.scipy.org/proceedings/scipy2021/pdfs/rollin_thomas.pdf
"""Abstract—In 2021, more than 30% of users at the National Energy Research
Scientific Computing Center (NERSC) used Python on the Cori supercomputer. ..."""
The idea is similar to what you have mentioned. Generalist computationally intensive libraries are programmed in C or Fortran, which are very fast from the machine's point of view.
From there, all the software binding and high-level handling of the libraries is done in Python, a very fast language from the programmer's point of view.
In any case, in other areas all software is written in Python. For example in what I use Python (web development) both the template system (Jinja2) and the offline web code generator (Sphinx) are completely programmed in Python.
There are also frameworks like Flask or Django to generate dynamic webs, written entirely in Python.
Like this very forum in which we are writing right now, which is programmed entirely in another interpreted language (PHP).
-
A few years ago I programmed from scratch a static web page generator, based on hundreds of images spread over dozens of directories and some small data files next to each set of pictures to describe them. The program automatically generates the web pages, the link structure between pages, the indexes, etc.
All written in Python. I'm not a professional programmer, so the code is not a marvel, but I'm proud to have made such a program. In another compiled or mid-level language, such as C, it would have been impossible for me. I owe it to Python to come up with it.
On the other hand, the compilation of the modifications takes only a few seconds and most of it consists of transforming the photos to formats with less weight and watermark. No one has complained about the speed of the program.
-
In another compiled or mid-level language, such as C, it would have been impossible for me.
I can appreciate that different languages can be easier (or harder) to use for differing purposes. Python sounds like it's much better for generating web pages that C. But why does the compiled vs interpreted thing matter? OK, with a compiled one you have to hit compile, but with an interpreted one you have to actually get the code run to find out if it's code, so really there's not much trade-off either way.
I am thinking the compiled vs interpreted arguments are thrown in simply because C is compiled and Python is not. If the reverse was so - C interpreted and Python compiled - would that make a difference? I suspect that many would say it does make a difference, but really it shouldn't.
-
I am thinking the compiled vs interpreted arguments are thrown in simply because C is compiled and Python is not. If the reverse was so - C interpreted and Python compiled - would that make a difference? I suspect that many would say it does make a difference, but really it shouldn't.
BASIC was an interpreted language and very popular in the early '80s when it was the only game in town on the just invented 'hobby' computers (predates 'personal' computers). It was BASIC or assembly language - those were the only choices for a while. Eventually, when computer speeds got out of single digits and memory got into the MB range, other languages started to appear.
Most programs run so fast on modern hardware they could as well be etched in stone. It simply doesn't matter. This is NOT true for computationally intense programs where even GPUs are a bottleneck. It turns out that moving large data blocks into and out of GPU memory is still a bottleneck even with 4000 MHz memory. More GPU memory is a big deal - multiple gigabytes (like 10 or 12 GB) is the way to go. Don't move the data any more often than absolutely necessary.
Python isn't interpreted in the same way early versions of BASIC were interpreted (parsing statements from source every time). Python does compile the source to bytecode and this is a pretty fast intermediate form. But it also explains the lag time between <Return> and any useable output. This is particularly noticeable for programs that use a lot of imported libraries.
Maybe playing around with the various timing functions would be interesting. I would be interested in the time around the import statements.
-
Here is a very small C interpreter, C99 compatible, that runs at full speed (although it does not optimize the generated code).
Tiny C Compiler: https://bellard.org/tcc/
https://en.wikipedia.org/wiki/Tiny_C_Compiler
It is able to compile and execute in memory, in a few seconds, a linux kernel.
Booting Linux kernel: https://bellard.org/tcc/tccboot.html
Edit:
Tiny C Compiler in Python https://pypi.org/project/tinycc/
-
But why does the compiled vs interpreted thing matter?
To recompile modified sources, you need a full development environment. In practice, this is nontrivial, especially when libraries and tool version dependencies are involved. Even the compilation process itself can be nontrivial. To modify interpreted human-readable code (as opposed to compiled bytecode), you only need a text editor to modify the code, nothing else.
Also, runtime dependencies are completely different to build-time dependencies. A typical example is code generation, for example flex/bison workflow, used to create parsers and lexers (for implementing new programming languages) in C. This means that even though you can run a specific compiled application, does not mean you can compile the same application in that same environment: lots of additional software is needed.
I find it extremely odd that you think the difference should not matter. To me, asserting that the two should be equivalent, is like asserting that automobiles with internal combustion engines are equivalent to bicycles: after all, both have wheels and move people from place to place, so they provide the same functionality... Of course they do not, when you really investigate the practical details.
I do suspect the difference is something one does not realize before having to build lots of software developed by others.
-
runs at full speed (although it does not optimize the generated code)
That is as useful as a recursive-only Fibonacci calculator. It, too, runs at full speed; it's just that the results aren't that useful in practice, because there are much better options around.
Compilers are not slow because they are badly written. They are slow, because they try to optimize the generated code. The optimizations are done at the algorithmic level –– at the abstract syntax tree level –– and can usually be mathematically proven to adhere to the abstract machine model used in the C standard. You could say that the fact that the current compilers really do this, is one of the most important features they provide, because if they didn't, we'd be using something that would, instead.
What do you think that Python project proves? In my opinion, nothing. I can write the same in Bash (and others probably have already), but it does not really say anything useful about Bash either. It is just a funny demonstration.
What matters, is which tasks is Python well suited for.
It seems to me you are quite desperately trying to prove that anything worth doing is possible to do in Python, with the proof being that so many humans are using it. I disagree. A single man can build a castle out of volcanic rock in a single lifetime, too, but that does not mean that it is a sensible way to build castles. Not even if you had tens of thousands of people cheering and egging him on, making it a very popular way of building castles. Nor even if there were tens of thousands of people, each one building their own castles out of volcanic rock. My proof is that with proper tools and workforce, a castle can be built in a couple of years, and from much better materials.
Again, I do use Python, and quite happily. Unlike SiliconWizard, I don't mind writing plug-ins (for GDB or Inkscape) in Python; Python seems to suit such tasks quite adequately in my opinion. Python definitely has its faults and its quirks, and actually has quite narrow niches where it is particularly useful. It is designed to be easy to write and understand, but it is quite far abstracted from the actual hardware –– so much so that current interpreters cannot run more than one thread of Python code at a time in a single process, which is a serious limitation for anything even close to systems programming. Pluses and minuses.
-
But why does the compiled vs interpreted thing matter?
To recompile modified sources, you need a full development environment.
Hmmm. I think my idea was either not expressed usefully or it failed to be noticed (which probably comes to the same).
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. You can get C interpreters and you can compile Python applications if you really want.
My point was trying to be that C doesn't have great string handling features, for example. Python has high-level features that make a lot of stuff trivial that would be a pain with C, but C is like a sharp knife compared to Python's blunt axe if you want to do (MCU) surgery. Those are the sort of features - the vocabulary - I would choose a language for, not whether it takes 3 secs more to compile or download.
[And it seems to me that when 'compiler' is mentioned, out come the "takes forever to compile" stuff. Even really very big and complex applications typically only take the longest time when setting up - ever after that you're just compiling the bits that have changed, which can often be completed before the return key has stopped bouncing.]
So, are we really saying that the language's lexical features aren't actually very important, and what everyone is liking is the ability to type into a live system and watch run or crash as they're doing that?
-
runs at full speed (although it does not optimize the generated code)
That is as useful as a recursive-only Fibonacci calculator. It, too, runs at full speed; it's just that the results aren't that useful in practice, because there are much better options around.
I find it useful to have a C interpreter that can quickly execute a script when what matters (again) is the speed of the programmer.
Once the program is developed, you can compile it with GCC to have the executable already compiled and faster. But during development, a compiler that compiles the whole project 10 to 15 times faster and runs in memory (without producing an executable file) can be an advantage.
For example to develop code that will later be ported to a microcontroller. The development phase will be much faster with a C interpreter like TCC.
I only intend to highlight the advantages of interpreted code over compiled code. And I don't care if others don't find advantages in Python. I do easily find the advantages of Python and that's why I use it where I think it will do well, which is not to build castles.
In other cases I have used C or JavaScript, where Python didn't make sense.
-
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. You can get C interpreters and you can compile Python applications if you really want.
Unfortunately, Python code cannot be compiled. I wish it could be done, even at the cost of removing capabilities from the language. But today it can only be interpreted.
-
One thing that saddens me is that many (I didn't say all) people who use Python almost refuse to consider alternatives. That's pretty sad (and unreasonable.)
"Monopoles" are never a good thing and they never end up well.
-
That's because Python is a religion :)
Seriously, I don't think there are any Python-only programmers. There may be C-only programmers, but Python-only programmers, impossible.
-
Hmmm. I think my idea was either not expressed usefully or it failed to be noticed (which probably comes to the same).
The latter is always possible with me, because me fail English often; I miss subtext and cues.
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. [...] So, are we really saying that the language's lexical features aren't actually very important, and what everyone is liking is the ability to type into a live system and watch run or crash as they're doing that?
No, we (I believe!) are saying that a small detail in one context can be a big factor in another context. That is, that there isn't one set of weights that would apply generally, that one could use to calculate a single qualitative scalar for describing the usefulness of a programming language.
Or, put another way, that the uses of programming languages vary so wildly, that there physically cannot be a single programming language that fits them all.
A better question would be, when does the interpretability/scriptability of a language override its lexical/library features, or vice versa?
(I have my own answer, already outlined in my posts where I describe how and when I use Python and why, but it definitely isn't "universal". It would be interesting to me to hear when others find themselves crossing that line. I expect use cases where domain-specific languages were traditionally used, would be quite informative.)
As to C standard library, I find it quite deficient, and instead prefer POSIX C (which basically all operating systems' standard C libraries implement, except for Windows). I've also started a couple of threads here talking about replacements for the standard C library, as it is not an intrinsic part of the language: the standard specify the freestanding environment, where the standard library is not available. Indeed, freestanding C/C++ is, I believe, the most common choice for software development on microcontrollers.
I find it useful to have a C interpreter that can quickly execute a script when what matters (again) is the speed of the programmer.
Okay, that would be an valid use case. I stand corrected.
The reason I didn't think of that, is that the way I develop my own projects, means that I don't actually ever need to wait for the compiler. Key algorithms and verification suites –– like the Xorshift64* with Marsaglia polar method PRNG I wrote yesterday elsewhere (https://forum.pjrc.com/threads/71225-Gaussian-Distributed-Random-Numbers-for-Teensy-4-1?p=313878#post313878), to generate normally distributed pseudorandom floats on Cortex-M7 –– I first implement in separate programs to test and verify their operation, before including in the larger project. For larger projects (and even smaller ones), I use Make extensively, so only the recently modified sources are recompiled and then the project linked, and even on this five-year-old HP EliteBook 840 G4 laptop with an Intel Core i5-7200U processor, I never need to wait. I would not save any time even if the compiler was faster.
For larger projects, like the Linux kernel, I run the build on the background (nice'd and ionice'd) while I check the Changelog, documentation, et cetera. Even there, the compilation itself isn't necessarily the slowest part of the build; there are lots of dependency tracking and such, which is why you'll see massive improvement in build speed if you have more RAM (because Linux uses otherwise unused RAM as a cache, which speeds up random access times). Of course, now with fast SSD drives, the difference has diminished quite a bit –– but not completely, because Linux is one of those projects with LOTS of small files accessed during the build, so it's more about I/O requests per second than about raw data bandwidth. Caching still helps.
I only intend to highlight the advantages of interpreted code over compiled code.
I've described how I do that too. I'm not trying to counter anyone here; I too am just trying to help concentrate on the useful and practical aspects of this discussion, and not let it devolve into an opinion shootout.
-
Unfortunately, Python code cannot be compiled. I wish it could be done, even at the cost of removing capabilities from the language. But today it can only be interpreted.
With Cython (https://cython.org/) + any old C compiler you can do exactly that.
The difference between 'compiled' and 'interpreted' is generally more about the toolchain/implementation than the language itself. It's hard to imagine a language that could be interpreted but not compiled, unless you write implementation details into the language spec. The lines get very blurry when you're talking about tools/runtimes that use an intermediate bytecode (like CPython) or a JIT (like PyPy). Java is traditionally considered a 'compiled' language, but its has an intermediate representation not unlike CPython's - it doesn't compile directly to native code - the tools just require you to compile it ahead of time with Java but do it at runtime (and cache it) in CPython. In fact, there are Python implementations that compile to other intermediate languages and use their runtimes, like Jython (Java) or IronPython (.NET CLR).
One thing that saddens me is that many (I didn't say all) people who use Python almost refuse to consider alternatives. That's pretty sad (and unreasonable.)
"Monopoles" are never a good thing and they never end up well.
I think this is as true of Python as it is of any other language. Perhaps Python's flexibility lends to this being a more viable position than with many other languages, but it is human nature to continue using a tool you know rather than invest the effort into one that might or might not suit you better.
Seriously, I don't think there are any Python-only programmers. There may be C-only programmers, but Python-only programmers, impossible.
Eh, I'd actually say the opposite is more likely. Like there are embedded programmers that started with Arduino and never moved past it, the same will be true of Python. It's flexible and 'good enough' that it can solve pretty much any normal programming problem in a reasonable way, so why learn something else? Whereas if you know C, you probably invested a lot of time into it, and along the way likely learned at least one other language.
-
One thing that saddens me is that many (I didn't say all) people who use Python almost refuse to consider alternatives. That's pretty sad (and unreasonable.)
"Monopoles" are never a good thing and they never end up well.
Isn't that universal, though? I mean, we are all surely familiar with the single-tool-fits-all-my-needs people, in all aspects of life. Python is no exception and no different to any other programming language, or even any other tool, really.
The fact that this is so common, does make me sad too, though. The older I get, the lesser my overall opinion of humanity becomes, and the more I value individuals who try to make a difference around themselves, in the small things, by helping others.
-
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. You can get C interpreters and you can compile Python applications if you really want.
Unfortunately, Python code cannot be compiled. I wish it could be done, even at the cost of removing capabilities from the language. But today it can only be interpreted.
py_compile?
But what I mean but 'compile' is really 'single standalone executable', and there are utils that will do that.
-
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. You can get C interpreters and you can compile Python applications if you really want.
Unfortunately, Python code cannot be compiled. I wish it could be done, even at the cost of removing capabilities from the language. But today it can only be interpreted.
py_compile?
But what I mean but 'compile' is really 'single standalone executable', and there are utils that will do that.
Only to a certain extend. You'll still need to figure out a way to pull all the system libraries in that the Python modules depend upon. Deploying a single binary that depends on a few libraries so it runs on various OS versions/flavours isn't easy. Deploying a lot of binaries that depends on even more libraries is very hard.
-
That's not far different from getting a compiled app to run somewhere else. You either include everything needed or have the user install 'common libraries' which, in the case of an interpreter, is the full stack.
-
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. You can get C interpreters and you can compile Python applications if you really want.
Unfortunately, Python code cannot be compiled. I wish it could be done, even at the cost of removing capabilities from the language. But today it can only be interpreted.
py_compile?
But what I mean but 'compile' is really 'single standalone executable', and there are utils that will do that.
Only to a certain extend. You'll still need to figure out a way to pull all the system libraries in that the Python modules depend upon. Deploying a single binary that depends on a few libraries so it runs on various OS versions/flavours isn't easy. Deploying a lot of binaries that depends on even more libraries is very hard.
Not to run on different operating systems but for linux this exists. https://appimage.org/ (https://appimage.org/)
-
What I mean when I say that Python cannot be compiled is that it cannot be converted into a static machine language. Although a Python application can be packaged into a single executable, it will contain the Python interpreter that will be dedicated to interpreting the intermediate object code generated earlier.
The final appearance is that of a compiled executable, but the interpretation is still done. Proof of this is that you can internally generate new Python code or enter new code in a keyboard entry and run it with the "compiled" application, which will be interpreting the new code.
Edit:
One consequence of this is that "compiled" Python code is not much faster. Variables can keep changing type during program execution, so the program has to check the type of each variable before using it. It is still just as slow as interpreted code.
-
What I mean when I say that Python cannot be compiled is that it cannot be converted into a static machine language. Although a Python application can be packaged into a single executable, it will contain the Python interpreter that will be dedicated to interpreting the intermediate object code generated earlier.
The final appearance is that of a compiled executable, but the interpretation is still done. Proof of this is that you can internally generate new Python code or enter new code in a keyboard entry and run it with the "compiled" application, which will be interpreting the new code.
Edit:
One consequence of this is that "compiled" Python code is not much faster. Variables can keep changing type during program execution, so the program has to check the type of each variable before using it. It is still just as slow as interpreted code.
While all that you say is true, JavaScript has exactly the same characteristics, and yet using JIT techniques it runs faster than unoptimised C and very close to optimised C.
It does of course have to carry the interpreter/JIT along with it.
-
It is true that Python could have a better performance in execution speed and that has been remarked many times here. In fact, improving its speed is a topic that is being worked on today.
But what I have commented on several occasions and I do not know if it has been well understood is that Python has a lot of performance from the programmer's point of view because:
1. you can do things with Python that you wouldn't know how to do or want to do with other languages.
2. With Python it takes little effort to make programs that would not be feasible in C or other languages because of their complexity.
3. Python is more maintainable than other languages because it helps create code that is easy to read. In the long run we spend more time maintaining and improving existing programs than programming new ones.
Therefore Python is a very good choice in cases where what matters is programming time, not execution time (which is becoming less and less important in many areas).
-
Execution time and power efficiency are becoming more and more important because of the power consumption and CO2 footprint. Might change some day when we'll have fusion power plants, but not for the foreseeable future.
-
You are right. So am I.
No matter how much of a carbon footprint it has, don't expect websites written in PHP to be rewritten in C.
Wordpress (written in PHP) dominates CMS. But it's not the only one out there. SMF and phpBB in forums, Matomo in Analytics, etc.
Alternatives? Perhaps Python, Ruby, JavaScript, all of them interpreted, not compiled and therefore with a larger carbon footprint. That's the way it is.
-
I once read that Python had failed to be used for Android apps precisely because it was slower than Java. In smartphones, saving energy is important, but anyway a compiled language (Java), not C, is used to program the Apps.
https://stackoverflow.com/questions/3560963/why-does-android-use-java
-
I am aware that there is big difference in getting compiled and interpreted stuff going, but surely that isn't what makes a language. You can get C interpreters and you can compile Python applications if you really want.
Unfortunately, Python code cannot be compiled. I wish it could be done, even at the cost of removing capabilities from the language. But today it can only be interpreted.
py_compile?
But what I mean but 'compile' is really 'single standalone executable', and there are utils that will do that.
Only to a certain extend. You'll still need to figure out a way to pull all the system libraries in that the Python modules depend upon. Deploying a single binary that depends on a few libraries so it runs on various OS versions/flavours isn't easy. Deploying a lot of binaries that depends on even more libraries is very hard.
Not to run on different operating systems but for linux this exists. https://appimage.org/ (https://appimage.org/)
I remain sceptical until I see it actually work 8) but this looks like an interesting solution I'm going to look into when I revisit the Python project that has hit a dead-end due to lack of distributability. The alternative is rewriting it in C++.
-
I remain sceptical until I see it actually work 8) but this looks like an interesting solution I'm going to look into when I revisit the Python project that has hit a dead-end due to lack of distributability. The alternative is rewriting it in C++.
Don't think it is written in python but saleae use it for their software. Works like a charm. Just the one file that you can execute. https://www.saleae.com/downloads/ (https://www.saleae.com/downloads/)
-
I got a message for wannabe programmers:
When children who wanna become mathematicians grow up, they leave behind their 10 times table and work on REALLY, REALLY difficult and complex problems.
Programming IS hard, because you're solving very difficult problems. You want the (imho mis-attributed) title of "software engineer", but ya don't want to put in the hard graft of learning what is ACTUALLY underneath all those layers? When you learn the low down stuff, you become a better programmer as you mentally visualise what's happening at the bare metal. I'm not saying you have to learn ASM, I mean it wouldn't hurt you, but at the LEAST become semi-proficient at C, even if you don't use it in daily work. Write some code then examine the ASM the C compiler spits out for you; you'll learn about stacks and pointers and registers.
Real engineers learn ohm's law, how transistors work etc, they don't plug together arduinos and say "Ehhhh, good enough; I'm an engineer now" - software is no different. Python is a toy, you can learn it once you've learnt the hard stuff.
People want all the praise without the work. Do something EXTREMELY HARD and work it out for yourself, you'll have a fundamental understanding of the bits and bytes and then you can build on that foundation. Drag and Drop IS NOT programming.
(https://media-exp1.licdn.com/dms/image/C4D12AQHonUN2x5WUJg/article-cover_image-shrink_600_2000/0/1618930907525?e=2147483647&v=beta&t=ZIgF_roC7IEl1OV2CoeQ2Z029RDKBt-VMDC30K8y3U4)
-
Pyratemp: http://www.simple-is-better.org/template/pyratemp.html (http://www.simple-is-better.org/template/pyratemp.html)
Pyratemp is a very simple, easy to use, small, fast, powerful, modular, extensible, well documented and pythonic template-engine for Python.
Simple? only a Toy? :-DD
1230 lines of code. One complete template languaje interpreter.
-
When I need to run certain things in Ubuntu, which depend on Python, I almost ALWAYS come across daft problems like needing 2.7 vs 3.X, having to search stack overflow etc for myriad, conflicting "solutions", and there being multiple conflicts etc. It's not the best first impression. :palm:
-
One thing that saddens me is that many (I didn't say all) people who use Python almost refuse to consider alternatives. That's pretty sad (and unreasonable.)
"Monopoles" are never a good thing and they never end up well.
Isn't that universal, though? I mean, we are all surely familiar with the single-tool-fits-all-my-needs people, in all aspects of life. Python is no exception and no different to any other programming language, or even any other tool, really.
Not really. It is universal for anything that has been considered a 'silver bullet', and those never last. They are just passing fads.
Just look at C. While it's still hugely popular if you consider its age, it is now restricted to niches (embedded software, maintenance of existing Linux/BSD/.. software, Linux kernel...) No one is currently trying to push it to be used universally for all purposes. Same for all other currently used programming languages. If that was once the case, the fad has passed.
So the same will happen with Python. But currently, its proponents are eagerly trying to push it to almost anything conceivable, going out of their way to try and find new applications for it at all costs. That's not sane and it will definitely not last - it never has in the past. If it does last, then we are in a seriously troubled period IMO. (Which uh, we are indeed, though.)
The fact that this is so common, does make me sad too, though. The older I get, the lesser my overall opinion of humanity becomes, and the more I value individuals who try to make a difference around themselves, in the small things, by helping others.
Yeah. And to restrict things to the thread, I also try at my humble level to use (and show to those potentially interested) a variety of tools and languages that are sometimes underrated and worth a look. This promotes some variety and healthy "competition" and expands your horizons. I again don't think that obsessively focusing on just one thing is sane, and that currently troubles me with Python, but of course not just that. Purely my opinion here.
-
It seems that the first 4 languages are taking the upper hand and leaving less and less room for the others.
"""
TIOBE Index for October 2022
October Headline: The big 4 languages keep increasing their dominance
Python, Java, C, and C++ are the top 4 languages of the TIOBE index for quite some time now. They are far ahead of the rest, and the gap seems to be only growing. Last year, these 4 languages had a 40% market share, this year the share is even 55%. This is an indication that there is not much room for competition at the moment. Java's main competitor C# is losing ground, whereas Python competitors R and Ruby are more or less stabilizing. However, for C and C++ there is one small threat arising on the horizon: the programming language Rust. Rust re-entered the top 20 again with an all time high market share of 0.70%. Rust focuses on performance and type safety. One of the reasons for Rust's increasing popularity is that Google started programming low level parts of Android in the Rust language. -- Paul Jansen CEO TIOBE Software
"""
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
(Of course, speaking of popularity, which may not mean anything).
-
It seems that they are working on solving one of the problems that "worry" so much about Python, its slow speed:
https://docs.python.org/3.11/whatsnew/3.11.html#whatsnew311-faster-cpython
"""
Faster CPython
CPython 3.11 is on average 25% faster than CPython 3.10 when measured with the pyperformance benchmark suite, and compiled with GCC on Ubuntu Linux. Depending on your workload, the speedup could be up to 10-60% faster.
This project focuses on two major areas in Python: faster startup and faster runtime. Other optimizations not under this project are listed in Optimizations.
"""
-
It seems that they are working on solving one of the problems that "worry" so much about Python, its slow speed....
One way the Python developers are doing that is by no longer supporting direct but infrequently used possibilities. For example, the documentation for exec() added that it may only be given a plain (not subclassed) globals dictionary. It appears I am partly and indirectly responsible for the restriction. :(
-
It appears I am partly and indirectly responsible for the restriction. :(
What did you do? :D
That said, I do like how one can easily restrict the interfaces available (including restricting which built-in functions are available) for evaluating user inputs by supplying carefully constructed globals and locals dictionaries to eval() (https://docs.python.org/3/library/functions.html#eval): it can be made quite robust and yet still effective, especially for stuff like allowing (numeric) expressions in (number) input fields in user interfaces.
I don't see any real downsides in my use cases for having to use a dict() instance instead of ones own subclass, so the restriction doesn't affect my use cases, but that's of course no indicator that such use cases do not exist.
Did you have one (with a dict-derived subclass), or was it due to discussions with the developers? (I'm just being nosy.)
-
So the same will happen with Python. But currently, its proponents are eagerly trying to push it to almost anything conceivable, going out of their way to try and find new applications for it at all costs. That's not sane and it will definitely not last - it never has in the past. If it does last, then we are in a seriously troubled period IMO. (Which uh, we are indeed, though.)
I am curious where you get the impression that this is not due to merit, but proponents 'pushing' the language to places it doesn't belong? Who are these proponents, and what is their motivation? From my view in the industry, it seems very apparent that this is organic growth because it is a useful language for many purposes, and those using it are naturally carrying their knowledge and experience with it to parallel domains. There is of course a snowball aspect of it where popularity begets popularity, but I really find it hard to see a vast conspiracy to push Python down people's throats - believe it or not, people actually enjoy using the language and get lots done with it.
-
It appears I am partly and indirectly responsible for the restriction. :(
What did you do? :D
Oh, I submitted a bug report, which the developers addressed by fixing the exec() docs rather than exec()'s behavior.
I had been using a subclassed dict to journal exec()'s global variable accesses while running tests of a set of requirements. The idea was that, using the journal, I could then roll back the System Under Test that caused a failure to the first errant state – and to shortly before. I write "could" because as an expedient (as in, shoot the engineer and ship it), I had been using the journal data to produce a focused dump of the proximate failure state and then manually rolling back the SUT with an existing GUI. That worked from Python 2.5 through either 3.6 or 3.7.
Someone subsequently had trouble accepting the restriction on exec(), filed a bug report and was told that it would not be fixed because having exec() check for a subclassed dict slowed down global accesses too much. I think the issue could be resolved to everyone's satisfaction, but need to try and submit some patches to prove that.
-
So the same will happen with Python. But currently, its proponents are eagerly trying to push it to almost anything conceivable, going out of their way to try and find new applications for it at all costs. That's not sane and it will definitely not last - it never has in the past. If it does last, then we are in a seriously troubled period IMO. (Which uh, we are indeed, though.)
I am curious where you get the impression that this is not due to merit, but proponents 'pushing' the language to places it doesn't belong? Who are these proponents, and what is their motivation? From my view in the industry, it seems very apparent that this is organic growth because it is a useful language for many purposes, and those using it are naturally carrying their knowledge and experience with it to parallel domains. There is of course a snowball aspect of it where popularity begets popularity, but I really find it hard to see a vast conspiracy to push Python down people's throats - believe it or not, people actually enjoy using the language and get lots done with it.
I agree. The idea of compulsive Python pushing seemed to me like a straw man. I remember people in its early days telling me that Python was a lot of fun but knowing it would not do anything for your resume. Some days I wish that were still true. I am half tempted to start a thread about why I like Python: to help people decide for themselves and perhaps lead some to the fun Assuming it is still fun – my mind may have become so happily warped I can no longer see how bad it is.
-
Just look at C. While it's still hugely popular if you consider its age, it is now restricted to niches (embedded software, maintenance of existing Linux/BSD/.. software, Linux kernel...) No one is currently trying to push it to be used universally for all purposes. Same for all other currently used programming languages. If that was once the case, the fad has passed.
So the same will happen with Python. But currently, its proponents are eagerly trying to push it to almost anything conceivable, going out of their way to try and find new applications for it at all costs. That's not sane and it will definitely not last - it never has in the past. If it does last, then we are in a seriously troubled period IMO. (Which uh, we are indeed, though.)
Years ago, when Microsoft wasn't behaving nearly as well as they are now, Ubuntu started including applications written in .net in default packages (some audio player or something). For several reasons (especially the patent issues – Microsoft and its partners claim patents on the underlying Common Language Infrastructure, and have only promised to license it on RAND terms and not for free, so there are no guarantees Microsoft will not try to go after you on patent infringement if you do something they don't like), I was very unhappy and worried. (Again, this was at an era when Microsoft was still heavily into EEE (https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish). They've changed a lot since.)
It is a very similar situation: like you said, a fad. As long as it is the proponents pushing stuff they develop themselves, let them. It is only if they start demanding others (especially companies) provide stuff written in that specific language or that specific framework, it gets really dangerous.
(Besides, whenever you start getting directives from the Cxx level as to which tools you must use, I'd say it is high time to switch jobs, because such companies do not tend to live long.)
As with Python, .net and Mono have settled down in their niche. There are those who happily use them, and those who prefer to avoid them, for various reasons. The fad will mostly calm down, and settle down to new developers discovering the New All-Purpose Hammer, and pushing it as the greatest invention since sliced bread. (Actually, they're rarer than you think. It is more visible only because of the current Social Media amplifies such inane messaging to the extreme.)
-
For me personally, Python has been a lot of fun ever since I discovered it 16 years ago. Back then Perl was more known as a scripting language, I used for some text scripts only AWK, and Python was not as well known as it is now.
When I started programming in Python I discovered a new way of doing things, really productive and fun. It allowed me to easily make scripts to validate other programs, to make data listings with templates, and to perform aggregate calculations from PLC data.
I am convinced since then that if you don't like Python you don't know it well.
-
I am convinced since then that if you don't like Python you don't know it well.
That is unassailable.
-
This is getting better and better! :-DD
-
I am convinced since then that if you don't like Python you don't know it well.
Works also for other programming languages! >:D
-
I have always found it useful to look at lists of fallacies (https://en.wikipedia.org/wiki/List_of_fallacies) and lists of cognitive biases (https://en.wikipedia.org/wiki/List_of_cognitive_biases), and compare to my own thinking and deduction methods, to see which ones I'm currently making. We humans are not rational by nature, we only are capable of it, and only if we work hard at it.
While I do consider Picuinos assertion irrational, I also see it as perfectly human and honest – and honesty is always commendable. :-+
As someone working on their own cognitive biases and tendencies towards certain fallacies, I won't pile on; and will only say that self-introspection and analysis of my own biases has helped me become more useful, more effective, and more capable of rational logic and thought. I consider it just another form of testing ones own mettle, if you will; character-building, if nothing else.
-
I am convinced since then that if you don't like Python you don't know it well.
You have to understand that there is a difference between not liking something and finding something actually usefull. Or put differently and more to the point: Python has strengths that make it useful for some purposes (cobble up a demonstrator / scripting) and weaknesses (poor distributability of applications).
-
I am convinced since then that if you don't like Python you don't know it well.
I try to stay away from black-and-white philosophies. Somebody could know Python very well and not like it. Somebody could argue that making programming easy for non-programmers just attracts the wrong kind of people to programming. Just as many experienced embedded programmers may use Arduino at times, but Arduino creates a large number of people who don't have the discipline to do real embedded programming and just want to have something to brag about and convince people that they're "awesome". Someone having Python on their resume (CV) impresses me not one bit.
-
weaknesses (poor distributability of applications)
For my use cases, slow I/O (compared to other programming languages) and lack of true multithreading (multiple concurrent Python threads in the same process) are a bigger drawback. On the other hand, Python works really well for me for building user interfaces, on top of compiled, dynamically linked native code.
Everything is a tradeoff, because the universe of things to do is too complex for any single language to describe efficient solutions efficiently in.
-
Somebody could know Python very well and not like it.
Ok, you are correct. I'm sure there are cases like that.
I will therefore limit myself to describing only my experience, not that of others.
Works also for other programming languages! >:D
That is something that has not happened to me. At least not in Pascal, nor in C, nor in JavaScript.
Something similar happened to me with AWK. I really liked it from the beginning and it was a lot of fun to quickly make some macros to create aggregated results from data in text files. But Python definitely surpassed it by far.
-
March 2024
"""
March Headline: The gap between Python and the rest has never been that large
February has been a very quiet month for the TIOBE index. The only interesting notes are that Python is now 4.5% ahead of the rest, Scratch reentered the top 10, and Rust keeps climbing. --Paul Jansen CEO TIOBE Software
"""
https://www.tiobe.com/tiobe-index/ (https://www.tiobe.com/tiobe-index/)
Python, against all odds and despite all its weaknesses, continues to maintain "popularity".
Congratulations to those of us who like Python.
EDIT: https://github.blog/2023-03-02-why-python-keeps-growing-explained/ (https://github.blog/2023-03-02-why-python-keeps-growing-explained/)
-
Does that make you feel fuzzy inside?
-
Does that make you feel fuzzy inside?
Sheep are fuzzy on the OUTside :p
-
Someone should invent the mongoose programming language
-
I'm actually concerned about the effect of Python's popularity to its future direction.
It was when PHP tried to please everyone and cater to the non-technical users (see magic quotes (https://en.wikipedia.org/wiki/Magic_quotes) for example) that it started down the road towards the messy hell it is today.
When humans are involved, it is the squeaky wheel that gets the grease. So, if the language developers start getting demands from tens of thousands of nontechnical users, they will focus on their complaints more than to the much fewer well-thought out cases with practical reasoning. Just like in the movie Idiocracy, this kind of catering to popularity will lead to the crapification of the language.
As a language, it is already teetering a bit on the edge. The artificial separation between 'bytes' and 'strings' makes its I/O very slow. Proper multithreading seems very difficult to achieve. The saving grace is the ease at which one can interface to native libraries via the ctypes module, without any modifications or particular requirements for the native library. I will use Python (especially for user interfaces) for as long as it makes sense, and not a second longer.
-
I know what would beat Python in popularity. A language with an easy GUI included. Something where you draw the windows and buttons with a mouse, and then right click on them to attach text code to GUI events. Having in mind the VB6 style from Microsoft, back in the 90s. I was having no problems writing code+GUI for VB6 20 years ago (without any training), but I struggle with anything GUI today, even after taking various classes and tutorials about GUI in python.
The way one slaps a GUI nowadays seems very unnatural. Write your code first, then start the GUI at the end, and no way to execute the lines following after that :-// seems ugly AF for non-programmers. The other alternative is to learn pygame or some other game developing platform, which is a big sidestep when all I want is a simple GUI with a couple of buttons and indicators in it. The other method I've seen (and tried once or twice) is Qt. Nice, but huge and very cumbersome, not for beginners. Even if I manage to do something with Qt, till next time I'll forget most of it, or the Qt version will change and have to start anew.
Another thing I wish from Python (and any other programming language) is to produce self contained code, as in no dependencies. I want to have one file, and run it today, or in 20 years. Won't mind if the executable packs itself in a container, or in a small virtual machine, but I want to be able to run the same code now, or 20 years from now without any hassle.
Lifespan of code has become as short as only a couple of months. If you try something from 5-10 years ago, chances are it won't install, it won't run and/or it won't even compile without putting a fight. We live in the age of disposable code. Run once, then update 2GB. >:(
Speaking of python, each time I use pip, it tells me to update pip 'cause there's a new pip version. Can't people make their mind about what pip should do, and how should do that, standardize, then implement once and forget about it for the next 20 years? Apparently this is not possible any more. Why? (pip is just a random example about a sw development trend, so far pip worked very well for me, thank you all for keeping it running)
-
I know what would beat Python in popularity. A language with an easy GUI included. Something where you draw the windows and buttons with a mouse, and then right click on them to attach text code to GUI events. Having in mind the VB6 style from Microsoft, back in the 90s. I was having no problems writing code+GUI for VB6 20 years ago (without any training), but I struggle with anything GUI today, even after taking various classes and tutorials about GUI in python.
The way one slaps a GUI nowadays seems very unnatural. Write your code first, then start the GUI at the end, and no way to execute the lines following after that :-// seems ugly AF for non-programmers. The other alternative is to learn pygame or some other game developing platform, which is a big sidestep when all I want is a simple GUI with a couple of buttons and indicators in it. The other method I've seen (and tried once or twice) is Qt. Nice, but huge and very cumbersome, not for beginners. Even if I manage to do something with Qt, till next time I'll forget most of it, or the Qt version will change and have to start anew.
That is what bothers me too. On Windows with visual studio, when I was still using it like over 10 years ago, it was possible to draw up a GUI and then implement the code in C++ for it. No idea what it is like now. On Linux I have tried Qt and others but they never did what I wanted it to do, so I wrote my own directly on top of X11. There is no graphical design entry, but at least the code remains the same, and I know how it works. No need to yet again learn how a new version of Qt does it now.
-
I know what would beat Python in popularity. A language with an easy GUI included.
I still maintain an application I wrote almost 20 years ago in Borland C++ Builder. It's actually quite refreshing going back to it. It's a 220MiB install and the IDE starts up in approximately one second and runs fine on Win10. Drag drop UI elements, easy access to properties and handlers, it's a breeze. No, it's not cross-platform but it doesn't need a bloated runtime interpreter either. The output exe's are tiny and fast. Old compiler though.
If only there were a C++ equivalent of Lazarus (https://www.lazarus-ide.org/), which basically the same IDE but targeting delphi.
-
C has been standard for decades (if we take C99 as standard) and this is a great advantage that unfortunately Python does not have. I also hope that the popularity of the language will not lead it to get lost.
In the Tiobe index Visual Basic still appears in the 10th place. For making simple GUIs it was unbeatable.
-
A language with an easy GUI included. Something where you draw the windows and buttons with a mouse, and then right click on them to attach text code to GUI events.
The reason why that does not exist, is the differences in existing native GUIs. Creating an abstraction layer that covers them all is pretty damn difficult. Even details like the visual box model (margin-border-padding-contents) differ.
Python does have Tcl/Tk (tkinter (https://docs.python.org/3/library/tkinter.html) and tkinter.ttk (https://docs.python.org/3/library/tkinter.ttk.html)) "built-in" (although usually requires a separate download, for example python3-tk; tkinter.ttk is the themeable version). You might wish to try that and Don Rozenberg's PAGE (https://page.sourceforge.net/), a "Visual Basic-style Tkinter GUI generator".
It generates the Python code for the Tkinter UI.
I prefer to use Qt Designer (Qt5) or Glade (Gtk3), saving the XML .ui description as a file, and building that at run time, with automagic name-based event handler association. It means the UI editor generates absolutely no code at all. I do need to give each interactive user interface element an unique ID, to make the name-based event handler association to work. (The simplest scheme is uniqueID_eventname, using only case-sensitive letters, digits, and underscore, possibly using a simple map from uniqueID and eventname to function-name. Both also support CSS for styling the interface.) I avoid setting/using sizes in pixels, because they clash with different-DPI displays.
I struggle with anything GUI today, even after taking various classes and tutorials about GUI in python.
Most of them are crap, written by learners not understanding the underlying reality (especially across different operating systems), enthusiastically telling others to follow in their footsteps, not seeing the inevitable brick wall looming a couple steps further.
A good tutorial would start by describing the limitations and differences in the different toolkits, then describe what widgets are, then what difference does code-based versus XML description make. Then, one could go into layout and display widgets, events/signals, event handling, and sane processing of data related to events (you don't do heavy computation in an event handler, because that causes the UI to freeze; you need to use either an idle handler that only does a bit of work at a time, or better, a separate worker thread that uses a thread-safe queue to talk to the UI thread). Most of those is the same for Gtk and Qt.
-
In network automation there's a new trend to move from Python to Go. The herd is moving on ...
-
Hopefully better languages than Python will be developed and become popular. That's the best thing for the users.
In the meantime I'm glad I don't have to learn to do macros, regular expressions and templates with Perl (that was the popular language when I learned Python) and I'm also glad I don't have to struggle with JavaScript other than in some of the frontend of my website. I much prefer working with Python for many reasons for macros and templating.
-
A good tutorial [for adding a GUI] would start by describing the limitations and differences in the different toolkits, then describe what widgets are, then what difference does code-based versus XML description make. Then, one could go into layout and display widgets, events/signals, event handling, and sane processing of data related to events (you don't do heavy computation in an event handler, because that causes the UI to freeze; you need to use either an idle handler that only does a bit of work at a time, or better, a separate worker thread that uses a thread-safe queue to talk to the UI thread). Most of those is the same for Gtk and Qt.
Where/how to start then, any recommended link/book/videolist please? (for Qt on Linux w KDE)
Last time I've tried (cca 2021) to write python code with a GUI was a fail. Did try already:
- PAGE - works, but nope, struggling with the editor, seems as buggy as an alpha version, erratic jumps on the screen, copy paste in GUI not working, etc. IIRC the kit was 10-20 years old, yet buggy on Linux, looked like abandonware.
- tkinter - followed (partially) this 18 hours video https://youtu.be/mop6g-c5HEY (https://youtu.be/mop6g-c5HEY) has a detailed ToC in the video description
- REMI - https://github.com/rawpython/remi (https://github.com/rawpython/remi) - seemed in early development stage, small community, not something to gamble it will last for 20 years
- PySimpleGUI - https://www.pysimplegui.com/ (https://www.pysimplegui.com/) - IIRC text only (tkinter based), no graphic designer for forms
- DearPyGui - https://github.com/hoffstadt/DearPyGui (https://github.com/hoffstadt/DearPyGui) - don't even recall which one was this (all GUI ways I've tried are mixing together ;D) - from my notes back then: overall DearPyGui is nice, but ImGui was rather made for games than for creating programs' GUI
- Qt/4/5/6 - great visual appearance, has forms designer, but huge. Was handling everything, audio, video, peripherals, etc. Got overwhelmed by such a mixture framework, plus confused by the differences between Qt4/5/6.
Might have tried a few other packages I don't remember. Qt seemed the way to go, for having a forms designer, and for being a mature product with many developers and big community. It is not exactly FOSS, in fact Qt was the most weird license I've ever heard off: commercial product, closed development, but the commercial owner loose all ownership if in one year (or 2) they don't open source it, or something like that. So, closed source for a year + open/free for products older than a year. Plus no binary downloads without a Qt account, though it is possible to build from sources without a Qt account. Weird. But apparently there is no other free option close enough to the old VB5 from 20 years ago. :-//
Dunno for others, but what bothers me the most is the lack of discoverability. In VB5/6 all the properties of the graphic objects were listed in the forms designer, in a GUI box that was populating itself with all the attributes once a GUI object was clicked, or dragged into its place. Easy to see how to make a button invisible, or to change its text/color without digging the docs for the exact text syntax.
When you make a GUI only once or twice a year, you won't remember anything from last time. I can barely remember how the program was called, or what exactly did I used. Have a brief text log inside each project, including how to (re)start the SW tools, how to build my own project, etc. Not only that I forget, but most programs won't even start after a year left untouched. Other packages will try to update themselves and fail. It looks like nobody is considering LTS in software development (long term support).
Even worst, there is a trend to make all online, not only the installers, but even the docs are now online. Except, with time websites changes, companies got acquired and all the pdf links becomes unusable, and so on. It has to be all offline, from installer, to running, to help and doc pages.
The only way to span a project over many years is to make a virtual machine for each project. Not kidding. Want to blink a LED with your devboard? Make a virtual machine, install all there, isolate the VM from internet, and store the VM in your project folder. Then keep that VM frozen in time and never update it. There is no other way, and even this one is fading away fast (i.e. current Arduino 2 IDE only has online help, which is stupid no matter how free it is). :horse:
Sorry for the rant. Any hints how to start with Qt please? (or maybe with something else as a GUI for own python code)
-
Where/how to start then, any recommended link/book/videolist please? (for Qt on Linux w KDE)
I haven't yet seen a good one.
Qt seemed the way to go, for having a forms designer, and for being a mature product with many developers and big community. It is not exactly FOSS
Bullshit. KDE desktop is completely based on the Qt toolkit. Because you are using KDE, you are already using Qt, based on the GPL and LGPL licenses.
Tough love follows.
Start with this:
Install qttools5-dev-tools. This provides Qt Designer (at /usr/lib/qt5/bin/designer), which you can use to create the user interface. It's user manual is here (https://doc.qt.io/qt-5/qtdesigner-manual.html). Do not confuse it with Qt Quick, Qt QML, or Qt Design Studio, which are a completely different thing. Do not use it to generate code, simply save the user interface as an XML .ui file. Ignore anything that talks about code and code generation. Make sure you create each interactive element an unique ID (using only ASCII letters, followed by ASCII letters, digits, or underscore; case sensitive), because that way, we can associate your event handlers with the correct UI objects just by using our own naming scheme and resolver.
If you like that, then install libpyside2-py3-5.15, python3-pyside2.qtcore, python3-pyside2.qtgui, python3-pyside2.qtsvg, python3-pyside2.qtuitools, python3-pyside2.qtxml, python3-pyqt5, python3-pyqt5.qtsvg. This gives you both PySide2 and PyQt5 bindings for Python3, so that you can test and write your Python3-Qt5 application that selects whichever is installed at run time.
If you used a Gtk+-based desktop instead of KDE, also install qt5-gtk-platformtheme, which helps Qt apps look more like Gtk+ apps on Gtk+-based desktops.
If you don't like that, install glade. This is the Gtk+ UI designer, the Gtk+ equivalent to Qt Designer. It's user manual is here (https://help.gnome.org/users/glade/). The same thing applies: ignore anything related to code generation, make sure you give each of your interactive UI elements an unique descriptive ID (using only ASCII letters, followed by ASCII letters, digits, or underscore, case sensitive), and save the UI as an XML .ui file.
If you like that, then install python3-gi, python3-gi-cairo, gir1.2-gtk-3.0, libgtk-3-0, libgtk-3-bin, libgtk-3-common, libgtk-3-dev, libgtk-3-doc (this will provide HTML documentation under /usr/share/gtk-doc/html/gdk3/ you can browse locally). This gives you Gtk+ Python bindings via GI (gobject introspection, sometimes written as gir).
If you're not happy with either, there is also wxWidgets (https://www.wxwidgets.org/) and wxGlade (https://wxglade.sourceforge.net/) and wxFormBuilder (https://github.com/wxFormBuilder/wxFormBuilder). In line with my suggestions above, use XRC for the code generation in wxGlade and wxFormBuilder, to get an XML resource file that can be instantiated at run time.
The steps forward from that point depend on which way you pick. Gtk+ can also be used from C, if you're more comfortable with C than Python.
Qt requires C++. One might consider using Lua with wxWidgets, although C++ and Python also work.
When you make a GUI only once or twice a year, you won't remember anything from last time.
Tough. The same thing applies to every single technical task. Dumbing down the tools is not a viable solution; it leads to "blunt scissors" tools that are designed to not cut anything, because otherwise those who like to eat glue and stuff crayons up their nose might hurt themselves with them.
What you need to do, is document yourself better.
As an example, whenever I switch to a new Linux distro or desktop environment, I record the list of packages I end up liking, as well as make notes on the changes I make. (For example, I like to use a variant of the Oblivion Gtk+ theme, except replace the gray backgrounds with true black.) It is not worth it to try and automate this, because just jotting the details down in a plain text file in a dedicated location, say your home directory, takes less time than any effort in automating this. It is a habit you have to adopt, if you want to survive without permanent brain damage from constant frustrations.
This way, I do not need to rediscover what I like; I already have the basis I need to continue my day-to-day stuff, within an hour or so if I have to switch computers. Which is also why I every day consider whether I created anything I would be upset about if lost, and back them up if I did.
It looks like nobody is considering LTS in software development (long term support).
I disagree. It is true that things change – for the exact same reason why the Linux kernel does not have stable internal APIs: having that would stifle innovation and limit what kind of things could be changed. That change is a necessity for things to develop at all, because human developers are just not getting paid or their dopamine kicks from maintaining existing code; they need to create something new to benefit.
Python 2/3 and changes in 3.x wrt. Windows support is a bitch; very true. I don't like that at all.
While Gtk4 and Python6 are "current"/"development"/"head", I personally target Gtk+ 3 and Qt 5, and can install all necessary libraries from standard repos to run my Gtk+2, Gtk 4, Qt 4, and Qt 6 code. That is, I have zero issues running my years-old code, because I always known this will happen, and prepared for it beforehand.
If you install Gtk3 support, and then run pkg-config --libs gtk+-3.0, it will tell you the libraries C code linked against Gtk+ 3.0 needs: libgtk-3, libgdk-3, libpangocairo-1.0, libpango-1.0, libharfbuzz, libatk-1.0, libcairo-gobject, libcairo, gdk_pixbuf-2.0, libgio-2.0, libgobject-2.0, libglib-2.0, all dynamically (.so). Alternatively, you can run your native program via strace -e openat -o logfile program [args...] to log all files it accesses. Using your package manager, you can find their owner packages, and list the package names required to run the application. Some of these will pull in additional packages, of course.
To distribute software in native Linux packages, you need to package them as .deb/.rpm/etc., and thus record their dependencies. This is done using the package names. This is crucial, so that installing an application will automatically ensure its dependencies are present. This has to be done by the developer, so if you intend to ever distribute anything you created yourself in a native package, you have to learn to track the package dependencies. Fortunately, it isn't hard, it is just something you have to spend the time to learn.
(If you also have a snapshot of a VM of a pristine install of the distributions and desktop environments you target, it is very easy and fast to verify the dependencies are sufficient. Verifying they are correct, i.e. even if someone removes packages included in the default installs, is a bit more complicated; your snapshot must be a minimal install then, and you'll also end up testing the dependencies of the entire package tree up to your own package, which will be slow. Unless you use a local SSD as the repository, in which case it is not that slow. And you generally only need to do that once, or when you add a dependency on a new library or other. For basic Python3 + Gtk/Qt applications, none of that is necessary; it's easy to just list the few root packages as dependencies. Mine above includes SVG support, but excludes multimedia, webkit (browser), and OpenGL widget support.)
A shortcut to distributing software is using Snap, Flatpack, etc. application images. Essentially, all the required libraries (and the services those libraries depend on) are provided with the application image.
An intermediate version of those is what I suggest for the cases when one wishes to distribute proprietary software. The software is installed system-wide, but for each user, a configuration directory (under their home directory) is used, populated with symlinks to the actual libraries the binaries will be using. This covers e.g. LGPL library update requirements, as long as the mechanism is described to the users and actually works. This includes the exact interpreter used, with the system-wide application "binary", say /usr/bin/your-proprietary-app, is actually a shell script that ensures the configuration symlink directory exists for the current user (perhaps populating it if necessary), and executes the user-specific interpreter via the symlink, with dynamic library resolution order (LD_LIBRARY_PATH and so on; see man ld.so (https://man7.org/linux/man-pages/man8/ld.so.8.html)). For many-many-users environments, if there is no user-specific directory, a global default directory can be used instead, to reduce disk space use. (Although symlinks don't take up much disk space at all.)
The only way to span a project over many years is to make a virtual machine for each project.
It is the easiest way, yes, but definitely not the only way. I personally don't need to do that, and can run stuff I wrote a decade ago right now without modifications –– might need to install a couple of libraries in some cases, but I tend to have those requirements listed, or they are obvious (as in Gtk+-2.0, or Qt 4 with PyQt4 bindings).
Even my embedded C code tends to be impervious to compiler version changes, because of my practical approach towards the standard and language implementation. The Python 2 vs 3 did bite me slightly (mostly just str vs bytes), but not enough to bother me too much.
:-//
There is no other way, and even this one is fading away fast (i.e. current Arduino 2 IDE only has online help, which is stupid no matter how free it is).
It may apply to Arduino and the proprietary world, but I definitely don't see that in the Linux distributions I use. Applications and projects –– including LibreOffice –– that use browser-based help files store them in /usr/share/doc/package/ just like they always have. (The only annoying thing is that if they use UTF-8, they need to explicitly state that with <meta charset="utf-8"> or <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, because although all text files on my system are UTF-8, I cannot set my browser default character set to UTF-8, because someone decided only legacy character sets can be the default character set and the only non-legacy character set is UTF-8. :wtf:)
My Arduino IDE is still 1.8.19, as that works fine with Teensyduino 1.59.
-
The only way to span a project over many years is to make a virtual machine for each project.
It is the easiest way, yes, but definitely not the only way. I personally don't need to do that, and can run stuff I wrote a decade ago right now without modifications –– might need to install a couple of libraries in some cases, but I tend to have those requirements listed, or they are obvious (as in Gtk+-2.0, or Qt 4 with PyQt4 bindings).
Virtual Machine disk images are pretty heavy-weight.
Docker is a pretty interesting way to manage this.
You can create a docker container for each project, and it uses disk space only for the actual files of that project -- which might be only a few KB or MB.
Docker containers are read/write. They are a layer (and the only writable layer) over the top of N immutable layers of other stuff. The immutable layers are called "images".
You can run multiple containers from one image. They each use just the delta of disk space. You can at any time save a snapshot of a container as a new image (again, just using that delta of disk space) and then launch any number of independent new containers using it.
As an example, I have an image riscv64/ubuntu which I got from the internet. It uses 61.6 MB of disk space (the x86 Ubuntu for some reason uses only 56.4 MB, I don't know why).
I have my own image, called "rvdev" which is riscv64/ubuntu with gcc, emacs and other stuff I use in most or all projects added to it (using apt install). It's about 3 GB.
Then I have a container for each project.
For example, I just ran a new container based on "rvdev" (docker run -it rvdev bash), edited hello.c, compiled it with gcc, and run it, and exited from the container.
The container size is 9.36 KB. I can run that at any time. I can "commit" it to an image, which also uses 9.36 KB. If I'm truly paranoid I can export it to a tar file, which has everything from all images it depends on, and is therefore 3.1 GB.
There are alternatives which do much the same thing e.g. podman.
-
I have a container for each project.
I do the same :-+
-
Another tool I use in Python are virtual environments, which allow you to keep different packages installed for a particular application isolated.
-
You can create a docker container for each project, and it uses disk space only for the actual files of that project -- which might be only a few KB or MB.
How is that different from having a base VM and then your project VMs being linked clones of that? Only the differences are stored in the clones, so pretty much just the actual project files. AFAIK, both VMWare and VirtualBox allow linked clones.
-
Start with this:
Install qttools5-dev-tools. This provides Qt Designer (at /usr/lib/qt5/bin/designer), which you can use to create the user interface. It's user manual is here (https://doc.qt.io/qt-5/qtdesigner-manual.html). Do not confuse it with Qt Quick, Qt QML, or Qt Design Studio, which are a completely different thing. Do not use it to generate code, simply save the user interface as an XML .ui file. Ignore anything that talks about code and code generation. Make sure you create each interactive element an unique ID (using only ASCII letters, followed by ASCII letters, digits, or underscore; case sensitive), because that way, we can associate your event handlers with the correct UI objects just by using our own naming scheme and resolver.
If you like that, then install libpyside2-py3-5.15, python3-pyside2.qtcore, python3-pyside2.qtgui, python3-pyside2.qtsvg, python3-pyside2.qtuitools, python3-pyside2.qtxml, python3-pyqt5, python3-pyqt5.qtsvg. This gives you both PySide2 and PyQt5 bindings for Python3, so that you can test and write your Python3-Qt5 application that selects whichever is installed at run time.
That was very helpful, thank you. Installed, and Qt5 designer is the one I like the most! :-+
Apart from those packages, I've installed 2 more suggested by the sudo apt install <whatever>, some 'whatwever-doc' packages, which I assume it's the offline documentation. Have space on disk, so installed them too, in total:
qttools5-dev-tools, qt5-doc <--- this one suggested by qttools5-dev-tools was funny, it dragged in a ton of extra packages, about +100MB extra :) ,
libpyside2-py3-5.15, python3-pyside2.qtcore, python-pyside2-doc, python3-pyside2.qtgui, python3-pyside2.qtsvg, python3-pyside2.qtuitools, python3-pyside2.qtxml, python3-pyqt5, python3-pyqt5.qtsvg, all of them installed with sudo apt install <package name> from the Ubuntu repositories.
Didn't took yet the tour/read of the QT 5 Designer manual (https://doc.qt.io/qt-5/qtdesigner-manual.html) you linked to, only opened the designer and made a very simple designer_try_1.ui form (attached). My understanding so far is that we use the 'designer' only as a graphic editor, good to drag in place buttons and other GUI elements. The rest (attach code to GUI events and such) is to be done from python.
Since I do not know the architecture of a GUI system (and how python/tk/qt interacts between them), and since all components have either py or qt in their name, to me it's a total confusion. For example, I understand that I've just installed 2 components: pyqt5 and pyside2. Do these two need each other in order to have a working GUI in python, or are they 2 distinct possibilities from which to choose one?
Anyway, having the install and the attached .ui file, what's the next step please?
-
You can create a docker container for each project, and it uses disk space only for the actual files of that project -- which might be only a few KB or MB.
How is that different from having a base VM and then your project VMs being linked clones of that? Only the differences are stored in the clones, so pretty much just the actual project files. AFAIK, both VMWare and VirtualBox allow linked clones.
As far as storage, the container uses the host OS, so even the base image will be much smaller than a VM image as it will basically just include the Python interpreter and standard library, for example. You also have a storage advantage in that you aren't tracking access time for every file in the image, temporary storage, caches and whatever other random stuff gets written as you use it. The container image is something you build with the application, and isn't writable at runtime. Writable storage in the container is either ephemeral or something you specifically define as persistent.
The main advantage of containers though is that they run in the host OS, so it is much easier to integrate them with a local workflow. Startup time is on the order of milliseconds not minutes, you can easily access local files without messy network mounting etc., a command can be passed into the container at startup. With minimal setup you can basically treat container commands the same as local commands. You can also build your images on top of 'reference' images maintained by someone else. For example if you are targeting Python 3.10, you can use the python:3.10 image tag published by the Python team, and you'll track the latest point release whenever you rebuild.
Mostly though, containers are just much nicer to use. They integrate much easier with the host system, so it's feasible to run a 'convenience' script inside a container, against files on your local machine. For example maintaining KiBot and all its dependencies is a nightmare, so I use their published container to run it against my projects locally. They're also much more conducive to reproducibility elsewhere. Container images are well defined, and as long as they're built for the architecture they're running on, should 'just work'. VM images require the correct hypervisor, correct hardware profile etc.
-
My understanding so far is that we use the 'designer' only as a graphic editor, good to drag in place buttons and other GUI elements.
Yes.
For example, I understand that I've just installed 2 components: pyqt5 and pyside2. Do these two need each other in order to have a working GUI in python, or are they 2 distinct possibilities from which to choose one?
They are two distinct possibilities. They arise from history: Qt did not provide Python bindings prior to Qt 5, but RiverBankComputing provided them as the PyQt4 package. For Qt5, there are now two separate possibilities: PyQt5 and PySide2. Either one can be used, and they are almost identical. PyQt5 is GPL, PySide2 is LGPL.
Anyway, having the install and the attached .ui file, what's the next step please?
You create a minimal skeleton in Python for the ui.
You created a dialog, which closes as soon as either button is pressed. As it is, there is not much coding to add in Python, because after the dialog has closed.
Assuming you name the UI file rogeorge.ui, the corresponding rogeorge.py might be
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# SPDX-License-Identifier: CC0-1.0
import sys
try:
# Prefer PyQt5,
from PyQt5 import QtCore, QtGui, QtWidgets
from PyQt5.uic import loadUi
except ImportError as err:
# but fall back on PySide2.
from PySide2 import QtCore, QtGui, QtWidgets, QtUiTools
def loadUi(uifile):
return QtUiTools.QUiLoader().load(uifile)
class RoGeorge(object):
def __init__(self):
super().__init__()
self.ui = loadUi("rogeorge.ui")
for slot in dir(self):
if slot.startswith("on_") and slot.find("_", 3) > 3:
method = getattr(self, slot)
widgetName, signalName = slot[3:].rsplit("_", 1)
source = self.ui.findChild(QtCore.QObject, widgetName)
signal = getattr(source, signalName, None)
if signal:
signal.connect(lambda *args, **kwargs: method(source, *args, **kwargs))
self.show = self.ui.show
def on_radioButton_3_USB_clicked(self, widget, clicked):
print("clicked on %s" % widget.objectName())
if __name__ == '__main__':
app = QtWidgets.QApplication(sys.argv)
win = RoGeorge()
win.show()
status = app.exec_()
if win.ui.result() == QtWidgets.QDialog.Accepted:
if win.ui.findChild(QtWidgets.QRadioButton, "radioButton_1_LAN").isChecked():
print("LAN: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP").text())
elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_2_COM").isChecked():
print("COM: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_2").text())
elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_3_USB").isChecked():
print("USB: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_3").text())
else:
print("None selected")
else:
print("Canceled")
del win
del app
sys.exit(status)
For an example of the event handling, I created the on_radioButton_3_USB_clicked() handler. Note that I use a lambda function, essentially a closure, to provide the handler both the context to the RoGeorge object (self), as well as the object that generated the signal (widget), followed by any additional parameters provided by the signal like checked boolean for clicked() signal. It just makes things easier.
The above works. I recommend you run it from a terminal, so you can see the 'clicked on' message as well as the result status when the window is closed or either button pressed.
If you resize the window, you'll see that everything stays in place, even though the window size changes. Similarly, even if you change your font size, the locations of the QLabels and QLineEdits stay fixed: not what you want. What you should do, is use a QFormLayout, then drop the QLabels and QLineEdits into its cells, and not define any sizes or locations in pixels. You can control how the window stretches (based on content/font size, and when resized), and how added space is allocated to the different elements.
(Those old Visual Basic UIs only worked because they used a fixed font and font size. That is no longer true, and placing UI elements just based on what they look like on your machine no longer cuts it, except for the cruddiest of throwaway single-use programs.)
Next, design a proper QMainWindow main window, and start exploring on what kind of signals (events) you can handle, and how.
Since they don't have the .result() method, you can then remove the entire if win.ui.result() block.
If we changed the RoGeorge class to be a subclass of QtWidgets.QMainWindow, we could use it as the base instance, and simplify things quite a bit. If you create a QMainWindow .ui file, I can show how the Python code changes. The main change is that instead of widgets hanging off self.ui, they'll hang off self, which makes things much nicer. I like to call such a class simply MainWindow. (In the Qt Designer, you'll still use QMainWindow, because MainWindow will be a derivative, and thus compatible). It can also make sense to create a dict/tuple-based mapping between widget IDs and handlers, especially when you have many widgets with the same handler, instead of copy-pasting them en masse. Another way to handle that is to create your own widget derivatives.
You may wish to look at the plain text XML .ui file, too. It is not a complex file format at all.
-
They're [containers] also much more conducive to reproducibility elsewhere. Container images are well defined. VM images require the correct hypervisor, correct hardware profile etc.
Container images depend on the rather stable Linux syscall interface.
> and as long as they're built for the architecture they're running on, should 'just work'
docker uses the binfmt_misc facility to run non-native images. So, actually, you can run any ISA of images on any other ISA, at reduced performance.
When you install the "Docket Desktop" rather than just the base Docker Engine, it includes QEMU and automatically sets up binfmt_misc.
I regularly run my RISC-V docker images on my x86 laptop or M1 Mac Mini for development. Other than speed it's just transparent. The laptop, in particular, has 24 cores and 32 GB RAM while my largest RISC-V board at present [1] has only four cores and 16 GB.
[1] the 64 core, 128 GB, Milk-V Pioneer has bee shipping for a couple of months, but I don't have one.
-
The main advantage of containers though is that they run in the host OS, so it is much easier to integrate them with a local workflow. Startup time is on the order of milliseconds not minutes, you can easily access local files without messy network mounting etc., a command can be passed into the container at startup.
OK, thanks. I can see that would be very useful to be using the normal tools and stuff. But it is dependent on the host OS. Let's say you upgrade to W10 then W11, then give up and move to a Mac before deciding Linux is he place to be... is your container going to survive that? The VM will regardless of what host it's sitting on, which I understood to be the problem RoGeorge mentioned some way up this thread.
-
OK, thanks. I can see that would be very useful to be using the normal tools and stuff. But it is dependent on the host OS. Let's say you upgrade to W10 then W11, then give up and move to a Mac before deciding Linux is he place to be... is your container going to survive that? The VM will regardless of what host it's sitting on, which I understood to be the problem RoGeorge mentioned some way up this thread.
There's no implicit abstraction between the container and the kernel; syscalls reach the kernel directly. So a container made to run on Linux (the vast majority of them) requires Linux syscalls be available at runtime. If you're using Docker as your container engine, it'll take care of running a Linux VM for this purpose transparently if you want to use macOS or Windows.
-
Services and command-line programs can trivially be run using only specific libraries provided with the binary, ignoring everything already on the system. The simplest way to do this is to compile your program statically against a standard C library that does not rely on dynamically loaded modules (for e.g. resolver).
The problems arise when you wish the independent binary to interface with different services, like desktop environments and audio libraries.
Docker provides these interfaces in a standardized format. It also uses Linux kernel features like cgroups to isolate what such processes can see of the host system. "Container" is a very accurate description for this.
The intermediate model I've described, with symlinks to either system or application-provided dynamic libraries in an user-controlled directory, is not "containerized" at all. It is just a way to control library versioning and dependencies in a straightforward manner in Linux.
The most common term for this is shims.
Python virtual environments (pyenv, Python venv) consist of environment variables and a shim directory for related executables inserted in PATH before standard command directories, so that for affected commands, the symlinks (or wrapper scripts) are used instead of the executables in standard directories.
Virtual machines are simply "containers" at the kernel level, limiting what hardware a kernel can access and when.
The most useful feature for myself for desktop virtual machines is snapshotting: creating a point in time, containing everything in the virtual machine at that point, that I can return to and continue as if forking a new timeline from that point. An excellent example is creating a snapshot before installing a new application. If I decide it was a wrong move, or it caused problems, I can simply erase that timeline completely by returning to the earlier snapshot.
When one creates installable software packages, having such a VM snapshot of the base install for testing makes it trivial to check if you have your package dependencies right. If they are, the dependencies will drag in any missing libraries and services required, and everything will work.
-
Python seems to have become the new Basic - the build free language people use for their quick and dirty experiments. 3 times in the last year I wanted to interface to something, looked around for existing open source code to help get me started, and found implementations only in Python. In each case it looked like the author had used python expressly to allow quick experimentation as they reverse engineered an undocumented or poorly documented interface. Now, you can take the knowledge they gathered, and reimplement the interface in another language, or just live with the python code. I guess most people will just use the existing python code, and write more Python. Things can achieve a lot of viral growth along paths like this.
-
That this is true does not mean that Python is like BASIC. The old BASIC was a language very given to spaghetti programming and quite unmaintainable. Python is much more maintainable and facilitates programming oriented to make simple to maintain programs.
Of course bad programmers program badly in any language.
-
That this is true does not mean that Python is like BASIC. The old BASIC was a language very given to spaghetti programming and quite unmaintainable. Python is much more maintainable and facilitates programming oriented to make simple to maintain programs.
Of course bad programmers program badly in any language.
Oooh, a zealot who can't resist stating the obvious. ;)
-
Oooh, a zealot who can't resist stating the obvious. ;)
It's not that obvious. It will be obvious to you who know Python well, but that doesn't mean it is obvious to everyone else.
Many people who don't know the difference will think, from what you've written, that Python is a language whose zen is to write fast and badly. And nothing could be further from the truth: https://peps.python.org/pep-0020/
Just because Python attracts flies doesn't mean that's what it was designed for. When I learned Python, some 20 years ago, there was hardly anyone attracted to the language. It was other languages that attracted bad programmers.
If that's the price to pay for popularity, maybe I'm not so sure I like Python being popular.
I do like that it is popular because it has certain advantages as you said, even if it has disadvantages.
-
Oooh, a zealot who can't resist stating the obvious. ;)
It's not that obvious. It will be obvious to you who know Python well, but that doesn't mean it is obvious to everyone else.
Many people who don't know the difference will think, from what you've written, that Python is a language whose zen is to write fast and badly. And nothing could be further from the truth: https://peps.python.org/pep-0020/
Just because Python attracts flies doesn't mean that's what it was designed for. When I learned Python, some 20 years ago, there was hardly anyone attracted to the language. It was other languages that attracted bad programmers.
If that's the price to pay for popularity, maybe I'm not so sure I like Python being popular.
I do like that it is popular because it has certain advantages as you said, even if it has disadvantages.
I said nothing negative about Python. That's projection on your part. I do think a lot of the impulse to use it stems from it having the immediacy of BASIC without being utter garbage for writing anything longer than a few lines, as BASIC is.
-
No, you didn't say anything bad about Python, you just said it to me (with a wink).
What you said about Python, which is true and I don't deny it, is only a part of the reality. Now the popularity and simplicity of Python attracts bad programmers and generates bad programs.
For my part I just wanted to emphasise that, being true, Python promotes much more good code writing than similar languages like Ruby or others like JavaScript. It has been in its Zen since 2004.
It may be obvious to you, but you haven't told us and it's important to know.
-
I quite like AWK. That was the tool/language I used to make macros before I knew Python. It is very expressive and you can easily make fast programs even on a single line. But when it comes to making more complex programs, programming becomes slower and cumbersome. That's not to mention the large number of tools that Python has built in and AWK no.
In the end for me it is easier to create a program in Python, even if it takes me more lines, than to do the same in AWK.
I am not a professional programmer, I use macros from time to time, but I am not programming all day long. So deciding whether AWK or Python is better for a task makes no sense to me. I now do all scripting tasks with Python and it takes less overall effort.
This is not to say that I don't recognize the many advantages of AWK. It's just that, in my case, it's not worthwhile to maintain competition in the two tools.
-
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# SPDX-License-Identifier: CC0-1.0
import sys
try:
# Prefer PyQt5,
from PyQt5 import QtCore, QtGui, QtWidgets
from PyQt5.uic import loadUi
except ImportError as err:
# but fall back on PySide2.
from PySide2 import QtCore, QtGui, QtWidgets, QtUiTools
def loadUi(uifile):
return QtUiTools.QUiLoader().load(uifile)
class RoGeorge(object):
def __init__(self):
super().__init__()
self.ui = loadUi("rogeorge.ui")
for slot in dir(self):
if slot.startswith("on_") and slot.find("_", 3) > 3:
method = getattr(self, slot)
widgetName, signalName = slot[3:].rsplit("_", 1)
source = self.ui.findChild(QtCore.QObject, widgetName)
signal = getattr(source, signalName, None)
if signal:
signal.connect(lambda *args, **kwargs: method(source, *args, **kwargs))
self.show = self.ui.show
def on_radioButton_3_USB_clicked(self, widget, clicked):
print("clicked on %s" % widget.objectName())
if __name__ == '__main__':
app = QtWidgets.QApplication(sys.argv)
win = RoGeorge()
win.show()
status = app.exec_()
if win.ui.result() == QtWidgets.QDialog.Accepted:
if win.ui.findChild(QtWidgets.QRadioButton, "radioButton_1_LAN").isChecked():
print("LAN: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP").text())
elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_2_COM").isChecked():
print("COM: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_2").text())
elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_3_USB").isChecked():
print("USB: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_3").text())
else:
print("None selected")
else:
print("Canceled")
del win
del app
sys.exit(status)
It works, thanks! :D
After replacing the filename, of course. Was the change of the filename a suggestion to use single word naming as a better practice (instead of long names made from a few words and underscores), or it is just happen to be how you saved the .ui file?
Asking about the names because I've notice in some books (long ago, it was Fortran or Cobol, don't recall), example of names that were back then very confusing for me. For example, a variable named variable, or an example of a text variable text = 'text', which was totally confusing while learning about variables for the first time.
Another strange naming I see sometimes in code example is foo and bar. Bad choice. They look and sound similar, easy to mix later in the code which was which. Not to say when same words foo and bar are used both in the main code and as arguments when defining a function or a class. Then some smarty decides to use uses foo, bar, foobar and barfoo, all in the same example. ;D Why not A B C D, or something else hard to confuse.
But foo/bar bambuzling is peanuts. Just wait to hear the encryption guys, explaining with Alice and Bob. :palm:
Worst choice ever. I never read/watch explanations with Alice and Bob, because they never specify if Alice and Bob are together. That detail alone will entirely change the dynamic of private keys exchanging, isn't that so? ;D
Back to GUI in Python, I've started to think what the main window should look like. Trying to figure out what controls to keep in the main window, if the comm setings should be as a pop-up or as a tab or maybe all in a single form, I've open a spreadsheet to draft the location of each GUI element.
Then I've realized I could just use a spreadsheet (LibreOffice Calc) as a GUI. ;D
Calc is always installed on my Desktop, and it's probably the ideal tool for small experiments and draft calculations and in the lab. Even charts are significantly easier to use/design than in Octave or Matplotlib. My main need of a GUI is to control some instruments, or to talk with a microcontroller over a serial port, things like that. I don't really need them to have a nice standalone program.
Unfortunately the default scripting language for spreadsheets is Basic (or VBA in MSOffice), but OpenOffice/LibreOffice (I don't use MS any more) can run Python scripts instead of Basic macros, and can assign Python functions to button events and such, just as if it were Basic functions (tried APSO - Alternative Script Organizer for Python (https://extensions.libreoffice.org/en/extensions/show/apso-alternative-script-organizer-for-python), a LibreOffice Extension, can embed Python scripts into the .ods file itself just as if Python code were Basic macro). Some extensions can even edit both Python and Basic sources inside the Office macro editor. ALT+F12 from any office document, and start using the IDE meant for Basic. :)
There is another possibility of remotely making use of the Libre/OpenOffice GUI, by using the UNO (Unified Network Objects) (https://help.libreoffice.org/6.4/en-US/text/sbasic/shared/uno_objects.html) protocol over LAN. UNO looks really complicated, but there are already some Python wrappers that makes UNO calls easy to make from Python (I've tried pyoo (https://pypi.org/project/pyoo/)). Can open a spreadsheet and write in it under your eyes like it were haunted, very funny to watch. :D
#!/usr/bin/env python3
# before running the .py start an office instance that is listening on a UNO interface, either manually or from python
#
# soffice --accept="socket,host=localhost,port=2002;urp;" --norestore --nologo --nodefault # --headless
import pyoo
import subprocess
import time
#subprocess.Popen(["python.exe", "second.py"], creationflags=subprocess.CREATE_NEW_CONSOLE) # this will wait for the subprocess to finish
# subprocess.Popen(['soffice --accept="socket,host=localhost,port=2002;urp;" --norestore --nologo --nodefault'], creationflags=subprocess.CREATE_NEW_CONSOLE) # windows only without waiting to finish
subprocess.Popen('soffice --accept="socket,host=localhost,port=2002;urp;" --norestore --nologo --nodefault', shell=True)
# time.sleep(0.5) # wait 0.5 seconds for soffice to start
desktop = pyoo.Desktop('localhost', 2002)
# pyoo.Desktop(pipe='hello') # <- not working ?
doc = desktop.create_spreadsheet() # new untitled spreadsheet document
# doc = desktop.open_spreadsheet("./os_made_calc.ods") # opens existing ods
sheet = doc.sheets[0] # access sheets by index
sheet = doc.sheets['Sheet1'] # access sheets by name
doc.sheets.copy('Sheet1', 'Copied Sheet', 2) # copy a sheet
# del doc.sheets[1] # deletes a sheet by index
del doc.sheets['Copied sheet'] # deletes a sheet by name
adr_text = str(sheet[0,0].address) # get cell [row, col] address ($A$1)
adr_text = str(sheet[0,1].address) # get cell [row, col] address ($B$1)
sheet[0,0].value = 1 # set cell value
sheet[1,0].value = 2 # set cell value
sheet[3,0].formula = '=$A$1+$A$2' # set cell formula
print(f'The value calculated by the spreadsheet is %i', sheet[3,0].value)
#########################
# Tabular (two dimensional) cell range:
sheet[1:3,0:2].values = [[3, 4], [5, 6]]
# Row (one dimensional) cell range:
sheet[3, 0:2].formulas = ['=$A$1+$A$2+$A$3', '=$B$1+$B$2+$B$3']
print('sheet[3, 0:2].values ', sheet[3, 0:2].values)
# Column (one dimensional) cell range:
sheet[1:4,2].formulas = ['=$A$2+$B$2', '=$A$3+$B3', '=$A$4+$B$4']
print('sheet[1:4,2].values ', sheet[1:4,2].values)
# Get cell range with all data
cells = sheet[:4,:3]
# Font and text properties:
cells.font_size = 20
cells[3, :].font_weight = pyoo.FONT_WEIGHT_BOLD
cells[:, 2].text_align = pyoo.TEXT_ALIGN_LEFT
cells[-1,-1].underline = pyoo.UNDERLINE_DOUBLE
# Colors:
cells[:3,:2].text_color = 0xFF0000 # 0xRRGGBB
cells[:-1,:-1].background_color = 0x0000FF # 0xRRGGBB
# Borders
cells[:,:].border_width = 100
cells[:,:].border_color = 0xFFFF00
cells[-4:-1,-3:-1].inner_border_width = 50
# Number format can be also set but it is locale dependent:
locale = doc.get_locale('en', 'us')
sheet.number_format = locale.format(pyoo.FORMAT_PERCENT_INT)
# Charts
chart = sheet.charts.create('My Chart', sheet[5:10, 0:5], sheet[:4,:3])
# Existing charts can be accessed either by an index or a name:
print('sheet.charts[0].name ', sheet.charts[0].name)
print('sheet.charts["My Chart"].name ', sheet.charts['My Chart'].name)
# Chart instances are generally only a container for diagrams which specify how are data rendered. Diagram can be replaced by another type while chart stays same.
print ('chart.diagram.__class__ ', chart.diagram.__class__)
diagram = chart.change_type(pyoo.LineDiagram)
print ('diagram.__class__ ', diagram.__class__)
# Diagram instance can be used for accessing and setting of miscellanous properties.
# Set axis label
diagram.y_axis.title = "Primary axis"
# Axis can use a logarithmic scale
diagram.y_axis.logarithmic = True
# Secondary axis can be shown.
diagram.secondary_y_axis.visible = True
# All axes have same attributes.
diagram.secondary_y_axis.title = "Secondary axis"
# Change color of one of series (lines, bars,...)
diagram.series[0].fill_color = 0x000000
# And bind it to secondary axis
diagram.series[0].axis = pyoo.AXIS_SECONDARY
# wait
print()
aaa=input('press ENTER to close...')
# Saving documents
doc.save('example.xlsx', pyoo.FILTER_EXCEL_2007)
# doc.save()
# And finally do not forget to close the document:
doc.close()
Mentioning Libre/OpenOffice as a GUI for Python because it was very fast to do the GUI with it (about 10 times faster for me). Aside from productivity, a spreadsheet has already very well polished tools and features (for example data validation with a helping message and error treating, conditional formatting, text colors and sizes, charts, etc.). Everything in a spreadsheet GUI is trivial to change, when compared with Qt designer.
A spreadsheet doesn't look as good as a Qt GUI, but for my use case that doesn't matter. I don't write and distribute programs, only need python with a GUI to control things around the lab, talking about hobby level experiments and such.
Will continue with Qt, too, and do an average size program side by side, in Qt+Python and in LibreOffice+Python. Want to see which one is easier for something more than just a hello world. At this moment, taking advantage of the Office GUI seems a ton easier for my use case.
-
For my part I just wanted to emphasise that, being true, Python promotes much more good code writing than similar languages like Ruby or others like JavaScript.
With what kind of evidence can you back this up? Because that sounds like bullshit to me. So show us your evidence.
Had you said "than the BASIC of the 70s & 80s", sure, there would be no question.
But Ruby or JS? Are you serious?
-
Was the change of the filename a suggestion to use single word naming as a better practice (instead of long names made from a few words and underscores), or it is just happen to be how you saved the .ui file?
More about how I saved the .ui file.
If I had thought about it longer, I probably would have named it something like connectionmethod.ui.
Asking about the names because I've notice in some books (long ago, it was Fortran or Cobol, don't recall), example of names that were back then very confusing for me. For example, a variable named variable, or an example of a text variable text = 'text', which was totally confusing while learning about variables for the first time.
Yes. This is also true of the interactive widget ID's, because for maintainability, you'll want your on_widgetname_signal() to be descriptive and intuitive.
In particular, the way you used names, lineEdit_1 and similar, is counterproductive. Something like LAN, LANSelected, Serial, SerialSelected, USB, USBSelected would lead to much more maintainable and intuitive code.
At the core, my advice is to name things according to their use and relevance, meaning, not their type. (This means I seriously recommend against all variants of Hungarian notation (https://en.wikipedia.org/wiki/Hungarian_notation#Systems_Hungarian_vs._Apps_Hungarian).)
The way I do this is think about what name would be most illustrative/intuitive for someone looking at the code/UI for the first time, trying to solve a bug or issue in it.
Also note that for .findChild(), the object type does not need to be the exact target object type, it can be any ancestor type, up to QObject. Instead of QtWidgets.QRadioButton, Qtwidgets.QAbstractButton would have been better, because it is the ancestor of all button types that provide a .isChecked() method. QtWidgets.QLineEdit does not have a similar ancestor, it is a direct derivative of QtWidgets.QWidget, so that's fine.
Another strange naming I see sometimes in code example is foo and bar. Bad choice.
Technically speaking, foo, bar, baz (https://en.wikipedia.org/wiki/Foobar) and so on are metasyntactic variables: not to be used as variables per se, but used as variable name placeholders to describe the syntax.
Single-letter names are applicable for variables of known meaning. Consider e.g. Cartesian coordinates x, y, z; barycentric coordinates u, v, w; indexes i, j, k, m, n; and so on.
Alice and Bob (https://en.wikipedia.org/wiki/Alice_and_Bob) arise from early cryptographic articles, where they described the two main communicating parties; nowadays there are many more names used for specific types of parties. They are a similar convention as using x, y, z for Cartesian coordinates, or r and ϕ (or θ or φ) for polar coordinates; just using human names.
For simple dialogs, you can use Zenity (https://help.gnome.org/users/zenity/stable/) (Gtk+) or KDialog (https://develop.kde.org/docs/administration/kdialog/) from simple shell scripts. The exit status will correspond to Ok/Cancel/Window closed, and any selections will be printed to standard output so you can safely capture it.
For desktop notifications (timed popups informing of e.g. network connection loss), use notify-send (https://man.archlinux.org/man/notify-send.1.en) (from libnotify-bin package). It uses DBus for the underlying mechanism, and should work in all desktop environments in Linux.
For the example case, I would create a simple single text entry dialog with a scheme prefix and help text, i.e.
ip:192.168.1.1
tty:/dev/ttyUSB1
usb:/dev/usb/001/001
If you use Bash and response="$(zenity ...)" then
scheme="${response%%:*}"
value="${response#*:}"
will split the scheme and the value into separate Bash variables. This way your Bash script can easily accept the same as a command-line parameter for those use cases where the scheme and value are already known at script execution time without prompting the user.
-
KDialog (https://develop.kde.org/docs/administration/kdialog/) from simple shell scripts. The exit status will correspond to Ok/Cancel/Window closed, and any selections will be printed to standard output so you can safely capture it.
Wow! I knew I can pop a MsgBox from a .vbs in Windows, but I didn't know Plasma can do the same. ;D
There are some misconceptions that Plasma is only a graphical environment. While it is true that Plasma is an outstanding desktop environment, the Unix heritage of command line and scripting is also well supported by Plasma. In particular, KDE applications can be controlled from the command line, and shell scripts can make use of some of the KDE widget set.
Quote from https://develop.kde.org/docs/administration/kdialog
That will cover 9 out of 10 situations with zero GUI programming overhead, perfect for my use case, thanks! :-+