4 ms·

I think one of the benefits of features, rather than libraries, is that someone can be expected to know what it does. In C#, ?? should be understood by anyone

by req2 17y ago

I think one of the benefits of features, rather than libraries, is that someone can be expected to know what it does. In C#, ?? should be understood by anyone who knows C#. In Smalltalk, ?? will be understood by the implementer and then need to be explained or learned by every fresh set of eyes. (Yes, they might expect it mirrors C#, but the problem still exists. The eyes know Smalltalk, not C#.) It is similar to the situation in http://www.37signals.com/svn/posts/1729-coding-style-helpers-that-return-params http://www.37signals.com/svn/posts/1729-coding-style-helpers.... link_to, easily understood, rss_link, not quite sure.

shiro 17y ago
In theory, if the feature provided by the library is very important (apparently it is important enough for C# implementors to build it in the language), you can expect that the library will eventually becomes standard or quasi-standard. For any language, its programmer is expected to learn not only the language features but also standard libraries, so eventually the difference of "knowing" part will be leveled out. In practice, there are two factors that work in opposite directions, and which factor you're looking at changes pros and cons of language feature vs. library discussion. * Time difference - for language features you have to wait until implementors implement them. For libraries you can start immediately. That gives you time advantage, sometimes for as much as years. * Pressure difference - to make it standard language features there are lots of pressures to make it right, and effort is taken accordingly. Similar amount of effort is needed to make a library feature into standard position. But for those who wrote that library feature in the first place, usually their need is fulfilled easily, so there may not be enough incentives for them to push the feature into standard. I feel the time advantage the 'library' approach gives me is crucial, so I prefer flexible languages (specifically I use Scheme). But in this side I do see the effect of the latter---there are tons of libraries, each of which is "good enough" for a specific circumstance but a bit short to be truly general, reliable solution.
stcredzero 17y ago
In Smalltalk, if you're curious about ??, you'd be able to find it instantly, and read the method. As you know from the article, it's fairly short and would be obvious to a competent Smalltalker in seconds. If that's not enough just take a second to type in nil ?? [ self halt ] And right-click "Debug-it." Debugging in VisualWorks is so painless, people actually write code in comments for people to understand by debugging -- and people will even follow it while in another debugger session! (And even doing that a 2nd, 3rd time is just as easy!) To heck with comments or API docs, you can see how everything works and tinker with it! Your division between access by the implementer vs. the "fresh set of eyes" is a misconception you're taking from C#. There is nothing in Smalltalk that demarcates the "implementer" from the regular programmer. It's "Turtles all the way down!" You can actually implement a debugger as an ordinary Smalltalk app, and in 5 minutes, you can be browsing a stack. There is little difference between programming and meta-programming. In other words, Meta-programming is easy and natural, not esoteric. You just see Smalltalk as a funny sort of Blub where no one knows what the language/library will look like, because you see things in terms of the programming you know: Blub. Take it from me, I've been to dozens of Smalltalk shops over a decade: this is not a problem. It's sometimes a huge advantage! One can create very powerful domain-specific languages and tools this way.
ralph 17y ago
One of the things that distinguishes a good programmer from your average one is a detailed knowledge of the language's standard libraries, even if they're de facto standard ones. How many times have we seen C that re-implements memrchr(3) or strcspn(3), often with bugs.

by req2 17y ago

shiro 17y ago

In theory, if the feature provided by the library is very important (apparently it is important enough for C# implementors to build it in the language), you can expect that the library will eventually becomes standard or quasi-standard. For any language, its programmer is expected to learn not only the language features but also standard libraries, so eventually the difference of "knowing" part will be leveled out. In practice, there are two factors that work in opposite directions, and which factor you're looking at changes pros and cons of language feature vs. library discussion. * Time difference - for language features you have to wait until implementors implement them. For libraries you can start immediately. That gives you time advantage, sometimes for as much as years. * Pressure difference - to make it standard language features there are lots of pressures to make it right, and effort is taken accordingly. Similar amount of effort is needed to make a library feature into standard position. But for those who wrote that library feature in the first place, usually their need is fulfilled easily, so there may not be enough incentives for them to push the feature into standard. I feel the time advantage the 'library' approach gives me is crucial, so I prefer flexible languages (specifically I use Scheme). But in this side I do see the effect of the latter---there are tons of libraries, each of which is "good enough" for a specific circumstance but a bit short to be truly general, reliable solution.

stcredzero 17y ago

In Smalltalk, if you're curious about ??, you'd be able to find it instantly, and read the method. As you know from the article, it's fairly short and would be obvious to a competent Smalltalker in seconds. If that's not enough just take a second to type in nil ?? [ self halt ] And right-click "Debug-it." Debugging in VisualWorks is so painless, people actually write code in comments for people to understand by debugging -- and people will even follow it while in another debugger session! (And even doing that a 2nd, 3rd time is just as easy!) To heck with comments or API docs, you can see how everything works and tinker with it! Your division between access by the implementer vs. the "fresh set of eyes" is a misconception you're taking from C#. There is nothing in Smalltalk that demarcates the "implementer" from the regular programmer. It's "Turtles all the way down!" You can actually implement a debugger as an ordinary Smalltalk app, and in 5 minutes, you can be browsing a stack. There is little difference between programming and meta-programming. In other words, Meta-programming is easy and natural, not esoteric. You just see Smalltalk as a funny sort of Blub where no one knows what the language/library will look like, because you see things in terms of the programming you know: Blub. Take it from me, I've been to dozens of Smalltalk shops over a decade: this is not a problem. It's sometimes a huge advantage! One can create very powerful domain-specific languages and tools this way.

ralph 17y ago

One of the things that distinguishes a good programmer from your average one is a detailed knowledge of the language's standard libraries, even if they're de facto standard ones. How many times have we seen C that re-implements memrchr(3) or strcspn(3), often with bugs.