Comment by bmitc | Hacker News Reader

Comment by bmitc | Hacker News Reader

Parent Full thread

I'm not sure what Python has to do with functional programming, even remotely. It basically contains none of the typical building blocks for functional programming (immutable data, real lambdas, pattern matching, sane scoping, etc.). Python has weird scoping, weird lambdas, and fully on mutability.

Regarding static versus dynamic functional programming, I think dynamic typing is probably oversold in that most dynamic programs could be static programs with very little effort. Where dynamic types really shine are at boundaries of programs. Dynamic types are very useful for handling messages, I/O, data formats, etc.

I actually think an ideal language would be one that is at its core a statically typed functional language, but then it has dynamic types allowed at the above stated boundaries. Then there could be some explicit conversion layer or solution that moves values from one side to the other.

Basically all other uses of dynamic typing can be solved in a statically typed language that has anonymous types like anonymous records and anonymous discriminated unions and some sort of "umbrella" or "shared" type such as interfaces, generics, and/or typeclasses, for example.

What do you mean by 'real lambdas'?

The functions you can create with Python's lambda syntax are a bit limited, but that's a purely syntactical limitation: you can create named function just fine and pass them around.

(I agree with most of the rest of what you are saying.)

They are likely referring to the hoops you have to jump through to get early instead of late binding. The boilerplate becomes automatic after a while, but that doesn't make it pleasant.

You get lexical scoping either way.

Of course, closures and mutability everywhere don't interact well. You have to make copies of values manually before they get mutated away, if that's what you refer to by 'early binding'?

Haskell is this. It is static with a dynamic type: https://downloads.haskell.org/~ghc/9.2.4/docs/html/libraries...

I think Typescript is close. It does suffer from JS heritage.

A TS like language that also had a way to runtime check types (for those data boundaries) but mix in some “any” when needed would be a hell of a pragmatic language.

A robust approach for data-boundaries is to write parsers or decoders. The Elm community has done some nice work here.

Yes I am suggesting making that sort of stuff but even further make it a language feature (I know purists prefer fewer language features which is OK). I feel it is a bit early in its journey but mint is a good example:

https://mint-lang.com/

It is made by someone coming from the Elm community, who made a lot of Elm packages.

Common Lisp is idd pretty nice.

Indeed, and I would further argue that business data be dynamically typed, because business data is often messy and changeable, whereas the plumbing that carries it can be statically typed to ensure you are connecting the pipes correctly.

> I would further argue that business data be dynamically typed, because business data is often messy and changeabl

Huh? Static types make change and refactoring much easier.

It's complicated.

Static typing easily leads to a over-specification of types.

With dynamic typing the least specific type that will make this work is automatically implied. You can often make huge changes to the underlying data structures and things will just work.

Basically: I need a Car Object with these exact fields vs give me a thing with the field "foobar" that contains something that I can concatenate with another things.

(Though static languages with structural typing like TS muddle the water here as they can represent some of the power of dynamic languages. That might be part of why TS is so popular. The problem is that types in dynamic languages can easily get super complex without feeling complex while for static languages you might need very advanced features (dependent types and other scary stuff) to represent some cases.)

The big downsides when working with dynamic languages: You need to have tests or at least some reliable way to test you program. If not, refactoring can be indeed worse than what you know from static languages.

Also static types make it easier to safely make changes to a program without actually understanding most of the code as you can just follow compiler errors while dynamic languages require you to have some model of what is going on in your head. So for people that jump projects a lot, static typing also allows for easier refactoring while dynamic typing allows for more productivity when one is more intimate with the code.

> Basically: I need a Car Object with these exact fields vs give me a thing with the field "foobar" that contains something that I can concatenate with another things.

Um, that's another matter entirely. Polymorphism. Mainstream statically typed programming languages until recently knew exactly one type of polymorphism based on objects, classes and interfaces. It is object-level polymorphism that lies at hear of OOP.

This form of polymorphism is easy to implement in compiler or interpreter, but it also is very limited in expressiveness. So proper functional languages use parametric object-level and function-level polymorphism and allow dictionary passing (both implicit and explicit). This approach filters into mainstream programming language: generics in Java, templates in C++ and so on.

Yes, I am aware of that.

The point is, Polymorphism in dynamic languages is pretty trivial.

There is a reason the golang devs resisted introducing generics for so long, it introduces complexity and can be hard to debug.

If you read my side-note:

> The problem is that types in dynamic languages can easily get super complex without feeling complex while for static languages you might need very advanced features (dependent types and other scary stuff) to represent some cases

If you want to have a functional example: Elm and it's lack of type classes or similar features. There is a reason Elm is resisting to implement a better way to add ad hoc polymorphism for better or worse. It is difficult to fit into the goal of Elm being a simple and easy to use language.

So yes, you can either have a more complex static type system and pay the price for that or just bite the bullet and over specify types.(The problem is also one of ergonomics. Programmer might over specify types because that is the path of least resistance or because things like generics make code harder to debug.)

> immutable data

sort-of possible now (frozen*)

> pattern matching

That has been added recently

Neither are foundational in the language and have all sorts of quirks. If anything, it makes Python akin to C++'s bloat, one of the complaints and ultimately ironic comparison at the beginning of the article.

I'd say that Python is uniquely functional not because of features or authors intention, but by being somewhat flexible and having users interested in writing in this style. So despite its quirks, for many people it is as functional as they can get, and for some even as much as they need.

Reply on news.ycombinator.com