16 ms·

A founder's perspective on 4 years with Haskell

347 points by mightybyte 10y ago

nxc18 10y ago
This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. Also check out F#, especially if you already have a code base involving .NET in any way. The CLR makes it super easy to write some parts in a functional language and other parts in more traditional OO - after all, the right approach often varies even within projects. As a personal anecdote, taking the time to learn Haskell or any other functional language makes you a better programmer. The concepts often apply to less'pure' languages and certainly stretch you to think in new ways.
- conistonwater 10y ago
  Shenanigans is a good word for that. So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. It does not help that theoretical and academic are so often used as slurs.
  - ebola1717 10y ago
    Haskell has its own share of shenanigans. Pragmas being the most blatant one, but also package management, the cumbersome-ness of some libraries, seq, and the number of operators (specifically the functorial ones).
    - axman6 10y ago
      Can you expand on all of these complaints? I've been using Haskell for about 9 years and none of these are things I've ever had a complaint about, except package management, which I find stack's solution works incredibly well in practice.
      - tmptmp 10y ago
        Here are some that I have encountered: Which string to use? String, ByteString or Text or something else? How to convert between zillions of String types, which are, it seems, completely incompatible even though providing similar functionality? So much for the support of abstraction. Which library is good for doing X? It seems, like String, the Haskell provides too many experimental and/or incompatible and/or immature libraries to do many trivial things. Then there are issues of laziness combined with IO and you get a `seq` shenanigan. Then there are issues of laziness combined with inability to profile/debug and you get a `analysis` shenanigan. Then there are issues of laziness combined with inability to handle exceptions without great grand-daddy-catch-all-bad-things IO monad and you get a `IO monad exceptions` shenanigan. So, there are a lot of Haskell shenanigans, too. Take your pick.
        tmptmp 10y ago
        It's not to say Haskell is bad, though. I'd be a fool to say so. The above comment is mainly to point out that there are its shortcomings and that it has a lot to improve and most of the times I have seen the proponents of Haskell tend to downplay and to avoid talking about these shortcomings. In fact, I have learned a lot many good programming practices/principles by spending time to learn Haskell. I do apply some of those in my projects in other languages.
        joseph 10y ago
        I have found the same to be true whenever I've tried to do anything in Haskell, especially with regards to error handling. I would try to decide on a specific style of handling errors, but the libraries I depended on maybe did it differently. So there ended up being a lot of boilerplate code to wrap other libraries to my own particular style. A lot of the problems I encountered probably boiled down to inexperience on my part, and perhaps not understanding idiomatic ways of doing things in the language. But another part of it is that I think the community has not settled on a set of common idioms. There are things about Haskell that I absolutely love. The expressiveness is amazing. Chaining a monadic sequence can feel magical at times. Treating errors as just values is nice. But what do you do when the libraries that you depend on throw exceptions instead of using Either? And those awful compiler errors can be so, so frustrating. But I will return to you again one day, dear Haskell.
  - Dr_tldr 10y ago
    JS runs natively on the web, it embraces multiple paradigms, it has a huge community, and you can get a job in almost any city on earth if you know how to use it. Haskell may be "better" as a language, (just as Esperanto may be superior to English) but if you want the widest range of opportunities in your life and not just in your language, Javascript/English beats Haskell/Esperanto. Why not help bring some of Haskell's concepts to a more relevant language instead of bemoaning the entirely rational decisions made by millions of junior and senior developers? Edit: the rabid insularity of the Haskell community definitely doesn't help. The Python community was dissatisfied with JS and created Coffeescript, and as of ES6 now everyone can enjoy the fat arrow syntax. Less pleasantly, the Java community got class syntax added to ES6, but at least they're trying to contribute. I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them, because all the Haskell community wants do is talk about how JavaScript sucks instead of embracing the functional side of it.
    - sotojuan 10y ago
      I don't know where they came from, but these projects and libraries seem to be influenced by Haskell (maybe?): https://github.com/folktale https://github.com/folktale https://github.com/sanctuary-js/sanctuary https://github.com/sanctuary-js/sanctuary
    - PeCaN 10y ago
      Firstly, poor analogy—English is a much superior language to Esperanto in terms information density over seconds per syllable in addition to being more expressive (it's easier to talk about a wide variety of topics and abstractions). Possibly more importantly than that, it takes a lot of people to make a spoken language useful for doing business but far far fewer for a computer language. > instead of bemoaning the entirely rational decisions made by millions of junior and senior developers I think people are bemoaning the stupid shit and not the entirely rational decisions. JS makes the former a bit easy. > Python community was dissatisfied with JS and created Coffeescript Nitpicking, but the first CoffeeScript compiler was written in Ruby and the language was largely inspired by Ruby. > the Java community got class syntax added to ES6 Huh that's a new one pretty sure that's not just the Java community, given that JS developers have been independently inventing class libraries (starting with Prototype, if not earlier) for ages. > I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them Underscore, lazy.js, other popular JavaScript libraries have some Haskellisms; LiveScript is a fork of CoffeeScript that used to be moderately popular and very Haskelly; React takes a lot of ideas from Haskell; immutable.js is quite Haskellian…. I think you're just not looking. > all the Haskell community wants do is talk about how JavaScript sucks You can drive a go cart on the highway, and you can keep modding your go cart, but at some point you might want to not be driving a fucking go cart on the highway.
  - logicallee 10y ago
    Hey how's that new patio coming along? The carpenter blew us away. They don't allow publication of a preprint, but it was just accepted into the Journal of Patio Support Design!! Which, I'm told, is the third most-prestigious journal in the business... No I meant like can we have a barbecue?
  - tmptmp 10y ago
    >>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. If the lenses for records thing in Haskell is amongst the simplest things for you, I beg to differ. I spent considerable time trying to get this working but could not succeed beyond toyish examples. Combine lenses/records with exceptions, applicatives, monads and monad-transformers as they become necessary once you try to expand your toy-example code and the Haskell thing becomes anything but simplest. Yet, other languages support records flawlessly and almost out of the box. The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it and due to almost arbitrary overloading of these symbols to mean different things in different contexts (libraries) just adds more cognitive overhead without any benefit. The almost cult-like insistence on the excessive usage of meaningless-to-humans symbols reminds me of the great practical programming language known as brainfuck [1]. Sorry but no sarcasm intended. Some Haskellers harp on succinctness, when talked about this religious fetish for symbolism in Haskell. So I ask, such succinctness at what cost? The excessive and obsessive usage of symbols may give mental kicks to the hardcore Haskellers out there, but sorry, I don't see any incentive to waste my time trying to wade through the gobble-de-gook of brainfuck type code. So sadly, Haskell and me are not a match. Maybe some most common things in other languages when tried in Haskell seem to be (are) rocket-science (e.g. lenses for records) and/or maybe I am a daft blockhead, but that's so. [1] https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck
    - thinkpad20 10y ago
      > The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. Furthermore, I'd add that what makes the symbols seem hard is not the fact that they're symbols, but that the ideas that they're representing are challenging when coming from the world of imperative programming. Using a named function like "bind" rather than ">>=" or "apply" rather than "< * >" is not going to help the fact that these functions are complicated and unintuitive to newcomers. I think a lot of the complaints about Haskell symbols, much like complaints about Haskell syntax, are more driven by how different Haskell semantics are to mainstream languages. Once a developer becomes comfortable with the "zen" of Haskell, these criticisms tend to melt away. That isn't to say that everything becomes easy: there are many concepts that one is only likely to encounter in Haskell, and they can often be challenging, or make someone else's code hard to grok. But the difficulty does not stem from the fact that they're written as symbols. IMO. As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language.
- jjzieve 10y ago
  Isn't JS functional?
  - sotojuan 10y ago
    JavaScript has functional features (first class functions for one are done well) but I think that's about it. Side effects, mutability, etc all are allowed. Compare with Haskell, Elm, or Clojure where those things are either not allowed at all or discouraged. The recent trend of "functional JavaScript" is mostly using third party tools that emulate feature from other languages (like Immtutable.js or Ramda), but IMO the core language cannot be called a proper functional language.
    - theGimp 10y ago
      It is a proper functional language, just not a "pure" functional language.
      - platz 10y ago
        Define proper functional language, as opposed to an improper one
        sotojuan 10y ago
        To be fair, everyone has their own definition of FP. For me, it just feels weird to call JS functional when it only has one "feature" of most functional languages. And at least in my college studies, the discouragement of side effects was stressed as the main feature of them.
        theGimp 10y ago
        To me, as long as functions are first class members, and higher-order functions are possible, I consider a language to be functional. Everything else is a convenience and not a requirement for the functional paradigm. Mind you, I do much prefer a Lisp or Scala to Javascript, but I face no trouble writing functional code in Javascript.
- catnaroek 10y ago
  > The concepts often apply to less'pure' languages and certainly stretch you to think in new ways. Purity is great help, but it isn't essential. The essential part is having a type system that actually captures what's going on in your program, without burdening you with manual annotations, and ML-family languages in general do very well in this regard.
  - sheepmullet 10y ago
    I've gotten much more value from purity and immutability than I ever have from advanced types although I'm speaking from a F#/Clojure background rather than a Haskell one.
    - catnaroek 10y ago
      I'm not talking about fancy types either. Standard ML's type system is dead simple (no higher-kinded types, no GADTs, no type families, not even type classes), and I got a lot more value from it than from Haskell's type system, mostly thanks to: (0) Abstract types, generated by means of opaque signature ascription, which Haskell doesn't have. This ensures that different modules can't “accidentally” each other's internal invariants. (1) The fact variables stand for values (due to ML being strict), rather than potentially diverging computations (due to Haskell being lazy), which makes useful algebraic laws sound even in the presence of nontermination or whatever effects.
- joe_the_user 10y ago
  This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. What do you mean? As far I can tell, functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn but Haskell would. And it's not that I think this is necessarily a bad thing - functional is the "next big thing" for taming the insanity of programming and even sixty years in, we need still new models because programming is still a mess. But let's frame things the way they are "here's an concrete argument the hype might be justified" or something like that.
  - chc 10y ago
    > functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn JavaScript topics do make it to the front of HN. For example, https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS was the top article on June 24. If you mean that simply writing about using JavaScript without any particular angle probably wouldn't make it to the front page, you're right. But that's actually proportionate to the two languages' usage. It's similar to how "I drank some water" is less interesting than "I drank a rare Japanese whiskey" — absent of context, they're equivalent, but because everyone has done the former, the fact that you did it too is boring on its own.
    - clishem 10y ago
      He said using JS won't get you to the top of HN.
  - nxc18 10y ago
    I would expect you're right that functional languages get more coverage than they would warrant based on usage, at least in industry and the startup scene. I was referring more to people dismissing the benefits of functional programming as they dismiss the benefits of strictly typed and compiled languages. Many of the benefits of functional are the result of restrictions far more 'onerous' than knowing the type of an object at compile time. Those 'restrictions' make you think about your code more carefully and catch huge classes of bugs. Using strings to access object properties in JS (to me) feels like shenanigans.
- wslh 10y ago
  > functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm The issue is that many times the programming languages don't matter, what matters are the libs written for that language. For example, there are cryptocurrency libs for Ethereum and Bitcoins that are only available for JavaScript/Node. Like it or not the better decision will be to use JavaScript only for this reason.
  - axlprose 10y ago
    I would argue that it's less about the libraries, and more about platforms and branding. Judging languages on their popular libraries can be a bit misleading, since not all languages need libraries for some of the stuff other languages need them for, they're often already baked-in to the language. F#'s Type Providers basically make ORMs, query builders, scrapers, web request libs, parsers, etc, largely unnecessary, because they enable the language to have built-in support for fully typed foreign data sources. Dart meanwhile, makes a large chunk of typical boilerplate js libs like jquery, underscore, promises, requirejs, etc, all obsolete while still being relatively similar to js. However, js is still the language of the largest platform out there (the browser), and the F# community still doesn't push it's branding and marketing towards trendy startup engineers very much, compared to a community like ruby's.
    - aninhumer 10y ago
      I don't think those kind of libraries are what the parent is talking about though. They're talking about when you need to interact with some interface, or implement some specific non-trivial algorithm, how likely is it that there's already a library for that.
      - axlprose 10y ago
        I hear this argument a lot too, but when you think about it, what would pull the original authors of those rarer libs to use the languages they chose in the first place? R is clearly geared and marketed towards statisticians, which have in turn given it a lot of such algorithms. Python has SciPy, which was also marketed similarly and has practically become its own platform. And Python itself was marketed towards academic types as 'executable pseudo code' that's easy to understand, which then culminated in NumPy and such. Also, I would argue that what op was talking about did fall more in line with platforms than algorithms, despite what the libs actually did, because Ethereum and Bitcoin are themselves platforms that spark those kinds of libs. Not to mention that you're always liable to run into situations where some obscure algorithm isn't available in your language of choice, regardless of how popular it is (unless you're using c++, which marketed/encouraged the kitchen-sink approach to development, and has had a lot of time to build quite a few kitchens). As for interfaces, I'm not sure exactly you mean that hasn't been covered already, like in the case of F# being able to smoothly interface with external data (which also includes the ability to interface with libraries from entirely different languages like R and Python). And interfacing with hardware is also a lot like a platform issue similar to the browser situation, except with C instead of js. And then there's stuff like arduino, which is also very clearly a platform. All in all, branding and marketing shouldn't be underestimated as the driving forces behind a lot of tech decisions, because software development does have a very strong social component that shouldn't be ignored. I mean, just look at the type of site we're on...
