millimeterman

Let's be real - Successor ML is never happening. I just don't think there's enough interest.

Just some examples:

- First-class modules don't feel very first class, with how clunky it is to use modules at the value level

- Records are very clunky and hacky to use

- Generative functors are a hack

- Special language-level equality magic is awful (although SML also has this problem)

- Special `let` forms (whether via ppx or integrated into the language) feel really hacky

- GADTs require too much handholding of the typechecker

- All the "Objective" parts have very few redeeming qualities and should probably never have existed

- The way infix operators work is really half-assed

I don't think OCaml is a _bad_ language - it's very practically useful. It's just not simple or elegant.

Here is a StackExchange post: https://math.stackexchange.com/questions/2453533/triple-nega...

Oops, good catch.

A simple diagonalization argument is perfectly constructive.

I'm not familiar with this specific proof, but reading the description it sounds perfectly constructive.

A true proof by contradiction would be "Assume [0, 1] is not uncountable. That leads to a contradiction, so [0, 1] is not not uncountable. By the law of the excluded middle, [0, 1] is therefore uncountable."

This proof seems to be "Assume [0, 1] is countable. That leads to a contradiction, so [0, 1] is not countable." That's not a proof by contradiction - it's just how you prove a negative.

This is a nice blog post about the distinction: https://existentialtype.wordpress.com/2017/03/04/a-proof-by-...

I don't know if I'd call OCaml dead simple. It's full of inconsistencies and bolted-on features that are practically useful but definitely not simple or elegantly designed. It's kind of like the C++ of ML derivatives in that sense.

I'd say Standard ML better fits the bill of "dead simple". The only issue is that tooling and learning resources are nearly nonexistent.

Not at all - that kind of dataflow analysis is basically just a hack to patch over the fundamentally broken design of having everything be nullable. It's totally unnecessary in a language with proper algebraic data types where there's no all-pervasive concept of "nullability". The only imperative language I know of that has this is Rust, but it originates from ML languages like OCaml and Haskell.

It's one of those features where once you get used to it, it's hard to fathom how anyone programs without it. It's such a simple yet expressive feature that's incredibly useful when writing normal, ordinary code. Nothing fancy or theoretical.

I don't know anything about mercurial's internal data model, so it's hard to say. In particular, it makes some fundamentally different choices (e.g. no staging area, the ability to use unnamed branches). I certainly think git could do a lot better with its interface though.

Strong disagree. Software quality is driven almost entirely by either insane dedication from hobbyists or (more commonly) monetary incentives. Lots of businesses depend on Postgres so it's good. Github makes money off of providing a good product. Wacom has a total stranglehold on the market so they don't care because they know artists will put up with it.

I mean, modern websites do a lot more than display documents. They're certainly bloated, but they increasingly need to "do everything." Normal people do so much of their computer usage in the browser that it could probably _be_ the operating system and most people wouldn't lose any functionality (see: ChromeOS).

I mean, that problem is hardly common and Windows is definitely full of similar bugs. And I'm not sure it's possible to make web browsers much simpler without losing functionality - the websites they have to support necessitate the complexity.

Inbox may have been a good concept but the actual software was horrible. The site took ages to load and was painfully slow.

Not OP, but I prefer the paradigm of phabricator diffs over GitHub PRs. It papers over git's inability to have unnamed branches and makes stacked diffs much easier. It also makes it easier to do "no branches, everything is on master" development, which I feel is superior whenever it's possible.

I disagree about Chrome. It's absolutely not perfect, but considering its sheer complexity - browsers are probably comparable to an operating system at this point - bugs are fairly rare and performance is quite good.

I think the best argument against git is to use mercurial for a few months. It has exactly the same functionality but a nicer and more streamlined interface, especially when it comes to branch management.

Emacs is just the VSCode of yesteryear - there's a reason people used to joke about "emacs" standing for "emacs makes a computer slow".

