> The goal of Java was always to be able to "write large programs quickly."
That wasn't the goal of Java, not by a mile. The goal of Java was to build a language that runs everywhere, and to facilitate Sun's "everything(your watch, toaster, pc) is networked" ambition.
All the things that people flout about Java saying that how it helps them manage large projects(completion, re-factoring, ide integrated debuggers, good libraries) wasn't even a twinkle in anyone's eyes who was involved with Java development. Java's initial release was terrible - it didn't even have decent stdout facilities, was interpreted and as a result dog slow, took a long time to load the jvm, and essentially failed it's "write once, run everywhere" motto as it became "write once, debug everywhere" in practice.
Java has evolved, mainly because people bought in the hype. I don't know why people stopped questioning the hype.
"Look, we are totally object oriented."
I am not sure what it means for me as a developer. So, what about classes? Are they objects? Packages? Are value type objects?
"Ummm. No it doesn't matter. Just listen to us. We are object oriented."
"Our goal is 'write once, run everywhere."
Your awt looks like dog shit on both windows and linux, and is slow.
"Hey. We didn't say anything about 'looking good'. I can bet it looks equally crap. That's platform independence."
> In some ways that sounds terrible by itself, but I think it turns out to be legitimate.
If that's the actual goal, it isn't terrible at all. Why do you think writing large programs quickly is a terrible goal?
> I've been on python projects that need to grow but struggle b/c all the things that make it easy to get a lot done the first few weeks become liabilities very soon.
And those things which make it easy to get lot done in first few weeks but are liabilities would be?
> Adding developers to a project that doesn't declare types and encourages just passing around hashmaps is brutal.
I understand time complexity, space complexity, and api of dictionaries. If you needlessly wrap it in your class, I couldn't know anything without reading through your wrapper. What exactly do you gain by wrapping dictionaries?
> All the stuff you can't do in Java makes it easy for someone else to understand it and edit it.
Examples please. If your developers have an easier time understanding implementing an interface to sort, rather than saying persons.sort(key=lambda a: a.name) then I don't know how that can be remedied.
> I would believe that C# might be a bit better but only being fully supported on MS is a non-starter for many server side situations.
The list of things which aren't supported on mono is small, and basically includes things which won't run outside of windows(office interop) or are deliberately dropped(WPF).
That wasn't the goal of Java, not by a mile. The goal of Java was to build a language that runs everywhere, and to facilitate Sun's "everything(your watch, toaster, pc) is networked" ambition.
All the things that people flout about Java saying that how it helps them manage large projects(completion, re-factoring, ide integrated debuggers, good libraries) wasn't even a twinkle in anyone's eyes who was involved with Java development. Java's initial release was terrible - it didn't even have decent stdout facilities, was interpreted and as a result dog slow, took a long time to load the jvm, and essentially failed it's "write once, run everywhere" motto as it became "write once, debug everywhere" in practice.
Java has evolved, mainly because people bought in the hype. I don't know why people stopped questioning the hype.
"Look, we are totally object oriented."
I am not sure what it means for me as a developer. So, what about classes? Are they objects? Packages? Are value type objects?
"Ummm. No it doesn't matter. Just listen to us. We are object oriented."
"Our goal is 'write once, run everywhere."
Your awt looks like dog shit on both windows and linux, and is slow.
"Hey. We didn't say anything about 'looking good'. I can bet it looks equally crap. That's platform independence."
> In some ways that sounds terrible by itself, but I think it turns out to be legitimate.
If that's the actual goal, it isn't terrible at all. Why do you think writing large programs quickly is a terrible goal?
> I've been on python projects that need to grow but struggle b/c all the things that make it easy to get a lot done the first few weeks become liabilities very soon.
And those things which make it easy to get lot done in first few weeks but are liabilities would be?
> Adding developers to a project that doesn't declare types and encourages just passing around hashmaps is brutal.
I understand time complexity, space complexity, and api of dictionaries. If you needlessly wrap it in your class, I couldn't know anything without reading through your wrapper. What exactly do you gain by wrapping dictionaries?
> All the stuff you can't do in Java makes it easy for someone else to understand it and edit it.
Examples please. If your developers have an easier time understanding implementing an interface to sort, rather than saying persons.sort(key=lambda a: a.name) then I don't know how that can be remedied.
> I would believe that C# might be a bit better but only being fully supported on MS is a non-starter for many server side situations.
The list of things which aren't supported on mono is small, and basically includes things which won't run outside of windows(office interop) or are deliberately dropped(WPF).