ff_

Here's a wrapper for express: https://github.com/nkly/purescript-express

Examples: https://github.com/nkly/purescript-express/tree/master/examp...

Agreed. Documentation is hard in all languages though, and it usually gets fixed slowly over time as langs mature.

If you had dependency problems you were likely using bower (where dependencies are "resolved", and this leads to broken states in some cases). You might want to try a "package set" approach instead - i.e. there's a curated set of library versions that are known to work together, so "dependency problems" become impossible for users: https://github.com/spacchetti/spago

AFAIK it's strongly discouraged: https://github.com/elm/projects/blob/master/roadmap.md#can-i...

One of the biggest reasons for me is that you can run it on the backend too (on NodeJS, or Erlang, or some other VM - yes, there are several backends available)

Most of if is already wrapped in a well-maintained package: https://pursuit.purescript.org/packages/purescript-web-dom/2...

But doing FFI and just using JS when needed is very easy: https://github.com/purescript/documentation/blob/master/lang...

So, to answer the question: no, it's exactly as in JS, because _it is_ JS

I think this is pretty ok news: if Maps gets too annoying to use an increasing amount of people will start using alternatives, which will get better because of this, and in the end it will make it easier to live a Google-free life.

This is easy to say and not unheard of, but in organizations it is common (in my experience at least) that if you say too often "this is hard and might take some time", people will just start to bypass you (and/or your input/judgement) in order to get stuff done quickly but less correctly.

This is an interesting paper, and I'd like a replication today, 25y after: I believe Haskell has matured a lot in all of this time.

As an experiment, some months ago we prototyped a new service in Haskell at work. We timeboxed a week for it (two people, proficient in Haskell), and the result is that (1) the Product Owners were really pleased with it, and (2) even if it was really bad Haskell code, we _still_ managed to encode business logic in the types so that it would always hold some important invariants. As a result we had to fix a surprisingly small amount of things before putting it in production.

The best thing is that as it happens we couldn't properly rewrite the prototype, so today's service is still the same codebase, BUT it's not a Python blob and it was such a breeze to refactor.

EDIT: would anyone be interested in a blog post "Rapid Prototyping in Haskell"?

I believe a "Helsinki HN meetup" would be super crowded

I cannot access it as well, but it should be "Cosmodrome"

Here's a nice explanation on why using "reasonably powerful languages" has many disadvantages: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant...

Also you might be familiar with the Rule of Least Power: https://en.wikipedia.org/wiki/Rule_of_least_power

This is a great analysis, but it's missing a fundamental point: why do we have a problem with these approximations of a programming language or just using a programming language to template stuff?

Because your build then becomes an actual program (i.e. Turing complete) and you have to refactor and maintain it! This is the common problem of using a "programming language as configuration" (e.g. gulp?)

Dhall solves exactly this problem: https://dhall-lang.org

It has the same premises of Pulumi, but without the Turing completeness (I don't know if/how Pulumi avoids that, but if it does it should be part of the pitch), so you cannot shoot yourself in the foot by building an abstraction castle in your build system/infrastructure config.

We use it at work to generate all the Infra-as-Code configurations from a single Dhall config: Terraform, Kubernetes, SQL, etc.

And there is already an integration with Kubernetes: https://github.com/dhall-lang/dhall-kubernetes

Amazing, thanks a lot!

I'm also following a GTD-like approach (and I strongly second the recommendation on the book)

My Trello board has the following columns:

- MAYBE - for things that I'll maybe do

- BACKLOG - for things that I decided I'll do at some point

- WEEK - for things that I'll do this week (limit: 8 items)

- TODAY - for things I'll do today (limit: 5 items)

- DONE - move things here once done

Once a week I do a review session where I clean the "DONE" column and reshuffle things in the other columns as needed

Super interesting! Do you happen to have an Italian translation/version of the paper?

Indeed it was Moxie: https://moxie.org/blog/we-should-all-have-something-to-hide/

I'm you but 6 years later :)

I actually dropped out of Poli and moved to Helsinki, and most of my friends scattered around Europe.

Did you see this thread? https://news.ycombinator.com/item?id=18045294

Your post has a nice collection of issues, IMO there is one missing: there is absolutely zero interest in investing in research and technology (e.g. afaik there is still no fast internet outside of big cities) and young generations (this is related to the aging population, that makes it convenient for politicians to target retired people to get their votes. Convenient for them in the short term, but not as much for the future of the country)

Also the + operator is typed with Num; from a Haskell repl:

  λ> :t (+)
  (+) :: Num a => a -> a -> a

In case of average we need /:

  λ> :t (/)
  (/) :: Fractional a => a -> a -> a

So our type is going to be constrained by Fractional instead of Num). So an implementation could be (from here [1]):

  import Data.List
  average :: (Real a, Fractional b) => [a] -> b
  average xs = realToFrac (sum xs) / genericLength xs

