7 ms·

The ideal solution is for someone to design a new programming language that is as similar to Python as possible without requiring a global lock. Rarely used fea

The ideal solution is for someone to design a new programming language that is as similar to Python as possible without requiring a global lock. Rarely used features that make it hard to parallelize Python would be dropped. STM might be built into the language instead of being hacked into one implementation, etc.

jrs95 9y ago
Perl 6 doesn't have a GIL, and already has a sane concurrency model, but the lack of libraries and community interest seems to make that pretty much a non-starter.
- DougN7 9y ago
  Well, that and Perl has to be one of the most unreadable languages out there ;)
  - vgy7ujm 9y ago
    Only if you don't know Perl... To me Python is more unreadable ;)
    - bsder 9y ago
      Only if you know ALL of Perl. I used to carry around a Perl program of my own on a printout to take to VLSI interviews. That way when I got the "Do you know Perl?" question I could bring it out and force the interviewer into MY stupid subset of Perl rather than being stuck in his stupid subset of Perl. That's not a compliment to the language.
      - vgy7ujm 9y ago
        Is Python really any different or is it just wishful thinking? Why do I see Python programs that look like a weird mix of Lisp and Java? Surely it is because even with what Python enforce, there are many many ways to produce unclear code that really don't even has to do with the language used. And why did my employer see the need for the comprehensive Python style guidelines manual... I guess Python bit just as hard as Perl. Also now that Python is used more by newbies and non-programmers that is where more of the bad code end up (aka Perl late 90s, still pollutes the internet). The quality of Perl frameworks, libs, example code etc is actually increasing and getting easier to find.
        bsder 9y ago
        > Is Python really any different or is it just wishful thinking? I'll stick my neck out and say that personally I feel that Python is actually better in this regard. Perl pissed me off so much that I left Perl at the height of its popularity. I probably had least 5 years(probably closer to 10+, but my memory of dates is fuzzy--pretty sure I never used Perl 3, though ...) years of professional use of Perl under my belt at that point. I still migrated to Python. That's a pretty big indictment when someone is willing to go back to being a n00b rather than continue to put up with continuing grief. > Why do I see Python programs that look like a weird mix of Lisp and Java? Surely it is because even with what Python enforce, there are many many ways to produce unclear code that really don't even has to do with the language used. The difference, from my experience, is that newbies in Python don't write code that A) other newbies can't understand and B) requires excessive mental effort from experienced folks to understand. Neither of those were true in my experience for Perl. A newb in Perl would very quickly trip something that would boggle even your local Perl expert. I remember when I was a beginner and posted a 15 line program to comp.lang.perl and watched several of the experts actually wondering what the correct interpretation of the grammar was. I don't think I ever managed to cause something like that in Python. Obviously, I threw that program out post haste. Sure, people can make amazingly complicated things with generators, decorators, etc once they get the hang of the language. However, newbies don't normally do this in Python. As you point out, they normally write it like Java (for better and worse). In Perl, newbies immediately had to grapple with things like list vs scalar context and god help you if you tripped over a corner case (although, to be fair, God, in the form Randall Schwartz, WOULD quite often help you if you asked on comp.lang.perl ...) > And why did my employer see the need for the comprehensive Python style guidelines manual... I guess Python bit just as hard as Perl. I would personally expect that any company writing a very large quantity of code would produce a style guide for any language they use. > The quality of Perl frameworks, libs, example code etc is actually increasing and getting easier to find. That's actually really cool.
    - deleted 9y ago
      [deleted]
- smitherfield 9y ago
  It’s also still dog-slow for the (Perl 5 / scripting-language) common case, which makes whatever theoretical performance improvements to its semantics a bit academic at this point: https://news.ycombinator.com/item?id=15004977 https://news.ycombinator.com/item?id=15004977
  - ash_gti 9y ago
    If you use master instead of the current release that example goes from about two mins to just under one minute for my machine. Also, if you use .subst(‘y’, ’n’) instead of a regex it runs in under 9 seconds locally. Thats still much slower than perl 5 (which locally takes less than half a second) but they’re making great strides at improving performance.
    - ash_gti 9y ago
      So, doing another simple change to my code brought the runtime down to a few ms. Doing: time yes | head -n1000000 | perl6 --profile -e 'for $*IN.readchars { .subst("y", "n").print }’ > /dev/null says it took 86 ms. Which is pretty decent I’d say.
      - smitherfield 9y ago
        Sure, but that's still kinda defeating the purpose of providing functionality that's easy to remember and type. Might as well do time echo "#include <stdio.h> main(n){char*b,*s=n=0;getdelim(&s,&n,-1,stdin);for(b=s;*s;++s)*s=='y'&&*s='n';puts(b);}">s.c|yes|head -n1000000|tcc -w -run s.c>/dev/null real 0m0.028s user 0m0.023s sys 0m0.019s 28 milliseconds!
        ash_gti 9y ago
        I was mostly just pointing out that perl6 might not be as slow as the comment you linked suggests. There seems to be something about using `perl6 -pe` that caused it to be slower than you’d expected. However, using a different approach its reasonably fast, or at least it appears reasonably comparable to the perl 5 example that was provided. Hopefully more edge cases will be discovered and fixed as the implementation matures as well.
adambyrtek 9y ago
Fork with no backward compatibility is hardly "the ideal solution". Healthy ecosystem is crucial for sustainability of any programming language.
- deleted 9y ago
  [deleted]
mFixman 9y ago
What are these features?
rburhum 9y ago
So basically recreate an entire language and library ecosystem because there is one feature that is less than ideal? I hope you realize why a better approach may be to reengineer that one component...
- dTal 9y ago
  Python has many less-than-ideal features. Do you think we finally got it right, that we will use Python forever, and that the library work of the past decade or so is irreplaceable? "Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble?" -- Alan Perlis
  - ehsankia 9y ago
    Just to go from py2 to py3, which was relatively a MUCH smaller change than a whole new language, it's taken a decade and it's still far from over. I don't see how a whole new language would be any better. And it's not like there's a lack of new languages popping up left and right. There's a reason most of them just die out. It's insanely hard to gain critical mass unless you have a huge backer, like a whole organization or company using the language.
  - rburhum 9y ago
    At the end of the day, the purpose of why we write software as software engineers is to solve real-world problems, not to have a perfect beautiful language. What you are describing is equivalent to doing an amputation when all you need is antibiotics. There are several things I personally _hate_ about python, but there is a cost-benefit that comes from engineering new things. What new problems are we going to be able to solve by using a new language? If the answer is clear (e.g. imperative programming vs declarative/functional programming let you solve different kind of problems) then it makes sense to do. If certain constructs enable you to completely avoid a recurring mistake (e.g. garbage collection), then it may make sense. But this?!?!? No man, you don't need a new language to fix this.
- digitalzombie 9y ago
  > I hope you realize why a better approach may be to reengineer that one component... Top comment is proposing basically Erlang or an actor model. As for immutability... well they have to either have it or manage mutable state. That task of engineering is not something to scoff at and I think building a new language or using an existing language with those ability would help. Erlang is not a number crunching language. But there are others such as Pony.
mrsteveman1 9y ago
> language that is as similar to Python as possible without requiring a global lock Something like Pony[0] or Nim[1]? I'm not very familiar with either one, but Nim says it is inspired by Python, and on the surface Pony appears to be as well. [0] https://bluishcoder.co.nz/2015/11/04/a-quick-look-at-pony.html https://bluishcoder.co.nz/2015/11/04/a-quick-look-at-pony.ht... [1] https://nim-lang.org/features.html https://nim-lang.org/features.html
nine_k 9y ago
If you want other multiplatform, open-source, highly parallel languages with nice syntax and quick turnaround, we already have a few, like Elixir, Racket, or, well, even ES6. Much of the Python's appeal is in its huge, colossal, powerful ecosystem, with modules for everything, and things like numpy or tensorflow using it as the high-level interface language. Not breaking this is probably more important for success than efficient in-process data sharing. (Yes, process pools, queues, and a shared DB cover most of my cases.)
- rlander 9y ago
  I don't mean to be pedantic, but please explain how ES6 is a "highly parallel" language.
  - nine_k 9y ago
    You have web workers, generators, all the async stuff, futures and promises — plenty enough from the language perspective. Maybe node.js does not happen to be multi-threaded, but it's not about the language.
    - jerf 9y ago
      That's all true about Python, too, and it's been true since before Node existed. If Node were adequate, Python would be adequate too. In fact, other than "run lots of Javascript", I'm not sure I can name a single thing Node did before Python.
    - heavenlyblue 9y ago
      By the same logic Python is multithreading-ready as well, since it's only a matter of it's major implementation why it doesn't support multithreading.
      - nine_k 9y ago
        > By the same logic Python is multithreading-ready as well, since it's only a matter of it's major implementation why it doesn't support multithreading. How web workers aren't threads? Browsers are more widely deployed than Node, even with the same V8 engine.
