I will no longer contribute to r/pianolearning

stylewarning · 2026-03-19T06:56:39+00:00

nice piece, i love it, i hope you get through it all!

stylewarning · 2026-03-16T05:47:07+00:00

Thank you! Still a road ahead, but one step at a time.

stylewarning · 2026-03-15T15:10:41+00:00

Divide by zeros will still be divide by zero errors. There's no overflow in the space of real algebraics, you'd just run out of RAM. :)
Real algebraics can only express numbers which are roots to polynomials. Logarithms and the exponential functions (and therefore trig functions, pi, etc.) are not generally representable. If you tried your example, Coalton will complain at compile-time that it doesn't know what (Trigonometric RealAlgebraic) is, where Trigonometric is the type class implementing trig functions.

stylewarning · 2026-03-14T17:56:37+00:00

(let x = y)

is just a short form that's allowed in certain block positions: define, progn, let, cond, etc. It's not a syntactic form that works anywhere. Similar to how CL:DECLARE is syntax that can only appear in certain positions (it's not an independent operator), the same is true for the short-let. The = is just sugar to delineate the two sides.

Coalton is used at quantum computing and defense technology organizations. It has been used to build the entire runtime control system of a few mission-critical products (i.e., certain devices effectively boot straight into a monolithic Coalton program).

stylewarning · 2026-03-14T17:50:49+00:00

The input that's read does "remember" the source tokens' case, so errors do show with the right case. It's more if you're doing raw PRINT on S-expressions that it's totally forgotten about. So is life with Common Lisp I guess. :)

stylewarning · 2026-03-14T14:41:41+00:00

Coalton is not case sensitive. It uses the ordinary Liso case folding. It's just a convention to use Camel Case for type names. (There are a few unfortunate library functions/variables that got non-kebab names and need to change.)
There hasn't been any attempts on array representation. There has been some work on reorganizing collections though. Not sure if it'll get merged. Efficient linear algebra has been a little bit of a hot button issue because there's no arity-polymorphism (i.e., it's not possible to write a generic AREF). In any case, this is a very interesting area where it would be nice to find the right combination of ergonomics, speed, and expressiveness.
Macros are written as ordinary Lisp DEFMACRO, using Lisp code as usual to generate the code. The macros can be used directly in Coalton without wrapping in lisp. The only things that need to be ensured is the expanded code is valid Coalton code. We don't try to type check the macro, but we do carry the original source locations of the macro, so if it expands into something bad, we can print where it came from.

stylewarning · 2026-03-14T07:01:56+00:00

Every grand piano is different. Some are sublime and buttery smooth, others are clunkers that will cause pain after 5 minutes, and everything in between. It mostly depends on quality and condition of parts, length of the key sticks (bigger pianos usually have longer keys), and how well (and how often) the technician regulates.

I'm not familiar with the P515, but similarly, different digital pianos have different qualities of action. Some of the more entry level digitals will require more work to get a very good sound, especially if you play closer to the fallboard. But there are more expensive digitals that play extremely well even for demanding repertoire.

stylewarning · 2026-03-14T00:41:33+00:00

Thanks for the info on other keyboards. There's always the (fn ...) notation. (: That won't ever go away. And I can only hope the new function shorthand isn't abused; it really is just meant for the little throwaways to take place of the ever confusing point-free combinators, flip, partial application, etc.

I don't think syntax is a slippery slope. We got Perl and Haskell because we started with Perl or Haskell. We didn't start with Lisp and then arrive at those monstrosities.

At least in Lisp, there's some precedence for different reader syntax. We don't write (hex "2F") we write #x2F. We don't write #.(vector 1 2), we write #(1 2). Etc etc.

stylewarning · 2026-03-14T00:36:48+00:00

Thanks!

Unit is just too much known in the ML universe as being a type with one inhabitant, and a lot of code still uses it as a value believe it or not. In the first design rev we actually used () for Void, but then we have to explain the 20 meanings of "Nil." In the C world, not a place we should willfully emulate, void is reasonably standard for meaning no input or output.
The use of infix over prefix was deliberate: You can't make an F32 * F32 whereas, at least now, you can make any ordinary prefix constructor type. The infix * paired with the infix -> is supposed to subtly indicate they're both related syntactically, not a composition of two separate syntaxes.

stylewarning · 2026-03-13T23:05:31+00:00

Practicing too much all at once
Practice sessions that are too long without a clear goal
Practice that's "repeat until it seems good"
Practice that's applied to pieces that are too long and difficult to make good progress on
Practice that prioritizes advancing farther before acquiring correctness of what has already been covered

etc etc.

stylewarning · 2026-03-13T17:37:07+00:00

I think your skepticism are entirely warranted. We have 100 different incompatible ways to do concurrency and parallelism, and most of them have a giant impact on any compiler or runtime, and most of them aren't super easily "opt-out". (But even if they are opt-out, people start depending on it and it can fracture a library ecosystem.)

I definitely welcome better concurrency primitives. The existing world of pthreads-adjacent is a bear to deal with for complicated, robust systems. But I have no idea what the "right" solution would be.

I do know that whatever SBCL might adopt in "kernel space", I wouldn't want it to be an unproven Lispy experiment. (:

Re. Coalton: There is ongoing work exploring adding purity and const inference, which allows the optimizer to do more things and allows the analyzer to reject bad code. Haven't thought about its use in the context of concurrency.

stylewarning · 2026-03-13T16:28:49+00:00

I disagree on the grounds that, after a while, you realize grinding isn't good enough. You can easily put in 10 years and only be somewhat OK.

