https://futureofcoding.org/ logo
#thinking-together
Title
# thinking-together
g

guitarvydas

05/31/2023, 10:59 PM
I think we need many different little languages and a substrate “language” (kernel) to bolt them all together. Note that, in electronics, there is/was something called “design rules” which is something more-than-type. In web-site design, one uses “input validation” which is like type-checking but on a very per-project basis. It would be nice to be able to bolt design-rule checkers together using a palette of existing components. Again, it seems that one should want a palette of components to help build up design rule checkers and completely different palette of components to build up actions. I would expect to use different “syntaxes” for each concern and would expect to use IDE layers to deal with each kind of issue separately then let the IDE automagically stitch them together. This is just another way of saying “I would like to use a different language (SCN in my words) to deal with each kind of issue”. Would I use text-based SCNs exclusively? No. But, for text-based SCNs, I would use Ohm-JS and for diagrammatic SCNs I would start by using draw.io. Both kinds of syntaxes are “easy” now, so there is no reason not to build project-specific SCNs. We have been indoctrinated to believe that “one language to rule them all” GPLs is the way to go. I don’t agree. duplicated in https://publish.obsidian.md/programmingsimplicity/2023-05-31-Bolting+Little+Languages+Together
c

Christopher Shank

06/02/2023, 5:55 AM
I really want to see a resurgence of little languages too! I was wondering what you think this “substrate” language looks like and how these small language compose and interact together?
k

Konrad Hinsen

06/02/2023, 11:33 AM
I have held this point of view for a few years as well. And started playing with Racket to try it out in practice. Today I am less convinced that this is a good approach. In the meantime, I discovered the importance of good and language-aware tools. Not just syntax-aware editors, but in particular debuggers. Either you need to adapt a debugger to every single little language, or you have to compile those languages to some unified substrate in a way that makes debugging at the substrate level possible in practice. I haven't seen either approach work so far.
g

guitarvydas

06/02/2023, 11:57 AM
I blame the tools not the approach. Deep down, I blame this on the fact that all languages are the same - they are all based on a single Pattern - synchrony. (Longer response pending...)
k

Konrad Hinsen

06/02/2023, 2:00 PM
It's possibly a tooling issue, but then, pragmatically speaking, if I can't build those tools myself (if only for lack of resources) and nobody else is doing it, then I am stuck.
d

David Alan Hjelle

06/03/2023, 11:57 AM
Looking forward to the longer response — how different do you see these languages being, especially semantically? While some programmers seem to be able to adjust between (existing) languages quickly, working in a shop that uses JavaScript and PHP — it's a real struggle for others. There are a surprising amount of differences that go way beyond syntax (i.e. JavaScript's reference semantics vs. PHP's copy-on-write) that can trip people up in surprising ways, and that's between two languages that are relatively similar. Part of the issue is, as you said in a previous comment, we are smashing together coding and architecture and design, etc. Are you suggesting that any given person or team would only need a single SCN? (Except for the "integrators" or whatever they'd be called?)
g

guitarvydas

06/12/2023, 12:46 PM
Little Networks and Little Languages, a collection of point-form notes “as is”. I am using Kinopio (hint: Kinopio looks weird and foreign at first, but is well-suited to riffing on ideas) https://kinopio.club/little-languages-qR324zwZ6Kvh390StgXMF
@David Alan Hjelle “…Are you suggesting that any given person or team would only need a single SCN?…” No. I’m suggesting that you use any SCN that is appropriate for the task. That means, more than one SCN for any sizeable solution. Example: need to make a query + need to format result of query ==> PROLOG syntax for query + JS syntax for formatting print (${...}). Seen in https://github.com/guitarvydas/eh/blob/master/das/das2f/contains_port.md which is transpiled to https://github.com/guitarvydas/eh/blob/master/das/das2f/layer4_query.bash (this is a particularly clunky example due to the use of Bash for the substrate layer and a markdown syntax for the programlets; a less unideal IDE might allow writing this as 2 separate programlets, plumbed together by a dataflow (maybe a line between two boxes?) ; explanation: the
query
section is written PROLOG syntax needing 3 relations (
das_fact
,
das_fact
,
containsport
) and the
display
section has one line which produces text that looks like another
das_fact
rule substituting the values of R and E into the text, and, the rest is there only to appease the compiler (
parameters
and
imports
sections))
7 Views