
From Haskell to Hardware [video] - begriffs
http://begriffs.com/posts/2015-06-28-haskell-to-hardware.html
======
agumonkey
I didn't even realized it was Conal Elliott. You're all invited (one at a
time) to visit his blog and enjoy the ride.
[http://conal.net/blog/](http://conal.net/blog/)

Especially if you're into Functional Reactive Programming, rendering, etc, ...

His [re]definition of 3d rendering was gold:
[http://conal.net/blog/posts/3d-rendering-as-functional-
react...](http://conal.net/blog/posts/3d-rendering-as-functional-reactive-
programming)

------
snaky
There's a good set of slides by Conal about the project

[https://github.com/conal/talk-2015-haskell-to-
hardware](https://github.com/conal/talk-2015-haskell-to-hardware)

------
eatonphil
Did not watch the video, is this about Bluespec?

~~~
tinco
No, and it isn't about Clash either. It's a system they designed for a now
defunct hardware startup called 'Tabula'.

Apparently the technology was some sort of space-tech FPGA that could
reconfigure at 2Ghz (i.e. close to the general max clock speed), they use
Haskell's typesystem and non-sequentiality to build these circuits in a nice
parallel way.

~~~
listic
Sounds very rad. I wonder why they closed and what they managed to accomplish?

~~~
mng2
The comments on this EETimes article[0] are snarky but the criticisms sound
cogent to me.

0:
[http://www.eetimes.com/document.asp?doc_id=1325499](http://www.eetimes.com/document.asp?doc_id=1325499)

------
DevPad
This posting convinced me to learn Haskell. But it requires to be more than
just a programmer.

Why I love Python, - because of scientific-friendly community.

Haskell is more than that: more algos, data structures, functional
programming, math, - completely next level.

~~~
Kenji
Be prepared to be much less productive in Haskell; you can't just get into it
and start writing code. Everything must be well thought out before you start
to write a line (and yes, that's how it's supposed to be but sometimes it's
easier to just hack something together to see what issues might arise, and
then make it beautiful). On the other hand, the beauty of Haskell is that the
code is much cleaner and modular. Don't be fooled, though: Even in Haskell you
can write very ugly code.

~~~
dllthomas
_" Be prepared to be much less productive in Haskell[.]"_

Likely to be the case, but mostly because there's a lot to learn before you
can be effective as an intermediate or senior level Haskeller.

 _" [Y]ou can't just get into it and start writing code. Everything must be
well thought out before you start to write a line (and yes, that's how it's
supposed to be but sometimes it's easier to just hack something together to
see what issues might arise, and then make it beautiful)."_

This is not the case at all. You can write Haskell that way, but remember that
1) with type inference, you don't need to specify the types of most things up
front; and 2) you can change your types as you go. You can totally just start
coding, and then later peel out this tuple into a named type and such. I find
I'm most productive somewhere between the two extremes - start from the few
types that I know must be fixed (by the fact that I'm interfacing with other
code expecting them), then continue sketching in both types and code and let
each guide the other.

 _" On the other hand, the beauty of Haskell is that the code is much cleaner
and modular."_

When you're doing it right, absolutely.

 _" Don't be fooled, though: Even in Haskell you can write very ugly code."_

Also very much the case - I've done it!

~~~
merijnv
> "Don't be fooled, though: Even in Haskell you can write very ugly code."

> Also very much the case - I've done it!

On the bright side, refactoring ugly code into not ugly code is substantially
easier in Haskell than many other languages! ;)

~~~
dllthomas
It can be. It depends on the reasons your code is ugly. Meaningful refactors
are much easier in Haskell. Small, local improvements in clarity aren't going
to be substantially different between Haskell and other languages.

Also, it's worth noting that Haskell has a couple ways it can get ugly that
are less of an issue in other languages.

First, point-free programming can be incredibly clear when you've got a simple
series of transformations of relatively simple data. Sometimes it winds up
over-applied, in situations where it would be clearer to break things apart.

Second, most languages enforce a distinction between expression and statement.
That Haskell doesn't gives more flexibility about how one breaks up
expressions. This flexibility means that sometimes ideas can be expressed more
clearly, but it's an additional thing to learn on the path to writing readable
Haskell.

