How we secretly introduced Haskell and got away with it • Hacker News Board

Re: How we secretly introduced Haskell and got away with it

#181

Post by Apaec » Sat, Mar 04, 2017, 3:13 AM UTC

daxfohl wrote: post #38

I'm just starting with Haskell and PureScript. So far I'm liking the latter better. It solves a few of their gripes with respect to strings, laziness and records, plus has a more granular/extendable effects system and cleans up the standard typeclass hierarchy. Also `head []` doesn't crash. Of course Haskell is more mature, has support for multithreading and STM, compiles to native, so it's more performant. But PureS…

A while ago I wanted a better JS for a project, so I tried PureScript and liked it, I have a little experience with Haskell and it was easy to understand and more consistent, however when I tried to do UI components I chose halogen and damn it was too complicated, ended going back to ES6 and React.

Re: How we secretly introduced Haskell and got away with it

#182

Post by Ruud-v-A » Sat, Mar 04, 2017, 10:41 AM UTC

arunix wrote: post #155

arianvanp wrote: post #20

I'm the author of the post. I'll be happy to answer any of your questions :)

How did you debug the space leaks? Can anything be done to mitigate/avoid them?

The GHC runtime has built-in support for memory profiling, it can produce a graph that shows a breakdown of the heap over time. After trying various combinations of flags I managed to produce a graph where one part was clearly growing over time. The corresponding function was a recursive function with two arguments, the first never changing in recursive calls. I rewrote that to a single-argument nested function, and that made the leak go away.

Re: How we secretly introduced Haskell and got away with it

#183

Post by Ruud-v-A » Sat, Mar 04, 2017, 10:43 AM UTC

guptaneil wrote: post #147

yawaramin wrote: post #39

Earlier quoted context omitted.

If the URL to a private repo is not secure, then a whole bunch of people (including GitHub) have a big problem, and exposing jobmachine is the least of their worries ;-)

It's not a security problem, or else my comment would have been much more adamant about removing the link. It's mostly just reader confusion. Seeing the git clone url led me to believe the project was open sourced and was disappointed to find that not to be the case.

We do have a different small tool in Haskell that we are likely going to open source though :)

Re: How we secretly introduced Haskell and got away with it

#184

Post by NegatioN » Sat, Mar 04, 2017, 2:13 PM UTC

tigershark wrote: post #138

NegatioN wrote: post #21

Earlier quoted context omitted.

Wouldn't a complete rewrite of a module usually be a lot easier if the program is procedural? I think that is one of the big factors stopping that from actually happening with OO code. A rewrite is a lot harder if you tap into what exists elsewhere in the codebase. I bet you have a lot more insight into this than me though.

I don't really think so. With OOP you can easily replace whatever part of the system you want. Obviously if you have written OO code, not if you have written a mixed procedural-spaghetti code in an OO language. You "just" write an implementation for your interfaces that makes all the unit, integration and acceptance tests green. With procedural programming you have no interfaces and more importantly testing was non-e…

Prodcedural code can also be well compartmentalized and tested.

I was also until recently quite convinced OOP was the only way to go, but I'm seeing signs everywhere that a lot of the design-problems I've met over the past few years are at least magnified by OOP.

The abstraction promised by OOP is a good thing, however very few people are able to consistently make good, reusable and maintained abstractions. To the point where it becomes a weakness rather than a strength. I don't want a billion wrapper-objects that obfuscate my code, and makes the surface area of it bigger than it has to be. Often I struggle understanding code more because of how it was separated, than because of the complexity of what it actually does.

I liked Rich Hickeys talk "Simple made Easy" [1] and "Brian Will: Why OOP is Bad" [2]

[1]: https://www.youtube.com/watch?v=rI8tNMsozo0 [2]: https://www.youtube.com/watch?v=QM1iUe6IofM

Re: How we secretly introduced Haskell and got away with it

#185

Post by nanxor » Sat, Mar 04, 2017, 4:28 PM UTC

slezakattack wrote: post #45

"It is said that Haskell programmers are a rare species, but actually the majority of developers at Channable had used Haskell before." Could you imagine if this wasn't the case? The hurdle to actually get people excited about a language such as Haskell especially moving from something like Python would potentially be huge. Kudos for already having that problem solved.

In many European countries there are workplaces that only hire people with relevant academic degrees.

A course on functional+logic programming is often placed in the 2nd or 3rd year of a typical European 3-3½ year CS degree.

Re: How we secretly introduced Haskell and got away with it

#186

Post by daxfohl » Sun, Mar 05, 2017, 11:47 AM UTC

Apaec wrote: post #181

daxfohl wrote: post #38

I'm just starting with Haskell and PureScript. So far I'm liking the latter better. It solves a few of their gripes with respect to strings, laziness and records, plus has a more granular/extendable effects system and cleans up the standard typeclass hierarchy. Also `head []` doesn't crash. Of course Haskell is more mature, has support for multithreading and STM, compiles to native, so it's more performant. But PureS…

A while ago I wanted a better JS for a project, so I tried PureScript and liked it, I have a little experience with Haskell and it was easy to understand and more consistent, however when I tried to do UI components I chose halogen and damn it was too complicated, ended going back to ES6 and React.

What was complicated about it? I'm just getting started with it and it seems pretty straightforward after two days. In fact, I'd say it's almost stupidly easy -- one state handler, one change monitor, and one renderer, done. None of the mangling local state/props/component/JSX/global state/flux/redux stuff in React. So many knobs and options and plugins, the React ecosystem strikes me as a zoo comparatively.

Re: How we secretly introduced Haskell and got away with it

#187

Post by KurtMueller » Sun, Mar 05, 2017, 8:51 PM UTC

chrisdone wrote: post #152

daxfohl wrote: post #38

I'm just starting with Haskell and PureScript. So far I'm liking the latter better. It solves a few of their gripes with respect to strings, laziness and records, plus has a more granular/extendable effects system and cleans up the standard typeclass hierarchy. Also `head []` doesn't crash. Of course Haskell is more mature, has support for multithreading and STM, compiles to native, so it's more performant. But PureS…

I think PureScript should catch on. The runtime performance story is much more predictable than Haskell, it integrates trivially with the most valuable target platform: JS, it has small output, fixes the warts of Haskell and yet is still pure. Aside from apps at work, I made some simple physics demos with it http://chrisdone.com/toys/ Perfomance seems good.

You use purescript at work? Are they internal-facing apps or external-facing? Would love some more details.

Re: How we secretly introduced Haskell and got away with it

#188

Post by eru » Mon, Mar 06, 2017, 12:01 PM UTC

saosebastiao wrote: post #178

zeptomu wrote: post #175

Earlier quoted context omitted.

Can you elaborate on that? What's an industrial simulation (compared to a "regular" simulation) and why do you like to solve it with inheritance?

An industrial simulation, in my context, is modeling the stateful flow of things through industrial processes. It typically involves millions of instances of thousands of types. There are typically much fewer very well defined processes, most of which would be trivial to implement with a simple impl trait with default methods. But some require stateful members in order to implement a default behavior, but Rust traits…

There was an interesting talk about industrial simulations at the International Conference on Functional Programming this year.

(The gist was that avoiding mutation and keeping everything purely functional allowed them to roll back and forth in time with no problem, or try out multiple different futures. That's somewhat orthogonal to inheritance.)