Slashdot Mirror

Jini and JavaSpaces are being used in a variety of organizations to build large, distributed, reliable, scalable systems that integrate a wide variety of existing systems, including those written in languages other than Java. The technology seems a good match for this problem.

Patrick

Perhaps you should read this article. It just might change your mind.

Having used TP and DelpiI was kind of disappointed to see Anders join Microsoft a few years back. But now behold .... Delphi 8 adopts quite nicely to .net and is actually giving Borland a new lease on life and delivering where Kylix couldn't.

Having used both java and delphi I allways missed some sort of generics. I found Anders thoughts to be quite interesting. Question: is it possible to change the java generics-implementation in such a way that it would loose the limitations mentioned (and changing the JVM in the process offcourse)?

A little OT, but Artima also has a really good article about the development of new features in Java.

...right here to save you a click thru the MSDN page.

Google turns up one result for an effort in Australia, but I can't find any cost for the system, or a download link. There's also this post about a Python project, which appears to be talking about The Open Voting Consortium, which has a SourceForge project page.

So it seems that there are movements happening, but these don't seem to be getting anywhere quickly. Does anyone know of any other projects?

Thats not correct. The parent poster is reffering to the fact that methods in Python have a argument called self, which you sometimes have to type, sometimes to declare, sometimes not.
I'm well aware of that. But 'self' is not a keyword. If you don't like to type it, use something shorter, say: 's'.
I have no clue what you mean by "declaring" and "sometimes not". It is always there, it can be called differently. And you never declare things in Python.

For the C++/Java folks, self is the equivalent of this. No one likes code like that: self.doThis(); self.doThat();
Except when you have class member 'thing', method argument 'thing', and a local argument 'thing'. In C++ you can also have a global variable called 'thing'. You might argue that it's a bad style, but I've seen codes that do that and play tricks with undescores to sort out the mess. In short, in C++/Java you're allowed to be incosistent: 'thing' and 'this.thing' mean the same, sometimes. Python doesn't have to save keystrokes because it's relatively succinct. I like the 'self' idea because it defines the context for me without looking it up in other places. You don't like it and that's fine with me - that's life.

But how should a class of PYthon 3.0 load a class from Python 1.0 over installatino boundaries?
You just start Python 1.0 as a subbrocess of Python 3.0 process and have a proxy class in Python 3.0 to look like Python 1.0 class that communicates with the subprocess. A page or two of coding.
And why does Python evolve that uncoordinated?
I don't think it can be called uncoordinated - at best you may call the changes too big. The changes go through a well defined process - PEPs. And there is a vote. So in a sense you should blame the majority. Guido only breaks the ties. With Ruby it's Matz's opinion that matters read his opinions in an interview. He hinder Ruby's support for international encondings (see this post).

IMHO it would make sense to define now a Python 7.0, or something. And put everything into it you want, and then let the implementations evolve from the current point towards 7.0. So everyone knows what the final language will look like and kows that the current state is only an interims state.
You've just described what's called Python 3k. The idea has been entertained for a while on Python lists. The problem I have is that I cannot code for something that doesn't exist so I prefer to code for what's out there today. I guess it works for me and it doesn't for you - that's life.

I currently make most of my living programming Java, yet I view it as either C++ for dummies or Python for suites, and either way, it doesn't match the original.

Guido van Rossum noted in an interview the following statistic, and I think it bears considerably on appropriateness:

This [ed: these stats] is all very informal, but I heard someone say a good programmer can reasonably maintain about 20,000 lines of code. Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter. It's still 20,000 lines. If your language requires fewer lines to express the same ideas, you can spend more time on stuff that otherwise would go beyond those 20,000 lines.

A 20,000-line Python program would probably be a 100,000-line Java or C++ program. It might be a 200,000-line C program, because C offers you even less structure. Looking for a bug or making a systematic change is much more work in a 100,000-line program than in a 20,000-line program. For smaller scales, it works in the same way. A 500-line program feels much different than a 10,000-line program

