Thinking In .NET

Access Thinking in C# (pre-release version) and more in the Library.

Free C# Compilers

Personal Homepage

My resume

I'm actively looking for contracting gigs. Whether you need mentoring, writing, or someone to just "shut up and code," I will exceed your expectations at a very reasonable rate. I'm located in the San Francisco Bay Area.

Click here to send an email to the editor of this weblog.

Thinking In .NET

Code, industry analysis, and miscellaneous cross-links from Larry O'Brien, the former editor of Computer Language and Software Development magazines.

To receive an occasional announcement message regarding my seminars or publications, please subscribe to my mailing list.


Monday, January 13, 2003

Top Ten Vulnerabilities of Web Applications Well worth reading.
12:55:53 PM    comment []

Bacteria Memory. Scientists have successfully stored information into artificial DNA strands and injected them into bacteria that maintained the data by reproducing. via [The Daily Nugget]

So... has anyone done the obvious corollary to this and looked for a smiley face embedded in the human genome? 

12:22:34 PM    comment []

25 Pathetic Attempts to Make .NET Look Bad Fun stuff, especially the comments.
11:41:16 AM    comment []

Met with Serguei Dmitriev and Eugene Belyaev of JetBrains, the makers of IDEA, the best IDE for Java. I was trying to show them some of Marin, but just as we got to the ocean, it started pouring. "We're from Russia," they said, undeterred. We walked for, oh, 3 minutes before retreating to a bar in Sausalito. They're looking for star programmers.

11:30:38 AM    comment []

The future is not objects

Managage code is language-neutral, right?  No!  Right now the CLI is very much tilted in favor of Object-Oriented languages (C++, C#, VB, Java).  This is fine for now, but looking around the computing landscape leads me to a hypothesis:

Hypothesis: The interesting programming models in the next three years are not going to be Object-Oriented in nature. 

There's just too much interest right now in other ways of doing things.  XML andWebServices for example are both non-OO at heart (heck, guys like Tim Ewald and Don Box have even been talking about the joys of weak typing).  This hypothesis is sort of academically interesting, but there is a corrollary:

Corrollary: The long-term success of the CLR may hinge on its ability to accomondate non-OO models of programming

and this is an interesting idea to me. So, Discuss.  Am I all wet?

[Managed Space]

No, you're perfectly dry; I ranted similarly the other day. Object-oriented imperative languages are a pragmatic sweet spot today, but there are other programming paradigms thare are known to be more productive in certain situations. Several of the most talked-about challenges of building applications today such as persistence strategies and "business rules" are fundamentally easier to solve non-imperatively. The history of visual form builders, which are a type of non-imperative programming, argues for your point -- the primacy of reflection in language and library design emerged largely because of the realization that visual form-builders had become a necessity. So while visual form-builders are layered on top of OOP, they fairly dramatically influenced language and library design. Some changes, though, such as new multiprocessing paradigms, will undoubtedly require evolution (or even revolution) of the CLR. I'd submit that Microsoft's behavior re Rotor compared to Sun's behavior re the Java Community Process is a much better strategy for evolving the fundamental substrate of their platform.

9:32:04 AM    comment []

The contents of these pages represent the opinions of one person.
All contents © 2003 Larry O'Brien. All Rights Reserved.



Search ThinkingIn.NET

January 2003
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Dec   Feb

Click here to visit the Radio UserLand website.

Subscribe to "Thinking In .NET" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.