Jonathan Aldrich

I don't usually respond to old comments, so I don't know if you'll read this, but I hope I can encourage you to think more broadly about what "differentiable programming" means.

Different fields have a different perspective on the same set of tools because those tools have different pathological cases in different areas. Context really matters.

> Well, that was my point above: You can't really lump quantum programming together with probabilistic programming, as they are paradigms on different "levels"

This distinction is not useful. If I write in a functional or logic programming language, it gets translated into imperative commands for an underlying architecture that is some mix of dataflow, event driven, automata-based, concurrent, etc... that is then further built on top of some physical atoms where an engineer worried about quantum effects. If I write in a quantum programming language, it will probably go through the same process for at least another 5 years. You might argue that quantum is somehow more dictated by the underlying physical model the way that people argue that imperative programming is closer to the physical world than functional programming. But the "level" doesn't change the usefulness of viewing all of these as "paradigms" worthy of study and analysis on their own terms with their own tools. At the level of studying a programming language, the "level" is a useful thing to be aware of for implementations and motivation but usually not for a…

Well, in terms of whether the example is a well-posed question, a networked window system isn't too different from the WWW, which as we know by now works pretty flawlessly.

Perhaps the key contrast here is between the tendency toward static mathematical perfection of the APL family and the notion of dynamic languages for building systems that Alan Kay et al would propose.

"APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can’t add anything to it. If you try to glue on another diamond, you don’t get a bigger diamond."
--Joel Moses

There's a talk by Ian Piumarta that tries to get to the core of what the VPRI guys feel is important. I'm not sure about it but it seems worth mentioning in this context:
Ian Piumarta "Building Your Own Dynamic Language"
http://www.youtube.com/watch?v=cn7kTPbW6QQ

Also, this:
https://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf

A fun excerpt from "Capabilities: Effects for Free"

Capability-safe languages prohibit the ambient authority [18] that is present in noncapability-safe languages. An implementation of a logger in Java, for example, does
not need to be initialised with a log file capability, as it can simply import the appropriate file-access library and open the log file for appending by itself. But critically, a
malicious implementation could also delete the log, read from another file, or exfiltrate
logging information over the network. Other mechanisms such as sandboxing can be
used to limit the damage of such malicious components, but recent work has found that
Java’s sandbox (for instance) is difficult to use and therefore often misused [2, 12].

Emphasis added my own.

[1] https://www.cs.cmu.edu/~aldrich/papers/effects-icfem2018.pdf

Just because something is complex doesn't mean it is bad, but something being really really complex (or feature rich), doesn't mean it is good either.

Now I might be mistaken, but Scala is one of rare languages that actually has compiler commands that disable parts of it syntax (or there was a plan to do so). To me that yells - Too complex. I'm quite sure it is powerful. But it doesn't look like something I'd enjoy using.

My main gripes about Scala is that the trait system is way less elegant than the Smalltalk variant [1], there seems to be a hundred different ways to do a thing (as opposed to a more unified way of doing things) and the overall "automagical" implicit. Not to mention the overall verbosity and ways the different features mesh together.

[1]http://www.cs.cmu.edu/~aldrich/courses/819/Scha03aTraits.pdf

> For example if a function needs to take a record containing x as a field with type int, it should also accept a record with y as a field that it does not use.

Not sure if I misunderstand what you mean, but this does not require subtyping. One of the key distinguishing features of row polymorphism is that exactly this can be achieved without subtyping. The extra unused fields (`y` in your example) are represented as a polymorphic type variable _instead_ of using subtyping. See for instance page 7 in these slides: https://www.cs.cmu.edu/~aldrich/courses/819/slides/rows.pdf

Maybe not everyone will know this but Typestate was one of the original 'headline features' of Rust when Graydon Hoare started it. It was based on the Strom/Yemeni paper[0] for the NIL language. There's a mention of in this SO answer from 2010[1] and in the LtU discussion[2].
I'm not sure why it was de-emphasised, I think it didn't work as well as anticipated in the 'real world'

[0]: http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestate.pdf

[1]: https://stackoverflow.com/questions/3210025/what-is-typestate

[2]: http://lambda-the-ultimate.org/node/4009