Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Wrong Kind of Paranoia

prog21.dadgum.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: The Wrong Kind of Paranoia

#21

Post by underbluewaters »

This post resonates with my experiences of the last 6 months. I'm a very good web developer, and have been working for a while now on a couple iOS projects. Coming from javascript which everyone seems to regard as dangerous and overall terrible, I expected that after some time I would get used to and appreciate working in Objective-C and Swift. Nothing could be further from the truth. While you can shoot yourself in the foot with javascript, in practice it's not really an issue. The absurd lengths that these languages (particularly Swift) go to make you less productive while preventing errors is ridiculous and unhelpful. I get as many runtime errors writing Swift code as I do javascript, but my code is riddled with as? or foo.bar!.method() cruft just to satisfy the compiler and get on with my life. Rather than thinking about how to solve a problem I'm strategizing how to work within the limitations of type systems.

As someone who learned to code with javascript, ruby, and python, I'm not sure I'll ever really appreciate these "nanny languages".

Re: The Wrong Kind of Paranoia

#22

Post by douche »

mikestew wrote: post #15
plorkyeran wrote: post #6

> If they're not in the tutorial, examples, or reference, you don't even know they exist. If you use the header file for documentation, and internal methods are grouped together beneath the terse comment "internal methods," then why are you calling them? Autocomplete is a thing. Even if there is a big comment explicitly saying not to use a function, if it doesn't show up in the autocomplete window someone will inevit…

If I'm reading this correctly, you're saying that someone will use a function for which there is no documentation, no external reference, and the user hasn't even seen the code (since they didn't see the comment saying not to use it)? Just a function name and (maybe) a method signature in the autocomplete? The caller deserves whatever woes befall them.

This kind of thing provides endless material for Raymond Chen's blog[1]. It also explains a lot of the insane backwards compatability that is still in Windows.

[1]http://blogs.msdn.com/b/oldnewthing/

Re: The Wrong Kind of Paranoia

#23

Post by haberman »

These protections might be overly fussy in small, one or two person projects. But for programming in the large they are essential as they represent a social contract between teams.

If you call only my public methods, you can generally expect:

   - if my public methods don't work properly, it's a bug
   - and I, as the library author, promise to care
   - if the internals of my library change, I'll keep my public
     functions working if possible.
Disregard my protections and all bets are off. If you cast away const on an object I gave you and then call a non-const method, you might be totally violating the threading model of my library. If you write and complain about this, I will ask why you thought it was ok to cast away const.

Without these annotations it would be much harder to effectively communicate and enforce the parameters within which the library is "promised" to work.

Re: The Wrong Kind of Paranoia

#24

Post by plorkyeran »

mikestew wrote: post #15
plorkyeran wrote: post #6

> If they're not in the tutorial, examples, or reference, you don't even know they exist. If you use the header file for documentation, and internal methods are grouped together beneath the terse comment "internal methods," then why are you calling them? Autocomplete is a thing. Even if there is a big comment explicitly saying not to use a function, if it doesn't show up in the autocomplete window someone will inevit…

If I'm reading this correctly, you're saying that someone will use a function for which there is no documentation, no external reference, and the user hasn't even seen the code (since they didn't see the comment saying not to use it)? Just a function name and (maybe) a method signature in the autocomplete? The caller deserves whatever woes befall them.

Yes. All the time, if the name and signature are enough to tell you what it does and how to use it, which is normally considered a good thing.

Re: The Wrong Kind of Paranoia

#25

Post by blt »

`private` is a joke in C++. Coupling happens at the header file level, not the class level. Any C++ programmer who cares about reducing dependencies should be thinking about header files, not classes.

Man, we really need a module system.

I think the problem is not that `private` exists, but that it is taught/sold to programmers as a silver bullet for making software architectures better. People think "Decoupled systems are good. `private` hides my variables from the outside world. Therefore, if I use `private` variables, my system will be decoupled." This is false. A program can use `private` extensively and still be tightly coupled.

So, I agree with the author that `private` encourages myopic engineering, but I think education is a better way to fix the problem than removing the features.

Re: The Wrong Kind of Paranoia

#26

Post by Swizec »

TheLoneWolfling wrote: post #13
Swizec wrote: post #2

