Haskell type classes are not classes (like Java or PHP classes); they are comparable to Rust traits -- which are different from PHP traits which are comparable to Java/C# interfaces (with default impls; if you just want contracts you have... PHP interfaces).
A fundamental difference is that you can instantiate/implement a type class (or Rust trait) for any* type, compared to interfaces where each class declares the interfaces it implements. You can therefore create generic (forall) instances, higher kinded type classes, etc.
> Actually in modern Java you can simulate type classes approach with a mix of interfaces and default methods implementations.
Can you? The beauty of traits/type classes is that you can attach them to any type - in a world where 90% of the functionality of any piece of software is supplied by dependencies - external types which you cannot change - this is a vital feature.
Failing that, there are always Clojure, Kotlin and Scala on the JVM, which expose language features to achieve the same, which you naturally can mix and match with plain old Java.
Why the reference to “modern Java” then? Writing adaptor classes is not “modern Java” nor does it involve using “a mix of interfaces and default methods implementations”.
I was responding to your original claim and I’m well aware of such facilities in both Kotlin and Scala - having used both extensively. I was genuinely curious if the latest Java was in the process of adding support for trait/typeclasses - so I don’t understand why you’d bother to reply with something that completely changes your original claim.
Microsoft started as a programming language company (MS-BASIC) and they never stopped delivering serious quality software there. VB (classic), for all its flaws, was an amazing RAD dev product. .NET, especially since the move to open-source, is a great platform to work with. C# and TS are very well-designed languages.
Though they still haven't managed to produce a UI toolkit that is both reliable, fast, and easy to use.
Off-topic, but this ongoing trend of brands getting TLDs is really starting to infuriate me. It's not what TLDs are for! Sony is a Japanese company, so it should use sony.com or sony.jp.
There's no inherent reason to restrict the number of TLDs. The best way to combat rent seeking from registries is to allow any organization that has the technical capability to operate a registry.
Why do companies and organizations get special treatment over regular people? I think a simpler fix is just to ban any companies that register domains from squatting on them.
The bigger problem is the rent seeking some registrars are doing now by increasing prices. Not sure what domain portability might look like (maybe requiring multiple registrars per tld), but something like it would solve this problem.
EDIT: I couldn’t have been more wrong — all three have TLDs. Not really sure if they are being used for much though! Most of the action still seems to be on their .com domains
The standard divisibility rule for 3, 6 and 9 in base 10 is to sum the digits until you only have one left and check if it's one of those. Here, 5+7=12, 1+2=3, so 57 is divisible by 3.
Math is not my strong suit at all, so I probably won't grok this, but that kind of blows my mind, so I'm curious... how?! That works for any arbitrarily large number?
Math is crazy!... still don't want to study it though!
When checking whether it is a multiple of some k, you can add/subtract multiples of k without changing the result, and those 99...9 are multiples of both 3 and 9.
It is basically because $10 mod 3 == 1$ (as 10 = 3*3 + 1). So if you are in the ring modulo 3, where every number is equal to the remainder of its division by 3, the sum of the digits of the number in its decimal representation equals the number itself (modulo 3), because in that ring 10 is actually 1, so the 10s in the decimal sum become 1s. Ie if n_k is the kth digit of n, you have
Hence, n is divisible by 3 iff $n mod 3 == 0$ iff $(n_0 + n_1 + n_2 + ...) mod 3 == 0$.
Of course, summing up the digits may not give you a 1-digit number, but it gives you a number that you know is divisible by 3 (if the original number is divisible by 3). So you can apply the same idea/process again, summing up the digits of that number, and get another number that is divisible by 3. Repeat until you end up with one digit (hence the recursion mentioned).
However, Rust does automatically provide a niche if you make a simple enumeration which doesn't occupy all bit patterns and we don't need compiler-only features, or even unstable Rust, this Just Works™.
If you have a USHoliday enum, with values like Juneteenth the fact is there's not that many US national holidays, so both USHoliday and Option<USHoliday> will be the same size, one byte with no extra work.
I think "blurry" was used here referring to the fact that they don't really pay attention to the differences between fonts, not to an aspect of the rendering.
It was kind of a double-meaning. Non-bitmap fonts really are blurry, comparatively. AFAICT the non-bitmap fonts just hide this thanks to people using HiDPI displays now, which is basically like saying "well, it looks fine from far away".
reply