4 ms·

Archives of sklogic’s posts here and /u/combinatorylogic’s posts on reddit. I think he might be right. [edit] reddit: https://camas.github.io/reddit-search/#{

Archives of sklogic’s posts here and /u/combinatorylogic’s posts on reddit. I think he might be right. [edit] reddit: https://camas.github.io/reddit-search/#{%22author%22:%22combinatorylogic%22,%22resultSize%22:100} https://camas.github.io/reddit-search/#{%22author%22:%22comb... hn: https://news.ycombinator.com/threads?id=sklogic https://news.ycombinator.com/threads?id=sklogic

ep103 5y ago
looks like his account was suspended?
- ffwacom 5y ago
  Ah yeah, I've updated the parent with links.
nextos 5y ago
What insights did you gain from this user(s)?
- ffwacom 5y ago
  My understanding of his argument goes something like this: When you are solving a problem with a program, the program has two types of complexity; essential complexity which is needed to define the problem, and incidental complexity that comes from executing the program on the computer (variables, functions, class definitions, etc). He argues that there is no way to eliminate the incidental complexity from the program without defining a DSL at the level of abstraction of the problem domain. So a DSL for generating a flow chart would contain keywords for 'start', 'end', the various states and structure to join the states together, just the minimal amount needed to uniquely define the flowchart. Unlike when solving the problem using a general purpose language, what the DSL would not contain would be functions and variables, methods to draw boxes, housekeeping for export formats etc. In this way the essential complexity of the problem is captured entirely by the DSL, and the incidental complexity has been moved to the DSL implementation. So once a DSL or language has been defined for the problem, he argues you now compile it down to an underlying metalanguage (anything with a quasiquotation operator, macros basically), rather than using an interpreter or something. The reason he argues for compilation is that compilation can be defined as a series of tree rewrite rules, as trivial as needed (nanopass was used as an example of a compiler framework that operates this way), then combined linearly until it's expressed in the underlying metalanguage (or another DSL). Any primitive runtime features needed for the program would be written in the metalanguage or another DSL. He argues an advantage of having a common underlying metalanguage is it allows him to combine the DSL's as needed, and whip new ones up on the fly as needed. His threshold for making a new DSL is anything that takes more than 5 minutes. He has a bunch of tools to make this whole process easier, inferring IDE integration code, autocomplete, debug info, etc. I find it compelling, and getting convinced by the argument that there's no other way to eliminate all incidental complexity from the program other than a babel tower of languages, linguistic abstraction.
  - nextos 5y ago
    Thanks for the writeup. I think this is spot on. I've argued for DSLs many times here on HN due to a slightly different, although intimately related, reason. I think it's the only way to avoid the Turing tarpit [1]. In other words, getting some clean semantics where it is easy to prove things. IMHO, the only way to get formal methods to scale. [1] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit
  - vendiddy 5y ago
    I recommend reading A Philosophy of Software Design. Gets into some fundamental principles of writing software without getting too prescriptive. A part of the book covers balancing the cost of abstraction with the amount of complexity it is hiding. The ideal is: simple interface (DSL in this context) and lot of hidden complexity. I agree with your point, but the threshold for writing a DSL needs to be carefully considered.

ep103 5y ago

looks like his account was suspended?

ffwacom 5y ago
Ah yeah, I've updated the parent with links.

nextos 5y ago

What insights did you gain from this user(s)?

ffwacom 5y ago
My understanding of his argument goes something like this: When you are solving a problem with a program, the program has two types of complexity; essential complexity which is needed to define the problem, and incidental complexity that comes from executing the program on the computer (variables, functions, class definitions, etc). He argues that there is no way to eliminate the incidental complexity from the program without defining a DSL at the level of abstraction of the problem domain. So a DSL for generating a flow chart would contain keywords for 'start', 'end', the various states and structure to join the states together, just the minimal amount needed to uniquely define the flowchart. Unlike when solving the problem using a general purpose language, what the DSL would not contain would be functions and variables, methods to draw boxes, housekeeping for export formats etc. In this way the essential complexity of the problem is captured entirely by the DSL, and the incidental complexity has been moved to the DSL implementation. So once a DSL or language has been defined for the problem, he argues you now compile it down to an underlying metalanguage (anything with a quasiquotation operator, macros basically), rather than using an interpreter or something. The reason he argues for compilation is that compilation can be defined as a series of tree rewrite rules, as trivial as needed (nanopass was used as an example of a compiler framework that operates this way), then combined linearly until it's expressed in the underlying metalanguage (or another DSL). Any primitive runtime features needed for the program would be written in the metalanguage or another DSL. He argues an advantage of having a common underlying metalanguage is it allows him to combine the DSL's as needed, and whip new ones up on the fly as needed. His threshold for making a new DSL is anything that takes more than 5 minutes. He has a bunch of tools to make this whole process easier, inferring IDE integration code, autocomplete, debug info, etc. I find it compelling, and getting convinced by the argument that there's no other way to eliminate all incidental complexity from the program other than a babel tower of languages, linguistic abstraction.
- nextos 5y ago
  Thanks for the writeup. I think this is spot on. I've argued for DSLs many times here on HN due to a slightly different, although intimately related, reason. I think it's the only way to avoid the Turing tarpit [1]. In other words, getting some clean semantics where it is easy to prove things. IMHO, the only way to get formal methods to scale. [1] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit
- vendiddy 5y ago
  I recommend reading A Philosophy of Software Design. Gets into some fundamental principles of writing software without getting too prescriptive. A part of the book covers balancing the cost of abstraction with the amount of complexity it is hiding. The ideal is: simple interface (DSL in this context) and lot of hidden complexity. I agree with your point, but the threshold for writing a DSL needs to be carefully considered.