Not finished yet but enjoying this: <https://www.y...
# thinking-together
s
Not finished yet but enjoying this:

https://www.youtube.com/watch?v=JQCJCTgzCFo

. So far it's about what computers are, how they related to the real world and the false emphasis on software as 'mathematics' when it there is a lot of non maths. Talks about shortcomings in current programming languages too.
👍 5
📝 1
Another slide from the talk.
w
I think he articulates well a number of interesting issues with conventional languages. My core issue with the talk is he spends all this time disparaging programming-as-math, yet that domain (PL theory) is doing more than any other field to address the problems he wants. Consider these strawmen he set up about “time being removed from programming”, or “the climate orbiter failing due to mismatched units”. Those are exactly problems being addressed in PL research. Every single “non-functional” property listed is a topic of PL research. I don’t know who draws that weird dichotomy he sets up, but it’s definitely no one designing today’s PLs. As a few examples of some things he listed later on: • Modeling complex communications with multi-party session types (https://dl.acm.org/doi/pdf/10.1145/1328438.1328472) • Representing real time in a type system (https://dl.acm.org/doi/pdf/10.1145/3236786) • Type-safe dimensional analysis (https://github.com/iliekturtles/uom) Then he goes on to give the terrible hand-wave answer “DSLs will solve our problems”. To me, it’s just saying: “we need better tools to model our domains”, i.e. better libraries. His only justification of languages over libraries is to give a weird argument about how a semaphore class needs to be compiled differently than a queue class?? Makes no sense to me.
☝️ 2
Coming up with a formal, general, extensible, verifiable model of concepts like time, communication, etc. are deeply challenging problems. It’s great he identifies the concepts most relevant to his experience in cyber-physical systems. But people are working on those problems, just not in the context of conventional languages with crippled type systems.
e
A wonderful lecture from a grizzled veteran. He may not have the answers, but he is very clear on the problems. He wanted to see physical units of measurement, and a syntax for a finite state machine, both of which are in the Beads syntax. I am pondering his proposal to have both a unit of time and a time interval type. Most people think of a time interval as a non-dimensional quantity (if you assume seconds). Will have to think about that. If you clutter up the language with too many primitive types it can get cumbersome.
❤️ 1
w
Part of the challenge is that the programming world is a lot bigger with a lot more noise these days. There may be a strong signal, but unless you're tuned to it.
k
@Will I agree with you, but the problem for practitioners is that the results of PL theory are out of reach for them. Academics implement their ideas in languages that are easy for them to work on, do a few test applications, and then move on to other subjects. Programmers need programming languages with strong ecosystems of tools and libraries. There is little overlap between the two worlds. Plus, as @wtaysom points out, there is so much noise interfering with communication.
👍 1
w
@Konrad Hinsen For sure, I think this guy’s concerns are super reasonable. This presentation would have been great if he just explained about how existing PLs failed based on his long experience building interesting systems. I’m just taking umbrage at the historical revisionism that makes him call math the root of his problems.
And I do genuinely believe that the theories being developed in the PL world will ultimately be what he wants in his DSLs. For example, embedding a dimensional analysis system in a language like Rust is due to innovations in type systems that have spilled into real world languages.
k
Good point. F# is another example. But dimensional analysis is also a good example to illustrate the communication issues between academia and software development. For years I have seen static typing fanboys citing it as an example for why static typing is great, and for a while I took pleasure in commenting that no mainstream type system can actually be used to implement dimensional analysis. One reason is that it requires dependent types (not necessarily full-blown, but more than standard type systems can handle). The other reason is that is applies only to a subset of variables in a program, so any type system that insists on every variable having exactly one type is unsuitable for dimensional analysis.
s
I didn't think the position was anti-math as much as saying that math is only one slice but building systems involves all these other non mathy things. Here's the list of things:
👍 1
Things like usability and evolvability aren't typically considered in the domain of maths. Same thing with DSLs. Being able to build a DSL and having an unambiguous syntax is one thing. But what about the study of what makes a DSL good? How do we evaluate in terms of how it fits the context? Yes we may use some math notation in this kind of study but the study itself is not considered math or even PL, afaik. My sense is that the HCI, design, usability and system integration are not really considered part of PL theory anymore.
👍 2
w
There’s a huge difference between “maths” as the set of topics regularly covered in a math major (discrete/real analysis, topology, proofs, etc.) vs. maths as the general study of formal languages x logical systems. The latter, I would, say covers every single bullet point under “non-functional properties” except for usability. Just look at POPL/PLDI proceedings and you will find papers about all of these topics. Yes, HCI/usability are left out since they aren’t amenable to theory, for all the reasons that people are difficult to model. And I’m the first person to advocate for more HCI in PL, it’s literally my PhD thesis. I’m all for balanced discussions of what problems programmers face in practice, and what methods can help design better tools for them. But thinking mathematically about programming has been, and will continue to be, an invaluable methodology in designing programming systems. Broadly casting aspersions about being too math-focused will not help move the needle.
z
Excellent talk! great way to start my Thursday morning!!!
e
Grace Hopper is a classic - she has a nice split between Data Processing and Math - she explains the history and how calculation of missile trajectory and record keeping tend to need different solutions. (1hour 25min) .. am fairly sure this is the right video, I remember it being long, but well worth watching.

https://www.youtube.com/watch?v=ZR0ujwlvbkQ&amp;feature=youtu.be

e
A bright, entertaining woman, but COBOL was hideous, one of the most verbose languages ever devised.