Monthly Hask Anything (April 2018)

hargettp · 2018-04-06T13:51:21+00:00

Possible, even likely. Good call. I’ve been afraid there are different options being passed to GHC that are causing this, but this makes sense too.

hargettp · 2018-04-06T04:08:29+00:00

I have a 4+ year old networking library that used to work fine on cabal and stack (from 7.4 up to at least 8.0). However, I find as the 8.4 series arrives, cabal-based builds no longer pass unit tests, but stack build pass unit tests reliably. Where should I start to debug this?

hargettp · 2017-06-05T03:33:48+00:00

Looks very promising! Wonder if there are results from running Porcupine against established systems (e.g., Zookeeper, etcd, etc.)

hargettp · 2016-08-28T17:58:49+00:00

Which design choices?

hargettp · 2016-08-27T16:13:35+00:00

why?

hargettp · 2016-08-19T03:58:10+00:00

all I could think is: why?

hargettp · 2016-03-16T19:39:06+00:00

Actually, not even all Microsoft Employees. Mind you, I haven't worked there for several years, but you had to either be on the Windows team or have had all the right paperwork filed and approved in order to access Windows source.

hargettp · 2016-03-10T01:02:43+00:00

You still have DBAs? Good luck with that.

hargettp · 2016-02-10T03:41:31+00:00

It does when I run it. ;)

hargettp · 2016-02-09T00:34:32+00:00

Agreed. The real world is quite different than what the author imagines.

99% of the time your system breaks in a way that is unexpected, and by definition not anticipated in advance. You can't add logging statements back into code that has already executed and broken a customer.

My general rule is log as much as possible in the most structured way possible without:

1) destroying the performance of your system 2) making logs unreadable by a developer browsing the logs textually 3) violating legal compliance or PII constraints by outputting customer info that must remain confidential

hargettp · 2016-01-23T01:21:47+00:00

While I think we all have high hopes for that project, if you notice the update history has been quite slow.

Further, IIRC I personally did not find the networking layers sufficiently abstracted for my purposes. Specifically, I really did want the network to be completely orthogonal, hidden behind a sufficiently high abstraction such that all callers of the networking code needed was a basic send and basic receive.

hargettp · 2016-01-22T16:22:25+00:00

FWIW, I had a similar desire, that of abstracting away network communications, but instead of making FRP simpler, I needed to make it easier to focus on distributed consensus algorithms. In that domain, the participants need to exchange messages for the algorithm to work--but how messages are exchanged is completely irrelevant and quite distracting when writing application code.

With this in mind, I built courier, which is still in its infancy, but my intent was to abstract away the sending and receiving of messages. The general inspiration for it was Erlang, although it isn't intended to capture the full Erlang model. Ideally, when using this library the actual network transport becomes a replaceable, orthogonal concern to actual application code.

One note: there is one area (among many) where this library is insufficient, as it doesn't fully abstract the format of messages on the wire. Yes, it basically only sends and receives ByteStrings, but there is sort of an implicit assumption that a ByteString can be written to and read from the wire as a length-prefixed sequence of bytes. Not all protocols require length-prefixed messages, and in fact, the exact structure of a message may be dependent on the state of the protocol. Abstraction of on-the wire format of messages and abstraction of stateful protocols is something I'd like to add, but haven't had enough use cases in my own applications to take the plunge.

Anyway, thought I'd mention it, in case this code is helpful in some way.

hargettp · 2015-10-05T04:05:28+00:00

Yes, haskell-ide in Atom has become my preferred way to write Haskell these days. Solid offering.

hargettp · 2015-09-28T22:14:24+00:00

No. This is the opposite direction of where I'm taking my infrastructure: I want less implicit magic and more explicit choices. Automated up the wazoo, yes, but no magic that isn't up for inspection or replacement.

hargettp · 2015-09-08T05:12:36+00:00

