codygman

> but "notebook-style" exploration also sounds interesting.

It is, but if the process and tooling isn't really polished and responsive it feels really bad.

When everything is smooth though, it might be ideal. Jury still out on that one.

Also see this related discussion: https://www.reddit.com/r/programming/comments/ij0qzl/comment...

Also see this related discussion: https://www.reddit.com/r/programming/comments/ij0qzl/comment...

It was kind of more like coming up with organized snippets and notes while understanding a problem.

I'm expressing the wish that were I better at organizing them better that I could have tangled all of those snippets into a working (if ugly) source file and work from there.

Does that make sense?

I had a similar example today in the functional programming slack.

> hello, quick question: i feel like there's a more elegant way to express this, but I'm struggling to come up with one:

    foo :: (a -> Bool) -> (a -> Bool) -> a -> Bool
    foo f g x = f x && g x

For those who aren't as familiar with Haskell, that is taking a function f and a function g, passing argument x to both, and then doing a binary and on their boolean result.

One answer suggested:

> You can get fancy, but the “simple” version is almost always more readable:

    (not . null . f $ x) && (not . null . g $ x)

Which I find myself agreeing with in many ways, but for some reason leaves me desiring more.

The answer to that desire complements this article I think:

> if f and g returned Maybe you could have:

    > f _ = Nothing
    > g _ = Just ()
    > x = ()
    >  (f x) <*> (g x)
    Nothing
    > import Data.Maybe
    >  (f x) <*> (g x) & isJust
    False
    > -- or to avoid <*> you can do
    > liftA f g x
    Nothing

If that's not clear, let me know what's confusing and I'll try to explain further

> Ansible, as an example, would abstract away the CLI commands and be very readable in very few lines.

If it's just a few lines can you give an example?

I've done this before, but more directed at general software development as a sort of documented reproducible and resumable state. Ask me anything :)

I never got good at tangling my blocks together in the end though which is what I think would have made this method really powerful.

> Sometimes I get the feeling that no one focuses on shipping actual software with Haskell.

With just a modicum of effort you can easily disprove this feeling.

> Yes, but you don't like, need that to be, I dunno, a complete programmer or person.

Yeah? I'm not sure how meaningful this argument is here since you can just get by with nano and a terminal.

> Which is how the "cult" (tongue-in-cheek) treats it, and why this person has FOMO.

I frequent the places that the "cultists" would most likely be and the prevailing theme is "if your workflow works, keep it, but emacs could do X for you".

> There are tons of examples of programming wizards and productivity gurus who don't use emacs.

Yeah, but that doesn't mean Emacs wouldn't make them less or more productive.

I don't think I've seen the "you need emacs" strawman your arguing against in practice.

> And you'll encounter lots of people who can't get shit done but who fiddle endlessly with emacs or vi or whatever configs and believe they have some super efficient direct connection from their brain to their computer.

Would those people be more or less productive without emacs? I find answering questions like this for myself difficult, I can't imagine trying to decide others would be better off not using an editor.

Isn't saying lots of people exist that would be more productive without the kind of presumption that annoyed you from the Emacs cult?

> Some of the best, most productive programmers I know use notepad, and some of the worst use emacs. ymmv.

Right, which is why I commented what the other user was missing and not "you need this".

You can have a good text editor and semantically meaningful code manipulation.

Emacs has had structural editing for lisp how long?

Plus, it's nice to fallback to ctags or ripgrep if your lsp server dies

> Emacs was invented for a world where Text was everything.

Text still is mostly everything for all of my backend programming, note taking, etc.

> The other problem is speed of typing is irrelevant if you are working with libraries all the time, which is basically what most of the programming world does.

Typing speed is far from the most important part. It's the consistent interface for everything, reduction of cognitive load, and everything being available at your fingertips in emacs.

I use jf as escape in emacs/evil ;)

> > I am afraid I'm missing something. > You are not

You are missing an entire world treated as text and a consistent and an endlessly configurable interface for everything you can pull into your emacs Borg.

See this comment too: https://news.ycombinator.com/item?id=23673299

Note, many still use emacs for what the GP described and more.

The point is the level of configurability and that you can remove all sharp edges from within emacs.

Then when you sync your Emacs config to your laptop, those sharp edges remain gone.

Examples like this, especially those widely meaningful to everyone, are nearly impossible to craft.

It's like seeing different paths of movement before trying parkour and after training a few weeks.

> Last time lists like this were posted, most of the links were false accusations, or just someone claiming something, with no way to know the truth.

What last link posted consisted mostly of fakes? I must have missed it.

I recall refractors from those proposal being very mechanical and easy to automate.

Maybe my memory is fuzzy... But if not can you give an example where that wasn't the case?

> And at that point, all the power you get from saying things like there's only one possible implementation of a function f :: a -> a immediately go out of the window, because you don't have a value of type a, you have a value of type SomeConcreteTypeThatIKnowThingsAbout.

Not if your logic is primarily in terms of domain types, invariants encoded in those domain types as is necessary and economical.

> And at that point, all the power you get from saying things like there's only one possible implementation of a function f :: a -> a immediately go out of the window, because you don't have a value of type a, you have a value of type SomeConcreteTypeThatIKnowThingsAbout.

Can you give an example? I can only see this being the case if your logic is done at the concrete type level.

> This is a common counter-argument. It is a true statement. And, in the nicest possible way, it is also completely missing the point.

Yes, kind of.

> When you're playing with cute mathematical code and almost everything is written in terms of totally generic types, it's cute that you get free theorems and automatic derivations of some basic functions and all that stuff.

It's not only "cute" as you so reductively put it. There are real world benefits.

