Discussion on:

Poll: Does Microsoft 'move the cheese' too often?

... to PHP.

Hope I'll manage to turn it into cash some day.

Granted, not all of them work in every scenario though. But it's kind of been a tough decade for UI/Front ends what with not necessarily the end of the dominant desktop but rather an elevation of web design, then the desire to bring desktop design to the web and then having to incorporate more mobile functionality with touch and ergonomic usage in "native" apps again so really...I think it's a lot to take in...even more to master but in the end, MS is a victim to technology as much we are and I think with all of these flavors, they're just trying to cater to the developers and saying "here, pick one!"

... but Microsoft stops work on them, for the most part... and employers generally want the "newest". ASP.NET MVC came out a few years ago, and it was "cutting edge" but now it's the only thing folks want, so unless you know it you almost don't seem to count as a .NET Web developer anymore, for example.

J.Ja

Its definitely difficult to stay marketable with everything that's out there but I just think that things, including those outside of MS's control, are moving so fast that no one really has the time to refine their own tools. Apples design strategy has been a luxury for them as iOS has pretty much stayed the same and the same goes for pure web technologies. Its all one huge nightmare.

The TIOBE software index lists the current popularity of programming languages. The top three are C, Java, and C++. These are all older technologies. I would suspect that employers are playing people to write code in these languages. Here is a link to the index:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

These are al demands for "app" builders. And the index is based on search results from various sites. These are not the most popular languages but the most in demand by recruiters

>> and employers generally want the "newest"

yes, a lot of them do; and they end up spending insane amounts of development time and money for little if any gain and, in some cases, completely failed efforts and/or ongoing frustration with "not being able to find the right people"

Nobody has to stay on the train, so I'm not really sure it's even Microsoft's fault .... I can think of a few companies I've worked with who just stuck with "ancient" technologies like Classic ASP or VB6 and still run SQL Server 2000. Their stuff still works fine and one of them just sold his 12 person company for about $60 million; the founders are unconcerned about the developers who sneered at their dev stack

Part of what made me turn away from MS technologies was when they came out with WinFX (.Net 3.0), it felt like they were telling programmers, "We don't need you anymore." I went to a DevDays demo *for developers* and all they talked about was system configuration and XAML. During intermission I asked somebody whether I was in the wrong auditorium, because I thought the information presented was meant for IT managers, system administrators, and UI designers. I saw very little programming.

