Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
codygman
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
31.
▲
by
codygman
6y ago
Have you written parsers in any other languages? Can you contrast?
32.
▲
In what niche does your favorite programming language surpass all competition?
13 points
by
codygman
6y ago
|
25 comments
33.
▲
by
codygman
6y ago
Also note that if you try thinking with types, you may start seeing them as tools rather than overhead. A good blog post about this is: https://lexi-lambda.github.io/blog/2020/08/13/types-as-axiom...
34.
▲
by
codygman
6y ago
> In my humble opinion, those two things are equal in difficulty and consequences. I'm not so sure, I'll give this idea some thought though. > I had almost the same number of bugs in my ML application that I would have in th
35.
▲
by
codygman
6y ago
> Do you really never need to see what a passed-in function actually does in your FP code? I'm hesitant to say always, but I can say: - in imperative code I never feel comfortable without inspecting the passed in function - in pure
36.
▲
by
codygman
6y ago
I'd argue if you can manage to write 10,000 line imperative programs that are correct as soon as they are compiled: 1) that's amazing, some of us aren't smart enough to do it without functional programming 2) I bet you could
37.
▲
by
codygman
6y ago
For posterity can you link to the questions that went unanswered on r/Haskell? I'd like to do an analysis.
38.
▲
by
codygman
6y ago
> Which, according to that comment (supposedly in support of Haskell) even points out that something as obvious and boring as "using a database" isn't clearly defined in Haskell. They are using a very high standard of clea
39.
▲
by
codygman
6y ago
Do you think any frustration is warranted for all of that articles false claims? I disagree with the cracked pot comment, that goes too far. It is pretty cringe-worthy, is it toxic to point that out?
40.
▲
by
codygman
6y ago
I use haskell for all of my general purpose programming. Webdev/rest apis at work mostly. Sometimes background services.
41.
▲
by
codygman
6y ago
I'm very sorry for your bad experiences. If you are comfortable giving some examples of that bad behavior and what it looked like I'd be happy to watch out for it and call anyone on that bad behavior so others don't have to e
42.
▲
by
codygman
6y ago
> Haskell will not catch on because the community thinks it is too smart to have to actually accommodate the programming community. Like, you don't literally mean there are Haskellers saying "we're to smart to write beginn
43.
▲
by
codygman
6y ago
> OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism. Also, in case Ocaml turns out to be a better fit for any future projects I have a question: What is the biggest advantage constituted in part or pri
44.
▲
by
codygman
6y ago
> Though Haskell is nice in many ways, I would choose OCaml for a commercial project over Haskell any day. As a counter-point I'd say the opposite: I choose Haskell :) > OCaml is ruthlessly practical and the culture around it is
45.
▲
by
codygman
6y ago
That's just untrue. Saying it is very inconsiderate of the efforts of everyone writing real world Haskell software. Facebook uses Haskell, Github uses Haskell, etc... the metaphor doesn't hold and means this is just FUD. On top of
46.
▲
by
codygman
6y ago
> Having developed Haskell skills, what can one then do with them? Who in the world wants to have any Haskell code written badly enough to offer to pay to have it done? Are there any languages you can immediately answer these questions f
47.
▲
by
codygman
6y ago
You mean like SemVer vs the default whose name I can't remember?
48.
▲
by
codygman
6y ago
Are you saying it's toxic that I argued with multiple people in multiple places to verify whether their claims were true or false?
49.
▲
by
codygman
6y ago
I was trying to reason with the author in good faith as well. Part of that means questioning large claims with no evidence. If you're going to accuse me of being toxic, please be explicit with quotes and what specifically was toxic rat
50.
▲
by
codygman
6y ago
I've said as much there in the comments already, but this gist doesn't have many useful insights. The problem is that highly valuing "first-principles thinking" is wrongfully attributed to arrogance and seen as "ign
51.
▲
by
codygman
6y ago
User experience and how it shapes the way you code is what matters, the features in isolation or not weaved together the same way are an entirely different result. The individual selling points are the smaller part of Haskell's USP.
52.
▲
by
codygman
6y ago
They should add a feedback wizard that guides a user to remove sensitive data and preserve the document format as much as possible.
53.
▲
by
codygman
6y ago
I hope more people are moving to markdown, but how are you confidence it's most and not just software developers? I think spreadsheets are still needed, just more flexible ones like Simon Peyton Jones elastic sheet defined functions:
54.
▲
by
codygman
6y ago
If the UX isn't done well I agree. However there a great opportunity for pushing for compatibility and a more portable document format in a less annoying way than gimp does for xcf.
55.
▲
by
codygman
6y ago
Maybe libreoffice needs a more strict word online compatibility mode that compromises UI and functionality for as perfect as possible compatibility. For instance a user in the thread mentioned all background colors can be applied in libreof
56.
▲
by
codygman
6y ago
.docx is the standard format per the people that are probably your bosses wondering why you're making trouble not using the standard microsoft word. Unless one can supplant the current ".docx" is standard across industry I do
57.
▲
by
codygman
6y ago
> As a dev it has kinda shredded my desire to do large scale unpredictable projects I understand the anxiety that drives this and have found the best approach to be bringing that up to my manager, verifying those types of contributions a
58.
▲
by
codygman
6y ago
> Consider Go, ... addressing them with the simplest solution possible. Go code doesn't result in the simplest solution possible.
59.
▲
by
codygman
6y ago
Yes! This "useful toolbox" approach to programming languages produces inelegant, incoherent, uncomposable, overly-complex results.
60.
▲
by
codygman
6y ago
> , I feel like I can confidently say structural typing, in practice, is MUCH easier, better and fun to work with than nominal typing. I can think of times I literally spent days trying to work through some refactoring in Java that was a
More ›