While Homebrew is absolutely slow, the experience of package management on macOS (homebrew gets you bleeding-edge versions of the crap you install, whereas Apple manages the system and keeps it stable) is IMO better than Linux where the choice of stable vs. bleeding-edge is systemwide.

I use SteerMouse. It lets you customize mouse speed/acceleration, remap all your buttons, and set up mouse chords.

It's admittedly paid and it's stupid that you should need to pay for functionality like this, but it's useful enough for other stuff (e.g. setting up buttons/chords to manage spaces to replace the trackpad gestures) that I live with it.

> I can buy a USD1k+ device and still not be able to install on it the apps I want because the manufacturer doesn't want me to

Yes. Good.

Sure it might benefit you and me, but Apple is designing their devices for normal people. Normal people don't care and likely benefit from the quality control of everything going through the curated App Store.

I agree that this kind of behavior sucks for you and me but we are a tiny niche audience. It's unreasonable to expect our needs to be catered to over the majority.

The fact that this is unpopular convinces me that most HN posters don't work on real commercial products. Or if they do, then I don't care to use the products they develop.

Counterpoint: OSS usually lacks polish and only works well if your workflow is sufficiently similar to the developers' workflow. Linux is great if all you're doing is developing software with popular tools/languages, but if you want to use your computer like a normal person for a change, it's pretty bad. I've consistently had issues with basic functionality like HiDPI scaling, trackpad and wifi drivers, power management, and just general polish. That's not to say that Windows and macOS are amazing and perfect - they aren't. But they're a whole lot better than Linux for normal use.

You say this as if Atom is some sort of widely used standard. Atom and VSCode are just two players in a wide ecosystem of editors and IDEs, most of which Microsoft has no control over. And I'd bet that most people using other tools (e.g. Visual Studio, JetBrains IDEs, Vim, Emacs) have very little inclination to switch to Atom or VSCode.

While true, this isn't a free get out of jail card whenever someone brings up slow compilation. OCaml's compiler is blazing fast.

> Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor.

Strong disagree. Even in small hobby projects it's slow, has limited functionality, and needs frequent restarts to function properly.

IMO stuff like <$> and >>= are fine. They're part of the standard library and are very widely used so you just learn them once. The real problem is when random libraries invent so many symbolic operators that they become their own little incomprehensible DSLs (looking at you, lens).

Haskell certainly has a _better_ parallelism story than OCaml but I wouldn't call it great. It's really nothing special.

We'll have to wait and see how finished coroutines implementations perform, but I'm leery of the fact that sidestepping heap allocation relies on compiler optimizations. Optimizers can be fickle and in a language like C++/Rust, I like being 100% sure that the abstractions are zero-overhead.

I'd actually point the finger at Java itself, though I imagine the editor didn't help. Java's type system is (IMO) about as cumbersome and unhelpful as they come. A good type system should be minimally obtrusive while preventing lots of programming errors (both when writing code and, perhaps more importantly, during maintenance by a different person a year down the line).

For languages with good type systems, I'd recommend something like OCaml (or maybe F# - I know it's very similar and probably has a better ecosystem but I haven't personally used it).

Elm also seems decent - it's designed to be pretty simple and has JS interop but it doesn't have good tooling. Typescript is an alternative that has an okay type system but pretty quality tooling.

I'd recommend staying away from Haskell even though it's commonly recommended. The type system is quite complex and its use of monadic I/O makes writing "real" programs, even toy ones, difficult for many people. If you want to learn Haskell, I'd say start with OCaml/F#/Elm. Those are all very similar and will let you learn the fundamentals of ML-style programming before diving into Haskell-specific details.

Counterpoint: the vast, vast majority of users never do any of that. I’m sure Google collects tons of analytics on how people use Chrome and the current design is tailored to fit the needs of the majority. Common functions like tabs, the address bar, and maybe bookmarks are front and center while everything is shoved into menus to declutter the top-level UI.