ie8 fix
Click Here

Managing L'unix

Paul Murphy
Home / News & Blogs / Managing L'unix

Virtual Reality Thinking

By | June 12, 2010, 12:15am PDT

Summary: It’s too soon to comment on the SCO decision - so, instead, a thought or two on systems as language.

I got a note earlier this week from a former frequent contributor to these forums pointing me at an interesting site discussing a movie about the people who, and the ideas that, made APL great.

One of the things linked from that site is a web reproduction of Kenneth Iverson’s 1979 paper Notation as a Tool of Thought; and my response to the person who sent me the reference suggested that he consider this bit from that paper:

The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind.

in a Java context.

Since then it’s occurred to me that the core idea applies equally well to evaluation of today’s virtualization hype - in particular it occurs to me that a user using a virtual PC (running on a real PC) across a virtualized network (running on a real network) to access a virtualized server (running on a real server) against virtualized storage (running on real storage) is using an incredibly complex “vocabulary” strung together with an astonishingly convoluted syntax to treat a very narrow range of topics.

In contrast, a dead simple Solaris Sun Ray set up can treat a much broader range of topics (i.e. run more software across a wider range) with greater reliability, better security, and at a fraction of the cost.

So that’s really the question: if the statement is true for programming languages, why isn’t it also true for systems? And if it’s true for systems, isn’t today’s mania for virtualization just what happened with Java - as a result of which it has now “growed” beyond all recognition and utility?

Or, if you prefer a different formulation: how much more divergence from reality can your employer afford?

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

More from “Managing L'unix”

Topics

Range, Virtual Reality, Productivity, Programming Languages, Cloud Computing, Sun Solaris, Storage Management, Virtualization, Utility Computing, Java, Emerging Technologies, Software Development, Software/Web Development, Operating Systems, Software, Storage, Hardware, Paul Murphy

Paul Murphy (a pseudonym) is an IT consultant specializing in Unix and related technologies.

Disclosure

Paul Murphy

I do not work for, or otherwise receive anything from, any of the companies I write about. I have some money in a number of funds that bet on the markets, including the technology market, but have no direct control over how these funds are administered or what investments are made. I use Sun and Apple technology both at home and at work.

Biography

Paul Murphy

Originally a Math/Physics graduate who couldn't cut it in his own field, Paul Murphy (a pseudonym) became an IT consultant specializing in Unix and related technologies after a stint working for a DARPA contractor programming in Fortran and APL. Since then he's worked in both systems management and consulting for a range of employers including KPMG, the government of Alberta, and his own firm. In those roles he's "been there and done that" for just about every aspect of systems management and operation.

Related Discussions on TechRepublic

Did you know you can take part in these discussions with your ZDNet membership?
Ask a Question Start a Discussion
24
Comments
Add Your Opinion

Join the conversation!

Just In

PPFPPL
Erik Engbrecht 21st Jun 2010
@Roger Ramjet
I think I'll start PPFPPL - Polyglot Programmers for the Proliferation of Programming Languages to compete with PAPPL.
View in thread
0 Votes
+ -
RE: Virtual Reality Thinking
clathwell 12th Jun 2010
Yes, of course, I think you have a point. Now, I'm off to make a film about it! Thanks for referencing my blog!

Catherine
0 Votes
+ -
I think it's a subtler problem...
Erik Engbrecht 12th Jun 2010
Think about languages like SmallTalk and Lisp, where economy in terms of the core language is taken to an extreme. There's a handful of core constructs that are immensely powerful.

The problem is really effectively using these languages requires a sort of higher-order thinking that most people lack. Think of going from Java to SmallTalk like going from algebra to calculus.

Java has been so successful because it drastically the amount of higher-order thinking required to use it without cutting off higher-order constructs entirely (think Visual Basic).

Java's success and cross-platform nature have caused a proliferation of libraries, frameworks, and application servers. And choosing among these isn't a simple linear operation where you pick one of each. They can be combined in a near infinite number of ways. Java achieves a certain higher-order nature through the size and diversity of its ecosystem, but it lacks the purity of Lisp or SmallTalk.

The result, of course, is the Java-based "systems" that Murph dislikes so much, because they are an endless maze of dependencies running in big, heavy processes.

The lesson here is people tend to prefer larger, more coarse grained decisions such a picking a library or framework versus the more subtle ones that they have to continuously make in a more powerful language.

Now briefly consider Microsoft, which basically makes all the decisions for you regarding your architecture and design. All you have to do is stay within the lines.

