131–140 of 558 posts
I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
Speaking as someone who has written Python code almost every day for the last 16 years of my life: I'm not happy about this. Some of this stuff seems to me like it's opening the doors for some antipatterns that I'm consistently frustrated about when working with Perl code (that I didn't write myself). I had always been quite happy about the fact that Python didn't have language features to blur the lines between what…
Many languages don't distinguish between statements and expressions—in some languages, this is because everything is an expression! I'm most familiar with these kinds of languages. I'm not familiar much with Python, beyond a little I wrote in my linear algebra class. How much does the statement/literal distinction matter to readability? What does that do for the language?
The first part of the statement (at least one obvious way to do it) goes to gaining a lot of expressive power from having learned only a subset of the language specification corresponding to the most important concepts. So you invest only a small amount of time in wrapping your head around only the most important/basic language concepts and immediately gain the power that you can take any thought and express it in the language and end up not just with some way of doing it, but with the right/preferred way of doing it.
The second part of the statement (at most one obvious way to do it) makes it easy to induce the principles behind the language from reading the code. If you take a problem like "iterate through a list of strings, and print each one", and it always always always takes shape in code by writing "for line in lst: print( line )" it means that, if it's an important pattern, then a langauge learner will get exposed to this pattern early and often when they start working with the language, so has a chance to quickly induce what the concept is and easily/quickly memorize it due to all the repetition. -- Perl shows how not to do it, where there are about a dozen ways of doing this that all end up capable of being expressed in a line or two. -- Therefore, trying to learn Perl by working with a codebase that a dozen people have had their hands on, each one preferring a different variation, makes it difficult to learn the language, because you will now need to know all 12 variations to be able to read Perl reliably, and you will only see each one 1/12th as often making it harder to memorize.
Earlier quoted context omitted.
Oh come on, it doesn't.
My metric for this is to put some of my freshest student in front of a code and see how they deal with it. How easily can they understand it ? How easily can they write it ? Debug it ? They are most of the time a fantastic indicator of the cognitive load a feature will add in prod. Because of course a feature doesn't exist in a vacuum, it's always in a more complex context. So what's easy to understand for a student…
That is fine if you want to optimize language for "fresh students". That is not representative how brain process stuff after getting even some experience.
Speaking as someone who has written Python code almost every day for the last 16 years of my life: I'm not happy about this. Some of this stuff seems to me like it's opening the doors for some antipatterns that I'm consistently frustrated about when working with Perl code (that I didn't write myself). I had always been quite happy about the fact that Python didn't have language features to blur the lines between what…
Many languages don't distinguish between statements and expressions—in some languages, this is because everything is an expression! I'm most familiar with these kinds of languages. I'm not familiar much with Python, beyond a little I wrote in my linear algebra class. How much does the statement/literal distinction matter to readability? What does that do for the language?
There's a bunch of changes in the official "what's new" doc that I think are more interesting:
https://docs.python.org/3.8/whatsnew/3.8.html
* Run-time audit hooks, to see if your modules are making network requests, etc.
https://www.python.org/dev/peps/pep-0578/
https://tirkarthi.github.io/programming/2019/05/23/pep-578-o...
* multiprocessing SharedMemory for fast data sharing between processes
https://docs.python.org/3.8/library/multiprocessing.shared_m...
* Duck-typing for the static annotation checkers
https://www.python.org/dev/peps/pep-0544/
* Literal checking for the static annotation checkers. ie: It's not enough to check that you're passing a string for the mode in open(), you want to check that it's 'r' or 'w', etc.
https://www.python.org/dev/peps/pep-0586/
* The compiler now produces a SyntaxWarning when identity checks (is and is not) are used with certain types of literals (e.g. strings, ints). These can often work by accident in CPython, but are not guaranteed by the language spec. The warning advises users to use equality tests (== and !=) instead.
* A bunch of speed and memory optimizations:
- "Sped-up field lookups in collections.namedtuple(). They are now more than two times faster, making them the fastest form of instance variable lookup in Python."
- "The list constructor does not overallocate the internal item buffer if the input iterable has a known length (the input implements __len__). This makes the created list 12% smaller on average."
- "Doubled the speed of class variable writes."
- "Reduced an overhead of converting arguments passed to many builtin functions and methods. This sped up calling some simple builtin functions and methods up to 20–50%."
Python looks more and more foreign with each release. I'm not sure what happened after 3.3 but it seems like the whole philosophy of "pythonic", emphasizing simplicity, readability and "only one straightforward way to do it" is rapidly disappearing.
“I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the n…
Yep, I entered the Python world with v2. I eventually reconciled myself to 2.7, and have only recently and begrudgingly embraced 3. Being over 35, I must be incredibly open minded on these things.
Python looks more and more foreign with each release. I'm not sure what happened after 3.3 but it seems like the whole philosophy of "pythonic", emphasizing simplicity, readability and "only one straightforward way to do it" is rapidly disappearing.
I'm working on a language with a focus on simplicity and "only one way to do it": https://vlang.io The development has been going quite well: https://github.com/vlang/v/blob/master/CHANGELOG.md
Earlier quoted context omitted.
> It's not clear to me what it does just from reading it How isn't it entirely obvious? := is the assignment operator in tons of languages, and there's no reason not to have assignment be an expression (as is also the case in many languages).
> := is the assignment operator in tons of languages It is? Which ones? Other than Go, I can not think of a single language that has ":=" as an operator. Java does not, JavaScript does not, C/C++ do not, Ruby does not, I don't think PHP does, Erlang/Elixir do not, Rust does not... (I could be wrong on these, but I've personally never seen it in any of these languages and I can't find any mention of it in these langua…
At least 18 prominent languages use that syntax.
I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. Why should this be true for every language? Certainly we should have languages like this. But not every language needs to be like this.
Earlier quoted context omitted.
So := is 'gets a truthy value from'? That seems to work. > For what it's worth, "x = y()" is one of the harder things for new programmers to translate to English in the first place Right... so why have we added more complexity to something known to be very complicated?
we added new syntax for a code pattern that has inherent complexity which can't be reduced.