5 ms·

What didn't he like about Python? There are things about Python which are ugly, but the language is nice for being flexible, lacking surprises, having an ethos

What didn't he like about Python? There are things about Python which are ugly, but the language is nice for being flexible, lacking surprises, having an ethos favouring readable code, and having a comprehensive set of libraries that are easy to use. Python's famed readability takes a dip when you use libraries like Pandas or Tensorflow -- which awkwardly glue a whole new language onto Python -- but standard library Python is very common-sense and readable. (Also, Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing. In Pandas, you sometimes have a function with the same name as a method, which behave subtly different from each other.) Academic functional languages don't have most of those, and academia has no right to complain given that they've done little to rectify this.

DonaldPShimoda 5y ago
Bob Harper is known (among my circles, anyway) as taking pretty hard stances in favor of first-principles approaches, and he's also one of the foremost researchers in advanced type theory. Python is about as far away from his interests as you can possibly get, I'd imagine. > Academic functional languages don't have most of those, and academia has no right to complain given that they've done little to rectify this. On this note, I'll have to (hopefully politely) ask you to learn a bit more about what you're going to talk about before offering such opinions. Most (maybe all?) modern languages were developed primarily as direct results of academic involvement. And in those areas in which the influence is not direct, advances are usually still due to the efforts of those in PL academia. I don't say this to be obnoxious, but you can pretty well trace the developments through conference proceedings over the past few decades. As for what we refer to as academic languages: they are not meant to be useful to the general programmer. They don't need powerful standard libraries or flexibility. They're meant for exploration and experimentation. Haskell (for example) was never supposed to catch on in the mainstream. It was designed to answer questions like "What does programming in a lazy language look like?" and "Is such a language useful?" and "In what ways is it not useful?" This is detailed in the phenomenal paper "A History of Haskell: Being Lazy with Class" from I think HOPL 3.
bmitc 5y ago
> Python ... the language is nice for ... lacking surprises Really?! The number one thing I dislike about Python is that it is chalk full of surprises, especially if you know more regular languages like MLs (e.g., SML, F#) or Schemes (e.g., Scheme itself, Racket). The scoping rules alone are a minefield. If one knows F#, for example, going to Python is a step back in basically every way unless you need a package that is only in Python (somewhat rare). > Academic functional languages don't have most of those, and academia has no right to complain given that they've done little to rectify this. It's an interesting stance, given Guido van Rossum seemingly did everything he could to avoid what came out of academia.
- angrais 5y ago
  You've made a lot of claims. I don't use F# of MLs, so why for you are they a step forward?
  - bmitc 5y ago
    For F# vs Python, I cannot think of anything that Python does better than F#, and F# has several features that Python doesn't. Things that come to mind in F# are unhampered lambdas, clear and consistent scoping rules, cleanly separating binding and assignment, built-in pattern matching inherent to the language, discriminated unions, built-in records, default built-in immutability, actual concurrency, piping, embracing imperative and OOP and functional paradigms, performance, modules, type inference, units of measure, etc. They share many things like whitespace sensitivity, notebook implementations, relatively clean syntax, but even the things they share, I'd give F# the edge on all of them.
    - Terry_Roll 5y ago
      Isnt this like comparing apples and oranges, both designed & built decades apart (Python late 80's by CWI in Netherlands, F# 2005, Microsoft Research at Cambridge). F# seems to be a language with more 3rd party addons built into the standard Off-The-Shelf offering seen with other languages. My biggest takeaway when I looked at F# is it seemed better suited to db work than C#.
kd0amg 5y ago
> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing. Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup, or something similar that effectively has `object` carrying around its own particular implementation of `f` (which might have been closed over some hidden internal state as well), and I'd expect `f(object)` to not do anything of the sort. > In Pandas, you sometimes have a function with the same name as a method, which behave subtly different from each other. This sounds more like a poorly designed library than any language-level awkwardness.
- lmm 5y ago
  > This sounds more like a poorly designed library than any language-level awkwardness. Languages ought to disallow these things. E.g. I'm constantly baffled that many languages won't let you use symbols as normal method names, but are absolutely fine with you having two methods whose names differ only in case. (There's even academic research showing that case sensitivity is the biggest pitfall for beginners learning Python).
- ogogmad 5y ago
  > Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing. >> Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup Low level details like that should not concern me. In which case, maybe `f(object)` should do a vtable lookup then; why not? The syntax `object.f()` and `f(object)` should be interchangeable in all situations.

DonaldPShimoda 5y ago

Bob Harper is known (among my circles, anyway) as taking pretty hard stances in favor of first-principles approaches, and he's also one of the foremost researchers in advanced type theory. Python is about as far away from his interests as you can possibly get, I'd imagine. > Academic functional languages don't have most of those, and academia has no right to complain given that they've done little to rectify this. On this note, I'll have to (hopefully politely) ask you to learn a bit more about what you're going to talk about before offering such opinions. Most (maybe all?) modern languages were developed primarily as direct results of academic involvement. And in those areas in which the influence is not direct, advances are usually still due to the efforts of those in PL academia. I don't say this to be obnoxious, but you can pretty well trace the developments through conference proceedings over the past few decades. As for what we refer to as academic languages: they are not meant to be useful to the general programmer. They don't need powerful standard libraries or flexibility. They're meant for exploration and experimentation. Haskell (for example) was never supposed to catch on in the mainstream. It was designed to answer questions like "What does programming in a lazy language look like?" and "Is such a language useful?" and "In what ways is it not useful?" This is detailed in the phenomenal paper "A History of Haskell: Being Lazy with Class" from I think HOPL 3.

bmitc 5y ago

> Python ... the language is nice for ... lacking surprises Really?! The number one thing I dislike about Python is that it is chalk full of surprises, especially if you know more regular languages like MLs (e.g., SML, F#) or Schemes (e.g., Scheme itself, Racket). The scoping rules alone are a minefield. If one knows F#, for example, going to Python is a step back in basically every way unless you need a package that is only in Python (somewhat rare). > Academic functional languages don't have most of those, and academia has no right to complain given that they've done little to rectify this. It's an interesting stance, given Guido van Rossum seemingly did everything he could to avoid what came out of academia.

angrais 5y ago
You've made a lot of claims. I don't use F# of MLs, so why for you are they a step forward?
- bmitc 5y ago
  For F# vs Python, I cannot think of anything that Python does better than F#, and F# has several features that Python doesn't. Things that come to mind in F# are unhampered lambdas, clear and consistent scoping rules, cleanly separating binding and assignment, built-in pattern matching inherent to the language, discriminated unions, built-in records, default built-in immutability, actual concurrency, piping, embracing imperative and OOP and functional paradigms, performance, modules, type inference, units of measure, etc. They share many things like whitespace sensitivity, notebook implementations, relatively clean syntax, but even the things they share, I'd give F# the edge on all of them.
  - Terry_Roll 5y ago
    Isnt this like comparing apples and oranges, both designed & built decades apart (Python late 80's by CWI in Netherlands, F# 2005, Microsoft Research at Cambridge). F# seems to be a language with more 3rd party addons built into the standard Off-The-Shelf offering seen with other languages. My biggest takeaway when I looked at F# is it seemed better suited to db work than C#.

kd0amg 5y ago

> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing. Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup, or something similar that effectively has `object` carrying around its own particular implementation of `f` (which might have been closed over some hidden internal state as well), and I'd expect `f(object)` to not do anything of the sort. > In Pandas, you sometimes have a function with the same name as a method, which behave subtly different from each other. This sounds more like a poorly designed library than any language-level awkwardness.

lmm 5y ago
> This sounds more like a poorly designed library than any language-level awkwardness. Languages ought to disallow these things. E.g. I'm constantly baffled that many languages won't let you use symbols as normal method names, but are absolutely fine with you having two methods whose names differ only in case. (There's even academic research showing that case sensitivity is the biggest pitfall for beginners learning Python).
ogogmad 5y ago
> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing. >> Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup Low level details like that should not concern me. In which case, maybe `f(object)` should do a vtable lookup then; why not? The syntax `object.f()` and `f(object)` should be interchangeable in all situations.