|
|
Re: To type or not to type
|
Posted: Mar 15, 2004 10:39 PM
|
|
> Getting back to Jim's original post - his assertion that
> strong statically typed languages are slower to develop
> rapid prototypes in - I think is also missing the point.
> The key to developing code rapidly is using a programming
> language with fewer average lines of code per function
> point (e.g. Perl, Smalltalk, ML) than ones with more (e.g.
> C, C++, Java). Most research that I know of (McConnell in
> Rapid Development is a great summary) says that average
> programmers write the same number of lines of code a day,
> regardless of the programming language. So choose one
> which has fewer lines and you'll develop faster. Other
> than that, I thought Jim's analysis was great.
I think it really depends on what you call the language. Your basic comment here, says to me, that you would never consider a library, or a platform (Java is a platform not a language) provided capability as a simplifying capability.
All languages end up with a certain platform of capabilities that are typically tied to a version of the language/platform. Languages which have a single source tend to have more features that are 'standard' than languages which are designed by committed and sold by the masses. C and C++ have hardly anything beyond basic math and programming constructs that you can rely to be present on every OS that you might try to run such a program on. Posix provides a set of functions with standard interfaces to operating system provided capabilities. There is essentially no standard for GUI display control in C or C++ because there is no 'platform'. C and C++ have a huge number of libraries for a wide range of things that you can get/buy. It is typically possible (ignoring cost of purchase) to get a wide range of C/C++ software with no effort for nearly any project you might imagine.
Perl and Python have tons of libraries that are widely varied in what they do as well. The big issue is that you ahve to look everywhere and integrate everything to get a platform to base your application on. The next release of your application will likely require a reintegration effort to get the best version of all the modules you found back together and to create/adapt tests.
Java's platform is provided by the vendor. The platform has a spec, and all the vendors have to meet the spec. So, any place you take Java code, you'll find the same functionality. There might be bugs, but the spec says what you can depend on, and you can hold that up to your JVM vendor.
Microsoft's languages in the .NET environment with the whole managed code business present a similar guarantee. You'll get the same environment everywhere (well, everywhere where the OS can run).
Productivity in any of these environments will depend on the stability of the platform/language, and your abilities to create any new Application Oriented Meta language representation in your API that makes it simple to create your app.
Most people don't write code to draw a line by having explicit pixel manipulations everywhere such as
setPixel(ctx, 1, 2);
setPixel(ctx, 1, 3);
setPixel(ctx, 1, 4);
setPixel(ctx, 1, 5);
instead, there is a functional line drawing capability
drawLine( ctx, 1, 2, 1, 5 );
Graphics drawing is such old hat, that all these things are well known, and always provided. In a new application domain, you might have to create the primatives that support the language that you'll use to describe the program structure that will make your work easy.
For all intents and purposes, there is no language, that if it can solve a particular class of problem, could not represent that solution as a single line of code!
This is the point that you have to grasp. It's not about fewer lines of code. It's not about consiseness of expression. It's only about the possibility of expressing a solution in a structure that is maintainable (based on the life cycle of the software), and existing as a code which is capable of providing a valid execution model for the needed solution.
Static typing has to be changed to make the program compile, and thus be executable. With untyped, or dynamicly typed languages, and TDD, tests are written to conclusively prove that the program is not broken. For me, these are dramtically different situations.
|
|
Previous Topic
