Home

Life and Times of Anders Hejlsberg

This episode of “Behind the Code” features industry luminary, Anders Hejlsberg. Before coming to Microsoft in 1996 he was well noted for his work as the principal engineer of Turbo Pascal and the chief architect of the Delphi product line. At Microsoft he was architect for the Visual J++ development system and the Windows Foundation Classes (WFC). Promoted to Distinguished Engineer in 2000, Anders is the chief designer of the C# programming language and a key participant in the development of Microsoft’s .NET framework.

This isn't a technical interview but it is fun none the less. Anders describes, for example, how his team works and how their meetings are organized.

When asked about the future of C#, Andres mentions better data integration (e.g., LINQ etc.), and the mismatch between programming languages and database programming. These are issues we discussed here many times, of course. As regards the future of programming languages in general, we are told that more declarative languages (or language features, I suppose) are going to appear. I quite suspect that different programmers have different ideas of what declarative programming really means, and I think question is worth exploring.

It's nice to hear Andres say that OOP is a tool, and not a religion, and mention that there are useful ideas in language such as Haskell, ML, Lisp and Scheme. I guess we weren't wasting our time after all...

By Ehud Lamm at 2006-03-02 13:13 | General | other blogs | 11607 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

It's nice to hear Anders say

~37min always one right way to do something
Pascal vs Perl :-)

54min object oriented programming is just becoming a tool... in many ways... if you go back 10 years ago it was a religion, now it's a tool.

Ehud: "mention that there are useful ideas in language such as..."
More than that, he clearly said that a lot of the inspiration with C# 3.0 came from functional languages.

By Isaac Gouy at Thu, 2006-03-02 19:02 | login or register to post comments

I was being facetious...

I was being facetious...

By Ehud Lamm at Thu, 2006-03-02 19:27 | login or register to post comments

a sense of wonder

I haven't given up double-meanings for Lent, but recently I understood how difficult it is to successfully convey a single meaning in a blog comment or email - so now I take the plain text at face value.

And I still have a sense of wonder that this is happening in a mainstream language :-)

By Isaac Gouy at Fri, 2006-03-03 19:49 | login or register to post comments

Chui Tey

LINQ is a right step. However, I'd really like to see someone address the mismatch between spreadsheet programming and database programming and general programming.

Of all the paradigms, I find spreadsheet programming both wonderful and nauseaously difficult. On one hand, one can come up with results quickly, but on the other hand it can be extremely error prone, since it is modelled on copy-paste style of programming.

SubText had a unique approach to it, but it's far too radical.

I'd like to see database programming ie SQL evolving some characteristics which deal with

1) ordered lists instead of sets
2) formulae which can reference values on previous rows
3) ability to deal with start conditions... e.g. B2=B1+C2, but B1=0

Alternately, some kind of functional programming that more resembles spreadsheets.

By Chui Tey at Fri, 2006-03-03 00:27 | login or register to post comments

spreadsheet programming

spreadsheet programming paradigm in lisp:
http://www.cliki.net/Cells

By VagifVerdi at Fri, 2006-03-03 02:03 | login or register to post comments

Sounds Like...

...constraint programming in Oz to me.

By Paul Snively at Fri, 2006-03-03 14:51 | login or register to post comments

I'd do away with spreadsheets

I'd do away with spreadsheet programming entirely. Anytime someone creates a spreadsheet they should have created a database. So write your spreadsheet programs in SQL, and get the advantages of a real database (multiple users, real time updates, select only the data you want to display...)

Now a spreadsheet is a great DISPLAY tool for your database. If you have a lot of numbers, a spreadsheet is a great way to put them on paper, and drag-and-drop cells to a table is going to be easier for managers than learning SQL, particularly when they are not doing the same query.

By Henry Miller at Fri, 2006-03-03 18:25 | login or register to post comments

Horses for courses

There are many applications where a full-blown database is simply far too heavyweight. Not all spreadsheet users create large or complex tables. Spreadsheets provide a mix of easy programming, dynamic calculations, simple definition of GUI-like features, and easy data visualization that makes them the right solution for many applications (particularly those involving users who are not programmers). They're not going away anytime soon...

By Allan McInnes at Fri, 2006-03-03 19:27 | login or register to post comments

We need to simplify the database then

You are partially correct. Spreadsheets are more lightweight, and many tasks are light enough that you don't need a full database. However even for simple tasks, the ability to re-arrange the data based on a different query would be highly useful if only the user knew how to do this.

Many companies have processes built around various spreadsheets, that make the entire process more cumbersome. However they do not realize that there even is a problem - it works, and is more like the paper they used to shuffle that they don't think that the computer provides a better way.

Part of the solution is to intigrate the spreadsheet with the database so that when users create a spreadsheet the system does the grunt work. However a large part is to get people to recognize that they should call in an expert (assuming they do not want to become an expert - a good idea for many people who have skills that I as a programmer lack - let experts do what they are experts in)

Web pages are taking over many of the things that I used to see people do with a spreadsheet. (expense reports and time cards used to be done on a spreadsheet in many companies - both are cases where the data had to be copied to some other format[s] so that it could intigrate with the rest of the processes)

I agree that a spreadsheet is a great data visualization tool. The solution is teach users to populate the cells from the database.

I'm not arguing that spreadsheets are bad. Only that they are abused - often there is a better tool.

By Henry Miller at Mon, 2006-03-06 17:42 | login or register to post comments

I've been fan of Anders'

I've been fan of Anders' work since Turbo Pascal, and I really enjoy writing client apps with the VS.NET environment. It's got the snappy-response quality that made BP and Delphi so much fun to use.

Spreadsheets I think also satisfy that want for instant gratification. Whereas an environment like VS is a great way to do GUI-centric programming, spreadsheets are great for data-centric programming. You're also always working with live data, which is more natural for some tasks.

Think about all the different perspectives you take when working on a programming project. There's the code view, GUI view, database view, filesystem view, revision control view, module-dependency view, debugging view, visualization view, documentation view ... it seems like to be successful you have to somehow integrate all those views.

I don't know how I got talking about IDEs... I guess the point is that I sometimes wish I had a (live?) spreadsheet view of my running program, and vice-versa.

By Steven Hugg at Sun, 2006-03-05 04:44 | login or register to post comments

AQuery

As far as I know, sql doesn't operate on sets. That is one of the complaints from C. J. Date.

You may want to look at AQuery: Query Language for Ordered Data. This is an extension to SQL which deals with times series. Since data is ordered, functions can access values from other 'rows' (moving averages, etc.).

By shahbaz at Mon, 2006-03-06 18:58 | login or register to post comments