Please stop using multiple accounts and please don't use HN primarily for promotion—it's against the site guidelines.
We've banned this account and some others. If you stick to one account and submit your own stuff as part of a mix of unrelated things, and don't overdo it, that would be ok.
The comments by singaporecode where they say "I should sponsor the guide’s author" (when the author is himself/herself/themselves) and "I found online" (where they published it themselves) are clearly deceptive self-promotions of https://ashok-khanna.medium.com/ and https://github.com/ashok-khanna but do notice that they are unrelated to Lisp-Stat.
Man PG has jumped the shark completely. What the hell is that tweet - a deal is a deal, how can he implicitly say it should be ok for it not to be honoured (and with his twitter following, saying something publicly has an impact, however small)
Very high uptime overall. Credits to PG and his lisp/arc inspired codebase! And to dang (who I assume does a bit of coding on it from time to time from previous comments I have read..sorry if I read wrong)
All these niche functional programming languages are an exercise in pseudo intellectualism
Give me an object oriented language any day. The world is made of state and processes, (modern niche) functional programming goes too far to derecognise the value of state in our mental models
The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain places…
It's kinda funny, because you could say exactly the same about object-oriented programming as a discipline.
In functional programming the jargon might be foreign, but they correspond with the math they came from. You also have clear rules and clear situations where you can apply all those things.
In object orientation, however, we have mostly made-up jargon (from patterns and from SOLID), the "rules" for the application of those are completely fuzzy, arbitrary and broken most of the time, and even the categorisation of those is mostly made-up. It's pseudoscientific-mumbo-jumbo compared to Monads and other FP silly-named stuff.
Functional programming is actually mathematics based on lambda calculus.
Imperative programming isn't.
OOP is a failed metaphor, unless you use composition, not inheritance, even then, the actual basis for OOP was about the messages between objects, not the internals.
> The world is made of state and processes
No, the world is made of objects that have state and messages (events) between them.
The lambda calculus is an entirely arbitrary way to organize things in math. It’s not based on nature or truth at all.
The real problem, though, is that FP doesn’t do anything well. It’s never the fastest method of programming, which means that it needs to excel in some other way for its proponents to be right about it. Is it the most maintainable? Maybe if you have zero side effects but then any paradigm would be in that case. Once you introduce state, it becomes a nightmare to maintain, unlike OOP. It’s certainly not the most readable.
> The lambda calculus is an entirely arbitrary way to organize things in math. It’s not based on nature or truth at all.
Lambda calculus, category theory, and logic are essentially 3 sides of the same coin (the Curry-Howard-Lambek correspondence). The rules of lambda calculus match those of natural deduction. It runs quite a bit deeper than you're suggesting here. It's not just some arbitrary formalism.
Glad to see these comments because the parent's "it's math therefore from a deity, and much more correct than your grubby computer stuff" is so often trotted out. It turns out that there's no directionality to the relationship between mathematics and computers -- they're the same thing and one can be transformed into the other. e.g. Lambda Calculus is just a kind of VM someone came up with that can be used to model certain structures. Same for Category Theory, and same for Logic. So you might as well say that Lambda Calculus is derived from IBM 360 assembler language than the other way around.
There are limits on what lambda calculus can model though. For example, it doesn't model IO very well. So, these days, lambda calculus is only one of the parts of maths that informs functional programming.
I guess you could also say that the world is made of state, state transitions and state derivations, and functional programming does a great job of making the latter two reliable.
Every anything-oriented language amounts to wankage.
The world is a complicated place with complicated problems. Complicated problems are always solved by splitting them into different sub-problems, each routinely of radically different character than the outer problem, other sub-problems, or its own sub-sub-problems.
So, a language "oriented" for any one of those is a terrible choice for others. To solve any whole problem, your language should support all the styles that might be useful. Often, a sub-problem falls to a style combining a little of this style and a little of that. Styles should not be straitjackets.
Generally, it is better if the language is powerful and expressive enough that support for a style is not built in, but can be provided by a library. Any fancy built-in feature is always an admission that the core language wasn't strong enough to express it in a library.
That is why weak languages so often have fancy core features (e.g. dictionary): without, you would be left with no support. This should make us suspicious of a "match" feature.
A more powerful language lets you pick from variations on the fancy feature in a library or libraries. And, the library might define a new style useful for the sort of problems the library is designed for.
I can relate to your sentiment but calling it "pseudo intellectualism" is a step too far in my opinion. The math behind FP is legit. Like Programming Language Theory it can teach you interesting abstractions. And useful basic things like how most collections you use are monoids, map/flatMap, etc.
On the other hand, the original Design Patterns book was published in 1994. I'm still waiting for its FP equivalent.
Design patterns are just a repetition of the golden rule "don't repeat yourself" (when they're not they're antipattern). Maybe the functional developers don't need a book to teach them how to walk...
Either define concretely what the world is made of (i.e. particles and what they do), or don't use this sentence. Currently you just say "wow this is so abstract, it's actually <something else that's also abstract>". Turns out neither paradigm has anything to do with real life, they have their own niches and their own place within different contexts.
