Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
willtim
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
31.
▲
by
willtim
5y ago
I've used Linux since it was first available in the mid 90s. I use it at work and on machines at home. It is almost certainly more reliable than Windows and MacOS as a server. However, the context here is desktop UI and laptops. Linux
32.
▲
by
willtim
5y ago
That's really good to hear. Perhaps I need to stop using fringe distros like NixOS.
33.
▲
by
willtim
5y ago
Hmmm so much for "just works". Macos is becoming as buggy as the average Linux distro. They need to take a pause with adding features and clean it up.
34.
▲
by
willtim
5y ago
I always thought Dart/Flutter was a hedge against Oracle shutting down Java-usage on Android. Now that they have Kotlin (which devs generally much prefer over the Java-facsimile Dart) and Jetpack, I'm not sure either what relevanc
35.
▲
by
willtim
5y ago
In my opinion, as a professional haskell developer, it is too hard to reason about the runtime space usage of Haskell programs to ever recommend Haskell as a "systems programming language". Haskell would be great for writing a DSL
36.
▲
by
willtim
5y ago
This is a noble effort and you can certainly take the moral high-ground over companies like Apple. However, often the problem is not only whether parts are replaceable but also availability of spares. For example, my 2016 X1 Carbon needs a
37.
▲
by
willtim
5y ago
They ditched their own inferior custom core design and now use ARM Cortex X1.
38.
▲
by
willtim
5y ago
Side-effects do not mix with lazy on-demand streams! This is unfortunately a problem with bringing functional programming constructs to a language with idiomatic pervasive mutation.
39.
▲
by
willtim
5y ago
> then complain about types instead of talking about static analysis Static types are a form of static analysis. One that is deeply integrated into the language and compiler, which gives obvious advantages such as machine-checked docum
40.
▲
by
willtim
5y ago
I suspect they wrote thousands of lines of code "Agile" style, without nearly enough upfront design. Now there is too much code to rewrite and it's too hard to change. I would be more sympathetic if it just lacked functionali
41.
▲
by
willtim
5y ago
This is of course why garbage collected languages exist. If you don't need the performance or efficiency gained from having full control of memory, then GC'd languages will offer less cognitive load. IMHO, programming in Rust is n
42.
▲
by
willtim
5y ago
Unfortunately Rust is currently lacking structural records/structs and enums. I think they removed them early on in the design. So you'd have to name the all the types. I hope they do add them back one day.
43.
▲
by
willtim
5y ago
It's better to evaluate at compile time, if possible, rather than runtime. The biggest issue with macros is code bloat, but every serious general purpose language should have them.
44.
▲
by
willtim
5y ago
> Imagine the function "fn bar(x: fn(x: int) -> string)", would that be more clear with a colon? In your example, why bother naming the inner "x" variable for the function param? It cannot be used on the right-hand
45.
▲
by
willtim
5y ago
That's a nice explanation of what's going on. My point remains that I found the syntax confusing though.
46.
▲
by
willtim
5y ago
You are quoting me out of context. In many languages, the term and/or pattern foo(x : int) is a string, if foo : int -> string.
47.
▲
by
willtim
5y ago
Yes and of course Haskell is quite capable of supporting uncurried functions too, e.g. foo :: (Int, Int) -> Int foo (x, y) = ...
48.
▲
by
willtim
5y ago
It did confuse me when I first saw it, but yes, it is not really a significant issue.
49.
▲
by
willtim
5y ago
Well the Python community is hardly an authoritative figure on static typing :)
50.
▲
by
willtim
5y ago
> That would imply that "foo(x: int)" is a string rather than a function But foo(x : int) is a string! It literally reads "foo applied to x". In the function definition, it appears to be used as a left-hand-side pat
51.
▲
by
willtim
5y ago
In Rust, a function definition left-hand-side looks like an annotated pattern, e.g. foo(x : int) Therefore, one would expect to annotate the return type as, foo(x : int) : string Since the pattern is showing foo applied to x. The Rust synta
52.
▲
by
willtim
5y ago
Rust maybe a little adhoc in places (e.g. the misappropriated Haskell/ML function syntax, enum/struct asymmetry), but overall it is a fantastic effort. It is not an easy task to combine an advanced static type-system with mainstre
53.
▲
by
willtim
5y ago
App makers complain about Apple's dominance, yet seem to put significantly more effort into iOS apps than Android apps.
54.
▲
by
willtim
5y ago
It can be difficult to avoid the culture/practices though. Every dependency you use, is code that you are ultimately responsible for. At a minimum you will need to learn how to use them; and you may need to debug and fix them. This is
55.
▲
by
willtim
5y ago
Google for "Enterprise FizzBuzz". And that one doesn't even use Spring. Yes it's a joke, but quite illustrative of why many dislike the Java culture and its ecosystem.
56.
▲
by
willtim
5y ago
So true! I once told my kids about the beautiful car-free bicycle cities, they replied something like "wow, I wish we could live there".
57.
▲
by
willtim
5y ago
> Monads are not the same thing as effect types Monads can be used to implement "effect types" and define the semantics of them. I believe this is how Koka works. > Talking about Haskell monads just does not seem all that re
58.
▲
by
willtim
5y ago
> I quite like it and don't see any particular problem or traps with it. While Go's model is certainly a valid point in the design space and keeps things nice and simple, there are of course going to be many trade-offs. For ex
59.
▲
by
willtim
5y ago
The problem is more that Rust cannot (currently) abstract over these different function types; and that they are more limited (e.g. no async methods in traits). But the idea of effects tracking is a good thing and we are bound to see more o
60.
▲
by
willtim
5y ago
And why restrict oneself to just two colours? Haskell monads also allow one to abstract over the "colour", such that one can write polymorphic code that works for any colour, which I think was the main objection from the original
More ›