5 ms·
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I d
by stevage 3y ago
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation.
It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer.
And somehow I have ended up with a very strong bias against DSLs.
- eru 3y ago> And somehow I have ended up with a very strong bias against DSLs. Most DSLs are bad, partially because most people are bad at designing languages. Embedded DSLs can be quite neat. Eg Haskell makes it easy to embed something like DSLs inside your Haskell code. (If you squint a bit, the ability to define your own functions in any language goes in that direction of allowing you to define your own mini-sub-language that handles your problem better. Haskell (and the Lisps) just dial that kind of approach up to 11.)
- stevage 3y agoI don't necessarily think the DSLs are badly designed. But personally I find the overhead in learning and remembering a new language to be enormous. I instantly drop from extremely high productivity in my language of choice to fumbling around like a newbie. And often DSLs are used for smallish tasks that you work on, write the code, then leave for a long time. Then you come back to it and have no idea how that language worked, its pecularities, etc. It had better have an extremely high payoff to justify that cost.
- eru 3y agoEmbedded DSLs have much lower learning overhead, since they are just embedded in the language you are already using. Eg in Haskell, they are still valid Haskell programs. So they eg inherit the control structures from the host language, and most of the tooling in your editor, like 'jump to definition' also still works. See http://wiki.haskell.org/Embedded_domain_specific_language http://wiki.haskell.org/Embedded_domain_specific_language Because the overheads are lower, the payoff doesn't have to be as high to make it worthwhile. (However, there's still some overhead, otherwise you wouldn't really label them as embedded-DSLs.)
- stevage 3y agoI wasn't really aware of the embedded DSL distinction. But even then. I was never really able to get into Observable because although it looks like JavaScript, there are kind of hidden objects and methods available to you that I found weirdly hard to discover.
- extr 3y agoThe issue is that a good DSL shouldn't be a "language", it should be a tool, a textual UI that is designed by and for power users for a particular task. When you are doing something 500 times a day you want a hyper efficient tool to accomplish that. Learning curve is irrelevant, only efficiency and expressibility. A DSL is a great fit. If you are doing some task once a month you just want something simple you can wrap your head around quickly. The problem is that the former often forget that the latter exists and so recommend their workflow to everyone, forgetting they have different needs. But both sets of needs are valid.
- nik3daz 3y agoHi, unrelated but I just wanted to say hello. Stumbled across your post about spin2win a while ago and I'm glad you found it useful! I still use it every day and wish I could fix the jankiness but oh well hahaha.
- hot_gril 3y ago> Most DSLs are bad, partially because most people are bad at designing languages. A perfectly-designed DSL is still bad just because it's a whole 'nother language for you to build, and for others to learn, that probably isn't needed for whatever project.
- eru 3y agoI don't know. Eg people seem perfectly happy to use regular expressions for matching text, instead of accessing the same functionality via eg regular functions in their favourite language.
- hot_gril 3y agoThere are a few exceptions that have made the cut for a useful DSL, like SQL, Solidity, and Regex. Unless your project is totally groundbreaking, odds are low that you invent a new language that can be widely adopted.
- hot_gril 3y agoYeah, nowadays a DSL is almost never a good idea. A library for some pre-existing flexible language can do the job without reinventing a whole lot of wheels. The most specific languages I can think of that make sense are SQL and Solidity. But DSLs are tempting, especially among the more passionate programmers, so at work we've ended up with a lot of them. All of them are tripping hazards.
- wolletd 3y agoI'm wondering, is Bash/Shell a DSL? You can do anything with it because it allows launching other programs, but I'd say it was designed specifically for the domain of launching other programs and building data pipelines with their in- and outputs.
- friendzis 3y agoWhile DSLs are primarily designed to easily express certain idioms (e.g. Logo-family primarily describes pencil movement), generally (!), DSL is embeddable, isolated, Turing incomplete language. Although some DSLs are Turing complete, they are first and foremost designed to express domain specific idioms. IMO Bash and friends are too powerful and generic to be considered DSLs.
- friendzis 3y agoDSLs are awesome for what they are. DSLs let you ingest/load untrusted user code directly and have strong isolation barrier, allowing for very powerful user customizations with "native" implementations of certain features /functions. Anything from programmable authorization to custom views becomes safely and relatively easily available. Say what you want about ESB pattern, but you can implement ESB transformers in a custom DSL. Obviously not every piece of software needs these features, but when it does DSLs are very handy.
- hot_gril 3y agoReact and RN let users define views with JSX that are natively implemented. Not sure if that counts as a DSL, but it's JS extended to allow embedded HTML with custom tags, so it's not really a new thing to learn. Part of what made React popular was how vanilla it felt compared to other things that defined whole new languages or heavy-handed frameworks. And now that it exists, it doesn't need to be reinvented. At work, we had two painful DSLs for monitoring queries. Our team changed monitoring systems entirely just to use SQL instead.
- dragonelite 3y agoI thought the same when i did compiler course, but 8 years after that course i wrote tooling to mass refactor a java codebase by creating AST manipulate AST and convert the AST to code again.
- stevage 3y agoOh, yeah, true. I have done a couple of pretty complex things that involved parsing code or manipulating ASTs and it was probably useful for that. I attempted to write a parser for Wikitext once in ANTLR which was an interesting nightmare.
- anonzzzies 3y agoI wrote so many compilers and interpreters in my life, simply because I cannot stand the long compile times and waiting while developing. Only single pass to make it as fast as possible, foregoing many optimisations (I don’t need them during dev); I wrote them for parts (so basically dsls which are compatible with the original compiler of the respective language) of c++, Java, c#, typescript etc. It gave us a competitive advantage as others were waiting for builds. Then I went back to Lisp (sbcl) and found it to be perfect; instant feedback, high performance, trivial to make dsls.