willtim

Designing a serialisation format has a lot similarities with designing a programming language: data types, declarative/ease-of-use versus full control, abstractions, static versus dynamic memory areas, optimising representations etc. There is definitely room for a variety of formats depending on the use cases; and many are unhappy with the current incumbent: https://reasonablypolymorphic.com/blog/protos-are-wrong/

But yes, it's a lot of work and they probably should document what the trade-offs are that they have made.

An insignificant breaking change is still a breaking change; and over time they build up. This may explain why so many developers have been unhappy with GTK3.

Very strange, I can confirm that your Spotify sample does sound much better than my one. Mine sounds identical on Windows and Android though, two very different platforms, so it may indeed be a UK problem. Thank you very much for the code.

I've uploaded a small example, a small clip taken from the CD followed by the same clip captured from Spotify: https://drive.google.com/file/d/1F3NvOpqcMfvNSmyyvbgfUlV6XMO...

This reply might be interesting: https://news.ycombinator.com/item?id=26354999

Thanks for the recommendations. I'm still very new to streaming and still buy CDs for most of my music. I am currently using UAPP on my phone and plug it straight into an RME ADI-2 DAC, the advantage being I don't have to fire up the PC. The disadvantage of course is storage on the phone.

I can confirm Qobuz sounds great. I've signed up for a free trial. The integration with UAPP on Android works well and gets around the Android 48Khz limitation. Thanks for the recommendation.

Thanks for the recommendation. I see that Qobuz also integrates with UAPP on Android (which gets around the 48Khz limit). Since I listen to mainly Jazz and Classical, it sounds like a good fit.

Sure, one example is the first minute opening of Osmo Vanska's Mahler 5. The big crescendo between 40-45 seconds sounds particularly bad, lots of break-up and distortion. Sounds fantastic on the CD.

I have it set to "Very High" and have their normalisation turned off. I can provide samples demonstrating distortion and break-up; the waveforms even look completely different visually. It's even audible over non-audiophile headphones. On my HD800S it's unlistenable. I have no idea what they are doing to the sound, but I have found many recordings that sound awful on both Android and Windows.

The marketing for this one hasn't reached me yet. Thanks for the recommendation.

EDIT: looks like Amazon HD might force re-sampling of 44.1KHz to 48KHz on Android, which is a shame if true.

I am thinking of moving to Tidal. The Spotify sound quality is awful for Classical music with their compression/processing unable to deal with complex passages. The Android app also upsamples everything to 48KHz and has occasional random audio glitches. Hopefully Tidal is better.

> A new format is a really weird way to go about fixing a problem that already has a solution.

Stripping comments before handing off to a JSON parser is not a full solution. For example, if the file has to be augmented with additional data and written out again, the comments would be lost.

I am not the source of the original statement, but my own interpretation of "powerful" aligns with simplicity and flexibility. Plain text has only slightly more structure than a stream of bytes, meaning it retains a lot of simplicity and flexibility. Yes plain text can be inefficient and is overused (a proprietary unpublished wire-format does not need to use JSON). However, 50 years from now, the only data I feel comfortable knowing I'll be able to read is plain text (and possibly also JPEG and a few other well-specified and simple binary formats). Many binary formats are effectively defined by large complex and transient code bases that target particular tool chains and APIs. A new binary format needs to justify itself, less so plain text.

Yes, deprecation is fine, as long as they are not removed.

I was responding to "Can Haskell evolve?", I was trying to say "I think it can, but I would prefer it to evolve in a new language". The standard library is riddled with partial functions, like head and tail. We should not take them away and break thousands of projects, research papers, books and blog articles.

Only if Haskell stops being maintained, which I very much doubt would happen. Therefore no one is forced into the change.

> You realize 3 would make 1 and 2 harder or less valuable?

Yes that is why I think (1) and (2) need a new language.

> And 3 would have also prevented a gazillion 1s and 2s from being still with us?

I disagree. Most new features have been implemented as extensions that must be enabled with language pragmas. This is not the same thing as large breaking changes in the standard libraries.

IMHO Haskell is missing three features that would really improve programming in the large:

1) better structural types. For example, polymorphic extensible records and variants. These could even be the basis for all algebraic data types. Current encodings have poor syntax and poor type inference (due to non-injective type families). The need to make all records nominal types really gets in the way when dealing with structured data. Python is the main competitor here; and so we could also just use strings and maps, but we can do better.

2) a better module system. Even Miranda had a better module system than Haskell. OOP has first-class modules.

3) a better commitment to backwards compatibility. There have been controversial and breaking changes to Haskell's standard libraries that have done more harm than good. This has likely damaged industrial adoption of Haskell. For example, my employer, a prominent Haskell sponsor, is stuck on a 7-year old version.

Unfortunately the above problems are difficult to retrofit for and so I think a new language may ultimately be needed.

I usually recommend "Since We Met" to anyone new to Evans, its a great collection of tunes and a great performance. "I Will Say Goodbye" is a great record too, although my CD copy has lots of tape wow and flutter all over it. I'm not sure if the broken tape machine was used in mastering or whether all recordings have these artefacts.

The problem with encapsulation in OOP, is that the (mutable) state is not truly encapsulated, it is just hidden. State encapsulation would be a pure function that uses mutation internally. OOP encourages mutable state and in general it is non-trivial to compose such effectful code. The state space of an OOP application can become a combinatorial explosion. This might be what you want if you are modelling something with emergent complexity, e.g. a simulation or game, but doesn't sound good for a line-of-business app.

As an anecdote, I once saw a stack overflow reply from a distinguished OOP engineer advocating for modelling a bank account with an object containing a mutable balance field! That is certainly not modelling the domain (an immutable ledger). OOP might fit some problems well, but the cult of presenting it as the one-true-way (made concrete in 90's Java) is deserving of a backlash IMHO.

The original ones had some problems that were never fixed (IIRC, the original firmware was outsourced to a company that went under), but the Advantage 2 was a redesign and works great (at least for me).

The Kinesis Advantage 2 has the keys in a concave well, which means less reach is needed to get them. It's similarly priced and worth a try!

"Generics" (a.k.a. parametric polymorphism) might be terrible for code clarity in a verbose language with subtyping and little to no type inference, but in many languages they actually improve code clarity:

map : (A -> B) -> [A] -> [B]

It's quite clear from the above type signature what this function does and does not do. It can only use the supplied A's to create B's using the supplied function. It cannot do anything else with the A's and the B's. To me, that is clarity.

I suspect the issue is partly caused by outsourcing the enforcement to private contractors and setting targets!

Java can be slow for many complex reasons, not just GC. Oracle are trying to address some of this with major proposals such as stack-allocated value types, sealed classes, vector intrinsics etc, but these are potentially years away and will likely never arrive for Android. However, a lot of Androids slowness is not due to Java but rather just bad/legacy architectural decisions. iOS is simply better engineered than Android and I say this as an Android user.

While I think that having some publicly funded radio/TV is a really good thing, the idea of the UK TV license and the subsequent enforcement is not. My friends elderly mother does not have or want a TV. She is constantly harassed and threatened by UK license enforcement. Her son has invited them into her home on numerous occasions, hoping that the legal threats and visits would cease, but to this day they have not. I object to having my license fee money spent on such abuse of vulnerable people.

A nice and fun tutorial. I'd also like to see a text editor example in Rust implemented using a persistent data structure, for better concurrency (e.g. background save) and undo support. Perhaps I should have a go!

You seem to be lumping all side-effects together as equally bad? I don't think you can expect to push everything out to the edges, for example partiality. I take your point that a lot of imperative programming is done in Haskell (e.g. State monads). However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects.

Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.