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

11–20 of 54 posts

Re: The Wrong Kind of Paranoia

#11

Post by TheLoneWolfling »

catmanjan wrote: post #4
Mithaldu wrote: post #3

"There's an architecture used in video games for a long time now where rendering and other engine-level functions are decoupled from the game logic, and the two communicate via a local socket." Is he talking about multiplayer or has anyone ever actually seen this?

Some games (even in singleplayer) host a "local server" and environment information is passed to that. If you're making a networked game it makes sense as you'd be creating the server anyway, decoupling is nice and less codebase to manage. Steam's Source games, UT do this, if you open up the console and scroll up you can see the local server initializing.

Ditto, Minecraft.

Not sure about Supreme Commander but it wouldn't surprise me if it did.

Re: The Wrong Kind of Paranoia

#12

Post by j42 »

To be clear, static typing is the zenith of of compiler optimizations and in many ways the programming "ideal," however in the context of loosely typed languages (and their OOP abstractions) and I think the author is missing a significant use-case.

Separation of responsibility/decoupling on the service level are good principles to begin with, but in an OOP paradigm where you are defining/exposing classes and methods, these keywords are really useful for grouping functionality when you adhere to "contract-driven development."

When used correctly they help you abstract the interface for your class (ie, the public implementation-agnostic methods that provide interoperability between the service and the program as a whole) and separate it from methods only designed for internal use (within the class itself).

Often times those abstractions are essential (DRY principles) and the class is the proper place to encapsulate them, however you wish to clearly designate that "this method is self-modifying, limited in scope, and does not interact with or is required by any other class in any meaningful way," and for that it's quite useful.

Re: The Wrong Kind of Paranoia

#13

Post by TheLoneWolfling »

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 opposed to at compile time.

Re: The Wrong Kind of Paranoia

#14

Post by bucky »

I completely agree we should stop being paranoid about what's going to happen when we let other people loose on our beautiful code.

But I don't think having private methods or marking variables const is about paranoia, it's about communicating intent to the people who come behind you and using the compiler to enforce that intent. Every piece of extra context you can give to someone reading your code helps them understand why it's there. Identifiers like const and private are almost like nonverbal communication for code.

Re: The Wrong Kind of Paranoia

#15

Post by mikestew »

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.

Re: The Wrong Kind of Paranoia

#16

Post by douche »

catmanjan wrote: post #4
Mithaldu wrote: post #3

"There's an architecture used in video games for a long time now where rendering and other engine-level functions are decoupled from the game logic, and the two communicate via a local socket." Is he talking about multiplayer or has anyone ever actually seen this?

Some games (even in singleplayer) host a "local server" and environment information is passed to that. If you're making a networked game it makes sense as you'd be creating the server anyway, decoupling is nice and less codebase to manage. Steam's Source games, UT do this, if you open up the console and scroll up you can see the local server initializing.

For Source, that's probably the GoldSrc/Quake legacy. You can see this somewhat in the source on GitHub - WinQuake has both client and server mashed into one process, but there are clear divisions, with the cl_.c/h and sv_.c/h files.

Re: The Wrong Kind of Paranoia

#17

Post by ryan-allen »

woah wrote: post #9
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.

JavaScript tears :'(

I ain't got no tears using Typescript these days!

Re: The Wrong Kind of Paranoia

#18

Post by chipsy »

j42 wrote: post #12

To be clear, static typing is the zenith of of compiler optimizations and in many ways the programming "ideal," however in the context of loosely typed languages (and their OOP abstractions) and I think the author is missing a significant use-case. Separation of responsibility/decoupling on the service level are good principles to begin with, but in an OOP paradigm where you are defining/exposing classes and methods,…

A nice standard reply. But how do you verify that your usage has the impact you think it does?

When I started estimating the complexity of my code - just using rule of thumb and line counts - I found that most uses of classes were unjustified. The "right size" of a class was quite large, especially so in the top level of an application.

Re: The Wrong Kind of Paranoia

#19

Post by epylar »

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 deserves whatever woes befall them.

Why?

Re: The Wrong Kind of Paranoia

#20

Post by rdtsc »

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 block of methods. So in that case there isn't a compiler rule but rather a common convention (which is kind of a step above comments if you wish).

Post reply on HN