grumpyprole

I remember running into this quite often. Apps would fail to draw completely and malfunction.

One months salary is still an awful lot for something that no middle class family ever needed. If the goal is educational and/or recreational (games), then a 6502 machine could be had at a fraction of the cost and with a community. In the UK, the Macintosh basically didn't exist as far as I remember, my first 68000 machine was an Atari ST in 1986/7, still a fraction of the price of a Mac. I didn't see a Mac until the early nineties and it was by then nothing new or interesting (the OS was already considered technically obsolete).

That's selling him very short. I would say most of his papers are applicable to functional programming in general and not just Haskell.

Yes, but it's changed a lot in 30 years.

He has spent the last 30 years since publishing more papers on compiling functional languages.

Probably because most programming languages haven't changed, imperative, loops, pervasive side-effects etc. Writing a compiler for a pure functional language would certainly need new material.

> You can't have closed enums without value constraints

Sum types and closed enums don't need to constrain existing sets of values, they define the set of values. Again, I think you might be confusing the type system with runtime representation.

> It's a neat parlour trick, don't get me wrong,

It's a step towards sum types which are the mathematical dual of product types. Not a parlour trick at all, every modern language should have algebraic data types.

> You're confusing unrelated features

Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type system in order to use integers as a runtime representation.

It has a lot to do with enums, especially if you are claiming statically typed enums. When defining a type, more often than not, we want to define the values that make up the set. For example, 'type boolean = true | false'

Creating new types wrapping int is not really the same thing. It's not a closed set. Presumably one could define additional overlapping constants with the same integer type elsewhere?

Go does not model enums as separate types (like e.g. Pascal), they are essentially just integers like C.

Using integers to model optional behaviour sucks, whatever you choose to call it. It's what one does in assembly language and C. Even Pascal from the early 70s had type-safe enumerations.

+1. Great advice

HD600 are hard to drive, they should sound notificably better on a dedicated headphone amp versus a ThinkPad. Many years ago I did this comparison and the difference was very significant, I've never used a stock headphone jack since.

I have Sennheiser HD800S with an RME ADI2 DAC. They sound absolutely incredible for classical and jazz music - amazing soundstage and detail. Possibly not the best for rock/pop (HD600 might be better). The RME ADI2 DAC is great, although I don't need to use the EQ for the HD800S at all. There must be something cheaper out there with less features, but an equally good amp.

Further evidence for this is that Apple ported their widgets, like stocks and weather, to native apps instead of using the web-based ones from OSX.

Taking that argument to the extreme, why test any new software at all when the underlying instructions have all been thoroughly tested!

> I'm one of those who prefers words to punctuation

It's not punctuation, it's notation. Notation is often essential for readability, we use it for mathematics and music for a very good reason. Consider why JSON is generally preferred to XML. While this guy might have a preference for pointless verbosity, most likely the person who needs to read his code won't.

Too many to list, but it's small things such as seeing how long a charge will take. Stock Android is certainly less refined.

While I might one day leave Samsung for the lack of Bluetooth codecs, in 2024 the UI is really very nice and I would miss it on many other "more stock" Android devices.

A complied language can be over 1000 times faster than Python, so maybe the dual core from 10 years ago would have been fine.

It all depends on what sort of party you want. Sharing whisky around a fire with some old friends is a great way to relax.

It also remains to be seen whether there will ever be any accountability. So far there has only been the promise to hand back a CBE.

Yes it's possible to write Java without any boxing of primitives or garbage collection, but one can't use any of the standard libraries and it's not really Java one is writing but a very restricted subset. I don't think these benchmark are particularly indicative of real world performance. But of course Java is still hundreds (thousands?) of times faster than Python.

The Cypertruck design is also weird, impractical and difficult to manufacture. Maybe that's probably a good reason to bet against?

Hopefully you agree Lisp is more productive than C++? Lisp is however not quite fast or efficient enough to displace C++ completely, mainly because, like Java and Go, it has a garbage collector. C++ was very much the language in Java's crosshairs. Java made programming a bit safer, nulls and threads not withstanding, but was certainly not as productive as Lisp. Meanwhile Lisp evolved into Haskell and OCaml, two very productive languages which thankfully are inspiring everyone else to improve. Phil Wadler (from the original Haskell committee) has even been helping the Go team.

I stand corrected!

Nice. My reply would have been something like: it combines the performance of Lisp with the productivity of C++. These days Java the language is much better though, thanks to Brian Goetz.

Java has a culture of over-engineering, to the point where even a logging library contains a string interpolator capable of executing remote code. Go successfully jettisoned this culture, even if the language itself repeated many of the same old mistakes that Java originally did.

It's interesting that they brought in Phil Wadler to help retrofit polymorphism, it literally is history repeating itself (Wadler did Generics retrofit for Java over 20 years ago).