If you don't like Java and generate your way around it, that's not a genuine measure of productivity in Java.
Just like using a HLL (which generates machine language) isn't a measure of machine language productivity.
Whatever approach you settle on is a language. E.g "Bob's Lisp-based Java Generator" is a language. It's neither Java, nor Lisp. That language helps give Bob a certain productivity.
What Bob is doing represents the vast minority, and could create a maintenance problem for the organization, and its army of people who know only Java. Code generation isn't a practical recipe by which every programmer everywhere can hit productivity in any language.
The productivity I am talking about is $ generated per time/cost. Not what you call “language productivity”.
For example, you will be more productive using C than (say) Python if your Python solution requires more servers to run than your C solution. Even if it took longer to write the C solution. Because the long term cost of the servers will be higher than the development cost. Which is why Google and other companies often rewrite code that alreadyworks to C++.
Another example is that you will be more productive using C# and the Unity game engine to write a commercial game than (say) Python. Because the Unity engine takes care of all the hard stuff you would otherwise have to write yourself in Python.
And you will be infinitely more productive using C to write a hard real time kernel than Python. Since Python is too slow unless you pretty much spend all your time calling C code to make it fast enough. Heh I can just imagine somebody trying to convince Linus to rewrite the Linux kernel in Python to be more “language productive”. That would be a very short conversation :)
So your comments might be true or not but that’s besides the point. I simply don’t care about “language productivity”. I care about real measurable productivity. The kind of productivity that the CEO of a company recognises.
That's a tricky one. If the product didn't sell, but the developers earned good salaries, was there productivity?
If a widely used, free program received $1500 in donations over fifteen years, is that $100/y productivity?
If I write the code and get paid, does it matter whether nobody runs it after that? Or whether it runs a lot without me getting paid more?
Basically, given $/t, whose $ and whose t are we talking about? Should these parameters not be constrained to be those of the same person or people? Or is it okay to divide the money made by some users of the software downstream, by the development time?
Yep productivity is a complicated tricky subject. And yes if your work generates zero $ then your productivity is zero by my definition. Or actually negative if you spent money doing it. This is because I am thinking like a business person.
However you can use other definitions of productivity of course. You could define it to be issues fixed per month for example. However that is even more tricky. Because different issues require different skills and effort. And to make it even more complicated, an issue that is easy for Ada to fix might be hard for Bob. Simply because Ada have fixed similar issues before. So Ada using C++ might be way more productive than Bob using Python. But that doesn’t prove that C++ is more productive than Python of course.
Which is why studies using the same people to solve the same problem twice using 2 different languages to “prove” that language A is more productive than language B is non-scientific BS. Obviously solving the same problem the second time gives you a huge advantage. No matter the language you use. And obviously the people involved will know one of the languages better than the other. Which again makes the whole experiment non-scientific BS.
So yes productivity is a complicated slippery tricky thing to nail down. We all think we know what it means but the more objective/precise we try to be the more slippery and complicated it gets :)
> yes if your work generates zero $ then your productivity is zero by my definition
Not only that, but you're not a good software developer, because you didn't "figure out how to be productive and get things done in any programming language".
Yeah, but the question is how productive are those things that are getting done.
A 100% productive assembly language programmer is not the same as a 100% productive Python programmer.