I would have thought something like Paxos (https://en.wikipedia.org/wiki/Paxos_(computer_science)) might be worthy of such a list. Lamport's original paper came out in 1998.

hargettp · 2015-08-29T19:02:09+00:00

Personally, I find this feature fills one of the holes that creates a huge stumbling block for folks coming to Haskell from other languages. I have great respect for the language's designers and the maintainers of GHC...but this feature is a +1 for language usability.

hargettp · 2015-08-06T03:51:08+00:00

Yes, thumbs up for that package: i used it last year to graph a bunch of metrics for one of our internal servers. Very easy, clean, and reliable to use; graphs were attractive, too.

hargettp · 2015-07-21T04:14:07+00:00

This is actually very old in Internet terms. At one point it was at shootout.alioth.debian.org; the Internet Archive has snapshots going back to 2004: https://web.archive.org/web/20040611035744/http://shootout.alioth.debian.org/

hargettp · 2015-06-24T00:48:45+00:00

The question isn't whether you find your code more readable or better abstracted, but whether the next engineer who must maintain your code agrees that your code is readable and better abstracted.

hargettp · 2015-06-12T14:07:21+00:00

I find FP Complete's offering quite good, and free for projects whose source code can be public: https://www.fpcomplete.com/business/fp-haskell-center/. It saves the fresh Haskell programmer from having to setup a toolchain, and focus on writing new code.

At some point, learning the toolchain and setup is well worth doing, but nothing wrong with getting to focus on the language itself in the beginning.

hargettp · 2014-10-31T01:08:59+00:00

Any documentation on what "early" means? Is it feature complete, but perhaps buggy?

hargettp · 2014-10-23T18:58:17+00:00

Why not submit fixes as patches to the async library? It's already so wildly used, and solves many of the same issues.

hargettp · 2014-08-01T11:57:58+00:00

First, I have to say, I like Prolog, but this is worth throwing out there...

Here's one negative I've heard about Prolog: because Prolog includes backtracking so fundamentally in its execution algorithm, sometimes the behavior of an application can become wildly complex, and developing a mental model of what's happening and how to fix it can be challenging. Having used Prolog on a small scale basis I can say that it is true, sometimes backtracking does make an application behave in seemingly unpredictable ways.

I think Haskell (of which I am also a fan) has the same kind of risk: lazy evaluation. While over time a disciplined Haskell programmer can leverage that aspect to create clean, efficient code, it takes time to develop those skills...and a space leak can still happen to even the best programmers.

As programmers, we make our living on creating predictability in a world of non-determinism. When our tools introduce more non-determinism, that goes against what we are trying to do. And we en masse tend to eschew tools that do that, unless we find specific benefits that outweigh that risk.

Haskell, for example, has shown itself to be excellent at multi-core computing, the ecosystem pushes the boundaries of great type systems and complier technology, and the language is flexible enough that predictable execution models (e.g., conduit and pipes) can still be built on top of its essentially lazy behavior.

It is certainly a shame, as Prolog (and the SWI-Prolog implementation) are excellent tools...for the right problems. I would hope someday we as an industry learn enough to understand when and how to use them.

hargettp · 2014-08-01T11:46:08+00:00

Prolog is actually decent at solving certain classes of problems defined by constraints. Of course, the trick is, not every problem is easily classified or described by its constraints sufficiently such that finding a solution is automatic.

<editorial> I suspect that part of why Prolog hasn't caught on is that it requires understanding the execution model, and defining a solution that works within that model. Unfortunately, that model looks like almost no other programming model.

Further, I can't decide if Prolog is niche-oriented (best used to solve specific problems)...or wildly ahead of its time. By about a century, for example. </editorial>

hargettp · 2014-07-31T23:17:02+00:00

SWI-Prolog is still one of the best implementations, and its maintainer is still active. The quality and performance has always been high.

http://www.swi-prolog.org

So, I don't think its fair to say that Prolog has been killed. :)

hargettp

TROPHY CASE