Hacker News Reader

Comment by choeger | Hacker News Reader

> I inevitably came the exact opposite conclusion. Perhaps because at the start of my career I was trying to do the same thing with Java, and it added overhead and expense without a commensurate payoff in safety.

It really sounds like your code base simply wasn't too big after all. When you change a Java API, how much time does it cost you to find all broken client code? How much in the same case for python?

> Frankly, I think velocity is ridiculously underrated

Again, it sounds like your projects were still rather young. IME, throwing away code practically never happens when it has been installed for at least half a dozen customers. So python helps you to build stuff quicker, because it does not force you to be sound. But soundness is exactly what you want after a certain threshold.

View on HN

>When you change a Java API, how much time does it cost you to find all broken client code? How much in the same case for python?

With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it.

>Again, it sounds like your projects were still rather young.

Probably just better tested than yours.

In time, you might learn to appreciate this quality but who knows...

> With a decent test suite and a bunch of well crafted asserts, it ends up being much quicker. Indeed, for the really subtle broken stuff, pretty much only a decent test suite can catch it.

I think you don't understand the point. Unless you propose that my test suite tests the libraries I am using, testing does not find code affected by API breakage. And even if you do test your used libraries in your client code, think again about how much effort it cost you to do what a machine can do just better.

> Probably just better tested than yours.

First of all, I doubt it. Second, you just sound rather arrogant.

I hope you are aware that a) testing by necessity will always be incomplete and b) type systems by necessity will always be restricted.

The developer who just discards one of these tools sounds like a woodworker who discards a chainsaw because he loves his splitting axe so much.

>Unless you propose that my test suite tests the libraries I am using, testing does not find code affected by API breakage.

I do find that well crafted integration tests give the best bang for the buck.

>First of all, I doubt it. Second, you just sound rather arrogant.

This was a mirror image response to your condescending assumption that I "just hadn't worked on large enough code bases"

It's a little sad that you didn't have the self awareness to recognize that my feigned arrogance was satirizing yours ;-)

> integration tests

if you really worked on large projects you would know that integration tests involve more than just one language. They are a helpful tool, and a very important one. But if I had to rely on integration tests to figure out API breakage, I would have to quote a massive price for any libray upgrade. Fortunately I have cheaper and better means.

> It's a little sad that you didn't have the self awareness to recognize that my feigned arrogance was satirizing yours ;-)

Yeah right. You quote two projects and consider your work better tested than mine. And I am the arrogant one. All I said is that you sound like you did not see the kind of projects I did.

Here's the thing. You either are really up to something and know something that all us soundness-first old farts doni know. Then you are going to revolutionize software development that has been coping with the same issues since the 70s. Or you are simply an arrogant youngster full of Kool aid, and you will crash against the same walls everyone else in the industry did.

>First of all, I doubt it. Second, you just sound rather arrogant.

Oh, the irony.

"It really sounds like your code base simply wasn't too big after all"

"Again, it sounds like your projects were still rather young"

Are you aware of the meaning of the phrase "it sounds like"? Because comments like this just make the whole discussion-in-the-web thing a rather unpleasant experience.

Not sure how the meaning of the phrase "it sounds like" plays into this.

My point was that you accuse the parent of arrogance, while he was merely mirroring/responding to the arrogant tone in your comment (in the lines I've quoted).

That is, my point wasn't that you made an absolute claim ("your code is X") that was false. If that was my claim, yes, you could refute it by saying "I only said that it sounds like X is the case, I didn't make an absolute claim".

But my point was rather that the tone in your comment was arrogant.

"Your code base simply wasn't too big after all" is equally arrogant whether prefixed with "sounds like" or not.

It makes assumptions about the size of the other person's codebases, and it arrogantly implies that they don't see what they see because they haven't worked in as large codebases as you have.

Reply on news.ycombinator.com