I’m exploring several possibilities for developing a new system (web application).
I’m an “old fashioned” kinda guy, object oriented in nature (converted from procedural many years ago). I played around with Python and studied a bit Ruby, but frankly I’m attracted back to using Microsoft’s tools (C#, ASP.NET MVC). All this run-time typing, no compiler errors on basic stuff, etc just makes my life harder when it comes to building large complex applications.
I constantly hear people speak about the great things you can do with dynamic languages, but except for examples with dogs, cats and how quickly you can code a cool way to count things, the “industrial strength” of Visual Studio just seems to eliminate those neat small things dynamic languages offer, especially now that you have free express versions of VS and full versions available for free for start-ups.
I feel like I’m missing something here, because big applications are indeed being developed with dynamic languages, so what are those great things these languages enable you to do, when looking at large complex applications? What can make you give away the strength of VS?
“how quickly you can code” so totally concerns me that I happily gave up the long, slow slog through getting things to compile.
Advantages of dynamic languages.
No compile, no build. Just Code and Test followed by deploy to production.
Immediate gratification. No time spent wringing my hands over what an API call might be. Just type it interactively in the Python >>> prompt and see what it actually does.
Very, very short design cycles. Rather than carefully crafting an class hierarchy with bonus interface definitions and proper abstract declarations and overrides, I can just code the classes, unit test them and be done.
Less code. Dynamic language introspection reduces the volume of source. I don’t write this stuff in my applications; I depend on frameworks to do this for me. But the framework-based code is often very short; there are no duplicative declarations that are so common in Java, where you have to repeat things in an XML config.
No mysteries. As we say in the Python community: “Use the source, Luke.” There’s no ambiguity in what a framework does or what an API really means.
Absolute Flexibility. As our requirements change, we don’t have to struggle with devastating changes that break the entire architecture. We can — trivially — make changes to a few classes because Python’s Duck Typing eliminates the need to retrofit missing interface definitions where we didn’t think they’d be needed. They’re just aren’t any; the code we didn’t write is code we don’t have to fix or maintain.
Resilience. When our actuaries have a brain-fart, we don’t have to spend months figuring out how to integrate this new, more sophisticated underwriting model into the apps. Almost anything can be squeezed in. Again, this is strictly a consequence of duck typing. We’re freed from force-fitting it into an architecture that couldn’t anticipate a new business model.
Since the source is the application, the source can be it’s own configuration file. We don’t have XML or INI configuration files in some foreign syntax. We have configuration files in Python. The Django framework does this and we follow their lead. We have very complex mocked-up data declarations for sales demo and unit testing. The super-complex data is actually a collection of Python objects that would have come from a database — except — we omitted loading the database. It’s simpler to just tweak the Python object constructor instead of loading a SQL database.
[BTW. After 30+ years of developing software in Cobol, Fortran, PL/I, Java, C, C++, I’m just tired of the relatively low-level hand-optimization that most compiled languages require. Years ago, I read a comment on the inefficiency of most compilers: it leads us to create elaborate build systems to work around the compiler limitations. We only need
makebecauseccis so slow.]Edit
Dynamic programming doesn’t make you a genius. It just saves a lot of time. You still have to manage the learning process. Things you don’t know are hard in all languages. A dynamic language gives you leverage by allowing you to proceed incrementally, uncovering one new thing at a time without having done a lot of design work only to find your assumptions were wrong.
If you want to write a lot of code based on a misunderstood API, then a dynamic language can help. You are free to write a lot of code that crashes and burns in a language: C#, VB, C++, Java or Python. You can always write code which won’t work.
The compiler gives you some advance warning that the code won’t work. Typically, not compiling is a big hint. However, you can still write a lot of code that compiles and fails all the unit tests. The compiler only checks syntax, not semantics.
Python can give you some advance warning that the code won’t work. Typically, you can’t get it to run interactively. However, you can still write a lot of code that fails all the unit tests.