C++ is the language that most of Microsoft’s big-name products are developed in and one of the most widely-used languages in the world. Charles Torre and Scoble interview Herb Sutter, architect on the Visual C++ team, in two parts. First part is up today, second tomorrow, which includes a small tour of the team. In this segment Herb talks about some of the language and compiler changes that are coming in the next version of Visual C++ and where C++ fits into the managed code revolution.
This teechno exists since the early 70s. Where is the Revolution?
Beyond that, as a software developer, I have to say that it doesn’t
really matter if you have managed or unmanaged code.
It DOES indeed matter if you have clean or messed up code.
There is no revolution, because software development is hard, has always been hard, and always will be hard. Lisp is arguably the best programming language, yet it has been around for decades. We really haven’t learned a whole lot of new stuff regarding programming, just little improvements here and there.
…when limitations of human consciousness, namely memory and mathematics, can be drastically improved upon.
The revolution is that managed code has become more mainstream and accepted as a viable business solution for mission critical systems.
Lisp is arguably the best programming language? It has its place in acedamia, and lends itself well to AI type programming, but outside of that (and in my 6 years as a professional developer) I’ve never seen it used in the corporate IT realm. Period. Main reasons being it doesn’t lend itself well to RAD development, and the main subset of business developers out there lie in one (or more) of the following realms: C/C++, MS languages, or Java. I have come across a handful of Smalltalk developers, but they all were fully versed in another business language in addition to that.
The “best” programming language is the one that best solves the development task at hand against business contraints (i.e. time to market, cost, resource availability, etc), and for that there is no one single language; it always depends on the project.
One meaning of Revolution is “A turning or rotational motion about an axis”
So it is a revolution, because we have now gone back to the beginning, and reinventing the wheel. Managed code is old, but now it is back, its cool, its hip.. its a way of selling more copies of Visual Studio.
There is no “best” programming language because each programmer brings their own prejudices into programming. One programming language seems to fit more naturally with the way that each programmer uniquely solves problems.
One problem is that many programmers get rooted in their own language/libraries world and don’t want to venture outside of the domain that they’re comfortable with to see what else is out there.
There is a double-edged sword to corporate development of programming languages. Large corporations such as Sun and Microsoft have great engineers and lots of resources to put into language, runtimes, libraries, and tools, but they also tend to be conservative. We’ve seen this with the progression of languages that have their roots in C(Algol really). From C++ to Java to C#. So you get great tools with these languages, but there’s not much innovation.
Sun research had Self, which had some innovative concepts, and Apple had Dylan which had some innovate (mainly borrowed from Lisp) concepts, but Sun decided to go with Java and Apple went with Objective-C.
Java, C#, and C++ do their jobs well, mainly because of the tools, frameworks, and library support. But even Java and C# are really systems languages.
Personally, I’d rather write low-level stuff in straight C and everything else in a language like Python, Ruby, or Smalltalk, but that’s just me. I bring my own prejudices to the table.
And of course there are other factors such as deployment options – languages like Smalltalk, Python, and Ruby have “historically” never compiled down to an executable even though there are tools to do that. An IT manager also has to worry about finding people with skills for the projects that have already been written. Lisp might be the “programmers programming language”, but if you can’t find anybody to maintain or add to Lisp code then it’s a moot point to the corporate IT manager.
Managed code is old, but now it is back, its cool, its hip.. its a way of selling more copies of Visual Studio.
Maybe you should wake up to reality. Managed code for Microsoft has nothing to do with selling copies of Visual Studio. The fact is that Microsoft would rather just give away their tools.
Managed code solves problems for Microsoft such as security concerns and gets rid of the clusterfuck that is the win32 API.
It has its place in acedamia, and lends itself well to AI type programming,
Java and C# are used in academia too, so I’m not sure what you mean there. Also “AI” is a vague term, what is “AI type” programming?
I’ve never seen it used in the corporate IT realm. Period.
There are a number of commercial Common Lisp vendors providing commercial Lisp implementations (LispWorks, Allegro, Corman Lisp, DigiTool). Now, hybbyists prefer to use the open source Common Lisps such as SBCL, but somehow these vendors continue to stay in business. So somebody with deep pockets buying their products; sounds like they have a lot of corporate clients.
Main reasons being it doesn’t lend itself well to RAD development,
Can you explain? I think most Lisp programmers would say that Lisp is the best “RAD” language that exists.
I think the biggest obstacle to Lisp adoption if it was a world where every programmer could choose their own tools is the prefix notation.
I think the Apple Cambridge research guys realized this with Dylan, which has much of the power of Lisp (such as a very CLOS-like object system) with an infix notation. Actually, there were versions of Dylan with prefix notation.
Well, Dylan didn’t get popular either, so I don’t think it was the infix -vs- prefix issue. Prefix is a non-issue as far as I’m concerned. Most code you write is not mathematical code — and advanced math algorithms benefit more from features like higher order functions and closures than they do from infix notation.
I just don’t like infix for the fact that you have to “peel the onion”. You have to go inside-out. It’s not that I can’t get used to it, but something like Dylan (Apple dropped it like a bad habit when the NeXT crew came in), can give you 90% of the power of Lisp without the prefix notation.
Indeed, Java and C# are now taught in acadamia, however they were not born directly from it (albeit they definitely borrowed concepts from many previous academic languages, Lisp (and others) being one of them). I’m not saying this is either good or bad, but any compsci/MIS student wishing to enter the corporate IT realm simply must have some exposure to one of the big 3 platforms: Win32(VC++/Legacy VB), Java, and .Net (and to some extent the C libs on *nix), and this is why institutions are now teaching these languages. Most of the “pure” academic languages lend themselves to a specific subset of programming and aren’t viable as APPL’s. Those that have made the transition have done so w/ numerous bolt on libs/compilers/IDE’s/etc.
AI == Artificial Intelligence, something Lisp lends itself very well to. Bear in mind I’ve done virtually no Lisp development, this just seems to be a general concensus from the Lisp folks I’ve spoken with over the years.
Of course most Lisp programmers would say that Lisp is the best RAD language that exists; as a C# guy I would say the same thing about .Net. I’ve *never* heard Lisp touted for its RAD abilities, and perhaps it doesn’t need them. There is no need to force a language into doing something it wasn’t originally designed to do. As has been said already, choose the best language for the situation.
If you’ve never used Lisp, then how can you hold an opinion about it? You won’t catch me bashing, say, Delphi. On the other hand, I can say that Java and C# are really bad for RAD, and most people I know say the same.
Lisp programming _is_ RAD development. Lisp is rediculously expressive, extensible, and elegant. The reason people hate it is the parenthesis and the fact that the only really good Lisp environments are expensive.
I’m a hard core UNIX guy, but even I admit that C and UNIX were the “Microsoft Windows” of the 1970s. Cheap and “worse is better” won out, just like Microsoft is the “worse is better” of the 1990s. Thankfully, UNIX is coming back, making Microsoft “worse is just plain worse” of the 2000s.
Well, I have use Lisp and it’s NOT a RAD language. It can be used to develop a RAD language because of it’s DSL macro capabilities, but in itself it’s not.
Lisp has the same problem that smalltalk, scheme, and other languages have. There is no real standard, there are only implementations.
Scheme is a clusterfuck of incompatible implementations. Lisp is a bit better because Common Lisp is a larger language in itself.
Well, I have use Lisp and it’s NOT a RAD language. It can be used to develop a RAD language because of it’s DSL macro capabilities, but in itself it’s not.
Rubbish. I’ve recently developed two Web applications on OpenMCL, and there’s nothing more rapid than being able to redefine functions and handlers in a REPL while the server is up and handling requests. The whole point of a Lisp (or Smalltalk, for that matter) environment is that you can interact with the running environment, allowing you full integrated debugging, exploring, and editing. Take a look at the Lisp machines (e.g. Symbolics Genera OS) for an example.
Any language which requires a compilation stage isn’t really RAD, no matter what the vendor says. The closest I’ve seen is Delphi, because the compilation is so fast, but you still have to restart an application if you want to change the functionality of a button, for example. That’s not the case with a Lisp, which makes it very ‘rapid’ indeed.
They seem to be getting more popular for some reason, but spending 23 minutes to watch something that I can read in 5 minutes…not particularly efficient…or did I miss the transcript?
I think there’s some confusion here about the definition of RAD. Of course, literally it just means building an app quickly, but the people who don’t think Lisp is a good RAD environment seem to be using the “slang” definition; i.e. something more like Delphi/VB/JBuilder, where you visually build the interface by dragging components around, then code the guts in an editor. I do a little VB at work, all database-interface programs, and there’s almost no complicated code in my work; the interface is most of the program. If I had to, I could whip up another such program very quickly, and I think this is what the “Lisp is not RAD” people mean.
I’m studying Lisp now, and I find I like it more every day. It is sometimes verbose when doing really simple stuff, like quarter-turning a square array(I’m using Paul Graham’s book.) However, it seems that Lisp was designed for complex algorithms, and that’s what the people who say it is a good RAD system mean. Having the interactive interpreter means you can rapidly test pieces of a complex program, which can’t be done in an edit/compile/debug system. I can appreciate this even at my early stage.
So, the VB type systems are RAD for interface-intensive programs, and Lisp is RAD for intense-algorithm programs, which is why it was big with AI; those people do more computation than interface development. Did I misrepresent anyone?
I just remembered something; I read on Andy Hertzfeld’s Folklore that Microsoft programs for the early Mac were compiled to byte-code, and run through an interpreter. If so, aren’t they just catching up with… themselves, 20 years ago?
“I just remembered something; I read on Andy Hertzfeld’s Folklore that Microsoft programs for the early Mac were compiled to byte-code, and run through an interpreter. If so, aren’t they just catching up with… themselves, 20 years ago?”
Technically this was java way back then, without some features I’m assuming – like garbage collection and OO. I don’t know the specifics so I’m guessing?
Anyway, this link says it best…
http://mail.maclaunch.com/Lists/lisalist/Message/630-P.txt
“One interesting and little know fact about Microsoft and their Macintosh
programs is Microsoft originally used an internal development system for its Macintosh programming. This system was never released to outsiders for their Macintosh work. This was a DEC VAX based system whose main language was C with a bit of 68000 assembler support too. Microsoft did not use Apple’s Lisa Workshop for its Macintosh progamming as most other Macintosh developers did. Microsoft’s development system for the Macintosh produced a variant of p-code (p=pseudo) which allowed them to create object code for a single platform (the p-machine) and then have just a p-code interpreter running on the host computer. I do not believe Microsoft uses p-machine technology today for its programming efforts since p-code is slower than normal machine code.”
From what I remember, the performance wasn’t great and since it ended up being only Intel/Apple, there was no need to worry about cross-platform support anymore.
and also
http://cc.msnscache.com/cache.aspx?q=1010131318682&lang=en-US&FORM=…
“I was to write the so-called “p-code C compiler” that was crucial to Charles’s business strategy. His strategy came to be known as the Revenue Bomb.
Here’s how the Revenue Bomb worked. You would list all the different business products that Microsoft would develop on the horizontal axis. On the vertical axis, you would list all the different personal computers that were coming out from the dozens of hardware manufacturers. The p-code C compiler, which I named “CS” and which was used for more than ten years to develop Microsoft application software, would allow us to create separate versions of each product very easily for each of the different machines.
What we didn’t realize — nor did most people in those days — was that there wouldn’t be dozens of different PC architectures competing for the market. There would soon be only two: IBM’s and Apple’s Macintosh. But CS gave Microsoft the upper hand for many years in developing Mac and IBM applications hand-in-hand.: