5 ms·

New languages need to have a distinct benefit in order to be enough encouraging for new people to learn it over picking something which is already well establis

by belorn 6y ago

New languages need to have a distinct benefit in order to be enough encouraging for new people to learn it over picking something which is already well established. In python case it was something that replaced shell language for data administrators, and many of the quite complex languages used by data scientists. The one big selling point a future language could have would be inherent parallelization that uses all the 32+ cores of the developers machine, but that are as beginner-friendly as python. Such language does not exist. A dynamic, easy to use, and built from the ground up to always utilize all cores all the time without demanding that the programmer are handling side effects.

fulafel 6y ago
Using a lot of execution resources is not a direct benefit from the user POV. Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases. Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).
valenterry 6y ago
Such a language _can not_ exist, because it stops fulfilling the "beginner-friendly" criteria. As soon as you deal with concurrency, things either get hard to learn or get super messy. Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.
- jerf 6y ago
  Go minus concurrency actually is a good candidate for a solid beginner language. It has quirks, but no more so than any other choice, and fewer than most, for a beginner. However, in my experience, keeping beginners away from concurrency is difficult. A lot of Go tutorials make a hard burn for it, since it's the big feature if you're already a programmer. And I've gotten (internet) yelled at for trying to suggest that concurrency is something beginners should leave until much later. The other problem is a lot of what beginners may want to pivot into after they are done writing their "is the number higher or lower?" first terminal app isn't great for them. It's not a great game/graphical language. GUIs mostly suck. Web is awfully hard to get into nowadays, even if you try to help them narrow their focus.
- enriquto 6y ago
  > As soon as you deal with concurrency, things either get hard to learn or get super messy. Strong disagree. There is a language where concurrency is trivial and beginner-friendly. It is called POSIX shell with standard GNU tools. To run several independent commands in parallel, you print them and pipe to GNU parallel. If your concurrency has an arbitrary tree of dependencies, you print it in the form target : dependencies ; command and then run GNU make. Languages that make this simple stuff complicated, like Python, do so by choice, not by need.
  - valenterry 6y ago
    There is a reason why no one uses shell for anything more complicated. E.g. start two long-running commands and then close the one of them depending on some later output of the other one or vice versa. If that's not already complicated enough, we can easily add things like, execute a command A and then another other commands (B, C, D) and, only once all these are finished, run a cleanup command D. But run D always, no matter wether B, C, D fail (think of closing a database connection). And now treat this whole thing as yet another command E, that itself can be used in the same place as e.g. B or C or D before (= composition). Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency".
    - enriquto 6y ago
      > Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency". Yet somehow beginners in my lab cannot get their hands off the shell and we have to politely guide them to other languages... But still, I insist that parallelism in the shell is very easy. How do you do that in Python, for example? # convert images from jpg to png, in parallel for i in *.jpg; do echo convert $i ${i/jpg/png} done | parallel Regarding your "complicated" use cases, I must confess that I don't understand them nor their relevance. But for simple people like me without fancy needs, the simple concurrency offered by GNU parallel and GNU make is good enough.
      - 6y ago
- jnxx 6y ago
  > As soon as you deal with concurrency, things either get hard to learn or get super messy. I'd argue that Clojure, while perhaps not the easiest language for beginners in all aspects, is both minimalistic and really fantastic for doing clean and safe concurrency.
andi999 6y ago
The program should leave one core for the OS.
dehrmann 6y ago
> replaced shell I'd argue it replaced Perl.
- visarga 6y ago
  Are you saying it was a replacement for a two year old language? Perl - December 1987 Python - December 1989
  - dehrmann 6y ago
    Yes. You need to remember than neither language was relevant yet; I'd draw that line around Perl 5 and Python 2. Don't forget that Perl 6 spent two decades in development hell. Not that the TIOBE index is perfect, but you can see what happened since 2001. Perl used to be a lot more popular for early dynamic websites and systems glue, but by 2011, Python had gotten a lot more popular in those roles. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
    - pjmlp 6y ago
      Zope was winning over mod_perl back on those days.
