3 ms·

> For complex, specialized systems what I'm often seeing is that essentially every decent large system gets split into a de-facto domain specific language Ever

> For complex, specialized systems what I'm often seeing is that essentially every decent large system gets split into a de-facto domain specific language Every time I've seen this, it's been a disaster. Custom DSLs for business logic are, 100% of the time, a red flag of a development process gone off the rails. (We may work in different industries.) Go prevents you from doing this at a very low level. This is a huge advantage.

PeterisP 7y ago
If you're writing a React or Django or Laravel or Rails app, then what you're doing is essentially work within that DSL which is quite different from the underlying Javascript/Python/PHP/Ruby language. The same goes for data analysis frameworks such as Pandas, or deep learning such as Tensorflow or Keras - if you're working in that most of your code and calls are going to be within that API/DSL, not "pure" Python. And I'd definitely consider all of the abovementioned as successes and a good thing - if Go would prevent people from writing their Web-CMS systems in a good Web-CMS framework/DSL, or writing their machine learning systems in a good ML framework/DSL, then that'd be a serious limitation. And it's worth noting that many (all?) of these particular systems were actually initially made as custom DSLs for internal use within a single company - Rails for 37signals/Basecamp, Pandas for AQR Capital Management, Django for Lawrence Journal-World, Tensorflow by Google Brain, etc. They were the exact thing that you describe - a custom DSL invented for the business logic that the particular company needed repeatedly. And they were not a disaster but the right thing to do in their case - mostly because they had the ability to make a somewhat good DSL though in all those cases it was an 'okayish' DSL initially and became good only through years of substantial changes. Yes, for every such case there are many bad internal DSLs. "Not Invented Here" is a common problem. You need to ensure that you're using good DSLs, and good DSLs generally gain wide adoption within that domain instead of every company building their own shoddy DSL. I've seen a bunch of nightmarish financial systems with horrible DSLs. However, even in that case the DSL problem was that this DSL was horrible not that a DSL shouldn't have been used - any fix or rewrite would generally require replacing it with a better DSL/framework/whole-encompassing-structural-API/whatever, instead of sticking to the core programming language (which would just result in another emergent "DSL" of some core libraries/classes, which would be lousy compared to something you intentionally design to be usable).
- orbifold 7y ago
  I would say most of the examples you mentioned are actually examples of well implemented libraries, with well named methods and abstractions, rather than DSLs. If you want to imply that a good large codebase is similarly structured into libraries of independent components rather than one big class hierarchy then I would agree.
  - PeterisP 7y ago
    I'm probably trying to make a point that when writing code to a large domain-specific library or framework, at a certain level of intensity of coupling it de facto becomes a DSL. You're writing code using "primitive" data types, data structures and functions specific to that DSL instead of the data types of your core language; the control flow and data flow is not the same as in your core language but determined by that framework. The differences between programming languages are smaller than the differences between DLS's implemented in the same language. Code in Rails (Ruby) and Django (Python) has more in common than code for Django and Pandas. Writing Tensorflow code in Python is somewhat similar to writing TensorflowJS code in Javascript, but very dissimilar to writing Pytorch code that does the same thing. They're not really independent libraries, they're frameworks that suggest, influence and sometimes even mandate most of the infrastructure around your code and the structure of your code in a much more stringent manner than the core language does. There's a fundamental difference between making a few calls to a black box library versus having the content and style of most of your code being dominated by the traits of that "library" - the large frameworks overwhelm the small(ish) core languages. So I believe it's justifiable to consider the frameworks I mentioned as DSLs.
jimbokun 7y ago
As PeterisP mentions, TensorFlow is an example of a massively, unequivocally successful DSL, which really wouldn't be possible with Go.

PeterisP 7y ago

If you're writing a React or Django or Laravel or Rails app, then what you're doing is essentially work within that DSL which is quite different from the underlying Javascript/Python/PHP/Ruby language. The same goes for data analysis frameworks such as Pandas, or deep learning such as Tensorflow or Keras - if you're working in that most of your code and calls are going to be within that API/DSL, not "pure" Python. And I'd definitely consider all of the abovementioned as successes and a good thing - if Go would prevent people from writing their Web-CMS systems in a good Web-CMS framework/DSL, or writing their machine learning systems in a good ML framework/DSL, then that'd be a serious limitation. And it's worth noting that many (all?) of these particular systems were actually initially made as custom DSLs for internal use within a single company - Rails for 37signals/Basecamp, Pandas for AQR Capital Management, Django for Lawrence Journal-World, Tensorflow by Google Brain, etc. They were the exact thing that you describe - a custom DSL invented for the business logic that the particular company needed repeatedly. And they were not a disaster but the right thing to do in their case - mostly because they had the ability to make a somewhat good DSL though in all those cases it was an 'okayish' DSL initially and became good only through years of substantial changes. Yes, for every such case there are many bad internal DSLs. "Not Invented Here" is a common problem. You need to ensure that you're using good DSLs, and good DSLs generally gain wide adoption within that domain instead of every company building their own shoddy DSL. I've seen a bunch of nightmarish financial systems with horrible DSLs. However, even in that case the DSL problem was that this DSL was horrible not that a DSL shouldn't have been used - any fix or rewrite would generally require replacing it with a better DSL/framework/whole-encompassing-structural-API/whatever, instead of sticking to the core programming language (which would just result in another emergent "DSL" of some core libraries/classes, which would be lousy compared to something you intentionally design to be usable).

orbifold 7y ago
I would say most of the examples you mentioned are actually examples of well implemented libraries, with well named methods and abstractions, rather than DSLs. If you want to imply that a good large codebase is similarly structured into libraries of independent components rather than one big class hierarchy then I would agree.
- PeterisP 7y ago
  I'm probably trying to make a point that when writing code to a large domain-specific library or framework, at a certain level of intensity of coupling it de facto becomes a DSL. You're writing code using "primitive" data types, data structures and functions specific to that DSL instead of the data types of your core language; the control flow and data flow is not the same as in your core language but determined by that framework. The differences between programming languages are smaller than the differences between DLS's implemented in the same language. Code in Rails (Ruby) and Django (Python) has more in common than code for Django and Pandas. Writing Tensorflow code in Python is somewhat similar to writing TensorflowJS code in Javascript, but very dissimilar to writing Pytorch code that does the same thing. They're not really independent libraries, they're frameworks that suggest, influence and sometimes even mandate most of the infrastructure around your code and the structure of your code in a much more stringent manner than the core language does. There's a fundamental difference between making a few calls to a black box library versus having the content and style of most of your code being dominated by the traits of that "library" - the large frameworks overwhelm the small(ish) core languages. So I believe it's justifiable to consider the frameworks I mentioned as DSLs.

jimbokun 7y ago

As PeterisP mentions, TensorFlow is an example of a massively, unequivocally successful DSL, which really wouldn't be possible with Go.