6 points•so-cal-schemer•3 days ago•4 comments•

4 comments

so-cal-schemer3 days ago
In the ideal world, software developers would analyze each problem in the language of its domain and then articulate solutions in matching terms. They could thus easily communicate with domain experts and separate problem-specific ideas from the details of general-purpose languages and specific program design decisions.

In the real world, however, programmers use a mainstream programming language someone else picked for them. To address this conflict, they resort to—and on occasion build their own—domain-specific languages embedded in the chosen language (embedded domain-specific languages, or eDSLs). For example, JavaScript programmers employ jQuery for interacting with the Document Object Model and React for dealing with events and concurrency. As developers solve their problems in appropriate eDSLs, they compose these solutions into one system; that is, they effectively write multilingual software in a common host language.

Sadly, multilingual eDSL programming is done today on an ad hoc basis and is rather cumbersome. To create and deploy a language, programmers usually must step outside the chosen language to set up configuration files and run compilation tools and link-in the resulting object-code files. Worse, the host languages fail to support the proper and sound integration of components in different eDSLs. Moreover, most available integrated development environments (IDEs) do not even understand eDSLs or perceive the presence of code written in eDSLs.

The goal of the Racket project is to explore this emerging idea of language-oriented programming, or LOP, at two different levels. At the practical level, the goal is to build a programming language that enables language-oriented software design. This language must facilitate easy creation of eDSLs, immediate development of components in these newly created languages, and integration of components in distinct eDSLs; Racket is available at http://racket-lang.org/

peakblick3 days ago
What's aged best here isn't "make DSLs" — plenty of people preach that — it's that they treat tooling for the new language as first-class: error messages phrased in terms of the DSL, not the host. That's exactly where most in-house DSLs die. Anyone can grow a macro layer in a weekend; almost nobody follows through on the debugging story, so six months later you have a bespoke language with stack traces that leak the implementation and one person who understands it.
It seems to me that AI code generation and "bottom-up" program design -- or to an extreme, language oriented design -- could work well together to produce well organized code. Not only would it be more meaningful for human consumption, but it would be more token efficient too.

I'd rather read tight, meaningful abstractions in code than verbose, repetitive, simple code that many promote today.

As an aside, confabulations / hallucinations could be seen as a feature. At least in the world of LOP.

I "vouched" this comment. Good point..

[why the down-voting? markers of AI?]

Read the full thread on Hacker News →

Related stories