5 ms·
This rebuttal isn't very good. The lack of canonical names for parameters to data constructors is usually addressed by convention, and can present real problem
by gue5t 9y ago
This rebuttal isn't very good.
The lack of canonical names for parameters to data constructors is usually addressed by convention, and can present real problems for reading unfamiliar codebases. There are solutions, but this is a legitimate complaint and saying "OO also has some nameless things" doesn't help. A more helpful response would point at lenses and tools for jumping to datatype definitions, where fields' purposes should be documented.
Functional "mutation" tracking is subsumed by dataflow tracking, which is necessary in every programming language. The rebuttal is basically right here.
Partial application is occasionally useful, but in languages where it isn't built-in, it's easy to wrap multi-argument functions in closures to curry them by hand. The comparison to overloading is based on visual similarity but has no real relevance to potential difficulty in understanding the meaning of curried function calls.
The notes on higher-order function calls and state-passing are okay, but it would be nice to note the ways state-passing can be avoided even in pure code in many functional languages.
Lack of methods is a real annoyance, not because the syntax is important, but because methods enable type-dependent dispatch. The right response here is to point at typeclasses and traits, which are how ad-hoc polymorphism is usually done in functional programming languages. In Rust, for example, traits provide methods with the same syntax as "OO" classes.
Cons-/linked lists are O(n) access and there are many situations where avoiding significant slowdowns involves roundabout code transformations or "reverse; process; reverse" nonsense. Both random-access mutable containers and immutable functional ones are useful and there are applications where the constant slodown factor due to indirection (often more so than the logarithmic factor) associated with pure data structures is prohibitive.
Poo-pooing early return rather than pointing at tools in functional languages (do-notation) for writing similiarly expressive code is ignorant at best, and disingenuous at worst.
The problem of H-M error messages bringing up two parts of a program and saying they conflict, rather than pointing at one part of the program and saying it's a mistake, is a well-known drawback. There other points in the design space of type inference and typechecking that may better align with what programmers expect for assigning "blame" to type errors.
- mrkgnao 9y ago> This rebuttal isn't very good. I'm inclined to agree, and I do find your points more "airtight". (I see you've been downvoted; it wasn't me.)
- nerdponx 9y agoI agree with you and I'm not sure why you're being downvoted. Dispatch, especially multiple dispatch, can be really useful when used judiciously.
- l_dopa 9y agoThis is exactly what higher-order functions do, without the ad-hoc OO junk that's slightly different in every language.
- nerdponx 9y agoI'm not talking about higher order functions. I'm just talking about regular old dispatch, like in C++.
- yawaramin 9y agoIn a way C++ is using higher-order functions conceptually too for polymorphic runtime dispatch. Because it uses vtables, which are lists of function pointers--essentially the object doing the dispatch is a HOF which calls one of the functions it has a pointer to. All this is just made explicit, and the boilerplate OOP mechanisms stripped away, when you just directly pass first-class functions around.
- nerdponx 9y agoI guess I just don't understand the connection between first class functions and multiple dispatch. I have a function "add()" that works differently for strings and numbers. How can I replicate that behavior with higher order functions?
- yawaramin 9y agoHere's an example (top-left corner, ReasonML syntax): https://reasonml.github.io/try/?reason=LYewJgrgNgpgBAQTGOBeOBvAUHOsAucAlgHb4AUAHgDRwCeAlGnJXANT0DcOeMhAzvgBOpAOZVajZqzYc63XATggADuQCGyGENo16TdJrDaJ+7gF9uWJUJj9o+AIzMkYAHSryrt6Xy1HtABMDNw2dg6BLsgeat6CIiSitABEABYwUFAgKSkA7iBCUGDJIVhAA https://reasonml.github.io/try/?reason=LYewJgrgNgpgBAQTGOBeO... The key idea is delegating the type-specific operations to specific implementations which handle them, and then statically (at compile time) choosing which specific implementation you're calling. In OCaml (ReasonML) you have to pass in the implementations manually, but Haskell and Scala have the ability to automatically choose the implementation based on the types of the arguments, so that it looks dynamic even though it's static and type-safe.
- dvfjsdhgfv 9y agoI'm also surprised you receive downvotes instead of counter-arguments.
- Karnickel 9y agoIMO there are a lot of needlessly downvoted comments on HN these days. A few months ago I was trying to stem that tide and upvoted downvoted comments when I saw no reason for those downvotes. It really looks completely random many times, or at the very least "I disagree", but without any attempt of making a counter argument. However, my voting rights were removed, and when I asked HN by contact email I was told I was behaving like a "troll" - the reasoning: I upvoted comments other people had downvoted, so I must be out to cause trouble! I gave up that account and don't care any more, I also hardly ever participate any more. I think the HN site admins contribute to this, being called a "troll" for doing what I still think was reasonable - I did not upvote a single comment that was in any way, shape or form objectively bad. They all had no insults, were no "cheap shots", not too short, not useless - they didn't even voiced troubling opinions. I still don't understand why they were dowvoted in the first place. The opinion of the site admin seems to be "you have to live with downvotes" and, at least in my case, when you try to work against what I think is clear downvote-abuse, you are assumed to be a "troll". Okay, I think voicing a negative opinion about the site is going to go down well... but that's okay. I think this site would be better off with no voting at all, given that a sizable number of downvoted comments don't deserve it at all.
- fro0116 9y agoFWIW I've always been of the opinion that HN would be better off without downvoting. Most arguments for downvoting I've heard revolve around the desire to maintain a high signal to noise ratio, but in my view, the marginal increase in SNR downvoting offers over upvoting and flagging alone isn't worth the chilling effect it has on unpopular speech. Even without downvoting, popular comments will rise up to the top and inappropriate comments will be flagged to oblivion. Downvoting is just an additional layer of censorship on comments that express unpopular opinions. While the first layer of censorship (from popular comments getting bumped up by upvoting) can be justified because of its high marginal contribution to SNR over a system without any censorship mechanism other than flagging, I don't think the same can be said about downvoting in a system where upvoting and flagging already exists. I feel downvoting has steadily been turning the HN comments section into yet another uninteresting, groupthinking hivemind with nothing provocative to offer, and will continue to do so until it gets reined in. And this is speaking as someone who doesn't get downvotes all that often.