- mercurial 10y ago
  > a world where JavaScript's shenanigans are the accepted norm. Hey, we have Typescript nowadays, which does help a lot.
rkrzr 10y ago
Is there something like a "standard" HTTP client library and also a SQL abstraction library in Haskell nowadays, that everyone is using? Similar to what 'requests' and 'SQLAlchemy' are in Python? I feel those would be the two libraries that I would probably miss the most when switching to Haskell for a project.
- platz 10y ago
  wreq and persistent are probably the closest libs to what you've listed for python
  - rtpg 10y ago
    Persistent is an ORM that doesnt support SQL stuff entirely. So replacement for SQLAlchemy ORM but not Core If you want to be at the same level of abstraction as SQLAlchemy Core, you'll want to try esquelito (a SQL DSL).
    - platz 10y ago
      Ah thanks, I wasn't familiar with that part of SQLAlchemy
    - rkrzr 10y ago
      Thanks for pointing this out. I would indeed be looking for a replacement for SQLAlchemy Core, since I usually avoid ORMs. Esqueleto looks like it would fit the bill, since it does offer composability of queries, automated migrations, and protection against SQL-injections.
- ethagnawl 10y ago
  Have a look at Haskell Toolbox: http://haskell-toolbox.com/ http://haskell-toolbox.com/
  - tinco 10y ago
    Woops, I lost steam a little on that project. How did you find it?
