December 12, 13:27
Like most of the advanced OO features available to Java programmers, strong typing is often labeled superfluous by proponents of weakly typed languages, such as PHP.
The argument is the same as that used against interfaces and abstract classes. It's unnecessary language fluff when all you need is common sense programming techniques.
But the problem with "common sense" is that your idea of what that entrails is different than mine. In lack of language support, every programmer is forced to develop his own work-arounds. That makes it harder for programmers to work together (although coding standards can relieve this problem somewhat within a single organization).
Anyway, here's two primary and one minor benefits inhabiting strong typing:
Explicit statements of intent
If you believe that programming is done for "humans first, machines second" then it follows that languages that promote explicit statements of intent are more efficient.
Strong typing is a communication tool for explicit statements of intent backed by the guard of compilation.
Method signatures with strong typing tells you exactly what kind of input they expect and what kind of output they return. And the compiler doesn't allow you to break those rules.
Weakly typing, on the other hand, requires you to be verbose about in- and output requirements in comments and vigilant about checking parameters manually.
Error prevention by failing at compile time
Having the compilation guard ensure that methods aren't exposed to types that doesn't meet their signature requirements. It's about failing fast.
In weakly typed languages, you won't be alerted to programming errors, such as parsing a method a string when it expected an array, before a problem arises at runtime. That's expensively late.
Overloading on type
It's often the case that you want to differentiate method behavior depending on the parameter type passed. Strong typing makes that very easy and simple.
Imagine you have a method that's supposed to act in one way if it's passed an object and another if it's passed a string. The weakly typed solution is having a single method and manually checking the parameter type and then delegating the action. The strongly typed solution does all of that for you.
Challenge by Brian Poulsen on December 12, 14:38
So you put strong vs. weak programming languages up against each other. Seems like David vs. Goliath.
You talk about programming languages (the strong) who needs compiling.
As you write, you get a compiling error if the code is bugged, or a different result than expected is returned. That is of course an advantage. As php (a weak programming language) is parsed on-the-fly, you wont be able to see errors until they appear. That's why you test it as you code it?
I can't see how it'll make it harder for more people to work on the same project. I doubt two people code alike. How I would do one thing in Java, somebody else might not?
Challenge by Martin Mouritzen on December 12, 21:32
Ah yes, the strong vs weak type discussion. Coming from a Perl/PHP background where I later switched to Java and now doing PHP (professionally) again, I know what you mean.
What I like about Java isn't it's strong/weak typing in general, it's more the later benefits. - You can't really quickly "hack up" something in Java as you can in PHP, but the Java way of thinking will save you a lot of trouble later on, and once you get used to thinking more OOP (as Java forces you too) it's easier to re-use code, and also do code maintaining. - Although after doing a lot of programming in Java, I find it easier to do the same in PHP. The downside is off course, as you say, that PHP allows you to do "quick'n'dirty" programming, which potentially makes code updating/maintaining a nightmare - An example: I'm currently developing on the CMS system "PostNuke", which is really a programmers worst nightmare, the code is horrible, and it's really hard to just do small changes, because unlike Java, you can't see dependencies (eg. which part of the system requires other parts of the system) unless you dig in way-deep in the code.
A counter-example, showing PHP's strong side: If you were to make a simple (yet) template-parsing system which allowed some plugin architecture, you can just parse the file, do some checks and eval some code. In Java you would have to roll out the whole arsenal, where you would need a big class-hierachy and rely upon the Reflection API to do the works.
The end result would be the same, and the Java version perhaps prettier, but if I were to say to my boss "PHP version takes 3 days" and "Java version will take 10-15 days" I know what he would decide on, anytime.
Now give me a cup of coffee for those 5 cents!
Challenge by george on February 14, 18:41
la sarkasmon. Neniam dum mia vivo mi estis tiel kontenta, tiel trankvila, tiel plena de bena paco, kiel hierau, kiam mi eksciis, ke Mikel-Angelo ne vivas plu. Ni eltiris ci tiun sciigon el nia gvidisto. Li kondukis nin tra mejloj da pentrajoj kaj skulptajoj en la vastaj koridoroj de Vatikano, tra mejloj da pentrajoj kaj skulptajoj en dudek aliaj palacoj; li montris al ni la grandan pentrajon de la Siksta Kapelo kaj freskojn, kiuj suficus por freskigi la tutan cielon, -- preskau cio estis farita de Mikel-Angelo. Ni decidis uzi kontrau li rimedon, per kiu ni venkis jam multajn gvidistojn -- malsago kaj idiotaj demandoj. Ci tiuj kreitajoj nenion suspektas -- ili tute ne komprenas la sarkasmon.
