4 ms·

Before Python got popular, Perl was the most similar popular language. Once I encountered Python, I felt, this is Perl, but done right.

TuringNYC 3y ago
+100 I loved Perl, but it had a culture of doing things in N different ways, too many shortcuts, and you ended up with incredibly tiny scripts which were unreadable -- even to the author -- a month later. This wasnt practical for business use in the face of more consistent code from Python
kstrauser 3y ago
That was my experience. I like Perl. I'm comfortable with Perl. And after about a day of Python, I never wrote another line of new Perl code. There were so many "it can't possibly be that easy, but it is!" moments. Let's write a function to add five to a number: def add_five(num): return num + 5 OK. So, can I pass that function as an argument to another function? def call(func, value): return func(value) call(add_five, 10) => 15 What? That worked?! And there was zero additional syntax, you just... do it? After a seemingly endless list of happy discoveries like that, I seriously rethought my idea of what programming languages could be, and ought to be.
- DoingIsLearning 3y ago
  > you just... do it? A few years from now, when researchers look at mental workload when writing/reading software, we will have the data to prove that Guido was a Neuroergonomics savant.
- KerrAvon 3y ago
  That sounds trivial? I mean, you can do that in C, what’s surprising about it? I have never found Python as nice to use as you seem to have, but Ruby always fit like a glove. I’ve written Python since 1999 and I still would rather use almost anything else. It’s so labored to do anything complex. You can build worlds in Ruby in the time it takes you to align indentation properly for a single class in Python.
  - kstrauser 3y ago
    > That sounds trivial? I mean, you can do that in C, what’s surprising about it? Here's the C version of it: #include <stdio.h> int addFive(int num) { return num + 5; } int call(int(*func)(int), int value) { return func(value); } int main() { printf("%d\n", call(addFive, 10)); return 0; } It's still manageable, but not nearly so simple. Even Perl doesn't let you escape having to consider pointers and references: sub addFive { return shift() + 5; } sub call { my($func, $value) = @_; return $func->($value); } print(call(\&addFive, 10)); Why do I have to remember to write `\&addFive` in Perl, when Python doesn't require it? Why do I have to write `$func->($value)` instead of the normal `func($value)` in this case? Why do I have to write `$value` in the first place? That's rhetorical: I know the answers. Still, this was the kind of thing that instantly won me over from Perl to Python. It's not that I could somehow write things in Python that were unwriteable in Perl (or C, or assembler, or ...), but that Python let me concentrate on what I was trying to say instead of how to say it. In fairness, the equivalent Python code with optional typing is also more verbose than my original, minus the pointer stuff: from collections.abc import Callable def add_five(num: int) -> int: return num + 5 def call(func: Callable[[int], int], value: int) -> int: return func(value) print(call(add_five, 10)) The key word there being "optional". Python lets you add that if you want to, but you don't have to. And note that the underlying syntax is identical if you delete the annotations. If you opt in to using them, you don't have to alter the code you're annotating.
    - cutler 3y ago
      You don't have to shift() or unroll @ any longer in recent Perls.
    - Izkata 3y ago
      int call(int(*func)(int), int value) { return func(value); } At least in gcc, you don't need to think about pointers. Just use the function signature: int call(int func(int), int value) { return func(value); } I don't know if this is an extension or what, but it's something I "just tried" on a hunch with no guide in 2009 and it worked.
- RhysU 3y ago
  Python didn't corner the market there: (define (add-five num) (+ num 5)) (define (call func value) (func value)) (call add-five 10) Admittedly, this was one-of-many examples. I do wonder how much would be different today if not for the Monty Python gags in the documents.
  - kstrauser 3y ago
    Sigh. I know. We are truly walking in the darkness. When I’m appointed Lord Emperor, we’ll all upgrade back to Lisp.
  - oblio 3y ago
    It did corner the market for "no extra brackets needed just in case people want to treat code as data which most people don't want to".
- cutler 3y ago
  If that blew you away you really should try Ruby: def call(fn, val) = fn.(val) call(->(n){ n + 5 }, 10)
  - takeda 3y ago
    It is still hard to understand unless you are familiar with the language. Python got popular because it made it simple. Ruby on the other hand encouraged cleverness like what you wrote. I think ruby faded for the same reason perl did. It is cool to write code, but once it's time to maintain it, especially after the rock star who wrote it left, it sucks.
    - cutler 3y ago
      > cleverness like what you wrote. So we should optimise languages for users who are not prepared to familiarise themselves with the language? How is this more complicated than its commonly-used Javascript equivalent? function call(fn, val) { return fn(val) } call(n => n + 5, 10) You see when written in a language in which lambdas are first-class citizens it doesn't look clever at all so maybe Python's sad implementation of lambdas and its anti-fp culture could be at fault?
rcarmo 3y ago
Excellent point. I moved from Perl 4/5 (writing fairly involved RADIUS code) to Python (doing other stuff, but still intricate) and the fact that I could actually read my code six months later made all the difference.
cutler 3y ago
As someone who began his programming career with Perl I've never understood this idea that Python somehow improved on Perl. For a start Ruby is Perl5's most obvious successor. Perl puts Python's text-handling to shame whilst Python's lambda is nowhere near as expressive as Perl's. Python also goes head-to-head with Perl's fundamental philosophy - TIMTOWTDI. If anything Python is the Anti-Perl.

