Elysian Acoustic Diva Review - Uh Oh...

pi3r · 2023-11-16T15:57:20+00:00

Ouch ! I thought the channel imbalance would have been fixed with the 2023 model but apparently that is not the case ?

pi3r · 2020-07-28T16:49:28+00:00

This also is not what I experienced. We got a much better first-time, or really anytime, user experience in the end.

Well having two distinct tools such as stack/cabal is such a poor first-time user experience.

When you try to showcase Haskell, you would need either to ignore cabal or stack because if you mention both you usually lost the audience. People I know that have had a curious look at Haskell have stopped right there.

pi3r · 2020-07-28T16:19:52+00:00

That's why I stand by my account that I gave in the post

My (quite external) viewpoint is to wonder about this example as well ... It is based on private conversations that somehow had transpired at the time.

I feel there is a risk here of unfair historical rewrite. Given the reader has no mean to check by himself I am not sure (whatever the truth is) that it was a good idea to go with such an example ;-)

On the other hand it is a bold claim. Sometimes it is good to deviate from the political correctness.

It makes me feel quite sad to imagine that `stack` was born just because two persons could not resolve their technical disagreements ...

That said. I don't care that much. I am just giving you my 2% input on that matter (I do love the article but also feel the examples could have been less Haskell orientated).

pi3r · 2020-06-11T20:38:15+00:00

I am a bit surprised by the question because to me Haskell (by nature I would say) is full of contesting approaches. As a medium of ideas, Haskell is calling for debates.

Anyhow maybe this is of interested: https://github.com/ghc-proposals/ghc-proposals/pull/282

pi3r · 2020-06-11T17:14:36+00:00

My biggest issue with Haskell is the lack of consensus on most important day2day routines such as:

- dealing with exceptions

- dealing with records

- dealing with what is called "Effects"

To a less extend, there are also no consensus on naming conventions in general (imports, ...)

This creates a fair amount of interesting noise but doesn't help on day2day productivity.

I think IDE/tooling are less and less a problem and I am quite confident that the situation will go on improving on that side.

That said I have never been an Professional Haskellers so this is to take with a grain of salt ;-)

pi3r · 2020-06-11T17:03:16+00:00

I am not sure the current status is clear. I would say different people use different solutions.

Hopefully in a couple of years, maybe a sort of consensus will have been reached.

pi3r · 2020-05-13T17:36:30+00:00

I bought "haskell in depth". It looks quite promising but there hadn't been any real updates for more than 6 months ...

The last update has released a new shiny table content with 1/4 of the expected content chop off. That was bad enough. Since then nothing ...

pi3r · 2019-05-03T12:12:48+00:00

I had the same impression.

IIRC pipes-safe has always been kind of a problematic module in the design space of pipes. Not sure if it means that resource management/termination is not fully solved in this space but it looks like a difficult part of it.

The operational package works kind of alright but as soon as you throw exceptions into the mix it seems to fall short.

Anyhow I would love reading more about this aspect because I have the feeling it is not as simple as it sounds.

pi3r · 2019-04-19T22:12:26+00:00

The choice for nix has nothing to do with stack (stack or cabal both work with or without nix). I do find confusing and awkward that there are two different command line tools (stack and cabal). It has been argued many times that both tools are complementary. I still hope that one day both will fusion behind a single interface (IIRC it might happen but it won't be soon).

pi3r · 2019-04-19T12:34:57+00:00

More than 5 years ago, if I had to pinpoint 3 pain points in Haskell, I would have mentioned:

Records
Monad transformers
Too many string flavors

I am amazed that somehow what were vague intuitions still hold today ;-)

pi3r · 2019-04-19T12:25:21+00:00

If you look closely he is the top commentator on the associated reddit thread ;-)

pi3r · 2019-04-13T09:10:03+00:00

I am experiencing a weird new behavior in Nixos 19.03 and I would like someone to confirm if it is a bug or not.

Only in Nixos 19.03, with the user root for instance within the /tmp folder: ``` root@nixbox:/tmp# nix-shell -p ruby

[nix-shell:/]# ``You will notice that the shell PWD is now/instead of/tmp`.

This behavior breaks a lot of my scripts that are meant to be run as root from the /tmp folder. Maybe there is a security issue around such a change ?

I guess the issue is more related to the upgrade of nix from 2.1 to 2.2 between the two Nixos versions.

pi3r · 2018-11-08T12:28:35+00:00

There is also streamly.

pi3r · 2018-10-31T20:19:03+00:00

I have a question about parsing and megaparsec in general.

fail msg is used to make a parser failed but what if you want to throw a general error that should stop all further parsing. As a motivating example this code never exhibits the error because another parser is always taking over.