So then, unless you quantify the types of apps you build, the team you use, and the results that are expected, my experience has shown me that most of the time, for business apps, it's overkill. Now, if you're in a dev team at a software company, well then, I could consider the other side.

Sure he did.

Try looking a little harder next time.

First, you CANNOT remove strong typing from Java. It's an object oriented language. Tell me how you do one without the other.

What is small? If you rather would deliver products without bugs, and there is a huge payoff here, you should have a look at Eiffel. It really supports a better style of programming. There are two commercial Eiffel compilers and one Open Source compiler. There must be hundreds of companies using it and thousands of programmers. You ain't gonna get a competitive edge if you use the same language as everyone else.

If you are a startup, you usually don;'t have a second chance. You don't have the luxury of Microsoft or Linux (SSH/sendmail/wu-ftp/...) programmers, who can use C/C++ and get away with buggy or insecure code and patch later. Will the programmers in your company produce better code with C++ than Microsoft does? That's hardly likely. Will they with a pure, clean language that supports Design by Contract?

Take for example the interview with Bjarne Stroustrup:

My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.

That is exactly Eiffel's position. But not only that, it allows you to write that invariant and it will make sure that upon violating that invariant you get an exception. That really helps, instead of having some abstract invariant or precondition that is burried in the documentation and which you only detect when your 500 million dollar rocket has blown up.

And Eiffel is infectious. People who use it and who got its ideas, don't even want to go back to inferior languages.

But for more information see the Eiffel Cetus pages.

Java is not "JAVA" ... it is not an acronym, just a name for a language.

See that's where I differ - I'd rather trade enforced checks for greater productivity - guess that depends on the environment you work in and whether you prefer to hand code or use an IDE.
But for checking, I prefer unit testing. Bruce Eckel makes an interesting argument that compiler checks are just a subset of Unit Testing, in Strong Typing vs Strong Testing.
There's a similar discussion going on at Artima right now with C#'s creator arguing checked exceptions are bad while Java's co-inventor says checked exceptions are good.
Sloppy coding is in the hands of the developer IMO, not the hands of the vendor.

See that's where I differ - I'd rather trade enforced checks for greater productivity - guess that depends on the environment you work in and whether you prefer to hand code or use an IDE.
But for checking, I prefer unit testing. Bruce Eckel makes an interesting argument that compiler checks are just a subset of Unit Testing, in Strong Typing vs Strong Testing.
There's a similar discussion going on at Artima right now with C#'s creator arguing checked exceptions are bad while Java's co-inventor says checked exceptions are good.
Sloppy coding is in the hands of the developer IMO, not the hands of the vendor.

Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.

Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).

Bruce Eckel sums it up best:
"Programmer cycles are expensive, CPU cycles are cheap, and I believe that we should no longer pay for the latter with the former. " from a post by Bruce Eckel on artima.com.