> However, in the real world, 99% of the time we work with concrete types to get concrete work done, and there are going to be many possible implementations of a function of type Int -> Int, or MyDataStructure -> MyDataStructure -> MyDataStructure, or SomeWrapper SomeType -> (SomeType -> SomeOtherType) -> (SomeType -> SomeOtherType) -> SomeWrapper SomeOtherType. This remains true notwithstanding the possibility that some of that cute generic code was used to implement various small parts of the function you actually care about if you dig down far enough.

That presumes an arguably wrong method of developing software that needlessly eschews understanding and correctness confused for superior economic choices, finally resulting in "real world programming".

I argue after the initial learning curve every Joe would find it easier to avoid bugs in Haskell.

https://www.simplehaskell.org/

Then if you use simple Haskell for a year and want more type safety, you can fearlessly refactor to get that.

> I am with you. Haskell is an brick wall of monads and other really hard words...

I understand the feeling, that's why it's very necessary to either find a very good teaching resource.

I'm currently reading "A Type of Programming" for fun and it kind of reminds me of "Why's poignant guide to Ruby in presentation (sadly sans artful illustrations)":

https://atypeofprogramming.com/ (do yourself a favor and at least click to read the well-written intro ;) )

The caveat (because there usually is one) being that it's 720 pages long. That's another tradeoff though.. you either get something that gets you all the way from point A to point B and it's very long or you get something very dense that requires lots of hammock time to derive the intuition yourself.

> I often wonder if Haskell is useful for anything

Also, I'll note that I write Haskell for my day job to combat your though of "wonder if Haskell is useful for anything".

> someone must be using it.

Yep :)

This gives you the ability to arbitrarily order via user defined list (the first argument) and then to order by some comparison function if for instance a new key were added (length in this example).

Given the example:

    {
      "baz": ...,
      "bar": ...,
      "foo": ...,
      "quux": ...,
    }

Then listing all of the keys in your desired order:

    comp :: Text -> Text -> Ordering
    comp = keyOrder ["foo","bar","baz","qux"] `mappend` comparing length

Note if you list all keys in the first argument of keyOrder it never goes to comparing length. There is probably a cleaner way to denote that this is the case but I can't be bothered to figure it out atm.

You can use this function:

    encodePretty' defConfig { confCompare = comp } YourType

And it will produce:

    {
      "foo": ...,
      "bar": ...,
      "baz": ...,
      "quux": ...,
    }

Can you give a sample of the javascript in the order necessary? This is from NPM? They have to use some comparison function to figure out how to sort their keys I'd imagine, so you could just copy that with Haskell.

> Functional programming is a style or pattern. If a language gives you basic stuff, you can do that pattern.

Kind of... correctness isn't as guaranteed though. Having a hard time putting it into words at the moment, maybe I just need some holes poked into it to draw out the rest of my view (or change it).

> - Haskell (pure FP, even HKT): good for fun but not for profit. Use Haskell for pure FP.

My day job disagrees Haskell isn't good for profit ;)

I agree about Haoyi's libraries, but you're mention of overhead reminds me of the overhead you run into trying to be purely functional in Scala.

If you're sold on benefits of purely functional programming, I think it's good to know (at least as of a few years ago) Scala makes that more painful than Haskell if you have even a little Haskell experience.

> I tried with haskell and gave up when I noticed I couldn't easily get json serialization to be in the same order as the javascript implementation and therefor couldn't verify nor sign messages with interoperability with the current clients.

This gets you most of the way there:

> With the Aeson library, the order of keys in objects is undefined due to objects being implemented as HashMaps. To allow user-specified key orders in the pretty-printed JSON, encodePretty' can be configured with a comparison function.

- https://hackage.haskell.org/package/aeson-pretty-0.8.7/docs/...

I'm not sure that messes with spacing or not though or you require specific space preserving requirements to interoperate with current clients.

Even if not you can probably look at the source of encodePretty' and work out how to not mess with spacing or keep it all on one line.

I've wanted a version of Aeson for a while that preserves order and all formatting for things like linters that are very unobtrusive. It seems your use case would have benefitted from that as well.

> In my experience, most harsh criticism comes from those who either barely used Go if at all or tried to build something Go wasn't aimed for.

How do you know the harsh critics of Go you read barely used Go at all? What things did harsh critics try to build with Go that it wasn't aimed for, and/or what is the most frequent wrong thing those critics try to build with Go?

>>> I follow a lot of prominent people in Rust ... I'm not sure these people are even building anything, they seem to be "snacking" on the language only. - Touche

>> This is obviously false. How do you square that with all the Rust code we've shipped in Firefox, for example? I build things in Rust every day. - pcwalton

> I didn't state that no one builds anything in Rust so I have no need to square it. - Touche

Touche!

You are technically correct I suppose. You didn't state no one builds anything, but arousing suspicion that "a lot" of prominent Rust people aren't building anything and are just "snacking" on the language is pretty pointed rhetoric with an obvious purpose.

You could start up a Programming Language tabloid with a headline like:

EXPOSED: PROMINENT RUST PROGRAMMERS CAN'T EVEN WRITE IN RUST!

And really that's all before analyzing the line of logic of "people tweeting only about interesting language features and not their personal projects, public work projects, or private work projects implies they might just not be building anything at all" which seems pretty flimsy at best.

> There was a thread on the Rust reddit where someone was asking how to do something relatively simple using some elaborate combination of map/reduce/filter/continuations/who-knows-what, and someone said "just use a for loop", and the OP was enlightened.

I think it's hard to discern between "that overly-complex functional and declarative definition is unfamiliar to me" and "that is way over-complicated and should just use a for loop".

Any chance you can track down that example so others can compare the two examples as well?

What is your useful definition of art that is useful in this discussion?

> Haskell is too academic

How so?

You know there has been a growing number of professional Haskell developers for the past 5-7 years right?