[HN Gopher] Dhall: A Gateway Drug to Haskell
___________________________________________________________________
Dhall: A Gateway Drug to Haskell
Author : todsacerdoti
Score : 99 points
Date : 2022-06-07 18:59 UTC (4 hours ago)
(HTM) web link (www.saurabhnanda.in)
(TXT) w3m dump (www.saurabhnanda.in)
| agentultra wrote:
| Neat article!
|
| Haskell _does_ have escape hatches though! They 're incredibly
| annoying to use: being both noisy and easy to spot. This forces
| developers to justify their use because it's going to be
| _annoying_ to maintain. This is _exactly_ what you want in an
| escape hatch! Not _convenience_ but _being easy to spot_.
|
| If it's easier to do it the Haskell way then you're often on the
| right path. Going off the path is dangerous and some times
| necessary, so don't hide it and make it easy to miss!
| wolfspaw wrote:
| I prefer the pragmaticality of Rust, or even it's father Ocaml,
| than the Over-the-top-abstractly Haskell.
| wrnr wrote:
| But what is Dhall? Ok yes, something that helps you write config
| files because Kubernetes is a pain. I am not a DevOps person so I
| can't always empathise with the problems DevOps deals with on a
| daily basis. That something is written in Haskell for Haskell
| sake is not something I care about. Not that I dislike Haskell,
| PostgREST is written in it and that is one of the coolest and
| most productive things I know about, and it does not ask me to
| learn Haskell (just a lot of SQL).
|
| How does it compare to something like CUE[1] which uses a lattice
| algebra to weave config files and code together to manage
| different configuration environments similar to how some
| computational-algebra-system use pattern matching and rewrite
| rules to encode mathematical knowledge.
|
| [1] https://cuelang.org/
| gregwebs wrote:
| IMHO cue is generally better for complicated configurations,
| including Kubernetes. Dhall has some nice features though. In
| particular the ability to import other files as semantic hashes
| seems like a great feature.
|
| To manage configuration you also need a system to understand
| the state of the configured system so that when you delete a
| configuration you can reconcile that with the system. So then
| it becomes more practical to use Pulumi with TypeScript. It
| would be nice if there was a separate state reconciliation
| system that one could adapt to use with Cue or Dhall or any
| other frontend.
| picozeta wrote:
| In my opinion Haskell's capabilities to help implement general-
| purpose SW (services, compilers, GUI, game-dev, systems) are way
| over-hyped.
|
| Sure, it's nice to implement parsers/compilers in it (see Nix,
| Elm, DHall) and it's to some extent popular for backend web
| development, but I don't think the strong static type system is
| such an advantage as advocates want you to believe.
|
| Of course it's safer (and faster) than dynamic languages like
| Python (Ruby, JavaScript), but in my personal opinion, you don't
| gain that much if you compare it to something like Rust, Java or
| even Go.
|
| In particular the common abstractions (Monad, Applicative,
| Functor) are used very differently in different libraries
| (everyone seems to want to write her own DSL), so it's hard to
| get comfortable with third party libraries.
|
| Furthermore it's still the case, that there's not much really
| interesting SW made in it. Some years ago you could argue, it's
| because of familiarity, but (static typed) functional programming
| is part of CS curricula for at least 10 to 20 years now.
|
| Lastly it's just incredible hard to estimate runtime
| characteristics (clock-time, memory usage), because you never
| know which compiler optimizations kick in or not.
|
| It's a nice language, but again, I don't think it's such a
| panacea as proponents often tell you.
|
| And to be snarky: If Haskell is such an advanced language to make
| implementing reliable SW such a breeze, it _should_ be part
| (maybe as a dependency) of more SW.
|
| EDIT: Nix is implemented in C++ as correctly pointed out in a
| comment.
| sa46 wrote:
| Dan Luu has a take on this: http://danluu.com/butler-
| lampson-1999/
| picozeta wrote:
| Thanks, interesting article.
| mastazi wrote:
| Interesting take but I find the RISC argument to be
| completely flawed in light of ARM/M1.
|
| Even accepting the distinction (which I don't agree with)
| between "non RISC-y" ARM (v7 and earlier) and "RISC-y" (v8
| and later), Apple M1 is "RISC-y" by that definition
| (instruction set ARMv8.5A)[1]. And it's doing well.
|
| [1] Line 256 https://github.com/llvm/llvm-
| project/blob/main/llvm/include/...
| klelatti wrote:
| It's a really odd take given that by 2015 Apple was already
| on Arm v8 for the iPhone and the performance gains over v7
| were clear. Calling it 'hopeless' seems incredibly wide of
| the mark.
| rowanG077 wrote:
| I only agree with the runtime characteristics point. It's very
| hard to get an idea of what is efficient or not sometimes. But
| on every other point I believe Haskell is magnitudes better for
| general software development then mainstream languages.
| picozeta wrote:
| That's my point (sry I edited my post, when you already
| replied).
|
| It's a good programming languages, but being "magnitudes
| better" is absolutely not true in my experience.
| amelius wrote:
| Perhaps the ideal language is then a combination of two
| approaches: Haskell in the outer loops, Rust in the inner
| loops?
| marcosdumay wrote:
| The Python code using C libraries you get on machine
| learning is a nice model. There is no reason why you can't
| recreate it with Haskell + Rust.
|
| But it has one drawback that it's relatively slow to pack
| stuff to send between languages. On Python everything is so
| slow that this doesn't make much of a difference, but on
| the Haskell + Rust scenario you will want much larger
| library blocks.
| lopatin wrote:
| Thoughts and prayers to all the people whose heads just
| exploded by reading that Haskell doesn't gain you that much
| compared to Go. (I tend to agree)
| sidkshatriya wrote:
| > Sure, it's nice to implement parsers/compilers in it (see
| Nix, Elm, DHall) [...]
|
| Nix is implemented in C++, not Haskell
| picozeta wrote:
| Oh, I thought it was Haskell. Thanks, fixed.
| skavi wrote:
| > functional programming is part of CS curricula for at least
| 10 to 20 years now
|
| My school (UIUC) only just added a functional programming
| course to the CS course map in 2021. Of course you could always
| take a functional programming course if you wanted to, but not
| many do.
| lopatin wrote:
| Interesting. I graduated a decade ago and remember taking
| CS421 where you implement part of an OCaml compiler in OCaml.
| I thought that it was required because I don't think I would
| have chosen it myself. It ended up being my favorite course
| in all of school.
| sfvisser wrote:
| > In particular the common abstractions (Monad, Applicative,
| Functor) are used very differently in different libraries
| (everyone seems to want to write her own DSL), so it's hard to
| get comfortable with third party libraries.
|
| I don't see how this is true. These common abstraction make
| reading code incredibly easy most of the time. Many Haskell
| libraries are based on compositional building blocks. Seeing a
| monoid, functor or monad instance gets you 90% there in
| understanding the usage. It's really _the superpower_ of
| Haskell that I miss (and badly reimplement) in every other PL.
| feanaro wrote:
| Completely agreed, but I guess this just doesn't click with
| some people as well as it did with me (empirically).
| agumonkey wrote:
| I wonder if the first point is due to a paradox of advanced
| tools.. society lives around "how do you assemble teams to
| solve big problems", they need organization tricks more than
| logic/language ones. That's why RoR, go, etc win, they allow
| most groups to end up with something workable. Haskell and the
| likes are more about exploration.. not tending to companies
| needs for profits.
|
| About the last point, my tiny observations is that language too
| advanced don't get used as dependencies.. they get ignored
| until the crowd matures enough to get the ideas in their own
| ways and pull a gene transfer.
|
| - lisp idioms (map, filter, destruct) => all dyn langs
|
| - react / vue .. basically let over lambda and closure based
| programming (I even believe vue provide/inject is near equal to
| dynamic variables)
|
| wait until someone there likes to thread state or rng seeds
| through 'chains of functions' and you'll see monads pop up
| nine_k wrote:
| We already sort of see threading state through chains of
| (pure) functions; it's how you write React, especially if you
| use Redux instead of hooks. You lug props around, they are
| explicitly immutable because you always get a copy, and it's
| fine, nobody complains much. It feels logical.
|
| Some more effort in packaging this _ergonomically_ , and
| we'll see purity annotations in TS and explicit passage of
| state objects around.
| armchairhacker wrote:
| Haskell does have advanced tools though. Stack / cabal,
| haddock, htest can be comparable to Rust's tooling. Haskell's
| LSP is making rapid progress and there are many formatters
| and linters.
|
| Tooling still has a way to go, but I don't think that's all.
| Haskell's abstraction is just too much when you need to
| design something which is ultimately kind of straitforward,
| and most apps are (design app, game, utility app, web server,
| etc.)
|
| I do think Haskell is more than a research language, it does
| have some use in practical, mainstream programming. In
| particular, Haskell is great at anything which is "input to
| output", like compilers or document converters. Or in a
| program which is ultimately complex, and not just for
| optimization but "math" complexity, like math programs or
| simulators. In those programs the implicit laziness actually
| comes in handy.
|
| But Haskell for a real-time video game or editor, and you're
| just wrapping everything in an IO monad or some restricted
| stateful equivalent, and executing most of the instructions
| in sequence anyways.
| tinco wrote:
| Why would you wrap things in an IO monad for a real time
| video game? There's a whole lot of code you can do purely
| functionally in video games that can make it very nice.
|
| I've done a couple small projects in Blueprint which is a
| purely functional programming language embedded in
| UnrealEngine 4 and I enjoyed it a lot. Blueprint notably
| does not expose any type classes, at least not when I tried
| it a couple years ago, but it felt very expressive for
| building complex game logic.
| Arelius wrote:
| FYI, Blueprint is very much not purely functional and has
| exposed type classes since it changed from Kismet IIRC.
| Karrot_Kream wrote:
| > I wonder if the first point is due to a paradox of advanced
| tools.. society lives around "how do you assemble teams to
| solve big problems", they need organization tricks more than
| logic/language ones. That's why RoR, go, etc win, they allow
| most groups to end up with something workable. Haskell and
| the likes are more about exploration.. not tending to
| companies needs for profits.
|
| I feel like "not tending to companies needs for profits" is a
| way to elevate Haskell and monadic FP abstractions with
| appeal to conspiracy/(postmodern) ideology. I don't mean this
| to be a pro-or-anti capitalism sentiment, but the excuse here
| is that "in a more just/less captalist/<other> world, Haskell
| would be a great tool, but our flawed world makes it not so"
| and I disagree with that. I just don't think Haskell is that
| good of a tool regardless (and I see the Haskell community
| these days appealing to this take a lot, trying to blame
| anyone but themselves.)
|
| I think that people genuinely don't derive much value from
| Haskell and monadic FP. My experience, having written and
| maintained non-production-grade Haskell code, has been that
| the community is obsessed with toys and small examples,
| derives a lot of pleasure from clever abstractions which
| don't materially affect development (like Lenses), and most
| importantly doesn't really care about shipping software.
| There's exceptions like SPJ and Joey Hess who definitely ship
| useful Haskell, but the community doesn't care nearly enough
| about making it easy to actually produce software that a non-
| Haskell enthusiast would care about using.
|
| Libraries are often created for a Masters project and
| abandoned. Even if a library works, debugging edge cases is
| never thought of. Almost nothing is written about testing in
| Haskell. No two libraries can agree on which monad stack to
| use, so a non-trivial amount of integration code involves
| matching and lifting into other monads (nor the performance
| implications of doing all of this matching and lifting).
| There are very few examples of organizational patterns for
| Haskell codebases for folks trying to create a project other
| than GHC itself, Pandoc, and perhaps XMonad. The community
| loves talking about abstractions and unifying concepts but
| doesn't really seem to have any practical tips about writing
| software. The string types in the language are confusing and
| poorly differentiated. The cabal and stack split is confusing
| and makes no sense to outsiders. The weird cargo-cult
| obsession in the community about category theory from people
| with little formal mathematical knowledge is bizarre. I can
| go on and on, but I don't want to dunk on the language
| endlessly (and I can certainly do this to any language I've
| used in love or anger :)
|
| Fundamentally I don't think Haskell offers the programmer
| much more than what you'd get out of a language like Rust,
| Java, or Go (yes even Go) as the GP said. It's a language
| with a lot of interesting concepts that's fun for folks who
| like to solve algebra problems and is certainly a clean
| introduction to monadic FP. I'm looking forward to a
| successor that takes its concepts, cleans them up, and offers
| a way to write actual software with them. Then again,
| Multicore Ocaml is landing soon...
| rbn3 wrote:
| >Furthermore it's still the case, that there's not much really
| interesting SW made in it.
|
| TidalCycles would like to have a word with you. Easily one of
| the most interesting and unusual pieces of SW that currently
| exists.
| eggy wrote:
| I played with Tidal when it first came out for music. I do
| like it. To me though, I prefer Grace[1] (CM, Lisp) and
| Extempore[2] (Scheme, xtlang). You can work within the
| grammar of music, or you can program your own DSPs. Xtlang in
| Extempore is a pretty neat DSL created by Andrew Sorensen. To
| me Tidal was mainly rhythm-based. I am sure it has evolved
| since then, but it felt like a coding sequencer or pattern
| generator. I liked Sporth, (Soundpipe + Forth), but it
| appears something has occurred on the internets that I am not
| aware of. The repo is still here[3], but it is not being
| worked on any longer from what I have read there.
|
| If interesting and unusual is your thing for generative
| music, check out Orca[4]. That has eaten hours of my time far
| more than Tidal for me.
|
| [1] http://commonmusic.sourceforge.net/
|
| [2] https://extemporelang.github.io/
|
| [3] https://git.sr.ht/~pbatch/soundpipe
|
| [4] https://100r.co/site/orca.html
| aranchelk wrote:
| > Haskell is hard.
|
| More accurately: Haskell is particularly hard for a procedural
| programmer to learn in comparison to a new procedural language
| and the time spent learning prior to being as productive may be
| (from my experience) 30x.
|
| IMO, once learned, the type checking is so helpful, everything
| else seems hard.
|
| Also, learning the language is only half the battle as it's much
| more difficult to establish for yourself good practices for
| common use cases like app development. You'll find plenty of
| people using FP for specialized stuff that's not relevant to the
| average working programmer. In looking for advice you may stumble
| across the promotion of peoples' impractical pet projects, and
| without experience you won't know it.
|
| If you can budget the time to learn the language and then build a
| couple poorly structured apps that you'll come to hate, expect
| very smooth sailing after.
| marcosdumay wrote:
| Haskell is hard. It doesn't need modifiers.
|
| It is harder for people that are used to program in
| incompatible ways, but it's hard for people without a lot of
| experience too, and for people with previous knowledge of
| different paradigms, and for people used to the functional
| paradigm but not to its level of purity.
|
| And learning the language is no half the battle. Maybe some 10%
| if you want to stick with very simply idioms, maybe less.
|
| And if you won't learn the hard idioms at all (instead of just
| not using them 99% of the time like most people do) is there
| even a point on learning the language? At most your code will
| be a bit easier to modify, but you will never get most of the
| value.
| eterps wrote:
| To be honest, after having learned other FP languages like
| OCaml/ReScript, F#, Elixir, Gleam and Elm, I still find Haskell
| baffling. Not necessarily writing it, but I find reading
| someone else's Haskell code insanely difficult. It will take
| many more years before I get comfortable with that.
| yodsanklai wrote:
| I agree. I'm quite experienced with FP, but I find Haskell
| hard, or at least impractical. Not necessarily because of
| abstractions, but some design choices make programs hard to
| read for no good reasons.
|
| > but I find reading someone else's Haskell code insanely
| difficult.
|
| It's true for expert Haskellers as well.
| fn-mote wrote:
| All of my sibling posts: please be specific!! Somebody not at
| your level (and there's more for Haskell than more mainstream
| languages)... like me... isn't going to get what you're talking
| about.
|
| > And if you won't learn the hard idioms at all ... you will
| never get most of the value.
|
| Ok... mention a hard idiom? Even if you don't want to go into
| detail. We'll look it up.
|
| > [...] reading someone else's Haskell code insanely difficult.
|
| I'm wondering if that's because they used a ton of operators
| like (.)(.)(.) or :=-=: (just made that up, i hope), or was it
| because of some deeper reason like too much magic hidden in the
| monad transformers. Anything concrete you're willing to say
| will clear some of this haze of non-understanding.
| AzzieElbab wrote:
| I no longer think all kinds of gateways to Haskell is actually a
| good thing. Once you go through that gateway you are most likely
| to get frustrated and go right back, as evident from other
| replies. People say it's enforced purely functional programming
| is difficult to grasp but I write mostly pure FP in Scala and I
| get frustrated with how difficult it is to build something
| practical in Haskell
| superb-owl wrote:
| I initially tried to learn Haskell by creating a small Physics
| programming project. It was fun, and I found some great math
| libraries, but eventually got frustrated by the slow pace and
| switched to Python. Specifically, the amount of time I spent
| debugging types and signatures was really frustrating, and often
| left me googling the same error patterns to figure out where my
| mistake might be.
|
| I'm excited to try out Dhall and see if it has a smoother onramp.
| DonaldPShimoda wrote:
| > the amount of time I spent debugging types and signatures was
| really frustrating, and often left me googling the same error
| patterns to figure out where my mistake might be.
|
| In my experience, people often describe their first experience
| with expressive static type systems in terms of "fighting with
| the compiler" (or similar phrasing). I think this is due to a
| poor introduction to static type systems, often in university
| settings.
|
| A static type system has one purpose: to prevent you from
| running unsafe code. Every type error is just the compiler
| telling you "what you wrote isn't going to work". This isn't a
| _fight_ ; it's a _conversation_. You write some code, run the
| compiler, get back some errors, fix them, and run the compiler
| again. This process is repeated until your mental model of how
| the code should work is properly reflect in the code, as
| determined by the success of your compiler 's type-checking.
|
| There are frequently two sources of frustration in this
| process:
|
| 1. A difficult-to-use type system.
|
| Some type systems are just obnoxious to use. (Older) Java
| required soooo much verbose typing. The resulting code would be
| difficult to read just because there was so much text on the
| screen. More modern Java is an improvement, but newer languages
| are often designed from the ground up to use _type inference_
| to alleviate your keyboard-typing obligation.
|
| Another form of frustration is what you mention: inscrutable
| error messages. Haskell is pretty well known for having type
| errors that are not obvious to newcomers, and that turns the
| programmer-compiler conversation into a frustrating experience.
| Again, newer languages are making lots of progress here. I
| think Rust does a great job with its error messages, for
| example. Hopefully this is something the Haskell developers
| will look more into.
|
| 2. An insufficiently expressive type system.
|
| If your type system is too limited, you'll have a hard time
| finding it particularly useful. If your types are "too big",
| they become unwieldy and unhelpful. Older languages frequently
| fared poorly in this metric, because "types" were meant
| primarily for memory optimization rather than programmer
| expressiveness. However, as our languages have become more
| user-centered, our type systems have become more expressive
| and, thus, easier to use to model data. Modern languages like
| Rust and Swift have taken a lot of inspiration from functional
| languages like Haskell and ML to provide type capabilities that
| are significantly more expressive than those in other
| languages.
|
| I think type system inexpressiveness is a big part of why some
| people prefer dynamically typed languages, like Python. They
| find that they have a difficult time converting their mental
| model of the data into an explicit type, and so they move to an
| ecosystem where they simply don't have to deal with that.
| Personally, I think this indicates the need for better
| expressive type systems and better type system onboarding to
| teach people how to use them effectively, because if you
| rephrase the static type proposition to those programmers as
| "Would you like to guarantee that erroneous programs are simply
| never run?", I imagine most of them would enthusiastically
| shout "Yes!"
| bmacho wrote:
| > A static type system has one purpose: to prevent you from
| running unsafe code. Every type error is just the compiler
| telling you "what you wrote isn't going to work". This isn't
| a fight; it's a conversation. You write some code, run the
| compiler, get back some errors, fix them, and run the
| compiler again. This process is repeated until your mental
| model of how the code should work is properly reflect in the
| code, as determined by the success of your compiler's type-
| checking.
|
| That's not true. Java or C++ force you to type out the types
| every time to - place constrains inside
| your program (both the caller and the called side) -
| be explicit about it (if anyone else wants to read your code
| later)
|
| E.g x = 5, y = 6, x+y does work in many languages. (Untyped
| languages, or languages with type inference.)
|
| It is an unambiguous command, and many languages would just
| do what you say, instead of forcing you to write code in a
| particular way that has absolutely no use for you.
|
| Being said, I absolutely love Haskell's function type
| notation ( f :: A->B f x = doSomeThing x ), its type
| inference, and how easy it is to alias types. I want this
| notation in every other languages please.
| picozeta wrote:
| > In my experience, people often describe their first
| experience with expressive static type systems in terms of
| "fighting with the compiler" (or similar phrasing). I think
| this is due to a poor introduction to static type systems,
| often in university settings.
|
| Maybe that was true 20 years ago, but most CS curricula offer
| mandatory (static) functional programming classes.
| DonaldPShimoda wrote:
| Depends on the school culture, the professor teaching, the
| particular language being used... there are a lot of
| factors!
|
| I did both my undergraduate and MS in the past decade,
| worked in academic research for a few years, and am
| currently in a PhD program. At the schools I've been at and
| schools I know well due to friends/collaborators, I think
| what I said still tends to be true for mandatory ("core")
| classes.
|
| You are right, however, that students who choose to take an
| elective in a statically typed functional language are
| probably more likely to come away with a healthier
| relationship with their compilers, but this is only a
| portion of all students.
| superb-owl wrote:
| I fully expected to spend time "fighting with the compiler"
| when playing with Haskell. I think the bigger issue was that
| the errors I got back from the compiler were very hard to
| trace back to the code, or to a particular part of my mental
| model that must be at fault. And it didn't seem to get easier
| over time - i.e. the same pattern of error message would be
| due to totally different issues with the model/code.
|
| I'm not sure if this is just a fact of life about FP or
| Haskell, or if it's something that could be improved on.
| DonaldPShimoda wrote:
| > I fully expected to spend time "fighting with the
| compiler" when playing with Haskell.
|
| Well that's part of the problem, is what I mean. If you
| look at it as a "fight", that's often how it will feel!
|
| That said, as I also said, Haskell's error messages tend to
| be more frustrating and mysterious than they ought to be.
|
| > I'm not sure if this is just a fact of life about FP or
| Haskell, or if it's something that could be improved on.
|
| No matter the cause, it can certainly be improved.
| Programming languages have largely not focused on user-
| centered design. Fortunately, there are some recently
| formed workshops seeking to get the ball rolling in that
| area, so hopefully over the next couple of decades we will
| see some significant shifts in the ease of use of popular
| languages!
|
| That said, I think if you had tried a different statically
| typed functional language (OCaml or Scala, for instance),
| you would not be quite as frustrated. But then Haskell has
| my favorite type system among common statically typed
| functional languages, so there's really no winning haha.
| Hopefully it will improve over time!
| fn-mote wrote:
| I also found that my initial understanding of the numeric
| types, based on a traditional imperative programming
| experience, was not sufficient.
|
| However - I now think that I understand Haskell's way of
| looking at numeric types and have not had this kind of problem
| for quite a while.
|
| I will certainly agree that Rust's error messages are 1000x
| better, if you're looking for something similar.
|
| After writing this comment I looked at TFA and I'd say read it
| and maybe even watch the author's talk on "why learning Haskell
| is hard". In spite of what I expected, the article addresses
| the ways in which Dhall is a good starting point. (Although
| readers should be aware that "Dhall is not Turing complete",
| which for most programmers is a bad thing.)
| zingplex wrote:
| I love Dhall and have used it in production, but I will say
| that the documentation, especially for things like dhall-
| kubernetes, often leaves much to be desired. You may need to
| spend a bit of time reading the source code.
| Q6T46nT668w6i3m wrote:
| My experience has been similar. I found that Haskell struggles,
| from a usability perspective, when there isn't a variety of
| diverse types in your program and/or your programs, by their
| nature, rely on the characteristics or behavior of machine
| types. It's not impossible, of course. It just adds an
| unfortunate amount of boilerplate.
| etra0 wrote:
| I recently tried to get into Haskell, while also looking for
| relevant projects written in it on Github and couldn't find
| anything "interesting" (this may vary from person to person,
| obviously).
|
| I was watching a YouTube playlist but I'd rather read something
| like "Haskell by example", or some sort of small apps with
| comments to understand how it works.
|
| I was interested in writing some binary parser in it but I failed
| miserably.
| picozeta wrote:
| Actually writing a self-contained parser (in essence a function
| parse :: [Binary] -> AST) is one of the things where Haskell
| shines. You could use `attoparsec` (and to start off, even
| using the stdlib's
| https://hackage.haskell.org/package/parsers-0.12.11/docs/Tex...
| can get you very far).
|
| And I say that as someone, whose top-rated comment in this
| thread is more or less a Haskell rant.
| etra0 wrote:
| That's cool to know, maybe I should keep trying.
|
| And regarding your top comment, I agree that's quite hard to
| find interesting SW written in it, that's one of the reasons
| I quickly gave up, but I guess it doesn't hurt to learn about
| FP after all, I want to at least write something that works
| before finally decide if it's worth it or not.
| xwowsersx wrote:
| I think OP's point was that THEY failed miserably.
| Presumably, they reached for Haskell to begin with because
| they knew it's supposed to shine for things like writing
| parsers. Maybe they were making a point about learning curve
| or FUX with Haskell...not sure since OP didn't elaborate.
| spion wrote:
| I love Dhall, but I think Optionals might not be a good fit for a
| configuration language, especially one that has to deal with
| Kubernetes
|
| A Dhall joke (those that write a lot of it will get it):
|
| Some foo walks into Some bar and asks the bartender, do you have
| Some beer? The bartender answers: We have None.
| rychco wrote:
| I've seen Dhall mentioned on HN front page twice this past week.
| Is anyone here using it regularly? How has your experience been?
| yarg wrote:
| One nice thing that can be done with pure functional programming
| (not sure what - if any - languages or runtimes implement it) is
| the caching of the results of expensive calls.
|
| If there's any escape hatch to a method/function there's no
| guarantee that the result of f(q) will be a constant.
| alkonaut wrote:
| On escape hatches: being able to do imperative style processing
| is great. A loop-and-mutation is often a much more readable way
| to write what could be written as a fold or (worse) some tail
| recursive method. F# does this very well I think, with imperative
| code sitting quite naturally inside an ML dialect.
|
| More importantly, it allows describing the _how_ (or at least
| something more closer resembling the how) of the computation
| rather than just describing _what_ is being calculated.
| benreesman wrote:
| I'm currently a bit overweight, like maybe 10-15lbs. This is
| because I have some combination of bandwidth-consuming and focus-
| consuming things going on that results in me not doing an
| obviously correct thing: get the fuck back in shape.
|
| Every hacker in the peanut gallery deep-down knows that they
| should know Haskell and Lisp well. They resent the fact that
| their job or personal life or whatever doesn't leave room to get
| serious about computation theory. And they vent this frustration
| endlessly on people lucky enough to have had the bandwidth at the
| right time to thoughtfully contrast computation with physical
| computing machines (the only person I know to stomp Lemire in AVX
| is a GHC hacker).
|
| I'm kinda fat because I haven't fixed it yet. People don't know
| Haskell and Lisp well because they haven't fixed it yet.
|
| Neither is an appealing look.
| sudosysgen wrote:
| Meh. I have had the time to learn a fair amount of Haskell and
| do a few projects in it (mainly interpreters). It's a fun
| language in some ways, and it was nice to know how to use it
| because it expands your ways of thinking, but beyond that it's
| not terribly useful, and I don't think that it's much better at
| that than other functional programming languages. Learning
| about the type-system is neat but IMO not as perspective
| changing as "getting" purely functional programming.
|
| However, as an actual tool to do actual work, I really don't
| see why you would go about it for anything but very specific
| projects.
| feanaro wrote:
| I seriously suspect there is a bimodal distribution are play
| here, because I would love to use Haskell, or something like
| it that's possibly more powerful like Idris, wherever I
| could. And at the same time I notice a lot of people
| expressing your sentiment.
|
| These systems make it easy(er) to model concepts in a
| mathematical way and this is my natural (or preferred?) mode
| of thinking. And they enable you to do it easily and
| ergonomically. What is there not to like?
|
| (I know there are flaws at hand, even some potentially very
| debilitating flaws depending on your use case. But damn, I'd
| use these languages wherever I can.)
| akamaka wrote:
| To take your analogy further, the LISP masters are like ultra-
| fit personal trainers. When they run a bootcamp for out-of-
| shape people, they start off with impractically intense
| exercises and just make everyone demotivated.
| grendelt wrote:
| "Oooooooh! Welcome to Rex Kwan Do! Let me show you how
| superior I am to you know-nothing chumps! Bow to your sensei!
| Bow to your sensei!"
|
| I had some pretty bad language instruction in college, but
| the professor teaching Haskell was the worst. Maybe it really
| was a case of "if you can't explain it simply, you don't
| understand it well enough.", but I remember everyone
| finishing that class (just barely) and nobody ever wanting to
| do use it again.
| exdsq wrote:
| I've worked with Haskell professionally. It was... interesting.
| I'd rather be in shape than deal with Stack/Cabal/Nix again. If
| anyone reading this is wondering if they should learn Haskell -
| wonder if your time could be better spent having a fun and
| active life instead lol.
| benreesman wrote:
| Oh I feel you on the weird effort/payoff curve. I spent
| months wanting to throw my computer out the fucking window
| learning Nix.
|
| But I eventually cracked the code and now it like where is
| deep enough to bury anything running Ubuntu. Let's fucking
| break non-dynamic linking of libc because GNU.
|
| NixOS is fundamentally wrong on a few key points. But it's
| close enough to right to make everything else look
| ridiculous. Who doesn't love never really knowing without
| rigorous audit what is running on my machine that's highly
| optimized for Drepper's career.
| foldr wrote:
| I second this. I think Haskell is a research programming
| language, and in a way I feel lucky that I first learned it
| way back in 2002, long before anyone seriously thought of
| using it for professional software development.
|
| Haskell 98 is a pretty awesome programming language. It's not
| the best fit for every domain, but you can write concise
| readable code in it. The type system is just sophisticated
| enough to let you model your domain, but not so sophisticated
| that it becomes a distraction.
|
| A lot of modern Haskell code has the unfortunate property
| that the types of the functions are harder to understand than
| their implementations. Type inference is much more valuable
| when it's the other way round. You _know_ that [a] - > [a] is
| the right type for the 'reverse' function, so if you get a
| type error, you're sure that you made an error in your
| implementation. Conversely, many modern Haskell libraries
| give rise to extremely complex types, even when you're doing
| something mundane like making an SQL query. When you get a
| type error, it's then anyone's guess whether you misannotated
| a type somewhere or made an error in your implementation.
|
| I personally feel that partial types systems are the way
| forward. Type the 80-90% of your code that's easy to type
| without a fancy type system. Dynamically type the rest and
| write some tests for it. Fancy types make you feel smart (and
| in all seriousness are a fascinating and important research
| topic), but their practical utility is limited IMO.
| ImprobableTruth wrote:
| I agree that gradual type systems are great, but man, I
| feel like the expressiveness of e.g. Typescript is
| fantastic even for 'normal' programming.
|
| Something like fully typed forms (so that e.g. <Input
| type='text' path='address.street' /> only works if your
| form data has a { address : {street : string} } + branded
| types for more custom data fields) is absolutely magical
| and makes working with lots of highly complex forms a
| breeze. Tests just don't compare.
| nh23423fefe wrote:
| Learning Haskell is a mind makeover I agree. People are missing
| the point when they say nonsense like, "well if haskell is so
| great why isn't every piece of software written in it and
| outperforming on all possible metrics?"
|
| That kind of lazy thinking "isn't even wrong." You learn
| haskell to become the kind of person who "has learned."
|
| The ignorant imagine haskell is a promised superpower that will
| under-deliver "productivity gains." It's a new way of thinking
| and building software.
| flakiness wrote:
| Skip the blog and look at the language landing page:
| https://dhall-lang.org/
|
| The blog article talks too much but the language itself seems
| reasonable. Statically typed config languages sound like a neat
| idea to pursue, although I'm not sure how promising this
| particular one is.
| aidenn0 wrote:
| Came here to say that Dhall has the best landing page of any of
| these new config languages that are bouncing around lately.
| pie_flavor wrote:
| > Take Kotlin, for example. It has so many escape hatches that
| someone new to functional programming can end-up writing what is
| essentially an OOP/imperative style Java program, merely in
| Kotlin syntax.
|
| That's... literally the entire purpose of Kotlin.
___________________________________________________________________
(page generated 2022-06-07 23:00 UTC)