4 ms·

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but

by dkarl 4y ago

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy. The language would be statically type-checked, with optional type annotations and magic support for duck typing (magic because I don't know how that would work.) The type system would prioritize helpful, legible feedback, and it would not support powerful type-level programming, to keep the ecosystem accessible to beginners. It would still have a REPL, but not everything allowed in the REPL would be allowed when running code from a file. There would be a strong module system that deterred libraries from relying on global state. Support for at least one fairly accessible concurrency paradigm would be built in. I suspect that the error system would be exception-based, so that beginners and busy people could write happy path code without being nagged to handle error values and without worrying that errors could be invisibly suppressed, but there might be another way.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
jezzamon 4y ago
I think free mutability and not really needing to know about types are two things that make the language easier for beginners. If someone who's not familiar with programming runs into an error like "why can't I change the value of X" that might take them multiple hours to figure out, or they may never figure it out. Even if the error message is clear, total beginners often just don't know how to read them and use them. They provide longer term advantages once your program becomes larger but the short term advantages are more important as a scripting language imo
- dkarl 4y ago
  The type system I want would just be a type system that tells you that your code will fail, and why. Pretty much the same errors you get at runtime. Hence the need for my hypothetical type system to handle duck typing. I don't think mutability by default is necessary for beginners. They just need obvious ways of getting things done. There are two places beginners use mutability a lot. The first is gradual transformation of a value: line = "The best of times, the worst " line = line.trim() line = line[:line.find(' ')] This is easily handled by using a different name for each value. The second is in loops: word_count = 0 for line in lines(): word_count += num_words(line) I think in a lot of cases beginners will have no problem using a map or list comprehension idiom if they've seen examples: word_counts = [num_words(line) for line in lines] # or word_counts = map(num_words, line) word_count = sum(word_counts) But for cases where the immutable idiom is a bit tricker (like a complicated fold) they could use a mutable variable using the mutability marker I mentioned. Let's make the mutability marker @ since it tells you that the value can be different "at" different times, and let's require it everywhere the variable is used: word_count @= 0 for line in lines(): word_count @= word_count + num_words(line) Voila. The important thing is not to mandate immutability, but to ensure that mutability is the exception, and immutability the norm. That ensures that library writers won't assume mutability and rely on it (cough SQLAlchemy cough), and the language will provide good ergonomic support for immutability. It's a common claim that immutability only pays off in larger programs, but I think the mental tax of mutability starts pretty immediately for beginners. We're just used to it. Consider this example: dog_name = Name(first='Rusty', last='Licks') dog1.name = favorite_name dog_name.last = 'Barksalot' dog2.name = favorite_name print(dog1.name) # It's not Rusty Licks! Beginners shouldn't have to constantly wrestle with the difference between value semantics and reference semantics! This is the simplest possible example, and it's already a mind-bender for beginners. In slightly more complicated guises, it even trips up professionals programmers. I inherited a Jupyter notebook from a poor data scientist who printed out the same expression over and over again in different places in the notebook trying to pinpoint where and why the value changed. (Lesson learned: never try to use application code in a data science calculation... lol.) Reserving mutability for special cases protects beginners from wrestling with strange behavior from mistakes like these.
lupex 4y ago
You should check out Julia (https://julialang.org/ https://julialang.org/), that's very close to what you describe.
- cjalmeida 4y ago
  You beat me to it! Julia is both dynamic and fast. It doesn’t solve all issues but uniquely solves the problem of needing 2 languages if you want flexibility and performance.
cornholio 4y ago
Exception error handling - and their extensive use in the standard library -is the fundamental design mistake that prevented Python becoming a substantial programing language. Coupled with the dynamic typing and mutability by default, it guarantees Python programs won't scale, relegating the language to the role of a scratchpad for rough drafts and one off scripts, a toy beginner's language.
- Daishiman 4y ago
  I have no idea why you say that it's a scratchpad or a toy language consdering that far more production lines of code are getting written in Python nowadays than practically any other language with the possible exception of Java.
  - cornholio 4y ago
    But that's the same with Excel: massive usage for throwaway projects with loose or non-existing requirements or performance bounds that end-up in production. Python is widely used, but not for substantial programming in large projects - say, projects over 100 kloc. Python hit the "quick and dirty" sweet spot of programming.
    - Daishiman 4y ago
      This is absolutely not true. I’ve made my living working with Python and there’s an astounding amount of large Python codebases. Onstage and YouTube alone have millions of lines of code. Hedge funds and fintechs base their entire data processing workflows around Python batch jobs. Django is about as popular as Rails and powers millions of websites and backends. None of those applications are toys. I have no idea where your misperception is coming from.
      - cornholio 4y ago
        I guess I'm more than a little prejudiced from trying to maintain all sorts of CI tools, web applications and other largeish programs somebody initially hacked in Python in an afternoon and which grew to become "vital infrastructure". The lack of typing bytes you hard and the optional typing that has been shoehorned into the language is irrelevant in practice. All sorts of problems would simply have not existed if the proper language was used from the beginning, as opposed to the one where anyone can hack most easily.
deleted 4y ago
[deleted]
Yoric 4y ago
Aren't you kinda describing OCaml?
noirscape 4y ago
This is pretty much what nim is btw. Very fun language in my experience.
- jasfi 4y ago
  Nim is fun, but it needs to be more popular.
Too 4y ago
Statically typed with duck typing is called structural typing. (As opposed to nominal typing, with inheritance hierarchies). It’s already what you get with python and mypy. Using typing.Protocol or Unions.

by dkarl 4y ago

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

jezzamon 4y ago

I think free mutability and not really needing to know about types are two things that make the language easier for beginners. If someone who's not familiar with programming runs into an error like "why can't I change the value of X" that might take them multiple hours to figure out, or they may never figure it out. Even if the error message is clear, total beginners often just don't know how to read them and use them. They provide longer term advantages once your program becomes larger but the short term advantages are more important as a scripting language imo

dkarl 4y ago
The type system I want would just be a type system that tells you that your code will fail, and why. Pretty much the same errors you get at runtime. Hence the need for my hypothetical type system to handle duck typing. I don't think mutability by default is necessary for beginners. They just need obvious ways of getting things done. There are two places beginners use mutability a lot. The first is gradual transformation of a value: line = "The best of times, the worst " line = line.trim() line = line[:line.find(' ')] This is easily handled by using a different name for each value. The second is in loops: word_count = 0 for line in lines(): word_count += num_words(line) I think in a lot of cases beginners will have no problem using a map or list comprehension idiom if they've seen examples: word_counts = [num_words(line) for line in lines] # or word_counts = map(num_words, line) word_count = sum(word_counts) But for cases where the immutable idiom is a bit tricker (like a complicated fold) they could use a mutable variable using the mutability marker I mentioned. Let's make the mutability marker @ since it tells you that the value can be different "at" different times, and let's require it everywhere the variable is used: word_count @= 0 for line in lines(): word_count @= word_count + num_words(line) Voila. The important thing is not to mandate immutability, but to ensure that mutability is the exception, and immutability the norm. That ensures that library writers won't assume mutability and rely on it (cough SQLAlchemy cough), and the language will provide good ergonomic support for immutability. It's a common claim that immutability only pays off in larger programs, but I think the mental tax of mutability starts pretty immediately for beginners. We're just used to it. Consider this example: dog_name = Name(first='Rusty', last='Licks') dog1.name = favorite_name dog_name.last = 'Barksalot' dog2.name = favorite_name print(dog1.name) # It's not Rusty Licks! Beginners shouldn't have to constantly wrestle with the difference between value semantics and reference semantics! This is the simplest possible example, and it's already a mind-bender for beginners. In slightly more complicated guises, it even trips up professionals programmers. I inherited a Jupyter notebook from a poor data scientist who printed out the same expression over and over again in different places in the notebook trying to pinpoint where and why the value changed. (Lesson learned: never try to use application code in a data science calculation... lol.) Reserving mutability for special cases protects beginners from wrestling with strange behavior from mistakes like these.

lupex 4y ago

You should check out Julia (https://julialang.org/ https://julialang.org/), that's very close to what you describe.

cjalmeida 4y ago
You beat me to it! Julia is both dynamic and fast. It doesn’t solve all issues but uniquely solves the problem of needing 2 languages if you want flexibility and performance.

cornholio 4y ago

Exception error handling - and their extensive use in the standard library -is the fundamental design mistake that prevented Python becoming a substantial programing language. Coupled with the dynamic typing and mutability by default, it guarantees Python programs won't scale, relegating the language to the role of a scratchpad for rough drafts and one off scripts, a toy beginner's language.

Daishiman 4y ago
I have no idea why you say that it's a scratchpad or a toy language consdering that far more production lines of code are getting written in Python nowadays than practically any other language with the possible exception of Java.
- cornholio 4y ago
  But that's the same with Excel: massive usage for throwaway projects with loose or non-existing requirements or performance bounds that end-up in production. Python is widely used, but not for substantial programming in large projects - say, projects over 100 kloc. Python hit the "quick and dirty" sweet spot of programming.
  - Daishiman 4y ago
    This is absolutely not true. I’ve made my living working with Python and there’s an astounding amount of large Python codebases. Onstage and YouTube alone have millions of lines of code. Hedge funds and fintechs base their entire data processing workflows around Python batch jobs. Django is about as popular as Rails and powers millions of websites and backends. None of those applications are toys. I have no idea where your misperception is coming from.
    - cornholio 4y ago
      I guess I'm more than a little prejudiced from trying to maintain all sorts of CI tools, web applications and other largeish programs somebody initially hacked in Python in an afternoon and which grew to become "vital infrastructure". The lack of typing bytes you hard and the optional typing that has been shoehorned into the language is irrelevant in practice. All sorts of problems would simply have not existed if the proper language was used from the beginning, as opposed to the one where anyone can hack most easily.

deleted 4y ago

[deleted]

Yoric 4y ago

Aren't you kinda describing OCaml?

noirscape 4y ago

This is pretty much what nim is btw. Very fun language in my experience.

jasfi 4y ago
Nim is fun, but it needs to be more popular.

Too 4y ago

Statically typed with duck typing is called structural typing. (As opposed to nominal typing, with inheritance hierarchies). It’s already what you get with python and mypy. Using typing.Protocol or Unions.