Hacker News Reader

Comment by ogogmad | Hacker News Reader

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.

View on HN

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.

> 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.

You've made a lot of claims. I don't use F# of MLs, so why for you are they a step forward?

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.

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#.

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/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.

huh. Forgot to mention tail recursion.

Isnt this a CPU optimisation thing, ie code & languages working better for some instruction sets than others?

One of the languages I've used in the past always performed best on certain AMD cpu's, but that was when we could choose what cpu the compiler was to optimise for, ie 286, 386 etc etc.

I'm also aware of backroom shenanigans going on with some languages and tools working better for some CPU's.

This 12 year old post goes into a lot of detail https://stackoverflow.com/questions/1414911/intel-x86-assemb...

Tail call optimization has nothing to do with optimizing for different CPUs, it's about dropping a function's stack frame when it's evaluating its return expression and its stack frame isn't needed anymore.

Is this the difference in calling conventions ie callee or caller stack clear up? https://en.wikipedia.org/wiki/X86_calling_conventions#List_o...

This is half the problem different terminology in use between different age groups, just like slang is different between different age groups.

I'm not sure, so here are a couple examples.

    def f() =
       g()

In a language implementation that doesn't optimize tail calls, the stack would look like the following after the call to g:

    g
    f
    main

In a language implementation that does optimize tail calls, the stack would look like this, because the result of f is whatever the result of g is so f is no longer needed:

    g
    main

If a language implementation doesn't optimize recursive tail calls, the following code will quickly overflow the stack and the program will crash:

    def loop() =
        do something...
        loop()

In a language implementation that does optimize recursive tail calls, this code can run forever because loop's stack frame gets replaced with the stack frame of the new call to loop.

The reason people want recursive tail calls optimized out is at a much higher level than anything to do with the actual CPU instructions being used, they just want to have a way to write recursive functions without worrying about the stack overflowing.

What's my age group, by the way?

I have never seen this referred to anything other than things like tail-call recursion, tail-call optimization, etc.

Languages like Python make implementing simple loops like:

    def loop():
        <whatever>
        loop()

impossible.

Python will reach a maximum recursion depth and error.

Why is this important? Like I said, it makes looping very easy. For example, actors can almost be trivially implementing in languages with tail-call recursion.

It’s not in Python because like most things in Python, van Rossum doesn’t like it because <reasons>.

https://stackoverflow.com/questions/13591970/does-python-opt...

There’s little point in having full traces of the data doing in and out of the tail-call loop is immutable, so you only really care about the current call of the function.

Its not something I've every heard of before, I guess its peculiar to Python though but dont most languages have some eccentricity?

It's absolutely not peculiar to Python, it's something that every single language implementation has to make a decision on one way or the other.

Here's an SO answer from 2008 about how to enable TCO in various C and C++ compilers: https://stackoverflow.com/questions/34125/which-if-any-c-com...

There are many things both you and I have never heard of before. That's normal.

Yes, the different terminology is a reflection of the entrance of so many new entrants going for what is easy in the short term, instead of learning the theory of their industry and thus learning better approaches that are not 'immediately' obvious.

This lack of learning theory in our industry, instead going for something that is 'easy to get started' explains the popularity of python and javascript, and at the same time why python and javascript are littered with problems that have already been solved, and cluttering up the field of knowledge by reinventing terminology because they never learned the original existing terms.

Yea! And that's a big one.

There wasnt much before Python either, I know some people who think OS/2 was better for multi tasking than windows, but the popular market didnt seem to think so.

> (for one, there's several different implementations of "concurrent" programming in Python with various impedance mismatches and incompatibilities). I.e., it's complicated.

Is this because Python doesnt offer any Co-operative threading model and just exposes programmers to preemptive threading and all the different synchronisation facilities an OS provides? https://docs.microsoft.com/en-us/windows/win32/sync/synchron...

I dont have a problem with any of the synch objects because they also have strengths and weakness which are relevant to what ever the code is doing. Speed of synch objects is one factor, but there are others, like handling of shared data between two or more apps.

So are you saying F# removes the ability to choose synch objects?

Half the problem I find is just keeping up with different terminology used in various parts of the world.

( s/chalk full/chock-full/ )

Lol. Whoops. Thanks!

it's chalk full because academic languages use up all the chalk.

I did wonder for a moment whether it was some pun or joke that was going over my head. :D

>unless you need a package that is only in Python (somewhat rare).

That's basically most of scientific/numerical computing.

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.

R you forgetting another language which is useful for scientific/numerical computing?

Would Matlab count?

> 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.

> 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).

> 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.

Reply on news.ycombinator.com