Another part of it was MS's whole development strategy felt very uncoordinated. I remember Ballmer saying that they were speeding up their release cycle, because developers were asking for that, but that threw me off. The thing that used to be attractive about MS's developer tools is you knew they at least tried to make everything work with each other (even if it didn't always do that 100%). Leading up to their .Net 3.0 release, you had to check the compatibility of everything, because you couldn't be sure whether thing A would work with thing B, even though both were from MS. You've seen that more recently with MS's MVC framework for the web. As you've seen as well, there have been times where they've released technologies that are not integrated into VS, though they are eventually.

I'm a different story, though, since I haven't done development professionally in a while. So I haven't had to deal with trying to find out what the market requirements are as far as if I switch to X technology, what do I need to know to be useful with it to someone else.

Skruis makes a good point that MS has had to adjust to customer demands. The thing is WPF/XAML was a complete redesign. It wasn't just an update to WinForms, which kind of begs the question, "Well, if they thought WPF was better than WinForms, why didn't they come out with that in the first place?" It wasn't that they anticipated RIA with WPF and not with WinForms. WinForms was internet-aware, though a bit heavier on the client end. Metro is once again a total redesign.

When you're talking about Ruby and PHP, though, you're not necessarily targeting a rich client. They're mostly used purely on the web. So you're kind of talking about apples and oranges. If you were only on the web, I don't think you would've seen as rapid a change even with MS technologies. The only significantly new web technology MS has come out with since ASP.Net is MVC, and its associated technologies, right? It's the rich client end that's gotten most of the churn.

Revolutionary change (as opposed to evolutionary change) is a major problem with the Microsoft platform. I hate being constantly de-skilled. Having also worked professionally with the LAMP stack, I marvel at its ease of use and rapid development thanks to not having to debug .Net's "mystery layers" as well as its fairly consistent development over the years.

If it paid as well to work with LAMP as the Microsoft stack I'd definitely cross over full time.

... that I can't continue to keep up with the .NET stack unless I can roll up the training costs and time into my standard work day. There's just too much!

For the last few years, my job is mostly maintenance work on existing .NET code written to "old style" stuff (WebForms, ADO.NET, SOAP, etc.). For me to catch up, I'd need to consume 4 or 5 600+ page books, and write a full-scale enterprise application on my own. That's not a welcome thought.

Meanwhile, a single 400 page book can get me where I need to be for Rails...

J.Ja

I've basically given up on Microsoft *native* UI technologies. WinRT looks promising simply because the Windows Division is behind it (unlike past UI technologies). But I'm so disenfranchised with Windows that I find it difficult to get excited about developing for it. It's not just their dev technologies, it's their services as well (i.e. Live Mesh??).

I love the C# language and ASP.NET MVC. Especially MVC since they've open sourced it. I'll be living there for a while to come. I'll stick to JavaScript, CSS, and HTML for my client side coding. Perhaps Phone Gap will be in my toolbox at some point in the future. There's always Mono projects as well. Either way, it won't be native Windows projects unless there's a project that comes along which is a nice fit for leveraging the WinRT stack.

Also, comparing the "churn rate" of native Windows technologies to Ruby is a bit misleading. Ruby is web based and the only true analog for .NET is ASP.NET MVC, which is quite nice in my opinion.

Look at iPhone development, everyone has to update their apps at every iOS release. At least Microsoft Windows still runs most old programs. Nobody has to move to the 'new technologies'. In reality there is still just Forms and XAML anyway.

Justin,

To appear unbiased I would expect you to put an option 'Yes but I kinda like it'

removed

Firstly, HTML is *not* 1980's technology - it's from the 1990's. Take it from a guy that worked with a lot of '80's tech.

Secondly, I have made desktop applications in Python (I've made some mediocre browser apps in PHP as well, but I've never really cared for it... IIRC, you *can* make desktop apps in PHP, but that's certainly not it's strong point.) - I've made graphical cross-platform apps in Python - they ran without code changes on Windows and Linux without issue.

I used to program in Visual Basic & a little Visual C, but when .Net came out is when I decided to jump ship to more 'free' platforms, and I've never looked back. Microsoft is the apex of "Vendor Lock-in" IMHO...

In the interest of full disclosure, I do a fair amount of programming, but that's not my primary function; so my programming skills (while decent) are not up to snuff to someone who programs full-time and has the time to keep up with the latest developments...

Oh, and by the way: If you're having issues with potholes, get a 4x4 truck like I have.

removed

A lot of what was in my previous post was opinion, so if you disagree with my opinion it doesn't make me wrong or you right - it just means that we disagree.

Quote: """Where did I say it was not possible, I said you ever tried... slight difference."""

No, I have not, as I opined (maybe not clearly enough) that PHP was not the best tool for that particular job. Python, on the other hand, is a much better tool for cross-platform desktop applications, and for my particular needs (apps that run on both Windows & Linux) .Net does not do what I require.

Quote: """And I went the opposite way, from perl, python and cgi onto Java and into .NET."""

If you do most of your programming in the Windows realm, then to some (and certainly to you) that could seem to be a logical progression.

Quote: """You don't find Apple the "lock-in" vendor (it is their strategy) or Google the "lock-in" search dictator... ignorance is bliss."""

WRT to Apple's lock-in: Pre-OSX, yes, I thought Apple was the lock-in master; but since their move to BSD, it's *much* easier in certain instances to find cross-platform applications and server daemons (i.e. Postfix) -- and those instances seem to hit closer to home for me than for others. BTW, I never said Apple didn't lock you in -- and in the iPad/iPhone area their walled garden has *really high walls* - which is why I don't have those devices. I don't have a Zune, either (are those even still being made / marketed?). IMHO, nowadays for vendor lock-in, Apple is one or two bricks lower than the Microsoft keystone now. Still way up on the arch, but no longer at the top.

Quote: """On a Microsoft platform I can run al sorts of languages, services and programs that can be run on Unix based systems."""

Was it Microsoft that made that happen, or could it have been a bunch of enterprising 3rd-party programmers that put in a lot of hard work to bring those applications to the Windows (and other) platform(s)? And how many of those platforms *don't* work with OSX? It's much more difficult to port a Linux application to Windows than it is for OSX; and vice versa. I do have a question: How many platforms other than Windows does the .Net environment run on, anyway?

Quote: """And 4x4 truck are so 1980, get something that plans for a greener future. """

If 4x4 trucks are "so 1980" why was my Avalanche built in 2004? Besides, I would find it quite difficult to fit all my DJ equipment in a Prius, let alone haul my 18 foot travel trailer with one. Where I live, 4x4 trucks are the norm for the region, and quite often *necessary* for the local climate:

http://en.wikipedia.org/wiki/Sault_Ste._Marie,_Michigan#Geography_and_climate

[[ For those who choose not to follow the link: In December 1995 during a 5-day period we were "blessed" {sarcasm} with 62 inches of snow. ]]

...and for the record, my Avalanche *is* flex-fuel approved.

removed

is why I moved from the U.P. to Arizona. Three consecutive years of snowfall records. At least I don't have to shovel sunshine!

When I first got to this message, you had a net vote total of negative two on this comment. Reading through what you said, I see absolutely no reason for that. What's going on with these votes? The only person who responded negatively, as far as I can tell, is someone whose comments have been deleted -- so there's no explanation for the hate.

I'm not a .net dev, but it's always seemed to me that MS is always trying to have their toolset and framework work across all their platforms: desktop, laptop, web, web services, mobile phones, and now tablets. Maybe having to satisfy some requirements of one of these target platforms causes enough changes that they need to stop the old platform, and make a new platform. Repeat for each platform.

Here's an example (that'll make me sound like a dino or a noob). I code for our office's Access database. There's a really weird mix of DAO api code and ADO api code. After digging into the issue, a couple reasons for ADO quickly jumped out for me - N-tier applications with greater demands, and more mobile client/server apps required some of ADO's features. Fine, but for what we needed, DAO was fine, even preferable, 90% of the time.

