1. What are the advantages of static language?
From robbin Taken from http://www.javaeye.com/article/33971?page=7
This is a common sense that exists in everyone's mind. I admit that I also subconsciously feel that static strongly typed languages are suitable for developing complex, large-scale systems. And weakly typed scripting languages are not suitable for developing too complex and too large projects. But in the process of participating in this discussion, I suddenly began to question this point of view. Is this the case?
First define the standard:
A strongly typed language (statically typed language) refers to a language that requires variable/object type declaration, and generally requires compilation and execution. e.g. C/C++/Java/C#
Weakly typed languages (dynamically typed languages) refer to languages that do not require variable/object type declarations, and generally do not require compilation (but there are also compiled ones). For example PHP/ASP/Ruby/Python/Perl/ABAP/SQL/JavaScript/Unix Shell etc.
For Java, IDEA/Eclipse is indeed very strong in code awareness, which can undoubtedly increase the ability to control complex systems of large-scale systems. But apart from Java having such a strong IDE weapon, it seems that other languages have never had such a strong IDE. Visual Studio of C# is very strong in GUI development and Wizard, but its code perception ability is not a little bit worse than Eclipse. As for Visual C++, it's just a compiler, I'm ashamed to mention the word Visual. Not to mention that so many C/C++ developers have written hundreds of thousands of lines of code using vi. Especially the millions of lines of code like Linux Kernel, which are written in vi, are complex enough, large enough, and have a long life cycle.
That is to say, the statically typed language can ensure the namespace division of the package, thereby avoiding naming conflicts and good isolation of the code. But this view is also unconvincing.
In statically typed languages, C and VB both lack good namespace segmentation and are prone to conflicts, but the systems they make are not large and complex enough without affecting them.
And Visual C++ development is notorious for version conflicting DLLs, and it seems that C++ namespaces don't help it much.
In dynamically typed languages, Ruby/Python/Perl all have relatively good namespaces, especially Python and Perl. For example, there are tons of third-party libraries on CPAN, and I have never heard of any conflicts.
It is true that dynamic languages like PHP and JavaScript that lack namespaces are prone to problems, but this seems to be caused by their lack of OO mechanism, not because of their dynamic typing?
When it comes to large-scale systems and complex business logic systems, many things in Google are developed in python, which also proves that dynamically typed languages are not incapable of doing large-scale and complex systems. Actually, I personally think:
Dynamically typed languages, especially high-level dynamically typed languages, can let people not need to be distracted to think about programming problems, but concentrate on thinking about business logic implementation, that is, the process of thinking is the process of implementation, and the process of describing problems with DSL is the process of programming , In this regard, Unix Shell, ruby, SQL, and even PHP are well-deserved DSL languages in the corresponding field. Obviously, statically typed languages basically do not meet this requirement.
So what are the advantages of statically typed languages? I think it is very efficient execution. So whenever you need to focus on performance performance, you have to use statically typed languages. There doesn't seem to be any particular advantage in other respects.
Some comments:
1. Check out yahoo, it's written in PHP. You may not be able to do that kind of performance with JAVA.
2. My feeling is that dynamic language is flexible enough, so although it allows people to concentrate more on the implementation of business logic, and also moves closer to the direction of artificial intelligence, it also relies more on the skills of the developers themselves. Basic skills, beginners, intermediate developers, it is difficult to make good use of it. The statically typed language has better continuity with the basic subjects (c/pascal/basic) of our computer teaching, so it is better for fresh graduates to accept and learn. So I think the learning/training/development cost is still the main factor. A not-so-good example: javascript's regular expressions, while powerful, are not easy to understand and learn. Generally only copy/paste can be used. So in many cases, you would rather write standard js to handle it.
3. I feel that a strongly typed quasi-static language like Java has another important feature. Once the programmer has basically mastered the grammar rules and writing specifications, the readability of the written program will be much stronger, because it has more limitations. In a large-scale system, it is very critical that Team members can know what each other is writing, which has also become an important basis for communication.
However, a language like Ruby, although it seems to be more in line with "describe a problem is to solve a problem", but for the same piece of logic, it can also meet the requirements, but the writing method is very different. I have seen a Ruby solution to a number reading algorithm written in 1 line, who can understand?
4. What I see more often is that Java programmers write hundreds of lines of shit, and Ruby can do it in a few lines.
5. A statically typed language is a language in which the data type of a variable can be determined at compile time. Most statically typed languages require that the data type must be declared before using a variable. Some modern languages with type inference capabilities may be able to partially alleviate this requirement.
Dynamic typing A language is a language in which data types are determined at runtime. A variable does not need a type declaration before it is used, usually the type of the variable is the type of the value to which it is assigned.
A strongly typed language is a language that cannot be converted once the type of a variable is determined. In fact, the so-called seemingly transformation is achieved through intermediate variables, and the type of the original variable must not change.
In weakly typed languages , the type of a variable is determined by its application context. For example, the language directly supports strings and integers, which can be done directly with the + sign. Of course, in strongly typed languages that support operator overloading, this can also be done formally through external implementation, but this is a completely different connotation.
Generally speaking, java/python is considered strongly typed, while VB/ Perl/C are weakly typed.
However, compared to the classification of dynamic/static languages, strong/weak typing is more of a relative concept.
6. If a dynamic language is used, the workload of unit testing is much more than that of a static language
robbin returns this one. In fact, you have overlooked a point. When using a framework like RoR, the amount of application code is very small, so there are very few parts that need to be tested, which is much less than when using statically typed languages.
Also, the lack of unit tests isn't as scary as you make it out to be. We don't write unit tests now. There are already more than 6,000 lines of ruby code. It's easy to program and debug errors. How can it be as scary as you say.
7. The complexity of the business system lies in the difficulty of organizational communication. In a large company, it is good that there is a person inside who can clearly understand the business process. This person can also explain the process clearly to the software personnel. begging. In this way, using ruby has an advantage. It can develop quickly, promote communication, and develop a model for business people to see. Using it, it is much easier to communicate naturally.
Now a developer's development efficiency is much higher than before. The main reason is because of the progress of development languages and compilers. This trend will only continue. Don't hold on to the dogma of the past. Java is also constantly improving. Reflection, assert, generics, and script support will be added in the next version.
8. In fact, in addition to performance considerations, the biggest advantage of statically typed languages is that they can provide static type safety. The compiler can check whether each of your function calls is written with the correct name and whether it provides the correct type. parameter. Such a system, coupled with the capabilities of custom types, allows many errors (more than many people imagine) to be found and located at compile time.
9. I have seen someone complaining about dynamic languages in discussions on similar topics on slashdot. That guy is in the banking system. He has about 100,000 lines of python code. In the end, he felt unmaintainable because of the constant bugs. Go to java platform. (If you look at the posts and comments about ruby and python on slashdot in the past two years, you can probably still find this post.)
From the description of this guy, his main problem is that there are no unit tests or unit tests do not achieve statement coverage Or stronger combination coverage of weak conditions, so that when some abnormal processes occur, these untested statements flow through these untested statements, resulting in syntax errors and eventually the entire program hangs. For business systems, this is a very serious thing . Like I said earlier, my own programs have died on logging statements more than once because I didn't test for passability of such statements in the first place.
As for the usefulness of unit testing, it is impossible to see the thousands of lines of code in a project of three or five people. In fact, workshop-style development can still make a lot of things. Five years ago, the domestic development method basically did not have unit testing, and it can still play well.
However, in my own experience, while I don't follow TDD, the unit tests are exhaustive enough and the confidence this testnet gives me (especially when making code changes and larger refactorings) is that before unimaginable. I estimate that thousands of lines of program can benefit from incremental unit testing.
10. How much help the compiler is to the programmer depends on the individual. A lot of what the compiler can find out are typos and spelling mistakes. Checking for this kind of error is a piece of cake for robbin, even without a compiler. But for less experienced programmers, the situation is probably very different. After all, an important aspect of the difference in programmer experience is the difference in debugging ability and experience. For experts, errors that can be found by carefully reading the program twice may take an hour or two for some novices. I have encountered this situation many times in practical projects.