This is outstanding -- although in lieu of Yet Another New Programming Language (YANPL), I would suggest simply having developers learn the concepts and apply them no matter what environment they're in. This should be part of any developer's education.
I have some good friends, smart people who know a lot more about good programming than I ever will, who keep saying things like "OO and FP are just different flavors. It's all the same"
That's both true and dangerously incomplete. Pure FP takes you places like this essay. Yeah you can make all of this happen in OO, but it sucks. And if you want to code at scale you gotta know exactly how much it sucks and what to do about it.
ADD: My biggest critique of this essay is that the people who need to understand it most will be put off by the terminology. I have no way to fix that, but it still sucks.
"This is outstanding -- although in lieu of Yet Another New Programming Language (YANPL), I would suggest simply having developers learn the concepts and apply them no matter what environment they're in."
One of the recurring themes I've been banging on on HN for the last couple of months is that there's actually a lot of room for new languages to come out that aren't just respellings of the current languages we have, and this is one of the opportunities that exist. I say this because the vast bulk of our current languages will just fight you so much if you try to work this way. What most languages are designed to do and designed to make easy are precisely the things that will blow your foot off. Trying to make this work in current languages is tapdancing through a minefield. It can certainly be done, but it's not something I think we can ever reasonably expect to be done at scale.
As you suggest, Haskell is pretty much the only semi-popular language that could implement this with a library, and it would be correct. And even then it probably would be a not-entirely-optimal experience, just because it's not really optimized for this.
I don't think we disagree. I'm a big fan of DSLs/languages over further app complexity. To clarify my point, Another Language (tm) is not the problem. The problem is a lack of understanding of the fundamentals.
I keep seeing people sell tech/languages/frameworks as some sort of replacement for deep understanding. Hey, that's cool -- as long as you don't spend all your time honking around with the tool instead of the problem. It's when these promises fail that devs and teams end up on a dark, lonely path with unhappy customers.
Overall I am quite fascinated by the concept of new environments for programmers -- and I believe it's not just new languages, but the tools, the industry background, the workflow, and a lot of other things come together to make tools and frameworks rock. (Many times we all want to geek out on language details when the problem with the language is lack of a community or tooling that makes you want to jump out a window. But I digress.)
Something I'm working on is coming up with guidelines of when and how to create good DSLs in order to create that kind of environment.
We do not. I meant more as elaboration, not outright disagreement. It is a great idea to apply these ideas today, but it's really hard, and I'd still love to see someone fix that. And maybe some other things as they go. But in the meantime, programmers of today really can't afford to wait to apply these principles.
I guess my point is that I agree that YAPL that just has this in it and is basically thrown out as a hack for writing a couple of papers is not very useful, but I'd love to see someone set out to create the Next Big Programming Language that incorporates this idea, as well as other things, but isn't just a demonstration project.
"Of the candidates enumerated in 'NSB', object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself." - Fred Brooks, No Silver Bullet Reloaded
I think we're mixing some things up here. If I have added to that confusion, I apologize.
Yes, OO is great. It's all of modern computing. Love me some abstraction levels -- as long as they actually abstract things. Any layer that I spend more time screwing around with other than making things people want is a net negative.
And there's my point: I'm not talking about the mechanics of FP or OO. I'm also not talking about the relative successes or failures of either model. My only point was how various modes of thinking end up solving problems different ways.
I find this a recurring theme. At the end, it's all Category Theory. So we're not talking about magic sprinkles here. Whatever we put on top of the math to help us reason about problems -- OO, FP, pure FP, and so on -- has various effects on the way we reason about problems.
Hell I don't care if you program COBOL. What's fascinating to me is how some folks read essays like this and go "Of course! Very cool" and others start talking about how it's all theoretical.
I read half-assed essays everyday that could mostly be described as some version of "I learned OO and now I think of everything as objects" The natural consequences of this thing -- which is not wholly bad -- is the same as the natural consequences of poor abstraction layers in coding: the person using them spends more time thrashing around trying to keep consistency and nomenclature aligned than they do working on the important stuff. Can you do the same with FP? Sure! But that's a conversation for a different day -- because it's a different failure mode.
Hmm. I thought it was all binary machine instructions. Or was it all NAND gates? Or everything is an object? Or everything is a list? Everything is a file?
Reductionist revelations are fun, and they also have some utility. But we have to be careful, because we tend to latch on to one of them and think that this is the one to rule them all. For different instances of "this" depending on person and time.
> Whatever we put on top of the math to help us reason
The math is another one of those magic sprinkles you put on top of the NAND gates. If that's the one that gets you going, good for you! And it certainly has its uses. But don't get carried away.
> half-assed essays everyday ... "I learned OO and now I think of everything as objects"
Funny, I don't see any of those these days, maybe you're thinking of the 90s? Instead, I see a ton of blog posts claiming that "everything is category theory". ¯\_(ツ)_/¯. Very often, they then take an interesting problem, claim that it's really this other problem solved elegantly by FP. By stripping away all the properties of the problem that made it interesting and useful. But at least now it typechecks. Sigh.
Anyway...
> Love me some abstraction levels -- as long as they actually abstract things.
Yes. This is important. Really, really important. In my current thinking, there are currently three levels of this: just indirection, compression, and actual abstraction.
A lot of people think they've contributed abstraction when they're really just adding indirection. When you find an abstraction, it really is magic, but those are fairly rare. So you typically want to keep it as direct as possible, while trying to compress (trading off with directness as appropriate). The compression can point you towards an abstraction:
Another point is that the point of OO is not the program, it is the system created by the program. That is at the same time its greatest strength, and its greatest weakness, because it means that in order to build those systems, the program that constructs the system has to based on "side effects". But that's really a limitation of our call/return architectural pattern:
Thesis: Architecture Oriented Programming is what Object Oriented Programming wanted to be. It talks about instances and systems rather than classes and programs. It also lays a solid foundation for meta programming (connectors). -- https://twitter.com/mpweiher/status/1100283251531411457
So the systems are great (or can be, if you have a great systems builder), but the way we are forced to build them is pretty bad. FP tends to recognise the latter but not the former. See also:
I have some good friends, smart people who know a lot more about good programming than I ever will, who keep saying things like "OO and FP are just different flavors. It's all the same"
That's both true and dangerously incomplete. Pure FP takes you places like this essay. Yeah you can make all of this happen in OO, but it sucks. And if you want to code at scale you gotta know exactly how much it sucks and what to do about it.
ADD: My biggest critique of this essay is that the people who need to understand it most will be put off by the terminology. I have no way to fix that, but it still sucks.