3 ms·

Hm, so he complains about the impossibility of 'bending a mainstream language to ones will', as in: to make it use a certain feature implicitly, like his transa

by tetha 17y ago

Hm, so he complains about the impossibility of 'bending a mainstream language to ones will', as in: to make it use a certain feature implicitly, like his transaction system. I have to say: This is a good thing, to a certain extend. Take Python, and consider Python's metaclasses (basically classes of classes (of objects)). Certainly, they allow you to do some things easier, but now imagine some Three-star-programmer abuses those metaclasses to subvert the class creation mechanism in nontrivial ways and bases the entire application on these metaclasses (and, of course, does not document this well). If you are supposed to maintain this, you are in trouble. So, my point is: It certainly is fun to have a very dynamic language which can do a lot of things easily, but this is a great power and requires great responsibility and the larger the project will be, the more responsibility is required, and -- being a careful person -- I don't want to assume that everyone touching that gigantic project is responsible and careful enough to handle this well. Thus, I like dynamic languages for my own small projects, but I can understand why those dynamic languages are not mainstream.

ubernostrum 17y ago
And thus was created Java, which deliberately breaks your wrists the first time you use it, just in case you were planning to write bad code.
apgwoz 17y ago
There's no doubt that abuse can happen in a model that allows openness. But, if you're worried about your inferior programmers abusing features of the language, that's a management problem. Do code reviews and hire people that aren't going to abuse the features, but instead use them for enhancement.
- timwiseman 17y ago
  You are completely right, when this is possible. The problem is that it is often not possible. The team lead in charge of actual implementation often has limited control over who is on the team. Even when the team leads have the luxury of chosing their own people, getting the type of people that understand capabilities like that and both can and will document them and refrain from abusing them are hard to find and expensive. Worse, if you need to hire from the outside, it can be very hard to know during a relatively short interview process if you have found such a person. If the lead manages to get such a team together and finish the project, it still needs to be maintained, enhanced, and extended. Gaurunteeing that your entire string of maintainers will be at least good enough to understand not break this beautifully constructed project can be very hard indeed, even if you managed to carefully create documentation at every step and keep the documentation in synch. In short, while a great idea in theory (and sometimes in practice) it may be nigh impossible in practice, especially for a mid sized or larger company.

by tetha 17y ago

ubernostrum 17y ago

And thus was created Java, which deliberately breaks your wrists the first time you use it, just in case you were planning to write bad code.

apgwoz 17y ago

There's no doubt that abuse can happen in a model that allows openness. But, if you're worried about your inferior programmers abusing features of the language, that's a management problem. Do code reviews and hire people that aren't going to abuse the features, but instead use them for enhancement.

timwiseman 17y ago
You are completely right, when this is possible. The problem is that it is often not possible. The team lead in charge of actual implementation often has limited control over who is on the team. Even when the team leads have the luxury of chosing their own people, getting the type of people that understand capabilities like that and both can and will document them and refrain from abusing them are hard to find and expensive. Worse, if you need to hire from the outside, it can be very hard to know during a relatively short interview process if you have found such a person. If the lead manages to get such a team together and finish the project, it still needs to be maintained, enhanced, and extended. Gaurunteeing that your entire string of maintainers will be at least good enough to understand not break this beautifully constructed project can be very hard indeed, even if you managed to carefully create documentation at every step and keep the documentation in synch. In short, while a great idea in theory (and sometimes in practice) it may be nigh impossible in practice, especially for a mid sized or larger company.