Smalltalk Tidbits, Industry Rants

A more detailed exposition of where you disagree with the authors would be nice. Isn't the Meijer/Drayton paper trying to bridge the divide by pragmatically adopting what form of type checking is necessary at any given point instead of taking absolutist positions?

Logical impossibility to make a language more powerful by omitting features?

I guess that's the reason why English has been adopted as de-facto world language, despite having far fewer features than French (once the language of engineers), German (once the language of philosophers), or any of the Slavic languages (my native Czech has been called the language of poets). Oh, and don't forget Latin, the most expressive and feature-full language of them all - it's so powerful, everybody speaks it today.

Backward conclusions, indeed.

For sake of argument, let's accept that these statements about English, and French, and ... are true.

They argue that English is more popular than... not that it is more powerful

So they have nothing to say about whether "it is a logical impossibility to make a language more powerful by omitting features"

XCheck is delving into false analogies. Its mighty odd to compare a natural spoken language with a programming language and try to apply the conclusions drawn from the latter to the former. This is the age old square IS-A rectangle debate that has been beaten to death in the OO community.

"the number of those errors I've seen in a runtime image is a really small number - 2 that I can recall"

Perhaps you are simply forgetful

As an example of the kinds of errors that sneak through to production, we could just look at a Cincom Smalltalk fix list (of course as product manager you'll see a lot of these)

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3268381755

At minimum 5% (and at most 15%) of those problems could have been detected by unsophisticted static type checking

Comment by James Robertson

Two things:

• I was speaking of my own code, stuff I've written over the last decade+ I can recall two actual type errors that hit a runtime
• I didn't wander through that list in detail, but it doesn't look to me like too many would have been caught by manifest typing

"speaking ... stuff I've written over the last decade+ ... runtime"
Have you been a professional Smalltalk developer for the last decade+?

By "two actual type errors that hit a runtime" do you mean errors that made it through testing to production, and then gave runtime errors in production?

"doesn't look to me like too many would have been caught by manifest typing"
15% isn't many
You'd get to 2 just on mis-spelt methods...

Comment by James Robertson

Whether I've been a "professional" developer for the last few years (since 1992) depends on how you want to classify it. I started as a Smalltalk consultant/trainer at Booz, Allen and Hamilton, and then moved to ParcPlace. I spent time there as a trainer, a consultant, and a sales engineer. I spent a lot of time in client shops diagnosing problems and fixing them.

I've written a lot of code over that time, and I've shipped two decent size products in the last few years - BottomFeeder and Silt.

"There was a server error accepting your comment. Try enabling cookies"
They are enabled, and they were good enough to post a comment earlier today - maybe a problem? (posted with IE)

"Whether I've been a professional..."
I phrased that badly, all I meant was doing Smalltalk development 8x5x300

Perhaps you meant that you could recall 2 "actual" type errors in Silt and BottomFeeder?

Perhaps for you, an "actual" type error has a very narrow meaning.

For me, if I can make the type system trap an error then that error is a type error.

Comment by Alan Knight

That article seems to have been quoted an awful lot lately for being so lame. I found it amusing to see the "parroted literally" phrase, immediately followed by a literal parroting from an article, whose point is not actually argued either in this paper or in the one quoted. Further, the statement is one I would consider thoroughly unjustified, at best a tautology. It's a tautology if we take the only rigorous definition of programming language power that I know of, Turing completeness. In that case it is for almost all features impossible to either increase or decrease power by adding or removing language features. For a more informal definition of power, it would be instructive to consider the features of Malbogle. If it is impossible to increase this vague "power" by removing features, then as a corollary it is impossible to decrease the same "power" by adding features. So by adding features of Malbogle to our favourite programming language, we do not diminish its power. Now, since said language presumably retains the ability to initialize memory, it wouldn't be nearly as difficult to program in, but I think it would be difficult to argue that those features had not diminished its power.

Even using the original example, removal of assignments, that hardly seems to me like the sort of argument that can be blithely dismissed without justification. I think you would find plenty of people in the functional programming community willing to argue that removal of assignment does in fact increase power. You could find plenty of people to argue the other way too, but that's what makes it a statement that requires justification, not one that you can claim to "argue", but then just assert without evidence.

The fact that people are willing to go on about the applicability or inapplicability of analogies rather than exploiting the power of the phrase "logical impossibility" just seems to demonstrate how regrettably poor the programming community is at applying logic to its own choices. The authors of the paper at least are open about attempting to be more provocative than rigorous. I guess that makes it sort of an academic troll.

Yes, on occasion it can be interesting to think about what audience the writer may have in mind, and what they want that audience to understand.

If nothing else at least it's a change from knee-jerk criticism - which has come from both static typing advocates and dynamic typing advocates :-)

Alan Kay opined on pop culture in this ACM Queue interview

"In the last 25 years or so, we actually got something like a pop culture, ... I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture. ... There are just two different worlds, and I don't think it's even that helpful for people from one world to complain about the other world - like people from a literary culture complaining about the majority of the world that doesn't read for ideas. It's futile."

"Isn't the Meijer/Drayton paper trying to bridge the divide by pragmatically adopting what form of type checking is necessary at any given point instead of taking absolutist positions?" - Dilip.

Ah NO

I get the impression with these type of "static vs dynamic" debates that the "static typing" camp have never developed in a dynamically typed language. I'd be interested to know if anyone reading this, who after having developed a project in a language like Smalltalk, actually prefers static typing.

It may just be so that Isac and Dilip are helping to make my point. Smalltalk (as an example of a dynamically typed language) may not be the most popular, but most people think that it is so because it's less powerful that, say, Java. Well guess what - Smalltalkers tend to come from using other languages first, so they actually CAN compare and appreciate the power they get from a dynamically typed language. I have yet to see someone who actually KNOWS and HAS USED EXTENSIVELY a dynamically typed language to switch to a statically typed one and say 'I like it'. Most statically typed languages have strong vested interest behind them - it's the power of the vendors, not the power of the language that matters in the marketplace (unfortunately). As far as analogies go - no question that computer languages are more formal than natural languages, but both kinds serve essentially the same thing - to communicate something from one entity to another (programmer->computer, writer->reader, speaker->listener). You can be computer science propeller-heady about it, or you can see it on a more philosophical level. I prefer the latter. I agree that the popularity or power of a language (computer or natural) say nothing about whether "it is a logical impossibility to make language more powerful by omitting features". It's the kind and quality of features that matter, not the quantity. The statically typed crowd still seems to be missing the point on that.

"I'd be interested to know if anyone reading this, who after having developed a project in a language like Smalltalk, actually prefers static typing. " HMM - I've programmed for many many years in just about every sort of language - including many static languages - my current favorite being of course ruby. I will say - I enjoy coding in ruby - it's really fun and you can do some amazingly neat and twised things. First - on the paper - I thought it was funny - but I understand why the "dynamic people" didn't like it - because it's not even close to a middle ground. We all expect dynamic features in our strongly typed languages - so it was just a paper supporting strong typing ;) But to the comment - can anyone who's had experience really prefer strong typing? YES Why? I still think a lot of people using dynamic languages are dealing with small systems with limited developers - or have one hell of a documentation standard. Because I always come back to the point - every single day of my professional life ( which has been now more than 15 years as an architect or technical lead) I have had to use or deal with code that someone else in an organisation has written. If I am presented with a function: PrintEmployeeDetails theEmployee, PrintDetails, PageInformation and that's all the information I have. HOW ON EARTH DO I USE IT? Do I have to look at the code, and see oh - on line 21004 it's calling a function on the page infromation variable called NumberOfLines, so I've gotta pass in something that has a NumberOfLines function, and the function it calls on line 18000 which is in this other file asks for a value called PrinterType - so I must fulfil that etc etc etc And within about 2 hours of seeing the function, I understand it and am ready to use it. In fact, any time using a dynamic language, I spend almost aLL my time searching for information Whereas in a typed language, I can see that it takes an EmployeeType, a PrintDetailsType, and a PageInformationType. Hitting control-space on one of those tells me what I need to do to create it. So within about 8 seconds of seeing the function, I'm ready to use it without understanding it. But wait you say! The functions will be documented. [yeah right, and I'm the queen of sheba] however - let's think about that. How DO we make the function useful? We document it. What would be useful to document about it? hmm.. what it does is worth a quick mention, but you can sort of see that from the name. The only thing that really makes sense is to document what you need to pass it. Let's make a quick note about what should be passed in - and what traits that should have.. uh oh. We just built an Interface. gee.. and lets think a bit more. If we've got it down on paper anyway - why not write a computer program to actually check that people are using it correctly - yeah - that's an idea, that would help, because then people will make less mistakes, and don't have to waste as much time on trial and error. yeah.. that's a good idea. I really want to know if anyone out there has really written a real production system in a dynamic language - by that, have you worked on a system that required more than about 16 programmers, and more than a few years of development, and had to be installed on at least 200 client machines? (so you have time for all the people who actually knew anything about the system to go away)