TuringNYC 3y ago

+100 I loved Perl, but it had a culture of doing things in N different ways, too many shortcuts, and you ended up with incredibly tiny scripts which were unreadable -- even to the author -- a month later. This wasnt practical for business use in the face of more consistent code from Python

kstrauser 3y ago

That was my experience. I like Perl. I'm comfortable with Perl. And after about a day of Python, I never wrote another line of new Perl code. There were so many "it can't possibly be that easy, but it is!" moments. Let's write a function to add five to a number: def add_five(num): return num + 5 OK. So, can I pass that function as an argument to another function? def call(func, value): return func(value) call(add_five, 10) => 15 What? That worked?! And there was zero additional syntax, you just... do it? After a seemingly endless list of happy discoveries like that, I seriously rethought my idea of what programming languages could be, and ought to be.

DoingIsLearning 3y ago
> you just... do it? A few years from now, when researchers look at mental workload when writing/reading software, we will have the data to prove that Guido was a Neuroergonomics savant.
KerrAvon 3y ago
That sounds trivial? I mean, you can do that in C, what’s surprising about it? I have never found Python as nice to use as you seem to have, but Ruby always fit like a glove. I’ve written Python since 1999 and I still would rather use almost anything else. It’s so labored to do anything complex. You can build worlds in Ruby in the time it takes you to align indentation properly for a single class in Python.
- kstrauser 3y ago
  > That sounds trivial? I mean, you can do that in C, what’s surprising about it? Here's the C version of it: #include <stdio.h> int addFive(int num) { return num + 5; } int call(int(*func)(int), int value) { return func(value); } int main() { printf("%d\n", call(addFive, 10)); return 0; } It's still manageable, but not nearly so simple. Even Perl doesn't let you escape having to consider pointers and references: sub addFive { return shift() + 5; } sub call { my($func, $value) = @_; return $func->($value); } print(call(\&addFive, 10)); Why do I have to remember to write `\&addFive` in Perl, when Python doesn't require it? Why do I have to write `$func->($value)` instead of the normal `func($value)` in this case? Why do I have to write `$value` in the first place? That's rhetorical: I know the answers. Still, this was the kind of thing that instantly won me over from Perl to Python. It's not that I could somehow write things in Python that were unwriteable in Perl (or C, or assembler, or ...), but that Python let me concentrate on what I was trying to say instead of how to say it. In fairness, the equivalent Python code with optional typing is also more verbose than my original, minus the pointer stuff: from collections.abc import Callable def add_five(num: int) -> int: return num + 5 def call(func: Callable[[int], int], value: int) -> int: return func(value) print(call(add_five, 10)) The key word there being "optional". Python lets you add that if you want to, but you don't have to. And note that the underlying syntax is identical if you delete the annotations. If you opt in to using them, you don't have to alter the code you're annotating.
  - cutler 3y ago
    You don't have to shift() or unroll @ any longer in recent Perls.
  - Izkata 3y ago
    int call(int(*func)(int), int value) { return func(value); } At least in gcc, you don't need to think about pointers. Just use the function signature: int call(int func(int), int value) { return func(value); } I don't know if this is an extension or what, but it's something I "just tried" on a hunch with no guide in 2009 and it worked.
RhysU 3y ago
Python didn't corner the market there: (define (add-five num) (+ num 5)) (define (call func value) (func value)) (call add-five 10) Admittedly, this was one-of-many examples. I do wonder how much would be different today if not for the Monty Python gags in the documents.
- kstrauser 3y ago
  Sigh. I know. We are truly walking in the darkness. When I’m appointed Lord Emperor, we’ll all upgrade back to Lisp.
- oblio 3y ago
  It did corner the market for "no extra brackets needed just in case people want to treat code as data which most people don't want to".
cutler 3y ago
If that blew you away you really should try Ruby: def call(fn, val) = fn.(val) call(->(n){ n + 5 }, 10)
- takeda 3y ago
  It is still hard to understand unless you are familiar with the language. Python got popular because it made it simple. Ruby on the other hand encouraged cleverness like what you wrote. I think ruby faded for the same reason perl did. It is cool to write code, but once it's time to maintain it, especially after the rock star who wrote it left, it sucks.
  - cutler 3y ago
    > cleverness like what you wrote. So we should optimise languages for users who are not prepared to familiarise themselves with the language? How is this more complicated than its commonly-used Javascript equivalent? function call(fn, val) { return fn(val) } call(n => n + 5, 10) You see when written in a language in which lambdas are first-class citizens it doesn't look clever at all so maybe Python's sad implementation of lambdas and its anti-fp culture could be at fault?

rcarmo 3y ago

Excellent point. I moved from Perl 4/5 (writing fairly involved RADIUS code) to Python (doing other stuff, but still intricate) and the fact that I could actually read my code six months later made all the difference.

cutler 3y ago

As someone who began his programming career with Perl I've never understood this idea that Python somehow improved on Perl. For a start Ruby is Perl5's most obvious successor. Perl puts Python's text-handling to shame whilst Python's lambda is nowhere near as expressive as Perl's. Python also goes head-to-head with Perl's fundamental philosophy - TIMTOWTDI. If anything Python is the Anti-Perl.