|
Anders Hejlsberg on C#
Note sure if this has been posted befure - I saw it on Slashdot today:
http://msdn.microsoft.com/vcsharp/homepageheadlines/hejlsberg/default.aspx
I'm not familiar with Borland or Delphi so this was my first introduction to Anders... Wow, this guy is very, very smart. He's a real hacker, not a substance-smoking academic. The kind of person you rarely see designing a major programming language... I wish there were more people like this in the Free Software world.
Dan Maas
Saturday, February 7, 2004
Larry Wall is the one guy I'd say is as smart and insightful when it comes to language design. Are there any others? (Not just smart but brilliant.)
Tony Chang
Saturday, February 7, 2004
"I wish there were more people like this in the Free Software world."
Yeah, but most people as talented and smart as Anders want to *gasp* get paid for their time and efforts and not rely on the charity of others. So they stick with more profitable ventures, such as working for for-profit companies. Oh the horrors.
Your Uncle Bill
Saturday, February 7, 2004
Dan, do you even use open source software?
Li-fan Chen
Saturday, February 7, 2004
Uncle Bill, it's no more common for a Free Software developer to be unemployed and rely on someone's charity, than for an "ordinary" developer. In fact, it even less common, as OSS is typically written by those who earn enough to afford it.
Egor Shipovalov
Saturday, February 7, 2004
Egor,
My point wasn't aimed at the average Open Source developer, but rather that most people of the caliber of Anders who tend to become leaders will prefer to work for a for-profit company because they recognize the instrinsic worth they bring and want to get paid for it.
Even Torvalds himself wrang his hands on several occassions wondering how in the world he was going to make a living. All I'm saying is that it's fairly rare to find leaders with the brains of Torvalds who want to dedicate themselves to Open Source.
Your Uncle Bill
Saturday, February 7, 2004
By the way, the guy doesn't seem to know the difference between a function reference, and a closure:
"Anders Hejlsberg: Delegates add a kind of expressiveness that you don't get with classes or interfaces, which is why I think they are important. Programming languages that have gone before us have recognized that they are important. They have many names: function pointers, member function pointers. In LISP they are closures. "
You need variable(s) in higher lexical scope referred in the function to make a closure. Otherwise you just have a function reference, not a closure, right?
Egor Shipovalov
Saturday, February 7, 2004
"By the way, the guy doesn't seem to know the difference between a function reference, and a closure:"
Here comes the ego-driven, technical nit-picking that techies are so famous for, and makes the universally unloved (and annoying) by non-techies.
I'm guessing that the creator of both C# and Delphi probably knows the difference, and if he doesn't, he probably doesn't give a shit either because it doesn't look like it has held him back much.
I Hate Whiners
Saturday, February 7, 2004
Anders did make some pretty good points (nothing new if you program in java) against java and the various mantrras you've heard java's marketers insist as The Word(TM)... althought not all of us would be around to enjoy it... the next ".Net-killer"'s architect would no doubt have a lot of monkey doo doo to sling at .Net.
Li-fan Chen
Saturday, February 7, 2004
In the end we have:
JAVA
- owned by SUN
- run by SUN
- evolved by the masses
- avaliable on multiple OS
C#
- owned by MS
- run by MS (please don't make me laugh about "standards bodies")
- evolved by MS
- available on Windows
The last item is what sold JAVA to the masses. Being "better" was merely a perk.
AnonAnonAnon
Saturday, February 7, 2004
I believe Chuck Jazdzewski of Borland (co-designer of Delphi with Anders) has also joined the ranks of Microsoft. Should be interesting to see this dynamic duo back together again.
Could only be good for C#/VS.NET.
Smitty
Saturday, February 7, 2004
"The last item is what sold JAVA to the masses. Being "better" was merely a perk. "
Yawn...Let's not ignite another pointless religious war over Java vs C#. That's been done to death a zillion times here.
Mark Hoffman
Saturday, February 7, 2004
Egor, I believe that you're missing his point. You're bringing up the issue of dynamic vs. lexical scoping, but he's talking about the importance of functions as first-class data types.
K
Saturday, February 7, 2004
Re: closures. I'll agree with Egor that the sentence parses somewhat oddly. He does seem to have jumbled simple references to functions together with references to functions + lexical scope. C# will do this sometime in 2004 with the release "Whidbey". Search this chat, posted this weekend, for the word closure. http://msdn.microsoft.com/chats/vstudio/vstudio_011603.asp Fair enough Hejlsberg doesn't know exactly what's released yet. More than likely he's already using some alpha-alpha-alpha longhorn release...
Then you will be able to do the classic return counters example something like this:
delegate int ACounter ();
ACounter getCounter()
{
int total = 0;
return new delegate {
return total++;
}
}
The whole series has been an interesting read. Hejlsberg is obviously a very bright guy.
Synder
Sunday, February 8, 2004
K, I understand what he's talking about, he just used a wrong (and misleading) term for some reason. I program in LISP and Perl most of the time, which use closures extensively, and believe me, when you use this term, you NEVER refer to just "function the data type".
Synder, thanks a lot for your point. Very interesting, and probably just explains it.
Sorry if it sounded like I'm really knocking Hejlsberg. I'm not. I find both Delphi and C# beatiful, innovative languages. He's clearly head and shoulders above Gosling when it comes to vision and creativity.
Egor Shipovalov
Sunday, February 8, 2004
To be fair to Gosling, Hejlsberg has had nearly a decade of watching Java in the real-world to learn from. Maybe Delphi would be a better comparision? That said, many people consider Delphi a great langauge/environment. As Hejlsberg mentions in the interview, some of the things in Java are relics of its particular past. The type speciifc instructions lend themselves to a simpler interpreter - consistent with a language designed for consumer apilicances (see http://java.sun.com/features/1998/05/birthday.html ). I certainly thank Gosling for the simple miracle of mainstreaming a garbage-collected language. Massive Libraries, bundled GUI toolkit, cross-platform, secure runtime. Despite its rough edges, Gosling did set a high bar for Hejlsberg and Microsoft.
Synder
Sunday, February 8, 2004
> To be fair to Gosling, Hejlsberg has had nearly a decade of watching Java in the real-world to learn from.
To be really fair, both have had four decades of LISP, about three decades of Smalltalk, two of decades of Squeak and O'Caml and a decade of Haskell to learn from.
LISP and Smalltalk for example had GC, massive libraries, GUI toolkits, cross-platform secure runtimes in the 70s!!! What they didn't have was Sun and MS marketing.
Dan Shappir
Sunday, February 8, 2004
"To be fair to Gosling, Hejlsberg has had nearly a decade of watching Java in the real-world to learn from."
To be fair-er, it was more like 5 years. We were already hearing about what was coming with .NET in 1999.
Oh, and what the guy above me said, too. :) Smalltalk was a language that was a few decades ahead of its time.
Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, February 8, 2004
"LISP and Smalltalk for example had GC, massive libraries, GUI toolkits, cross-platform secure runtimes in the 70s!!! What they didn't have was Sun and MS marketing."
Eh, I'd rather say what they didn't have were cheap personal computers on which these languages would perform reasonably well... if nobody had bothered inventing Java and C# we might just as well see a Smalltalk renaissance right now.
Chris Nahr
Monday, February 9, 2004
if nobody had bothered inventing Java and C# we might just as well see a Smalltalk renaissance right now.
There are much more pages on Smalltalk, LISP and other dynamic languages than two years ago. May it be the light at the end of the tunnel?
Giovanni Corriga
Monday, February 9, 2004
(warning: young Smalltalker talking)
By the way, I don't agree with the praises to Hejlsberg I read here. Almost all of his design choices scream 'premature optimization' to me. I could rant for half a day on what's wrong with C# and .Net...
Giovanni Corriga
Monday, February 9, 2004
"Almost all of his design choices scream 'premature optimization' to me. I could rant for half a day on what's wrong with C# and .Net..."
with a few exceptions pretty much everyone on this forum would be very interested in hearing you do so...care to make a few points now?
FullNameRequired
Monday, February 9, 2004
WE are seeing a lots of new little languages & dynamic langauges and NEW interest in old langauges..
Rant on young smalltalker! That's what we are here for.
george plenn
Monday, February 9, 2004
The tone is somewhat over the top, but this poster
http://www.cincomsmalltalk.com/blog blogView?showComments=true&entry=3253682598
argues that value types make the language "immensely complex." Allocate and forget. Let my runtime can take care of the optimizations. The JVM is doing its generational garbage collection and building thread local heaps behind the scenes & outside the language. With value types, suddenly the bad old world of caring where something lives rears its ugly head. Is it a sharp tool we need or a relic of slower days that 64bits and 6Ghz will make us forget?
Synder
Monday, February 9, 2004
"Almost all of his design choices scream 'premature optimization' to me. I could rant for half a day on what's wrong with C# and .Net... "
We'll settle for just five literate, intelligent points.
..or did you have no intention of backing up your claims and just prefer to whine that C# and Java are more popular and widely used than SmallTalk?
I Hate Whiners
Monday, February 9, 2004
Egor/Synder, it's my understanding that "closure" (ie: "lexical closure") refers to the combination of a function and a set of environment symbol/value bindings. In Lisp, this is the function-value type ... you can't make any other kind (although there are dynamically-scoped Lisps where this isn't an issue of course). So I can see why he'd refer to closures in particular w.r.t. Lisp's version of function references. In the Lisp interpreter I wrote, my internal documentation is consistent with this interpretation.
I think that language designers have understood that they're adding layers of syntactic sugar to Lisp for several years now. I'm sure that Hejlsberg knew what he was talking about.
K
Monday, February 9, 2004
I've seen only one *real* difference between C# and Java, and that is that Java attaches political ideals to their language design. Java is designed not only to do the job, but to encourage developers toward the "right" way to do that job.
I like the idea, but every couple of years the "right" way to do things changes. When you build what's "right" into your language, five years later you find that you've built "backwards" concepts into it. They weren't backwards when you built them, but things changed.
I think the biggest problem in the technology field today is the number of people who consider every new technology an avenue for them to make people do things THEIR way. If you look at the various communities that grow up around technologies, there's an awful lot of "everything else is crap" being thrown about.
Someone once told me "nothing is all-purpose, and nothing's squirrel-proof". Over the years, I've found this to be a pretty good perspective.
Caliban Tiresias Darklock
Monday, February 9, 2004
"We'll settle for just five literate, intelligent points. "
I would like to respond to this, not because I agree with the poster, but because I'm interested in hearing the responses.
a) Value types -- already mentioned in the referenced article. Makes the language more complex because value types are "different" than objects only for the reason of performance.
My (admittedly uninformed) response to this would be that simple math does get used in almost all applications. Everyone has to loop right? Would i++ get unboxed/reboxed on every iteration in a language that didn't have value types? you'd think there'd be some low-level optimization built-in for this type of thing. Atleast C# has gone a step further than java with autoboxing.
b) Delegates. Hejlsberg mentions that delegates are actually more performant than virtual method calls because they are resolved only once, on instanciation.
My repsonse: I don't think that was the main reason for incorporating them, just a side benefit. I liked his point that callbacks and function references are a natural part of programming that should be a first-class citizen. I would like it even better if we could just get a f**king function reference instead of all this wonking around with delegates.
c) "Inappropriate Abstractions". This isn't really part of C#, but in one of the articles, Hejlsberg talks about why there's no real ORM infrastructure in .Net, and it basically comes down to performance.
You can maybe call this a kind of premature optimization, but he makes a good point about ORM system having been proven to be difficult to make performant. There are places where the abstraction just doesn't work. Maybe the value types are a case of that as well.
... that's about all that I can come up with. Any responses?
Aaron Boodman
Monday, February 9, 2004
Found another one --
d) virtual methods. Hejlsberg says that one of the reasons for them being non-virtual by default is performance.
But again, I don't read it as that being the main reason, only a benefit. The main reason, as i read it, was for versioning.
Aaron Boodman
Monday, February 9, 2004
Sorry for being late, but I was away from my net connection.
Since someone brought up the value type issue, I'll start from that.
I'm not arguing that having stack allocated types in the VM is useful. In a Smalltalk VM in fact, Integers in the 31-bits range are allocated on the stack (one of the bits of a 32-bits word is reserved for tagging and discriminate between integers and pointers to object). Having a more complex value type system may even be useful in some limited circumstances. But that's not a reason for exposing value types at the language level.
I see no reason for not abstracting away the fact that a type is stack- or heap-allocated. The compiler and the VM have enough information to decide that by themselves, and not to burden the programmers with those decision. If these details were hidden from the programmer, the language would be easier to grasp and to use, making you more productive.
Giovanni Corriga
Tuesday, February 10, 2004
Sealed classes are a bad idea. Mine may be a Smalltalk bias, but I see a class hierarchy as something that you work with, not against. It often happen that the simplest way to implement something is by subclassing from the framework. But it may happen that the class you'd like to extend is sealed, so you can't create a new subclass. So you have to lose two days to create a workaround which will do what you want, but will have duplicated half of the framework's functionalitis with twice the bugs. And that because someone tried to do the thinking for the programmer, and believed he has thought of all the possible uses for that class.
Giovanni Corriga
Tuesday, February 10, 2004
Giovanni,
>I see no reason for not abstracting away the fact that a type is stack- or heap-allocated.
Including value types in the language has consequences other than performance improvements. Say we have code like this:
point p = someGuiWidget.position;
p.x = p.x + 5;
then it matters whether or not "point" is a value type. If it is, then p is simply a copy of the position of the widget, so the assignment to p.x has no effect on the widget. In C#, is p is an object (not a value type) then the assignment to p.x will actually cause the GUI widget to move - since for objects assigment just copies the "pointer", not the value.
Does this issue have any counterpart in Smalltalk?
John
John Rusk
Tuesday, February 10, 2004
John, I'm not sure I'm following you here. If I'm not getting you right, please reformulate your question.
What I think you're sayinf is that if p is an object, then by changing p.x you have the side effect that you also change the position of someGuiWidget, since p is also referenced by it. This would be a bad practice, and having p be a value type would prevent this.
But what if position (assuming position is a property) returned a copy of p? Then you would have the same protection, without the need of a value type.
Another solution would be to have point objects be immutable, like Squeak Smalltalk does.
Giovanni Corriga
Wednesday, February 11, 2004
Another thing I don't like is properties and how they where implemented in C#. They're just syntactic sugar, but they make the language much more complex.
In C#, you have methods, public members and properties. In Smalltalk you have only methods. Among these methods, there are _accessors_, which are always required since an instance variable can't be accessed from outside tha class. Thus in Smalltalk by leveraging an already existing feature (message sending) you obtain the same results that you obtain in C# by adding a new feature (accessor modifiers to fields).
Properties are ambiguous too. When I read the snippet of code John has posted, I couldn't decide at first if position was a property or a public member. And that's not just a detail, since if it something is just a public member, you may assign a value to it or read it without any side effects implied. But if it is a property, when assigning a value to it you may trigger unwanted side effect without even knowing it. That's more complexity you have to take care of.
Giovanni Corriga
Wednesday, February 11, 2004
Giovanni,
Yes, you did understand me correctly. Thanks for explaining how it would be handled in the Smalltalk world. Personally, I like the C# approach - I guess it partly depends of what one is used to. (I've done a lot of work in Delphi, Anders Hejlsberg's "other" language, so many of the C# concepts that you've highlighted seem quite natural to me.)
John Rusk
Wednesday, February 11, 2004
I find it really annoying that methods are not virtual by default. Whenever I have to override something I have to:
1. either hope the class' designer made what I need virtual,
2. or make my changes in two places (specifying override AND virtual)
Performance, as mentioned, should not be the concern. .Net is JIT compiled, right?
Can someone explain to me how it helps on versioning?
Thomas Eyde
Friday, February 13, 2004
 Recent Topics
Fog Creek Home
| 
