I know your comment is relatively old, but fuck it. I don't really understand why a package manager has any business being attached to a language. It seems like a glaring fuck-up in terms of compartmentalization and modularity. What's the point? The package manager should be separate from the language, like apt is separate from C. Apt works great, install packages, use them from C, it's all good. Why do we need to have a special package manager for a language when it really should be an external tool?
@@niktedig853 Hmm, I think I do actually agree with you, but you cannot deny that having the package manager with the compiler is easier to use and more practical.
Ah, but that is too bad for us, because your old Haskell videos are some of them most informative and important videos I've seen. Monoids, IO monads, your explanations were just 👌
+1 to that. I learnt a lot from your Haskell videos on how to use Haskell effectively without getting bogged down by advanced features. However, I only use Haskell for pet projects and offline competitive programming.
@@driden1987 I don't think he used lisp very often. But I do think that lisp is a lot more "Developer Friendly" than Haskell in the way this video points out
@@sebastiangudino9377 Oh no, i don't think it is either. I still want to see more videos from him on those langs :D He did one on clojure which is a lisp dialect in the jvm and he enjoyed it, but it was more for solving a specific codewars problem rather than a whole project on it.
Have you used Haskell/Cabal recently? Things have improved a lot, and there’s a strong emphasis on making the tooling around the language much better for commercial use. Obviously I’m biased, Haskell has been paying my bills for most of the past decade, but because of that, I have seen the huge effort that’s gone into improving things. It’s also worth remembering Haskell is relatively old, so the designed of tools like Cabal were amazing in their time, but newer languages have made improvements from having a clean slate.
@@godnyx117 I'm sure cabal / stack could be redesigned, but that has two big problems: 1. Backward Compatibility (existing packages have to support Cabal & Stack - now they will also have to support the new, re-designed package manager). 2. Community Fragmentation - there are already big debates around Cabal vs Stack - adding a third option is not going to help.
@@sohangchopra6478 1. The oldest problem. Now take my opinion on this with big care. I think that backwards compatibility should never be kept. It keeps projects for truly improving and getting better. This is the approach OpenBSD takes (from what I heard) and the reason that while it's far beyond Linux (at least in regular desktop usage), it's catching up with each version. And that's another reason software have "maintenance". But in any case, people can still use the old version of the project if they want and if they cannot for some reason update. But again, this is just my humble opinion 2. The fact that the community is split between these two says it all! The fact that there is not one tool that the majority of the community likes and uses means that none of them are good enough. So we need to either add a new one (probably not) or re-design on of the existing ones to eliminate its flaws. Again, these are just my opinions, there is no right or wrong. In general, this is the approach I'm thinking to follow with my programming language and its tools.
Dependency Roulette is the most fun game for anyone who is tired of C's packaging brilliancy and just want to mess around with XML, JSON, or cabal files guessing which version of which package is compatible only to find out it was out of order. If you were missing stress in your life, this is totally the game for you!
@@max3446 What does theoretical computer scientist even mean? The entire field is practice basically. I don't think you can call the people implementing a real world production compiler theoretical anything.
@@harry3life I'm talking about the backgrounds of those originally involved in the design of the language. Simon Peyton Jones, Philip Walder, etc. All (originally) academics with backgrounds in language design and semantics, so it's natural that the beauty of the language itself will take precence over creating the most convenient tooling (something which from their prespective is/was probably just a necessary evil).
I never even tried doing anything except abstract problem solving in Haskell despite it being my favourite language of all. Somehow python, go, c++ just naturally feel far better for application development - which sadly is often far from elegant.
Yeah, I'm starting to think the only way to get things done is to learn to be comfortable with ugly code. You can make it beautiful after it works but lets be honest, you probably won't.
2 года назад
@@timwhite1783 "Learn to be comfortable with ugly code". See "Perfect is the enemy of good". And of course, "You can make it beautiful" brings to mind Knuth's "Premature -beautification- optimization is the root of all evil." and the old principle "first make it work, then make it right, and, finally, make it fast" (as quoted from an article in a 1983 issue of BYTE by Stephen Johnson and Brian Kernighan).
Haskell being your favorite language despite not having done anything besides "abstract problem solving" in it, tells me you're just fangirling over it and it's not a serious or substantive opinion.
@@jadetermig2085 and your comment tells me you've never used Haskell or have the IQ to use Haskell. A Haskell enthusiast might not be able to get an actual production ready app out not because he doesn't have any experience in production or enough experience with Haskell but it has more to do with the poor ecosystem and tooling of Haskell.
How amusing, I'm using your parser as a project to orientate myself into how you actually go about development, and here you refute the language. Ultimately I suppose most people who wish to work in Haskell are more interested in a new way of thinking, rather than creating working solutions.
If you can somehow make your way out of the build process and packaging mess, sure you can get something working. I myself am trying to use Haskell as backend server script, tried multiple Haskell wed frameworks, only one was easy to quickly set up and get some work done right off the bat. As he says, such an elegant sexy language but God awful tooling.
Haskell seems to be split between super-mathy research people . . . and people who want it to be a working programming language. Alas. And even the mathy stuff about Haskell seems very often one-off and lost-in-the-weeds. Evidence: Bad docs that are not much better than stream of conscience/reference dumps. Haskell needs a big, centralized effort to deal with all this fragmentation. But then there's also this feeling that it's just the temporary "base camp" of some great assault on category theory, that Agda is the true "peak" language. Fragmented and schizoid is Haskell for sure.
Good thing you mentioned documentation. That's one of the most frustrating parts of trying to get into Haskell. I don't mind reading a bit of theory, but to the point where you need HOURS to learn how to do something completely abstract which seems like necessary to actually just write simple applications, that's insane.
@@beauteetmusculation8191 There's a lot of programming environments, projects out there where you're pretty much on your own having to read source code. Haskell is definitely like that. I think lots of contributors just think you need to read the code because that's the league you're playing in. So yeah, Haskell is big in the academic world -- and they're not about writing O'Reilly books. I think the "center" of Haskell can be seen in _The Haskell Road to Logic, Maths, and Programming_ by Doets and van Eijck. It's sort of an answer to Paulson's _ML for the Working Programmer_ which is a seminal CS text. _Haskell Road_ really complements the discrete stuff you learn in a CS program.
What don't you like about the tooling (if that's what you mean?) Poorly documented libraries to me seem the worst aspect, trying to write in any language, except maybe C, these days seems to have a tooling issue in general where you're overloaded with choice and can't just do some coding. Nix could probably solve your issues, and introduce a whole bunch more :P
as someone who uses nix. You only start to make back the time invested in nix once you use it for everything and idk if it will be worth it for most people without many more years of maturation unfortunately
Interesting point you make there. I just got into functional programming a year back, explored elixir. Felt disappointed for lack of type system. Was peeking my interests in Haskell, although it was ocaml first. What functional programming language would you recommend for backend use?
I’ve felt that same want coming from Elixir. I tried using Crystal, you can do functional programming, but it’s not immutable by default; if I remember correctly, there are mutable and immutable update functions for arrays, and I always just used structs and instantiated a new one. I haven’t gotten around to doing performance tests. Other than than, I just saw the Kotlin library Arrow, which seems to have a similar feature set as scala’s Cats library, supporting monads and for comprehensions, optics, etc. Ahh, I also wanted a language that could just compile to an executable, and it seems there’s kotlin native which can support that, rather than having to run it on JVM.
I'm doing backend stuff with F# at the moment, it's not half bad. That being said, have you looked at IHP (Integrated Haskell Platform)? I've only played around with it but it's very cool platform... and their focus is very much on getting stuff actually done with it :)
I never coded much Haskell myself like you did, though I did read allot about it and watched your videos amongst many others because the language is really nice like you noted. I seem to never actually used it practically for the same negative reasons as you pointed as well. There are just too much good alternatives to use out there which are usually far easier to learn and are far more practical to use. Nevertheless I enjoyed your Haskell videos and learned quite a bit more about how it all works.
The many weird symbols are also annoying..a few would have been enough, like the dot operator and the dollar operator. But when people start defining their own symbols which are often just chains of other symbols it becomes too difficult for most people .
@@samuraijosh1595 it's not difficult when you made it yourself but when you look at other people's code it can be. Some code I've had to give up on understanding.
@@Boxing_Gamer oh sorry I misread your comment, I read it as just too many symbols. I agree, abusing the symbol functions meta programming because it's fun or makes aesthetic sense to you personally is awful.
Do you use any different keyboard or just remap the keys with xmodmap or something. Because I have seen you using Emacs so fast. Just share with use. If you rebind the keys tell us which one. You are awesome btw
In retrospect its the kind of thing you want to be using for like, a microservice or something that intuitively doesn't deal in side effects. So for spam filtering for example it's actually spot on.
oh man I feel you.. both cabal and stack really suck ... Personally though this is worth it in exchange for the language itself, but people might differ on that. Worse to me is that fact, that it's so difficult to estimate and optimize for resource usage in haskell, because it is so abstract.
I think Haskell is an interesting and expressive language, but I gotta agree that maintenance, from my limited experience in it, does seem like a nightmare. The error messages can be very obfuscated, like with how it says there's a type error in a function for example, as well as just the syntax of the language can be a bit difficult to read coming from the imperative side of the programming world.
The things you described have nothing to do with what makes Haskell maintenance difficult, but ok. Type errors are one of the main benefits that help with refactoring of Haskell codebases that other languages do not provide in the same level of detail.
Wrong justification for the right complaint. Resolving type errors are not the problem, the type errors being so elaborate is part of the intended design. You need to learn about typeclasses and how type meta programming works in general and you'll love those type errors in the long run. The problem actually lies with the poorly managed libraries and tooling and packaging
There is really not enough documentation so the majority of the learning you spend trying to figure out why and how something works. Personally I like to build things and OCaml is not suited for that. It’s great for learning in college classes but if you’re going to learn a langage why not go with something more modern/used. As for the time it takes to learn I’ve had it this semester and at the end of the year I still don’t get everything to the point where it feels comfortable.
how about learning F#? it is based on OCaml, but the advantage is that it has the .NET ecosystem including Visual Studio (not Visual Studio Code) for debugging. also .NET Core is now open source and cross platform
I feel the fuck out of this pain. I LOVE Haskell but I've never had more problems with a language's implementation mechanics except, of course, Java (because I refuse to use intellij or eclipse).
I think emacs and language servers will give you a nice java idea. So far I've used emacs with rust, elm and csharp and it worked perfectly. Even has refactoring and goto definition etc. For a much easier learning curve you could use spacemacs.
Well :)) Actually I support the main points of the video. I have a long storry fighting with the overall lack of engineering in Haskell, and I can confirm that the propoganda exists. In fact, it's based on the ideology that Haskell is a superior language, and Haskellers are doing well. Unfortunately, it's prohibited to openly talk about problems (social mostly, technical secondly). I hate to say that, but for decades, the most powerful camps of Haskell were demonstrating the lack of pragmatism and knowledge in software engineering. Also, self-isolation ideology from the outside (mainstream) world was an obstacle to see the ignorance. Despite that, Haskell managed to get some traction of software engineering and attracted some businesses, although these pragmatic people rarely sound in the community as the core believers that math is everything. That's my long-term staying opinion. P.S. Thank you for mentioning me and Vitaly!
I love Haskell, it’s incredibly fulfilling to be productive in it but it’s true that it’s a complete PITA. When I picked up Go i realized what a completely abusive relationship I was in with Haskell.
The amount of info online that potential Haskell programmers dig through just to learn the tool chain and language is so fickle it's ridiculous. It's terribly hard to find up to date learning materials and parts of the tool chain are frequently deprecated or replaced and documentation just doesn't keep up. I remember Haskell Platform or w/e it was was the de facto toolchain, then Cabal, now Stack which still uses Cabal somewhere, and God knows what it's going to be next lol.
Because u need to learn things better. U didn't use Cabal for package managment. It was cabal-install actually. And Cabal is a library which Stack uses, yeah
I've been learning Haskell for some time now, and you just read my mind. I couldn't agree more. The language is awesome, but the ecosystem particularly Cabal and Stack as you mentioned is so unreliable its almost broken. And just like you said the creators of Haskell care much, much more about language design than useful tools. I've been having so much trouble with cabal it's not even funny. I use Haskell for prototyping and other languages to code in. Swift has so amazing support for functional programming that I can almost directly translate all the Haskell code. Now I cant really put all the blame on the Haskell designers since Haskell has a healthy community the experienced users should also contribute if they want the language to become more popular. Pharo Smalltalk has a tiny community and they have been able to create an incredibly impressive IDE far more impressive than anything I have seen in the Haskell world.
2 года назад
Haskell was, is, and probably will forever be a research language first and foremost. Well, all functional languages are research languages more (much more) than practical languages. You go through a lot of pain, to get… what exactly? I tried my hand at studying computer science (at university, for real). And we did functional programming (in StandardML I think)… the goal was to *prove* programs correct, but I don't see that happening, not on a scale that is useful. And I also doubt it can even *really* be done what with a) side-effects (which you need to have to do IO) and b) the halting problem. Sure, you can prove parts of software correct. But is that such a huge benefit? But in the end, the biggest problem for functional programming (pure functional, but also non-pure, like Lisp or Scheme) is that it goes against our "natural" way of thinking, against the way most people's thought processes work. It's hard enough for most folks to get into a programming mindset. And then they expect those to start to think *functional*? No way, Jose.
@ to me functional is the "natural" way of thinking. You type out functions that transform inputs inside out, you tell exactly what to do. The only disadvantage is there's a lot more base functions, but for example expressing "sumList = fmap (+)" instead of needing to declare local variables and a for loop
Год назад
@@firelights3675 To you, and good for you. But to *most* people it's completely foreign (as I said). Look for people complaining that math is hard, or that math sucks, and how many people can be seen to agree. All joking how bad they were at math and that nobody needs it (and then getting the wool pulled over their eyes thanks to their ignorance and innumeracy).
@ yeah once people have been programming in oop for some time, it's hard for them to break free from that thought process. But I wonder how hard fp would be to learn if it was your first language?
So…what is a good alternative to Haskell? Something that enhances functional style and with an elegant syntax yet isn’t a pain in the ass for packaging/building? I agree, stack and cabal seem like they were created by HS students…
Scala will let you do whatever abstract functional stuff you like (with a few different flavours of that e.g Cats, ZIO, etc.) but as a jvm language it can piggyback on much of the enormous java tooling ecosystem. The syntax is not as mathy as haskell but is very expressive and generally clean
The second half of this video is a good point about how Haskell's nice maths is held back by problems with the software engineering side. (I myself haven't used it for like 15 years.) It has become a great place to copy ideas from. The first half of the video is at risk of repelling people who need to hear the second half by calling them lying and brainwashed. I can tell you weren't trying to convince any Haskell fans. :-)
I also have another Haskell rant regarding some people overusing custom operators for no good reason, and turning the language into a shitshow despite Haskell having very simple syntax at its core. But that's a story for another time.
cabal (haven't used stack), does suck. However, I think it sucks because its way too involved. You should be able to just say you want package x, and then run package x, but because everything is so hooked to their dependency versions and so many customizable options, it is really really hard to use and a huge pain in the ass. That's not to say it can't work correctly, but it is to say that I've spent at least as much time just learning how to work with cabal as I have having to learn about haskell. The expectation for the developer to get cabal to work right is just too involved, however, I do think a lot of this can be solved simply by containerization. This doesn't solve maintainability and upgrading packages, which is kind of its own beast, but at least you don't end up with hundreds of competing dependencies in a global environment.
Yeah I've not been able to install popular Haskell backend frameworks because of stupid Cabal, it complains complains, complains about shit than actually getting shit done.
As a mathematician, I wouldn’t dream of using Haskell. Julia is another language designed by mathematicians and it manages to look elegant without sacrificing functionality
Is it something that can be fixed ? I mean, is it just because there not enough tools that make your life easier (Like in JavaScript, nvm, yarn and shit ) or is the language fundamentally unrecoverable ?
Imo, the way monads are explained is often way too abstract, but in use they click and its really just "oh I can ignore this wrapper" unless you want to write a research paper lol. Have you tried learning parsers? Personally that's when monads clicked for me.
Хехехе :) Ну, я смею думать, что делаю это вопреки всем возможным идеологиям Хаскеля, и развиваю альтернативный взгляд на то, чем может быть этот язык и практика его применения. Это гораздо глубже, чем просто использовать фри монады, это прагматизм и инженерный подход. P.S. Я рад, что вы обо мне вспомнили :)
you are right in fact Haskell is not been invented but discovered, so yes mathematicians are not good at building programming languages but are very good at discovering them
@@anonymousalexander6005 Or you just come up with a system that is internally coherent. It's questionably if math even try to describe nature/reality in a similar way that natural science as Physics, chemistry and biology do. It's strange how good some advanced and esoteric mat is as a tool/language for the Natural science.
@@lubricustheslippery5028 Two different people who never talked to each other, several times in history, have discovered the same mathematics. When have you ever seen two people with the same opinion?
@@jboss1073 It have happened several times that different people have come up with similar and wrong physics theories independent from each other. They have probably read the same books and have similar math backgrounds. Like we hav 10 fingers so we use the base 10 for numbers. So that is at least an covergent math because of human physiology not some fundamental math fact.
Yeah, I totally agree with you. The Haskell development environment is the worst in the world. If you've ever experienced a rust analyzer, the bloody experience of a haskell language server would want to put Haskell in the trash right away
I now can understand. I 'd give it a try and then I run into trouble with stack, I had to fall back to cabal and the joke is the .cabal file is overwritten if one uses stack and so I have a package manager which can give me an file for the cabal build system but I can not use the package manager to build it really. That sucks ...
I love Haskell as a language for things like niche problems but any time I try to build a larger project I don’t enjoy it very much. I tend to get lost in the details of the implementation instead of just making something that works.
Module system is so bad honestly it should be remade because the language is so good. I gave up the idea before even getting to cabal because when I see how modules worked I knew immediately what it would be like to build large, practical projects with it Still a brilliant language and I don’t regret spending time on it one bit.
@@samuraijosh1595 implicit importing unqualified symbols from other NS is what made me die inside, but on retrospect this should not have stopped me from learning it, there are acceptable import patterns that solve that problem
Cabal and Stack are a pain in the ass... Compared to what? Stack and Cabal are the best package managers I've used outside of cargo. I'll take them over gradle any day.
I say to people myself that Haskell is not production friendly. So I cannot say I do not see where you’re coming from. Haskell tooling has improved tremendously in this last 5/7… Saying that it has not been “engineered properly” is going to far IMHO. Also, Go ? I mean come 🤣