Virtualization is a nice, coarse grained hammer. It frees IT from the bounds on physical tangling caused by dealing primarily in real servers and network gear without forcing them to think differently. Murph's favorite technologies, like Sun Rays and Solaris Containers, are all too fine grained and require different thinking. They require a type of thinking that simply isn't that common. Especially if you count all the Microsoft technology experts.
0 Votes
+ -
"Easier to do in", not "Easier to think in"
Mark Miller Updated - 12th Jun 2010
@Erik Engbrecht

Languages like Java have adopted from the beginning the idea that at least in the U.S. people learn things easiest by learning axioms and patterns. As long as programs can be constructed inside a pattern framework people are happy. I believe this is otherwise known as a "frame-based solution".

You are correct that Lisp and Smalltalk require higher order thinking, though a focus of Smalltalk developers has been to find ways to ease one's way into that higher order thinking. It doesn't have to hit you all at once. Smalltalk has a different, more advanced concept of what OOP is than do most OOP systems. I frankly find it easier to work with for some problems. .Net (and I assume Java) have adopted something like this by now, but I remember back in 2006 struggling to find a way in .Net 1.1 to economically filter a list of objects on a criteria. I couldn't find a way to do it economically, so I just did it brute force. I had just started getting back into Lisp, and I finally realized what a lambda was. I went to a demonstration where an alpha release of Linq was demonstrated, and I got really excited. I realized that this was what I was looking for, but I couldn't use it in a production project. How disappointing. Later that year I got into Smalltalk, and realized it had this ability from the beginning...back in the 1980s! All I had to say was:

newCollection := aCollection select: [:item | :item = criteria].

Done! Simple. But the beauty of this is it's constructed out of simple elements. "aCollection" is an object. It gets sent a message "select:" which contains a lambda (the part in []'s) as a parameter.

The way this would be done in a language like Java would be something like:

newCollection = aCollection.Select( criteria);

Where "Select" is a function of "aCollection". A version of "Select" would be type-selected, based on what's in the collection. In this case, the selection action is simplified down to always being "=". Smalltalk isolates the concern about the objects being compared by using a lambda. It also allows more flexibility by allowing you to say what kind of comparison you want "select:" to make.

It was experiences like this that convinced me this approach, programming with a language that was designed through a scientific process, was the better way to go. It allowed me to think in terms of the problem I was trying to solve instead of focusing so much attention on "how to get the language to do this". Another thing I realized is that the library in Smalltalk filled in the space that most programmers experience as the language, so it's possible to build what you can think of as your own language constructs just by adding to the library. Lisp is similar, though one often uses macros to accomplish this.

.Net has adopted strategies that are Smalltalk-ish without allowing its full flexibility. It's been a bit painful to watch, because you can see that the potential is there, but they don't quite go all the way to where it can go.
0 Votes
+ -
Definitely think in...
Erik Engbrecht 14th Jun 2010
@Mark Miller
I have a contention with many advocates of powerful languages (a group of which I consider myself a member). They often argue that you don't need to fully understand a language and its more advanced features in order to use the language and use the features in the form of existing libraries. They show examples such as you did, where one line of easy-to-read SmallTalk replaces a dozen lines of Java.

And I think from a purely pedagogical standpoint they're right.

But in real projects I think people run head onto them really fast. Maybe there's an existing code base that's full of more advanced constructs. Maybe a team member is an expert (hopefully!) and keeps on using them. Maybe a team member is just obsessed with shiny objects and keeps using them. Regardless, advanced stuff gets sprinkled everywhere, and if you want to understand the code base you better understand the language.

SmallTalk and Lisp are so beautiful because they're so small and their constructs to fluidly reenforce each other...kind of a network effect. But really understanding it requires something akin to enlightenment, and I don't think the importance of reaching that stage in order to work in a language professionally should be downplayed.

I think what many of today's languages are trying to do is introduce concepts from SmallTalk, Lisp, Haskell, etc in ways that are more orthogonal...less fluid. That, of course, dampens the network effects and reduces the power of the languages. But it also lowers the barriers to understanding by pre-subdividing the language up. I think people at MS and in open source are looking for the maximally powerful division that is accessible to a the majority of mainstream developers.
0 Votes
+ -
Have gotten a little into the advanced stuff
Mark Miller Updated - 17th Jun 2010
@Erik Engbrecht: In response to "Definitely think in..."

