chrisdone

What a coincidence, slightly!

I recently registered keybase.vote for a related web app idea. Rather than anonymous voting, rather, I wanted the opposite: authenticity in voting, polls, surveys, etc. A common problem in surveys is verifying that the respondents are real and from people you trust. Within small communities, you would have a large enough web of trust that you could rely on who you are following to determine who you individually pay attention to from the result set.

So my idea was simply to have the survey/poll generate a text field of all the Q/A in a JSON body, kinda like the proofs of keybase, and then have the user copy/paste it and sign it on keybase and then submit their response.

I would have the whole result set downloadable in raw format that anyone could easily verify with keybase commandline tools. But I’d also employ the web of trust created by following on keybase.

I thought I’d try it out and see if works. I like the idea of Keybase being a general way to authenticate without needing any elaborate login process or email acccount.

As I wrote elsewhere that depends on the string type used: https://www.reddit.com/r/haskell/comments/b0l93l/how_we_made...

I feel that there is a wealth/background effect here that could be studied somewhat too. I think people who don't have to worry about money are less likely to pay any attention to discounts and deals.

Having come from a council estate, there is a certain mindset behind getting a deal for everything, making your little money go as far as possible, buy one get one free, or discounts on anything, or coupons to get into restaurants or discounted vacations, or companies that "get you deals" on all your electric, gas, TV, internet bills, 8 packs of cheap beer, etc. are all seen as victories and you are crazy for not taking advantage of them. There's an emphasis on getting more quantity for less money. That's easily exploited.

If you're saying they should have solved a distributed problem with a distributed language like Erlang, I'd probably agree.

Adding examples, with dependent types we can write the type-safe printf in Idris:

https://github.com/chrisdone/sandbox/blob/master/dependently...

Meanwhile with Liquid Haskell (refinement types), it was really easy for me to define a date data type that can only construct valid year-month-day combinations:

https://github.com/chrisdone/sandbox/blob/master/liquid-hask...

The `if ..` tests are all required, otherwise Liquid Haskell rejects the program.

So I see value in both directions, if you extrapolate from these examples to harder problems.

> There needs to be stricter regulations which prohibit apps

I was agreeing with you until there. We don't need censorship. Anything you see online is a reflection of the attitudes and education of the people using it.

The characterization of philosophical delight as "progress" is a downer.