hkjgkjy 10y ago
How I wish for a lisp like Clojure with a type system like Haskell... Hope core.typed will be that!
- nine_k 10y ago
  But will it have type inference? Haskell would be unbearably wordy without it.
- TheMagicHorsey 10y ago
  Have you looked at Typed Racket? They are doing some amazing things with rich type systems and gradual typing. You can get the best of both dynamic languages and statically typed ones by introducing types gradually as you develop. I quite like their model for types. I like Haskell also, but I feel Haskell is less readable than a lisp. But I will concede, this might be because I have been writing lisps longer than I have worked with Haskell.
  - hkjgkjy 10y ago
    Sadly haven't, because I have not had a reason to need it. Working with Clojure mostly. I like how Typed Racket "carries" the types with it when code from it is imported into other languages (like untyped Racket) via contracts. Lisps are definitely the most readable language - and with something like Smartparens or Paredit, combined with Rainbow-delimiters in Emacs it's the best programming I know by very very far. What is your experience of Typed Racket?
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- Confusion 10y ago
  Take a look at Shen.
facorreia 10y ago
Interesting, but so many caveats (e.g. writing rough libraries for things like sending emails). I find that Scala offers a better balance by enabling functional programming while still taking advantage of a huge, mature ecosystem including great libraries and tools.
- continuational 10y ago
  There are libraries for sending email. He was talking about a specific cloud API for sending email.
  - runeks 10y ago
    Last time I checked, and I did check recently, I couldn't find a Haskell library that offered an easy way to send email using a Gmail account. Resulting in this homegrown example, which doesn't work: https://github.com/runeksvendsen/restful-payment-channel-server/blob/master/src/PayChanServer/Misc/Email.hs https://github.com/runeksvendsen/restful-payment-channel-ser...
- gbersac 10y ago
  Working in scala and enjoying it a lot ! You have a library for every thing and syntax express functional code elegantly. The mix of object and functional programming make all seems a little bit confusing. A problem haskell doesn't have.
- willtim 10y ago
  It very much depends on how far you want to take your functional programming. If you want to make heavy use of purity, monads, type classes, tail recursion etc, you will be much better off in Haskell.
  - facorreia 10y ago
    I understand. I don't want to do that, though.
- SatvikBeri 10y ago
radicality 10y ago
Maybe someone can chime in here - I would love to be working full-time in Haskell, but I'm having trouble figuring out just how much knowledge I need upfront. I know I would be reasonably good at it after 2-3 months of working full-time with some Haskell expert to keep bugging. I try to learn as much Haskell as possible after my normal work but of course my rate of learning is much slower than if it was my full-time job. Looks to me like a chicken-and-egg problem. Anybody have any tips/knowledge of getting a Haskell job?
- chadaustin 10y ago
  In my experience, it is tricky for people to learn Haskell meaningfully outside of a team of people to explain the concepts. I'd say write a few real programs in Haskell. Beyond that, if you find the right company, they will hire based on general engineering skills rather than Haskell-specific skills. When it comes down to it, Haskell is just another language with a particular set of capabilities. Also there are occasionally posts to the /r/haskell subreddit with job listings. Good luck!
  - lallysingh 10y ago
    The new Haskell Design Patterns book, I think, covers a lot of the existing gap.
    - warkdarrior 10y ago
      The reviews seem to be quite negative: https://www.reddit.com/r/haskell/comments/41z1ih/haskell_design_patterns_any_good/ https://www.reddit.com/r/haskell/comments/41z1ih/haskell_des...
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- svanderbleek 10y ago
akurilin 10y ago
Thanks for posting that! We've also been a Haskell at scale in production company for a few years at Front Row, great to see others pulling off the same successfully. It's a small community so I'm happy to pool our resources together to make this continuously a better ecosystem to build businesses on.
- 0xmohit 10y ago
  Here is a link to a relevant post: http://www.kurilin.net/post/117369543198/haskell-at-front-row http://www.kurilin.net/post/117369543198/haskell-at-front-ro...
  - akurilin 10y ago
    <3