Well that was one of the most powerful examples I ran across as I was learning about Smalltalk. I've since learned about using DNU as a means of creating a proxy object, which enabled me to look at OOP in a whole new way that felt very powerful to me (it was along the lines of "object = web server" and "message = CGI request"!), and a few meta-object features that enable one to do some neat stuff that's done by IDEs on other platforms (but the cool thing is it can do this stuff at run time, not just design time).

Re: the importance of enlightenment

I agree. That's something I'm striving for. As you could tell from my example, it's a few years old now. I've used it before because I figure it's something that the uninitiated can relate to.

The main challenge I've had in trying to understand existing Smalltalk code is not so much the advanced constructs, but answering questions like, "When I do X, who's really dealing with it?" It's more an issue of understanding the system than an understanding of the language. And sometimes while I can understand the individual steps by parsing the language accurately, I don't understand the concept that's being modeled. So it makes it very difficult to try to change its behavior to something desirable. So the barrier is higher-order thinking skill, and to a certain extent a domain knowledge gap.
0 Votes
+ -
Java vs smalltalk
DevGuy_z 17th Jun 2010
@Erik Engbrecht
Java was designed to do 2 things: be cross platform, i.e. abstract the type system and endianness. Be performant. It borrowed heavily from smalltalk but still had concepts like int which are closer to the processor. In one sense smalltalk was more abstract than java.

And regarding Microsoft. Microsoft has typically been C/C++. Yes there was VB6 and .net which were popular in corporate cultures, but many shrink wrapped packages are written C/C++ which is very lowlevel. .Net itself also maintains primitive types and in C# at least you can also deal with unsafe concepts like pointers.

So in my book, smalltalk is more abstract (no primitives or processor specific entities) and the other languages less so) That's why I see very few applications written in smalltalk, not because smalltalk is too hard. It isn't performant enough and doesn't give enough control over the system.

I think I disagree with your characterizations.
0 Votes
+ -
Former frequent contributor...
Erik Engbrecht 12th Jun 2010

You blog a lot less then you used to, Murph. And about a year ago I jumped clean out of the IT-related business. I'm just a user now.

Anyway, I would highly endorse more blogs on scientific computing or computing for advanced engineering.
0 Votes
+ -
Thanks for the pointer - and the comments
murph_z 13th Jun 2010
@Erik Engbrecht

Nice to have a sensible discussion for once.

The best thing about blogging is the reader response - people like you and Mark add real value on topics like this.

Unfortunately very few people understand that these kinds of issues even exist so I tend to talk about them much here.
0 Votes
+ -
Hey Rudy
junknstuff@... 13th Jun 2010
I love to troll your blog or rather tell the truth but
topics like net neutrality or this one suck.

Since SCO took their beating earlier in this year and as Oracle
are restructuring Sun's former hardware business there has been a lack of UNIX/CPU/Raw Technology on this blog.

Now I know when you do blog it's basically Solaris/SPARC rule and everyone else sucks but that is easy to counter and fun to troll. This garbage is no fun at all and boring too.

I really think your next blog should be all about SCO.
Might as well face up to it sooner than later.
There are soooo many good parts of your previous blogs that will come back to haunt you. One of my faves is where you laid out a "Form" where people basically have to declare their wrongness and your rightness :-P Hehe.

C'mon Rudy bring it on. For the rest of your life SCO and you being on the wrong side of history will forever allow your "expertise" to be pummeled.
0 Votes
+ -
Hey Rudy
junknstuff@... 13th Jun 2010
I love to troll your blog or rather tell the truth but
topics like net neutrality or this one suck.

Since SCO took their beating earlier in this year and as Oracle
are restructuring Sun's former hardware business there has been a lack of UNIX/CPU/Raw Technology on this blog.

Now I know when you do blog it's basically Solaris/SPARC rule and everyone else sucks but that is easy to counter and fun to troll. This garbage is no fun at all and boring too.
That's basically what Erik Engbrecht is getting at.

I really think your next blog should be all about SCO.
Might as well face up to it sooner than later.
There are soooo many good parts of your previous blogs that will come back to haunt you. One of my faves is where you laid out a "Form" where people basically have to declare their wrongness and your rightness :-P Hehe.

C'mon Rudy bring it on. For the rest of your life SCO and you being on the wrong side of history will forever allow your "expertise" to be pummeled.
0 Votes
+ -
RE: Virtual Reality Thinking
Erik Engbrecht 14th Jun 2010
@junknstuff@...
Huh?

