4 ms·

And it's fun for novice programers to implement this kind of overenginered specialized turing complete language... Until one has been burned by one, it's very e

by gommm 15y ago

And it's fun for novice programers to implement this kind of overenginered specialized turing complete language... Until one has been burned by one, it's very easy to be lost in overarchitecturing and be very happy with one's own cleverness. When I look back at the projects I started, way back when I started programing, they all tended to have this characteristic and were completely unmaintainable (which is why they were never finished)

michaelfeathers 15y ago
I've seen a very bad case of this that was a direct result of the 'second system effect'. The devs were told that they could have a re-write, but it would be the last re-write, so everything became configurable.
mhw 15y ago
And I spent quite a bit of my early years as a team lead dragging novice programmers back off the slippery slope of the configuration system. You can tell someone's edging out onto the slippery slope when they extract things out of the source code and into a configuration file. Then they realise they need to expose values from the runtime environment into the configuration file, so you get symbolic values added to the language. From there it's a short slide to implement expression evaluation and conditionals (one usually comes before the other, but they fit together so well that I've never seen someone fail to implement both 'to cover future scenarios'). A lot of configuration systems reach a complexity maximum at this point, where the ability of the implementor (or their memory of the compiler construction class) runs out before their ambition for their configuration language does. Some particularly resourceful individuals press ahead regardless though and find a way out of this sticking point. At this point they will often also separate their configuration system out into a library so that others can gain the benefits of a poorly thought-out programming language being embedded directly into their software. For some companies, the configuration library would be the only reusable component shared between different applications because the guy who wrote it was the one everyone else looked up to. The other route out of this sticking point came through the trendiness of XML and the availability of general purpose XML parsers. This meant that not knowing how to build a proper parser (with decent error messages and such like) was no longer an obstacle, just as long as you could convince people that writing programs as XML elements was a step forward. XML parsers also turned your configuration file into something similar to an AST (if you made your language look like a serialized AST) so programmers who had never even done the compiler course could stumble across the solution without too much effort. At least configuration files could be checked into some source control system and managed properly. Don't get me started on storing business rules in relational databases...

by gommm 15y ago

michaelfeathers 15y ago

I've seen a very bad case of this that was a direct result of the 'second system effect'. The devs were told that they could have a re-write, but it would be the last re-write, so everything became configurable.

mhw 15y ago

And I spent quite a bit of my early years as a team lead dragging novice programmers back off the slippery slope of the configuration system. You can tell someone's edging out onto the slippery slope when they extract things out of the source code and into a configuration file. Then they realise they need to expose values from the runtime environment into the configuration file, so you get symbolic values added to the language. From there it's a short slide to implement expression evaluation and conditionals (one usually comes before the other, but they fit together so well that I've never seen someone fail to implement both 'to cover future scenarios'). A lot of configuration systems reach a complexity maximum at this point, where the ability of the implementor (or their memory of the compiler construction class) runs out before their ambition for their configuration language does. Some particularly resourceful individuals press ahead regardless though and find a way out of this sticking point. At this point they will often also separate their configuration system out into a library so that others can gain the benefits of a poorly thought-out programming language being embedded directly into their software. For some companies, the configuration library would be the only reusable component shared between different applications because the guy who wrote it was the one everyone else looked up to. The other route out of this sticking point came through the trendiness of XML and the availability of general purpose XML parsers. This meant that not knowing how to build a proper parser (with decent error messages and such like) was no longer an obstacle, just as long as you could convince people that writing programs as XML elements was a step forward. XML parsers also turned your configuration file into something similar to an AST (if you made your language look like a serialized AST) so programmers who had never even done the compiler course could stumble across the solution without too much effort. At least configuration files could be checked into some source control system and managed properly. Don't get me started on storing business rules in relational databases...