Nemant 10y ago
The Better platform gets around half a million learning actions every week and it has been running for well over a year with no downtime or maintenance. We still don’t know of any bugs. I'm guessing people use your learning software during weekdays and working hours (5 days and 8 hours/day). That's 3.4QPS. How many machines are you running on? Also, I'm really shocked to hear you've not encountered any bugs. How many humans are using your systems? A scale is good enough (100s, 1000s, 10000s?).
- coldtea 10y ago
  >That's 3.4QPS. Who said a "learning action" is equivalent to a query? >Also, I'm really shocked to hear you've not encountered any bugs. What's so shocking about it?
  - yyhhsj0521 10y ago
    I wrote Haskell myself and it is indeed generally free of bugs. However, there are many things that type system alone cannot fully address, for example, boundaries (Haskell's functions could be not total, and yes I know there are type-level integers and things, but they are often a pain to use)
  - sheepmullet 10y ago
    > What's so shocking about it? It's a different style of development. A lot of people have never worked on projects without lots of bugs. My current F# project for example has almost 100 outstanding issues. They would be really surprised to know that lots of people have worked on large c projects that are virtually bug free.
    - taeric 10y ago
      To be fair, not encountering bugs is often broken into two fields: a) aggressively defining user issues as out of scope, or b) not having a varied user pool. Examples of (a) are not always malicious, mind. For a small shop, if your program messes up because during a process the machine it was on got unplugged, it is easy to see why that can be called not a bug in the system. When your shop gets large enough, though, scenarios like that become far too common.
Confusion 10y ago
I was really disappointed by Haskell when I wrote the simple dynamic programming solution to the knapsack problem in it. To get good performance out of that took a lot of time and help from people at #haskell to deal with space leaks. Ultimately, the functional solution was verbose, harder to understand and still slower than the more imperative solutions in Clojure (also very hard to get good performance in BTW, but at least you can easily implement performance critical stuff in Java) and Ruby. That experience really turned me off Haskell.
- tome 10y ago
  Why didn't you just write the imperative solution in Haskell?
- SunChrono 10y ago
  dynamic programming can be very declarative in Haskell: http://lpaste.net/172965 http://lpaste.net/172965
thoradam 10y ago
> You might later find that something that took you 5 lines is a standard abstraction ready to be re-used. Such a great point and perhaps one of the biggest challenges as languages allow increasingly reusable and powerful abstractions. I would love to have GHC tell me something like "this piece of code here has a signature that is familiar, you could probably make this fit into {list of abstractions}".
- BellsOnSunday 10y ago
  That doesn't seem like something a compiler should care about, I think it would be better to add it to something like hlint.
- asib 10y ago
  If you're interested in a tool like that, check out Hoogle: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/. It allows you to search by signature, including using generic types (e.g. their front page example is (a -> b) -> [a] -> [b], which will return map as a result, among others).
- runeks 10y ago
  Such a tool exists. I've had hlint tell me many times how to do something in a better way. At some point I had it hooked into my IDE, so it would mark improvable code in yellow. Especially in the first year I learned a lot of new Haskell syntax and functions just from its suggestions.
  - harveywi 10y ago
    If you don't mind me asking, which IDE do you use?
    - runeks 10y ago
      Oh, yeah, I should have mentioned that: IntelliJ IDEA with the Haskforce plugin. The plugin isn't maintained any longer, though, so it's not the best solution, but it was perfect when both ghc-mod and hlint worked. ghc-mod still works, because I can't go back to coding without it, speeds everything up so much to have instant compiler feedback. For example, there is this fatal, unresolved bug that no one knows how to fix: https://github.com/carymrobbins/intellij-haskforce/issues/285 https://github.com/carymrobbins/intellij-haskforce/issues/28... EDIT: It's working again (for projects that do not exhibit above bug): http://i.imgur.com/jPo4Tas.png http://i.imgur.com/jPo4Tas.png
structorg 10y ago
I am a bit confused, lets suppose that TLS is broken in haskell libraries, or there is some kind of thing haskell has no libraries for and you don't want to lose time implementing it; what stops you from making a service for that task in another language?. I fail to picture a big system that is not distributed, maybe the problem of this startup required a monolithic system, or is it that a monolith project is in some ways easier to manage?.
bogomipz 10y ago
I am curious why the founder chose Zurich if they didn't know anybody there, which makes me think they are from somewhere else. Isn't Zurich particularly expensive? Wouldn't that be a detriment to a startup? I realize the article is about Haskell but, but its also about a startup and a founder so I thought I would ask.
- solidsnack9000 10y ago
  Carl and Jan are from Sweden and the Czech Republic, respectively, and our staff when I joined were a Dane, and Dutchman, a Hindu and an American (me). There was no particular effort to integrate -- of the team, I was the only one who regularly took lessons in Swiss German -- but it turns out that there are several practical reasons to run a European startup in Switzerland: * Taxation in Switzerland is fairly light, lighter even than in the United States. * Business regulation is comparatively streamlined, and labor flexibility is relatively great. * The tradition of efficient public services is rather relevant to any one trying to manage a small tribe of people, anywhere. * Lots of European people would like to work in Switzerland and, unlike SF, it is possible to hire from your European network without visas. Relative to San Francisco, Zurich is not particularly expensive.

347 points by mightybyte 10y ago

nxc18 10y ago

This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. Also check out F#, especially if you already have a code base involving .NET in any way. The CLR makes it super easy to write some parts in a functional language and other parts in more traditional OO - after all, the right approach often varies even within projects. As a personal anecdote, taking the time to learn Haskell or any other functional language makes you a better programmer. The concepts often apply to less'pure' languages and certainly stretch you to think in new ways.

