Rochus

45 ms·

931.
by Rochus 2y ago
Thanks for pointing to Glicol; this is amazing; looks like some kind of marriage of Chuck and Faust; or to which other language would you compare it? Just looked around a bit on the sites, but didn't see a language specification. Can y
932.
by Rochus 2y ago
> not exactly the easiest language to compile Besides "call by name", also using gotos for dynamic non-local exits, even by passing labels as an argument to a procedure, is pretty tricky.
933.
by Rochus 2y ago
Don't agree. Writing a compiler "the old way" is still fun and useful, even in the age of ChatGPT (used by the method recommended by the author). I also think that PEG parsing might make life easier in some situations, but it
934.
by Rochus 2y ago
Well, the author doesn't claim that poetry is dying, but rather that an overwhelming amount of poetry is being written and published, leading to a flood of mediocre work that makes it difficult to find good poetry.
935.
by Rochus 2y ago
Love it!
936.
by Rochus 2y ago
> The other part is how many people you need to produce music. One is enough, see e.g. http://rochus-keller.ch/?p=1317 . The band is just one guy and the output is the result with no overdups, just with the (AI) masteri
937.
by Rochus 2y ago
That's correct. Relative pitch gives you 99.9% of the benefits, with 0.1% remaining for perfect pitch.
938.
by Rochus 2y ago
Perfect pitch is in no way necessary for this. Interval listening is sufficient. The additional benefit of perfect pitch would be, that your friend would know the basic key of the tune without first playing one note on the piano. For exampl
939.
by Rochus 2y ago
With perfect pitch, you save yourself the five dollars for a tuning fork. In my forty years of experience as a musician, I have yet to encounter any other benefit.
940.
by Rochus 2y ago
(2017)
941.
by Rochus 2y ago
> I learned perfect pitch as an adult. Better learn to play an instrument; I don't know what a perfect pitch would be good for.
942.
by Rochus 2y ago
Computer science has a long tradition of not or misattributing inventions. Unsurprisingly, the early contributions from Japan can be found in the historical summaries by Schmidhuber (see e.g. https://people.idsia.ch/~juergen
943.
by Rochus 2y ago
It's a conceptual and implementation issue; the conditions must also be met in a multithreaded environment, which means they have a synchronization effect (and corresponding thread synchronication code must be added by the compiler); t
944.
by Rochus 2y ago
> But it has many other good language features, IMO. It also has a few rather problematic corners, e.g. that preconditions in multithreaded applications interfere with thread synchronization.
945.
by Rochus 2y ago
(2012)
946.
by Rochus 2y ago
I found a demo video here: https://youtu.be/ZyeR6pCyUi0 As it seems it's rather a beginner's tool.
947.
by Rochus 2y ago
English is not my native language; I probably should have written "that the speed-up *from* a manual assembler implementation compared to a generated interpreter is about 30%"; the point is that the speedup is small but at least d
948.
by Rochus 2y ago
See also https://stefan-marr.de/papers/oopsla-larose-et-al-ast-vs-byt... which demonstrates that we can do that with GraalVM/Truffle, and the generated VM from the AST based interpreter is even faster than the byt
949.
by Rochus 2y ago
> Deegen’s generated interpreter is faster than LuaJIT’s handwritten one by 30% That's exactly what I've written. But apparently I got that wrong with their baseline JIT.
950.
by Rochus 2y ago
You can e.g. use Node.js as a reference and compare with these results: https://github.com/rochus-keller/Oberon/blob/master/testcase... . LuaJIT with JIT on is usually factor two slower than Node.js and f
951.
by Rochus 2y ago
Ok, apparently I misinterpreted the text; it would be easier to unserstand if they used factors instead of percentages. Actually it's pretty close to LuaJIT in JIT performance, which calls into question both the use of manual assembler
952.
by Rochus 2y ago
Discussed here: https://news.ycombinator.com/item?id=42186507
953.
by Rochus 2y ago
"Pfarromat"
954.
by Rochus 2y ago
Interesting, thanks; though I don't think that what you describe is comparable to L-systems. Just had a look into the book "Unplayed Melodies, Javanese Gamelan and the Genesis of Music Theory" by Perlman, which I have at hand
955.
by Rochus 2y ago
Is it? Can you provide a reference, please?
956.
by Rochus 2y ago
Prusinkiewicz indeed did important work on L-systems and music in the eighties, but the use of generative grammars and rewriting systems in music dates back at least to the sixties. The reslts of such approaches are not random, but "ps
957.
by Rochus 2y ago
> "The original note-taking program" There were many note-taking apps much earlier. Even on the Alto they had note-taking apps. In the eighties, systems like Lotus Notes appeared. And not to forget the many outliners, e.g. MO
958.
by Rochus 2y ago
How can it be that JS (i.e. Node.js) is not included? I would bet it has a much higher prevalence as a server-side PL than e.g. Scala.
959.
by Rochus 2y ago
> experiment with Large Language Models (LLMs) a la GPT-4 or Llama3 in the area of music generation LLMs are/were indeed used for music generation, but none of these results were convincing from my perspective as a practicing musi
960.
by Rochus 2y ago
Doesn't look like a property management firm; see https://en.wikipedia.org/wiki/RUAG .

More ›