ryanjl 9y ago
Jython and Iron Python lack the GIL. It's just an implementation detail of the underlying VM. There's nothing in the language itself which requires a GIL.
- fijal 9y ago
  C API... You can argue it's not a part of the language, but PyPy was forced to support it at the end
  - xenadu02 9y ago
    IronPython interoperates with a whole host of C and C++ code. I'm not sure why this would matter? The initial implementation may need to assume single-threaded C interface support and take a global lock but it wouldn't be a stretch to have these things declare they are multithread aware and relax that restriction. Forgive me but most of these objections seem like post-hoc rationalizations. The first step is deciding to support a GIL-less multithreaded mode. After that, solve the problems one step at a time. It is amazing how many times accomplishing "magic" boils down to: 1. Decide we're going to solve this problem. 2. Iterate toward the solution in manageable steps. #1 is by far the most difficult aspect :)
    - ryanjl 9y ago
      Jython uses the JNI and IronPython does it through C++/CLI, neither of them support the CPython extension interface, meaning the C modules aren't compatible. Because of this, Jython and IronPython inherit the interface properties of their respective VMs and they can remain thread safe without the GIL.
- dom0 9y ago
  > It's just an implementation detail of the underlying VM. Python itself is just an implementation detail of the underlying VM.
NewEntryHN 9y ago
What makes it so hard for CPython to drop the GIL is keeping backward compatibility for the CPython C API. If you're willing to break the API there's no need for a new language.
weberc2 9y ago
If we're talking about creating an entirely new language, I don't think the "ideal" is Python with a few tweaks; it's going to be radically different. The point is, you have to draw the line somewhere, and if you're going to build an entirely new language, you should probably address as many problems as you can; few will switch to an incrementally better Python (unless you can give strong compatibility guarantees, in which case it's arguably not a new language).
freyir 9y ago
We could call it Python 3.

jrs95 9y ago

Perl 6 doesn't have a GIL, and already has a sane concurrency model, but the lack of libraries and community interest seems to make that pretty much a non-starter.

DougN7 9y ago
Well, that and Perl has to be one of the most unreadable languages out there ;)
- vgy7ujm 9y ago
  Only if you don't know Perl... To me Python is more unreadable ;)
  - bsder 9y ago
    Only if you know ALL of Perl. I used to carry around a Perl program of my own on a printout to take to VLSI interviews. That way when I got the "Do you know Perl?" question I could bring it out and force the interviewer into MY stupid subset of Perl rather than being stuck in his stupid subset of Perl. That's not a compliment to the language.
    - vgy7ujm 9y ago
      Is Python really any different or is it just wishful thinking? Why do I see Python programs that look like a weird mix of Lisp and Java? Surely it is because even with what Python enforce, there are many many ways to produce unclear code that really don't even has to do with the language used. And why did my employer see the need for the comprehensive Python style guidelines manual... I guess Python bit just as hard as Perl. Also now that Python is used more by newbies and non-programmers that is where more of the bad code end up (aka Perl late 90s, still pollutes the internet). The quality of Perl frameworks, libs, example code etc is actually increasing and getting easier to find.
      - bsder 9y ago
        > Is Python really any different or is it just wishful thinking? I'll stick my neck out and say that personally I feel that Python is actually better in this regard. Perl pissed me off so much that I left Perl at the height of its popularity. I probably had least 5 years(probably closer to 10+, but my memory of dates is fuzzy--pretty sure I never used Perl 3, though ...) years of professional use of Perl under my belt at that point. I still migrated to Python. That's a pretty big indictment when someone is willing to go back to being a n00b rather than continue to put up with continuing grief. > Why do I see Python programs that look like a weird mix of Lisp and Java? Surely it is because even with what Python enforce, there are many many ways to produce unclear code that really don't even has to do with the language used. The difference, from my experience, is that newbies in Python don't write code that A) other newbies can't understand and B) requires excessive mental effort from experienced folks to understand. Neither of those were true in my experience for Perl. A newb in Perl would very quickly trip something that would boggle even your local Perl expert. I remember when I was a beginner and posted a 15 line program to comp.lang.perl and watched several of the experts actually wondering what the correct interpretation of the grammar was. I don't think I ever managed to cause something like that in Python. Obviously, I threw that program out post haste. Sure, people can make amazingly complicated things with generators, decorators, etc once they get the hang of the language. However, newbies don't normally do this in Python. As you point out, they normally write it like Java (for better and worse). In Perl, newbies immediately had to grapple with things like list vs scalar context and god help you if you tripped over a corner case (although, to be fair, God, in the form Randall Schwartz, WOULD quite often help you if you asked on comp.lang.perl ...) > And why did my employer see the need for the comprehensive Python style guidelines manual... I guess Python bit just as hard as Perl. I would personally expect that any company writing a very large quantity of code would produce a style guide for any language they use. > The quality of Perl frameworks, libs, example code etc is actually increasing and getting easier to find. That's actually really cool.
  - deleted 9y ago
    [deleted]
