ocharles

I'd be more worried about the content becoming even more extreme.

CircuitHub (https://circuithub.com) | Full-stack (Haskell, Elm, NixOS) engineer | London, UK | Full Time

Join our growing team to work on a variety of problems across CircuitHub's entire stack. No direct experience with factory automation or electronics is necessary but we like curious people willing to learn.

Our stack:

* Haskell API server using GHC 8, Yesod, Opaleye, and many other libraries from Hackage.

* Elm front end.

* PostgreSQL for data storage, with querying via Opaleye & Rel8.

* AWS / Heroku for hosting.

* NixOS for development environments, continuous integration and deployments.

* Functional reactive programming for standalone GUI applications.

* Prometheus and Grafana for metrics and instrumentation.

What we look for:

* You enjoy figuring out what to work on and teaching yourself whatever you need to get the job done.

* You enjoy working as part of a team and you're also happy working on your own.

* An ability to move quickly and and respond to changing requirements.

* Pride in your work, taking ownership of features and collecting requirements from end users.

Interested? Get in touch! https://circuithub.com/careers/haskellers

It depends what you mean by "good UI libraries", but there is http://elm-ui.info/ for one. Perhaps that helps?

Is there any evidence you can provide for this? I don't necessarily dispute it, but I don't entirely buy that it's just for rendering - I thought some games were starting to offload particle systems and physics.

Also see

https://github.com/hedgehogqa https://hackage.haskell.org/package/smallcheck

That's right, we should always strive to assess technical projects based on how the author communicates.

I have been writing Haskell professionally for about 4 years now, and I absolutely love it. I'm constantly finding myself having to answer questions of "So, what do you mean?" or "what is this" so early on in development. Never before have I had a language that is so directly tied to my understanding of problems.

On the practical side, I love having types that let me refactor so mercilessly, along with a very mature compiler with a decent suite of warnings.

You wouldn't implement this in production, you would use a library - just like 90% of everything else you do in production. This paper is packaged up here https://hackage.haskell.org/package/logict

Oh neat, I didn't know Ross had actually released a version of transformers with Select. Now I've got to go learn it.

The point is that you don't need to write the types down anymore. The program is still typed, but the compiler can figure out what the type of variables (in a well typed program) needs to be. As said, this has previously been a hard problem. If you're familiar with the `auto` keyword, think of that - but everywhere.

https://twitter.com/acid2/status/811691084623527940 has some update

Yea, it's only Edge, but if you look at WebSockets you'll see that everything except Opera Mini supports them - so you can get (some of) the same functionality without polyfills at all.

It's a shame Server-Sent Events aren't universally supported. I find them a lot simpler than WebSockets - modifications are just normal HTTP calls, and then you can broadcast the actual result of the transactional call back down with a SSE. But Edge doesn't support them :(

Probably the sexist nonsense about pink appealing to girls and scaring off "the boys"?

> I often format code in a specific way for regularity:

I am trying to write my own formatter at the moment, and this is exactly the property I want, also. I'm working in Haskell, and one example is case statements. There are two ways I'd like to format them:

case foo of A -> ... B -> ...

or

case foo of A -> ...

  B ->
    ...

The first is when every case fits on one line, but the second is when at least one case needs to span multiple lines. I don't want this:

case foo of A -> ...

  B -> ...

I haven't yet come up with a good way to do that heuristically and efficiently, but maybe just looking at how the original code is formatted would be enough! Thanks for providing some food for thought :)

This becomes very difficult when languages change their AST. Most languages are still evolving and the AST changes.

A related quote that's sticking with me well at the moment is "no one wishes they spent more time on their phone when they are on their death bed".

For more realistic stuff, I generally use https://hackage.haskell.org/package/text-icu. For example, in an old project we had a type called `Texty`, which was roughly non-empty normalized text:

  mkTexty :: Text -> Maybe Texty
  mkTexty = \a ->
      let a' = T.dropAround Char.isSpace (ICU.normalize ICU.NFC a)
      in if T.null a' then Nothing
                      else Just (Texty a')
  {-# INLINE mkTexty #-}

There's a good chance you'll end up on a list if you're an exit node, but if you're just using Tor I think you should be good.

If there are any bug reports you could file, that would be much appreciated. Installing Emacs should just be a case of downloading the prebuild binaries, which shouldn't take long at all. I use Spacemacs and have never encountered any problems. I have a feeling things are still a lot worse on OSX though...

hint is a really fun little project. I used it in a toy project to add Haskell as function language to PostgreSQL here: http://github.com/ocharles/plhaskell.

It's really messy code, and I have to do a bunch of hacking to invent a type from the PostgreSQL function metadata, but once I do that I can invoke hint: https://github.com/ocharles/plhaskell/blob/master/PlHaskell....

> hrowing away the earlier version and replacing it with the argon-wrapped version can't hurt them

Are you sure? And if so, can you convince me as to why you are so sure?

Consider something like https://pythonhosted.org/passlib/modular_crypt_format.html and support all your old hash-functions. If you really want to migrate people to the new hash functions, you can:

* Fully expire the accounts (and send emails asking them to reset their password)

* If they successfully login to their account and you have the plain text password, you can re-hash that using argon2i.

* Have them reset their password on next sign in before allowing them to do anything.

* Let the user know their account has less security than it could, and they can upgrade the security by changing their password.

Afaik, there is nothing you can do to upgrade their passwords, modulo argon2'ing the result of another hash function - I am simply too unclear on the safety of this approach so I don't do it.

Haskell bindings are here: https://hackage.haskell.org/package/argon2-1.0.0/docs/Crypto...

Yes, this is a terrible idea - it violates referential transparency, which is a property that is always worth working towards, imo. I can't think of a reason to justify breaking that property in this scenario.

I'm aware of that. You didn't however have such a reliance on cars, nor the convenience afforded to having a car (e.g., the popularity of drive-thrus now, which were only getting started in 1980). There is such easy access to things like Netflix and Steam - it is very easy these days to waste entire days away without even noticing.

Does this study factor in the huge life style changes over 20 years? Far more access to cars, and far more spending entire days sitting down (computer jobs, Netflix binge watching, etc). A lot of how we live has changed in 20 years, I'm inclined to think the problem lies there, not in environmental factors.

Do you have any information that cold showers are really beneficial? I spent a month doing it, saw very little benefit - other than a mental pat on the back because obviously enduring something I didn't enjoy must be good for me. I can't find anything convincing that a cold shower really does much.

Are you using --pure? I'd imagine these problems are from lost environment variables, but only --pure should clobber those.