Tech Off Thread

10 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Gilad on cutting out static

Back to Forum: Tech Off
  • User profile image
    Charles

    Interesting post on eliminating static-ness from languages by Gilad Bracha.

    Thoughts?

    C

  • User profile image
    Rossj

    Only a couple of thoughts (it has been a long day).


    Whilst it is true that the use of statics is both imperative (as in the style of) and involves taking a lot more care of how it is used, there are benefits which are not necessarily outweighed by the disadvantages.  

    Implement a local cache without statics, now do it without passing references back up the call stack from the owner of the non-static cache all the way to the place where it is actually needed. 

    I can see Gilad's point about distributed systems, and the difficulty in maintaining the 'one true static' but that isn't such an issue if you aren't building a distributed system.

    His points about re-entrancy, whilst true, depend totally on your usage. Personally a lot of my use of statics tend to be read-only after an initial locked update, so I'm not so worried after any threading issues. 

    Yeah, he has lots of great points, but how would I build my Factories and Caches and Blackboards without statics?

    I think we'd all agree that he could write the same document about pointers and that'd be true as well, but I don't think pointers being evil (or not) warrants eliminating them from C (or C++) or is likely to ever be considered.  Same goes for statics, and as with pointers, use it carefully and it won't bite you.

  • User profile image
    stevo_

    Interesting, but I'm always on high alert when writing 'stateful' static interaction.. I 'try' to keep them implicitly threadsafe, but I guess its not always possible..

    I've noticed that I use static less and less, the only statics used are stateless, such as utility functions..

  • User profile image
    evildictait​or

    Charles wrote:
    

    Interesting post on eliminating static-ness from languages by Gilad Bracha.

    Thoughts?

    C



    Geez, Charles, you nearly gave me a heart attack. He means static variables not static types. Consequently I fully agree with him.

  • User profile image
    littleguru

    This post came in today via the RSS and I have to agree with him. Although there are from time to time solutions where a static variable is handy but I really really use in a few scenarios and that's it...

  • User profile image
    Charles

    evildictaitor wrote:
    
    Charles wrote:
    

    Interesting post on eliminating static-ness from languages by Gilad Bracha.

    Thoughts?

    C



    Geez, Charles, you nearly gave me a heart attack. He means static variables not static types. Consequently I fully agree with him.


    Yes. He's talking about state. Did I make it sound like he was talking about something else (I was pretty vague)? I guess I should have said eliminating static-ness from program code... Sorry to scare you. Smiley

  • User profile image
    evildictait​or

    Charles wrote:
    
    Yes. He's talking about state. Did I make it sound like he was talking about something else (I was pretty vague)? I guess I should have said eliminating static-ness from program code... Sorry to scare you. Smiley


    It's not that you made it sound like it here, but Gilad is a famous dynamic languages person and has a (shall we say) low opinion of strong, staticly typed languages. You recently held an interview with him and Mads and Erik where this was fairly clear.

    It's worth noting, of course, that losing static variables from a language is nothing new - Haskell hasn't had them in nearly two decades now.

    For those people thinking that you couldn't possibly cope without static variables, I should remind you that you can migrate all of your static variables to some big class called State, create a new instance of it on program startup, and pass it around via function parameters to everyone who needs a copy of it. I'm not advocating this as an approach, but merely trying to emphasise that everything that can be done statically can be done (often better) non-statically.

    As a general rule, whenever I've had the notion to include a static class inside a program, I've been quickly dispersauded of this notion when it turns out that there are (admittedly bizzare) instances where having two of the program being called at once is appropriate, and thus a static class is inappropriate.

  • User profile image
    vesuvius

    This is a little confusing. I am developing an n-tier application where I have a static class that returns table adapters to a WCF service. All this code will be running on the server (secure) and I cannot see how a malicious user can invoke their nefarious deeds because they are validated by Client Application Services.

    Gilhad is correct insofar as security concerns, but different distributed architectures expose/deny access to their code base. It would take me a few hours to go through the code and 'new' up all references but there is no immediate advantage. My data access and validation occurs on a secure firewalled server.

  • User profile image
    cheong

    The only time I use static object is for caching web.config values. These information are shared across sessions of the web application, loaded at the beginning, and we need only 1 copy of it.

    Since we have to access those settings quite frequently, having it shared in static class as cache would save a lot of read I/O operations.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    Frank Hileman

    I have found eliminating global data is generally one of the most useful design directions one can take.

    Static data, according to the C# definition of "static", is a type of global data. You can modify it from anywhere and side effects can be far from the point of modification. Sometimes that is a conveniece, especially when starting a prototype design. As soon as you wish to adding concurrency, or event re-entrancy, global data is not longer a source of convenience. It becomes a source of hell instead, and then you start thinking about locks, etc.

    That is my perspective based on 20 years of removing global data out of hundreds of software systems.

    How do you remove global data? You have to put it into objects, or parameters. It is not so painful when it is in objects, because one object can hold a lot of global data. A language that has a sense of context can also make it easier to eliminate global data (a context being, a place where you would put normally global data).

    Generally speaking, the more "local" you can make a state change, the more reliable your software becomes. It also becomes composable. I am not sure how many people remember the days before OOP was popular, and global variables (a type of static data) were common. They were a popular source of hell and probably caused more debugger use than any other design decision.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.