smitherfield 9y ago
It’s also still dog-slow for the (Perl 5 / scripting-language) common case, which makes whatever theoretical performance improvements to its semantics a bit academic at this point: https://news.ycombinator.com/item?id=15004977 https://news.ycombinator.com/item?id=15004977
- ash_gti 9y ago
  If you use master instead of the current release that example goes from about two mins to just under one minute for my machine. Also, if you use .subst(‘y’, ’n’) instead of a regex it runs in under 9 seconds locally. Thats still much slower than perl 5 (which locally takes less than half a second) but they’re making great strides at improving performance.
  - ash_gti 9y ago
    So, doing another simple change to my code brought the runtime down to a few ms. Doing: time yes | head -n1000000 | perl6 --profile -e 'for $*IN.readchars { .subst("y", "n").print }’ > /dev/null says it took 86 ms. Which is pretty decent I’d say.
    - smitherfield 9y ago
      Sure, but that's still kinda defeating the purpose of providing functionality that's easy to remember and type. Might as well do time echo "#include <stdio.h> main(n){char*b,*s=n=0;getdelim(&s,&n,-1,stdin);for(b=s;*s;++s)*s=='y'&&*s='n';puts(b);}">s.c|yes|head -n1000000|tcc -w -run s.c>/dev/null real 0m0.028s user 0m0.023s sys 0m0.019s 28 milliseconds!
      - ash_gti 9y ago
        I was mostly just pointing out that perl6 might not be as slow as the comment you linked suggests. There seems to be something about using `perl6 -pe` that caused it to be slower than you’d expected. However, using a different approach its reasonably fast, or at least it appears reasonably comparable to the perl 5 example that was provided. Hopefully more edge cases will be discovered and fixed as the implementation matures as well.

adambyrtek 9y ago

Fork with no backward compatibility is hardly "the ideal solution". Healthy ecosystem is crucial for sustainability of any programming language.

deleted 9y ago
[deleted]

mFixman 9y ago

What are these features?

rburhum 9y ago

So basically recreate an entire language and library ecosystem because there is one feature that is less than ideal? I hope you realize why a better approach may be to reengineer that one component...

dTal 9y ago
Python has many less-than-ideal features. Do you think we finally got it right, that we will use Python forever, and that the library work of the past decade or so is irreplaceable? "Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble?" -- Alan Perlis
- ehsankia 9y ago
  Just to go from py2 to py3, which was relatively a MUCH smaller change than a whole new language, it's taken a decade and it's still far from over. I don't see how a whole new language would be any better. And it's not like there's a lack of new languages popping up left and right. There's a reason most of them just die out. It's insanely hard to gain critical mass unless you have a huge backer, like a whole organization or company using the language.
- rburhum 9y ago
  At the end of the day, the purpose of why we write software as software engineers is to solve real-world problems, not to have a perfect beautiful language. What you are describing is equivalent to doing an amputation when all you need is antibiotics. There are several things I personally _hate_ about python, but there is a cost-benefit that comes from engineering new things. What new problems are we going to be able to solve by using a new language? If the answer is clear (e.g. imperative programming vs declarative/functional programming let you solve different kind of problems) then it makes sense to do. If certain constructs enable you to completely avoid a recurring mistake (e.g. garbage collection), then it may make sense. But this?!?!? No man, you don't need a new language to fix this.