[1]: https://stackoverflow.com/questions/2376981

I don't know about OCaml, but Haskell has typeclasses (which look like "polymorphic interfaces"?) so you can define functions generically and put a typeclass constraint to make them work on a certain class of types. E.g. your avg function would be of type:

avg :: Num a => a -> a -> a

Where your "a" is a number (that is, a type that implements the Num typeclass)

This would work out of the box on floats, ints, etc

This, so much. After some 3y spend doing Clojure, having a Haskell codebase is a totally new level of stress reduction.

All of a sudden you can stop worrying about "what am I getting in this function" and actually concentrate on the business logic.

(No, tests can't cover everything. Yes, we still have to write tests, but now they are all useful. Yes, the thing that types hinder you from doing changes is a lie, it's quite the opposite, much easier to change things since the compiler covers your ass)

Same here in Finland!

Italian engineer here. The brain drain is real and the graphs represent quite accurately what's happening to me and my peers. (It might be my bubble of course, but hey, now we have this legit-looking snapshot in the article)

The really funny thing about doing any construction work in basically any Italian city is that you already know from the start that there is going to be several years of delay due to finding ancient stuff...

But it's impossible to dig all of that out (reasons: too big, too disruptive, no funds, happens everywhere, etc). So what usually happens is: take pictures, save some artifact, cover with concrete and go on with the works.

Dhall was such a godsend to make our infra configs more safe & modular (we jointly configure Kubernetes & Terraform with it).

If you need some example of use cases to see if it might help you, check out "Dhall in Production" [0]

So far I'm a maintainer of dhall-kubernetes [1] and we'll soon open source some of our integration with Terraform.

And because it's absolutely safe to distribute Dhall code I'm toying with the idea of making some kind of Dhall-Kafka pubsub, in which you can safely distribute Dhall code and data, with automatic version migrations (check this out for more info on why this is possible [2])

[0]: https://github.com/dhall-lang/dhall-lang/wiki/Dhall-in-produ...

[1]: https://github.com/dhall-lang/dhall-kubernetes

[2]: http://www.haskellforall.com/2017/11/semantic-integrity-chec...

Same here. All code goes in a Pull Request, and requires at least 1 approval.

Since Pull Request review is a high priority activity there's no "bottleneck", and you double the bus factor for free + prevent bad things from happening.

I guess they didn't try with a "signed append-only log", they might be able to shave off even these two remaining seconds.

It is a general problem (that is, not only Redux has it, but basically any React-based thing), and the pattern that works best for reusability (in my esperience) is the "pure component sandwich": you have a pure component which takes a bunch of functions as parameters (and is reusable, no framework-specific stuff) and wrap it in the app-specific component which implements these functions for the current app.

Oh wow this is super cool. IME the hardest part of using this kind of accounting software is to keep using it over time, because entering transactions is super boring, and it's hard to build the habit.

Right now, since all my expenses come from one bank account, I export the data from the bank and use a bunch of excel sheets to keep track of stuff, but of course is a quite limited system.

I was wondering if HoneyMoney has some kind of import system? In this way I could just dump the exports in there like once a month.

I come from Italy as well, and felt that sense of dread, and I solved it in the easiest way possible: I moved to another country. In Europe is really easy to move nowadays, and you can pick a well-governed state to move to :)

Looks like OP is the author behind the app, so I would suggest adding a "Show HN" to the title, for more kudos and feedback.

That said, congrats for the good work! I really like the idea, and I feel this problem very much. Currently picking up Swedish, and unable to find easy enough news worth reading every day, so I'm a bit stuck at that level "able to understand a bit but not enough to read everything".

Do you happen to have a roadmap about the addition of new languages? If Swedish was there I would totally go Pro.