conistonwater 10y ago
Shenanigans is a good word for that. So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. It does not help that theoretical and academic are so often used as slurs.
- ebola1717 10y ago
  Haskell has its own share of shenanigans. Pragmas being the most blatant one, but also package management, the cumbersome-ness of some libraries, seq, and the number of operators (specifically the functorial ones).
  - axman6 10y ago
    Can you expand on all of these complaints? I've been using Haskell for about 9 years and none of these are things I've ever had a complaint about, except package management, which I find stack's solution works incredibly well in practice.
    - tmptmp 10y ago
      Here are some that I have encountered: Which string to use? String, ByteString or Text or something else? How to convert between zillions of String types, which are, it seems, completely incompatible even though providing similar functionality? So much for the support of abstraction. Which library is good for doing X? It seems, like String, the Haskell provides too many experimental and/or incompatible and/or immature libraries to do many trivial things. Then there are issues of laziness combined with IO and you get a `seq` shenanigan. Then there are issues of laziness combined with inability to profile/debug and you get a `analysis` shenanigan. Then there are issues of laziness combined with inability to handle exceptions without great grand-daddy-catch-all-bad-things IO monad and you get a `IO monad exceptions` shenanigan. So, there are a lot of Haskell shenanigans, too. Take your pick.
      - tmptmp 10y ago
        It's not to say Haskell is bad, though. I'd be a fool to say so. The above comment is mainly to point out that there are its shortcomings and that it has a lot to improve and most of the times I have seen the proponents of Haskell tend to downplay and to avoid talking about these shortcomings. In fact, I have learned a lot many good programming practices/principles by spending time to learn Haskell. I do apply some of those in my projects in other languages.
      - joseph 10y ago
        I have found the same to be true whenever I've tried to do anything in Haskell, especially with regards to error handling. I would try to decide on a specific style of handling errors, but the libraries I depended on maybe did it differently. So there ended up being a lot of boilerplate code to wrap other libraries to my own particular style. A lot of the problems I encountered probably boiled down to inexperience on my part, and perhaps not understanding idiomatic ways of doing things in the language. But another part of it is that I think the community has not settled on a set of common idioms. There are things about Haskell that I absolutely love. The expressiveness is amazing. Chaining a monadic sequence can feel magical at times. Treating errors as just values is nice. But what do you do when the libraries that you depend on throw exceptions instead of using Either? And those awful compiler errors can be so, so frustrating. But I will return to you again one day, dear Haskell.
