3 ms·

> Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision;

by jl6 5y ago

> Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision; it was the best for the problem given the resources and time I had. Are you completely sure you didn’t just create a massive headache for the team that followed you? Now they have to understand something that looks like magic, or pay more money to hire a wizard. I’ve seen a lot of “clever and elegant” solutions that become instant legacy when the original genius leaves, and a lot of “boring and repetitive” solutions that stand the rest of time.

skytreader 5y ago
I feel like the bit you quoted already captures what I think came of it after I turned it over. It is even from a paragraph labeled "Honest negatives". Complete certainty of how it turned out is a bit too much to ask. For every story like mine, there's an equivalent story of a legacy system in boring Java/C that no one wants to touch, works like magic, etc. FWIW, I wrote a pretty extensive documentation of the project before I left, including recommendations for improvement[1]. Again, it's foolish to claim complete certainty but the nature of the project was such that they are unlikely to need to rewrite anything on top of the engine. Any modifications and additions moving forward would be in the declared rules, not in any of the logic. And for that, they have hundreds of examples from me to copy from. And if they do need to touch the "parser", at ~200LoC the complexity is certainly far below, say, a Spring J2EE code base. It's all in one file too, that shouldn't be too bad. [1] If I may use HN as a small soapbox, actually, months later, I figured out a further small addition to that project that would've made working with it far easier. If any of my previous team recognizes this and this project is still in use, feel free to reach out to me for one last brilliant idea. :)
- xpe 5y ago
  Sounds like a useful project. > It's all in one file too, that shouldn't be too bad. Fewer files is not necessarily better. The guiding principle in my mind is reduction of entropy. If splitting one file into multiple files makes sense in the brains of the beholders it is a good thing.
  - robertlagrant 5y ago
    200 lines in one file sounds fine on the face of it. I like it when I don't have to trace through to other files to see what's going on.
erik_seaberg 5y ago
I haven't yet seen a DSL that wasn't a big improvement over compiling the DSL to a bunch of boilerplate in my head and making everyone try to reread the boilerplate forever.

by jl6 5y ago

skytreader 5y ago

I feel like the bit you quoted already captures what I think came of it after I turned it over. It is even from a paragraph labeled "Honest negatives". Complete certainty of how it turned out is a bit too much to ask. For every story like mine, there's an equivalent story of a legacy system in boring Java/C that no one wants to touch, works like magic, etc. FWIW, I wrote a pretty extensive documentation of the project before I left, including recommendations for improvement[1]. Again, it's foolish to claim complete certainty but the nature of the project was such that they are unlikely to need to rewrite anything on top of the engine. Any modifications and additions moving forward would be in the declared rules, not in any of the logic. And for that, they have hundreds of examples from me to copy from. And if they do need to touch the "parser", at ~200LoC the complexity is certainly far below, say, a Spring J2EE code base. It's all in one file too, that shouldn't be too bad. [1] If I may use HN as a small soapbox, actually, months later, I figured out a further small addition to that project that would've made working with it far easier. If any of my previous team recognizes this and this project is still in use, feel free to reach out to me for one last brilliant idea. :)

xpe 5y ago
Sounds like a useful project. > It's all in one file too, that shouldn't be too bad. Fewer files is not necessarily better. The guiding principle in my mind is reduction of entropy. If splitting one file into multiple files makes sense in the brains of the beholders it is a good thing.
- robertlagrant 5y ago
  200 lines in one file sounds fine on the face of it. I like it when I don't have to trace through to other files to see what's going on.

erik_seaberg 5y ago

I haven't yet seen a DSL that wasn't a big improvement over compiling the DSL to a bunch of boilerplate in my head and making everyone try to reread the boilerplate forever.