On the whole, I'd go with Java. This isn't because Java is better, or because Java people are better, but because Java is infinitessimally more robust against lazy code written by average coders. Bad Java is bad Java. It's harder to maintain than bad Python (bad Java tends to be verbose and over complicated, whereas bad Python is over-simple and a bit easier to rework). However bad Java smells worse. There's an awful lot of good practice around in how to run an effective Java shop, even if most of the suits wouldn't recognise it if it bit them. If you have an average team, and some better than average team leads, you can at least judge your product quality. You can know that some new Java is bad, which gives you the chance to fix both the code and its coders. Pair programming works well in Java, I've never seen it work in Python
( ... )
The thing with dynamic typing is that it is nice in the occasion you want it, but you don't want it everywhere, all the time. There is lots of code where you can assign some type to your data with certainty. You'd like to express that in the code, if only to aid the reader in understanding what's going on, and to help the compiler to double-check. However, to my knowledge (I'm not a Python expert), Python has no syntax to let you optionally specify the type of your data.
Python has plenty of ability to build statically-typed code, but it's so tedious that you might as well do it in Eiffel. You can't do it by syntax alone, but the check is easy enough with isinstance
( ... )
Yes, this is like an anti-missile system. There is a cost to providing it, and it keeps you safe from the wrong sort of incoming items. There is also an insignificant overhead to delaying every commercial flight in mid air to check its bona fides.
However it's not a "wait for the bang" method. We don't execute upon these incorrect types, and hope to catch some thrown exception.
When it boils down from the source to the executable or VM code, then there is little to choose between what the compilers and optimisers can build. Only the most esoteric static type systems can avoid such a check of a type tag and there's no strong reason why this has to become significantly less efficient in a dynamically typed language (granted it's a burden in the source).
Von Neumann is obsolete, at least at this level. We need something smarter and more flexible.
I've spent the last dozen years worrying about semi-structured data and metadata. A vast class of interesting problems are out there that I cannot solve by the classical application of statically-typed approaches. I cannot know the types of incoming objects because they are simply unknown or undefined at the time I choose my static types. This is either because they haven't been defined yet, or they haven't been defined "here", i.e. within visibility of my client coding effort. I need techniques that can work under this constraint, and I certainly need something better than many statically typed systems that collapse into a reference typed as no more than a pointer to "an object", with the hope of some exception trapping it it goes obviously wrong
( ... )
On the whole, I'd go with Java. This isn't because Java is better, or because Java people are better, but because Java is infinitessimally more robust against lazy code written by average coders. Bad Java is bad Java. It's harder to maintain than bad Python (bad Java tends to be verbose and over complicated, whereas bad Python is over-simple and a bit easier to rework). However bad Java smells worse. There's an awful lot of good practice around in how to run an effective Java shop, even if most of the suits wouldn't recognise it if it bit them. If you have an average team, and some better than average team leads, you can at least judge your product quality. You can know that some new Java is bad, which gives you the chance to fix both the code and its coders. Pair programming works well in Java, I've never seen it work in Python ( ... )
Reply
Reply
Reply
Reply
Yes, this is like an anti-missile system. There is a cost to providing it, and it keeps you safe from the wrong sort of incoming items. There is also an insignificant overhead to delaying every commercial flight in mid air to check its bona fides.
However it's not a "wait for the bang" method. We don't execute upon these incorrect types, and hope to catch some thrown exception.
When it boils down from the source to the executable or VM code, then there is little to choose between what the compilers and optimisers can build. Only the most esoteric static type systems can avoid such a check of a type tag and there's no strong reason why this has to become significantly less efficient in a dynamically typed language (granted it's a burden in the source).
Reply
I've spent the last dozen years worrying about semi-structured data and metadata. A vast class of interesting problems are out there that I cannot solve by the classical application of statically-typed approaches. I cannot know the types of incoming objects because they are simply unknown or undefined at the time I choose my static types. This is either because they haven't been defined yet, or they haven't been defined "here", i.e. within visibility of my client coding effort. I need techniques that can work under this constraint, and I certainly need something better than many statically typed systems that collapse into a reference typed as no more than a pointer to "an object", with the hope of some exception trapping it it goes obviously wrong ( ... )
Reply
Leave a comment