Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Comments

Frank Hileman Frank Hileman VG.net
  • Erik Meijer, Gilad Bracha, Mads Torgersen: Perspectives on Programming Language Design and Evolution

    Thank you to all in the interview, and the interviewer. Gilad is not arrogant. His comments are right on target. He does not avoid strong opinions.

    These videos reach a much larger audience than the people at a programming language conference. While some may react badly to criticisim of their favorite technology (i.e. severe limitations in the CLR), the videos are a wonderful way to spread ideas to the larger audience. It is a great way to do "marketing" for these ideas.
  • Everything you wanted to know about VC++ deployment but were afraid to ask

    Thanks, littleguru. I assumed we were being forced to use a technology.
  • JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 1

    sylvan wrote:
    
    No language disallows side effects. Haskell is full of them!

    The difference is that in Haskell the side effects are contained within a pure type system. So even if you have small component somewhere that uses mutable state internally (e.g. some algorithms require mutable state!), the type system can keep track of that for you, and will refuse to let any of that mutable state "leak" out to the pure code. You can use side effects, but the compiler will force you to keep them separate from the bulk of the code (which doesn't have side effects).



    This is a great point! As I mentioned, this is closer to the original idea of object oriented programming, whereby an object's state is purely encapsulated. The original motivation behind OO was to view each object as a small computer in and of itself.

  • JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 1

    duplicate post deleted Perplexed

  • JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 1

    staceyw wrote:
     We can actually do this pretty easy with OO today.  You can derive all objects from a class that has an in and out queue and a worker thread.  Then send messages to it and it processes all messages in local scope if it wants.  However, not sure this is better then some library (i.e. ccr, pfx) that takes lambdas and does the work inside a closure.  With the ability to have nobs on the library for thread min/max, wait times, throttles, perf mon, etc. The former could be a good design for a pipeline server (i.e. sql), but I think the later is better for general work and things like joins, choice, futures, etc.  Room for both I think.


    I would qualify this:
    1. A "process" in something like Erlang is more lightweight and transparent than a Thread in a traditional OO language/library such as C# -- you can create millions, and distribute them across networks easily. Libraries can do similar things but the distribution might be difficult without integrated support as in Erlang. 
    2. There is nothing in C# or the CLR to prevent modifying encapsulated state in an object, in the sense that every value returned from a function, and every property getter, needs to return something with value semantics, not reference semantics.
    3. In Erlang at least, the flow of control is generally turned inside out with the "objects" waiting for a message to arrive, rather than sending a message and waiting for an object to return. The .net framework libraries are generally not designed around this model.
  • JAOO 2007: Joe Armstrong - On Erlang, OO, Concurrency, Shared State and the Future, Part 1

    This was a great video, thanks!!! While people are going to have to start giving up the shared state model, it does not mean OO will go away completely -- "objects" will be more like independent, encapsulated processes than one giant intertwined memory structure in a single process. This is a different way of programming but closer to the original idea of object oriented programming.
  • Patrick Dussud: Garbage Collection - Past, Present and Future

    Thanks, Patrick, Charles, for the great discussion. If Patrick is going to answer any questions in the future, I would be interested in how the CLR and GC will change to work in a world of hundreds of CPU cores, which is not so far away.

    The original idea of object oriented programming, as expressed by Kay, was that each object was a computer in miniature. I am interested in how .net will evolve to reduce visible shared state between objects so that concurrent programming can really take off.
  • Tony Goodhew - The path to Orcas, (future Visual Studio), studying the market research

    To the interviewer, regarding rapid trend changes: it is important to distinguish between "hype" and real trends. Hype would be the marketing buzzwords, or trendy blog topics. A true trend is a steady, long term change in the industry. The hype comes and goes, and doesn't necessarily address any real need. The trends do address real needs. So true trends rarely change quickly, as I am sure Tony is aware of. Blogs are not trends at all.
  • Tony Goodhew - The path to Orcas, (future Visual Studio), studying the market research

    Whoo-eee! This thread gave me a good laugh several times. It is quite funny to hear the young whippersnappers give it to the old cooters -- and the cooters snap right back.

    It is not about age or conservativism. It is about listening to the customer, instead of the geeky developer playing video games. The customer often does not give a hoot about the fancy features that developer has planned -- and the developer does not feel like working on that code his successor left behind. So there is a fundamental conflict. At MS, I would argue for development tools, the developer, not the customer, often wins these days.

    The customer is more important, always. Avalon has a horrible API, eats far more memory than it should, and is essentially useless on older machines or small devices. Every time someone points out a problem there it is explained away as a "feature" or a "revolution". This is a general trend I think at Microsoft. Sorry to bash but... there are dull, boring tasks that need to be done (for the customer) and someone has to do them.
  • John Pruitt - Usability Testing

    It is too bad over-engineered API's like Avalon are fully baked before hitting the usability lab for developers. At that point it is too late to fix the usability problems; they are embedded in the architecture.

    Give all the developers machines with very limited memory and CPU power, and suddenly all the new libraries and development tools would be scalable and easy to learn. Visual Studio would run speedy; Avalon would actually be usable with 100K elements. That is the best usability tool for getting rid of gold-plating and inefficient code.