Likewise, I thought I'd go along with MS's push to move developers off of VBA running inside Access, and toward .NET apps using the Office PIAs. Well, for our organization, it turned out that really didn't make sense. I know VB6, VB.NET and C#.NET, but using any of these, and .NET, significantly raised the bar for hiring my replacement if I leave the organization. Besides, the Access environment is really correct for our uses, which are generally small databases.

...it would be accused of standing still.

The issue is not how often Microsoft (or any company) changes its technologies, but how well it documents those changes, and how easy it makes the conversion of existing software. I suspect all companies fail badly in these areas. (As a technical writer, I'm virtually certain of it.)

could not agree more ... personally, I think the lack of high quality documentation and training is the #1 problem in the dev world

Justin isn't complaining that MS keeps changing the OS/feature set. That's been part of MS's business model practically since its beginning. I don't *think* he's complaining about changes to their languages. (What do you think, Justin?) He's complaining that they keep changing the frameworks they expect developers to use.

Why did MS go the route it did with its pseudo-object-orientation in .Net? (Java and C++ are afflicted with this as well.) Was it just because the paradigm was popular? It seems to me MS has not understood the power of abstraction. If they did, they wouldn't find it necessary to keep changing their frameworks as much as they do.

The issue isn't that they make changes to the languages. No one's complaining that they added generics or closures to C#. The issue is the constant churn in frameworks and libraries. Every few years we're being told to "move on" from, say, ADO.NET to Entity Framework, and it's rarely an easy transition.

J.Ja

confusing thread; Mark may "have it right" about what you're complaining about (and not) but he was responding to GrizzledGeezer, who never said you WERE complaining about changes to the languages

I still think you were correct to assign the problem to employers who want to adopt every new, shining object that comes along; it should also be said that not all of these come from MS .. I keep on hearing about job requirements with demands for skill and experience with every trendy methodological "innovation" under the sun

I got this sense years ago that one of MS's business strategies was to release a set of desired features in its OS as quickly as possible. It didn't matter if it was a bit messy. To them, it doesn't matter if they understand how to deliver it well. Just get it out there. Then with each subsequent release, they'd learn how to deliver those features better, at least within the framework of their design concept, which I can see now sucked. Let's put it this way. They made the best of a bad situation... Meanwhile the customer base was paying them to do that the whole time, even if they were not cognizant they were doing it. Nice work, if you can get it, though I think the strategy has dubious value for the customer. From what you're describing, it sounds like they've been doing the same thing with .Net over the past 10 years. Summarizing one of my points, I think the reason you're experiencing this large amount of churn is with each iteration they're understanding better how to do what they originally set out to do. Each time they're saying, "That thing we did before sucked! Let's try this approach," until next time... In fact, I used to hear MS engineers say that literally, "That approach we took before sucked. This is better." Then I heard from others that they had said that before the time I heard it. They keep repeating the same pattern.

It's disconcerting to learn that the thing they said was so great earlier sucks now. They should try creating something that when you look back on it doesn't suck. Wouldn't it be nice to look back on something and say, "Yeah, that's old hat, but it's still a thing of beauty?"

"Each time they're saying, "That thing we did before sucked! Let's try this approach," until next time... In fact, I used to hear MS engineers say that literally, "That approach we took before sucked. This is better.""

Yup, exactly what's going on. If you look at, say, .NET data access technologies, what happened is that ADO.NET was designed to build on top of and not be too different from technologies that Microsoft's customers already knew and were comfortable with, like ODBC, even though they were not really the best way to do things. When the limitations became too obvious to ignore, then they finally tried to move to Entity Framework, but their initial release was awful. By the time EF4 came out, EF had a bad reputation and few people really wanted to use it, and folks who did want a similar technology had checked out the competitors.

One of Microsoft's biggest weak spots is their dedication not only to backwards compatibility, but trying to build on top of and extend older technologies that are the wrong approach for the issues at hand. Yes, at SOME POINT in the chain, there's going to have to be a "don't do that, do this" moment. The difference is, with other systems, it's whole hog and done once. IE, you switch from C++ and Qt for native apps to PHP or Ruby on Rails for Web apps. And and over. But with Microsoft, you are being dragged along this slow, bumpy road where every few years it changes enough to basically be "new" and cause a ton of learning, but not enough to ever be "right", so the process needs to keep repeating itself.

J.Ja

There's been more attention paid to the importance of architecture in the Java community than there's been in the .Net community. The reason for this, I think, is that historically people from the Smalltalk dev. community in the '90s came over to Java once they realized that the Smalltalk community was not "with it" on the internet (at least at the time). It also got adopted in the CS/open source community within short order. Having said that, all is not great in "paradise." The Java language has many deficiencies, IMO, but among the community there is more of an openness to looking at new ways of doing things with the JVM, even if it's a bit impractical. It just always seems like those people are in the minority. Maybe it's a large minority. They get noticed, but they always seem to have trouble gaining much traction. Clojure seems to be the latest craze in the "alternative Java" community. It's been nice to see this sort of thing developing in the .Net community with IronPython and IronRuby. The same phenomenon is present in that scene.

I think you're right that MS tries to make "the old way" work until it can't do it anymore. This is a pragmatic approach for them. History has shown that if you get too far ahead of the crowd in this sort of thing, you really lose people, though sometimes it's been unavoidable for MS. Remember what happened with VB.Net. Ruby has taken years to grow to where it is now, largely thanks to Rails. It's been a slow process. One area where it's been getting converts for years is from the Java community.

Scala seems to be pretty popular amongst the "alt. Java" community as the language of choice for people doing development for Android and similar targets, from what I've seen. It would be interesting to see Clojure make some real gains in market share, though. Guy Steele famously said of the Java team's goals:

QUOTE: "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren???t you happy?"

I always though that was a ridiculously overblown estimation of what they accomplished. There's no what that I would characterize Java as being halfway from C++ to Lisp. With the advent of Clojure, however, that may finally be the case; the JVM provides the environment for something that could get halfway from C++ to Lisp.

the JVM provides the environment for something that could get halfway from C++ to Lisp.

Maybe that's what he was talking about. The C++-ness of the language was "eye candy." It's been apparent from Java's history that the reason they gave it a C++ look was to draw those programmers in. In fact, the JVM was based on Strongtalk, a VM that was being designed in a lab at the time to run Smalltalk. Sun bought it and used it (or aspects of it) to create the JVM. I'm unclear on how far along it was in its development, and what Sun did with it after they bought it. They didn't have to give Java the syntax and semantic rules you see, as is apparent from the alternatives.

I remember at the last Lisp user group meeting we attended together I said I wasn't sure what made Lisp seem to go easier for me the second time around. I suggested that maybe Java had something to do with it. After I said that I remember thinking I had given it too much credit. I came to understand FP better in a senior CS course I took in college on programming languages, though we only used SML for that. In that course we talked about how interpreters and garbage collectors worked, plus the principles of FP and OO. I remember when I first learned Java that going from pointers to references wasn't a big deal. I'd say that's been the only thing to which Sun "dragged" programmers. Their language design didn't help "drag" them further. Alan Kay criticized Java on a few fronts. One of them was the language designers thought they were doing programmers a favor by giving them a familiar environment, when in fact they were damaging the programmer's ability to really understand the power of programming. I get that, but at the same time I can see what the Java team was getting at. If you get too far away from the familiar, most programmers reject it. Lisp still has that problem.

At the last meeting, I got to talking with someone about this, that there is a bridge to Lisp for many programmers, and interestingly Java might have something to do with it, though not in the way many people expect. I read an article several years ago saying that XML is just S-expressions with angle brackets. I realized during our discussion that this was not the same as saying "XML is like Lisp," because many of the tools that use it lack Lisp's recursive nature. The guy I was talking to said that in Lisp you can nest expressions inside each other, but tools that use XML force you into using it in a "square-ish" way. Well, okay. I just remember that when I first learned Lisp that the concept of S-expressions, and how they were turned into list structures, and then executed, was foreign to me. Another hurdle I didn't think about is getting programmers to think about programming in terms of recursion.

Bill Joy, in the history, talked about trying to convince Gosling to include features like lambdas, continuations, etc. in the initial release of Java. Gosling rejected that idea, saying he wanted to create a "workhorse" language that programmers could understand and use to "get things done." He didn't want to make it "theoretical." This had the feel of, "I wanted to cripple it for cripples, so they'd find it more useful." I thought when I read that, "Well why not include the architectural capability to do those things in the JVM, but don't surface them in the language at first, if you're worried about that. As you expand the language, surface them later. This way that ability is already 'baked in' rather than bolted on later?"

From what I've seen, Java (the language) has a "shelf life." They've expanded its feature set as far as they can with its design legacy. The best way for it to move forward is to encourage the development of alternative languages on top of the JVM.

Working since 2005 only with asp.net (even for mobiles) + Ironspeed. No problems.

I'm just curious about what you mean by "are you look for ..."?

In the late 90's I had enough of the constant changes in Netware and recertification every 6 months. Netware 4 was the end for me with such a dramatic change in structure but it was the increased complexity. I switched the entire corporation over to Windows NT. Now MS Win8 is proving to be their Novell moment for me. I'm now in the process again of looking for tools that span platforms and are more stable i.e. Java is looking really good and PHP is a natural option for the web.

When a company looks solely at its bottom line and forgets about their customers the bleeding edge becomes a noose. Reminds me of the old saying, "The tighter you squeeze the more it slips through your fingers."

I am recently graduated and have been going through some issues. I do not know where to focus my attention in learning scripting and oo programming. What you are stating in this article is the general fear I have. I am questions whether it is worth it to jump on board with the .NET world and be forced to keep up with this constant self maintenance and growth or push toward more open source languages and technologies to give me a more well rounded skill set. I just shudder at the thought of putting any time into anything with no pay out. Is Microsoft where the money is at?

There's money in .NET, in C++, in C, in Ruby (especially with Rails), in Python, and so on. You don't have to pick one particular platform or technology stack to get paid.

I used to hear from .Net developers that as of .Net 3.0 you had to start specializing is specific areas of the framework (WPF, WF, WCF, etc.), because you couldn't master them all. There was too much to learn. I don't know what that meant, since I got out of .Net development around the time of Ver. 2.0.

What I've noticed is that language flexibility changes with platforms. The language is a secondary concern to the task at hand, and it conforms to IT org. priorities, which are mainly functionality, and these days, security. You might find some web applications done in C or C++ (C++ and Perl were a popular combo for that more than 10 years ago), but I'm thinking that's unlikely now. My understanding is they're mainly used for open source and embedded systems development now, though I'm sure there are still end-user applications still around written in C++, along with VB 6/COM. I think for IT/business/database operations it's mainly Java, .Net (C# and/or VB), and XML, along with web technologies these days, though you've shown a flair for using alternatives in that environment. Considering the emerging mobile market, there's C, C++, and Objective-C on iOS, with Obj-C being the main one used. Apple has usually allowed alternatives, though my understanding is that's fairly rare, given their fickleness. I don't know what's used on Android.

As I hope people discover, though, design dominates materials. The choice of architecture (or architectural design) in a runtime is part of the overall design of a software system. Different architectures are represented by different languages. So in a way language choice (if not crafting a new architecture and language) is an important part of the design process. In my experience (though this has only been with business IT) it's rare if that gets consideration, though as we've seen with RoR and some with Python, people are gradually waking up to it.

I'm not sure your estimate of where C++ is used is very accurate. A lot of open source development actually shuns C++ in favor of C because where close-to-metal performance is needed people shy away from the language because of its (often dangerous) complexities relative to C, and where that kind of performance concern is not important C++ is too cumbersome and unwieldy and prone to certain types of errors. There are exceptions, of course, such as in the Qt/KDE development community, but the number of browsers written as very community driven projects in C instead of C++ is pretty surprising, considering how much the gigantic corporate projects (IE, Safari, Chrome, and arguably even Firefox) focus on C++. It seems that, regardless of what tools they're pushing on their developer "communities" and commercial "partners", the major software and platform vendors are themselves very prone to using C++, including Microsoft (IE, Office, various OSes), Apple (Safari, et cetera), Oracle (basically everything that wasn't acquired from Sun), and the descendants or spin-offs of Netscape, SGI, and AOL.

C++ mostly only gets used for systems development in those major vendors' core offerings, I think. For embedded development, C++ doesn't seem to have a whole lot of traction right now; everything's going to C, Java, and niche languages in that realm, I think. Instead, C++ seems to be big largely in development of really big user applications and certain academic ivory tower uses, plus occasional high performance "enterprise" stuff like industrial plant control systems. That, at least, is what I've seen. I suppose I could be mistaken, looking in from the outside. You're right about "IT/business/database operations" being mostly Java and C# (plus some VB.NET) with a crapton of XML, for bureaucratic organizations at least, but visible uses in those niches are actually a pretty small percentage of the whole (and the non-visible uses are anyone's guess, probably including a hodge-podge of fringe, creakingly old, and narrowly proprietary languages/environments, along with the standby Enterprisey languages like Java, C#, and C++).

Android, for the record, is a Java platform. A lot of people are starting to use frameworks that compile from other languages to Java, or to develop in JVM languages other than Java itself, though.

What you say about C++ vs. C in the OS community I think makes sense. I got a taste for how complex C++ can get with its use of objects over 10 years ago. While I could handle it for the most part, I said to myself, "This is insane," mostly because of templates. The only thing that made it somewhat reasonable was the use of design patterns, though quite a bit of the code I worked on was "C code using an object framework," since most of the programmers working with it only understood how to design in C, but we used commercial APIs, which had some minimal "object-ness" about them.

I remember what Alan Kay said about C++. He's softened his stance towards it. He used to say, "When I coined the phrase 'object-oriented' C++ isn't what I had in mind." More recently he said he realized that C++ was a macro language in the sense that you should define your own programming system out of it with macros, "or else it would kill you." He said the problem is most C++ programmers don't understand this.

C has a nicer language design than C++, once you realize what it's doing, and get a sense of what its intended purpose is (though perhaps C++ is the same way), though some C++ features are "nice to have" even in C code. Runtime type checking (though I don't remember if this extends to native types), references/aliases, and operator overloading are a few examples I can think of. Has anyone thought of using C++ without objects (ie. just staying "in the mode of C" and not interacting with objects)? It seems like that might be a nice experience.

re: design patterns

It has been said (insightfully, I believe) that design patterns are not so much development best practices as they are language design smells. That is, design patterns are necessary for languages whose design is deficient in the facilities it provides for the task you are attempting to accomplish.

re: Alan Kay

I had heard the "not what I had in mind" quote, but not the "it would kill you" quote. Both seem quite relevant, all things considered. I wonder, though, if his choice of how to reframe the C++ problem might be a political decision ("Let's try not offending people as much, and see if they'll listen to reason," I imagine him saying to himself), rather than a realization that C++ per se is valuable if people would simply use it properly. No situation comes to mind where using C++ as a macro language to satisfy the somewhat famous statement (to whose credit it belongs I simply don't remember) that the best way to solve a programming problem is to write the code in the best language for the task whether the language exists or not, then implement the language if necessary (and I'm sure I've hopelessly mangled the quote too), is a good choice when we have things like Smalltalk and Lisp (or even Ruby) available to us, and more to the point I have a very difficult time imagining Alan Kay of all people thinking there would be such a case given Smalltalk's far superior design for purposes of metaprogramming. In short, yes, perhaps C++ would be much more productively used if people focused on its metaprogramming/macro capabilities than on its bureaucratic OOP features and so on, but if the metaprogramming facilities made available in C++ fall orders of magnitude short of those provided by languages like Lisp and Smalltalk and even Ruby that still doesn't raise it to the level of Kay likely thinking it should actually be used in preference to its alternatives, I think.

re: C vs. C++

As I get more and more into C (again, after many years away) I am seeing the relative simplicity of its design and low-level fiddliness of its demands on the programmer conceal significant power that is not at first glance obvious. I increasingly see (in structs and unions, for instance) some potential for building a more elegant and flexible way to do OOP than the default object orientation paradigm of C++, just as I see in Perl (in lexical scope and first-class anonymous functions, the building blocks of closures) some potential for building a more elegant and flexible way to do OOP than the default, bless-based object orientation paradigm of Perl. C can really do a whole hell of a lot of stuff that at first glance it seems like it's singularly designed to prevent through sheer stubborn difficulty of wrangling the language. In general, while I see that there are things in C++ it would be nice to have in C, I think most of them are relatively superficial; the stuff most C++ programmers seem to value most about C++ over C look to me like more trouble than they're worth.

I'm not as familiar with C++ as I am with C, though, so I'm not sure I'm properly qualified to say how much of C++ one would need to ignore to get something like a "better C". It kinda seems, from where I'm sitting, like you'd have to throw out 98% of the language. I guess I could be wrong.

Go to blogstrapping dot com and read "C++ Skepticism, Not Hating" for some more of my thoughts on C++, including a link to a TR article of mine called "A Skeptic's History of C++". I recall you commented in the discussion following that article, actually.

re. design patterns

I realized that a few years ago, that if the GoF had worked on their concept some more, they might've been able to fashion a language out of their patterns, and then they wouldn't have to deal with constructing these patterns, but could just use the language to do what they wanted. As I recall, in the introduction of the book they said they were after a "pattern language," but maybe that was just a metaphor.

Re. Alan Kay and C++

Yeah, he was not expressing a preference for it. Here's the article and the actual quote. I tried summarizing it here, but when I found the original article again, I realized I was mischaracterizing what he said somewhat. He didn't express any realization, nor did he say "use macros." Rather he said the whole language is a macro processor, and that most C++ programmers miss this point.

This is an interview with Stuart Feldman from 2004:

http://queue.acm.org/detail.cfm?id=1039523

AK In the 1960s Ted Steele spent several years promoting an idea called UNCOL (universal computer-oriented language), and, to me, by a weird and interesting process mainly because its easy to implement, C turned out to be UNCOL. I dont think any human being should write in it, but its a great target for anybody who wants to do multiplatform things especially if you pick the right subset.

The problem with the Cs, as you probably know if youve fooled around in detail with them, is that they're not quite kosher as far as their arithmetic is concerned. They are supposed to be, but they're not quite up to the IEEE standards. You have to pick a subset of C and you have to have some side information to get to a mathematically perfect transform of your VM.

SF To what do you attribute the long-term love of Smalltalk? There is a certain set of languages that I would assert people seem to love, not just use. I know many people who love C. I know very few who love C++, even though they may make their living on it.

AK You have to be a different kind of person to love C++. It is a really interesting example of how a well-meant idea went wrong, because [C++ creator] Bjarne Stroustrup was not trying to do what he has been criticized for. His idea was that first, it might be useful if you did to C what Simula did to Algol, which is basically act as a preprocessor for a different kind of architectural template for programming. It was basically for super-good programmers who are supposed to subclass everything, including the storage allocator, before they did anything serious. The result, of course, was that most programmers did not subclass much. So the people I know who like C++ and have done good things in C++ have been serious iron-men who have basically taken it for what it is, which is a kind of macroprocessor. I grew up with macro systems in the early 60s, and you have to do a lot of work to make them work for you, otherwise, they kill you.

SF Well, C++, after all, was programmed as a macro processor, in essence.

AK Yes, exactly. But so was Simula.

In the work that he's done in the last 17 years, I haven't seen one instance of him, or the people he's worked with, doing anything in C++. They've used C some, but only as a high-level, portable assembly language, and even then, he's expressed a desire to get away from it, to create something better for low-level stuff.

Incidentally, in a 2010 interview, he had this to say:

http://www.computerworld.com.au/article/352182/z_programming_languages_smalltalk-80/

Q: What contribution do you feel you made to successive programming languages like Objective-C and C++?

The progression from the first Smalltalk to the later Smalltalks was towards both efficiency and improved programming tools, not better expression. And I would term both Objective-C and especially C++ as less object oriented than any of the Smalltalks, and considerably less expressive, less safe, and less amenable to making small compact systems.

C++ was explicitly not to be like Smalltalk, but to be like Simula. Objective C tried to be more like Smalltalk in several important ways.

However, I am no big fan of Smalltalk either, even though it compares very favourably with most programming systems today (I dont like any of them, and I dont think any of them are suitable for the real programming problems of today, whether for systems or for end-users).

Re. what you're finding in C

You might be interested in checking out Allen Holub's book, "C + C++: Programming with objects in C and C++." It's an old book, originally published in 1991, and was never updated. It looks like it's out of print, but you can still get it used. It's the book I used to learn C++. As I recall, he wrote it for people who were C newbies. So he goes from teaching C all the way through to teaching C++. I skipped the early part of it. The part that was really interesting to me was he goes into a "transitional phase", explaining how you could implement something object-like in C, using structs. He explained for example how you could implement inheritance by defining one struct, and then including that struct as the first instance inside a second one. This way you can hold onto a "derived" struct, recast it as the "base" struct, and it'll work. I haven't looked at the book in years. It was extremely helpful to me in learning how C++ works, which was necessary for me to get the language. There comes a point where he says, "You could do this in C to kinda get this feature in C++," and he demonstrates the principle, but then says, "This is a lot of work. Here's how C++ does this for you." So he explains the rationale for C++. At the time he wrote it, I think templates might've just been introduced into the language. He didn't cover templates at all, IIRC.

In the last part of the book he explains how you can use C++'s features to do some system-level abstraction. I remember one example he gave was explaining how you could create a "paging array". You created a container that looked for all appearances like an array (using operator overloading), but you had no limit on what you could index (well, up to MAXINT), because under the covers the array was a buffer which paged its contents to disk. It could save the portion of what you had put into it, that you weren't using at some point in time, and load some other portion you were trying to access. I thought it was a good book for what it was trying to teach.

To just explain your point for others why meta capabilities are important, an idea Kay gave me several years ago, which I'm still exploring, is that "most programming is architectural design." He didn't mean this to say that "most programming projects you encounter are architectural design," but rather, that's what it should be, and he didn't mean it in the sense that most programming effort is carried out on the "drawing board" with design schemas. The idea is, as Turing said, "If you're not satisfied with the computer you have, you can build a better one," out of the one you have, and that once you've built your architecture, you're 98-99% done with what you were going to build as your end goal. So what a language's meta capabilities give you is at least some ability (depending on what meta capabilities you have in the language) to create a new runtime and language whose goal is to support the operations needed to accomplish the end goal. The value of this way of doing it is when you're done, you have not only created the end goal, but you have an expandable system that not only makes the maintenance of the existing software easier, but enables you to solve a whole class of problems with less effort than if you had stuck with the old language/system.

With meta capabilities, you can change the fundamental assumptions of what you're using.

The challenge I've found with trying to realize what this concept is about is understanding, "What is architecture," as Kay expressed it. As best I can surmise at this point, it's (roughly) "a way of operating." It's not just a way of applying functors. It's a way of storing, recalling, constructing, and processing information. As was discovered 40 years ago, it's also a method of interaction, not only with people, but other computers. These principles (storing, recalling, constructing, processing, interacting) need not be tightly bound to each other. In fact they can even be distributed on different systems. The rub is the field ought to strive for the operation and expression of the integration of these principles to be seamless. Above all, we shouldn't have to take down an entire system just to maintain it. Thank goodness the internet doesn't operate that way!

If you don't deal well with change, software development might not be the best career choice. But I hear you on the explosion of UI markup options; that's why I leave design to designers and focus my career on the backend. You have to exercise some judgment in selecting which technologies to use and the depth of knowledge necessary to be productive and competent. 90% of what I've learned in a decade of using .NET are things I still use constantly. I learn new libraries and paradigms as needed, when there's an obvious ROI, and I don't dilute my skillset by trying to be a jack of all trades, master of none.