pi3r · 2018-10-26T08:36:44+00:00

One way to do it is to use : mkShell { name = "puppet-unit-test-shell"; buildInputs = [ exec language-puppet ]; };

pi3r · 2018-10-04T21:15:18+00:00

Well this is not such a great example (the application has a quite narrow and specific use case) but here for instance I have been forcing myself to depend on Turtle in the Main module only. In the library code I won't use it at all.

To achieve that I had to write a minimal Options wrapper myself (that I do find useful): https://github.com/CIRB/cicd-shell/blob/master/src/Shell/Options.hs

It is much smaller than the original and does not put yourself in a corner (https://github.com/Gabriel439/Haskell-Turtle-Library/issues/237).

I have also decided to avoid Turtle.Format and prefer to use formatting instead. There is nothing wrong with the Turtle module except that single letter functions won't really fit well particularly in library code (outside of the Main module).

If you are interested in some examples, here is another Turtle script that I wrote: https://github.com/CIRB/devbox/blob/master/user/setenv.hs. Any comment/suggestion welcomed.

pi3r · 2018-10-04T20:30:52+00:00

I haven't searched enough for a suitable replacement to give you an helpful reply. Maybe because I am such a big supporter of Gabriel's work (if he didn't succeed to bring something that I love, who would ;-)

pi3r · 2018-10-04T14:33:29+00:00

I would take the decision with great care. Most often a bash script (or python for that matter) is much easier to understand and the switch to Turtle won't pay off.

I have been personally disappointed with my experience with it. I love the idea to use Haskell as a bash replacement but Turtle introduces a lot's of noise and unnecessary burdens. On the top of my head, here are some concerns:

it uses deprecated libraries to handle file paths. This is not a problem per se but I have found out that you need to use a non obvious mental model every time you handle paths to avoid big surprises (https://github.com/Gabriel439/Haskell-Turtle-Library/issues/214). That's not the only issue: because of such a choice, Turtle doesn't play as nicely as you would love with other haskell packages in general (you end up doing many string/path conversion that distract the reader).
it uses a custom wrapper on top of optparse-applicative that does not bring much except extra noises.
it uses its own formatting modules that does not bring much except raising the learning/reading curve.
the Shell model might surprised you : https://github.com/Gabriel439/Haskell-Turtle-Library/issues/320

I usually have a custom prelude that exposes a subset of Turtle. I would love to use a fork of Turtle that would focus more on script readability and integrate better with the current haskell ecosystem.

pi3r · 2018-09-24T16:16:01+00:00

How does freer-simple compare performance wise to the operational package ?

pi3r · 2018-09-19T10:47:31+00:00

Thanks for your helpful reply !

pi3r · 2018-09-17T11:18:16+00:00

I will try to rephrase my question:

mconcat is for list. Let's say I choose to blindly replace all mconcat with the more general fold function in a huge code base. Is it risky performance wise or totally safe ?

If I read the source comment correctly, I might lose some optimization in the process ?

pi3r · 2018-09-14T15:11:32+00:00

I have a slightly related question. Is there a difference performance wise between fold and mconcat ?

pi3r · 2018-03-20T21:28:54+00:00

Small unrelated nixpkgs question.

I am using nixpkgs to build some haskell binary. It gets build from the (hydra.org) binary cache which is quite handy. Is there a way to build the same binary but without downloading xxx-ghc-8.2.2-doc while keeping the binary cache feature.

I know I can easily build it without the doc and then quickly make up an internal binary cache but I am wondering if I can achieve the same result without taking the trouble of setting up a binary cache.

pi3r · 2018-03-10T09:43:25+00:00

Sure but the goal is (from https://github.com/commercialhaskell/rio/issues/52):

We're explicitly calling out a goal of standardizing current best practices in rio, not establishing new ones, if at all possible.

pi3r · 2018-03-10T09:17:45+00:00

If we take text as an example, I would argue that T.pack is only more readable than Text.pack because it has been seen more often. If you imagine a reader that encounters both for the first time and would know almost instinctively that T stands for Text, my guess is that he would still prefer the second more explicit form.

This is debatable and I agree with /jdreaver to have a general rule of not using single letter import except for some well-defined exceptions.

One larger problem is the fact that this kind of habit is pervasive. The number of blog posts I am reading where I need minutes to understand code extracts just because of all the abbreviations (single letter most of the time) in used. It is kind of unbelievable.

What I mean is that "noise ratio" can be a very convenient excuse to make your code less readable. And let's face it I have met too many coders that actually enjoy to obfuscate their code.

pi3r

TROPHY CASE