Why bother with _any_ programming language?
After reading a question on HN, I started thinking again about programming languages. Does it matter if you know one or plenty? Can you know 5 languages equally well? Or even well enough to claim that you actually know them?..
What's the actual difference?
If we're talking just of statically-typed, object-oriented languages, there's not much difference. Only thing you should always be aware of, is memory management. If there's a garbage collector, you don't really care about pointers and disposing objects yourself. You also sacrifice part of performance and memory (not always true, for certain, since Garbage Collection most of time allows you to avoid memory fragmentation / segmentation, and you always get single slice of allocated data, and free memory for further allocations). Although, better understanding of heap and stack, pointers, values, passing messages comes from languages, where GC is not available by default. Hence, in c++ you still can use Boehm GC, but existing patterns such as smart pointers and pools are quite useful, and you can get far enough without GC, and remain certain you have your memory managed, and can be certain about when the object gets freed. So, you have stuff to learn from both worlds. You get to know, how to manage your memory, and how to delegate management. Quite useful, isn't it?
Moving to dynamic dispatch, and loosing certainty of method existence prior to execution is a tough goal. Dynamic languages bring up a whole new world of expanding your object, making system more flexible, mixing in, extending natives and so on. Ruby gives an ability to do hardcore mixins through modules, which is widely used all around Rails. Active Record found a perfect use for method_missing, which certainly is a great idea. Kernel.autoload is a good idea. It also seems to me that these are patterns, or templates rather than simple methods or extensions. Something you can benefit of. Same thing is relevant to Scala Traits. Ruby Gems and Python Packages are both great ideas, even though Ruby guys went further and made it easier. Lisp s-expressions were picked up by Microsoft guys and turned into beautiful expression trees in C#, that changed a lot of things, when LINQ broke the ground.
Code reading and practice comprehension
Code reading skills are essential for all the developers. Know several people who'd stick to their language, and would never even try to expose the unknown. Is it that bad, though? Not quite. Let's think of programming for a bit more. At first, looking on a new language, try not to get to the situation when you're diving too deep into the framework, rather than language itself. The thing is that if you see that there's a framework, wonderfully written and performing well and it's open-source, you can take a look on the code, read it up and get to know some practices. But without language knowledge it's going to be not that easy. You all know that story about alias_method_chain in Rails / Ruby community. Some practices came out of tutorials, and lot a of people never thought of the better way of doing that. Most likely, same exact thing happened to .NET postback-oriented model and ViewState, when people have forgotten of a web way of persisting state. Same thing happened to default position of Django models and views in Python, that are kept in a single file. For some reason, a whole lot of people do not want or even do not know how to separate them.
Next time, when you start looking for another framework, whatever you're working on, just ask yourself, if you _can_ write it yourself. If not, dig into it, understand the way it's written and reasons behind it (I realize, that it's not always possible, but Open Source World extends every single day). And do not learn the framework. Learn language. APIs change, some other day you may be even forced to extend or modify it for your own needs. What's your first though when your hacky selectors do not work in your favorite JS library? Googling solution only gets a half of a problem solved. The other part remains untouched: an ability to perceive the code, read it up, debug it, understand the root and fix a cause with your own hands.
Conclusion?
New languages are cool. They make you think of syntax again, and force you to shift your paradigm. You start looking on your own code from a different point of view, just by thinking of what would it look like if it's in any other language. You think of garbage collection, or freeing memory, whether it's relevant for certain cases, and may checkout implementations of things in other languages too. So, my IMHO is that any other language may help you to get to know lots of new things about the one you're currently using.
What's the actual difference?
If we're talking just of statically-typed, object-oriented languages, there's not much difference. Only thing you should always be aware of, is memory management. If there's a garbage collector, you don't really care about pointers and disposing objects yourself. You also sacrifice part of performance and memory (not always true, for certain, since Garbage Collection most of time allows you to avoid memory fragmentation / segmentation, and you always get single slice of allocated data, and free memory for further allocations). Although, better understanding of heap and stack, pointers, values, passing messages comes from languages, where GC is not available by default. Hence, in c++ you still can use Boehm GC, but existing patterns such as smart pointers and pools are quite useful, and you can get far enough without GC, and remain certain you have your memory managed, and can be certain about when the object gets freed. So, you have stuff to learn from both worlds. You get to know, how to manage your memory, and how to delegate management. Quite useful, isn't it?
Moving to dynamic dispatch, and loosing certainty of method existence prior to execution is a tough goal. Dynamic languages bring up a whole new world of expanding your object, making system more flexible, mixing in, extending natives and so on. Ruby gives an ability to do hardcore mixins through modules, which is widely used all around Rails. Active Record found a perfect use for method_missing, which certainly is a great idea. Kernel.autoload is a good idea. It also seems to me that these are patterns, or templates rather than simple methods or extensions. Something you can benefit of. Same thing is relevant to Scala Traits. Ruby Gems and Python Packages are both great ideas, even though Ruby guys went further and made it easier. Lisp s-expressions were picked up by Microsoft guys and turned into beautiful expression trees in C#, that changed a lot of things, when LINQ broke the ground.
Code reading and practice comprehension
Code reading skills are essential for all the developers. Know several people who'd stick to their language, and would never even try to expose the unknown. Is it that bad, though? Not quite. Let's think of programming for a bit more. At first, looking on a new language, try not to get to the situation when you're diving too deep into the framework, rather than language itself. The thing is that if you see that there's a framework, wonderfully written and performing well and it's open-source, you can take a look on the code, read it up and get to know some practices. But without language knowledge it's going to be not that easy. You all know that story about alias_method_chain in Rails / Ruby community. Some practices came out of tutorials, and lot a of people never thought of the better way of doing that. Most likely, same exact thing happened to .NET postback-oriented model and ViewState, when people have forgotten of a web way of persisting state. Same thing happened to default position of Django models and views in Python, that are kept in a single file. For some reason, a whole lot of people do not want or even do not know how to separate them.
Next time, when you start looking for another framework, whatever you're working on, just ask yourself, if you _can_ write it yourself. If not, dig into it, understand the way it's written and reasons behind it (I realize, that it's not always possible, but Open Source World extends every single day). And do not learn the framework. Learn language. APIs change, some other day you may be even forced to extend or modify it for your own needs. What's your first though when your hacky selectors do not work in your favorite JS library? Googling solution only gets a half of a problem solved. The other part remains untouched: an ability to perceive the code, read it up, debug it, understand the root and fix a cause with your own hands.
Conclusion?
New languages are cool. They make you think of syntax again, and force you to shift your paradigm. You start looking on your own code from a different point of view, just by thinking of what would it look like if it's in any other language. You think of garbage collection, or freeing memory, whether it's relevant for certain cases, and may checkout implementations of things in other languages too. So, my IMHO is that any other language may help you to get to know lots of new things about the one you're currently using.
Comments
Post a Comment