seanparsons

If you think that's hard don't look at the types for any moderately complicated JavaScript project.

What? I've worked in a whole bunch of languages and I tend to find that Haskell is the easiest on this front. Hackage has all the definitions for packages cross linking to each other.

Types for checking things are correct is really important which is what this talks about.

For me though they really come into their own when those types then help to eliminate boilerplate. Haskell's foldMap function is my classic example of handling the accumulation of a result where it does the hard work based on the types. Idris goes even further by supporting the ability to infer obvious code for your code editor like handling each case in a sum type.

Because of the way iMessage is designed though, it just happens to benefit them by making any other platform look broken if you don't do these steps. They worked with the mobile companies to get visual voicemail support, why not for this?

How many regular users do neither of these things and just shove their old phone in a drawer or let their kid watch YouTube on it?

> Apple set up a page years ago that lets you manually disable iMessage to avoid this issue.

Exactly, why is a page needed in the first place? I'd bet more than 99% of users don't even have a clue that exists or even know about the underlying problem.

But the problem stems from their use of iMessage and Apple not doing an Android app.

Surely helping prop up iMessage is a terrible idea? Especially if it still has that "feature" where if you switch from an iPhone to an Android phone the messages aren't sent to your phone for a while?

Any company with a load of binaries built without any effort towards supporting cross platform builds that uses Docker is gonna have a bad day with this. They buy a bunch of new MacBooks and then find they can't use them until they spend a few weeks porting everything.

I've found it to be easy to work personally, if you want long names of functions in your code if it helps you should. Common libraries might not have long names for functions, but you'll find the same thing for the most part if you look at the API of collections in various languages for example.

Oddly now I find it really legible compared to other languages, you can still make things obtuse if you really want to, but the flow seems so much clearer.

I would say compared to Java (as you mentioned it) there's much less separation because things invariably gravitate towards big balls of mud containing lots of state. But in Haskell the function you're looking at is only tied to the functions and data types it uses, no more, no less.

OMG, they actually fixed the a + b + c... issue I assume in version 5 (5.1.1 is what I have available in NixOS).

The string concatenation issue was that if you do a ++ b ++ c... When that got to about 6 variables that single line alone took a minute to compile. Go to 10 variables and just give up on ever seeing a result. I used to try it in online Swift REPLs and it was still happening with whatever was most recent a bit over a year ago.

The exponential issue was still there in version 4 and I think 5 as well. Didn't say SourceKit crashed, but it was virtually useless because it functioned like a crap version of the language parser.

OK then:

- Slow compilation, I think even now immutably concatenating a handful of strings makes the compile time exponential.

- Over reliance on keywords and special case syntax, magic doesn't compose. A bunch of it just supports Optional for example.

- Xcode, nuff said.

- Equatable and Hashable for tuples were implemented with invisible compiler magic, so they wouldn't work with generics.

- Variance is hot garbage, it has variance, but no way to control it.

- No higher kinded types, so useful FP abstractions become a chore to implement.

- I regularly had compiler crashes on comparatively simple code.

- Sometimes absolute nonsense compile errors pointing at random parts of my code.

- SourceKit didn't handle basic stuff like type aliases.

Going on the various things I've seen since we switched our project to JavaScript from Swift it looks like the keyword soup has gotten worse.

Already handled in NixOS by Nix.

Not sure about daily signal failures, even when I commuted daily it wasn't near that bad. The idea of powering such a safety oriented system with JavaScript quite literally terrifies me, I'd expect it to be about 30 minutes before two trains collided.

Credit where credit is due, they did unicode "right", if you need to deal with those shenanigans it's really nice.

However it also adopts a bunch of the bad parts like having variance but not really having a way to handle it. Last I remember the Equatable instance for tuples was just magic, it was impossible to rely on it with the types. Even maybe 6 months ago when I last tried this if you write some code that appends maybe 6/7 arrays together immutably the compiler would go into an exponential spin.

The project I'm working on ending up dumping it entirely and moving over to being a web project written in TypeScript because it was so bad. Part of that being a laundry list of problems with the surrounding tooling like SourceKit which may or may not still apply.

Words I never thought I'd see attributed to Swift, it's a blend of a Scala like design with Objective-C parts.

In a dynamic language it's entirely likely you still have those types, but they're just not defined anywhere. You the developer have to validate them in your head.

