4 ms·
I'm curious about whether there is a large skills overlap between engineers working on compilers and embedded DSLs (for the case of external DSLs, such an overl
by ablekh 7y ago
I'm curious about whether there is a large skills overlap between engineers working on compilers and embedded DSLs (for the case of external DSLs, such an overlap would IMO be quite significant).
By the way, are there any people here (or, perhaps, you could recommend someone) who is very capable and would be interested in doing some potential contract work on a DSL (I'm still pondering about embedded vs. external - obviously, each category has their own pros and cons, but platform stack selection adds an additional complexity dimension)? Several people who I have approached so far, are definitely very knowledgeable, but they all work in academia and, thus, practically, have no time for consulting or contract work. :-( Not to mention potential issues arising from IP clauses in some experts' university contracts, hence the question above.
- aednichols 7y agoI have no specific experience with compilers (I missed the chance to take the class in college due to scheduling conflicts). My current day job, at a research nonprofit, is working on a system whose behavior is driven by an external DSL. I get to work on the parser/compiler type thing that generates executable units and the interpreter that actually runs them. This is certainly not the “big leagues” as far as compilers are concerned, we’re not executing anything directly on anyone’s CPU, but I do find it tremendously enjoyable.
- ablekh 7y agoThank you for sharing your experience. Do you use a more or less well-known toolset like MPS or Xtext or it is some kind of a custom framework? Any lessons learned and best practices regarding external DSL design and development?
- aednichols 7y agoWe built everything ourselves. The parser in particular was written in-house by a Person Who No Longer Works Here who was a parser enthusiast (Conway’s law). If we were starting from scratch today I would think we would use an off the shelf package. One excellent choice was to make the language [0] an open standard and now there is at least one totally novel implementation [1] in addition to ours [2]. 0. https://github.com/openwdl/wdl https://github.com/openwdl/wdl 1. https://github.com/chanzuckerberg/miniwdl https://github.com/chanzuckerberg/miniwdl 2. https://github.com/broadinstitute/cromwell https://github.com/broadinstitute/cromwell
- ablekh 7y agoI appreciate your clarifications. Until now, I was aware of [0], but not [1] and [2]. Your implementation seems be much more popular than both the new alternative and a reference implementation. The (general and scientific) workflow engines universe is very large - it likely contains, at least, dozens of production-level implementations. Such diversity is both a blessing and a curse, though ...