21–30 of 128 posts
I'm confused as to why this piece was written using LaTeX.
Earlier quoted context omitted.
Why? The LaTeX required to produce a PDF like that is no more complicated than your favorite format.
Compared to Markdown, LaTeX is extremly complex, in fact, isn't LaTeX is turning complete.
Earlier quoted context omitted.
> the more I've grown to appreciate the concept of Optionals You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs. Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenev…
One of the things that makes Optional so pleasant in Swift is the syntax support. This includes optional-chaining, if-let and guard-let unwrapping, and some convenient operators. For example, in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. But in Swift this works like you would want. All that is to say that Options in Swift are a bit nicer than what you could get wit…
Haskell has bind (>>=) and do-syntax, rust has `and_then`. This is pretty standard with any ADT-supporting language.
> if-let
Most languages with ADT support have good pattern matching that subsumes if-let syntax and allows you to do other things as well. Swift's pattern matching, such as it is, is a bit of a mess.
> guard-let unwrapping
Haskell has `guard` and `MonadFail`, which address the use cases for this in a more principled way. `guard` for boolean matching (like equality) and `MonadFail` for structural matching (like pattern matching on a constructor).
Rust has (?) and `try`, which are syntactic sugar around a simple match/return statement that addresses most use cases of guard-let.
Obviously there are going to be small differences between this implementations, but Swift doesn't really excel here.
> `5 == Just 5` fails.
As it probably should. Supporting such implicit casting could lead to some obvious confusion and buggy behavior. Ideally, the fact that "a == b" typechecks should indicate that "a" and "b" are of the same type.
In Haskell, you would just do `Just 5 == x` if you want to check that something is, in fact, `Just 5`. If that really wasted a lot of space somehow, you can define something like `x ==: y = Just x == y`.
Swift: better OO, syntax, IDE; Go: built-in concurrency; Swift is a great joy for iOS development, where compatibility with Objective C makes things smooth, and operation queues are good enough for concurrency. Xcode is a big productivity booster. Good to break Swift's own backward compatibility with new releases to keep innovation, while providing a quick fix tool. Hope it will become a great server language too.
Everything you saîd about swift is correct for small sized projects. The story becomes much much different once you work on a piece of code for a few months with a team. Then xcode crashes, swift builds slowly ( in minutes), you start to be crippled because of the compiler and tool. I hate to say it, but It's not production ready yet, at least not for a big project.
There's some tools you can use to diagnose build times, often slow builds are just a line or two that seem to mess with the compiler and can easily be broken apart or written in a different way.
Also, have you tried the Android emulator/Android studio? Last time I did it made me appreciate Xcode and the Apple dev ecosystem a whole lot more.
Earlier quoted context omitted.
> the more I've grown to appreciate the concept of Optionals You may also enjoy a language that supports the generalization of Optionals, which are Algebraic Data Types (ADTs). Optionals are a single, limited application of ADTs. Optionals allow you to shift null pointers (and null pointer exceptions) to the type level. So instead of having to worry about a function returning null, you just deal with Optionals whenev…
Swift supports ADTs and implements its Optional type as an ADT.
True, but perhaps not practically relevant. The pattern matching in Swift isn't much better than what you would get with a tagged C union, which is why no one really uses it very heavily. The Optional type in Swift gets a lot of special compiler support, which is indicative of the fact that the broader language isn't very friendly towards using ADTs to structure data.
But you're right, I should have clarified in my comment that Swift does have a basic degree of support for ADTs.
Very basic comparison. Doesn't go into the quality of the generated code, compiler speed or efficiency, etc.
I'm confused as to why this piece was written using LaTeX.
Earlier quoted context omitted.
One of the things that makes Optional so pleasant in Swift is the syntax support. This includes optional-chaining, if-let and guard-let unwrapping, and some convenient operators. For example, in Haskell, by default you can't compare an Optional with the value it wraps: `5 == Just 5` fails. But in Swift this works like you would want. All that is to say that Options in Swift are a bit nicer than what you could get wit…
> This includes optional-chaining, Haskell has bind (>>=) and do-syntax, rust has `and_then`. This is pretty standard with any ADT-supporting language. > if-let Most languages with ADT support have good pattern matching that subsumes if-let syntax and allows you to do other things as well. Swift's pattern matching, such as it is, is a bit of a mess. > guard-let unwrapping Haskell has `guard` and `MonadFail`, which ad…
edit: FWIW, there's some overlap between '?' and 'guard let', but not that much. Using hypothetical Rust syntax, they'd overlap in this case:
guard let Some(x) = foo else {
return Err(GettingFoo);
}
let x = foo.ok_or(GettingFoo)?;
No mention of functional programming and the idiomatic async calls using closures made popular as of late by JS?