Perhaps people should stop obsessively benchmarking platform VMs, and start benchmarking coding productivity and teamwork, perhaps in Python, with the performance bits in C. For a real-world example, Zope does exactly that: 95% of the code in Zope ends up being done in Python - only the real performance-intensive stuff need be in C... and the stuff done in Python is easy to read, modify, reuse, and tweak (thus, better productivity for both developers that use Zope as and app-server platform well as developers who work on Zope's core).

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

There's a fairly detailed interview with bruce eckel ("famous" guy who has written c++ and java books and sits on the C++ standards committee) at artima on why he likes python (I linked to the last part of the article series, since that contains links to the previous ones).

I think that Alan Kay was way ahead of his time - getting kids to program. I think much like the spreadsheet revolutionized office work by allowing dynamic analysis of data the next big language will be one that is simple enough to allow average office workers to speed up and automate their own work. Abstraction is key.

VBA is being used currently for a lot of that work - but it is truly horrible. Wharton has started teaching its MBA students Python.

Check out what Paul Graham has to say about programming languages in 100 years (basically they won't change much).
http://www.paulgraham.com/hundred.html
And Artima had a discussion on this topic, "After Java and C# - what is next?". http://www.artima.com/weblogs/viewpost.jsp?thread= 6543

Python is definitely not typeless. It's actually strongly typed. But it uses dynamic typing.

Take a look at this article for clarification on typing models.

On Guido's weblog you can read that he's made a wager on parrot's speed:

And let's not forget the opening lightning talk, which I presented together with Dan Sugalski: the Great Python Parrot Challenge. Dan believes that at OSCON 2004, Parrot will be able to execute Python bytecode faster than CPython can. I don't give him a chance. Dan bets me ten bucks, a round of drinks, and a pie at ten paces.

So the power of parrot against the regular python-interpreter-written-in-c. Nice wager, though!

Check out Artima if you want to see Bruce Eckel's take on the Python language which, incidentally, with the addition of things like a logging API, and with long-existing additions like Jython, is beginning to look more and more like a viable competitor to Java.

Why?

Python carries a LOT of the same advantages, but with a dramatically accelerated prototyping and general development speed, and a few tricks of its own. Plus, via Boost, it interoperates with C++, too. I'm an avid Perl hack, but I have to admit that Python, which even has a whole API for basic game programming is looking more and more attractive for quite a number of things.

Download soon and often.

Guido seems to disagree.

GvR: In a strongly typed language, when you change to a different data structure, you will likely have to change the argument and return types of many methods that just pass these things on. You may also have to change the number of arguments, because suddenly you pass the information as two or three parts instead of one. In Python, if you change the type of something, most likely pieces of code that only pass that something around and don't use it directly don't have to change at all.

Now you might be splitting hairs and saying that "static" means known at compile time and "strong" means type errors are always detected, but in common parlance "strong typing" includes static typing. For the pedants, there's Sebesta:

...we define a programming language to be strongly typed if type errors are always detected. This requires that the types of all operands can be determined, either at compile time or at run time.

This criterion is met by very few real-world languages. Most imperative and object-oriented languages include type coercion which contradicts this property. It is interesting to note that future Python development is moving towards still stronger typing -- and, dare I say it -- functional-style constructs.

Of course, the pragmatic thing to do is to understand strong/weak typing not as binary, but as a continuum. In this case, Haskell is more strongly typed than Ada is more strongly typed than Python is more strongly typed than C++ is more strongly typed than C is more strongly typed than FORTRAN. It looks like Python 3.0 will be moving up the chain, however.

It would appear that you are the 'dumbass' since Python is most definitely strongly typed.

Try running this command...
python -c 'print "3"+2'
... and you'll get a type error, it won't automatically cast the 123 to "123". You might find this link useful Strong vs Weak typing.

AFAIK Perl is a variant-bound language and as such isn't strongly typed, although I'm no Perl guru so I could be wrong.

Typing...
perl -e 'print "3"+2'
... does result in 5 suggesting that it is indeed weakly typed.

I do agree that Python is much easier to read than Perl :-)

Andrew

Guido van Rossum: In 1986 I moved to a different project at CWI, the Amoeba project. Amoeba was a distributed operating system. By the late 1980s we found we needed a scripting language. I had a large degree of freedom on that project to start my own mini project within the scope of what we were doing.

Sun would have a better chance surviving if people like Gosling could show Jackpot and its benefits in a BUSINESS CONTEXT.

Artima.com serves a community of developers interested in object and service-oriented architectures and design. At Artima.com, developers can find practical information in articles, interviews, books, links to resources, FAQs, and discussion forums. Our intent is to make Artima.com a place that developers can learn from experts in the software industry as well as interact, share information, and learn from each other. -- About Artima.com

artima.com: "Jim Waldo is a Distinguished Engineer with Sun Microsystems, where he is the lead Jini architect."

Ok... and? How many "lead architects" are there out there? Every hardware manufacture has a lead architect, why is this guy's opinion special enough to be given a article on /.?

Here's a juicier example for Java...

"hi there".equals("cheers !") == true

Not only does Heinz Kabutz demonstrate accessing private members, he shows how one can alter the behavior of interned Java strings!

Have a look at Bruce Eckel's weblog on the subject which points to Bob Martin's thoughts. (Artima seems to be down at the moment, unfortunately.)

The exceptions and formality of Java are supposed to aid development by making sure you've crossed all your t's and dotted your i's when it comes to error handling and type checking. (emphasis mine)

You carefully qualified your statement so I won't lay into you ;-) That is indeed the "strong, static type checking" party line.

An increasing number of smart people are starting to ask questions about that party line though. They'll try out a dynamic language like Python, and the disaster promised by the static typing advocates conspicuously fails to materialize. For two examples of this, see Are Dynamic Languages Going to Replace Static Languages? and Strong Typing vs. Strong Testing. A lot of other people are leaning this way too in newsgroups and on personal weblogs, and of course a lot of people still believe the party line.

Personally, I'm suspicious of "received wisdom" that's much older then 10 or 20 years, as the static typing claims are; the world has changed a lot since then in a lot of ways, not least of which is our improved understanding of how to build things (i.e., even in non-technological ways).

No, php does not work like that. You cannot define two different functions using the same identifier in the same namespace and I imagine this isn't going to change for PHP5. This is a good thing. This makes it absolutely clear which function your code is calling, which vastly improves maintainability.

In addition, php functions can have default arguments, unlike Java. Your example would work like this in PHP:

function foo($a, $b = -1) { ... }

If -1 is a legitimate value for $b (and $b can take on any integer value), you make the $b argument an object with a "set" and "unset" state (Java way) or you simply add another optional argument which specifies whether or not $b is valid (php way). This is not a nasty hack: you see a function call and you can immediately tell which function definition is used without examining any object hierarchy.

In addition, php is dynamically typed, so function overloading makes no sense at all because a function's signature is simply the function's identifier. Look at other dynamically typed languages like Scheme and you will see that they do not implement the type of overloading that you speak of.

There are two reasonable uses of C++-like function overloading: 1. simulating optional arguments, like this person wanted (first hit from google on "Java optional arguments"); and 2. behaving differently based upon the type of the argument, like this:

void foo(int a);
void foo(double a);

You may have been confused by the php5 example on the website:

Class Hello
{
function __call($name, $args)
{
echo "Hello $name!\n";
}
}

This has nothing to do with the C++ or Java notion of "overloading." The word "overloading" means something completely different in each language, and you won't get anywhere if you expect C++-like constructs in PHP.

Unlike Java or C++ or most of the other C-syntax based procedural languages (with the notable exeption of Objective C), PHP has a dynamic run-time type system, which means it can implement dynamic run-time binding. What the php5 __call construct allows you to do is to bind identifiers at run-time. If you've studied Lisp or Scheme, you will understand the power of this. However, from the presentation, I do not see any way to define code at run-time (Lisp's lambda or perl's "sub {...}"), so it won't allow you to do functional programming. What (I believe) it will allow you to do is dynamic binding, like Objective C or Smalltalk. I can't quite figure out why this would be useful in php, however :)

Artima has a couple of recent interviews with Andy+Dave that are worth reading.

I'd be surprised if most people could show you code. If they're working for another company its likely they don't have the /right/ to show you anything.

Its possible to set programming exercises at interview, but only very short ones. Since this was Delphi I guess you could let people use the IDE, but generally it'd just be pen and paper or a simple text editor, to avoid favouring people more familiar with a given IDE.

You might be interested in this article and its followup on how to interview programmers. Some of the panel do talk about asking to see code.

Asking someone to write a bit of code is more something I'd do to a junior programmer, to see if they can cut it at all, because of the small size of the exercise. For senior posts, I'd hope to hear them describe how to solve a problem, being specific about the technologies involved; a demonstration of the breadth of knowledge and problem-solving ability that they'd need to lead on a project.

I'd be surprised if most people could show you code. If they're working for another company its likely they don't have the /right/ to show you anything.

Its possible to set programming exercises at interview, but only very short ones. Since this was Delphi I guess you could let people use the IDE, but generally it'd just be pen and paper or a simple text editor, to avoid favouring people more familiar with a given IDE.

You might be interested in this article and its followup on how to interview programmers. Some of the panel do talk about asking to see code.

Asking someone to write a bit of code is more something I'd do to a junior programmer, to see if they can cut it at all, because of the small size of the exercise. For senior posts, I'd hope to hear them describe how to solve a problem, being specific about the technologies involved; a demonstration of the breadth of knowledge and problem-solving ability that they'd need to lead on a project.

Aside from the usual compiled vs. interpreted divide, a lot of the differences between programming and scripting languages boils down to strong vs. weak typing. A recent Guido van Rossum (of Python fame) interview was a real eye opener for this primarily programming language coder. For instance:

In a strongly typed language, when you change to a different data structure, you will likely have to change the argument and return types of many methods that just pass these things on. You may also have to change the number of arguments, because suddenly you pass the information as two or three parts instead of one. In Python, if you change the type of something, most likely pieces of code that only pass that something around and don't use it directly don't have to change at all.

He goes on to talk about how, as a consequence of this, your scripts are much shorter and easier to read. Of course, one man's flexibility is another man's "coding without a net", but van Rossum makes an important point here that I think gives a huge advantage to scripting languages like Python.

As I mentioned elsewhere in this topic, I ask for registration so that I know who the users are. Even though SuiteRunner is free and open source, I consider it a product. If you check the Artima Newsletter checkbox, you'll be notified of updates to SuiteRunner as well as new articles on Artima.com.

Also, for several reasons we decided to create a web-based discussion forum for SuiteRunner user support rather than using a mailing list. The web forum (I fear this will add weight to your conspiracy theory, but the forum is based on Jive.) requires that you have an account, so by getting an account when you download SuiteRunner, you are ready to post to the SuiteRunner users forum.

On top of that, shouldn't I get points for requiring such a minute amount of information to register? Many times I have been confronted with a long scrolling page full of edit boxes I'm required to fill in. At Artima.com, all I ask for is a name, which you can fake, a nickname, which you can make up, and an email address that I confirm. The name and nickname shows up on forum posts. If you watch a forum topic you get notified by email when someone posts a reply, which is why I confirm the email address even if you opt out of the newsletter.

Interesting that you found the site "flashy." I was going for simple. If you look carefully, you'll see the site is primarily text with a bare minimum of graphics.

Nevertheless, although I incorporated Artima Software a couple years ago, it is still just one person (me). So what you really need to ask yourself is not whether you trust a faceless corporation with your email address, but whether you trust me with it. I assure you I am very concerned about privacy.

I interviewed Martin Fowler, author of Refactoring, last year. In this interview I asked him to define refactoring. He said:

Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.

We didn't refactor JUnit's code, because we didn't start with JUnit's code and make changes. But we did do what I consider a "refactor" of the design. We started in effect with JUnit's API, and made changes. We started with knowledge of what we liked and didn't like about JUnit's API, and refactored that.

Where you can see the refactoring is not in the code, but in the JavaDoc. Compare JUnit's JavaDoc with SuiteRunner's JavaDoc. I'm guessing it was version 3.7 of JUnit that I had in front of me when I decided I would start over. It may have been 3.6.

I interviewed Martin Fowler, author of Refactoring, last year. In this interview I asked him to define refactoring. He said:

Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.

We didn't refactor JUnit's code, because we didn't start with JUnit's code and make changes. But we did do what I consider a "refactor" of the design. We started in effect with JUnit's API, and made changes. We started with knowledge of what we liked and didn't like about JUnit's API, and refactored that.

Where you can see the refactoring is not in the code, but in the JavaDoc. Compare JUnit's JavaDoc with SuiteRunner's JavaDoc. I'm guessing it was version 3.7 of JUnit that I had in front of me when I decided I would start over. It may have been 3.6.

I think I was lucky that I didn't come across his book for a few years, particularly because of his skepticism of MI. I might have followed his advice and my career would have been the worse for it.

Funny, you had the opposite experience that I had. I discovered Scott's book quite by accident when I first started programming C++. It guided me away from multiple inheritance, which I ended up never using until I turned to Java five years later.

To avoid self-aggrandizement, I didn't independently invent the notion of pure abstractions. I had fiddled with Objective-C and it had a construct (whose name I forget) that allowed you to define a pure interface.

Your comment about Objective-C reminded me of something James Gosling once said in one of my interviews. I went to Artima.com and searched for it, but couldn't find it. To my surprise, the comment wasn't in the article anywhere. I went back to the text file that originally came back from the transcriber in 1999, and there was his comment. Somehow it never got published. So I just published it four years after he said it. Sorry.

Like you, Gosling found inspiration for Java's interface from the corresponding construct in Objective-C. Here's what he said in 1999:

http://www.artima.com/intv/gosling13.html

". . .interfaces also have no data. I have come to appreciate that if you use abstract base classes and eliminate any data from them, then a lot of the difficulties of multiple inheritance that I wrote about just go away, even in C++."

You seem to have a somewhat different definition of refactoring than the one Fowler uses in his book on refactoring, in his other writings, and in the interview referenced above.

First of all, adding OLE or CORBA would not be Refactoring. Fowler described it like this:Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.

Secondly, Fowler's book doesn't recommend refactoring for no reason. He has some specific design problems that a developer might see in a body of code they are working on. (a method too long, two classes too tightly intertwined, etc.) In his book, he describes refactoring as being the flip side of design patterns. Design patterns can be used during the design phase to create a good design. Refactoring can be used during the construction phase to become a good design.

Thirdly, the developer who didn't create a good design initially can use refactoring and come up with something better, because there are catalogs of effective refactorings The recipes that define these refactorings describe how to make these changes efficiently and safely without disturbing any more of the code than necessary.

These aspects work together like this. A developer , while coding finds that some problem is impeding their progress. For example, he discovers that every time he makes a change to one class, he discovers that he needs to make a correllary change to another class. He then decides that it fits the description of "Feature Envy", and performs the move method refactoring.

Basically, I see refactoring as a software developers equivalent of building codes. Building contractors don't need to know, or at least calculate out every time, the physics involved to make a structure solid enough to support itself and its contents. The building codes are a distilled instructions of what the physics calculations would indicate as appropriate action (with a bit of a margin of error.) Performing refactorings based on well known, tested, refactorings is using design tips of people who are much better software designers than you are.

As others have pointed out, Perl's garbage collector does lend itself to the circle of garbage problem because it uses reference counting. Could you comment on the tradeoffs weighed when designing the garbage collector? e.g., Efficiency, time to implement, etc. If you could, would you reimplement it so that it used techniques like the Train Algorithm instead?

I have no idea why you say this is academic. You may have heard of Josh Bloch's company, the one he is paid to write APIs for. It's called Sun. Sun are very serious about business and not about being academics.

I consider Josh Bloch's book on Java (Effective Java) to be the best language-specific book on architecture and software engineering I have read. The format is based on Meyer's highly acclaimed Effective C++. Venner's own books are clearly based heavily on his own decades of experience and yet he sees in Bloch's wisdom something which makes software work better for the programmers who have to continue to build it. Also, Gosling, Java's creator says Bloch's book is the only book on Java which he needs. Of course they both work for sun, but there are plenty of other useful books put out by Sun which he could have acclaimed.

Incidently your point is well taken about the sorts of topics you would like to read about. Those topics are linked directly off Venner's site because he writes about them all the time, including in Java World. Venner's article talks about the monkeys on the back of the software developer. The Biggest monkey is the time-to-market deadline moneky.

In my view, time to market is important, but it can't possibly be more important than the fact that when you get to the market, you'd better have something worth selling.