The current discussion about SmalltalkImage current vs Smalltalk etc., has reminded me of a previous discussion of a few years few years ago on vm-dev.
I had run across the following very confusing naming conventions while attempting to compile a vm and I posted some comments:
>I was rooting around everywhere learning where things happened and it being the first time through, I was initially confused by the following:
>
>internal plugin B3DEnginePlugin generated as Squeak3D
>internal plugin BalloonEnginePlugin generated as B2DPlugin
>internal plugin BitBltSimulation generated as BitBltPlugin
>internal plugin DSAPlugin generated as DSAPrims
>internal plugin DeflatePlugin generated as ZipPlugin
>internal plugin FFIPlugin generated as SqueakFFIPrims
>internal plugin KlattSynthesizerPlugin generated as Klatt
>internal plugin LargeIntegersPlugin generated as LargeIntegers
I was told more or less that it was because of backwards compatibility that this ongoing source of confusion is allowed to continue.
I responded in part with the following:
At 7:45 PM -0600 5/6/07, Ken G. Brown apparently wrote:
> It seems to me that back compatibility is most often a big anchor on moving forward. Those that want/need back compatibility are always free to stay in the past with whatever version they last had. In the long term, if compromises are always made in the direction of back compatibility, I think that the overall quality of the system is of course, 'compromised'.
>
>Similarly, if decisions are always made in the direction of 'the simplest thing that could possibly work', in the long run you end up with bunch of stuff that perhaps only 'simply' works. This 'simplest thing' idea is great for prototyping or testing out ideas, but one needs to always remember to go back and clean up after.
>
>Perhaps a better rule of thumb is 'doing the best thing in the best possible way'. The semantics can be argued forever tho.
>
>And since I seem to be on a roll here, if you always buy cheap tools, in the long run you end up surrounded with a bunch of cheap junk that when you really need to get a job done, the tool either breaks or does a crappy job.
>
>And if you always patch things instead of repairing properly, pretty soon you are surrounded with patched stuff everywhere, all on the verge of failure.
>
>Yeah, yeah, I know, need to define 'repair properly', 'best thing', 'best possible way', etc.
I think that backwards compatibility should take second or third place in the current discussions about SmalltalkImage current vs Smalltalk.
I am of course not advocating breaking things for frivolous reasons, especially if there are good alternatives available.
However, for important decisions moving forward, I AM advocating 'doing the best thing in the best possible way', to the best of our abilities.
Ken G. Brown
Locked