It's worth bearing in mind that when writing something side effecting (reading and writing to a database for example) in Haskell, it will be done imperatively.

There's definitely a bias towards the familiar however, it took me a while to get my head around the "FP way" as it were. The frustrating thing is that like you say most people are just trained in procedural programming with often at most minimal contact with anything functional which causes a kind of pressure on the whole industry.

Would it make sense to make the code Literate Haskell?

We switched from watchman to entr on the project I'm currently working on because watchman was troublesome to configure and IIRC it completely detaches from the shell as well.

This is a more fundamental issue though, we(the software industry as a whole) need to throw off the shackles of languages like C.

Swift is probably one of the worst examples when it comes to functional programming because it's still a C like language with some FP like things in the stdlib. So you get none of the advantages and some inconsistencies weighing it down.

I don't remember any ad hominem attack, you appear to be inventing something. I was being flippant granted, but that's after the most frustrating year of my career, which is 90% Swift annoyances.

As someone who has been writing Swift for a year, I've definitely got some questions!

I'm not a fan of LISPs, but this is really cool, especially the inbuilt REPL!

Now if I could use Haskell in Unity3D then I'd get hella excited, but there's a lot more barriers there methinks.

I don't think I've ever seen anyone regard the compiler as tooling, SourceKit for sure that makes sense, but not the compiler. Especially in this case as there really is just the one compiler for it so those are issues that will hit anyone using Swift now. But if you want problems with the language itself, let me see:

It suffers from similar problems to Scala, where it tries to blend OO concepts in with FP concepts. Variance is where this flares up terribly because it doesn't provide any explicit support for covariance or contravariance. You end up with invariance and subtyping in a bunch of places which is not a nice combination.

Protocols like Equatable and Hashable are implemented with compiler magic for arrays and tuples. Which means that you run into trouble with generic functions that say accept two instances of the same type which is Equatable if you pass an array of ints. The underlying reasons behind this (which mostly escape me at midnight on a Sunday) are something to do with protocols on generic types. You can't say "for a List if the elements are Equatable the List is equatable" IIRC. This one annoys me no end as we've had to fudge our way around it several times on the same project.

For some reason that eludes me, Optional<T> is given all sorts of special case syntax ("if let" and "guard let") which is like a crap version of "for yield" from Scala or do notation in Haskell that only works on that. As a result a lot of convenient abstractions are just not possible you end up writing all kinds of horrid looking chained map/flatMap calls instead. Sometimes because of this dissonance between things a block of code might have a guard let block, then some other stuff, then an if let block with an else condition. Whereas if you wrote the same thing in Haskell it would be one do block and that's it.

Concurrency and parallelism support is effectively Grand Central Dispatch, which is the most imperative API ever on macOS/iOS and on other platforms (according to the Github page I just looked at for it) is in the early stages of development. You're just calling the old Objective-C API and the language doesn't help at all there.

Edit: As a bonus addition, it's a statically typed "FP" language which doesn't have higher kinded types which means a bunch of handy abstractions are a real pain. See the Swiftz project for how they have to define things like monads as an example.

Is that enough problems?

Other people have listed issues in here like compiler crashes from valid code, gotta spend time unwinding changes until it works and write the code differently.

Simple things like "a + b +...+ n" cause compile times to balloon exponentially, which means for arrays you end up refactoring concatenation of immutable arrays into a mutable array you call appendContentsOf on a bunch of times.

SourceKit on the surface sounds great, but in truth it's a simple text parser that doesn't understand type aliases for example.

The compiler _really_ struggles with anything beyond very simple generics, first the type inference starts to fail and then it'll refuse to compile until you break the code apart and add type ascriptions.

The compile errors are often absolute nonsense, pointing nowhere near the actual errors or are like the Magic 8-ball coming up "ask again later".

The project I'm working on has been a mix of Swift and JavaScript, we're happily increasing the ratio in favour of the latter because of all the pain we've had with Swift. I personally don't even like JavaScript but it's not even a contest between the two.

What on earth is this all about? Having spent a year working mostly in Swift I can't wait to see the back of it, even "billions" of dollars spent wouldn't turn it into a halfway decent programming language.

Well if you don't think a modern FP language needs higher kinded types you probably do need vodka.

Literally can't wait for this.