5 ms·

> 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, especia

by 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#.
    - bmitc 5y ago
      I think the major thing is that F# did not ignore the things that came before it, whereas Python did. While Python did come about in the early 90s, it had already ignored things like Lisp, Scheme, Smalltalk, Erlang, and Standard ML (SML). As it evolved into the 2000s and 2010s, it continued to ignore developments. Compare that to Clojure, Elixir, and F#, and there's a stark difference. All three of those languages were designed to be highly pragmatic and not academic, but they all three stood on the shoulders before them. If you read interviews with van Rossum, he shows a complete unwillingness to accept the functional programming paradigm as pragmatically useful and basically rejects it wholesale. In his Slashdot interview, he explicitly said "functools (which is a dumping ground for stuff I don't really care about :-)". https://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions https://developers.slashdot.org/story/13/08/25/2115204/inter... It's frustrating to me, because if Python had adopted at least some of the things that languages like SML then OCaml and then F# were doing, it would dramatically elevate it. At the time of the interview, in which he goes on to state "Admittedly I don't know much about the field besides Haskell", the year was 2013, and so at that point, F#, Clojure, OCaml had already been around for a while, Erlang had been released with a permissive license, and Elixir had actually been released the year before. Further, it's not like even before that that Haskell was the only functional language. SML, Scheme, and even Racket (then known as PLT Scheme) had been around for a while. Python is a wolf in sheep's clothing to me. It has a deceptively simple look at at the surface, but it is actually a quite complicated language when you get into it. I've done concurrent programming my entire programming life in F#, Elixir, and LabVIEW. I simply do not understand how to do concurrency things in Python in a reliable and composable way (for one, there's several different implementations of "concurrent" programming in Python with various impedance mismatches and incompatibilities). I.e., it's complicated.
      - mellavora 5y ago
        huh. Forgot to mention tail recursion.
        Terry_Roll 5y ago
carapace 5y ago
( s/chalk full/chock-full/ )
- bmitc 5y ago
  Lol. Whoops. Thanks!
- bryanrasmussen 5y ago
  it's chalk full because academic languages use up all the chalk.
  - carapace 5y ago
    I did wonder for a moment whether it was some pun or joke that was going over my head. :D
eli_gottlieb 5y ago
>unless you need a package that is only in Python (somewhat rare). That's basically most of scientific/numerical computing.
- bmitc 5y ago
  And yet, people are using Python on much more for things that never touch Numpy, Pandas, or machine learning libraries. Also, Python isn't the only source for scientific computing. Although, I'm a bit frustrated Microsoft didn't see F# as a Python competitor early on and poured resources into it like they did with Visual Studio Code or TypeScript.
- mellavora 5y ago
  R you forgetting another language which is useful for scientific/numerical computing? Would Matlab count?

by bmitc 5y ago

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#.
  - bmitc 5y ago
    I think the major thing is that F# did not ignore the things that came before it, whereas Python did. While Python did come about in the early 90s, it had already ignored things like Lisp, Scheme, Smalltalk, Erlang, and Standard ML (SML). As it evolved into the 2000s and 2010s, it continued to ignore developments. Compare that to Clojure, Elixir, and F#, and there's a stark difference. All three of those languages were designed to be highly pragmatic and not academic, but they all three stood on the shoulders before them. If you read interviews with van Rossum, he shows a complete unwillingness to accept the functional programming paradigm as pragmatically useful and basically rejects it wholesale. In his Slashdot interview, he explicitly said "functools (which is a dumping ground for stuff I don't really care about :-)". https://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions https://developers.slashdot.org/story/13/08/25/2115204/inter... It's frustrating to me, because if Python had adopted at least some of the things that languages like SML then OCaml and then F# were doing, it would dramatically elevate it. At the time of the interview, in which he goes on to state "Admittedly I don't know much about the field besides Haskell", the year was 2013, and so at that point, F#, Clojure, OCaml had already been around for a while, Erlang had been released with a permissive license, and Elixir had actually been released the year before. Further, it's not like even before that that Haskell was the only functional language. SML, Scheme, and even Racket (then known as PLT Scheme) had been around for a while. Python is a wolf in sheep's clothing to me. It has a deceptively simple look at at the surface, but it is actually a quite complicated language when you get into it. I've done concurrent programming my entire programming life in F#, Elixir, and LabVIEW. I simply do not understand how to do concurrency things in Python in a reliable and composable way (for one, there's several different implementations of "concurrent" programming in Python with various impedance mismatches and incompatibilities). I.e., it's complicated.
    - mellavora 5y ago
      huh. Forgot to mention tail recursion.
      - Terry_Roll 5y ago

carapace 5y ago

( s/chalk full/chock-full/ )

bmitc 5y ago
Lol. Whoops. Thanks!
bryanrasmussen 5y ago
it's chalk full because academic languages use up all the chalk.
- carapace 5y ago
  I did wonder for a moment whether it was some pun or joke that was going over my head. :D

eli_gottlieb 5y ago

>unless you need a package that is only in Python (somewhat rare). That's basically most of scientific/numerical computing.

bmitc 5y ago
And yet, people are using Python on much more for things that never touch Numpy, Pandas, or machine learning libraries. Also, Python isn't the only source for scientific computing. Although, I'm a bit frustrated Microsoft didn't see F# as a Python competitor early on and poured resources into it like they did with Visual Studio Code or TypeScript.
mellavora 5y ago
R you forgetting another language which is useful for scientific/numerical computing? Would Matlab count?