- Dr_tldr 10y ago
  JS runs natively on the web, it embraces multiple paradigms, it has a huge community, and you can get a job in almost any city on earth if you know how to use it. Haskell may be "better" as a language, (just as Esperanto may be superior to English) but if you want the widest range of opportunities in your life and not just in your language, Javascript/English beats Haskell/Esperanto. Why not help bring some of Haskell's concepts to a more relevant language instead of bemoaning the entirely rational decisions made by millions of junior and senior developers? Edit: the rabid insularity of the Haskell community definitely doesn't help. The Python community was dissatisfied with JS and created Coffeescript, and as of ES6 now everyone can enjoy the fat arrow syntax. Less pleasantly, the Java community got class syntax added to ES6, but at least they're trying to contribute. I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them, because all the Haskell community wants do is talk about how JavaScript sucks instead of embracing the functional side of it.
  - sotojuan 10y ago
    I don't know where they came from, but these projects and libraries seem to be influenced by Haskell (maybe?): https://github.com/folktale https://github.com/folktale https://github.com/sanctuary-js/sanctuary https://github.com/sanctuary-js/sanctuary
  - PeCaN 10y ago
    Firstly, poor analogy—English is a much superior language to Esperanto in terms information density over seconds per syllable in addition to being more expressive (it's easier to talk about a wide variety of topics and abstractions). Possibly more importantly than that, it takes a lot of people to make a spoken language useful for doing business but far far fewer for a computer language. > instead of bemoaning the entirely rational decisions made by millions of junior and senior developers I think people are bemoaning the stupid shit and not the entirely rational decisions. JS makes the former a bit easy. > Python community was dissatisfied with JS and created Coffeescript Nitpicking, but the first CoffeeScript compiler was written in Ruby and the language was largely inspired by Ruby. > the Java community got class syntax added to ES6 Huh that's a new one pretty sure that's not just the Java community, given that JS developers have been independently inventing class libraries (starting with Prototype, if not earlier) for ages. > I'm sure Haskell has plenty of really cool things to bring to the table, but I've never heard of any of them Underscore, lazy.js, other popular JavaScript libraries have some Haskellisms; LiveScript is a fork of CoffeeScript that used to be moderately popular and very Haskelly; React takes a lot of ideas from Haskell; immutable.js is quite Haskellian…. I think you're just not looking. > all the Haskell community wants do is talk about how JavaScript sucks You can drive a go cart on the highway, and you can keep modding your go cart, but at some point you might want to not be driving a fucking go cart on the highway.
- logicallee 10y ago
  Hey how's that new patio coming along? The carpenter blew us away. They don't allow publication of a preprint, but it was just accepted into the Journal of Patio Support Design!! Which, I'm told, is the third most-prestigious journal in the business... No I meant like can we have a barbecue?
- tmptmp 10y ago
  >>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell. If the lenses for records thing in Haskell is amongst the simplest things for you, I beg to differ. I spent considerable time trying to get this working but could not succeed beyond toyish examples. Combine lenses/records with exceptions, applicatives, monads and monad-transformers as they become necessary once you try to expand your toy-example code and the Haskell thing becomes anything but simplest. Yet, other languages support records flawlessly and almost out of the box. The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it and due to almost arbitrary overloading of these symbols to mean different things in different contexts (libraries) just adds more cognitive overhead without any benefit. The almost cult-like insistence on the excessive usage of meaningless-to-humans symbols reminds me of the great practical programming language known as brainfuck [1]. Sorry but no sarcasm intended. Some Haskellers harp on succinctness, when talked about this religious fetish for symbolism in Haskell. So I ask, such succinctness at what cost? The excessive and obsessive usage of symbols may give mental kicks to the hardcore Haskellers out there, but sorry, I don't see any incentive to waste my time trying to wade through the gobble-de-gook of brainfuck type code. So sadly, Haskell and me are not a match. Maybe some most common things in other languages when tried in Haskell seem to be (are) rocket-science (e.g. lenses for records) and/or maybe I am a daft blockhead, but that's so. [1] https://en.wikipedia.org/wiki/Brainfuck https://en.wikipedia.org/wiki/Brainfuck
  - thinkpad20 10y ago
    > The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it This is an oft-repeated criticism of Haskell which I frankly find has no basis. Firstly, symbols are preferred for these kinds of functions precisely because of their ubiquity. Once you're familiar with them (which you almost certainly will quickly become, for the common ones like `>>=`, and `< * >`) they make the code easier to read, not harder, in general. Few would complain about having to write "<" to compare two numbers in most languages, rather than, say, "lessThan", because it's all over the place, and having a symbol for it makes it easier for a developer to read. The same is true for many common combinators in Haskell. There is no "cult-like insistence" on them; it's simply the case that many Haskell developers find them more pleasant to write than named functions. Honestly, the comparison to brainfuck is completely unfounded, and the references to cults and religious fetishes are IMO unnecessarily derisive. Furthermore, I'd add that what makes the symbols seem hard is not the fact that they're symbols, but that the ideas that they're representing are challenging when coming from the world of imperative programming. Using a named function like "bind" rather than ">>=" or "apply" rather than "< * >" is not going to help the fact that these functions are complicated and unintuitive to newcomers. I think a lot of the complaints about Haskell symbols, much like complaints about Haskell syntax, are more driven by how different Haskell semantics are to mainstream languages. Once a developer becomes comfortable with the "zen" of Haskell, these criticisms tend to melt away. That isn't to say that everything becomes easy: there are many concepts that one is only likely to encounter in Haskell, and they can often be challenging, or make someone else's code hard to grok. But the difficulty does not stem from the fact that they're written as symbols. IMO. As for your comments on lenses and records, I've been writing Haskell for a good number of years and still haven't really spent the time to grok lenses. I think they're probably great, but certainly mastery of them is not required to be productive with the language.
jjzieve 10y ago
Isn't JS functional?
- sotojuan 10y ago
  JavaScript has functional features (first class functions for one are done well) but I think that's about it. Side effects, mutability, etc all are allowed. Compare with Haskell, Elm, or Clojure where those things are either not allowed at all or discouraged. The recent trend of "functional JavaScript" is mostly using third party tools that emulate feature from other languages (like Immtutable.js or Ramda), but IMO the core language cannot be called a proper functional language.
  - theGimp 10y ago
    It is a proper functional language, just not a "pure" functional language.
    - platz 10y ago
      Define proper functional language, as opposed to an improper one
      - sotojuan 10y ago
        To be fair, everyone has their own definition of FP. For me, it just feels weird to call JS functional when it only has one "feature" of most functional languages. And at least in my college studies, the discouragement of side effects was stressed as the main feature of them.
      - theGimp 10y ago
        To me, as long as functions are first class members, and higher-order functions are possible, I consider a language to be functional. Everything else is a convenience and not a requirement for the functional paradigm. Mind you, I do much prefer a Lisp or Scala to Javascript, but I face no trouble writing functional code in Javascript.
catnaroek 10y ago
> The concepts often apply to less'pure' languages and certainly stretch you to think in new ways. Purity is great help, but it isn't essential. The essential part is having a type system that actually captures what's going on in your program, without burdening you with manual annotations, and ML-family languages in general do very well in this regard.
- sheepmullet 10y ago
  I've gotten much more value from purity and immutability than I ever have from advanced types although I'm speaking from a F#/Clojure background rather than a Haskell one.
  - catnaroek 10y ago
    I'm not talking about fancy types either. Standard ML's type system is dead simple (no higher-kinded types, no GADTs, no type families, not even type classes), and I got a lot more value from it than from Haskell's type system, mostly thanks to: (0) Abstract types, generated by means of opaque signature ascription, which Haskell doesn't have. This ensures that different modules can't “accidentally” each other's internal invariants. (1) The fact variables stand for values (due to ML being strict), rather than potentially diverging computations (due to Haskell being lazy), which makes useful algebraic laws sound even in the presence of nontermination or whatever effects.
joe_the_user 10y ago
This is a great article - functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm. What do you mean? As far I can tell, functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn but Haskell would. And it's not that I think this is necessarily a bad thing - functional is the "next big thing" for taming the insanity of programming and even sixty years in, we need still new models because programming is still a mess. But let's frame things the way they are "here's an concrete argument the hype might be justified" or something like that.
- chc 10y ago
  > functional languages get an amount of attention disproportionate to their usage and even this article is example - using js wouldn't get to the top of hn JavaScript topics do make it to the front of HN. For example, https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS was the top article on June 24. If you mean that simply writing about using JavaScript without any particular angle probably wouldn't make it to the front page, you're right. But that's actually proportionate to the two languages' usage. It's similar to how "I drank some water" is less interesting than "I drank a rare Japanese whiskey" — absent of context, they're equivalent, but because everyone has done the former, the fact that you did it too is boring on its own.
  - clishem 10y ago
    He said using JS won't get you to the top of HN.
- nxc18 10y ago
  I would expect you're right that functional languages get more coverage than they would warrant based on usage, at least in industry and the startup scene. I was referring more to people dismissing the benefits of functional programming as they dismiss the benefits of strictly typed and compiled languages. Many of the benefits of functional are the result of restrictions far more 'onerous' than knowing the type of an object at compile time. Those 'restrictions' make you think about your code more carefully and catch huge classes of bugs. Using strings to access object properties in JS (to me) feels like shenanigans.
wslh 10y ago
> functional languages like Haskell don't get enough credit in a world where JavaScript's shenanigans are the accepted norm The issue is that many times the programming languages don't matter, what matters are the libs written for that language. For example, there are cryptocurrency libs for Ethereum and Bitcoins that are only available for JavaScript/Node. Like it or not the better decision will be to use JavaScript only for this reason.
- axlprose 10y ago
  I would argue that it's less about the libraries, and more about platforms and branding. Judging languages on their popular libraries can be a bit misleading, since not all languages need libraries for some of the stuff other languages need them for, they're often already baked-in to the language. F#'s Type Providers basically make ORMs, query builders, scrapers, web request libs, parsers, etc, largely unnecessary, because they enable the language to have built-in support for fully typed foreign data sources. Dart meanwhile, makes a large chunk of typical boilerplate js libs like jquery, underscore, promises, requirejs, etc, all obsolete while still being relatively similar to js. However, js is still the language of the largest platform out there (the browser), and the F# community still doesn't push it's branding and marketing towards trendy startup engineers very much, compared to a community like ruby's.
  - aninhumer 10y ago
    I don't think those kind of libraries are what the parent is talking about though. They're talking about when you need to interact with some interface, or implement some specific non-trivial algorithm, how likely is it that there's already a library for that.
    - axlprose 10y ago
      I hear this argument a lot too, but when you think about it, what would pull the original authors of those rarer libs to use the languages they chose in the first place? R is clearly geared and marketed towards statisticians, which have in turn given it a lot of such algorithms. Python has SciPy, which was also marketed similarly and has practically become its own platform. And Python itself was marketed towards academic types as 'executable pseudo code' that's easy to understand, which then culminated in NumPy and such. Also, I would argue that what op was talking about did fall more in line with platforms than algorithms, despite what the libs actually did, because Ethereum and Bitcoin are themselves platforms that spark those kinds of libs. Not to mention that you're always liable to run into situations where some obscure algorithm isn't available in your language of choice, regardless of how popular it is (unless you're using c++, which marketed/encouraged the kitchen-sink approach to development, and has had a lot of time to build quite a few kitchens). As for interfaces, I'm not sure exactly you mean that hasn't been covered already, like in the case of F# being able to smoothly interface with external data (which also includes the ability to interface with libraries from entirely different languages like R and Python). And interfacing with hardware is also a lot like a platform issue similar to the browser situation, except with C instead of js. And then there's stuff like arduino, which is also very clearly a platform. All in all, branding and marketing shouldn't be underestimated as the driving forces behind a lot of tech decisions, because software development does have a very strong social component that shouldn't be ignored. I mean, just look at the type of site we're on...
