codygman

10 ms·

61.
by codygman 6y ago
> If it really sucked then people wouldn't use it. What if they never give an alternative a chance? Then that scenario could happen quite easily.
62.
by codygman 6y ago
> if you recognize that some common construct is in fact a semigroup or functor, does knowing this actually buy you anything? At least in Haskell one thing it means is you can use lots of new helper functions. > guide you to some nice
63.
by codygman 6y ago
Someone already did and the goalposts just got moved again: https://news.ycombinator.com/item?id=24352585
64.
by codygman 6y ago
> There are some tiny niches where functional programming is particularly useful, but outside of them the code is classically difficult to read, write or debug What niches are these where FP is "classically difficult to read, write
65.
by codygman 6y ago
> map is also quite natural, but isn't it telling that the way a human will do this on paper is by reptition of the same task in sequence... i.e. a for loop. Would they?
66.
by codygman 6y ago
Catching up on comments and kind of fuzzy, but this is pretty cool :) foldr1 (&&) ( [ (==3), (==4) ] <*> pure 3 )
67.
by codygman 6y ago
> This actually is pretty ugly. What precisely is "this"? From my point of view at best it's calling out FUD and an unsupported claim sold as obviously true. It's not abuse to challenge unsupported claims and call the
68.
by codygman 6y ago
> Go got rid of Generics which made programming so much simpler. I can't wait for its new Generics feature though. What? If getting rid of generics made programming so much simpler why can you not wait for its new Generics feature?
69.
by codygman 6y ago
> Mathematicians mostly care about value semantics but programmers need to care about how it's realized in hardware too. Exactly! The thing is this book gives a method where you care about value semantics, keep the ideal representat
70.
by codygman 6y ago
> "Oh, this thing turns out to be a Monoid! Let me abstract it." You seem to have an example in mind where this leads to the "making everything a mathematical problem" , can you share it? > Haskell communities do i
71.
by codygman 6y ago
As a professional Haskell programmer for a bit now, I see no problem with a chat app in Haskell. In fact, something close is wire[0] whose server source code is here[1]. They are a secure alternative to slack and mattermost for the curious.
72.
by codygman 6y ago
When you design software focusing only on the business logic and domain the end result will be better than if you have to do it while juggling implementation and performance concerns. > We have no metric to use to quantitatively score on
73.
by codygman 6y ago
> 95% of Go programs could be replaced with a single traverse This is a rather abrasive way of putting it that tries to communicate this point. I would have found it difficult to even entertain when my Gopher squishee on my desk and I ca
74.
by codygman 6y ago
This "theoretic book" can help you design a very good api. If you mean REST api's by chance, remember those were theoretic once too!
75.
by codygman 6y ago
> But if more boilerplate translates to greater readability (i.e. less abstraction & much closer relation to the problem domain) then I would argue that the added boilerplate is justified. The added boilerplate usually translates to
76.
by codygman 6y ago
> Applications written in haskell you can run on your computer for doing something other than programming is still a list that you can count on your fingers. Before you make such strong claims, you should at least try and validate they&#
77.
by codygman 6y ago
> I am turned off as well from the abstractionauts in the software world Is there any way you can give examples of this in Haskell? If I'm just blind to them by now I'd like to know, but most "abstractionaut" criticis
78.
by codygman 6y ago
> C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the wa
79.
by codygman 6y ago
> Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out, and from outside the software looks like an impenetrable, rugged piece of craftsmanship. I disagree. I think they only feel robust.
80.
by codygman 6y ago
> Bad code that ships is better than good code that doesn't. Sometimes, but not always. The bad code that ships however always feels better and gives the feeling that progress is being made. That works fine until a wall is hit and
81.
by codygman 6y ago
> The other reason is that many FP users are too enthusiastic about creating abstractions. Are they? I'd argue most real-world Haskell code doesn't abstract enough, perhaps out of over-reaction to this untrue assertion that see
82.
by codygman 6y ago
You might have been bitten by this before: 1. Make it work 2. Make it right 3. Make it fast (uh-oh your nice design prevents performance optimizations, time to scrap it) The reaction to that is usually to think more about p
83.
by codygman 6y ago
> But recently I started to think that one of the reasons that prevent it from becoming more popular is that the community focuses too much on "mathematical" abstractions. Many times being in the middle of any two extremes is a
84.
by codygman 6y ago
> However, based on the website and sample chapters, it’s not clear that there will be strong arguments made here about either scalability or performance I've read most of it, performance is addressed after correctness. The trick
85.
by codygman 6y ago
> I don't know many programmers who are jumping to use Haskell for their personal projects. If you don't use Haskell or are suspicious of it, would you expect to know other programmers who use it? We have data that can more str
86.
by codygman 6y ago
The advantage (or potential problem as you see it) is typeclasses encourage thinking about the meaning and behavior of what you are doing. For simple cases, the end result of no typeclasses can be compelling sometimes. For larger cases, tak
87.
by codygman 6y ago
> Haskell code can be optimised to run very fast indeed, but resulting optimised code does not look much like idiomatic Haskell at all. It's still Haskell though, which means it can compose nicely with all that idiomatic Haskell! Fu
88.
by codygman 6y ago
> I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to. What you describe as a problem sounds like a solution to me :) I'm curious whether you think there are imperative ab
89.
by codygman 6y ago
> But that requires compiler-as-a-service, and GHC is not. And writing your own analyser for a language is quite a task. Yep. Haskell-language-server is very nice, though there are some performance issues I've experienced with a tem
90.
by codygman 6y ago
> but "notebook-style" exploration also sounds interesting. It is, but if the process and tooling isn't really polished and responsive it feels really bad. When everything is smooth though, it might be ideal. Jury still ou

More ›