To be succinct, my points were:
1. Languages like Java (C#, VB, etc) tend to be more successful than more powerful, smaller, elegant languages because the mainstream languages don't discourage higher-order thinking while the elegant ones require it.
2. Murph's favorite family of solutions are simpler and more elegant than "mainstream" infrastructure technology because Murph's solutions require higher-order thinking.

...and I made a side point about how I don't contribute frequently anymore because my career has went in another direction, so I can't spend so much time of IT stuff anymore.

But this one is relevant, because it speaks about design. Part of a good design is that the people who need to work with it can understand it. Often times this runs contrary to elegance, simplicity, and even pure correctness. It's kind of an alternate perspective on the "worse is better" mantra.
0 Votes
+ -
RE: Virtual Reality Thinking
civikminded 15th Jun 2010
@Erik Engbrecht

So that's pretty much this blog in a nutshell. People who don't work in IT anymore lecturing those who do on how their solutions aren't 'elegant' or 'cerebral' enough.
0 Votes
+ -
RE: Virtual Reality Thinking
scotth_z 15th Jun 2010
@Erik Engbrecht
The catch 22 of a 'simple/elegant' solutions is that you are catering to the lowest common denominator of skills.. Many of these simple/elegant languages become niche markets in time... After all, Pascal and Fortran were 'simple/elegant' languages designed to be the next 'cobol killers' where are they now... This is not to say that COBOL is sophisticated, but even a 3g language is closer to design specs than java, but the point is, is where is the next set of architects going to come from for these 'designs'. I have heard many a professor lament that they are not teaching computer science skill, but just programming. They have a point. Also certain features do require some skill... Many of these features save companies alot of money. Virtualization, ILM, storage management, virtual switch technology... save alot more money than the salary of some one to implement/maintain it in many shops.

Rudy foolishly thinks that virtualization is somehow a fad..or in his words a 'mania'... Sorry... saving money never goes out of style, nor is it a form of temporary insanity.
0 Votes
+ -
Virtually thinking
Roger Ramjet 15th Jun 2010
@scotth_z

One of the biggest problems with Virtualization is well ... Problems. When you virtualize everything, you also virtualize the system problems. When a system is "running slow" (as much of them do) and you try to diagnose where the problem is - Virtualization makes your job that much harder. We had an Oracle instance running on an AIX LPAR using VERITAS volumes on a McData SAN connected to an EMC array - and I/O was slow. Every layer had its own set of tools, and those tools would always say that everything was working "fine".
0 Votes
+ -
mania != fad
murph_z 17th Jun 2010
@scotth_z
I don't deny that virtualization is sometimes useful or claim that it's just a fad - it's been around as one solution to the problem of having multiple processes share some set of resources since the 1950s and will continue to attract the same users it does now well into the indefinite future.

What I do say is that better solutions to the same set of problems were developed during the 1960s; that people who want to get better results for less money use those better solutions; and that it's madness to prefer the more complicated, more expensive, and less effective solution simply because that's what grand dad learnt to do.
0 Votes
+ -
RE: Virtual Reality Thinking
Mark Miller 17th Jun 2010
@civikminded

Re: not 'elegant' or 'cerebral' enough

This attitude in a nutshell illustrates why the simple/elegant languages haven't succeeded. It's because 'elegant' is considered irrelevant, for one thing. And I understand why it is. Nobody who pays us understands a wit of it, and so doesn't care whether it's spaghetti code or not. However, in my experience elegance = clarity = less mental load. This leads to greater maintainability and fewer bugs.

As to 'cerebral', the point of it all is not to make things harder, but to add clarity to complexity. But if you insist, I think this quote from Dijkstra serves as a good rebuke:

The ongoing process of becoming more and more an amathematical society is more an American specialty than anything else. (It is also a tragic accident of history.)

The idea of a formal design discipline is often rejected on account of vague cultural/philosophical condemnations such as ?stifling creativity?; this is more pronounced in the Anglo-Saxon world where a romantic vision of ?the humanities? in fact idealizes technical incompetence. Another aspect of that same trait is the cult of iterative design.

Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its work force. -- from "Computing Science: Achievements and Challenges" at http://userweb.cs.utexas.edu/~EWD/transcriptions/EWD12xx/EWD1284.html

@scotth_z

The basic story I've heard over and over again from people in the field is that it used to be the case that a few brilliant software engineers could create an elegant solution, and it would work from a business perspective, at least for a time. The problem came when those people left, because people find it difficult to find programmers who are equally capable--quality varies. So what often ended up happening is the people who replace those who leave just don't get what the former engineers were driving at, and so they end up rewriting it in a lower quality architecture that's messy and kludgy, but the architecture is easier for them to understand. So eventually what companies realized is that there are more low-quality engineers than there are high-quality ones, and if you're going to commoditize the field, just go with the lowest-common-denominator. Don't bother catering to the high-quality engineers ("And if you do hire them, stick them with the low-quality stuff, because they can deal with it."), because their ideas are practically non-transferrable for all practical purposes. Now, I don't think it has to be this way. It's just that skill level is so dramatically uneven.

What I find frustrating is no one's asking, "How come there aren't more high-quality engineers?" or "How do we create more high-quality engineers?" The preference is for shlub, because the assumption from hiring experience has been "That's just the way it is," and all most do is make excuses for it. You don't find this in mature engineering disciplines. There is a high expectation of quality not least because if that isn't the goal there's a high probability people will be maimed and killed. I suppose there's some allowance for it in software because in most worst cases what happens is the program crashes, the user's data gets corrupted or lost, or some money gets misallocated. It's upsetting or annoying, but not life-threatening, and so people go on with the expectation, "Oh, that new-fangled technology. It's a little unreliable," but people put up with it. The exceptions of course being if you're talking about medical applications, or controls for aircraft or something like that, in which case liability comes into play.

It's odd to me that expectations are not higher.
0 Votes
+ -
RE: Virtual Reality Thinking
Erik Engbrecht Updated - 21st Jun 2010
@scotth_z
Actually the problem with elegant solutions is that they rarely pander to the lowest common denominator...or even the 'average' person. They also tend to play poorly with inelegant solutions. I think one of the big reasons virtualization has taken off is that so many Windows server apps (and probably even some Unix ones) expect to "own" the server rather than be run in a shared environment, so cohosting them isn't really an option and virtualization is.

But virtualization also appeals to folks who think of individual servers as a atomic unit where you need at least one per app (usually at least 2).

I don't doubt that virtualization saves money. It lets people turn their terribly flawed architectures running a tons of hardware to terribly flawed architectures running on a lot less hardware. It can greatly decrease the cost of stupidity.

That's not to say virtualization doesn't have it's uses. I think it's great for development and testing. The flexibility we can achieve today using a virtualized environment in a well tooled compute cloud relative to relying on big, dedicated labs is astounding. I also think it makes sense for certain classes of web hosting because the architecture of the hosting provider needs to be decoupled from the architecture of the hosted.

In a well architected enterprise environment you shouldn't need that decoupling, or the need for it should be limited. In most real environments, well...

Regarding languages, I think you can divide "high level languages" into three buckets:
1. Languages designed for the programmer to build abstractions using lower-order constructs (e.g. Java, C#, C++ (excluding template metaprogramming - basically mainstream languages)
2. Languages designed to put the programmer "close to the spec," meaning at a fixed, predefined high level of abstraction e.g. 4GLs, assorted domain specific languages, to some extent Visual Basic
3. Languages design for the programmer to build abstractions using higher-order constructs (e.g. Lisp family, SmallTalk, Haskell, Scala, ML family, Python, C++ w/template metaprogramming, Ruby and Perl with significant use of 'eval')

Effective use of the features in #3 can put you at the same (or higher) level of abstraction as #2 without the boxing-in effect that comes with 4GLs. The problem is, unless you blindly follow the conventions of a well-developed and fairly complete framework (e.g. Ruby on Rails), in order to deal with the languages in #3 you have to really understand them and really understanding them is a lot of work. It also tends to go against instincts that have been built up over years working with languages like C++ and Java.

But back to my point...I think languages like Lisp and SmallTalk represent pinnacles of conceptual elegance, yet despite being around for decades they never attained the adoption levels of languages like Java. My argument is not that current solutions are "elegant" or "cerebral" enough. My argument is that Lisp and SmallTalk essentially contain design flaws because, in my opinion, they force higher-order thinking. Python, while not nearly as elegant, does much better job of separating the higher-order magic from the regular language features. So you have a less elegant (and considerably slower) language that achieves much wider spread adoption.

And, for the record, this isn't meant to be derogatory. A single human brain can only hold so much. Often times in IT domain expertise or generic "business skills" can be much more important than pure technical stuff. The size (and relative monotony) of the market also makes the 4GL approach highly viable. Also, this general problem extends to areas well outside of IT. I think it applies to the development of any product or delivery of any service that requires collaboration of many specialists.
0 Votes
+ -
Aren't simple languages all dead by now ?
s_souche 13th Jun 2010
Simple languages are powerfull because they are not imposing their paradigm on you. They however require you to be clear about your own paradigms.

Modern programming, for a various set of reasons, need to be very restrictive on the programmer, and at the same time very versatile...

Expert programmers tend to think this is because we require illiterate to program, with a set of very intrusive economical restrictions. As a result we're back at the connect the dots probelm. back to kindergarden... But there is no red pill, this is the real world
0 Votes
+ -
PAPPL
Roger Ramjet Updated - 15th Jun 2010
Maybe this is a good time to recruit new members to PAPPL (People Against the Proliferation of Programming Languages). It seems that anyone with a Thesaurus can create a "new" PL. In the real world, human languages are disappearing at an alarming rate - yet in IT they seem to keep growing. Ritchie named his PLs A, B, and C - so at least you could tell where they came from and what "level" they were. Seems pretty simplistic compared with today.

So if you agree that it is ridiculous to learn a new language every year - and have the marketplace reduce your experience to "obsolete", then join PAPPL today!
0 Votes
+ -
You want to get stuck?
DevGuy_z 17th Jun 2010
@Roger Ramjet
Languages proliferate because people want to find ways to do things better - tools. I would just let the free-market rule. Lot's of languages come on the scene - very few write most of the real applications.

The reality is that there are a lot of different hammers out there. Why because some hammers are better for driving different nails. I don't need a 28 oz hammer for driving a finishing nail or for doing roofing or for dry wall. It's nice that a roofing hammer has the ability to measure. A tack hammer which is great for upholstery is a lousy framing hammer. Java fills a niche because it is very portable. C/C++ definitely has a niche but I would rather use PHP for doing web pages. And my favorite C# is just a great overall language to work with when developing windows libraries and forms.
0 Votes
+ -
PPFPPL
Erik Engbrecht 21st Jun 2010
@Roger Ramjet
I think I'll start PPFPPL - Polyglot Programmers for the Proliferation of Programming Languages to compete with PAPPL.
0 Votes
+ -
Java?
tonymcs@... Updated - 16th Jun 2010
I have to object to both calling Java a success and cross-platform. While Java may have limited success in a few IT shops, it doesn't even come close to .Net and it is definitely not write once, run anywhere. If MS still had a Java runtime that installed with Windows, it might have some use in the big wide world, but these days trying to get a Java app to run on a Windows computer is difficult. Once you do download Sun's runtime, you can look forward to lots of updates and bug fixes. Did I also mention slow and clunky? Of course to mention the one benefit Java has that acts as anaethema to Rudy - it's object oriented.

I've written in Assembler, Forth and Smalltalk, Algol and Lisp, suffered through Pascal compilers telling me I was missing a semi-colon and did my time in a COBOL shop. I've done FORTRAN and C, C++, C#. Now of course, I indulge in ASP.NET, PhP, Javascript and struggle with document object models and CSS.

In the end, I use the language most scorned by Rudy et al. Visual Basic has been my primary choice for the last decade as it provided ease of use, gui design and object oriented code. Each version improved the last and it now shares the .Net Common Language Runtime. If, like me, you have apps over 1 million lines of code and a shifting population of programmers, being able to understand and test the code easily are the main priorities.

The most important factor for developers is support. No matter how much you believe MS to be the AntiChrist, their programming support is unparalleled.

Instead of investing so much blog space on pushing your own weird assumptions (Virtualisaion BAD, Sun GOOD), you might look at another problem with development - desktop versus web. Developing for the web, is much like programming before a Visual IDE existed, Given that we are essentially using a picture frame as a development environment and a variety of technologies such as Javascript/add-ons/HTML/CSS, it generally sucks in comparison to any modern desktop development environment. So, done any programming at all lately Rudy?
0 Votes
+ -
Can the SunRay talk to my hardware?
MeMyselfAndI_z 17th Jun 2010
I have a lot of custom hardware at my desk that I need software to interact with. Various bus architectures are used and some at high speed. Typically I use VMs because they can be snapshot copied (duplicated) and if they get messed up restored.
0 Votes
+ -
RE: Virtual Reality Thinking
JoeKach 19th Jun 2010
As an ex-programmer who went on to systems analysis, the beauty of COBOL was it's ability to debug when bad or unexpected data caused a programme to crash at 3:00AM. It was simple to code, simple to read, simple to enforce one function, one programme, with JCL to tie it all together, and the determine what went wrong, especially if coding standards were maintained, IE write the bad/unexpected record before causing a dump.

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

Blog Roll

Blog Archive

White Papers, Webcasts, & Resources
ie8 fix