LearnDynamically
I'm a long time python user. I have trouble saying bad things about it. I am a newer Ruby user and feel the same way. There is almost nothing wrong with either one of the languages that the other doesn't correct. ;-) These languages are powerful enough for large business applications, and are a lot of fun to work with as well. Dynamic languages like python and ruby are not only more pleasant than statically-typed monst^h^h^h^h^hlanguages but also make it possible to *learn* unfamiliar APIs and existing code very quickly.
Without a live command-prompt, you are forced to guess and try things in edit/compile/debug cycles, which give you a sense of distance from the code you're learning: kind of like programming through a keyhole. There's a gap in activities between expressing what you want to try and getting the computer to try it. Once you get it to do something, you have to print all the data you want to see, or else you have to run it in a debugger. That's a lot of plumbing to see what a particular API can do, not to mention the number of times you'll cycle through in trial-and-error if the API is at all complex.
In python or ruby (via irb) or smalltalk, you can work in a live environment, rather than compiling and running things to see what happens. A live environment means that you can import libraries and call apis (including your own libraries and apis) _live_ at the command prompt. Rather than running a debugger to learn a variable's value, you just ask for it. Rather than writing and compiling and running and debugging a program, just type the api at the command prompt. How can it be easier?
One of the things that Python excels at is documentation. Rather than fighting your way through paper or online documentation and examples or requiring a really powerful editing environment, you can simply ask. The builtin "help" and "dir" commands give more than enough information (in about 90% of all circumstances).
Today I ran into a unicode problem in reading and writing files. I used google to get a quick clue, and the live python environment to try out the solution. I had the answer in seconds, and was able to verify that problem and the solution without having to have a monstrously powerful IDE and a number of open books. I could "just do it". I was even wrong about the codec the first time, and had to try a different one. When I was right, I knew right away that I was right. BTW: The clue came from Dive Into Python.
I expect to see statically-typed languages dying off in most non-sytem applications. And that's good. Business applications don't need them, and they're a darned nuisance anyway.
!commentForm
I'm just now beginning to do more than play lightly with dynamic languages. I've started with Ruby. The environment (irb) encourages me to experiment freely based on (virtually) instantaneous feedback. Learning this way is both exciting and fun for me! I encourage everyone to give it (or Python or Smalltalk or whatever) a try!
If you try it in python, you'll find the same idea goes much further. The built-in methods dir() and pprint() and help() give you an awful lot of information. I know very little about smalltalk, but I seem to remember that being able to "bang test" in the development environment was always considered a strength.
Static typing is the ability to ensure type correctness via static analysis. Dynamic typing ensures type correctness at run time (and we are merely speaking of correct behavior of the evaluated computations, we can't make statements about the correctness as a whole). What you are talking about seems to be a tool issue rather than a language issue (which is still significant), because you confuse static typing with compilation, which is a process of code transformation. I think what you are deep down excited about is the notion of developing software with a development environment that exposes you to an interpreter and allows you to accomplish tasks at the language level, interactively. The fact that static type analysis can be performed on a statically typed language does not preclude an interpreter from implementing that language. Some statically typed languages (and they are decent examples of POOR type systems) such as Java and C are typically compiled rather than interpreted (I don't personally know of an interpreter for either language), but this has absolutely nothing to do with their type systems. As a corollary, dynamically typed languages make no requirement for being interpreted; they can be compiled just fine.
Unit tests aid developers of dynamically typed languages in that they allow us to test multiple execution pathways and if well written, can detect type errors for us. This is still a rather ad-hoc approach compared to what advanced type systems provide, but in my opinion it ends up being a decision made by the developer in the interest of his own taste. And before we jump on the 'correlation implies causality' boat, languages with advanced type systems (such as ML and Haskell) can still be developed with unit tests in a TDD fashion. The difference is that we are now PROVING a portion of a program's correctness (because there is more to 'correct' software than type correctness), which means that we have more confidence, and we spend less time rewriting code to fit tests, because you end up getting the types right the first time around ;)
For the record, I am not trying to promote statically typed languages as somehow superior to dynamically typed languages (in fact you will find me most often writing Scheme code). However, I felt some clarification was needed.
Unit tests aid developers of dynamically typed languages in that they allow us to test multiple execution pathways and if well written, can detect type errors for us. This is still a rather ad-hoc approach compared to what advanced type systems provide, but in my opinion it ends up being a decision made by the developer in the interest of his own taste. And before we jump on the 'correlation implies causality' boat, languages with advanced type systems (such as ML and Haskell) can still be developed with unit tests in a TDD fashion. The difference is that we are now PROVING a portion of a program's correctness (because there is more to 'correct' software than type correctness), which means that we have more confidence, and we spend less time rewriting code to fit tests, because you end up getting the types right the first time around ;)
For the record, I am not trying to promote statically typed languages as somehow superior to dynamically typed languages (in fact you will find me most often writing Scheme code). However, I felt some clarification was needed.
True enough: Sometimes we confuse the attributes of things we love or hate. Thanks for clarification.
1) Interactive nterpreters are great for quick learning and confidence-building
2) Statically-typed languages tend to not be interpreted dynamically and interactively
Because of these, I tend to get away with sloppiness here, but you are right.
1) Interactive nterpreters are great for quick learning and confidence-building
2) Statically-typed languages tend to not be interpreted dynamically and interactively
Because of these, I tend to get away with sloppiness here, but you are right.
BeanShell[?] is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell[?] dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript[?].
Add Child Page to LearnDynamically