This reminds me of Watt's zen-based observation that we make all decisions by gut feeling, noting that it's _us_ who grant authority to outside sources, and that any time spent making a decision is usually dithering. Regarding the article, leaning on a previously concluded opinion, or saying "I don't know", are both forms of unthinking, and not being open in the moment (dithering). "I've seen Shunryū Suzuki take 5 minutes before replying with an answer. But he never hesitates." (There's a difference, see?)

A designer can just write HTML or some toy language.

A programmer will translate it to something manageable eventually anyway. A trivial automatic process can convert HTML to a DSL. Although making code sensibly refactored and readable is usually a manual job for the programmer.

I have a bunch of open source projects; I'm getting quite good at giving my projects new homes because I don't want to maintain them anymore.

Speaking for myself, thanks is fine but I don't need it; thanks doesn't do anything for burnout. People using my software is enough thanks. The biggest thanks is someone contributing a useful bug fix or needed feature. Time and effort is the currency in open source.

Oh, that explains why it's familiar. I might be mixing them up. There's a similar ... thing in DF. Trying not to spoiler.

Dresden Files reference. Excellent.

I'll cite your Hacker News comment in my next paper.

Direct your "so?" at the original poster who pointed out that a particular land was acquired by force, as if that was somehow notable.

I think language plays by natural selection rules; speciation mirrors groups of people that don't speak to each other anyway.

Funny I read the whole thing thinking that this is like The Language Instinct by Pinker and then at the end saw it was by him. That explains why nothing but one point in it was new to me.

The point that did spark my interest was that it's not rules that are important but expressing yourself as a writer (or speaker), which most people are poor at.

Pinker is good, Christopher Hitchens was good, George Orwell was excellent at condensing ideas down into clear, lucid pros. Our own Dijkstra is probably admired mostly for his ability to write so clearly regardless of the topic. Hacker News's Paul Graham's success as an author of articles seems to me to be 80% his writing abilities and 20% actual valuable ideas.

That comes down to the really important point for me. It doesn't matter how good your ideas are if you can't communicate them, they'll just sit in the shed propping up cobwebs. You may get lucky and someone else does it for you. If there's a "one thing" that language teaching efforts should be focused on, it's getting your point across effectively.

> Purity is tricky to define.

I think it's pretty easy.

Purely functional (it's important to retain the word "function") means that we have a language in which the value of a function application "f x" depends only on the body expression of "f" and the function argument "x". That's why we say "purely" functional, because it's just functions of this flavor.

In types, f : X -> Y means that for all terms in X, f x maps to a unique term in Y. In Haskell's, Elm's and PureScript's case, it's weakly normalizing (meaning it might get in an infinite loop). In Agda's case, it's strongly normalizing (modulo implementation bugs).

> if you can measure how much time a computation takes, then Haskell is impure, because a lazy value takes longer to compute the first time than the second

Time is an operational concern. "Purely functional" is concerned with what things mean, what do syntactic expressions in the language denote? If 1+1 launches missiles every time it's evaluated, or causes the machine to get hotter by 1°C, that's an implementation detail that is not observable in the language. 1+1 normalizes to 2. You can do all your regular equational reasoning and follow the substitution model. You might chide the writer of the interpreter or compiler, though.

For example, here is a substitution stepper for a dialect of Haskell http://chrisdone.com/toys/duet-gamma/, and each line in the bottom left is equivalent to the line after it. You can pick any of those lines as your starting point.

> And that raises another problem, where printing to standard output becomes "pure" if the standard output can't be observed by pure code (which is true in Haskell).

It doesn't "become" pure. You're making a category error by calling an implementation detail by names that we reserve for expressions in a language. We should use "observe" in a precise way: to observe means to write a case analysis on something.

> You could try to patch it up by saying the impurity must be observable via pure code, but that makes the definition circular.

Where exactly is the circular part?

Direct mutations for a mutating algorithm is certainly faster than rebuilding a data structure representing a set of variables. Most of the time. Though, there are exceptions where they're equivalent thanks to GHC's optimizations (e.g. splitting up a record's fields into n registers).

I believe that Aurora (covered in the article) was some kind of pre-cursor to Eve, by the same Chris Granger.

I generally get a slimy feeling whenever I interact with someone who is clearly applying some kind of rules of how to interact, make you feel comfortable and listened to, nodding at the right times and fake-laughing on cue, all the while I feel more and more uncomfortable and alienated. There are certain things you've either got or haven't got. You can't read a book to be good with people any more than to become a good comedian.

However, I would prefer that people at least be explicit about the fact they're doing such things. Then it's just process, and not fake and uncomfortable.

You're (presumably) being paid for 5 days a week at 8 hours per day.

If you cannot manage your time reasonably within this period, consider doing some research into that. If you can and yet your employers expect more time, then you're probably being exploited.

Either way this is not normal.

I don't think you can "explain" to people that you need to concentrate, if you've already told them in ten different ways, then they know what you think you need, and either (1) don't care about your needs, in which case you are doomed, or (2) they see in your actions that you still do your job anyway, so it can't be that bad. The fact is, for most of us, even if we are interrupted, we still do get the job done. Just not as comfortably or in such detail as we'd like.

I've been through the "explaining" phase of trying to help my spouse, who cares a lot about my ability to do my job, and yet is a prolific interrupter, "get it". It hasn't worked for me. It leads to bitterness and arguments.

The healthy solution: If you need peace and quiet to concentrate, like me, get yourself your own space. Start going to a different room to concentrate, or a co-working space (if you work from home). Depending on your job, you might only need a certain percentage of the day for solid concentration.

I came to the same conclusion. If you have someone around who can't help interrupt you, either by directly asking you for responses or doing distracting behavior, it's wise to simply get your own room, in the house or in a coworking space or a proper office. It doesn't matter how much you try to coach and train someone to respect your need for peace and quiet while working. It only leads to arguments and bitterness. It's much healthier to solve it by physically moving to a quiet place. I found that while it's possible to get work done in that environment, moving to your own space by yourself is a whole different experience. You can finally concentrate without fear of distraction (which is itself a distraction).

In Haskell and PureScript, `fmap` is a method in the `Functor` class, which is defined by

   class Functor f where

     fmap :: (a -> b) -> f a -> f b

for which instances should satisfy `fmap id = id` (and you get `fmap (g . f) = fmap g . fmap f` for free). If you can find a type for which you can implement `fmap` and satisfy the laws, then you have an instance of `Functor`.

That's the precise and short definition. It assumes the following knowledge:

0. How partial application works and the . works.

1. How Haskell's type-classes work (`Functor`).

2. How Haskell's methods work (`fmap`).

3. How Haskell's higher-kinded types work (the `f`).

So good luck explaining `fmap` in one sentence unless you already know Haskell and understand its type system to a confident degree, which depending on your background can take weeks to months.

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.

I don't really use foldr even in Haskell. It's almost always a performance problem.

I think it's a much easier pill to swallow than laziness.

You don't have to study its effect system in detail, there's not much to it. Instead of IO a you have Eff e a, where e is a record of effects, using PureScript's records support. The neat thing is that statements in the Eff monad tend to get compiled to x; y; z in the resulting JavaScript, which is great, you don't pay a performance penalty. Check out the source code in this demo: http://chrisdone.com/toys/elastic-collision-balls/ There is still some overhead for currying, but there's a lot of room for decurrying saturated calls.

You might be happy to hear there is a PureScript native compiler. I'm also averse to JS things, I use PS but don't use the node-based tools to build it.

Stack requires package sets (aka "snapshots"), which some kind of CI system (Stackage: http://stackage.org/) has to do a daily build job to see if they all build and pass tests together. That requires some money to keep running, and buy-in from package authors as there is a maintenance overhead each release. It took a few years for Stackage to get enough packages in it to be generally useful, and then we wrote the Stack tool which was able to default to using Stackage snapshots.

There was (and still is a little bit) of resistance to the whole idea of Stackage from the community; people liked the idea of build plans magically being figured out on demand, it's an interesting research problem (it can be hard to let go of an interesting problem when a solution side-steps it all together). I believe eventually many people changed their minds after experiencing the simplicity of using Stack and not having build hell be a substantial part of their development cycle.

Python would likely have to go through the same process. Although with Stack and Yarn providing frozen builds (and QuickLisp); the idea has some precedence, which makes it an easier idea to sell. I mean, Debian and a bunch of other OSes do it like this, but experience shows programmers don't pay attention to that.

I think making sense of the scale of weather would be aided by an accurate world map like the peters projection or something of that nature that doesn't do Eurocentric seafaring things like put Greenland as being the same size as Africa when Africa is like 11 times larger in reality. For example, with a proper map, the fact that much of the northern Atlantic landmass is heated by the sea would make more sense -- it's a much smaller area in reality than is represented.