Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
ebingdom
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
21 ms
·
91.
▲
by
ebingdom
5y ago
> I don't do that any more. simply because I'm very lazy I'm lazy too, but that's exactly why I use static types. So that when I refactor code, I can let the type checker tell me all the places that need to be updated
92.
▲
by
ebingdom
5y ago
That alternative definition seems less useful, because quite often there are two people who can individually maintain a project, and in that scenario the bus factor is 0 even though there is a risk that both of them will leave the project.
93.
▲
by
ebingdom
5y ago
By the "author", I meant the author of the article. I figured you were just being consistent with them.
94.
▲
by
ebingdom
5y ago
The author uses the term "union", but unfortunately they picked the one wrong term against a long list of correct alternatives: sum type, tagged union, discriminated union, coproduct, disjoint union, variant, algebraic data type,
95.
▲
by
ebingdom
5y ago
I'd much rather debug someone's pure functional code rather than trying to figure out how someone's imperative code got into some unexpected/invalid state.
96.
▲
by
ebingdom
5y ago
> They want to geek out and feel smart. Jesus Christ, I am so sick of you and all the people like you who repeat this lie. I've invested a lot of time learning about category theory, domain theory, type theory, etc. so I could becom
97.
▲
by
ebingdom
5y ago
> generally favour hard to understand style like point free where pipes are a lot easier to follow No they don't. Every Haskeller I know (myself included) acknowledges that sometimes point free style is better, and sometimes it isn&
98.
▲
by
ebingdom
5y ago
> I still think they don't often come up in algorithms research, though. Why are you so fixated on algorithms research in your attempts to dismiss the usefulness of functors and monads?
99.
▲
by
ebingdom
5y ago
> monads have very specific properties that imperative code often doesn't have. You don't know what you're talking about. In the context of programming language theory, monads were first used by Eugenio Moggi precisely for
100.
▲
by
ebingdom
5y ago
> much easier for humans to intuitively reason about than complex category theoretical concepts. We're not talking about any complex category theoretical concepts here. Functors, for example, are one of the first ideas one would lea
101.
▲
by
ebingdom
5y ago
> I strongly dislike Haskell's focus on theory. First of all, I completely understand where you're coming from. But the fact that Haskell embraces computer science, unlike most other programming language communities, is what at
102.
▲
by
ebingdom
5y ago
> Furthermore, even in Haskell, there is no such thing as the category of Haskell types[0] (because of things like divergence and partiality). Divergence and partiality can easily be modeled by the category of complete partial orders and
103.
▲
by
ebingdom
5y ago
Because the typical situation with error handling is that there are two possible cases: (a) a function succeeds with some result, or (b) it fails with an error. A sum type represents those two possibilities exactly. In contrast, a product t
104.
▲
by
ebingdom
5y ago
Using product types instead of sum types to represent "success or error" is definitely something wrong with it. Product types should be used for "and", and sums should be used for "or".
105.
▲
by
ebingdom
5y ago
> From the Swift docs regarding closures What makes you think Swift only supports functional programming? > I would have used Haskell doc reference And if you would have, you would have disproved your own point. In Haskell, closures c
106.
▲
by
ebingdom
5y ago
To all the people downvoting me: if you really think OOP is as well understood as FP, learn some programming language theory. Tell me what the universally agreed foundation of OOP is. You won't be able to, but I can tell for FP it'
107.
▲
by
ebingdom
5y ago
Yes, that's one of the most prominent in a long line of attempts at creating formal models of OOP. And in the preface, you'll find: > There is a well-established theory of functions, the λ-calculus, ... However, our theory of o
108.
▲
by
ebingdom
5y ago
> Isn't every existing programming language eventually based on (or at least traceable to) lambda calculus? Not really. FP has an obvious connection to lambda calculus. Many OOP languages don't even have a straightforward notio
109.
▲
by
ebingdom
5y ago
> FP is a cult. It's a programming paradigm based on simple, well-understood mathematical framework. It's also the starting point for most research in programming language theory.
110.
▲
by
ebingdom
5y ago
It's true that functional programming also doesn't have a formal definition, but I wouldn't say it's "exactly the same" as with OOP. Functional programming is based on a simple well-understood mathematical mode
111.
▲
by
ebingdom
5y ago
I would say it doesn't have a formal 100% unambiguous definition, but it's certainly _more_ well-defined than OOP: a functional programming language is one which is based on lambda calculus.
112.
▲
by
ebingdom
5y ago
> > it enhances the ability to reason about code > In your opinion. Correct. But my opinion is informed by years of experience with functional programming, procedural programming, and OOP (each). > Please provide any evidence th
113.
▲
by
ebingdom
5y ago
I think this is a reasonable point, and of course you could take it further and say that assembly language is better than functional programming when you're doing work that requires you to reason about what the CPU is doing exactly. Bu
114.
▲
by
ebingdom
5y ago
I would say the imperative version is easier to read in this article. The functional version doesn't really illustrate the benefits of functional programming very well, IMHO. I think there are two issues that reduce the effectiveness o
115.
▲
by
ebingdom
5y ago
It's a shame that someone can become so misguided about functional programming. Functional programming isn't about destroying readability. It's actually the opposite; it enhances the ability to reason about code by (a) being
116.
▲
by
ebingdom
5y ago
Um that's just an ADT, not a GADT...
117.
▲
by
ebingdom
5y ago
Yes, I've worked on several Go systems. Nothing I mentioned about the language is an assumption; these are well-documented properties of Go. I've also have experience in a handful of languages which have more disciplined type syst
118.
▲
by
ebingdom
5y ago
Why would anyone want to use a programming language that uses product types instead of sum types for the return types of functions which can return errors? Or why would anyone want to use a language that doesn't even let you write a ty
119.
▲
by
ebingdom
5y ago
Yes, that is what they are, but a generalization of a thing is not the same as the specific thing, and in this case the generalization already had other names (since it has been around for many decades in many other languages). It would hav
120.
▲
by
ebingdom
5y ago
> Rust's enums (used to illustrate static dispatch) are amazing, and one of the best (of many) language features. Enums can contain data of their own (as enum structs or enum tuples), opening up many more possibilities than the exam
More ›