mercurial 10y ago
> a world where JavaScript's shenanigans are the accepted norm. Hey, we have Typescript nowadays, which does help a lot.

rkrzr 10y ago

Is there something like a "standard" HTTP client library and also a SQL abstraction library in Haskell nowadays, that everyone is using? Similar to what 'requests' and 'SQLAlchemy' are in Python? I feel those would be the two libraries that I would probably miss the most when switching to Haskell for a project.

platz 10y ago
wreq and persistent are probably the closest libs to what you've listed for python
- rtpg 10y ago
  Persistent is an ORM that doesnt support SQL stuff entirely. So replacement for SQLAlchemy ORM but not Core If you want to be at the same level of abstraction as SQLAlchemy Core, you'll want to try esquelito (a SQL DSL).
  - platz 10y ago
    Ah thanks, I wasn't familiar with that part of SQLAlchemy
  - rkrzr 10y ago
    Thanks for pointing this out. I would indeed be looking for a replacement for SQLAlchemy Core, since I usually avoid ORMs. Esqueleto looks like it would fit the bill, since it does offer composability of queries, automated migrations, and protection against SQL-injections.
ethagnawl 10y ago
Have a look at Haskell Toolbox: http://haskell-toolbox.com/ http://haskell-toolbox.com/
- tinco 10y ago
  Woops, I lost steam a little on that project. How did you find it?

hkjgkjy 10y ago

How I wish for a lisp like Clojure with a type system like Haskell... Hope core.typed will be that!

nine_k 10y ago
But will it have type inference? Haskell would be unbearably wordy without it.
TheMagicHorsey 10y ago
Have you looked at Typed Racket? They are doing some amazing things with rich type systems and gradual typing. You can get the best of both dynamic languages and statically typed ones by introducing types gradually as you develop. I quite like their model for types. I like Haskell also, but I feel Haskell is less readable than a lisp. But I will concede, this might be because I have been writing lisps longer than I have worked with Haskell.
- hkjgkjy 10y ago
  Sadly haven't, because I have not had a reason to need it. Working with Clojure mostly. I like how Typed Racket "carries" the types with it when code from it is imported into other languages (like untyped Racket) via contracts. Lisps are definitely the most readable language - and with something like Smartparens or Paredit, combined with Rainbow-delimiters in Emacs it's the best programming I know by very very far. What is your experience of Typed Racket?
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
Confusion 10y ago
Take a look at Shen.

facorreia 10y ago

Interesting, but so many caveats (e.g. writing rough libraries for things like sending emails). I find that Scala offers a better balance by enabling functional programming while still taking advantage of a huge, mature ecosystem including great libraries and tools.

continuational 10y ago
There are libraries for sending email. He was talking about a specific cloud API for sending email.
- runeks 10y ago
  Last time I checked, and I did check recently, I couldn't find a Haskell library that offered an easy way to send email using a Gmail account. Resulting in this homegrown example, which doesn't work: https://github.com/runeksvendsen/restful-payment-channel-server/blob/master/src/PayChanServer/Misc/Email.hs https://github.com/runeksvendsen/restful-payment-channel-ser...
gbersac 10y ago
Working in scala and enjoying it a lot ! You have a library for every thing and syntax express functional code elegantly. The mix of object and functional programming make all seems a little bit confusing. A problem haskell doesn't have.
willtim 10y ago
It very much depends on how far you want to take your functional programming. If you want to make heavy use of purity, monads, type classes, tail recursion etc, you will be much better off in Haskell.
- facorreia 10y ago
  I understand. I don't want to do that, though.
SatvikBeri 10y ago

radicality 10y ago

Maybe someone can chime in here - I would love to be working full-time in Haskell, but I'm having trouble figuring out just how much knowledge I need upfront. I know I would be reasonably good at it after 2-3 months of working full-time with some Haskell expert to keep bugging. I try to learn as much Haskell as possible after my normal work but of course my rate of learning is much slower than if it was my full-time job. Looks to me like a chicken-and-egg problem. Anybody have any tips/knowledge of getting a Haskell job?

