codygman

So that the AI model that generated code can get proper credit and we'll know to use (or not use it) next time.

I'll consider avoiding jj because of this, personally.

No, you need to use -nw with emacs to make it apples to apples. Then it's emacs 0m0.095s vs nvim 0m0.057s:

    $ time nvim -es --cmd 'vim.cmd("q")'

    real 0m0.057s
    user 0m0.016s
    sys 0m0.017s

    $ time emacs -Q -e kill-emacs

    real 0m0.230s
    user 0m0.165s
    sys 0m0.064s

    $ time emacs -nw -Q -e kill-emacs

    real 0m0.095s
    user 0m0.057s
     sys 0m0.017s

I use an emacs based system with org-mode, org-habits, and howm.

I think they are saying you sound like:

"It's One Banana, Michael. What Could It Cost, $10?" - Lucille Bluth

Location: Dallas, TX

Remote: Yes

Willing to relocate: No

Technologies: Haskell, Rust, Nix, Golang, Python, Linux, Mentoring, Javascript/HTML5, SQL, NoSQL, REST APIs, Django, Terraform, Docker, PostgreSQL

Résumé/CV: https://www.linkedin.com/in/codygman/

Email: cody@codygman.dev

Over 15 years I've worked both in large corporations in cross-functional teams, small teams (5-10) at small to medium companies, and alone as a freelancer taking on projects across many different technologies. My focus in the past few years has been on being a force multiplier for my team and increasing predictability, stability, and developer enjoyment of output. I'm also a big proponent of mentoring and frequently create tech talks from the daily work notes I take so that the lessons from any challenges I face benefit not only me, but my team as well.

My preference is functional languages and companies that use Nix and/or NixOS, but it's more important to have a healthy company and team than any specific technology.

I also do Parkour in my free time, and I have given lessons to coworkers in the past who are interested :)

A great video introduction to magit: https://youtube.com/watch?v=_zfvQkJsYwI

Do. Not. Break. Workflows. Software that doesn't understand this principle is something I don't trust not to break itself when its developers decide to get cute.

What use would magit be if it presented the exact same interface as `git rebase`?

Do you know what it would lose?

Did I stop and read the docs to figure out how it wanted me to rebase in this brave new world? Hell no.

I suppose you don't since you didn't read the docs.

Why try it in the first place if you expected it to be the exact same?

Forced error handling semantics so that unhappy paths are easily enumerated

They could have just added pattern matching and exhaustivity checking though, right?

https://marketplace.visualstudio.com/items?itemName=arrteria...

they're case classes then you're moving around a lot of unnecessary data fields and you've got the overhead of making fifty intermediate case classes yourself.

Haskell developer here... What about case classes and lenses? Do they solve this?

When I think Haskell, enterprise maintainability coding isn't exactly what comes to mind.

One day hopefully

Is Go fundamentally type-unsafe?

Interface{} and nil pointers point to yes.

All the magic will make them feel confused and powerless when they do anything outside of the blessed path.

Maybe, but what are the chances they chalk it up to a normal and acceptable learning path?

They can't extrapolate that forM_ works for any monad in the future.

I think it's important people know that, but how much does it matter for IHP's intended audience?

Agreed, I wish we all used |> instead of &, but that operator is called & in Haskell. You're crippling your users' ability to read other code-bases in the future

I think this is an important point, but I'm not sure how much it would matter for most.

And that same code would be plenty readable with &, don't you agree?

Most would assume & means something with boolean and I bet. I find & readable, but even Haskellers on my team didn't really seem to take to it.

There's so much more to "building" than the first month of development!

People don't really value the long term but default I've found. Then once they have committed to something to a degree, they don't change from it.

If IHP makes it easy enough to get to the point of feeling like one should keep using it rather than starting over...

Maybe the extra learning challenge will feel "normal", worth it, and otherwise motivated.

Haskell is an order of magnitude more productive for me than other languages (ruby), because of its differences.

I can relate to this, but coming from Python. Others who aren't sold on Haskell by it's usually toured virtues are probably likely to be sold by getting someone spun up to hack away on more quickly.

I find making a lot of these arguments kind of funny since I typically find myself arguing from your position :)

There are keyboards for people who want a truly ergonomic input system and there are keyboards for fanboys

Kinesis advantage 2 is for the first kind and ergodox is for the fanboys

Maybe it's true, but I bought the Moonlander (same brand as ergodox) for ergonomic reasons. It allowed my hands to be more in line with my shoulders and reduced shoulder pain/tightness I would have at the end of the day.

I want to try the Kinesis advantage, but one thing stopping me is the fact that it's not a split keyboard. I think it's likely my natural arm position is wider than the Kinesis.

The most efficient tools are usually the most ugly and boring ones

I think there's some truth to this, but speaking it as such an absolute truth seems misguided.

I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time.

Just as an anecdote, if you are persistent enough you can learn Haskell and get a job writing it :)

If you have the option between creating a function which accepts a string (e.g. ID) as argument or accepts an instance of type SomeType, it's better to pass a string because simple types such as strings are pass-by-value so it protects your code from unpredictable mutations

What if you work in a language where SomeType is pass-by-value?

Would you still prefer the string?

If you say Java is optimized for developer happiness, or worse, Haskell, I'll pass on this cheap trolling attempt.

Haskell with stack is a pretty happy place for professional software development in my experience.

extended remote work may not be all it’s cracked up to be, at least for some job functions. While pre-pandemic studies found remote workers were just as efficient as those in offices, there were questions about how employees would perform under compulsory lockdowns.

Or maybe ya know... A pandemic has its own negative effect on productivity.

I have written Haskell code and Haskell does not solve any real problem. Same goes for F# so no one uses

You are being down-voted for either lying or using such a ridiculous definition of "no one" to push your agenda while disregarding facts.

Do you have any code examples of array languages being used for general purpose tasks? Clis, web applications, anything with lots of branching, games, etc?

GitHub semantic powers goto definition in GitHub IIRC. Here's why they use Haskell:

https://github.com/github/semantic/blob/master/docs/why-hask...

Have you used other languages here? Can you give a code example where Go shines here?

Can you give an example of something you have to do all the time in Python that's a lot nicer in R?

Related, xwidget browser in emacs with keyboard navigation, etc:

https://github.com/BlueFlo0d/xwwp/tree/xwwp-ace-dev

Do you have any personal favorite examples? Maybe a recent from your history?

Have you written parsers in any other languages? Can you contrast?

Also note that if you try thinking with types, you may start seeing them as tools rather than overhead.

A good blog post about this is:

https://lexi-lambda.github.io/blog/2020/08/13/types-as-axiom...

In my humble opinion, those two things are equal in difficulty and consequences.

I'm not so sure, I'll give this idea some thought though.

I had almost the same number of bugs in my ML application that I would have in the imperative program, but they manifested in different ways.

Can you talk about some of the different ways the same bug manifested?

Do you really never need to see what a passed-in function actually does in your FP code?

I'm hesitant to say always, but I can say:

- in imperative code I never feel comfortable without inspecting the passed in function

- in pure functional code, I rarely feel uncomfortable taking a pure function at it's word