digitalzombie 9y ago
> I hope you realize why a better approach may be to reengineer that one component... Top comment is proposing basically Erlang or an actor model. As for immutability... well they have to either have it or manage mutable state. That task of engineering is not something to scoff at and I think building a new language or using an existing language with those ability would help. Erlang is not a number crunching language. But there are others such as Pony.

mrsteveman1 9y ago

> language that is as similar to Python as possible without requiring a global lock Something like Pony[0] or Nim[1]? I'm not very familiar with either one, but Nim says it is inspired by Python, and on the surface Pony appears to be as well. [0] https://bluishcoder.co.nz/2015/11/04/a-quick-look-at-pony.html https://bluishcoder.co.nz/2015/11/04/a-quick-look-at-pony.ht... [1] https://nim-lang.org/features.html https://nim-lang.org/features.html

nine_k 9y ago

If you want other multiplatform, open-source, highly parallel languages with nice syntax and quick turnaround, we already have a few, like Elixir, Racket, or, well, even ES6. Much of the Python's appeal is in its huge, colossal, powerful ecosystem, with modules for everything, and things like numpy or tensorflow using it as the high-level interface language. Not breaking this is probably more important for success than efficient in-process data sharing. (Yes, process pools, queues, and a shared DB cover most of my cases.)

rlander 9y ago
I don't mean to be pedantic, but please explain how ES6 is a "highly parallel" language.
- nine_k 9y ago
  You have web workers, generators, all the async stuff, futures and promises — plenty enough from the language perspective. Maybe node.js does not happen to be multi-threaded, but it's not about the language.
  - jerf 9y ago
    That's all true about Python, too, and it's been true since before Node existed. If Node were adequate, Python would be adequate too. In fact, other than "run lots of Javascript", I'm not sure I can name a single thing Node did before Python.
  - heavenlyblue 9y ago
    By the same logic Python is multithreading-ready as well, since it's only a matter of it's major implementation why it doesn't support multithreading.
    - nine_k 9y ago
      > By the same logic Python is multithreading-ready as well, since it's only a matter of it's major implementation why it doesn't support multithreading. How web workers aren't threads? Browsers are more widely deployed than Node, even with the same V8 engine.

ryanjl 9y ago

Jython and Iron Python lack the GIL. It's just an implementation detail of the underlying VM. There's nothing in the language itself which requires a GIL.

fijal 9y ago
C API... You can argue it's not a part of the language, but PyPy was forced to support it at the end
- xenadu02 9y ago
  IronPython interoperates with a whole host of C and C++ code. I'm not sure why this would matter? The initial implementation may need to assume single-threaded C interface support and take a global lock but it wouldn't be a stretch to have these things declare they are multithread aware and relax that restriction. Forgive me but most of these objections seem like post-hoc rationalizations. The first step is deciding to support a GIL-less multithreaded mode. After that, solve the problems one step at a time. It is amazing how many times accomplishing "magic" boils down to: 1. Decide we're going to solve this problem. 2. Iterate toward the solution in manageable steps. #1 is by far the most difficult aspect :)
  - ryanjl 9y ago
    Jython uses the JNI and IronPython does it through C++/CLI, neither of them support the CPython extension interface, meaning the C modules aren't compatible. Because of this, Jython and IronPython inherit the interface properties of their respective VMs and they can remain thread safe without the GIL.
dom0 9y ago
> It's just an implementation detail of the underlying VM. Python itself is just an implementation detail of the underlying VM.

NewEntryHN 9y ago

What makes it so hard for CPython to drop the GIL is keeping backward compatibility for the CPython C API. If you're willing to break the API there's no need for a new language.

weberc2 9y ago

If we're talking about creating an entirely new language, I don't think the "ideal" is Python with a few tweaks; it's going to be radically different. The point is, you have to draw the line somewhere, and if you're going to build an entirely new language, you should probably address as many problems as you can; few will switch to an incrementally better Python (unless you can give strong compatibility guarantees, in which case it's arguably not a new language).

freyir 9y ago

We could call it Python 3.