Lingo: A Go micro language framework for building Domain Specific Languages

DSLs don't need to be supported by a separate lexer/parser. Some (for better or worse) use standard formats like yaml or json. Some (ie embedded DSLs) are represented using terms defined in a programming language.

Any naming of types, functions or variables that you do while solving a problem in software is creating a "language" of terms that are specific to the domain.

A well-constructed fluent API can read a lot like what you would call a DSL. A configuration language in YAML is both YAML and a DSL for config.

You might be interested in this classic pdf: http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf (Growing a language)

Without those function names that you talk about, you wouldn't really recognize a language. Those standard library function names give the "batteries included" kind of feeling. The size of the community libraries furthers that accessibility and productivity feeling of the language. Furthermore, you can certainly create control flows via libraries--with callbacks specifically--and create any kind of novel branching structure your domain had need of.

A good API is a sort of DSL. If it well reflects how you think about the domain and helps you express instructions within that domain. The language can be very different. We experience that in our own language when we hear people talking with heavy use of jargon we don't recognize: they might as well be speaking another language.

But overall I agree with you that I would probably save the use of the jargon term DSL for novel syntax targeted at a specific domain.

I would agree with your sentiment.

This is basically a lib with some extra syntax to parse CSV Files.

A 'proper' DSL would require a very specific domain where it is applied to. Like document creation, or solving a certain problem and only that but not much else. Turing completeness is usually not required as well.

For example Matlab or LaTex are domain specific as well as SQL. Those are used to do math, create documents or do mangle tables.

Imho just renaming forEach to Map to parse CSV files does not fit the bill so the linked example is not that great.

This project basically a DSL builder thingy with a text processor demo.

As an aside:

I am missing the most important thing when it comes to CSV which is configuration of the input.

Might be because this is more of an example but it is usually a sign of a lets say more academic project.

Working with CSV, is usually a source of a lot of "good fun" where many hours can be spent.

Because your average CSV is often a SSV or TSV in some ISO that is everything but not UTF8. It usually contains line breaks which have been renamed to funny icons by some combo of tool and operating system. Also there are weird escape character in orders which are not consistent on every row. Also sometimes you have titles sometimes not. Dates make no sense, are language depended and in a weird format the intern made up 10 years ago. And even numbers are weird too, like 12e^-25 or '0.00' or '10.000,0'. Then you get columns which really should be 2 or more, or there are lines which span multiple rows.

Ihmo it is way better for robust CSV parsing to have a really low level approach where you rigorously check for everything (and return everything to sender that does not fit).

CEL seems very much in line with the Golang ideology. It looks like CEL doesn't really have any upsides at all, except for being non-turing-complete. It looks like it is more of a convenience food, for people, for whom any other syntax than what they know from mainstream programming languages is "too adventurous" or "too foreign". As if they cannot be trusted to be able to cope with another syntax. This might even be true, considering the character of Golang itself, which was created as a dumbed down lowest common denominator of several mainstream languages, so that everyone gets it. It was even missing generics for a long time, deeming them to be too complicated.

As a DSL CEL is kinda pointless, since it does not create any additional convenience beyond the usual mainstream programming language syntax. It therefore leaves potential on the table, and as a tradeoff appeals to familiarity of syntax. As a configuration language it is usable, probably with reduced risk, compared to using Golang itself (no turing-completeness!).

I don't think it actually appeals to anyone, who considers creating a DSL for a good reason.

Which is still in use today by hobbyists mainly, but also Habbo Hotel released their old client using their old Lingo code as "Origins" it runs as an EXE that embeds the runtime. People are working on emulators that will run it natively on web, and there's a really interesting decompiler for it as well.