> Am 04.12.2017 um 14:45 schrieb Nick Holland <n...@holland-consulting.net>: ... > > Oh yeah. > I recently discovered a very major business operations application where > rather than using the OS's FTP and SFTP functions, they wrote their own > in "safe" Java. I don't know why. ... > If the other machine is being serviced? Network broke? receiving > machine unable to recieve? Oh well. Magic doesn't work, the file is > lost, without alerting the "sending" program. > > Error reporting? Well, for a long time, I thought it was non-existent, > but I recently found they just dumped all the java runtime output to a > file. Nothing is actually done with this info in the application, but > if 100+ lines of J-crap is your favorite way to see "server timeout", > this is your tool. ... > Nick.
So they wrote a program that was a) shitty and b) memory-safe? Those are two orthogonal dimensions. Also, the anecdotal evidence that safe languages attract bad programmers does not imply that using safe languages is bad: a good programmer won't suddenly commit such atrocities as you mentioned, just because they use a safe language. Finally, your example probably speaks more about business practices than about safe programming languages. If you want to compare Java to a non-memory-safe language, you should compare it to one that is also designed *for* (instead of *by*) programmers, like Cobol.
