3 ms·

At some point--well before Java--sufficiently constrained syntax turns your DSLs into libraries, which tend to be less close in design to the given domain than

by tikhonj 14y ago

At some point--well before Java--sufficiently constrained syntax turns your DSLs into libraries, which tend to be less close in design to the given domain than actual DSLs. Put another way: with Java or Python, you coerce your problem domain to fit the language. With Lisp and Haskell, you coerce the language to fit the problem. I personally like the latter approach, but I suspect it's also a matter of preference.

debacle 14y ago
It's a matter of maintainability. For the startup scene, the latter provides faster development, more flexibility, and a more intuitive codebase. When you reach corporate scales, convention needs to aid in the grokking of the codebase. I greatly prefer JavaScript in a functional style when I'm coding for myself, because I know the code in and out, but I prefer something more like C# when working on a team because then at least there is a set of more strict conventions we have to adhere to.
- swift 14y ago
  While conventions are useful, different conventions are appropriate for writing different kinds of code, and one should use the right tool for the job. Understanding code written in a functional style is something a good developer should be able to do for the same reason that recognizing design patterns in use is something a good developer should be able to do.
- tikhonj 14y ago
  I think which one is more maintainable also depends on the makeup of your team. If it's primarily a bunch of Java/C# programmers, than the former style is best. On the other hand, if you have a set of string programmers and a bunch of domain experts, the DSL style is not only faster but wait to maintain. Your core programmers should be good enough to deal with both the host language and the DSL with no difficulty, and your domain experts need only to understand the DSL, which could be easy since it's already optimized for their domains. I've certainly read about this approach being very successful with Haskell at a bank. More generally, core logic should be easier to understand and maintain with a DSL. Perhaps this makes it harder to extend or repurpose the DSL without a good understanding of the host language and the codebase, but it makes working within the domain much easier, and makes it simpler to verify that the code is correct in regards to the specific domain. Also, Javascript is not the best language for embedding DSLs; while it's not horrible, the syntax is inflexible and the semantics are somewhat limiting.

by tikhonj 14y ago

debacle 14y ago

It's a matter of maintainability. For the startup scene, the latter provides faster development, more flexibility, and a more intuitive codebase. When you reach corporate scales, convention needs to aid in the grokking of the codebase. I greatly prefer JavaScript in a functional style when I'm coding for myself, because I know the code in and out, but I prefer something more like C# when working on a team because then at least there is a set of more strict conventions we have to adhere to.

swift 14y ago
While conventions are useful, different conventions are appropriate for writing different kinds of code, and one should use the right tool for the job. Understanding code written in a functional style is something a good developer should be able to do for the same reason that recognizing design patterns in use is something a good developer should be able to do.
tikhonj 14y ago
I think which one is more maintainable also depends on the makeup of your team. If it's primarily a bunch of Java/C# programmers, than the former style is best. On the other hand, if you have a set of string programmers and a bunch of domain experts, the DSL style is not only faster but wait to maintain. Your core programmers should be good enough to deal with both the host language and the DSL with no difficulty, and your domain experts need only to understand the DSL, which could be easy since it's already optimized for their domains. I've certainly read about this approach being very successful with Haskell at a bank. More generally, core logic should be easier to understand and maintain with a DSL. Perhaps this makes it harder to extend or repurpose the DSL without a good understanding of the host language and the codebase, but it makes working within the domain much easier, and makes it simpler to verify that the code is correct in regards to the specific domain. Also, Javascript is not the best language for embedding DSLs; while it's not horrible, the syntax is inflexible and the semantics are somewhat limiting.