pjmlp 6y ago
Chapel and Julia.
N1H1L 6y ago
dask in my opinion comes decently close to better parallel computation in Python, and being beginner friendly. It is immensely compatible with numpy and pandas, and can abstract away a lot of the parallel computation complexities which makes getting up to speed easier. However, their scheduler really needs speed ups, and they do run into weird data handling bottlenecks in my experience.

by belorn 6y ago

fulafel 6y ago

Using a lot of execution resources is not a direct benefit from the user POV. Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases. Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).

valenterry 6y ago

Such a language _can not_ exist, because it stops fulfilling the "beginner-friendly" criteria. As soon as you deal with concurrency, things either get hard to learn or get super messy. Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.

jerf 6y ago
Go minus concurrency actually is a good candidate for a solid beginner language. It has quirks, but no more so than any other choice, and fewer than most, for a beginner. However, in my experience, keeping beginners away from concurrency is difficult. A lot of Go tutorials make a hard burn for it, since it's the big feature if you're already a programmer. And I've gotten (internet) yelled at for trying to suggest that concurrency is something beginners should leave until much later. The other problem is a lot of what beginners may want to pivot into after they are done writing their "is the number higher or lower?" first terminal app isn't great for them. It's not a great game/graphical language. GUIs mostly suck. Web is awfully hard to get into nowadays, even if you try to help them narrow their focus.
enriquto 6y ago
> As soon as you deal with concurrency, things either get hard to learn or get super messy. Strong disagree. There is a language where concurrency is trivial and beginner-friendly. It is called POSIX shell with standard GNU tools. To run several independent commands in parallel, you print them and pipe to GNU parallel. If your concurrency has an arbitrary tree of dependencies, you print it in the form target : dependencies ; command and then run GNU make. Languages that make this simple stuff complicated, like Python, do so by choice, not by need.
- valenterry 6y ago
  There is a reason why no one uses shell for anything more complicated. E.g. start two long-running commands and then close the one of them depending on some later output of the other one or vice versa. If that's not already complicated enough, we can easily add things like, execute a command A and then another other commands (B, C, D) and, only once all these are finished, run a cleanup command D. But run D always, no matter wether B, C, D fail (think of closing a database connection). And now treat this whole thing as yet another command E, that itself can be used in the same place as e.g. B or C or D before (= composition). Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency".
  - enriquto 6y ago
    > Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency". Yet somehow beginners in my lab cannot get their hands off the shell and we have to politely guide them to other languages... But still, I insist that parallelism in the shell is very easy. How do you do that in Python, for example? # convert images from jpg to png, in parallel for i in *.jpg; do echo convert $i ${i/jpg/png} done | parallel Regarding your "complicated" use cases, I must confess that I don't understand them nor their relevance. But for simple people like me without fancy needs, the simple concurrency offered by GNU parallel and GNU make is good enough.
    - 6y ago
jnxx 6y ago
> As soon as you deal with concurrency, things either get hard to learn or get super messy. I'd argue that Clojure, while perhaps not the easiest language for beginners in all aspects, is both minimalistic and really fantastic for doing clean and safe concurrency.

andi999 6y ago

The program should leave one core for the OS.

dehrmann 6y ago

> replaced shell I'd argue it replaced Perl.

visarga 6y ago
Are you saying it was a replacement for a two year old language? Perl - December 1987 Python - December 1989
- dehrmann 6y ago
  Yes. You need to remember than neither language was relevant yet; I'd draw that line around Perl 5 and Python 2. Don't forget that Perl 6 spent two decades in development hell. Not that the TIOBE index is perfect, but you can see what happened since 2001. Perl used to be a lot more popular for early dynamic websites and systems glue, but by 2011, Python had gotten a lot more popular in those roles. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
  - pjmlp 6y ago
    Zope was winning over mod_perl back on those days.

pjmlp 6y ago

Chapel and Julia.

N1H1L 6y ago

dask in my opinion comes decently close to better parallel computation in Python, and being beginner friendly. It is immensely compatible with numpy and pandas, and can abstract away a lot of the parallel computation complexities which makes getting up to speed easier. However, their scheduler really needs speed ups, and they do run into weird data handling bottlenecks in my experience.