Comment by James Robertson

A few things:

• I spent a number of years in C. Having the declared types didn't help as much as you might think in being able to use a function. I spent a lot of time printing out code - I've yet to print out any Smalltalk code for my own use
• I spent lots of time looking over other people's C code - the types didn't help my understanding any. I've looked at tons of Smalltalk code. Even badly written Smalltalk (except in the worst cases, and yes, they exist) is easier to grok than well written C.
• Read up the comment stream and you'll see Kapital mentioned - a rather large, long lived system at JP Morgan. There are plenty of other examples - check our website for a few examples.

XCheck wrote: "yet to see someone who actually KNOWS and HAS USED EXTENSIVELY a dynamically typed language to switch to a statically typed one and say 'I like it'"
People will always surprise - there's always someone with a different view :-)

I've programmed fulltime with various Smalltalks for ~10 years.
And I switch to Clean and Oberon-2 (and Nice and...) - and I like it!

Smalltalk is a great tool, and Clean is a great tool, and Oberon-2 is pretty good, and ... Lua is neat and ...

Darren wrote: "using a dynamic language, I spend almost aLL my time searching for information"
You're describing a difference between the editing tools you have available. There have been powerful Lisp and Smalltalk IDEs for 25-30 years - my ignorant assumption is that IDEs for Ruby and Python and... are still primitive compared with those old tools.

