marick

1393 $ /usr/local/lib/node_modules/node/bin/node[82126]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
 1: /usr/local/lib/node_modules/node/bin/node[82125]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
 1: /usr/local/lib/node_modules/node/bin/node[82122]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
 1: /usr/local/lib/node_modules/node/bin/node[82123]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
 1: /usr/local/lib/node_modules/node/bin/node[82127]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
 1: /usr/local/lib/node_modules/node/bin/node[82120]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
 1: /node::Abort()usr/local/lib/node_modules/node/bin/node[82121]: ../src/node.cc:4012:void node::PlatformExit(): Assertion `(err) != (-1)' failed.
node::Abort() [/usr/local/lib/node_modules/node/bin/node] [/usr

marick

Clojure

• Clojure excels at transforming streams of data. It’s great at taking data flooding in from a network, changing it, and storing it into a database.

• Clojure code is interoperable with Java programs because it’s compiled to run on the Java Virtual Machine. For Java shops, that means it’s easy to adopt gradually. (It’s just one more JAR!)

• There is a mostly-compatible implementation, ClojureScript, that runs on the JavaScript Virtual Machine (that is, in-browser). Many open source libraries work in both implementations, and you can write your own libraries to work that way.

• There is a lot of emphasis on performance. The underlying data structures are tuned to work fast. For many many execution profiles, you can expect performance not too different from Java’s.

marick

> To show the use of `map` and `andThen`, let me define a function
> `headButLast` that takes the `head` of a `List String` and removes its last
> character:
> 
> {lang=elm}
> ~~~~~~~~~~~~~~
> > headButLast ["Dawn"]
> Just "Daw" : Maybe.Maybe String
> ~~~~~~~~~~~~~~
> 

marick

...

Like a lot of the early agile advocates, I was programming in the 1980's, when programmers didn’t tend to be people who thought it was a way to become rich. As I thought of it at the time (and it might even be true), programmers were divided into two categories: corporate drones and people with a strong math/physics attitude, including a lot of received wisdom about elegance and simplicity.

I was the latter. So were a lot of people who’ve come to be identified with “Agile”. What we noticed was that when programmers like us had power, we tended to favor our own values over those who were actually paying for the software we were writing. We’d force users to think in terms of our abstractions instead of their own — which tended to be messier, less abstract.

Some of us became “reformed sinners”, became much more inclined to err on the side of letting the users’ needs drive the software. We still had our values, but not at the expense of theirs. Sometimes a magical thing happens: we can find abstractions

marick

(<$>) :: Functor f => (a -> b) -> f a -> f b

vs.

(<$>) :: Functor f => (a -> b) -> f a -> f b

marick

TL;DR: given a functional-reference/optics library, should you be able to say "set the endpoint of this path to X, creating empty elements along the way as necessary"?

---

Scala and Elm have a lens implementation libraries (Scala, Elm). They add an Optional to the canonical Lens/Prism/Iso types. It's useful for dictionaries/maps/hashes. I think it corresponds roughly to Haskell/Lens's Lens.At. I have a question about the behavior of Elm's version that seems Not What You'd Want, but can't interpret the Haskell or Scala versions well enough to determine an answer from them.

The issue is composing two Optional values together. Suppose we have two Optionals that focus on particular keys in a dictionary:

• top is an Optional tha

marick

Types and tests in functional programming - a workshop

Edinburgh Scotland, [[[date]]]

An interesting thing about types and tests is that they have a long history of programmers embracing them reluctantly (at best). But in this century they've both become respectable -- even trendy in some circles. One difference from the old days is that proponents of both emphasize a claim that their tool is useful in design, not just in checking implementations.

This workshop assumes that claim is true enough. That is, despite all the other virtues of types and tests, we believe their value for design is worth exploring and amplifying.

However: types and tests come from radically different traditions. To a considerable extent, their communities don't talk to each other. That's a problem, because it makes it easy to see types and tests as antagonistic approaches to design. Positions could harden -- perhaps have hardened -- before there's been serious work to discover and articulate how they could be *complemen

marick

-- To make things interesting, I decided to assume a 32-bit machine.
-- Because invalid 32-bit numbers don't lie on nice boundaries, you 
-- have to be careful about doing validity checks before multiplying.
-- That is, you can't calculate out a value of 2147483648 and then
-- check if that's bigger than the 32-bit boundary (2147483647) because 
-- on a 32-bit machine, the value you'd be checking would be way negative.

toInt "1" => 1
toInt "-1" => -1

marick

What the book covers

The book will begin by teaching the ideas behind the Elm programming language. Elm is one of the breed of languages that compiles down to Javascript. It's also--as far as I know--the friendliest of the static FP languages. Its error messages are superb. Its documentation is good and errs on the side of plain language over jargon. Its emphasis is on the beginner, and the features it provides are well-chosen for that audience. Its command-line interface (the "repl"[^repl]) doesn't present you with

marick

type alias FormCommon more = 
  { more
    | id : Id
    , sortKey : String  -- Distinct from name so that changing the name
                        -- doesn't cause list entries to change position
    , effectiveDate : DateHolder
    , intendedVersion : Int
    , species : Namelike
    , name : Css.FormValue Namelike
    , tags : List Namelike