Related, xwidget browser in emacs with keyboard navigation, etc:
1,459 karma · joined October 19, 2011
http://codygman.github.io
A good blog post about this is:
https://lexi-lambda.github.io/blog/2020/08/13/types-as-axiom...
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 the imperative program, but they manifested in different ways.
Can you talk about some of the different ways the same bug manifested?
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 functional code, I rarely feel uncomfortable taking a pure function at it's word
1) that's amazing, some of us aren't smart enough to do it without functional programming
2) I bet you could write 2-3x as much functional code and maintain the correctness. Reason being understanding doesn't require keeping track of mutable states in your head.
They are using a very high standard of clearly defined. Haskell has production ready ways of accessing databases and working with them today.
> problems that aren't significant or meaningful are difficult/not well defined (like using a database).
If you feel database work isn't meaningful, Haskell provides "write plain parameterized SQL, get back results" type libraries too.
I disagree database access and the realm of ORMs is simple, which is what they are talking about. You can tell by how they say "working with databases".
Other languages disagree about the best ways to work with databases. I'm sure you've seen the endless raw SQL vs ORM debates.
I disagree with the cracked pot comment, that goes too far.
It is pretty cringe-worthy, is it toxic to point that out?
Sometimes background services.
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 experience it.
Like, you don't literally mean there are Haskellers saying "we're to smart to write beginner-friendly documentation haha" right?
Jokes aside, can you give an example of this?
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 primarily from it's ruthless pragmatism?
As a counter-point I'd say the opposite: I choose Haskell :)
> OCaml is ruthlessly practical and the culture around it is was one eminent pragmatism.
Is this a plus? Practical and pragmatism seem to be unlaterally considered a positive, but when does "pragmatism" just start to mean "unprincipled"? There's much talk about when being too principled gets in the way of getting things done, but I'm wondering what your position on the opposite is here.
What are your thoughts on 1) Real-world thinking 2) first-principles thining and 3) the balance of each that is ideal in software-engineering?
> Ocaml is designed to get stuff done, and the tooling and ecosystem strongly reflect that.
Haskell was designed to get stuff done too, just maybe not quite the same way. If you ever had an inkling of "maybe people in industry are outright dismissing research too fast" you might like it.
>> If something was going to kill Haskell, it would OCaml, not Javascript or some other language.
> I would feel very comfortable running a business on OCaml, Haskell, not so much.
I'd feel comfortable with either. I agree it'd have to be something at least as strongly typed as Ocaml to kill Haskell as well.
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 that, you're actually talking to a working professional Haskell programmer whose company depends on it.
Are there any languages you can immediately answer these questions for? Are there any popular languages you can't answer these questions for?
I have some ideas, but I want to nail things down a bit more before attempting an answer if you don't mind.
If you're going to accuse me of being toxic, please be explicit with quotes and what specifically was toxic rather than unconstructive allegations.
The problem is that highly valuing "first-principles thinking" is wrongfully attributed to arrogance and seen as "ignoring truths from the 'dirty' mainstream".
The individual selling points are the smaller part of Haskell's USP.
I think spreadsheets are still needed, just more flexible ones like Simon Peyton Jones elastic sheet defined functions:
https://m.youtube.com/watch?v=jH2Je6wUvPs
Perhaps calc implementing that first would be a competitive advantage.
For instance a user in the thread mentioned all background colors can be applied in libreoffice, but in word online some are restricted.
Ux having those restricted colors grayed out by default with a hover note why seems perfect to keep compatibility and show where word online is wonky.
Hope this makes sense, will have to pay or in a better format to the issue tracker tomorrow.
Unless one can supplant the current ".docx" is standard across industry I don't see how your expect others to use a different format.
Personally, I wish odf were the default along with libreoffice.
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 are still welcome, why you think they are important for the business, and your desire to make sure your keeping up with "core functions".
I assume those "boilerplate type" tasks communicate their business value outwardly much better and are known quantities, but do little for your development.
Go code doesn't result in the simplest solution possible.