Darren wrote: "I really want to know if anyone out there has really written a real production system in a dynamic language"
Of course :-)

For the sake of variety:

• AOL runs on AOLserver which is written in the dynamically type checked language Tcl.
• Ericsson's AXD 301 ATM Switch control system is mostly written in the dynamically checked language Erlang (well worth a look).
• etc etc

ok - first, you keep mentioning C - as pointed out above - C isn't a good example of ANYTHING - it was ALWAYS a bad language, and always will be. c#, delphi, even Java can be used as comparisons - but please, not C. My point still remains - but I'll change the tone - I'm less trying to argue a point [it's been done to death] - and more up to that point of asking a question. If I'm in C#, and someone yells across to me - "I've finished the credit card processing module", I can click [control space] - select the new "creditcards" from the menu. Click . and see the function Process, type open bracket and see that I need to pass a number as a string, and expiry date as a MonthYear. I move up a line and type new MonthYear open bracket, and see that it takes a month, year - I fill them in from what I have, move down, hit comma and see the last bit is a cid - put my cid var in, and close the bracket - I see that it returns a credit card validationResult. On the next line I type validationResultWas . and see the that there is a "Success" flag. I type the line if (validationResultWas.Success) Save() else ShowUserTheErrorMessage( "Something went wrong"); I hit compile, and if it compiles.. It will work I guarantee it. I really don't understand, and don't want to argue, I want you to educate me - how can I do the same thing in a dynamic language AS QUICKLY. Because that's all it really comes down to. And the above I could do without moving a mouse, without clicking away from where I am, without looking at a different menu, without reading ANYTHING - literally the work of seconds - just selecting things off menus. I don't understand how a dynamic language can compete, because no one, including the compiler, has the information needed to create those menus - and if you HAVE created that information somewhere in documentation - you've just created a type - with all the work without any of the benefits.

Comment by James Robertson

Darren, you say:

I hit compile, and if it compiles.. It will work I guarantee it. I really don't understand, and don't want to argue, I want you to educate me - how can I do the same thing in a dynamic language AS QUICKLY

First off, no, there's no guarantee that compiling means it will work. If you think that's true... well, I think you should look up NUnit for .NET, and the equivalent for other systems.

Second, in Smalltalk, you right click on a selector listed in the browser, and look for senders, or implementors, or senders/implementors of any message sent in that method. You can limit that search to the current hierarchy as well.

Since most methods are 7-10 lines long, and don't invoke many methods, such searches are simple, and since it's all in memory, they are very fast.

"There was a server error accepting your comment. Try enabling cookies."
I just successfully posted a comment using IE6 and attempting to post another comment a few minutes later (again using IE6) failed - I haven't changed any settings, so there seems to be "a server error".

Comment by James Robertson

There's no server error - there's a throttle. Any comment from the same IP address within 3 minutes of the last one will fail.

"Any comment from the same IP address within 3 minutes of the last one will fail."
It would be helpful to clearly state that restriction on the "add comment" page (and the current error message is misleading).

Darren wrote: "do the same thing in a dynamic language AS QUICKLY. Because that's all it really comes down to"
No, that really isn't what it all comes down to - but this is an excellent illustration of what fuels these endless disputes.

We all mostly use one language at a time, we become adept at the best techniques for solving problems with that language, and when we look at some other language we ask how well it supports those same techniques - that's simply the wrong question.

It doesn't matter that (for sake of argument) it's 2x faster to find a method name with static when dynamic needs (for sake of argument) 10x less code.
The difficulty is finding an honest broker who can say that after using the very different best practices for some particular static and dynamic languages their experience was that one was dramatically more effective than the other for some specific problem domain.