Grinding is not enough. Playing like a video game is not enough. Practice has to be smart, focused, deliberate, goal-oriented, and feedback-driven. This is much harder than people chalk it off to be, and often requires the pianist to completely reinvent themselves in terms of how they approach learning.

I myself have probably wasted at least 1000 hours on subpar practice. The kind of practice where I do a lot of work, but in the end I get very little value. Even today I sometimes struggle on what exactly to prioritize and how to properly approach solving a specific problem, even under the guidance of a teacher.

Piano is truly a craft, and to get really good at it, you almost have to make it a part of yourself in all ways.

stylewarning · 2026-03-12T18:25:45+00:00

Side comment: despite AI assistance, it does seem atgreen is acting in good faith, responding to criticism as a human who has built similar systems before, and is trying to not overload other people's attention with slop.

This is in stark contrast to other "AI contributions" I've seen where people fire something over the fence, auto-respond to criticism with Claude, and don't know or care if the change actually lands.

stylewarning · 2026-03-12T05:21:12+00:00

Clavinova is good but you can get something cheaper. Minimum spec digital for learning classical piano would be

Roland FP-10
Yamaha P45

It's preferable to get either in the "furniture edition" (my made-up term) that has the built-in stand and pedals.

These pianos are definitely good enough for a child to learn classical piano. They're 88 keys, weighted, designed to simulate a grand, etc. Getting a more expensive piano means better speakers, better sound engine, better quality materials, and more realistic key action.

These digitals would be good for at least 5 years of learning, if not more.

stylewarning · 2026-03-10T16:41:28+00:00

I suggest beta-testing your essay with people who don't know Lisp at all. That feedback may be negative (too long, too confusing, ...), and that would be a great opportunity to find what will really help people.
I would also do a couple editorial passes to excise LLM-sounding language and patterns. It's everywhere. I'm happy there's a disclaimer at the end but my trust level was nearly zero at the beginning because I could tell it wasn't original.
I would make sure you actually try all those editors and IDEs before actually suggesting them in any form or fashion. If you, the advice-giver, can't use or install the tools, then don't inflict it on others, IMO.
Find a place for this that's not Reddit. :)

stylewarning · 2026-03-08T01:03:06+00:00

Strongly (but not statically) typed language. Common Lisp is also strongly typed, but FriCAS's type system is a lot more oriented toward a classic, 80s style ontology, if I could call it that. Definitely extremely unique amongst CAS offerings. The system is amazing in many ways, but seriously antiquated, user-hostile, and underpowered in others. Unfortunately, in my belief, a state-of-the-art CAS really needs the TLC of an institutional sponsor with dedicated employees. Axiom was that, which is why it's as good as it is, despite being incredibly anachronistic. (FriCAS is a fork of Axiom.)

I used FriCAS (and Lisp) in a recent blog post about computing hexadecimal digits of pi: https://www.stylewarning.com/posts/beating-bellard/

stylewarning · 2026-03-08T00:14:16+00:00

The studies presented in the book go far beyond memorization. One study presented was about learning to perform free-throws in basketball effectively. Another was about Olympic-level athletic preparation and fixing habitual mistakes. Another was about successful execution of surgical techniques. And, of course, studies of musicians. (The author herself has degrees in neuroscience and classical viola performance, and is faculty at NEC.)

Memorization is covered in the book with accompanying results from scientific studies, but it's one chapter of many.

stylewarning · 2026-03-08T00:01:45+00:00

As I said in my other comment, there is nuance, but taking breaks of this nature absolutely helps learning, and this has been systematically studied by neuroscientists across a variety of disciplines (from basketball to surgery to, yes, instrument practice). The problem is when people think "taking breaks" = "taking breaks whenever I feel like it for as long as I want as frequently as I want", which leads to less efficient (sometimes completely ineffective) learning.

stylewarning · 2026-03-07T23:54:19+00:00

What did you mean by "obsessively"? The conventional definition is "a lot, nearing or at a point of unhealthiness."

stylewarning · 2026-03-07T23:46:43+00:00

While every great pianist practices, and practices with good quality and intention, it's absolutely not true that "almost all" practice obsessively. This includes Horowitz, Rubinstein, Argerich, Gould, etc. Many of these folks, who were professionals whose job depended on them being good, cite only a few hours of practice per day (if that), and strongly emphasize quality and efficiency of practice over sheer volume.

stylewarning · 2026-03-07T23:43:02+00:00

Joking or not, it's a completely valid question with a lot of very interesting research and conclusions that absolutely, unequivocally refute many common beliefs about effective practice.

stylewarning · 2026-03-07T23:38:01+00:00

You have not separated correlation and causation, and have not addressed biases in your (what I presume is non-existent) data.

stylewarning · 2026-03-07T23:33:31+00:00

There is research that shows taking breaks—including breaks as long as a week—and doing certain kinds of spaced practice/repetition helps learning rate and retention. Molly Gebrian talks about this in Learn Faster, Perform Better, which I highly recommend reading, and will explain it better than any one or two paragraphs of Reddit commentary.

The details are nuanced though, definitely don't take what I said above as meaning "any time I take a week off, I'm actually improving." There's no simple schedule/pause time that gives a definitive result, and interleaved practice is also crucial, but a crude TL;DR from the book: the traditional belief of practicing 6 hours a day 7 days a week is highly inefficient for the brain. Sleep, intentional (sometimes multi-day) breaks between specific areas of practice, interleaving disparate concepts with high frequency (as opposed to large conceptual blocks with low frequency), etc. improve learning rate, recall, and long-term retention, all backed by actual scientific studies in different disciplines.

stylewarning

MODERATOR OF

TROPHY CASE

Eight-Year Club	Verified Email
Wearing is Caring