What does /g/ think of haskell?
It's beautiful.
It teaches beginners the importance of seperating IO from Processing. It teaches the importance of really thinking about what you're trying to do.
It's all right. Prefer clojure myself but to each their own.
My experience has been that lazy evaluation hurts more than it helps. Strict evaluation with laziness annotations would be preferable to me. Other than that, I like it.
I'd write a webserver in pure assembly from scratch rather than writing a hello world in haskell.
It is a meme language with literally no real life use. Don't waste your time learning it.
>>47779835
Zenith kek
Didn't even bother to learn it (yet), but at least it can print and add.
So it's pretty much the future.
>>47779620
Too much syntax for a good idea. People who don't know it fear it, which is great fun.
>>47779835main = putStrLn "hello world"
>>47779995
Only semantics matter.
>>47780092
You've clearly never tried Perl or heard of the Sapir–Whorf hypothesis.
>>47780072
actually, I tried
print "hello world"
and it came out just fine
>>47779640
>It teaches beginners
kek
>>47779620
It truly is really great.
There is very little it gets wrong. Easily one of the best designed languages around.
>>47779815
You can force strictness.
>>47780261
It's commonly taught as an introductory language in university.
>>47780125
Except it had quotes around it, because print turns data into strings using the show method.
all the 1337 meme people use it so its good
weeb language, on the same tier as lisp
All languages have strengths annd weaknesses
Haskell seems not that great for making things like web browsers, operating systems, or games, but I can imagine it being the first choice for some complex computation tasks and scientific applications
I think the creators intended to make a language that was easy to state problems in
>>47782652
>operating systems
https://en.wikipedia.org/wiki/House_%28operating_system%29
>>47779995
>Haskell
>Too much syntax
What. There are lots of arguable complaints people can lob at Haskell, but syntax isn't one of them. Haskell's syntax is lean and sexy.int g(int x) { return x + 3; }
g x = x + 42 -- noiseless function definitions
int (*f(int (*)(int)))(int)
f :: (Int -> Int) -> (Int -> Int) -- a sane type syntax
f(x, y)
f x y -- function application through juxtaposition
Really, just that last one is huge. Spaces are always quieter than parens.
>>47782748
Compare the formal grammar to that of Scheme to see what I mean. The places where whitespace is significant is also quite a mess.
>>47782748
> There are lots of arguable complaints people can lob at C, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at Java, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at LISP, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at PHP, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at JavaScript, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at C++, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at Rust, but syntax isn't one of them.
> There are lots of arguable complaints people can lob at my favorite language, but syntax isn't one of them.
well meme'd my friend :%)
Packages (1) ghc-7.10.1-1
Total Download Size: 68.65 MiB
Total Installed Size: 899.94 MiB
:: Proceed with installation? [Y/n] n
Why is ghc so bloated?
Haskell looks like the most popular ML today but it is 1) lazy; 2) plagued by dependency hell. What ML would /g/ents recommend has neither of these two issues?
>>47783951
OCaml?
>>47782983
years worth of libraries maybe?
>>47782839
It's a fact.
>>47780092
That's what Perl faggots tell themself.
>>47779620
you switch side effects with lazyness memory leaks
>>47784192
Dream on. Haskell syntax is truly shit.
It's a shame the alternate braces based syntax isn't taught.
I prefer F#, but Haskell's cool, I guess. Syntax is really hard to get used to, though.
I'm a chemist but I do computational chem. I use MATLAB but all I've been hearing recently online is Haskell, Haskell for science! It used to be Python. So, tell me, folks, what does this do better than MATLAB?
>>47785661
Nothing. Just keep using matlab if you know it.
>>47779620
It's a somewhat dated and bloated but still pretty beautiful language.
A good first time introduction to modern FP.
>>47780125
That would come out as"hello world", mind. ‘print’ is more of a debugging tool, designed to print a literal code representation of its input.
The proper way to print a string is putStr, orputStrLnif you want a newline.
>>47782652
This is literally the inverse of reality.
Haskell is generally bad for scientific computation or number crunching where abstraction = performance loss, but it's great for web browsers, web servers, operating systems or games where abstraction helps a lot.
Basically, Haskell is all about abstractions - of the languages in mainstream use, it has the most tools to generate them.
So wherever abstractions help, Haskell helps. And for stuff like designing high-level systems, that's a gigantic benefit. It promotes code reuse, code safety, code clarity and makes development and refactoring easy.
The only time it really bothers is when you need to write micro-optimized benchmarks or numerical code. While possible in Haskell, it's generally quite cumbersome.
(Fortunately, you can usually wrap up the cumbersome numerical heavy lifting code inside a good abstraction to prevent any of that ugliness leaking)
>>47786127
This is a good summary. Haskell is slightly mathematical in nature, but terrible for both symbolic and numeric computations. If you insist, look up REPA.
>>47782983
>Why is ghc so bloated?
Mixture of hysterical raisins and other things: https://stackoverflow.com/questions/4858585/why-is-ghc-so-large-big
Also, GHC itself redistributes a lot of ‘core’ libraries and tools, typically the ones it uses as a dependency itself.
>>47786156
Haskell is actually not that bad at high-level symbolic computation, thanks to (G)ADTs and the powerful tools we have to work with them.
This makes the code you write really elegant, in exchange for some constant factor compared to C.
>>47786202
Call me when Haskell can carry out RIsch algorithm.
>>47786230
What makes you think Haskell is any less suited for an implementation of the Risch algorithm than C, C++ or whatever else your tools that implement it are written in?
>>47786296
It may not be, but we don't have an implementation or even a symbolic algebra framework yet.
>>47786360
You should implement one.
>>47786372
There's a reason only one open-source implementation of it exists and the related manual is 13 volumes (some tens of thousands of pages) long.
http://www.axiom-developer.org/axiom-website/documentation.html
>>47786360
That's not a fault of the language, I think.
Haskell makes manipulation of algebraic trees much easier than most other languages, especially ones like C and C++.
For a simple example, something like this: http://5outh.blogspot se/2013/05/symbolic-calculus-in-haskell.html
While not very impressive in terms of capabilities, what's impressive here is how easily we can work with expression trees in Haskell.
That's just the basics though; going beyond that we have tools like Traversable, Data.Data.Data, Plated, syb, lens etc. which make it trivial to work with nontrivial data structures like DUAL trees in an efficient manner.
It's probably the best language for stuff like Project Euler
I like it, it's satisfying to code in, but could never build anything particularly useful in it
>>47786127
There are actually instances where powerful static safety is *beneficial* for performance, rather than detrimental.
For example, Haskell's purity allows it to easily work with advanced GC techniques or threaded I/O in ways that impure languages can only dream of.
(That's one of the reasons why Warp performs so much better than nginx - purity allows it to avoid copies of inputs and parallelize for free without requiring shared memory modification)
Another example is stuff like https://github.com/ekmett/discrimination, which allows for free O(n) sorting and partitioning of arbitrary data structures using arbitrary equivalence relations without requiring quotient types.
Type inference is just based.
Haskell is an experiment in making a functional language that is optimized for lazy evaluation. Hardly anyone who uses Haskell is aware of this and if they are they actually think this experiment worked (the designers of the language are very open about the fact that the experiment failed). So Haskell is basically the Arch Linux of programming languages where people enjoy fixing problems that dont really need fixing.
Lazy by default is considered harmful.
>>47779620
Academic garbage with no practical real world application.
>>47779620
Meme language used by people who understand so little about computers that they think minimizing state change as much as possible is somehow a good thing.
Laziness by default is pointless
Obfuscates performance characteristics
Global exposure of record accessor functions is pitiful
Library documentation is conventionally terrible
Has a culture of overengineering and complicating simple ideas that's worse than "enterprise" Java
GHCI type error messages are often as bad those from C++ templates
Pure functional programming doesn't map to how computers actually work
Cabal sucks
>>47787418
>type error messages
All true except for this one.
It becomes clear when you understand what an occurs check is in unification.
>>47787418
>Laziness by default is pointless
Laziness by default + selective strictness is cleaner theoretically and syntactically than strictness by default + selective laziness in terms of programming semantics.
That said, I think that data constructor fields should be strict by default. That would be the best compromise.
>Obfuscates performance characteristics
I can agree with this. It's harder to reason about nonstrict code.
>Global exposure of record accessor functions is pitiful
“Global” is a strong word here. Haskell is based on namespaced modules. I'd call them “module-wide”, if anything - but the same is true for all functions.
Also, it's not like Haskell developers have been sitting around on their asses doing nothing about it: https://ghc.haskell.org/trac/ghc/wiki/Records there are at least 11 concrete proposals to resolve this situation, the “winner” of which has ALREADY been implemented in GHC, but not merged into any release yet.
>Library documentation is conventionally terrible
Disagree, virtually all libraries end up documented (via haddock) on hackage, it's a rather small minority of libraries that don't have adequate documentation in my experience.
>Has a culture of overengineering and complicating simple ideas that's worse than "enterprise" Java
Strongly disagree. The Haskell culture is based on recognizing patterns and abstracting them when found. We don't just sit around saying “oh, I wonder how I could reinvent the wheel in a more complicated way!”. We sit around and say “Look, I wrote this same function in 10 slightly different variants for 10 slightly different use cases. I wonder how I could merge them all into a single implementation in order to avoid code reuse and reduce the potential for error”.
Big difference IMO. Also, unlike Java, Haskell can actually into abstraction and polymorphism.
>>47787418
>GHCI type error messages are often as bad those from C++ templates
From what I've seen, GHC type error messages are only confusing to those unwilling to read them. Just because a type error spans 10 lines doesn't make it complex and confusing - it just means it contains 10 lines of helpful suggestions and probable causes.
GHC type errors are actually some of the most helpful type errors I've come across; meanwhile type errors in C are often true nightmares due to the complete and utter lack of proper type inference in C.
>Pure functional programming doesn't map to how computers actually work
And yet GHC+Haskell manages to consistently outperform stateful imperative languages like Python, Perl, Ruby, PHP etc. by an order of magnitude or two? Gee, I wonder why. Oh right: Because of strong static typing, which is ironically what lets it actually be COMPILED, unlike most imperative languages.
Even on top of that, it's still complete bull shit - x86 is not the end-all definition of how a computer system should operate. What if I constructed a processor that did graph reduction natively and then showed you benchmarks of how slow C executes on it while complaining about how “state transitions simply aren't how computers actually work”?
>Cabal sucks
Great argument!
>>47779620
Why is haskell uncommon for "real life" applications?
>>47787717
Because Haskell (and FP in general) is currently mostly used in sectors not exposed to the end user.
If I had to come up with a reason, I'd say the biggest contributing factor is the fact that end-user applications tend to be rather trivial, small, constrained programming problems; designed to run on one system, typically even on one core; and if something crashes it's not too bad.
Haskell is seeing adoption for internal server backends, control systems or tools, which is how Facebook, Google, Ericsson, Nokia, banks etc. are starting to use it.
See eg. https://wiki.haskell.org/Haskell_in_industry for more examples of companies using Haskell internally, but not externally.
>>47779620
Still don't know what functional programming/10
>>47787761
interesting.
I've been learning haskell for a few weeks know and I think it's awesome but I had no idea why it isn't used more widely.
>>47787783
*now
>>47787685
>Disagree, virtually all libraries end up documented (via haddock) on hackage
Good documentation is more than the usual list of uncommented function signatures that ends up on hackage most of the time.
>>47787761
Also, I asume you are more experienced with haskell than I am, so do you mind if I ask If you know any category theory?
>>47787816
Meh, depends on the library. Most of the time I think the function names + signatures are sufficient documentation.
>>47787821
I know an intermediate amount of CT, but I mostly use it in the context of Haskell - not outside it.
(I'm also happy to answer any questions, Haskell, CT or otherwise)
>>47787685
>“Look, I wrote this same function in 10 slightly different variants for 10 slightly different use cases. I wonder how I could merge them all into a single implementation in order to avoid code reuse and reduce the potential for error”.
To be fair, this is what Java devs that build factory factories think about as well, they're just killing code duplication through an abstraction.
The problem is that this sort of abstraction barely reduces code duplication and makes code harder to read. If you abstract too much, your code becomes too hard to understand.
>>47779620
One of the best realizations of the functional paradigm.
>>47787844
>The problem is that this sort of abstraction barely reduces code duplication and makes code harder to read. If you abstract too much, your code becomes too hard to understand.
There are multiple points of consideration here.
First of all, in general we're talking about the trade-off between abstraction cost and reimplementation cost. I agree that languages like Java have a very high abstraction cost, usually just as high (if not higher) than the reimplementation cost. This is because the type system and overloading mechanism in Java are very weak.
In Haskell, the abstraction cost is generally much, much lower - which is why we can get away with much more abstraction that still ends up cheaper than the reimplementation cost. However, I agree that it's not universally true.
In fact, Haskell has seen its own share of “abstractions not worth the cost”, a good poster example being recursion schemes: https://hackage.haskell.org/package/recursion-schemes-4.1/docs/Data-Functor-Foldable.html
(In fact, we get our own version of AbstractSingletonProxyFactoryBean from it: zygohistomorphic prepromorphisms. The difference of course, being that the former is a serious component of a serious package, while the latter is a joke used to demonstrate the abstraction fallacy)
tl;dr nobody uses recursion-schemes, no matter how “elegant” they may be - because they're more expensive and harder to understand than just writing the recursion directly.
And I think this is a trend that most Haskell programmers share - I don't know many Haskell programmers who are over-eager to abstract. In fact, most try to use it only where the gains are higher than the cost (eg. see the “Fairbairn threshold” often cited in the Haskell community)
>>47787844
>The problem is that this sort of abstraction barely reduces code duplication and makes code harder to read. If you abstract too much, your code becomes too hard to understand.
Also, I think this goes both ways - and which way it goes is a sign of whether or not your abstraction is good or bad.
It's certainly true that bad abstractions exist, just as there are bad programmers. I think that's unavoidable.
However, there are also plenty of good abstractions, where the abstraction makes it MUCH easier to work with code.
For example, when sequencing together and parsing streams of data, it's MUCH easier to read, write and understand high-level code likesource >-> process >-> processMore >-> consumerthan it is to understand a 10-line block implementing manual looping and error handling.
>>47787833
How much CT do you consider is essential to become a better haskell developer/programer?
The greatest EDSL host ever made. Thank you based do notation.
>>47787973
Nothing is essentially.
What you will learn, you will learn automatically because it's useful. Nobody's forcing you.
>>47787953
I agree - but I personally often spend too much time abstracting things that maybe wouldn't even need abstraction. I consider this a bad habit because I waste a lot of time, often make my code harder to understand and barely gain anything from it in the end.
Some abstractions, such as the streaming abstraction you mentioned, are absolutely beautiful. I wish I was able to properly decide when an abstraction is worth it and when it isn't.
>>47788021
Agree absolutely. Being able to figure out when something is worth abstracting, and if so, how far, is one of the things that can ONLY be learned with many slow years of programming experience.
A college course may be able to teach new programmers *how* to abstract using CT and/or singletonproxyfactories, but there's no course that can teach you when it's a good idea.
>I consider this a bad habit because I waste a lot of time, often make my code harder to understand and barely gain anything from it in the end.
I don't consider this a bad habit. I consider it a learning experience. The best way to realize when an abstraction is not worth it is to try it and find out.
The only thing you have to be willing to do is recognize your mistakes and learn from them, so in the future you won't make the same mistake in the same situation.
>>47788009
I was asking because next semester I have the option to take a CT course but i maybe too much just for haskell, guess it won't hurt a nd I'll take it anyways.
Finally, do you recomend any particular material for learning haskell? besides LYAH and RLH.
thanks m8.
>>47788073
Alright, thanks, this is good advice.
>The only thing you have to be willing to do is recognize your mistakes and learn from them
I think that if you spend too much time abstracting things unnecessarily, even considering the "cross the line to learn where it lies"-argument, you become more immune to realizing when you are abstracting too much.
I guess most programmers, including myself, tend to build too abstract code because it is really difficult to pragmatically decide if an abstraction is too complex when you are writing code yourself.
>>47788132
>I was asking because next semester I have the option to take a CT course but i maybe too much just for haskell, guess it won't hurt a nd I'll take it anyways.
I would definitely consider that in complete isolation of Haskell - take the CT course if you think you will enjoy CT, not because of any relevance to Haskell.
(My best heuristic for that is: Do you love systems with strong structure (like abstract algebra or type systems)? If so, CT will be right up your alley)
>Finally, do you recomend any particular material for learning haskell? besides LYAH and RLH.
I don't like RWH as much, but LYAH is what I started with as well. My best resource recommendation for learning Haskell would be #haskell + programming. Try programming something. If you get stuck, ask on #haskell. If you finish it, show it on #haskell and ask for critique. You will learn a lot.
Also, just idling and reading #haskell is often a great way to learn new things. If something's over your head, ask or look it up.
>>47788166
>you become more immune to realizing when you are abstracting too much.
Agree, I do see people falling into this pithole in reality. For example, one of the greatest Haskell programmers I know is a bit out of touch with reality by now. He's been contributing so many category theoretic abstractions, that he then himself proceeds to use, that it's become his default mode of communication and documentation.
‘lens’ is perhaps my best example. In my opinion, it's one of the most powerful abstractions on hackage - and one of the most influential packages in recent times that simultaneously also draws very, very deeply from category theory.
The person who gets the butt-end of this combination is the newbie Haskell programmer trying to understand ‘lens’ type signatures and errors.
>it is really difficult to pragmatically decide if an abstraction is too complex when you are writing code yourself.
It's also even more difficult to let “great ideas” die.
>>47788132
CT is fun and all, but in my experience it feels a bit pointless just to study CT with no specific application in mind. Enter with the mindset that you're going to use it for some other subject (algebra, logic, functional programming, linguistics, whatever) and it will be much easier. A good course will give you motivating examples and applications from all of these subjects, but it helps to have a favourite one to lean back on.
>>47788261
An example of the ‘lens’ thing I mentioned.
“Choice” is one of the most important underlying type classes inside ‘lens’, since it's used to abstract over constructors and constructor-like things.
So what if you get a type error involving a Choice constraint and, as a newbie Haskell programmer, decide to look up what it actually is?
You see this.
>>47788261
>It's also even more difficult to let “great ideas” die.
Especially if you have spent quite a lot of time implementing and thinking about your great idea or experimenting with your great idea.
I hate the feeling of rebuilding code I specifically refactored to see if a "great idea"-abstraction is really worth it because I realized that it's stupid as fuck or trashing code that I thought about a lot but just isn't worth it.
autistic NEET of languages
>>47780261
literally my first language
>>47788319
Fortunately, in this case, the type signature itself is way, way more descriptive than the paragraph before it, especially if you already know what a Profunctor is.
>>47786081
>print’ is more of a debugging tool, designed to print a literal code representation of its input.
not really.print :: Show a => a -> IO ()
print = putStrLn . show
>>47788388
‘show’ is a debugging tool, designed to return a literal code representation of its input as a string.
>>47788397
>‘show’ is a debugging tool, designed to return a literal code representation of its input as a string.
You're kind of right. It was more about cheap serialization. On the kind that it should had respected 'read . show = id'. Doesn't matter that much anymore because we have better serialization classes around.
>>47788319
Yeah, Ekmett goes a little too far on the CT-centric documentation.
I'm currently learning Haskell (as in a complete beginner). I've got to say, I think I love it. It's certainly very different from anything I've done before.
>>47788440
No, Show/Read was never proposed as a cheap serialization tool.
We have cheap serialization tools, and they are not Show/Read.
Show was intended as a convenience type class for human display of values. The primary motivating use case, for example, is the REPL - Show is needed because the REPL needs *some* standardized way of transforming data types into a human-compatible representation.
The ‘read . show == id’ thing is also part of that - it should be possible to easily paste around the output of a REPL, perhaps even using it in another line of code.
Show was never proposed for use in actual larger-scale scenarios where you need either serialization OR string-based user interaction. For those, stuff like Binary or Doc exists. GHC uses something like Doc internally for its own prety-printing, for example.
>>47788495
>Show was intended as a convenience type class for human display of values
I should clarify: low-overhead/cheap human display of values.
This often comes at the expensive of beauty, eg. for ADTs the Show instances can get pretty hard to read, pretty quickly.
>>47788492
>iktf
>>47788495
I don't like to argue, but it is right into the gentle haskell tutorial https://www.haskell.org/tutorial/stdclasses.html
> We refer the interested reader to §D for details of the Read and Show classes.
>We can test the Read and Show instances by applying (read . show) (which should be the identity) to some trees, where read is a specialization of reads:
>read :: (Read a) => String -> a
>This function fails if there is not a unique parse or if the input contains anything more than a representation of one value of type a (and possibly, comments and whitespace).
This is also instigated by the definition of the haskell report 98 : https://www.haskell.org/onlinereport/derived.html#derived-appendix the default instances for read and show and the forms it should do so. They didn't write directly (show . read = id) because it would mess recursive ADT, fixity declarations and associativity.
>>47788591
Ah, yes; I don't mean to dispute that “read . show == id” is a thing that is indeed considered a useful property.
But personally, I think that's just a specification that concerns Read, not so much Show. Show is more useful than Read and had a justification for existence of its own - I feel Read is more of an addition “to do the opposite of Show”.
>>47788591
>(show . read = id)
This is not really possible, incidentally - only up to equivalence defined by ‘read’.
The reason is that “[1, 2]” and “[1,2]” both parse to [1,2].
The only reason functional languages exist is because computer science was borne out of pure math, and so there were lots of mathematicians hanging around, and they though that imperative languages were inherently confusing because they were different from math. I.e., in math, when you say x = 4, you can't say x = 5 on the next line, stuff like that. Also the love for recursion over iteration. To a pure math person who wants to write their programs as proofs, it makes sense. But if you're not a mathematician, it probably won't seem inherently easier, and it certainly doesn't reflect how the hardware works either.
I don't really see the point of most of it, but maybe I'm just "ignorant."
>>47788649
Some Lisps actually guarantee read . show = id (although not show . read = id for sanity).
>>47788707
For me, it's purely the fun of trying something different.
>at work
>oh shit, the creator of haskell died
>fellow programmer looks over
>what's haskell?
IT grads
>>47788707
Functional languages just attempt to destroy complexity where none needs to be.
There is mostly no need to specify the order in which operations happen, being able to declare the solution without considering the order is way easier.
There also is mostly no need for mutable state, so using it in places where it is not necessary also makes it harder to understand how a certain piece of code behaves.
I don't think it's just easier for people used to maths, some functional features are less powerful while others absolutely defeat their imperative counterparts in every way possible (streams for instance: shorter, declarative, stateless, easily parallelizable, easier to read).
>>47788707
I don't agree with your general sentiment.
Most imperative programming concepts were also born from math - for example some of the earliest attempts at modeling computation in general is based purely on state transitions (finite state machines, turing machines, etc.). Mathematicians have been perfectly fine reasoning about them.
>But if you're not a mathematician, it probably won't seem inherently easier
I don't agree with this. There's plenty of evidence to support that teaching functional programming to first-timers (eg. kids) is picked up just as quickly, if not quicker than imperative programming.
>and it certainly doesn't reflect how the hardware works either.
This is not some fundamental principle, it's simply the way silicon design has evolved. It's just as possible to build hardware graph reduction machines, eg. see the Reduceron project for working FPGA designs that run Haskell “natively”. It just hasn't seen nearly as much funding or study as imperative programming and classical chip design has.
FP is still an emerging technology, often times out of necessity. For example, at my university we're working on a collaboration with Nokia to develop a new functional language for their internal telecommunications backends, since their classical imperative approaches can no longer scale to meet the new challenges the way Erlang and Haskell can.
>>47788707
>I don't really see the point of most of it
There's a cure!
http://shaffner.us/cs/papers/tarpit.pdf
>>47785035
>braces syntax
I found the Cfag.
>>47788707
Haskell (not FP in general) is about realizing that artificially restricting yourself makes it much, MUCH easier to reason with and transform code, which helps write better libraries, better compilers and safer code.
I mean, at the core, the fundamental principles of Haskell are:
1. you no longer have side effects
2. you no longer have state mutation
3. you have a very strict type system that tells you what you can and can't do
4. you can no longer even specify *when* code gets executed
By giving up all of those, you give the compiler great freedom to transform and optimize your code.
Apart from compilers, another thing that this enables is being able to integrate low-level hackery and high-level semantics in a clean way. For example, we can design “efficient” abstractions like ST, ‘reflection’, ‘discrimination’, ‘repa’ or other examples, which all use stuff like unsafeCoerc, unsafePerformIO or other hackery under the hood - but ensure that the user can't possibly break anything by using guarantees about Haskell's purity and type system.
This is the only reason they are allowed to interface with arbitrary code while requiring no guarantees about said code from the user, with zero risk of breakage or undefined behavior.
>>47788707
>and it certainly doesn't reflect how the hardware works either.
Yet the world swear that OOP is the right way.
>not making all of your functions one-linerspopulateTags :: Connection -> Image -> [String] -> IO Image
populateTags conn (Image id title ext hash _) tagNames = single <$$> mapM (Tags.getByName conn) tagNames >>= return . (Image id title ext hash) . map fromJust . filter isJust
>>47789724
No. Great example of a function that would be much more readable as a do-block.
>>47789724
Holy shit, this function could be written so much cleaner and nicer.
Seeing bad Haskell code makes me want to cry. ;_;
>>47789754
I'm mostly shitposting with that function, but I'd appreciate some help if I can make it cleaner.
Here's the actual version:-- | Takes an image without any tags and a list of tag names and populates that image with tag entities from the database.
populateTags :: Connection -> Image -> [String] -> IO Image
populateTags conn (Image id title ext hash _) tagNames = do
tags <- fromMaybe <$> single <$$> mapM (Tags.getByName conn) tagNames
return (Image id title ext hash tags)
where
fromMaybe = map fromJust . filter isJust
>>47789817
First of all, you don't seem to be using the (Image id title ext hash) bit at all, instead you seem to be simply modifying the ‘tags’ field.
For this kind of scenario in particular, I would personally start by using the ‘lens’ library, which makes ‘update a single record’ stuff like this easier to express.
Apart from lens, you could eliminate that portion of the code by essentially making it more like this:populateTags conn img tagNames = do
...
return img { tags = val }
Second, ‘map fromJust . filter isJust’ is pretty bad style. It's much better to write something like this:[ v | Just v <- xs ]. (No partial functions, no boolean blindness)
What is ‘single’ in your example?
>>47788707
You are ignorant, but we've all been there.
You're right that it doesn't seem inherently easier and certainly doesn't reflect how the hardware works.
But as you encounter common problems and their elaborate workarounds, where you can see the solution but not implement it in your paradigm, there you might find some piece of fp slides into place.
