Slashdot Mirror
Anders Hejlsberg Interviewed On C#
ghost. writes: "I'm sure it's been submitted already, but here's an O'Reilly interview with Anders Hejlsberg, Chief C# language architect for Microsoft (as well as the force behind Turbo Pascal and Delphi, in the past). While my interest in C# specifically is mild at best, I always seem to learn a lot when /. gets into a good discussion about programming and language design, and I'd enjoy reading everyone's insight based on what Hejlsberg had to say." It's a good read, too -- this interview brings to the fore some of the questions about openness that people raise about C#, and Hejlsberg has strong words about his new baby.
Chief Architect of Delphi and His Team Designed WFC
Good details on C# as described in The Register
M$: "We're #2!"
This guy definitely knows his stuff, and he had some very interesting things to say about his baby. I would almost get the impression that this guy is one of the lucky ones who doesn't represent the image of his company.
Of course, I could just be easily fooled. Did anyone else count how many times he mentioned "innovation"? :P
I think C# contains some pretty interesting innovations that make component development easier
It's not as though this hasn't happened before, but the way we've applied it to the language is pretty innovative.
We're not saying, "Now that there's only one language, there shall be no further innovations in this race."
We want to create a platform where there can be innovation.
Microsoft's favorite word?
wish
---
Rumor has it that M$ snarfed this guy from Borland for a measely $2,000,000/year. Wonder if they're over the league's salary cap?
RM
Actually, Microsoft wrote PC-DOS too (well, sort of; they licensed QDOS [Quick and Dirty Operating System] from Seattle Computer but surely must have made a few changes before releasing it). PC-DOS 1.0 shipped with the original IBM PC, and MS-DOS 1.0 was identical except for the name (AFAIK) and shipped at the same time.
Bill conned IBM into this arrangement wherein IBM paid MS for R&D, MS gave IBM PC-DOS, but MS got to keep it for themselves too and release MS-DOS in competition with IBM.
Somebody more familiar with this stuff please correct my details.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
My favorite part:
Osborn:
So you can't write unsafe code in VB?
Hejlsberg:
No, you cannot.
:)
-Waldo
-------------------
Here is a link to minutes from a recent ECMA T39 meeting where they discuss the submission of C# and CLI.
with humpy love,
with humpy love,
humpmonkey
Speaking as a big fat idiot :) I would ask the same question. Aside from tieing us into the whole .NET nonsense, why IS Microsoft trying to reinvent both C++ and Java? And the first response to use the word "innovation" loses...
Well it's really just a matter of perspective. Microsoft also doesn't find a BSOD to be "unsafe". Why else would the feature be so prominent in every one of their OSes?
But Java ain't the end-all, be-all. There's nothing wrong with trying to develop a language that takes what they like, and discards whatever features/misfeatures irritate them.
Even Sun does this, deprecating / adding / altering... Java is an imperfect language in flux, and even Sun knows this as demonstrated by the rate of change. I have no problem with MS also recognizing this and deciding that they'd make slightly different design decisions, which apparently they do.
Only the dead have seen the end of war.
... and I quote:
.NET base-class library."
"In C#, enums are not just integers. They're actually strongly typed value types that derive from System.Enum in the
Wow! Now, next time I accidentally set the colour of my car to "Tuesday", the compiler will throw a hissy-fit at me! Hooray for C-#!
Donny
...I think we've done a great job supporting COM on the .NET platform. But people in the industry have been reading too much into our use of the words COM and DLL. They conclude that the .NET platform is for Windows platforms only, and that's absolutely incorrect.
People have read too much into the comments because of Microsoft's past actions. It would be really nice to think that they are fully supporting open standards for SOAP and C#. SOAP has tremendous potential. Reading this gives me some hope... Until I think about every Microsoft product's perverted implementation of standard.
I feel like a guy who just met a pretty girl at the bar. I *know* I'm not going to get to take her home, but the **slightest chance** that it might happen has me buying drinks and listening to her every word all night.
Might actually improve my programming. There has been many a moment I stuck a printf in a Java program, tried to use system.out in a C++ program, or found myself wondering why bash didn't like the cout I fed it..
You should see my Perl. [shudder]
.sig: Now legally binding!
Do y'all think this is for real? Hejlsberg says:
The language design team consisted of four people. The compiler team had another five developers.
Working with such a small team seems just too cool for Microsoft. To be fair, he says that the "the whole company" was involved with the framework. I think it's actually a good sign for C# that it was made with such a small team.
-Waldo
-------------------
I'd like to clear up a common misconception. People will tell me I'm wrong, I just know it, but still... For most Win32 programs Delphi and C++ code will run at pretty much the same speed. There is no noticable difference for non-number crunching tasks, and Delphi makes development much faster.
C++ is more flexible, granted, and some things in Delphi (pointer offsets, for example) are a nightmare in Pascal, but the development time is often far faster. There is no trying to remember whether you want a pointer to a pointer to an array of chars or just a pointer to an array of chars, or whatever...
Please don't start a huge debate about Delphi v C++, it's not worth it. And let's not mention the VB 'compiler' in the same sentence as fast (oops, just did it...).
Which company will inherit .NET?
.NET with it to its grave -- unless the software division is granted control of it.
.NET goes to the software division, they will have no incentive not to make implementations for every platform that it's economical to do so for. C# will then become a true international language, combining the speed of Java with the things that Python, C++, and Modula-2 got right.
.NET platform goes to the OS division, it remains tied in to windows, and nobody outside of windows will use C#. As windows loses mindshare, so will C#, ruining what might eventually be a great language.
.NET platform goes with the software division. C# and .NET are ported to various platforms as it becomes economical to do so. Lots of developers use C# and it becomes the language Java only dreams to be.
While this might sound like it only has a tenuous relationship to the topic on hand, it is extremely important to the survival of C#. Why? Platform Independence. As much as they would like to claim so, C# is far from platform-independent. Microsoft likes it that way. So what will happen if it goes to the Windows division? Lock-in. While Java was destroyed by inconsistencies (one might say purposeful inconsistencies) in different implementations *cough*Microsoft's*cough*, C# will be destroyed by only being available for one platform. As Windoze slowly dies a painful death, it will take
If Microsoft is split up and
When I was reading this article, I actually was quite impressed with the language. But as far as I'm concerned, there are two options:
1: The
2: The
--
Friends don't let friends misuse the subjunctive.
"We will be presenting the judge and jury with a simple question," said attorney Rick Oxford. "Is it possible to write unsafe code in Visual Basic? Microsoft has already provided us with the answer: No."
Oxford was referring to a recent interview with Hejlsberg published on www.oreilly.com. In it, the interviewer asked whether it was possible to write unsafe code in Visual Basic; Hejlsberg replied, "No, you cannot."
US Attorney-General Janet Reno was flummoxed. "I'm flummoxed," she admitted. "That pretty much sinks our whole case right there. But you can be we'll make Gates pay for this." This comment sent Microsoft (NASDAQ: MSFT) share prices plummeting to 0-7/8 per share.
Free Software Founation founder Richard M. Stallman was unavailable for comment. A spokeswoman said he was "busy buying Visual Basic For Dummies(tm)".
Carousel is a lie!
That's great, but his examples are stupid. Cases in point:
"one of our key design goals was to make the C# language component-oriented, to add to the language itself all of the concepts that you need when you write components. Concepts such as properties, methods, events, attributes, and documentation are all first-class language constructs."
Sure. That's new.
"And C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code."
So what? Ever heard of JavaDoc? POD? Having to code your comments in XML isn't a revolutionary leap (forward, anyhow).
"One of the key differences between C# and these other languages, particularly Java, is that we tried to stay much closer to C++ in our design."
-snip-
"Another important concept is what I call "one-stop-shopping software." When you write code in C#, you write everything in one place. There is no need for header files, IDL files (Interface Definition Language), GUIDs and complicated interfaces."
What?? First, C++ is the master of header files and interfaces. To write a language eliminating these is a good thing, but it's moving away from C++ and towards more modern languages like Java, not vice-versa. And even so, how can you say you're creating a highly component-ized language and then write everything in one place? OO-Pascal?
The most annoying thing about this interview is Hejlsberg's stance that people should choose C# because "We're starting with a clean sheet of paper" building a language from scratch. This has been done several times, but too often the first thing that happens to that clean sheet of paper is that it gets marked up with the motives of the creating body, in this case, anti-Java, anti-interoperability Microsoft.
Don't forget this is the same company that spearheaded the standardization of CSS, yet still fails to support the standard correctly in their browsers.
I'd just as soon start using Dylan exclusively.
Kevin Fox
Kevin Fox
from the interview:
s /gosling/index.html
'This notion that Java is 100% pure and gives you 100% portability just isn't true. There's a great interview with James Gosling on IBM's developer works site in which he directly addresses this issue. He said, yeah, the whole right-once-run-anywhere, 100%-pure-thing was a really goofy idea, and was more of a marketing thing. He says, in effect, "We didn't think we'd ever be able to deliver all that, and basically we haven't." Here's the inventor of the language saying that neither purity nor portability exists.'
The Gosling interview he refers to is here:
http://www-4.ibm.com/software/developer/feature
Check out the part he's referring to. The Microsoft guy is totally misrepresenting what Gosling says.
I disagree. that's like saying the world has enough operating systems, who needs another? We have windows and linux, that's all the world needs. Who needs BeOS? who needs MacOS? Each highlevel language is good for certain things, they each have their own niche. -V
And C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.
.NET base-class library. An enum of type "foo" is not interchangeable with an enum of type "bar" without a cast. I think that's an important difference.
.net base class in-fucking-deed. warning bell: anyone who talks this much about enums (which ARE cool, but not all that friggin' cool) is talking out his butt. how many times have you been writing a C program and thought, well, shit, if only i needed to typecast this enum before i could interchange it, this language would really be much nicer..
buuuuuullshit. (except for the XML qualifier) this is exactly what perldoc does.
Enum is in the
he managed to fit some nice hype in there, aye? the
When you write code in C#, you write everything in one place. There is no need for header files, IDL files (Interface Definition Language), GUIDs and complicated interfaces.
so? aren't all of those things methods used to make code portable? if you're interpreting it all anyways, of course you don't need headers.
Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.
what fucking planet is this guy from?
ok, so maybe it won't be a shitty language, but this interview is 100% market-driven spin-filled drivel. M$ is trying to replace 'object-oriented' with 'component-oriented' as the next language buzzword, and then be the only kid on the block with a buzzword compliant language.
blah! shut up and use perl.
--
blue
i browse at -1 because they're funnier than you are.
Of course, for a more radically "innovative" approach, Microsoft already hired Simon Peyton-Jones, of some "fame" in the world of Functional Programming, and furthermore, he already had C--, Still Another "BCPL stepchild."
There are probably a whole pile of "cool things" that have been deployed internally that might actually be good things that will never see the light of day because, as Matt Welsh observes,
That can apply as well to languages as to OSes...
If you're not part of the solution, you're part of the precipitate.
Unusual little point in the interview I couldn't help but notice: Until now, MS has tried to milk the cash cow by locking the industry into proprietary standards that weren't usable without MS tools, MS platforms, etc. Examples would be COM+, OLE, ActiveX, VB, MFC, J++ extensions, etc.
Oddly, they seem to have taken a slightly different route this time: Yeah, they still want you to run Win2000, upgrade to Windows
I might point out that we're taking a true open standards approach with ECMA. When and if ECMA actually arrives at a standard for C# and a common language infrastructure, the result will be available under ECMA's copyright and licensing policies, which are truly open. Any customer, and any person, will be able to license the ECMA C# standard, subset it, superset it, and they won't have to pay royalties. They'll be able take it and go implement it on any platform or any device. We fully expect people to do that. That is something fundamentally different from our competitors who wandered around the standards bodies, looking for someone to rubber-stamp their proprietary languages.
The ECMA, if it ratifies the C# standard, will be in charge of at least trying to assure that MS can't mess with the specifications too much, such as to break platform/language interoperability. I'm as astonished as everybody else about Microsoft's sudden commitment to open and certified standards. Maybe they're aiming to have everybody use their language and platform - thereby creating a viable long-term solution that'd keep MS in business even if they were split up or if computing moved in a different direction, rather than attempting to make as much money as possible in the short term.
Makes you wonder, doesn't it?
Alex T-B
St Andrews
Another important concept is what I call "one-stop-shopping software." When you write code in C#, you write everything in one place. There is no need for header files, IDL files (Interface Definition Language), GUIDs and complicated interfaces. And once you can write code that is self-describing in this way, then you can start embedding your software, because it is a self-contained unit. Now you can slot it into ASP pages and you can host it in various environments where it just wasn't feasible before.
So if I'm reading this right, the whole project goes in one big file? *twitch* Can you imagine the linux kernel in C#:
jferg@wallace$ wc -l linux.c#
3172394
Yeah. That's what I'm looking forward to.
So the compiler uses the tags to generate documentation? Cool.. I don't have to document anymore... I just put in a tag and let the compiler figure out what my code actually does.
This will be a great debugging tool!
wish
---
I guess I expected this. Everyone's too busy bashing C# because it came out of Microsoft to realize one simple fact.
/sarcasm
Regardless of where it came from, In spite of the fact that it was almost absolutely meant to be a "Java Killer", I'm still probably going to use it.
Why? It's like a new tool for my toolbox. Sure, I've already got 3 different screwdrivers I'm very fond of (Torx, Flathead, and Phillips), but what if a problem comes along where I a hex 'driver would be easiest? I'll be ready for it.
Even if it's not my programming language of choice, I'll still be competent enough to use it if necessary. All this zealotry and MS bashing is fun, but denying the usefulness of a language just because it came from MS is just narrow-minded, even if it's only a niche language for COBOL programmers to wrap their code in so it'll embed into an asp page.
I mean, someday YOU might need to wrap a chunk of COBOL into an ASP page.
Oh, and by the way,
"If Stupidity got us into this mess, then why can't it get us out?" -- Will Rogers
Let me see if I understand:
"You know all crap we've been forcing you to use to make your code work in our byzantine operating system for the past ten years? Well, turns out it wasn't actually as pleasant as we told you it would be, and we can do without it. Please don't lynch us for your RSI."
Funny comment, but VB != VBS. The I love you bug was written in VB Script, which, while similar to VB, is not the same as VB. Sorry to piss on anyone's parade:)
-={(Astynax)}=-
-={(Astynax)}=-
"Darkness beyond Twilight"
Anders really twisted James Gosling's words here. He says, quoting James Gosling:
... There's a great interview with James Gosling on IBM's developer works site in which he directly addresses this issue. He said, yeah, the whole right-once-run-anywhere, 100%-pure-thing was a really goofy idea, and was more of a marketing thing. He says, in effect, "We didn't think we'd ever be able to deliver all that, and basically we haven't." Here's the inventor of the language saying that neither purity nor portability exists.
And this is what James said:
"The perfect goal of "write once, run anywhere, anything runs on anything" is just goofy. You're never going to run some piece of weather modeling software on a toaster [laughs]. And you wouldn't want to. So there are some scale and capability limits. But within that, you can do an awful lot to make sure that if somebody wants to read a file, it looks the same everywhere reading a file makes sense."
This is clearly a misquote. Gosling is saying that a toaster can't run a weather simulation package (yes, that is goofy). There are physical limits to what you *can* run (ie: you can't run an app with a display requirement of 4000x2000 on a handheld PC with a display of 100x100, or one requiring 128MB on a 64Kb watch). Nothing here is really surprising - Java's strength is trying to hide the minor differences so that you don't need to worry about these while moving between platforms (even some platforms that vary wildly in terms of physical specifications).
æeee!
We focused hard on giving programmers all of the right solutions for interoperating with Internet standards, such as HTTP, HTML, XML (snip)
Ah yes, as usual Micro$oft are keen to promote internet standards. But who's standards? I wonder, do they mean w3 standards or M$ 'standards'?
If you want product speed, you program in C or C++. If you want fast development, you use a rapid application development package like Inprise's Delphi. If you want database access, you learn SQL. If you want a language that anyone with any coding genes at all in their body can use, you write in Perl or Python. If you want to make a serious stab at portability, you use Java. And C#? Uh ...well, let me think now, uh...
That's a pretty narrow view, considering there are many, many good languages out there. For embedded systems, Forth is an excellent choice. For exploratory programming, Lisp is hard to beat. For writing compilers or slinging complex data structures, I'd choose ML or OCaml or maybe Haskell. For distributed systems, I'd use Erlang or Mozart. For certain problems, Prolog is an unbeatable tool.
C, C++, C#, Object Pascal, and Java are all working the same general territory. Sometimes you need a different approach.
Does this mean that they will be releasing BFlat (or what ever) for Linux, Solaris, BeOS, MacOS, etc. Does this mean that I will be able to work and compile my programs under Linux and they will just run under Windoze, like I do now with Java? Somehow I think that the answers to these questions is "No Fucking Way". I think the boys at M$ are as confused about the meaning of "cross platform" as they are about the meaning of "innovation".
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
OK, so javadoc isn't XML, but it does the exact same thing he's talking about here. Maybe the next version of javadoc can support XML as well. Or, maybe javadoc shouldn't be revised until XML2.0 comes out. Or maybe we should wait until the next big Marketing Buzzword comes into the now.
Remember, people, XML is useless without agreed upon standards of the XML structure. These are generally being decided by industries as a whole. This same sort of thing could've happened without XML (look at things like vCards, HTTP protocol, BCD, etc. -- all ways of communicating information irregardless of the platform-specific source).
Just to clear things up about the above (out of context) quote. He isn't saying you can't write a macro virus in VBScript. He is saying you cannot obtain an unsafe pointer and crash the system.
This will probably be moderated down as (obvious -1), but people are already responding with posts about VBScript kiddies etc...
The state of language design these days is down right depressing. The world can't seem to move beyond all of those silly Algol-derivatives like C, C++, Java, and now C#, making Smalltalk- a language designed throughout the 70s and finialized as Smalltalk-80 in 1980- still the height of language design.
What does C# add to Smalltalk, and contribute to the the innovation of language design? Not much. It has "attributes," which are nothing more than embedded XML comments; COM integration (good if you're on Windows, but you could always use Dolphin Smalltalk for that; SOAP integration (Dandy, but it's available for almost every language around); compilation (you can do this with Smalltalk MT); and the ability to regress back into C-pointer mode to write "unsafe" code, to make sure the incompetent GC doesn't eat your objects (which were never rooted, probably by an incompetent programmer).
Many of these things are neat and useful, but reek of the sad state of language design nowadays, and available elsewhere with or without add-on packages.
What's almost as sad, is that a lot of programmers are in awe at the power of C# and Java, with their heads too buried in the sand of C's syntax to see the innovations that Smalltalk (cf. Squeak) made 20 years ago.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Who's helping COBOL programmers today? Who's taking them to the Web? Only on the .NET platform can you embed Fujitsu COBOL in an ASP page. I mean it's truly revolutionary.
THANK GOD! This truly is revolutionary! Yay Microsoft, you have finally made the web usable for the 1970s. I, and half a dozen COBOL programmers who couldn't really get INTO asp until now, thank you.
:D
sig:
sig:
See the "..for smart people" banners Wired runs here? Look elsewhere guys.
Look, I'll probably get downgraded for being redunant or off topic or creating flaimbait, but I'm going to say this anyway. Anders credentials are based more on luck than skill. Here's why:
When Anders took over as the Borland Pascal Chief Architect (note: Delphi didn't exist yet). What he succeeded in doing was developing a product that nearly faded into the dev tool "Where is it now?" bin. It almost disappeared! VB was swallowing up BP programmers like crazy. Knock VB all you want (God knows I do), it was a *much* easier tool to develop Windows apps with because of that Visual paradigm that's so standard in tools today.
Then, one day, Anders gets this "brilliant idea" to take the BP language and put a visual interface on it! What a great idea! Why didn't anyone else think of that!?? (hmmm...)
The people that made Delphi a great tool then and continue to make it a great tool today are *still at Borland*. Anders came up with *one* idea - the Delphi *team* made that dream a reality.
I love Delphi, and I wish Anders well, but don't think that just because C# has his name on it that it will just automatically be great. That's the hype that Microsoft is hoping you'll buy into.
Polymorphism -- It's what you make of it.
One of the key differences between C# and .... Java, is that we tried to stay much closer to C++ in our design
... to pin down memory so it won't accidentally be garbage-collected.
.NET platform can you embed Fujitsu COBOL in an ASP page. I mean it's truly revolutionary.
.NET framework offers. ...we always seemed to end up marrying a programming language to a particular API and a particular form of programming.
...is that we made the decision up-front to not have interpreters. Our code will always run native
.Net to be one of the highest quality releases in Microsoft's history
I was under the impression that one of Java's big strengths was that it didn't stick too closely to C++, and actually had a coherent, consistant design.
Why are there no enums in Java, for example?
Granted, having type-safe enums would be nice; but is this really a big enough flaw to design a language around?
one of our key design goals was to make the C# language component-oriented
Great... they're making it easier for us to write stuff to sell to those VB guys...
C# is the first language to incorporate XML comment tags
OOOER!!! XML tags. I'm glad Microsoft has decided that it's time to follow the industry standard hype. {MumbleMumbleJavaDocMumbleMumble}
Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.
trans: Why bother writing decent software, when some schmuck who's never heard of a linked list can do it in less than half the time with VB (and nobody'll notice the difference)? Might as well accept that, and sell him the bits he uses to do it with.
We focused hard on giving programmers all of the right solutions for interoperating with Internet standards, such as HTTP, HTML, XML, and with existing Microsoft technologies
Well, what else do you need? HTTP, HTML, XML and M$? I should have figured that out a long time ago, and just taken UDP out of my TCP/IP stack altogether.
. Unsafe code allows you to write inline C code with pointers
If you need to write unsafe code to ensure that things don't get "accidentally garbage-collected" either the GC is worthless, or you're failing to fully utilize the paradigm.
people seem to think we're on drugs or something. I think it's a misunderstanding
Yes... the guys at Berkely were doing drugs when they wrote BSD. They guys at M$ are obviously too sober to put ideals over profit.
Only on the
The only revolution I want to involving COBOL very closely resembles the French revolution. Guilotines and all.
with C# we were able to start with a clean sheet of paper
Hrmm... earlier they were talking about how it stayed closer to C++ than Java did; now it's a "clean sheet of paper". I really wish they could make up their mind.
The unification of programming models, which the
So, they've learned the error of their ways, and have decided to bring the new unified APIs into the world with a new language?
one of the key differences between our IL design and Java byte code
And this is important how? Are they saying you can't run it interpreted? Anyways, I'd like to see a JIT compiler do better than the Hotspot model (interpretation + realtime profiling to find sections of code to compile to native code).
you can name your source files anything you want.
For some reason they seem to think this is important. I fail to see it. Skinable filenames?
I think developers will find the release of Visual Studio
It's a little late for them to start worrying about quality now; they're getting their asses Ma-Belled.
my sig's at the bottom of the page.
I meant no disrepsect. I literally meant I'd rather use Dylan (even though it's noi longer supported).
Actually, the best language I've ever programmed in is NewtonScript created by Walter Smith who, ironically, later left Apple to work on Windows CE (now he works on Windows Update).
It's worth checking out (NewtonScript, that is. Not Windows Update).
Kevin Fox
Kevin Fox
Is C# a good language or not?
If it is, then a compiler that emits C code compilable by gcc should be built. End of story. I think Microsoft would hate that.
If tits were wings it'd be flying around.
This should be a standard measurement for articles concerning Microsoft. Call it the "bogosity" index of the article at hand.
Ah, but you missed multiple occurances of innovat on a line. It may be that there are more than than. (I'm not saying that there are, but it's possible. Something like a line:
"We're innovating using other innovations...")
how about
lynx -dump some_URL | perl -e 'my $count=0; while(){ while(m/innovat/gi){ $count++; } } print $count,"\n"; '
(I'm sure there's a quicker way to do it with sed or something else, I just tend toward perl)
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
I'm somewhat interested in it.. I registered csharpplanet.com and planetcsharp.com, I just haven't gotten around to putting up content yet since I'm bogged down with other freelance work..
BilldaCat
To start with, let me state that I have absolutley no knowledge of the C# language and so may be off on a few points. I look forward to vigorous correction by C# proponents.
.Net framework
.Net is that tied to C#.
.NET platform can you embed Fujitsu COBOL in an ASP page.
:-)
.Net. Looks like that COBOL programmer will have to learn a few new tricks after all.
.NET Compact is a subset of the .NET framework designed to be ported to other devices and platforms.]
.NET is the Java VM, IL is the bytecode, and C# is Java. The parallels to things like .Net Compact and PersonalJava are just too close.
First of all, C# is not a Java clone. In the design of C#, we looked at a lot of languages. We looked at C++, we looked at Java, at Modula 2, C, and we looked at Smalltalk.
In other words, it's Java. Java has concepts taken from amny of those same languages - packages, everything inheriting from Object, and so on. They might have chosen slightly differently, but they seem to share the same base.
Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?
That's because having such a feature as part of the language is not nessicary. You can get every benefit of enums he mentioned in the article just by making a static class like so:
public class EnumThing
{
private int color;
private EnumThing();
private EnumThing( int colorID ){ color = colorID; }
public EnumThing RED = new EnumThing(1);
public EnumThing BLUE = new EnumThing(2);
}
Then you just refer to it by EnumThing.RED, or whatever. You have the same level of type protection, and in addition you can specify the access level of the class to make the enum only accessible to that package (I have no idea what level of access control C# enums have).
And C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.
It's not XML based, but Java has always has JavaDoc comments from the start - you've been able to generate documentation directly from code for some time now. This might be at a more granular level though (Javadoc comments are really for methods and attributes and classes, mostly).
You could easily add this to any language though - you'd just have to run documents through an xslt processor to strip out xml tags before compiling.
We've tried not to take an "ivory tower" approach to engineering C# and the
I don't have much to add, I just thought it was interesting to hear that
You've seen all the COM interoperability that we have built into the language and into the common runtime; you've seen how you can just import existing DLLs [Dynamically Linked Libraries] using the DllImport attribute; and you've seen how even if that doesn't get you there, we have the notion of unsafe code. Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected.
And how does security work in C#? That's a lot of access to a lot of things I'm not sure I want to trust at all!!
When you're writing unsafe code in C#, you have the ability to do things that aren't typesafe, like operate with pointers. The code, of course, gets marked unsafe, and will absolutely not execute in an untrusted environment. To get it to execute, you have to grant a trust, and if you don't, the code just won't run. In that respect, it's no different than other kinds of native code.
I really hate region oriented trust models. It also opens yourself up to bugs where you can get something to run even if the region is not trusted...
We want to create a platform where there can be innovation. Who's helping COBOL programmers today? Who's taking them to the Web? Only on the
Nothing like embedding COBOL in a web page for the ultimate in maintainability!!
I wondered how that really worked with other languages though, and came across this:
For example, we only have one kind of class in C#, and it is always garbage-collected. Managed C++, on the other hand, has two because it has to preserve the non-garbage collected style of programming.
So it seems for other langauges there are extra constructs that must be learned in order to work with
One of the interesting things that came out of our developer tracking study is that over 60 percent of all developers in the professional developer market use two or more languages to build their applications.
Yes, { Java,C++,Perl,PHP } and { HTML, WML }.
And what that tells us, especially when we ask which tools programmers use, is that there isn't going to be one object-oriented programming language which is the end all and be all language that everyone will use.
That might be true, but that's quite an extrapolation. I think it might be more true to say that the languages you use will migrate into business logic and presentation langauges, and perhaps more fragmented from there.
This next part is REALLY funny:
C# has more headroom and more power than VB does.
Osborn:
Meaning that you can accomplish more with fewer statements in C#?
Hejlsberg:
Well, meaning you have more power through the provision for unsafe code.
Yep, Lot's 'o power - just like a six year old with a tactical nuke is pretty powerful.
I think the approach we've taken with the IL is interesting in that we give you options to control when compilation -- or translation, if you will -- of the IL to native code occurs.
This is kind of interesting. Basically, IL is like the Java bytecode, but they give you a lot more options as to when the compilation to native code happens.
However, it does make you wonder why they just didn't work on using java bytecode as the IL, compile everything into that, and then work on ways to give you the same degree in compilation flexibility for java bytecode they do with IL.
For the compact framework, we have the EconoJIT, as we call it, which is a very simple JIT [Editor's Note:
Now I'm sure that
When you make the decision up-front to favor execution of native code over interpretation, you are making a decision that strongly influences design of the IL. It changes which instructions are included, what type information is included, and how it is conveyed. If you look at the two ILs, you'll notice that they're quite different.
I'm not sure if this is a stregth or a weakness. In once sense it's nice because you get somewhat optmizied IL for the type of platform you hope to hit. It another way it's quite annoying because you have to regenerate the IL for difefrent types of platforms - sort of moving binary incompatibility from the processor space to the task space. This might be bad for a library that could be used in a client side to generate something, but also up on a server in a web environment, and seems somewhat against the philospophy of components they are trying to put forth.
An interpreter emulates a CPU. We turn it upside down and we do one pass -- we always do one pass -- where we convert the instructions into machine code.
So, no HotSpot for C#!! It looks like they've decided dynamic optimization is a waste of time. Oh well, I guess they really didn't want that server market after all.
Since C# does not have that sort of marriage between physical and logical, you can name your source files anything you want. Each source file can contribute to multiple namespaces and can take multiple public classes.
All I can think of here is - ARRRRRRGH! I can just iamgine the maintainability of looking for code that could be ANYWHERE. It also seems sort of dangerous in that some totally independant library can "contribute" something to any namespace at all. It might be of use but it sounds like people could really make a mess with it.
Now, he is asked about Generic programming and what C# plans in relation to same:
Well, some of what we had hoped to include in the first release has been constrained because -- unlike what everyone believes about Microsoft -- we do not have unlimited resources. We had to make some hard decisions in terms of what is actually in this first release.
And generic programming features didn't make the cut. Now there's something you really want to tack onto a language later on!!
Our IL format is actually truly type neutral. And, by keeping it type neutral, we can add generics later and not get ourselves into trouble, at least not as much trouble. That's one of the reasons our IL looks different from Java byte code. We have type neutral IL.
Now that's an interesting aspect to IL. It will be interesting to see if they do come up wth some Generic programming ideas in the language, and how well they work out.
Overall it seems like an interesting language, and the end part of the interview mentioned some very nice capabilities. It will be interesting to see if they can stop some of the momentum of EJB application servers in the market.
They also talked about a number of areas in the EJB spec where vendors are allowed to create extensions. They claim that will lead to a lot of code that can only run within one app server, but from what I've seen people are pretty careful not to use vendor specific extensions of any sort unless absolutley nessicary - and usualy it's not.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
- Is low-level enough to permit tweaking of memory allocation and can map classes onto hardware register sets (so Java is out)
- Has intrinsic vector types so I can write code for vector units which is optimized by the compiler
- Doesn't lost all its potential optimizations to pointer aliasing problems
This would be great for writing games! The world may have enough C-like languages, but that doesn't mean that specific sections of it don't need their own.--
It's a
-- Danny Vermin
From the sounds of things, C# is a sort-of-interesting language that's fatally crippled by its close relationship to Microsoft. Unless it gets full, free, equal implementations on Unix platforms, it's dead.
That doesn't mean it's entirely worthless, though; in fact, the real benefit of C# might be that it guilts Sun into finally submitting Java to a real standards body. Sun likes to portray itself as an open company, and that image has largely flown up until now -- but when the contrast of Microsoft standardizing C# and Sun zealously guarding Java becomes too glaring, Sun's going to look decidedly less friendly. With any luck, Microsoft's pressure will push Sun into doing the right thing.
As one of the highest-rated posters already implied, the article is full of self-contradiction and buzzwords. A modularized language that does away with interfaces and header files? Do tell..
I'll reserve absolute judgement until I play with it, but, here's a thought:
Whenever M$ gets backed into a corner by a competing technology that they either can not buy, or can't catch up to early, they release a vaporous competitor. This 'alternative' is intended to
1) bring in a cash infusion from the 'early adopters' of all things Microsoft (Usually clueless managers who mandate to unwilling IT staffs),
2) get FUD and fluff from magazine article writers from Ziff-Davis who are so deep in M$'s hip pocket they eat lint,
3) engineer public opinion that M$ has something better than the competition, 'just waiting in the wings'.
M$ most recently did this with WinCE, as a response to the PalmPilot. They had no real alternative to PalmOS, so they just threw something together and hoped it would stick enough to eat away at Palm. Now that they've had a few years to look at the problem, they release PocketPC - not an improvement IMHO; but I digress.
C# looks like round 2 of the Java war. Period. It's not INNOVATIVE in the least. It's a different way of doing things. It rolls together some previous ideas (comment markup, components, C syntax, M$-specific VM to run the bytecode) to see what will stick.
As with all things M$, it's probably a good idea to wait until Version 3.1, to see what it has to offer BESIDES an alternative to solid technology.
-- What you do today will cost you a day of your life.
So you're saying that once a word processor is on the market, companies should stop writing word processors? Come on, the market has room for many word processors. Let's not knock Microsoft for coming out with Word when WordPerfect was available. Just look at how many word processors and typesetting programs we have in the Linux world, and there's still plenty of room for improvement (on the word processor side at least).
For more information, click here.
I think lots about this, really, truly:
1. Too many languages? No. Too many C's? maybe. People keep going back to C as the lingua franca so there has to be something to it. If you're going to come up with a new language, sticking to C roots may be the best way to ensure durability.
2. Languages will have to become more spcialized as time progresses and the complexity and scale of computing tasks grow. The future I see in my crystal ball (written in C, btw) are languages devoted to specific tasks such as cgi, game development etc. In a lot of ways this is a throw back to the early days of Fortran, Lisp and Cobol which were non-general languages. There weren't really the issues of scale and complexity back then though that we face now, so it was fairly easy for C to sweep them under the rug.
3. Future specialized languages will almost assuredly be themselves written in c. I'm not talking about yacc-hacks but honest-to-god interpreted or even compiled languages. What this means, though, is that in a future with fragmented languages used for specialized purposes, people looking to expand their power and control will look back to the source of those languages construction which leads to point 4.
4. Which is the same as point 1. People keep going back to the lingua franca.... so future specialized languages should stick closely to C while maintaining all the neat features that make them specialized in the first place...
Was that a bit scattered? Sorry, it's clearly organized in my head, but I haven't gotten around to scribbling out the boxes and arrows yet...
2 1337 4 u!
The questions I would have asked Hejlsberg:
- will Outlook (or WinMe) come with this "innovative" JIT compiler?
- will it be within the same "security" model as VBScript and WSH?
- what are the C# file extensions again?
While that's true (insert typical raving about enharmonics in different instruments) do you think Britney Spears would want to be associated with ANYTHING labeled "flat"?
For more information, click here.
To fulfill those promises, Microsoft not only need to do better than some of the best dynamic language implementors in the world, but they need to do the hard work of producing implementations for their less favorite platforms, just like Sun did with Java. Given Microsoft's track record, I suspect that is less likely than the proverbial snowball in hell, and I wouldn't exactly plan projects around Microsoft's promises.
But if they deliver, good for them and good for all of us. Let's hold Hejlsberg to those promises a year from now.
I really wonder about a few 'features' of C#. First, I should preface this by saying I spent 6 years programming my Amiga in nothing but 68000 assembler. I then spent years programming in C (on the Amiga and when I first migrated to PC). When I heard that Java did away with pointers, I was less than impressed. Over the past year, though, I've programmed in nothing but Java and I actually appreciate this 'dumbing down'. Debugging other peoples' code is way faster because of it. By allowing 'unsafe' code, C# is going to unnecessarily complicate debugging and open up the application to longer development times and increased maintenance costs.
'They' seem to think that allowing unsafe code is no worse that allowing naitive calls. I beg to differ. If I'm going to access libraries that I've written in the past, those libraries were written and debugged with tools speicifically designed for that particular language (ie, C++ in my case). I've debugged and tested the code using source level debuggers and it's been in production in other environments so I feel secure in bringing the same library over to Java. Finally, like other aspects of object oriented programming, the libraries become a black box, hiding their 'complexity' from other developers on the project. When you allow for the ability to start dropping 'foreign' code right into your c# code, it is going to have a deleterious impact on OO development. Things don't remain as 'encapsulated' and it will likely demand a greater (language) knowledge from your development team. The last problem with 'unsafe' code is how you go about debugging it. When doing fancy pointer acrobatics using C/C++ (and even one graphics application I worked on using Delphi), I really needed the ability to drill down to the underlying assembly code. With Java, I've never found the need to so this. What level of debugging will be available for C#? How will C# cater to the debugging/testing needs of developers using "any" language?
Finally, I just want to say that I'm not happy about their support of compilation to native code. Having code be interpreted by default and leaving it to vendors to create native code compilers keeps your application MUCH more platform independant. Sure, Java was slow at first because all initial Virtual Machines interpreted byte code, but these days you wouldn't think about using a JVM without at least JIT (if not naitive compilation). The point is, your application always ships as 'generic' byte code and it's up to the user to have a JVM that offers JIT/naitive compilation.
Man, the gall of Hejlsberg. I used to code in VB, and some of us at work still do, and we were ROFL at this quote.
Maybe he meant "I can't write unsafe code with VB."
Or maybe someone spiked the punch again.
Will in Seattle
Rather than evaluate how C# might help them most /.ers only want to start comparing it to what is already out there ("so what if it can do blah, I can already do blah by blah blah blah in the blah language.")
The fact is, when it comes down to it, every high level language concept can be done in assembly or machine code. Big deal. The important part is how does the high-level language make the programmers life easier (and thus improve their productivity).
Stop your bitching, start thinking how C# might make you a better programmer. Tim Sweeney has written an article that you need to read. Although (from what I can tell) C# doesn't meet all his ideas of a "next generation" programming language, it is closer than C++ or Java. A quote for the whiners:
Assembly programmers didn't realize they needed processor-independence; it doesn't seem like a practical concept when your life's work is focused on micro-optimizing individual CPU instructions and register usage. C programmers didn't realize they needed objects because, after all, the world is made of functions and data structures! This seems silly nowadays, but at the time, C programmers had become so accustomed to the strengths and limitations of their language that they thought: since it's so difficult to express object-orientation in C, object-orientation must be a flawed concept. It wasn't then clear that C was simple a poor language for object orientation.
Similarly, most programmers don't see the fatal flaws in C++ and Java. People tend to look at the failings of C++ frameworks, component-based software, and binary platform independence, and deduce that those concepts are flawed. It isn't clear to most people that C++ and Java are simply poor languages for frameworks, and parametric polymorphism, and binary portability. Most programmers never switch languages. Either they don't want to, or the circumstances of their job don't allow them the luxury.
Complexity Happens
Yes, this would be very cool... assuming MS's marketing and legal departments don't piss in the soup and turn C# into yet another MS proprietary weapon to snare customers into an MS-only world. I can imagine them tying key technology into C# and .NET that is somehow
covered by MS patents or such, making it near
impossible for a truly open implementation to
be created. They will of course wait until
C# has caught on, then break compatibility at
some point in the future. At least that is
my fear.
The designers of C# seem to have done some really interesting things with it, but they are not ultimately free to implement everything in the totally open way that they seem to desire, not unless management allows them to... and we all have seen the track record that MS management has in that respect (cough)Kerberos(cough).
Excuse me for being skeptical, but I've been burned by MS one too many times.
Thad
The Bolachek Journals
Only on the .NET platform can you embed Fujitsu COBOL in an ASP page. I mean it's truly revolutionary.
HAHAHAHAHAHAHA!!! I almost fell out of my chair when I read that. ASP in COBOL???? Revolutionary??? Maybe Microsoft should also bring back some UNIVACS to run their .NET servers on :)
Never knock on Death's door:
The Anti-Blog
Quicker to type, anyhow. I can't bear to see an explicit loop in a one-liner.
m l | perl -e 'print -1 + scalar split /innovat/s,join "",;'
lynx -dump http://windows.oreilly.com/news/hejlsberg_0800.ht
Innovative bogosity rating: 8
---
Despite rumors to the contrary, I am not a turnip.
Near the beginning:
we tried to stay much closer to C++ in our design. C# borrows most of its operators, keywords, and statements directly from C++. We have also kept a number of language features that Java dropped.
Then about a third of the way thru...
with C# we were able to start with a clean sheet of paper, so to speak. We did not have any backward compatibility requirements
Previously the interview had been at least interesting, but from here on he lost all credibility with me. I think he has been absorbed into the borg and has lost the power of independent thought.
--
Infuriate left and right
C# suppots Goto: after 30 years of people trying to get rid of it this misrable programming construct, Microsoft include it in their 'clean sheet' language. How pathetic is that?
Anyone that tries to pretend that C# isn't a Java ripoff is just completely full of it, and doesn't know a thing about Java. The gall is unbelievable. Its the big lie.
"the idea of having everything in one file is a bit screwy"
True, but I think the point was that physical
and logical structure were not tied together,
the way they are in Java. You *could* put
everything into one file, split one
big class into several files, put two classes
in one file, etc. In pratice, one class per
file is probablly the best way to go most of
the time, but I still like the fact that
you *can* separate the physical vs. logical
structure of your modules if you want to.
Stephen Molitor steve_molitor@yahoo.com
This may be a little offtopic, but I program a little bit but never in C++ (yet) therefore the meaning of the word 'enums' is strange to me.
enum is short for enumerated type, a type with a list of named possible values. For example:
enum DaysOfTheWeek { Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday };
If you define a variable of this enumerated type, you can't assign other numerical values to it (without forcing it via casts or other mechanisms.
Not a huge deal, but handy, and worthy of mention as a missing item.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
You could write a C compiler that had safe pointers. It would generate significantly slower code, but it could be done quite easily. You just treat all memory as bounded arrays, and each pointer as having an array and an index. If the index is outside of the range when you attempt to access the pointer, you get a fatal error. Simple.
I'm still disappointed that nobody seems to have come out with a universal sandbox that isn't tied to any system or language. Emulation of real-world systems is very complex (and therefore hard to optimize and debug), and if you put in mandatory features like garbage collection in the Java runtime, it's very hard to write compilers for certain languages.
BTW, I think calling it C# is a cheap stunt that will just add to name confusion. C is all about pointers, if pointers are frowned on as "unsafe", rather than the default way of doing things, it's not C.
---
Despite rumors to the contrary, I am not a turnip.
"Parts of Word, internally, use a p-code engine because it's more compact"
That's first time I've heard the adjective "compact" applied to the ultimate in bloatware. Even Emacs looks compact compared to Word.
It's no secret that they are much better at buying and extending than they are at innovating. And actually not everything that buy and extend sucks.. IE for example is much better than any other browser I've ever tried.
And there's actually little or no Spyglass code left in IE today.
Simon
Coming soon - pyrogyra
Usually, in a classless OO language, most of the explicitly defined objects clone themselves and act like classes anyway. It's a step towards a fully imperative language, like Perl or Forth, where the definition parts of the language are just more commands to be executed in sequence, unlike, say C, where struct and function definitions are all read and analysed before you are allowed to run any commands.
However, I think in newtonscript's case, the classes are just hidden and called "types" (however, I could be wrong; I only skimmed the page).
---
Despite rumors to the contrary, I am not a turnip.
They just had to pick that ugly C syntax.
I just finished dealing with that! I wrote Cugar to make C and C++ look clean and graceful, like Python. Now I suppose I'm going to have to write #ugar.
(ladies and gentlemen, please keep the barrage of rotten fruit to a bare minimum. I like Python syntax)
---
Despite rumors to the contrary, I am not a turnip.
lynx -dump some_URL | tr -c 'a-zA-Z' '\n' | grep -i innovat | wc -l
Here, I use 'tr' to break up words into seperate lines.
It seem strange looking at these types of languages. The more langauges evolve, the more they get the sementics of LISP.
LISP has an interactive read eval print loop, so you can do interactive development without signifigant recompilation.
Java inner classes are just a more verbose way of getting closures.
LISP gives you dynamic redefinition of classes and a lot of introspection of classes, objects, etc. It has safe execution in that it's crash-proof. All objects are subtypes of 't', but may be declared more explicitly. It also has seperate compilation.
It does have a few things that other languages don't. It's 30 years old, although using post-1989 versions is more pleasant. CMUCL has an interpreter, bytecode compiler, and machine code compiler. It's had all the functionality of 'aspect oriented programming' for about 20 years. You can use LISP to define transformations on LISP programs. (The 'SERIES' package is an obvious example, but the OO subsystem is another.)
The base OO system (CLOS) is a wet-dream, and with MOP, you can add network-transparency, orthogonal persistence to objects, or even reimplement your own OO system.
Admittedly, it doesn't support compilation into hard-to-reverse-engineer bytecode and later compilation of that bytecode. Products would have to be distributed in an executable format, or as source.
The 'pretty girl' is homicidal maniac, and a psychopathic liar, suffering from delusions and hallucinations...once you sleep with her, you can't ever sleep with anyone else, because she has the super incurable form of a really virulent and nasty STD, and your IQ was just lowered by 30 points...
...and she's laughing at you...
...and she stole your best girl friend...
...and she told all your friends what a lousy lay you were...
...and you had to pay her twice (after she called you 'ugly' and 'stupid')...
Remember guys, this is Amerika. Just because you have the most votes, doesn't mean you get to win.--Fox Mulder
Has anyone ever heard what C++ inventor Stroustrup thinks about the latest addition to the C family?! Although we never really had a C *family* until that third language came up ;-)
Stroustrup, IIRC, likes his C++ a lot but admits that it is very complex and not suitable for everyone. Maybe he can live with a simplified version for those programmers that are less advanced...
That's pretty simple, huh?
Yech.
It reminds me of writing object oriented programs in C. Sure, it can be done, but it is inefficient and a waste of time, like doing text processing in FORTRAN.
The good things about C and C++ are that they have a syntax. LISP has no syntax. You cannot simply look at a LISP program and read it; you need to understand the functioning of every single macro. You can (and people do) write your own language in LISP. You have to, to get anything useful done. It makes the average LISP program incomprehensible to anyone but the original author.
LISP may have sexy features, but only because the sexy features are easy to add to an interpreted syntax-less language. You can do anything you want in LISP, and that is both its power and its weakness.
It's a great academic language, but for serious work (i.e. big projects with many programmers) LISP is simply not viable.
--
It's a
-- Danny Vermin
Well, I was referring to lingua franca in the sense that it is the language of the State, business and social order. A lot of the infrastructure we take for granted (like, oh, Unix) is written in C. I believe Perl was written in C (correct me if I'm wrong) and a big bag of our tools are too. There were precedents to C for sure and some of them were amazingly well-formed for the time they came from, but C hit it big because it promised the same thing Java does: protability. My how our opinion of "portable" has changed!
Doesn't lingua franca mean french language
Technically that would be la langue Francais. Lingua Franca is Latin for "language of the Franks" and dates to the time of Charlamagne (literally Carolus Magnus or Charles the Great) the Frankish king who was crowned Holy Roman Emporer. The HRE was, basically, the last stab of Rome (sacked and beaten in the west) to impart it's imperial "cred" on someone with power and thus maintain the image of an undying line of civilizaiton. It was also a fine way for the newly-minted Catholic church to grab onto a chunk of the state by making emporership conditional upon the approval of the Father of Rome (Pater Romanii, later Poppa Romanii, later just plain old Pope). The bottom line is Charlemagne spoke Frankish, a German-like language that got imported into France during the HRE (displacing Asterix and his Gauls). The adoption of Latin from the vestiges of Rome and the Church gave it a good mixing until it wound up as, essentially French. Witness, for instance, the popular name of Frankish nobility: Clovis. The french call him Louis. Hm. Anyway, since old Chuck spoke Frankish and he ran the show for a large linquistic diverse conquered area, Frankish became the language of everything but the peasant. Sort of like English during colonialism. Viz. Lingua Franca.
Sorry if that was too much, I get carried away sometims.
2 1337 4 u!
Why on earth are you using a switch statement in an object-oriented language, anyway? That's just poor engineering. If you have behavior that depends on a on object's type, you should polymorphize on that object, either by (in my example) subclassing InodeType or by using double-dispatch, a la the Visitor pattern. Sure, that will cause all of you VB programmers who've bought "Teach yourself Java in 21 days" a little grief, but it's the proper way to write OO code. If you really want to use switch statements, then I can't see why you care about type-safety.
This is absurd. You have clearly misunderstood my argument. I didn't say "hey, language features which make code terser are bad"; rather, I said "syntactic sugar is bad." There's a big difference there. Syntactic sugar makes your code terser, but at the expense of consistency.
Using established patterns and idioms is the way to make code easier to write and maintain. C#'s "support for type-safe constants" defeats some serious OO ideals by allowing you to cast from one enum type to another -- basically, this means that "you're still using static final ints, but the compiler will sneeze at you if you try and abuse it." What is the possible sense of casting a "kind of shape" to a "kind of file"?
Not to nit-pick, but it's twelve lines of code (try counting semicolons), and "what syntactic sugar is [sic] gets you" is inconsistency. The time it takes me to write 12 LOC is negligible compared to the time it saves me later by having type-safety. Anyone who tells you that "the fewest LOC is best" has never
- engineered any significant project.
- maintained someone else's code.
A terse, elegant solution is great. A terse solution that relies on a fashionable language "feature" is merely the mark of a programmer who doesn't understand what it takes to become an engineer.I was under the impression that one of Java's big strengths was that it didn't stick too closely to C++, and actually had a coherent, consistant design.
Java's consistent design???Right, like the bizare dichotomy of reference types and primitive types?
XML tags. I'm glad Microsoft has decided that it's time to follow the industry standard hype. {MumbleMumbleJavaDocMumbleMumble}
JavaDoc is not the same as the XML-attributing system they discussed. As it stands, JavaDoc is extremely lame. Even POD is more useful, and POD is quite broken on its own.
Well, what else do you need? HTTP, HTML, XML and M$? I should have figured that out a long time ago, and just taken UDP out of my TCP/IP stack altogether.
I can't figure out what the hell you are trying to say here, but its not coherent or intelligent.
If you need to write unsafe code to ensure that things don't get "accidentally garbage-collected" either the GC is worthless, or you're failing to fully utilize the paradigm.
Did you understand a fricking thing those guys said?
They guys at M$ are obviously too sober to put ideals over profit.
How would Berkeley value profit over ideals? Why would M$ value ideals over profit? You're almost at troll level here.
Anyways, I'd like to see a JIT compiler do better than the Hotspot model (interpretation + realtime profiling to find sections of code to compile to native code).
Uh, check some benchmarks - HotSpot'd code still runs at least twice as slow as native.
The rest of your post I won't even comment on, most of it was uninformed trolling. Once again, I am also highly suspicious of MS and .NET, but this retarded trolling is ridiculous.
This is what happens when you take C and try to pound it into submission. You just end up making a hash of things.
-- Life is short. Forgive quickly. Kiss slowly. ~ Robert Doisneau
I have recently started using gtk+ and the API is similar IN CONCEPT to that of Java, C++ and C#. At least to me it is. Everything in gtk+ is also an obect, at least all the widgets, and believe it or not they have some inheritance. I.E. Composite widgets inherent from there ancestors. It is really quite interesting to see an object oriented C again. Gtk is simeilar to neuron data, which once upon a time used an object C approach. C# may be what Java should have been, but that can only happen if it is cross platform. I noticed that they submitted it to ECMA, but they also did that with XML, HTML4.0 and so many other standards that they eventually toss aside. What will be the life of C# before they make M$ specific extensions that noone else can implement. ;-)
~~~~~~~~~~~~~~~~~~~~
I don't want a lot, I just want it all
Flame away, I have a hose!
Only 'flamers' flame!
First: LISP is not an interpreted language. It has modern, high-performance optimizing compilers that are comparable in performance to C/C++, and have been for the last decade. In fact, a paper from a year ago showed that it was twice as fast as C++, by either measure you want to used: execution speed or productivity. (reference available upon request.)
A simple syntax lets one programmably alter program code. These types of operations are potent. (See Aspect oriented programming, where they're reinventing macro's for C++/Java. I agree that it'll be a big thing in 10-20 years.) Macro's let one transparently and trivially add in automatic serialization onto objects. Or handle remote-procedure call, orthogonal persistence, network-transparency. Literally, these can be added to a class with one line of code.
Like any other powerful feature, it can be overused or abused and make code swiss cheese. But, properly used (CLOS/Series/defpackage), it lets one add signifigant semantic abilities to a language.
You cannot look at a C program and just read it. For example: What does this code do?
typedef struct tree_node Tree;
struct tree_node {
Tree * left, * right;
int item;
};
Tree * foobar (int i, Tree * t) {
Tree N, *l, *r, *y;
if (t == NULL) return t;
N.left = N.right = NULL;
l = r = &N;
for (;;) {
if (i < t->item) {
if (t->left != NULL && i < t->left->item) {
y = t->left; t->left = y->right; y->right = t; t = y;
}
if (t->left == NULL) break;
r->left = t; r = t; t = t->left;
} else if (i > t->item) {
if (t->right != NULL && i > t->right->item) {
y = t->right; t->right = y->left; y->left = t; t = y;
}
if (t->right == NULL) break;
l->right = t; l = t; t = t->right;
} else break;
}
l->right=t->left; r->left=t->right; t->left=N.right; t->right=N.left;
return t;
}
You claim that LISP is incomprehensible and cannot be read without looking at the details or macros. C/C++, without macro's, appears to have the same shortcoming.
Because you have to trace through all of the classes and functions and definitions. Large, or even small gobs of code are hard to understand in any language. LISP, Java, or C++, although it can be helped if the people use reasonable variable names and comment their code with invarients.
Please do tell me what this code does and how it works. Yes this was some code I was attempting to port to LISP. I gave up trying to understand it and rolled my own implementation. I won't post what it does. You can email your guess if you want.
In my experience with Allegro Common LISP, the compiler produces dog-slow code even on the highest "optimization" settings. I laugh at this paper that "shows" LISP to be 50% faster than C++. There are always articles saying Language X is faster than Language Y, no matter what X and Y are. They set out to prove something, and prove it, by ignoring evidence to the contrary and magnitfying supporting evidence. If you're convinced by this paper, and not just wowed by its conclusion (hey, you obviously love LISP) then maybe I should read it.
Just looking at CLOS, the amount of effort the compiler has to make just to dispatch a method invocation makes it seem extremely unlikely to me that a CLOS program is ever going to even approach an equivalent C++ program in speed terms.
Mind you, I only have experience with ACL (Allegro Common LISP) which performs extremely poorly. If you know of a faster compiler which is commercially available, please let me know!!! We have a mission-critical application written in CLOS which needs an order-of-magnitude speed improvement. I was considering recoding it in C++ ;)
You mention many features of LISP which are useful - and indeed they are. LISP is very good at wrapping things in other things. That's all its syntax does, so it should be ;) However, Smalltalk has an equally powerful object model, and it uses the more friendly infix notation (let's face it, prefix notation is unreadable to anyone but Ubergeeks).
As to your obfuscated C function, well wow, I've never seen one of those before ;) I can't be bothered decoding that function. It has no comments, no meaningful variable names, and no meaningful function name. If I had to guess I'd say it was doing an operation on a balanced tree.
But my point about syntax is that C's syntax helps you read the code, whereas LISP's syntax gives you no help at all. Sure you can write ugly C and LISP code, but I defy you to show me pretty LISP code! No-one's saying that every C program is readable - many quite famously are not - but we are trying very very hard to make our LISP code readable, and still failing.
LISP is certainly a more powerful language than C++, I'll concede that, but that sort of power scares me. Wait until you work on a bigass project and you'll see why.
--
It's a
-- Danny Vermin
However, Smalltalk has an equally powerful object model, and it uses the more friendly infix notation (let's face it, prefix notation is unreadable to anyone but Ubergeeks).
:)
Then quite looking for that non ACL CLOS implementation and use Smalltalk!
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I don't know the whole history of LISP from way back when, maybe it was interpreted for the first few versions from 20 years ago.
C practically started out as being a simple frontend, one-to-one translatable to assembly language. And now we have optimizing compilers that do a hell of a lot more.
This all is about 20 years before my time, so I don't have all the details.
That C function is (believe it or not!) The demo code written by the creator of Splay trees. (Daniel Sleator, CMU) for the splay operation. BTW, it can be decoded in either language, with a 8-line block comment at the head, and about 8 lines explaining the variables and the invariants.
As for syntax, I think I know where you're problem is.. With C, you create lots of variables, but each line of code is essentially atomic. With LISP, it's (syntatically) annoying to bind a variable, so you use function calls. This means that the 'line of code' in C is short, but it's long in LISP. (I experience a similar problem with GUI programming in TCL. It's easy to create&destroy a widget set. To create and UPDATE it has no flashing, but requries a lot more work.)
For examile, I can think of a few things that might help. A coding style change, with a macro&codewalker to turn:
(assn
(a = (- (circbuffer-room circbuffer) 1))
(b = (- (circbuffer-alloc-size circbuffer) wi))
(c = (min a b))
c)
into:
(min (- (circbuffer-room circbuffer) 1)
(- (circbuffer-alloc-size circbuffer) wi))
You're right about the first to be easier to understand, but calling it an artifact caused the syntax of LISP is wrong. I'm using a lot of LISP syntax there. I think it's the deeper reason, it's easier to keep track of what a single variable is than the gob of code. Fortunatly, you're not really tied to the existing syntax that LISP gives you, and the macro 'assn' is about 6 lines of code (If you want an implementation, I'll write the 6 lines.) . Infix is also a lot more familiar for representing expressions, but a long line of infix code is just as hard to understand:
(Taken from a quick patch)
+#define F_APPLY_FG_ATTRIBUTE(orig,add) \
+ (((add) & F_FGCOLOR) ? \
+ (((orig) & ~F_FGCOLORMASK ) | ((add) & F_FGCOLORMASK )) \
+ : (orig))
+#define F_APPLY_BG_ATTRIBUTE(orig,add) \
+ (((add) & F_BGCOLOR) ? \
+ (((orig) & ~F_BGCOLORMASK ) | ((add) & F_BGCOLORMASK )) \
+ : (orig))
+
+
+#define F_APPLY_ATTRIBUTE(orig,add) (\
+ F_APPLY_FG_ATTRIBUTE ( F_APPLY_BG_ATTRIBUTE ( (orig) , (add) ) , (add) ) \
+ | ( (add) & ~ (F_BGCOLORMASK | F_FGCOLORMASK) ) )
Here, the ability to break this up into multiple lines of code would make it a LOT easier to understand, the same way it helped above. (What this code is trying to do is overwrite attributes on text, which can be both flags or colors. For flags, it or's them, for colors, it overwrites. Given the #define names and some study, you could infer that. You could never just read it out.)
--
Now, before I start too much on compilers, I only know one compiler fairly well, CMUCL, as ACL costs about 30x what I can afford.
The CMUCL compiler was a very sophisticated compiler for it's day, and (appears) to still be the most sophisticated even today. It uses type declarations. It treats them as assertations to be checked, but also does type inference on them. If you give declarations on your defstructs and functions, it'll usually do enough type inference to determine everything else. Under these conditions, it spits out essentially the same optimized code that C/C++ compilers would. In a benchmark with EGCS, it takes about 30% longer for array multiplication. Not bad for a compiler that's been orphaned for 6-7 years and in the public domain.
CLOS method call for PCL under CMUCL is fairly expensive, about 10x a function/closure call. For highly recursive functions or inner loops, that sucks, otherwise, only profiling can tell whether it matters. (I benchmark it at about 500ns). Comparing C++ and CLOS, CLOS offers dispatch on multiple arguments, something which C++ cannot. With the MOP, it offers infinitely more than C++ could. It's not an apples to apples comparison.
Depending on the nature of your codebase, CMUCL might speed it up some or a lot, or slow it down, or be a wrong choice. Also, what you describe has happened in the past, the Garnet project at CMU started out in Lisp, when they ported it to C++, they found their first C++ version about 3x faster than their highly-optimized LISP. (This might be an artifact of bad compilers or coders, or the fact that they didn't use CLOS. As Gabriel wrote, It can be too easy to write slow code in LISP.)
The paper I was referring to had a dozen people write the same program in Lisp and C/C++. They then compared the programs. ALthough the fastest overall program was done in C++, the average/median C++ program took about 100 seconds. The average/median lisp program took about 50. If you compare the best of the two, LISP lost.. If you compare a random pair, LISP wins by 2x. Ah, glorious statistics, the art of lying with numbers.
Let's take this to email if you have any reply.
Instant passwords: tr -d -c 'a-zA-Z0-9./' /dev/urandom | dd bs=1 count=8
"The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place." (Douglas Adams)
Borland would have sued MS again, and MS would have been forced to buy even more of them (just like a couple of years ago, when Borland sued MS for taking Anders, and some patent infringments, and MS ended up paying $100M in "licencing" for Borland's MIDAS technology, and buying 10% of Borland. The case was settled out of court)
After all, Object Pascal (in Delphi), which Anders designed is a fair attempt at a successor to Pascal, even if it does keep the Pascal name, backwards compatibility, and the ability to code in a non-OO style if you choose.
How much of this was his design and how much was hier ups saying "Gee wouldn't it be nice if..."
In todays world you design Apps, operating systems and programming languages diffrently.
With Apps you have a known goal and a known result. The rest tends to be fuzzy but managable.
With operating systems there is a basic design goal. Easy to visialise but internals need to be left to the experts.
A new programming language is an enigma from day one. Only the designer has a clear idea what it will look like and even he is wrong.
Sun knows how to make operating systems and knows how to back off enough to let people get the work done.
But even that wasn't enough to prevent... Java....
Microsoft is far worse. I can only guess what they do but it shows in the results that managment has WAY to much say in app and os design.
So the question is... did Microsoft lay off or did marketting climb all over this like ants...
Microsoft is capable of doing this.. setting a team away from the normal managment style and let them go at it. They can do this for ANY project.
My question is... did they... can't assume they did.. can't assume they didn't....
But then if it turns out as planned we know Microsoft did something right...
I doupt we'll have a Java... Microsoft would rather kill the progect than have a "all new Java"...
My guess... Market droids poked in a lot and said "Don't make it like Java" and walked away.. thats all.. do ANYTHING just don't make annother Java...
I don't actually exist.
You completely misunderstood me!
The language is good based on its merits, and has nothing to do with C.
My point is that C is available for just about every machine out there, and it can be considered to be a universal machine language. In fact, there's many compilers out there that compile their language right down to C. Even Java could be turned into C with a compiler.
It's a nice way to quickly implement a highly optimized, portable, and standard compiler.
That's all.
If tits were wings it'd be flying around.
Wait a minute! Why do we feel excited about SOAP?
Anders describes this as an easy and more importan scalable way for beaming objects around in a network (possible object migration is the better term):
You take your object and tell it or some facility to write down its type and state into a piece of XML and -whoop- transport this (HTTP conforming mostly) from your socket over ther wire to some receiving socket, where the reverese process is happening, the XML gets read and reassembled into a copy of the object. A similiar thing holds for method calls of an object - the method plus parameters get XML-fied (this is described in the SOAP spec) and beamed over.
When I first read such a scenario I was excited too. What would be the alternative. On the lower end it would mean devising my own beaming protocol using sockets/udp packets. But on the higher end there is something like CORBA.
Wasn't CORBA supposed to act as object bus? And this on a higher level than fiddling with sockets myself?
Right now I think I have this latent positive feeling about SOAP because that uses simple technology (sockets + HTTP + XML) I understand, plus I understand how to scale such a system. while on the other hand there is this behemoth of CORBA specs and the mysterious world of orbs that I don't know yet.
I would love to know some comment from somebody who has done some real CORBA work and who would express his opinions on this matter!
One of the arguments in favour of SOAP was that this would mean that there is no state involved in the protocol. Uhm, what is the real advantage here? Isn't this situation not a bit different from serving just a page from whatever server to a client?
And why would CORBA look unfavourably in this setting?
The other thing I could not follow Anders' argumentation was about him distinguishing beetween Java interpretes and his IL run time mechanisms. Sorry sounded pretty much like JIT technology. If .NET sends no binary to the
target host, I would not declare that one
running natively.
Amen brother!
ANSI C, in the hands of a decent coder is very portable. IMHO much more portable than any JAVA code will ever be.
That portability is not achieved automatically, but can be strived for. The reward for that extra work is payed back in form of speed.
I mean not some silly applet, but large packes. Think gcc, Emacs, or UNIX.
Yes, C is a universal assembler and there is still hope that ISO C++ will some day too became widely available in full power.
OK, suppose that I'm writing a Modula-2 compiler, and since Java is nice and portable, I decide to make my M-2 compiler emit Java code, which will be run on a virtual machine.
Then suppose next year, I decide that I'm going to write Suckix, and new operating system for the Play Station 2, and I'm going to write it in Modula-2.
Bzzzt! I'm screwed, because my absolutely STUPID choice of an intermediate language prevents me from accessing the hardware.
Modula-2 is a systems programming language. It makes sense to use C as the intermediate, as it is also a systems programming language.
If tits were wings it'd be flying around.
Any function with (eval) or equivalent is an interpreted language. The general LISP program contains (eval), therefore the general compiled LISP program still needs to contain a full LISP interpreter! Remember, with (eval) you can do anything - rebind +, for instance ...
Splay trees are something I've never come across - I shall have to read up on them!
Variables aren't that difficult to create in LISP. We use the (let) form from Scheme. Having many intermediate variables (rather than complex expressions) definitely helps code readability. But it's more than that. Consider the following form:
(foo bar 2)
Depending on what bar is, and what foo is, this may be any of:
That's what I mean by LISP being hard to read. In C++ the syntax distinguishes all three cases without you having to know anything a priori about foo and bar.
Now, I know that ACL can optimize function calls nicely, and provides typing (which is a prerequisite for the former). And I know that CLOS member calls are slow. This is what makes C++ so much faster. In OO you want virtually everything to be an object (down to some granularity level). Thanks to fast member invocation and inlining, C++ lets you take that granularity very low indeed. In C++ you can encapsulate single longs and still see no speed loss, provided all the accessors are inlined. You can't do this in CLOS, because the cost of a member call is so heavy. This makes CLOS great for large-scale objects, but useless for small-scale ones. For general OO, therefore, I'd say CLOS is a little useless. It would be great for objects on the scale of COM objects - no doubt Microsoft will make VisualLISP for .NET ;) - but no good for many of the design patterns used in C++.
As for the LISP vs C++ comparison - it sounds about right for a procedural task. If you compared large object-oriented LISP applications vs their C++ counterparts I would be amazed if any of the LISP programs beat any of the C++ programs ... but it's certainly possible to write clunky C++ code!
Let's take this to email if you have any reply.
I'm loath to do that, since others may be reading this.
--
It's a
-- Danny Vermin
As for + and (eval) - of course (eval) is generally avoided (unless you need it), and of course you shouldn't rebind +, but you're missing the point. LISP's very design, from (eval) up through CLOS, is based on its interpreted nature. You just wouldn't design a language like that if your design brief said "it's intended for compilation".
a lot of natively compiled implementations have to include the compiler
There aren't a lot of natively compiled implementations! We found about six. ACL contains an interpreter. I don't know about other LISP implementations; maybe one of them does JIT compilation for (eval) ... somehow I doubt it. It's not much work writing a LISP interpreter on top of a pre-existing runtime.
--
It's a
-- Danny Vermin
Source-as-data-structure is certainly a principle in LISP ... and you're right, this is independent of compiling vs interpreting. But it's not just (eval) - the whole CLOS object model is much more reminiscent of Smalltalk (also originally interpreted) than C++ (always compiled). You should see the amount of code a generic CLOS function takes! It's that sort of design decision I mean ... C++ is designed for fast method lookup and execution (which makes is less powerful) while LISP is designed in a milieu where a method lookup through a table is not much slower than a function call (which is true in an interpreted language).
Another good example of this is Java Bytecode. CPU emulators are slow at best, since CPUs are not designed to be emulated (the MIPS does OK; the 68000 is a bitch). The Java virtual CPU is designed for emulation, therefore has features which would be expensive to implement in silicon but cheap to implement in software; it also avoids all the bit twiddling that silicon finds so easy and software finds so hard.
There's always this sort of trade-off in a language design, and LISP definitely (to me) takes the "this will be interpreted" path. And, of course, it did used to be (and still is in ACL until you compile it).
Even compiled LISP still has the equivalent of (eval 'symbol) which is a lookup from a symbol ... this is another example of its interpreted legacy. A compiled C++ program doesn't need to keep the symbol table around!
--
It's a
-- Danny Vermin