Over here in the dynamic languages world (JS, Ruby, Python, etc) I often cry myself to sleep because I spend hours debugging something that turns out to be preventable with a const or a private function or something.

Python being Python, you can prevent non-malicious problems of the sort you mention (const and private functions / variables). Const via overwriting setattr / etc, private functions via stack inspection (among other things. There's a sliding scale of thoroughness versus clean code here.) Though it won't protect you from malicious intent (though this is still the case with C / etc), and it's caught at runtime as oppos…

> Though it won't protect you from malicious intent

It often does feel like junior developers are malicious. While I commend their ingenuity in solving the problem, code review can be a real schlep.

Re: The Wrong Kind of Paranoia

#27

Post by chipsy »

AdeptusAquinas wrote: post #7

In my view the purpose of const/protected/internal/static etc is not so much to prevent mistakes by myself or others, but to embed in my code a 'living documentation', enforced by the compiler. If I mark a method as internal, that means I intend it for reuse within the library but don't expect it to be used by any external caller, which means another developer can come along and make changes to it without needing to…

I disagree with the exact statement but also agree with its sentiment. The functionality of a language should be applied for a specific engineering reason, and protection features are sensible at the right scale. But at no point does it replace documentation efforts. You can surface the simplest possible interface to your users and still have questions and concerns that need supplementary text.

Re: The Wrong Kind of Paranoia

#28

Post by buttchrist »

underbluewaters wrote: post #21

This post resonates with my experiences of the last 6 months. I'm a very good web developer, and have been working for a while now on a couple iOS projects. Coming from javascript which everyone seems to regard as dangerous and overall terrible, I expected that after some time I would get used to and appreciate working in Objective-C and Swift. Nothing could be further from the truth. While you can shoot yourself in…

This old canard.

I am a professional Objective-C developer and have been for several years. Type safety is not an absurd length. Eliminating an entire class of errors from your program by having the compiler infer and enforce types is not ridiculous. Using a type-safe language is a very good idea.

We are human. We have stupid unchecked nil object errors come up in our code bases all the time. Swift will ensure that does not happen again. That's like the least part of what I am looking forward to.

If you are having trouble writing a program that compiles with strong typing, I don't know what to tell you. Using types is nothing more than stating what you expect the shape of the data to be in and having the compiler make sure that is so.

Re: The Wrong Kind of Paranoia

#29

Post by quanticle »

mikestew wrote: post #15
plorkyeran wrote: post #6

> If they're not in the tutorial, examples, or reference, you don't even know they exist. If you use the header file for documentation, and internal methods are grouped together beneath the terse comment "internal methods," then why are you calling them? Autocomplete is a thing. Even if there is a big comment explicitly saying not to use a function, if it doesn't show up in the autocomplete window someone will inevit…

If I'm reading this correctly, you're saying that someone will use a function for which there is no documentation, no external reference, and the user hasn't even seen the code (since they didn't see the comment saying not to use it)? Just a function name and (maybe) a method signature in the autocomplete? The caller deserves whatever woes befall them.

The caller does indeed deserve whatever woes befall them, but sometimes the caller is loud enough, powerful enough, or prominent enough that you have to support them... even when they're bypassing your actual API and hitting your internal methods.

Re: The Wrong Kind of Paranoia

#30

Post by rpedroso »

rdtsc wrote: post #20
AdeptusAquinas wrote: post #7

In my view the purpose of const/protected/internal/static etc is not so much to prevent mistakes by myself or others, but to embed in my code a 'living documentation', enforced by the compiler. If I mark a method as internal, that means I intend it for reuse within the library but don't expect it to be used by any external caller, which means another developer can come along and make changes to it without needing to…

I agree with this. The code is not just a message to the compiler to build the binary/bytecode, it is also a message to other programmers. As such there is value in annotating things in that manner. Even in Python, a very dynamic language, there is a convention that methods that start with _ are private. And I often also separate them into a different (bottom) section with a big header saying this is the private bloc…

If you want to enforce this more stringently, you can even prefix methods with __ (double underscore). Python will mangle the name:

    __mydef -> _myClass__mydef
You can, of course, still access the method, but it's very useful for keeping implementation details of a base class out of a subclass. This way, your subclass can have its own `mydef` without overriding the base class.
Post reply on HN