sullyj3

If in fact it is viable, then it's a good idea to work on it. Seems like a big "if". Regardless, it's a different argument to the nonsensical one gp was making.

How is it narcissism? It's pragmatism! A company isn't going to work on something that a minority of people care about out of the goodness of their heart. Why would you expect that of them?

The difference is that you can delete code with confidence that the compiler will tell you if you did something wrong, rather than things failing at runtime at some indeterminate point in the future.

It's short for "composite" recording. As in, mixing several takes together to form a single one with the best bits of all of them.

Strictly speaking you can already do this using multiple tracks, but having a dedicated workflow will make it much easier.

What specifically do you mean by fundamental? Not made out of other things?

- Built in LSP support

- Moving away from config and plugins in VimL, which is extremely idiosyncratic and awkward to use, towards lua and other languages via rpc

- Long term health of the project - neovim feels like a truly community driven project, whereas Vim seems bottlenecked by Bram and his specific desires. Neovim has also gone to great lengths to make the source easy to maintain long term.

- inccommand (https://neovim.io/doc/user/options.html#'inccommand')

- saner defaults

I'm not sure about the specific instance of vscode. Since it's a gui app, I don't think you can run it inside of wsl. You can use a plugin to connect to wsl, but I don't think that's quite the same thing, and I wouldn't expect it would allow clipboard sharing.

The general point is right though. This is an issue with any terminal program that either doesn't allow selection of text, or has a system for selection of text that's separate to that of the terminal emulator.

Yeah, I've been following that one for a while, I pre-ordered it. I was a little disappointed they switched from neovim back to vim. I'm sure the engineering reasons were sound, although I didn't understand them and it made me a little less excited about the project.

Not sure how to feel about the goal of vscode plugin compatibility. I'd hope for a vim based ide to kind of "be its own thing".

I've found it to be a colossal pain in the ass in WSL, since the emulated linux clipboard isn't synced with the windows clipboard. I have to :wq, cat the file, and ctrl-ins to copy.

I'm still holding out for proper IDEs with embedded neovim at the core. Vim has a few killer apps I can't live without - custom text objects, vim-surround, and vim-sneak.

Unison's ability system (an implementation of algebraic effects) is looking promising as an ergonomic method of tracking effects.

It's worth noting that Haskell allows mutable variables in IO actions - a type used to model computations that are not referentially transparent. It's just that using this facility is not super ergonomic.

Sometimes people infer things that aren't strictly speaking logically implied. That doesn't make it not misleading, if it reliably causes people to make those inferences.

I can't even sort my artists in alphabetical order on the webapp. It's a total embarrassment.

Haskell is very free, and very suitable for complex systems!

It's interesting that this line of argument perhaps leads to the conclusion "keep libraries small, to allow more granular selection of dependencies".

But this is the kind of reasoning that leads to the situation in npm of thousands of tiny libraries such as "leftpad" that many systems programmers are so derisive of.

Should probably note that

  class Convert a b

requires MultiParamTypeclasses

The point about let exressions is excellent, and I definitely relate to the author. I think they're underemphasized in FP evangelism to people used to the imperative paradigm - "look, this is pretty similar to how it'd look in python if you were disciplined about not reusing names."

Given that I don't have a degree in hyperbolic topology, that would definitely put a damper on my appreciation for the language, yep haha. I'd probably consider myself to be on the lower side of average intelligence for programmers, and I like it a lot. Granted, I haven't gotten around to writing a working web app in it yet.

I mean, at a certain point you're asking for ultimate power over everything and instead of attempting to become autonomous you find yourself attempting to become a supervillain

I'm not entirely sure what you're getting at here. Are you saying the author is arguing a call like

  new Customer()

should return something valid? I think the FP way would be to disallow constructor overloads with no arguments, as really, there's no reasonable thing to be done here. If you don't have all the necessary information to initialize a customer yet, you don't get to initialize one, and you pass around a partially applied constructor function instead.

ie, The argument is that (in pseudocode):

  Customer(name = "Jimmy", address = null)

is not really a customer if address is a necessary piece of information, so we should distinguish at the type level by passing around a function that takes the address and returns the correctly initialized Customer like so

  \addr -> Customer(name = "Jimmy", address = addr)

Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored.

Previous discussion (2015): https://news.ycombinator.com/item?id=8998117

I like how this could be taken as an endorsement or criticism of the article, depending on the hubris of the reader

Good point! last time I used elm i didn't know what a nonempty list was.

In practice I've found that it leads to writing code that you know is unreachable, but you can't prove it to the compiler.

Definitely don't disagree!

Combination of somewhat high barrier to entry (they're unlike most other languages so experience isn't as transferable), and network effects - those in charge of choosing a technology for a project generally make the subjectively prudent decision to use technology that is already in common use, leaving the less common languages in a catch 22.

The general consensus in the community afaik, is that

  head :: [a] -> a

in Prelude was a mistake, and the default should be to return a Maybe/Optional. Beginners are generally advised to avoid head, and all other partial functions in the Prelude, such as tail and the indexing operator, wherever possible, and rely on pattern matching instead, which is generally sufficient and more idiomatic for the relevant use cases. I agree that having the option to use a partial function is useful, escape hatches are important, but it shouldn't be the go to.

Nonempty was just a simple example. You're right that it's not very commonly used (probably because it's not in Prelude), but the general culture of writing type safe interfaces and pushing guarantees to compile time %100 is a thing. A commonly used, more complicated example might be Servant, which is a web library which statically ensures your implementation meets an API spec.

In Haskell, it's both common and idiomatic. There's always a tradeoff between the usefulness of having static guarantees, and the complexity of the type system features that enable those guarantees. In some cases it's more trouble than it's worth to enforce certain static properties - you have to weigh the costs and benefits on a case by case basis. But it's nice to have the option, and Haskellers make use of it frequently.