141–150 of 242 posts
We are a YC company doing very well, all our back end code is written in Haskell. We have produced a lot of functionality with a relatively small team. I would say we are existence proof that Haskell is good for business.
Earlier quoted context omitted.
Two weeks, Just as much as for any other new language. After two weeks new member can introduce simple features. After a month - relatively complex ones. Full development speed is achieved after half a year and is roughly equal to all languages because all this time people learn problem(s) domain(s) and its (their) mapping to the code. For example, if I ask you to optimize Kaldi's HCLG-based decoder, you won't get an…
> Two weeks, Just as much as for any other new language. What?!! :) I was introducing new features within a day after switching from Java to C#. New features within less than a week when switching to Erlang (having had little FP experience). etc. etc. > For example, if I ask you to optimize Kaldi's HCLG-based decoder Why would you ask me that? Is it such a common problem? How about: if I ask you to implement a stream…
With Erlang you have to master OTP, which is part of language and, frankly, the only reason to choose it. The supervisor tree alone worth a week to see how it will work with different failure cases.
To quote "Real Programmers Don't Use PASCAL":
My first task in the Real World was to read and understand a 2O0,OO0-line FORTRAN program, then speed it up by a factor of two.
https://web.mit.edu/humor/Computers/real.programmers
It is humor, but every joke contains some truth. Optimizing Kaldi's decoder is a critical task if you recognize several thousand voice queries per minute.
Again, to take analogy from outside world. Interpids mostly cruising in under-Mach speeds. It is their common problem. But they are designed to intercept other aircratfs who can fly at MachN speeds and to avoid missiles which are fly at MachN speeds. The difference between under- and over-Mach speeds is... critical? Wings of under-Mach speed airplanes would flatter at Mach1+ and destroy plane itself (see Mig15 wings). Wings of interpid will work on under-Mach speeds just okay.
Common problems are easy to solve if you are ready to uncommon and critical ones. Which are often lie outside of programming language realm, can be solved easily with almost any language and Haskell provides better way to solve them (EDSLs, for example).
I will probably get stomped on for this but to me it's a giant elephant in the room. When that one purist on the team proposes mandating having 100%, 80%, or any hard number of unit test coverage, most sane people tend to disagree and understand its wild impracticality and counter-productivity. However - when one (ie, a Haskeller) says that the code must universally pass 100% strong static type verification coverage…
My experience is exactly the opposite. Using the type system is less effort, guides your development more and, in a way, provides more consistent guarantees than spending time on a wide unit test coverage.
Obviously, these things are not totally mutually exclusive though.
Earlier quoted context omitted.
For the problem you are solving and at your scale. Things start to change when you need to hire n+1 teams or engineers quickly.
They... might? I worked at a Haskell start-up for a bit. Hiring wasn't easy. But it doesn't seem to be easier at the mostly-JS start-up I'm working at now.
Earlier quoted context omitted.
Interfaces can have static methods.
I believe they mean static methods as part of the interface signature, e.g. to define constructor/factory methods. AFAIK there are issues with how Java handles dynamic dispatch that prevent this.
Earlier quoted context omitted.
>but what's wrong with the syntax? I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better. http://www.haskellforall.com/2015/09/how-to-make-your-haskel...
Note that this is to make Haskell more readable to non-Haskell programmers (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code less readable if you're familiar with Haskell and is quite frankly just bizarre. I do not think you'll find many programmers, Haskell or otherwise, who find lots of nested parenthesis to be the paragon of readability.¹ If…
This is why no one likes Haskell programmers and why the community just sucks.
You're telling me that it's _more difficult_ for a Haskell programmer to understand parentheses than for a non-haskell programmer to understand functors?
I can't think of a single haskell programmer that doesn't also know at least 2 C-style languages.
Meanwhile, there are many C-style programmers that don't know Haskell at all.
If the goal is to remain an impenetrable fortress / secluded monastery, the Haskell community is a safe bet for the Benedict Option[1]. But if the goal is to become popular and get others to understand the benefits of Haskell, it seems to be a culture problem within Haskell, more than anything else.
[1]: https://www.amazon.com/Benedict-Option-Strategy-Christians-P...
Earlier quoted context omitted.
The capability pattern that Data Has implements is definitely used in other projects[1], and notably is endorsed by RIO[2]. [1] https://github.com/input-output-hk/cardano-sl [2] https://github.com/commercialhaskell/rio#monads Elaboration: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_c...
The GitHub issue I linked is basically "switch from data-has to RIO"; the issues with data-has come from its use of multi-parameter type classes. RIO avoids the issues by using single-parameter classes. AFAICT multi-parameter type classes are the subject of numerous GHC bugs/misfeatures and are best avoided in production.
Earlier quoted context omitted.
Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least. There can and should be a conversation about doing this job well. Mandating strong static typing across the board is exactly what Haskell does. My claim is this is…
If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.
ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in.
Trying to pass an opaque reference down a function call chain.
There’s 3.
Earlier quoted context omitted.
Nope. Not everything is "every way is just as good as the other". >Whatever you like and whatever gets the job done: bravo "The job" is this: it's an optimization problem of maximizing development throughput. That's the job in the business world, at least. There can and should be a conversation about doing this job well. Mandating strong static typing across the board is exactly what Haskell does. My claim is this is…
I believe you're exaggerating the frequency that the compiler rejects valid programs. It happens, but no more frequently than random runtime type errors occur in dynamic code. In any case, one can just as easily argue that the value of static types come not just when the code is first written, but under the legion of modifications that need to occur. Not to mention how self documenting it is which also aids modificat…
The reason I’m confident in my objections is because this is what I get from static typing fundamentalists: never a concession as to its cons and costs. Is it that static typers can’t see the relative costs bc they are not using the full power of dynamic languages?
Earlier quoted context omitted.
If it happens every time then it should be easy for you to give a small example. Please do! It’s very hard to understand what you mean otherwise.
Pattern matching for one. I can prove that 3 cases won’t be met but I have to ‘fill in’ them anyway. ADTs with non-Maybe fields. I can prove that all is fine if this ‘slot’ isn’t filled in. Trying to pass an opaque reference down a function call chain. There’s 3.