chadaustin 10y ago
In my experience, it is tricky for people to learn Haskell meaningfully outside of a team of people to explain the concepts. I'd say write a few real programs in Haskell. Beyond that, if you find the right company, they will hire based on general engineering skills rather than Haskell-specific skills. When it comes down to it, Haskell is just another language with a particular set of capabilities. Also there are occasionally posts to the /r/haskell subreddit with job listings. Good luck!
- lallysingh 10y ago
  The new Haskell Design Patterns book, I think, covers a lot of the existing gap.
  - warkdarrior 10y ago
    The reviews seem to be quite negative: https://www.reddit.com/r/haskell/comments/41z1ih/haskell_design_patterns_any_good/ https://www.reddit.com/r/haskell/comments/41z1ih/haskell_des...
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
svanderbleek 10y ago

akurilin 10y ago

Thanks for posting that! We've also been a Haskell at scale in production company for a few years at Front Row, great to see others pulling off the same successfully. It's a small community so I'm happy to pool our resources together to make this continuously a better ecosystem to build businesses on.

0xmohit 10y ago
Here is a link to a relevant post: http://www.kurilin.net/post/117369543198/haskell-at-front-row http://www.kurilin.net/post/117369543198/haskell-at-front-ro...
- akurilin 10y ago
  <3

Nemant 10y ago

The Better platform gets around half a million learning actions every week and it has been running for well over a year with no downtime or maintenance. We still don’t know of any bugs. I'm guessing people use your learning software during weekdays and working hours (5 days and 8 hours/day). That's 3.4QPS. How many machines are you running on? Also, I'm really shocked to hear you've not encountered any bugs. How many humans are using your systems? A scale is good enough (100s, 1000s, 10000s?).

coldtea 10y ago
>That's 3.4QPS. Who said a "learning action" is equivalent to a query? >Also, I'm really shocked to hear you've not encountered any bugs. What's so shocking about it?
- yyhhsj0521 10y ago
  I wrote Haskell myself and it is indeed generally free of bugs. However, there are many things that type system alone cannot fully address, for example, boundaries (Haskell's functions could be not total, and yes I know there are type-level integers and things, but they are often a pain to use)
- sheepmullet 10y ago
  > What's so shocking about it? It's a different style of development. A lot of people have never worked on projects without lots of bugs. My current F# project for example has almost 100 outstanding issues. They would be really surprised to know that lots of people have worked on large c projects that are virtually bug free.
  - taeric 10y ago
    To be fair, not encountering bugs is often broken into two fields: a) aggressively defining user issues as out of scope, or b) not having a varied user pool. Examples of (a) are not always malicious, mind. For a small shop, if your program messes up because during a process the machine it was on got unplugged, it is easy to see why that can be called not a bug in the system. When your shop gets large enough, though, scenarios like that become far too common.

Confusion 10y ago

I was really disappointed by Haskell when I wrote the simple dynamic programming solution to the knapsack problem in it. To get good performance out of that took a lot of time and help from people at #haskell to deal with space leaks. Ultimately, the functional solution was verbose, harder to understand and still slower than the more imperative solutions in Clojure (also very hard to get good performance in BTW, but at least you can easily implement performance critical stuff in Java) and Ruby. That experience really turned me off Haskell.

tome 10y ago
Why didn't you just write the imperative solution in Haskell?
SunChrono 10y ago
dynamic programming can be very declarative in Haskell: http://lpaste.net/172965 http://lpaste.net/172965

thoradam 10y ago

> You might later find that something that took you 5 lines is a standard abstraction ready to be re-used. Such a great point and perhaps one of the biggest challenges as languages allow increasingly reusable and powerful abstractions. I would love to have GHC tell me something like "this piece of code here has a signature that is familiar, you could probably make this fit into {list of abstractions}".

BellsOnSunday 10y ago
That doesn't seem like something a compiler should care about, I think it would be better to add it to something like hlint.
asib 10y ago
If you're interested in a tool like that, check out Hoogle: https://www.haskell.org/hoogle/ https://www.haskell.org/hoogle/. It allows you to search by signature, including using generic types (e.g. their front page example is (a -> b) -> [a] -> [b], which will return map as a result, among others).
runeks 10y ago
Such a tool exists. I've had hlint tell me many times how to do something in a better way. At some point I had it hooked into my IDE, so it would mark improvable code in yellow. Especially in the first year I learned a lot of new Haskell syntax and functions just from its suggestions.
- harveywi 10y ago
  If you don't mind me asking, which IDE do you use?
  - runeks 10y ago
    Oh, yeah, I should have mentioned that: IntelliJ IDEA with the Haskforce plugin. The plugin isn't maintained any longer, though, so it's not the best solution, but it was perfect when both ghc-mod and hlint worked. ghc-mod still works, because I can't go back to coding without it, speeds everything up so much to have instant compiler feedback. For example, there is this fatal, unresolved bug that no one knows how to fix: https://github.com/carymrobbins/intellij-haskforce/issues/285 https://github.com/carymrobbins/intellij-haskforce/issues/28... EDIT: It's working again (for projects that do not exhibit above bug): http://i.imgur.com/jPo4Tas.png http://i.imgur.com/jPo4Tas.png

structorg 10y ago

I am a bit confused, lets suppose that TLS is broken in haskell libraries, or there is some kind of thing haskell has no libraries for and you don't want to lose time implementing it; what stops you from making a service for that task in another language?. I fail to picture a big system that is not distributed, maybe the problem of this startup required a monolithic system, or is it that a monolith project is in some ways easier to manage?.

bogomipz 10y ago

I am curious why the founder chose Zurich if they didn't know anybody there, which makes me think they are from somewhere else. Isn't Zurich particularly expensive? Wouldn't that be a detriment to a startup? I realize the article is about Haskell but, but its also about a startup and a founder so I thought I would ask.

solidsnack9000 10y ago
Carl and Jan are from Sweden and the Czech Republic, respectively, and our staff when I joined were a Dane, and Dutchman, a Hindu and an American (me). There was no particular effort to integrate -- of the team, I was the only one who regularly took lessons in Swiss German -- but it turns out that there are several practical reasons to run a European startup in Switzerland: * Taxation in Switzerland is fairly light, lighter even than in the United States. * Business regulation is comparatively streamlined, and labor flexibility is relatively great. * The tradition of efficient public services is rather relevant to any one trying to manage a small tribe of people, anywhere. * Lots of European people would like to work in Switzerland and, unlike SF, it is possible to hire from your European network without visas. Relative to San Francisco, Zurich is not particularly expensive.