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.
Why is Microsoft trying to reinvent both C++ and Java?
Fawking Trolls!
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
Chief Architect of Delphi and His Team Designed WFC
Good details on C# as described in The Register
M$: "We're #2!"
Has anyone else noticed this post before? I feel like I've read it at least once and maybe two or three times, attached to stories that were equally unrelated to Linux networking. Does anyone know why this is?
Ben
Perhaps they'll rewrite Perl and call it !Perl :)
Seriously, though, M$ has been doing this their whole life. PC-DOS became MS-DOS. GWBASIC became BASICA.
M$'s marketing strategy: take something people are already familiar with and sliiiightly modify it.
"Beware he who would deny you access to information, for in his heart he deems himself your master."
Yes, yes, we've had this discussion before.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
This is the worst joke I've ever heard.
Although--since C++ handles increments slightly better in very specific situations before the variable than after, it should probably be called ++C. So I guess #C would be... parallel to that... but... senseless.
And there's already a fairly high-traffic #C on irc.debian.org.
"Beware he who would deny you access to information, for in his heart he deems himself your master."
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
Let's take Java, C++, Prolog, Scheme,Perl, Delphi, and the rest,and put them all into one language and call it Screw++. Then we won't have any fights on which language to use. You can use anyone you want in the same environment.
nWo 4 Life
"Unsafe code is deeply tied into the security system." - Anders Hejlsberg
'nuff said
-------------------------------------------
Fawking imposters! Go back under your bridge. Good siggy impression, though.
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
-------------------
I hate to troll MS like this -- it's kind of cliché on slashdot, but think about their other products.. very few actually 'innovative' ideas.
Windows95 -> System 7
Word -> WordPerfect
Excel -> Lotus 123
Access -> Borland database.. any database software
Explorer -> Netscape + Finder
Outlook -> Lotus Notes
Defrag -> Norton Speed Disk
Drivespace/DiskSpace -> Stacker (didn't they get in trouble over this?)
etc etc etc.
Sorry about the OT post. I'll withold my +1.
And wasn't GWBasic -> Gates, William BASIC ? I thought that's what GW stood for, but I'm likely wrong.
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
I remember when this initially came up on /. I asked this question: Does the world need another language?
Why on earth would we need yet another language to learn, be incompatible with (at least at the beginning), and have to study? Why would anyone think C# would be necessary?
My view is that it's not. The world has enough high-level languages. C# should not revolutionize anything, it should be a redundant addition. We already have anough C's. What do you think?
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.
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
-------------------
All this vaporware has really cleared up my sinuses!
:)
---
I wear pants.
This should read: "Although--since I have a shitty C++ compiler, I have to do micro-ops myself". There is nothing about the C++ language which would tend itself to performing the post-increment or pre-increment operators *any* differently unless the value of the operand were used. Micro-ops are always a bad idea unless you're coding in machine language.
Of course! We already have languages - coming up with anything new would be stupid and a waste of time! Where we really went wrong was building anything more abstract then assembler... wait, no, dammit, everything they're doing is just 1s and 0s - I pity the fool programmer who uses any development kit more complex than a text editor and two buttons!
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...).
Any chance somebody can get hold of the specs enough to build a Linux/*BSD implementation? A logical name for the open source version would be Db (D flat), the enharmonic equivalent to C#.
My office has been taken over by iPod people.
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.
Personally the idea of generated readable documentation is a good idea that would probably be implemented sourly. I don't believe AI can still make things as clear and understandable as another human being stating it to antoher. Hasn't this been done before tho? Visual C++'s documentation always irked me. I always hated some of the //'s I'd see in the programs I'd have (not by choice) to do for school. God I hated being REQUIRED to do programs in MFC. That hurt.
When you write code in C#, you write everything in one place. There is no need for header files
Wouldn't this lead to much less organization and bloated single source files that we didn't need? Or does it take the overhead off by not having to compile in header files? I'm not much into programing as I want to be, but I still have a general idea :-)
Oh well. It was a rather boring read I guess... I think I'll just continue using C/C++ to get the jobs done. I don't forsee wanting to learn this thing. Supposedly it's not tied into COM... Heh.
Who's the black private dick, who's a sex machine for all the chicks?
"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!
people used to joke that BeOS stood for Buzzword enabled Operating System.
they should have named this BePL, not C#
(the pound is what you'll do with your head learning Yet Another Not Quite C Syntax )
this interview was so full of buzzwords, it is hard to believe that hejlsberg is not a puppet sitting on the marketroid's (product manager's) knee or reading off a cue card.
of course he is biased, it is his baby, AFAIK it _MIGHT_BE_ a great PL, but buzzwords and fluff won't convince me.
the message I got out of this interview is that C# is sort of C+++ (third + intentional) and java, with all the dangers of C++ and new and different syntactic idiosyncrasies.
The difference between Theory and Practice is greater in Practice than in Theory.
This O'Reilly that we see in the interview - the one that is so focused on Open Standards - is not the true O'Reilly. Far beneath the surface, there is another O'Reilly & Associates, one that sells closed source software. You heard me right - O'Reilly and Associates makes and sells Closed Source Software for Windows, O'Reilly Website. It's time to expose the hypocritical, two-faced O'Reilly!
So what you are saying is that if someone does many things that are good and helpful and then does one thing that you don't approve of, then he is EVIL.
There must not be many acceptable people in your reality.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
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
For my birthday I got a humidifier and a de-humidifier... I put them in the same room and let them fight it out. -- Steven Wright
Uhh the point of his post is that C# doesn't offer anything *new*.
No no no.
I am not one of those guys, I am a new poster to Slashdot, trying to positively contribute to the well-being of everyone in the community.
So please don't put me down. I am only trying to express my honest opinions to people.
Because.... I Am Canadian.
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.
No, ya got yer "facts" wrong there. Delphi shares it's machine code generator with BCB. If you want to learn about product speed, check out this. Delphi is a visual RAD tool that is capable of generating binaries just as efficient as C++. I would argue that OP is more readable/maintainable than C++, but THAT's just my opinion.
meh.
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.
And it ain't even Siggy himself... it's SiQnal 11.
My bad - I wasn't paying close attention to the user name... didn't mean to feed the imposter troll. And I'm usually so good about these things... perhaps more beer would help. Heh - either way I think I'll have some.
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.
Some people claim it stands for Gee Whiz because it executes code so quickly. Just the other day I wrote a c001 '133t pR0gR4m Th4t l15t5 pr1m3 nUmBar5. 1 l00k3d 4T 1t th15 mr0n1nG & 1t h4d 4lr34dy r34cH3d t00 f1gur35! N444h, y0u'd n3v3r g3t th4t k1nD 0f sp33d 1n y0uR 3|33t C++ pr0Gr4mM1nG |4nGu4Ge! D00dz, 1'm 4n '133t h4x0R!!!
Ahem, that's enough of that for now.
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
This is not something I'm going to waste my time learning.
heh heh... one pseudo-word:
Kerberos#
Lame, very lame...
Oh yes. Very true. I forgot about those satanic overloaded operators. Hopefully they're inlined anyway, though :D.
But your opinions don't make any sense.
I mean, all you said was canada's cool, the states isn't? I wouldn't even mind that if you actually have some kind of reasoning behind it.
You haven't even said why you think C# is so bad and useless.
I'm not tryin to slam you, I'm just trying to figure out exactly why you believe what you believe.
-V
Is noone reading Slashdot interested in this language?
Sure, it may be Java rip-off, but at least they've submitted it to ECMA for standarization. They're right when they said, "That is something fundamentally different from our competitors who wandered around the standards bodies, looking for someone to rubber-stamp their proprietary lanugages."
I, for one, like the fact that somebody's trying to make a language the right way (whether it be Java or C#), but is also interested in making it standarized (which is certainly not Java right now).
http://www.talknerdy.org
They are submitting C# and CLI (the Common Language Infrastructure) to ECMA for standardization. Earlier I posted a link to the minutes from the most recent ECMA T39 group meeting.
with humpy love,
with humpy love,
humpmonkey
Please award Siqnal11 with a prestegious "Most Uninformed Post of The Year." He manages to write grossly incorrect statements in each and every post.
In the end, we'll find siqnal11's posts more drivil not even worth reading.
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."
Hopefully, Bonobo on top of CORBA will replicate this a bit since it's interfaces will be language neutral. I hope the IDL will somehow be wrapped in a template library or wizard because interface definition is what make component programming more complicated than it really has to be. Can't wait for GNOME 2!
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"
class InodeType {
private int _type;
InodeType(int type) {
this._type = type;
}
}
public interface InodeTypes {
public static final InodeType FILE =
new InodeType(0);
public static final InodeType DIR =
new InodeType(1);
public static final InodeType FIFO =
new InodeType(2);
public static final InodeType SOCK =
new InodeType(3);
}
That's pretty simple, huh? (You don't even need the int member -- it's just there for clarity.) Just because Java doesn't provide a syntax for enums doesn't mean it's impossible to implement typesafe constants easily, just like it's possible to write code which uses semaphores instead of monitors as long as you build a semaphore framework yourself (see Doug Lea's page for a lot of useful concurrent Java info).
Adding syntactic sugar to a language merely shackles developers to the way the language designers thought a problem should be solved, and saves a few keystrokes at the cost of lost consistency.
Typesafe value types are not a bad idea (*shudder* Pascal uses them to some advantage), but it is just plain dishonest to say that they provide anything more than sugar in an OO language.
Remember, folks, as Alan Perlis said: "Syntactic sugar causes cancer of the semicolon."
~wog
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!
eww... I apologize for that post, I forgot to change it to plain text... my bad :\
You can automatically log in by clicking This Link and Bookmarking the resulting page. This is totally insecure, but ver
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'?
In the context he was speaking in, "unsafe" == "Won't crash".
The cake is a pie
Was it just me, or did he refer to cross platform programming as using .NET and sticking code into an ASP page?
ASP? Portable? Barely....
MunITioN
MunITioN
"A mind is a terrible thing to lose"
Um, try this. It works even with Visual C++: enum A {A_FOO, A_BAR}; enum B {B_FOO, B_BAR}; void test() { A a(A_FOO); B b(B_FOO); A c(B_FOO); // produces an error
a = A_BAR; // ok
a = B_BAR; // produces an error
a = b; // produces an error
a = A(b); // ok
}
The fact that these guys don't know (or at least refuse to test) the simplest things about C++ is not reassuring. C++ has lots of problems, but it sounds like they are reinventing the wheel, not necessarily better, just different.
Anybody who thinks this thing is going to be remotely cross-platform is totally deluded. The run-time will require Windows, just like they tried to do with Java. They can talk all they want about the standard language but it is a lie.
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).
The work that we've done with attributes -- a feature used to add typed, extensible metadata to any object -- is completely new and innovative. I haven't seen it in any other programming language
OK, so he's either an idiot or a liar.
Tell me about mainstream language which has this feature. You know, attributes in C# are just C# objects. You may create your own and write your own tools which will use reflection to get attributes from class.
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
You can implement C++ classes inline in the header file, nothing forces you to write a header then an implementation, it's just convention. [BTW, I know, I've seen it done, and done it myself]
-={(Astynax)}=-
-={(Astynax)}=-
"Darkness beyond Twilight"
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.
C, C++, C#, Object Pascal, and Java are all working the same general territory.
Exactly.
--
You are a fucking moron.
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.
"innovate" count: 7
what's wrong with M$? normally they give us at least a dozen new innovations with a new product, espically something like this.
anyone know the "innovate" count in the average M$ article?
I wish they would give us something good like multi-colored blue screens of death, it could double as a screen saver =)
Josh
Boxing and unboxing are simple features and could speed up programming a bit. But that's hardly earth-shattering.
Their IL is nothing new as you could actually compile any language to Java byte-codes if someone took the time to write the compiler.
Compiling to native code isn't new either -- in fact, wasn't Microsoft the first with the JIT stuff for Java?
What I'm waiting for is something truly revolutionary. Something that would make it worth my while to change the syntax I know and the way I think. I've already seen an inkling of such ideas in Tim Sweeny's A Critical Look at Programming Languages.
I actually sent a few e-mails back and forth with Tim Sweeny before I truly understood what Parametric Polymorphism is and the power it could provide. I even went as far as to emulate some of the parametric polymorphism behavior in Java. I can see how it will simplify compilers, empower programmers, greatly improve code re-use and better organize software architecture.
That's the kind of Giant Leaps for man kind I'm looking for, not these one-man Small Steps.
IF you are doing something serious, the flexibility of being able to run on a mix of platforms is really important. I use Windows for my desktop, and linux on the server side. I'd give my eye teeth for C#.
The point is it will become a full out standard, and then the wonderful world of open source software will likely take it and run. Sun missed this with Java, it's good to see microsoft catch up on the vision..
August
Who's the fool?
:)
Have you ever even looked a piano keyboard in your life, smarty pants?
C-sharp is enharmonic to D-flat. B-flat is the same as A-sharp, and E-sharp is enharmonic to F.
Get your theory straight next time, Mr. Beethoven.
--Markus
BlackholeTV - TV that Swallows
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.
Hejlsberg states: "We've preserved enums in C# and made them type-safe as well. In C#, enums are not just integers. They're actually strongly typed value types that derive from System.Enum in the .NET base-class library."
Are enums part of C# or C# part of .NET?
Cool article, the first 1/2 made sense, then when started talking .NET IL, I glazed over. But overall it feels like this guy's big brain (and hist team) gave this much thought before churning out a new language. Here's my $0.02...
.NET is all about...
1. extensible metadata gives me wood... oh yeah!
2. categorizing code as safe/unsafe opens the door to the possibility of on-CPU encrypted execution: won't be able to hack w/o Tektronix TLA-711 logic analyzer, but definite plus for more secure computing.
3. the section on garbage collection sounds like s/w "hints" to the core libs that aren't specifically procedure calls. if that's true, and they're intrinsics, that would be way cool. (like lfetch.nta in ia64... assembler hints to the cpu) this ties into his statement about where the standard libs end and the langauge begins.
Now to go read what
And when can we get a compiler for C#?
---
https://www.accountkiller.com/removal-requested
I would have been pleased to see what he could have done if he had staid with Borland. I used to like Delphi/CppBuilder as a student, doing quick and not so dirty apps.
He could make writing apps for windows atractive again.
Now it's just another troll.
Wow. You found another way to be boring! Imagine that!
I have no
Right from the get go they call it "one-stop shopping" for the language in that all the code is in one file. That is one reason for me to stay away.
Modularity is clearly the way to make debugging easier unless of course they plan to sell a Microsoft debugger for C# as well. Then I can see the motivation to making a programming nightmare.
I have written programs "one-stop" as was mentioned when I was 14. This was until I learned how much easier it is to write things reusably. How can you possibly reuse code that isn't broken up into logical parts. It also seems to violate some component-like features for a language that is supposed to have deep object orientation.
No thanks Microsoft. I'd rather not try to write or maintain code that sounds like it will be more convaluded than MFC.
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
That's while() not while(). Damn HTML filter...
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
just thought you should know.
I just realized...
C# can be pronounced "cock-tothorpe".
-
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
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.
This clearly seems to be a case of M$ doing market research and then gluing existing lanuages together around the findings.....
I say, program in SML. Strongly typed, no functions, no variable statments. A perfect functional language.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
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.
And who's to say Microsoft is standards body shopping?
http://www.angelfire.com/ca3/marlowe Better a smartass than a dumbass.
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?
Not at all. What I was saying is that almost all Microsoft products are based on other products.
Simple. Don't put words in my mouth.
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.
What I think is one of the coolest things about java is the late binding. You can take a running program and introduce a new class, and the program can use the new class either by knowing about one of the new class's parents or via reflection. This is what allows things like Jini to work. I often write programs that use this for extensibility.. need to add a new functionality module to the program? Just extend my base class and then tell me the name of the class you created.. no restart required.
Anyway, I would hate to loose that. In what they themselves describe as a very disconnected world, I think that having the ability to load new code into a running program over the network is going to be increasingly important to do.
Oh, one more thing. One of the big things that I like about Java is that it is not a "Kitchen Sink" language. I do not want to use a language that keeps me so tied up in the intricacies of implementation that I loose the big picture of the architecture. A good architecture is the key to any good software and no other language lets you take your concepts and implement them cleanly as well as Java does. I am also pretty in to UML and the symmetry between UML and Java is a beautiful thing.
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.
That isn't a bad thing. Linux is just a ripoff of Unix, Apache is just a ripoff of the very first http server ever created, and the keyboard is just a ripoff of the typewriter. And they're all good products.
For more information, click here.
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
Hi,
:) but hey.
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.
I was wondering if someone could give me a quick rundown on enums, why they are important and why they are something to be excited about in C#.
I personally don't see the need for yet... another... programming... language...
--Markus
BlackholeTV - TV that Swallows
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
Dylan simply never had a firm commitment from an industry partner that was willing to market it, develop it, and see it through. Apple dropped it shortly after releasing the first version.
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
lynx -dump http://windows.oreilly.com/news/hejlsberg_0800.htm l | perl -e 'print -1 + scalar split /innovat/s,join "",<>;'
---
Despite rumors to the contrary, I am not a turnip.
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.
C# sounds a lot like Objective C on antisteroids (estrogen?). Of course Obj. C is supported by GCC, and has been aroung for years.
If Apple ever got their heads out of their asses and re-released Cocoa (Yellow Box) for Winders, and began helping with GNUStep. They could have a fully cross platform Language and API, which is all what D Flat seems to be, and more.
"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
Can you think of at least one programming language (C), markup language (HTML), or Communications Protocol(HTTP) that was in widespread use before a standard for it was completed?
This is a manual virus. Copy it to your sig and help me spread!
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.
It isn't clear to most people that C++ and Java are simply poor languages for frameworks, and parametric polymorphism, and binary portability.
While I sort of side with you on C++, I disagree strongly with Tim Sweeney's remark about parametric polymorphism and Java's inability to deal with it. I assume Mr. Sweeney has not taken the time to look at GJ, a.k.a., Generic Java which provides a good start towards parametric polymorphism. The type parameterization of classes/interfaces/methods provided by GJ has been a godsend for me - fewer messy manual casts to deal with.
Also, take a look at this paper on NextGen, which is an extension of GJ that will allow expressions like "new T()" and "instanceof T" where T is a type variable.
It is my personal belief that C# is one of the most poorly designed languages to come around in recent years, but I will expound on this in a different post because I have to catch the bus home in a few minutes.
> Mike
"There is no culture in computer science, only cults." - M. Felleisen
Word on the street is that when Anders was snarfed my MSFT he set about to create a virtual machine-based language akin to java. This was going to be the common back end to replace the decrepit pcode comile options formarly supported in several of microsofts 'compilers' including vc. Then Microsoft had a change of heart, refocused on the intel-only market and picked up the more rhobust Java language.
.Net branding strategy without a product, out comes the 5 year old software, resurected, given tech writers and Anders is a star again. (of course they've kept him happy with internal awards every year along with his massive paycheck).
Well, Sun has steadfastly refused to "open" Java and instantly make MSFT an equal in the direction of the language. This combined with BillG's amorphous all-things-to-all-people
The real questions are:
1) Why do we need another Java.
2) Will sun do the right thing and open Java and kill this C# thing here and now.
3) Will sun ease up on the distribution requirements so people can ship a thin runtime?
4) If Sun hands Java over to a standards body will Anders be quietly stuffed back into the closet where he's been hiding the last 5 years?
http://www.webstandards.org/wfw/ieah.html
"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
Click me
Look at the parent message to see why I posted this.
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.
I can't answer for Tim but I would guess that he did not know about GJ (or any other generic programming initiative for Java) when he wrote the article. I didn't know about it either. Until GJ or NextGen are part of the standard java library I don't think Java measures up - and I think Tim would still fault Java for being so utterly slow (I know I would - from my days programming with Swing, etc).
Anyways, I wish the best of luck to GJ and NextGen, and I'll be sure to to check them out for my next Java project.
In any case, I don't know for sure that C# is a good language - I havent used it. I have read over all the material that has been linked to from Slashdot, and this preliminary investigation seems to show that it has potential. (I love the fact that they are concentrating more on components and object interactions.)
Complexity Happens
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.
Win 95->CDE or System 7->Xerox PARC
Everything was graphical then, it had to be or it would die. microsoft windows was quite unique, just as Motif/CDE was.
also try WordPerfect->Wordstar.
or Linux->UNIX
maybe even Kdevelop->Visual C++
sorry, but slashdot folks seem to bash MS without really thinking what they are saying...
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.
Osborn: We've talked about Java, C++, and scripting. I have heard a number of people here at the PDC argue that there really is no difference between .NET IL (IL is the Microsoft
Intermediate Language that all compilers must produce to run in the .NET
framework) and the Java byte code that is consumed by the Java Virtual Machine
(JVM). It's clear from the talks you've given that you do not agree. Would you care to
comment further on the distinction?
Hejlsberg: Sure. First of all, the idea of ILs is a very old idea. You could trace the concept back to the UCSD Pascal p- machine (an early implementation of Pascal for personal computers) or to Smalltalk. p-code is used by Basic and Visual Basic. Parts of Word, internally, use a p-code engine because it's more compact. So, p-code is nothing new. 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. With managed C++, you can actually generate native code directly from source. Managed C++ can also generate IL, as can C# and VB. And when you install your code we give you the option to compile it at that point; to compile the IL to native at that point, so that when you run it there's no just-in-time compiler overhead. We also give you the option of running and compiling code dynamically, just-in-time compilation. And, of course, having an IL gives you many advantages, such as the ability to move to different CPU architectures and to introduce verifiability in type safety and then build the security system on top of that. I think one of the key differences between our IL design and Java byte code specifically, is that we made the decision up-front to not have interpreters. Our code will always run native. So, even when you produce IL, you are never running an interpreter.
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
I have a strange feeling that C# is going to be much the same way: The idea is great, the implementation will not be as expected.
The clash of honour calls, to stand when others fall.
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...
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
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.My understanding, after playing with the language for over a week, is that classes built with C# are not COM-classes. You must through a compiler switch to make this happen! Because of this, the language is truly microsoft neutral and portable. There is nothing "COM" like in the language whatsoever until you start tying COM attributes to the classes. I think if you die-hard MS bashers truly spent some time understanding the language, you might actually be a little impressed. Microsoft certainly has their faults, but they ARE getting better.
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.
At the end of the article the C# product manager slams Java and tries to smack write-once/run-anywhere by quoting an interview with Gosling as supposedly saying it is nothing but a bunch of marketing hype. There's a link to that interview, and if you read it, he really says that there are limitations on certain platforms (embedded devices, e.g.) but that overall his point is "Java is -- a glue layer that tries to make "write once, run everywhere" as close to true as it can be"
My mother can and does use COBOL, and I do think it can be useful to connect legacy systems to the web.
OK, from the standpoint of having done Java, C++, and COM, (and sorry to say, a bit of VB) here's what C# is trying to be:
.NET. Except that .NET is really COM. Well I dunno what's going on here.
It's C++ minus some of the messiest parts of the syntax. Think ATL.
It's VB plus some bits of Java and C++ to give the language more power. Except MSFT to push it to try to stem the tide of VB programmers rushing to Java.
It's a new COM language -- built on and married with COM. Except that COM is going away in favor of
It's Java plus pointers and some other C/C++ language "features" that certain ossified programmers can't seem to learn how to do without.
It's another MSFT product to get you to buy something to replace all that product that you've sweated bullets to make halfway-functional but isn't making MSFT any money anymore.
The benefits of learning it do not seem worth the effort. My understanding of it after reading the interview is that it is simpler than C++ but includes some C++ feautures left out in Java.(operator overloading is offered as an example) Also of course it has a lot of integration with MS specific stuff like VB and DLLs.
There are also some very minor tweaks such as controlling garbage collection, managing the namespace differently and more control over compilation. They may be nice(i'm not really sure) but are they worthy of a whole new language? I don't think so.
Basically to me this language seems to address more Microsofts needs than any genuine developer needs. They want to take a bite out of Java and this is how they will do it. They may well succeed ( you know they will push it real hard).
Finally, in this day and age why would I want tie myself so closely to a Microsoft solution? The control that Sun has over Java is deplorable but at least they didn't integrate it real closely with Solaris and tie it in with their other products. In short you can download the JDK and start working without any further interaction with Sun. This C# language on the other hand is being heavily marketed as microsoft centered.
Essentially it does not look like this C# stuff will be ported over to Linux or Solaris any time soon.
I don't hate Microsoft, (hell, I am using NT right now)but at the same time I don't want to be tied to them any more than necessary. This is not zealotry,its common sense.
Just my 0.02$
The only reason all cover-ups appear to fail is that you never hear about the ones that succeed.
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
Really, why not just hire a summer intern to put a bytecode back end on an old version of CFront?
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.
The language is pretty immaterial here, folks. It's primarily being developed to let your average Joe "VB" User move up to a slightly more powerful toolkit, without having to get in to the nitty-gritty of C++. Plus, if the full spec is really submitted to the EMCA, it can be copied and implemented by anyone, including the GNU Project, or any other open source development group or team. (Maybe the Blackdown guys need another challenge?)
.NET libraries themselves. If they're licensed as prohibitively as most MS software, then the language will be crippled outside the Windows sandbox; think of Java without any of the more complex packages, like AWT, JDBC, etc. However, if the libraries are even distributed like Java's (binary format only), then they can be used as a stopgap until open source replacements can be built.
Anyway, the card to watch for here is the core
VB is a better language than C++ on many levels. Much of its ridicule here, is short sighted.
;'s will switch. Probably many Delphi coders too.
MS's common runtime is going to bring the vb's debugging advantages to C++. Many VB developers who can stand
The huge disadvantage with vb and Java, is that your code gets locked in to the version of the runtime you're using, upgrades seem mandatory, and its a trap many c++ people may fall into.
fixed.
- Sam Ruby
A good list of programming languages for the JVM can be found at http://grunge.cs.tu-berlin.de/ ~tolk/vmlanguages.html.
- Sam Ruby
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
I found this quote to be funnier:
.Net to be one of the highest quality releases in Microsoft's history.
:)
Osborn: So, instead of a code completion date, we're looking at a "ready-to-go" date?
Goodhew: Yes, that's right. I think developers will find the release of Visual Studio
Hmmm....wonder if he'll remember saying that.
w/m
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
Plus who really wants multiple incompatible Java versions anyway? I know I don't.
The only reason all cover-ups appear to fail is that you never hear about the ones that succeed.
I'm not saying that hotspot isn't impressive, but it isn't anywhere near native code yet.
And becuase of this, I refuse to even acknowledge Sun sponsored benchmarks - they're rigged. So don't respond with Sunworld, Javalobby, or Sun.com benchmarks.
Accidental garbage collection is near impossible in a Win32-based system. In UNIX, rm -rf /* CAN actually happen by accident. In Win32, you can't get rid of the whole GARBAGE OS without meaning to do so. I mean, the damn thing asks you three or four times, if you're really, REALLY sure about it.
:)
I guess UNIX is just "unstable" that way.
Sorry - I've been drinking again.
-- What you do today will cost you a day of your life.
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
Great discussion here! I have posted TONS of information and links to sites about Microsoft's .NET / ASP+ / C# / Visual Studio.NET initiatives.
I will add this Slashdot article shortly. Here's the link:
http://www.devx.com/free/press/2000/vsnet/vsresour ces.asp
Note the reference to emulation. I want a universal sandbox for cross-platform development.
And, yes, I'm working on one... sort of. I'm trying to make a language that can be used for defining the function and interfaces of arbitrary computing devices. A universal sandbox is one application for it. It's kind of a life project, so don't expect to hear about it in the near future.
For a long time, I wanted to call it C**, because of the Alpha Centauri reference, and just to be perverse, but I slowly came to realize that it would be just a little too perverse. I think I might name it "Restraint".
---
Despite rumors to the contrary, I am not a turnip.
First off, I'd like to say that although my comments here seem to be more criticism than comments on C#, I'm an admirer of Hejlsberg's previous work (particularly the Delphi environment). Also note that I'm not married to Java although it might seem from my coments, but I just feel that Java is the closest thing to compare C# to in the real world.
.Net platform supports and their respective programming environments.
t ml and you will see how Mr. Goodhew is missinterpreting what Goslin gsasys.
My comments on Hejlsberg's views on C#are the following:
- C# is not the first (or only) component-based language out. Java gets those honors with the [much simpler to use I should add] JavaBeans component model. You can write a full usefull, and reusable JavaBeans component in 5 lines of code.
- Everything he mentions in the O-reilly interview has been done before with SmallTalk and Java.
- He never mentions that the reasons many C++ language constructs are not in Java is because of their complexity, run-time load, or bug-pronness.
- The "everything you need to run your component" philosophy of C# is nothing but a more complicated version of Java's jar and war files.
- The Boxing and Unboxing properties of C#, from what I understand, is already more elegantly (and simply) done in Java without additional syntax constructs via simple casts, objects constructors, etc. In other words, it's just adding extra unnecessary weight to C#. Same for the enums feature.
- All his comments about "we can't afford to keep rewriting software anymore, but need to start using components" sounds too cliche. This talk has been given before countless times in the now-very-mature Java object-oriented and component-oriented community.
- The "support of key internet standards like HTTP, HTML, etc" is nothing new to Java which has come with objects dealing with these standards since day one.
- The "innovative" XML-based built-in documentation support is nothing more than C#'s version of Java's built-in documentation system JavaDoc.
- C#'s garbage collection is just a copy of the same Java feature.
- The "unsafe code" C# directive is just JNI (Java Native Interface) gone too extreme. The Java vision is that you should be writing fully platform-independent code and use JNI only when you absolutelly have to, meaning usually for legacy access. The C# vision is that you should be able to write native (usually windows-dependent or in the future some other platform-dependent) code anytime, without regards for the global tendency to write platform-independent code to protect future IT investments, migrations, etc.
- Ok, maybe I got this wrong, but here's a question from Osborn to Hejlsberg and his actual reply: Osborn: "So you can't write unsafe code in VB?", Hejlsber's reply: "No, you cannot". Yeah right...
- On a side note he notes the incredible ability of the forthcoming ASP+ technology to compile pages before spitting their contents out to the web browser. Heck, this has been the case of JSP (Java Server Pages) since day one 3 years ago.
- It seems that Hejlber strong views of using the IL (Intermediate Language) to directly write native code, as opposed to the more flexible intermediate Java ByteCodes are obscuring his views of the why of the ByteCodes philosophy. Just look at the Crusoe processor, HP's Dynamo dynamic compilation technology, or SUN's HotSpot dynamic compilation technology to see why running intermediate code while obtimizing it at the same time could actually yield faster performace than native code. Side note example: HP's Dynamo is a layer of software which emulates the actual chip on top of which it is running (!), which intuition leads to believe that you get slower performance, however the caveat is that as it runs the code it also obtimizes it; the end result: the code runs 30% faster in emulation mode on the same processor than in "direct" mode on the same processor. This is the best proof yet that the dynamic compilation technology of intermediate code as that use by Java's HotSpot can yield faster performance than native code.
- Hejlber: "we give you the ability to write verbatim string literals where you don't have to write two back slashes every time you want to specify one". This I think is cool, although we have to see how they manage to do this across all the languages the
- My programming experience tells me that using C#'s way of naming and packaging source files (or even writing all your code in one huge file) will eventually be something that Hejlberg (and programmers who start using it to do "spaguetty naming") will be sorry about.
- Mr Goodhew's view of EJB (Enterprise JavaBeans) as a technology which doesn't allow Java apps to be fully portable is basic Microsoft marketing speech (disclaimer: I use some Microsoft products, think some of them have good things to offer, and I'm not an anti-Microsofter, even though I do tend to agree a bit on the monopolistic oppinions in the air against MS). From my experience with MS and non-MS customers who have used EJB, they are pretty happy with its portability, and the latest versions all but guaranteed portability across EJB containers). Also, he critisizes how SUN allows extensions to exist to EJB to meet the needs of users who need them, well, just off the bat C# with DevStudio already comes with COM extensions which make your code 100% non-portable to other platforms. BTW, if you want to see for yourself what Gosling says in his interview go to http://www-4.ib m.com/software/developer/features/gosling/index.h
- I can't belive Hejlsberg says that EJB doesn't scale (tell that to the customers using it for million-plus-transactions-per-day duties) due to its use of "statefull CORBA and RMI". Does he know that Java already supports and runs XML and SOAP code, (as a matter of fact, Java supports more XML varieties than any other platform), and all the non-statefull protocols you care to name off the bat (HTTP particularly which is the underlying SOAP protocol). Besides, since Java supports both statefull and non-statefull protocols, it provides a more flexible solution than C#. Also note that any experienced consultant will tell you that under many circunstances statefull protocols are way more efficient than non-statefull ones.
- Hejlsberg says that with C# him and Microsoft are a generation ahead of everyone else. Well, my view is that this is neither a step back or forward, but sideways. It's, wheather they want to admit it or not a "plan" to sidestep Java/JSP/EJB/etc and come up with a Windows-centric competitive product. It's more a reaction to the wide lead and momentum Java has today rather than an innovation.
You're right, if you don't buy the theory that there is no such thing as perfect pitch. If you have it you can tell the (very very) small difference between sharps and flats. I don't have so I can't tell the difference. Damn those that are more gifted in music then us regular people. ;)
if my wife asks a question, and I'm not paying attention, and then I answer wrong does it still count
"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)
> so you can't write unsafe code in vb? :)
this will probably be moderated down as (obvious -1), but people are already responding with posts about vbscript kiddies etc...
is a link to minutes from a recent ecma t39 meeting where they discuss the submission of c# and cli.
maybe.
future specialized languages will almost assuredly be themselves written in c.
- ---------------
that's an odd comment to make. the important thing is to look at it objectively. not something i think the slashdot community agrees with.
which is the same as point 1. people keep going back to the lingua franca.... sorry, it's clearly organized in my head, but i haven't gotten around to scribbling out the boxes and arrows yet... the language design team consisted of four people. -waldo "that pretty much sinks our whole case right there. can be we'll make gates pay for this." this comment sent microsoft
i'd agree, for the most part, but not entirely - perhaps i'm crazy. it's not something you think about every day, so it's kinda difficult to put into so many words. maybe i'm missing the point, but i think that's a bit spurious.
-----------------------------------------------
al ex chebowan (alexchebow@yahoo.com)
I'll re-iterate... Anders had the *idea* for the component library, but his *team* at Borland made it a reality. And you're absolutely right, the VCL (and more importantly the concept of the PME - Properties Methods and Events - model) is what influenced JavaBeans. In fact I went to a lecture with the developers of JBuilder and they said that the VCL is exactly where Sun got the idea for the JavaBeans design, based on Borland's input.
And I did use Delphi.. every day! For Windows it's the ultimate development environment, IMNHO. Then Java came out, and I moved to JBuilder.
And as far as the WFC goes.. how great was that, exactly? It's in the "Where is it now?" bin where BP was an inch away from ending up just 6 years ago..! That's not Anders' fault, more like MS being myopic, but still....
And I'll say it again.. I hope C# does well.. It'd be nice to have another language out there with the power and ease of use and acceptance of Java. What it really boils down to is, what makes you productive? If it's VB, great! More power to ya! For me, the language that I'm productive in is Java (tho augustz apparently thnks this is impossible).
;-)
Polymorphism -- It's what you make of it.
I agree that concentrating on components is a worthy cause. No language I know does that well, not even Java. However, I think Microsoft is going about it the wrong way, and I will qualify my disagreement with a few examples. Unlike Mr. Hejlsberg, I tend to side with ivory tower philosophies, and my opinions about programming languages reflect that. With memory and processors becoming ever faster, and with the advances made in virtual machine technology, slowness will become less of an issue. Until that time, I won't pretend that Java can handle kernel-level
functions efficiently. That's what C is for.
The override keyword
C# deviates from the standard Java/C++ inheritance mechanism for methods by providing an "override" keyword. By default, C# shadows method names whose names appear in a particular class' superclasses. E.g.,
class A {
public void printme() { Console.Writeline( "I am an A."); }
}
class B : A {
public void printme() { Console.Writeline( "I am a B."); }
}
class C {
public void printthem( A thing ) { thing.printme(); }
}
void main()
{
A a = new A();
B b = new B();
C c = new C();
c.printthem( a );
c.printthem( b );
}
Do you know what the output will be?
I am an A.
I am an A.
The method printme() in B shadows, but does not override printme() in A. You need to use the override keyword to do that, which is standard behavior in both Java and C++. In class B, you have two versions of printme() floating around, which can lead to confusion and incorrect code, especially with novice programmers. IIRC, C# was supposed to help reduce casual programming errors (forgetting deletes for news, etc.), but I don't see this particular feature as very helpful.
new for methods?!
Of course, the compiler will generate a warning with the above code stating that B.printme should have the prefix "new". It will still compile, but it wants your blessing to shadow the method. I can't think of a situation where I would want to use C#'s method inheritance scheme. The thing I like about Java's treatment of method overriding is its consistency. I know what my program is going to do. Imagine a programmer wants to extend a component Doohickey for which he has the API but not the source, and he shadows a method he didn't know existed in his implementation, called Thingamajig. Imagine his surprise when he passes a Thingamajig to a method processDooHickey( DooHickey ), and it behaves very strangely and not at all like he coded.
And God said, 'Let there be types.'
But my gripes with the method inheritance mechanism is nothing next to my disgust at the inclusion of "unsafe code." I believe very strongly that in order for an object-oriented language to be truly object-oriented, it has
to have a notion of safe types. C++ does not have a notion of safe types, it has the pretense of types. You can still jack around with the individual bits comprising an object in memory. C++ is not so much an object-oriented language as it is press-on objects tacked onto a portable assembler (C). C has no such pretense: types are merely directives to the compiler on how much memory to allocate for data. C# seems to be taking the C++ route with its "unsafe code."
With type safety, you can usually generate a type-soundness theorem, a guarantee that your program will produce results within a certain type
bound. This eliminates many of the crashes due to invalid data floating around in an ambiguous form. I am reminded of a question on an exam in my
programming languages class:
A certain software company in Redmond, WA, discovers this great language Haskell. It has many exciting features, like a type-soundness theorem, safety, blah, blah, blah. A bright young intern at said company sends a memo to his superiors agreeing that Haskell could be the wave of the future - it only needs two slight modifications, the addition of "peek" and "poke", direct memory access function calls.
1) What would the proposed changes do to the parser?
2) What would it do to the type-soundness theorem?
3) Is this an afternoon's project?
What do you think?
> Mike
"There is no culture in computer science, only cults." - M. Felleisen
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.
> 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
I agree that standards are good, but it is worth remembering that MS has with C# played ball to greater extent than Sun has with Java (read the article!)
But your assumption that a language is only good if it reducable to C is questionable at best. Read the article again, especially where AH talks about atributes. I don't see that being turned in to generated C easily.
My Karma: ran over your Dogma
StrawberryFrog
Module test
Sub Main
Dim s As String
System.Console.Write( VarPtr(s) )
End Sub
End Module
Results in:
Microsoft (R) Visual Basic Compiler Version 7.00.8905 [NGWS version 2000.14.1812.10]
Copyright (C) Microsoft Corp 2000. All rights reserved.
D:\tmp\test.vb(4) : error BC30451: The name 'VarPtr' is not declared.
System.Console.Write( VarPtr(s) )
~~~~~~
D:\tmp\test.vb(4) : error BC30451: The name 'VarPtr' is not declared.
- Sam Ruby
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.
The core Java language has changed very little. The last major new feature was inner classes when 1.1 came out years ago. New packages appear, but that seems like a requirement for a popular language. Do you not think that C# API's will proliferate? Do you not expect that some methods in C# API's will be deprecated (at least a fast as any other MS API)? The number of methods deprecated in Java packages seems rather small, considering the size. I find Java much more stable, as a language, than C++ compilers compared on different platforms. When will C++ template instantiation stabilize? When will we have a reliable consistent way to use strings in C++ across different platforms?
(Reality reasserts itself sooner or later.)
VB is a terrible language. No language I have worked with has come close to the frustration levels I reach when I work with VB.
;'s will switch.
;'s") is inane. If we want to talk about syntax, why the hell does VB require a "_" every time you want to extend a command over more than one line.
Many VB developers who can stand
Choosing a language because of trifling syntactical details ("I don't like
The huge disadvantage with vb and Java, is that your code gets locked in to the version of the runtime you're using, upgrades seem mandatory, and its a trap many c++ people may fall into.
IIRC, most old Java code will pass through current JVMs. You'll get a deprecated warning when you compile, but it will still run, if that's what you're concerned about. Languages evolve and designers may realize that they need to change their original design. Improving a language - gasp!
Maybe Sun keeping control of Java is not such a bad thing if the programming community wants to endow it with the features from C++ and the like.
> Mike
"There is no culture in computer science, only cults." - M. Felleisen
If you're interested in parametric polymorphism, check out GJ or this paper on NextGen. GJ is currently available for download, and NextGen is still in development.
> Mike
"There is no culture in computer science, only cults." - M. Felleisen
'P' and 'L' were left unscathed. There's no word on whether or not this will affect 'T's current sponsorship deal with Sesame Street.
Hmm. Good examples of strange C# design decisions Mike.
:)
I've tried to think of an example of when you would want to only shadow a method, but nothing useful comes to mind. However, I freely admit that I haven't done enough generic programming and "real" virtual polymorphic coding. However perhaps the idea is only that compiler would just throw compile errors without the keyword (so the override keyword just helps other programmers realize what is going on).
Your example:
Imagine a programmer wants to extend a component Doohickey for which he has the API but not the source, and he shadows a method he didn't know existed in his implementation, called Thingamajig. Imagine his surprise when he passes a Thingamajig to a method processDooHickey( DooHickey ), and it behaves very strangely and not at all like he coded.
Not a good example. In Java (and C#) the public methods would be documented (through JavaDoc or whatever C# is calling their autodoc feature) and the private methods wouldn't have that problem. In any case C# must give some sort of compile time warning...
However, unless there are really good compile warnings/errors, I agree the override keyword does not seem well thought out.
As for types, I'm 100% behind you - strongly typed languages are so much nicer to work with (although Java makes casting a nightmare - which BTW sounds like it will be a much easier task with C#).
"Unsafe code" also sounds like a nightmare, but I never have to use it. I think it will only be used in extreme circumstances (small memory footprint devices, etc) where the GC would not perform as well - and in these cases C# has an advantage over Java, by providing the flexibility needed without defining all sorts of work arounds (Jini, etc).
As for the Haskell example... LOL. Great question, I wish I could have taken your class.
However, it's hard to say without testing, but from what I've read there seems to be some sort of memory "sandbox" idea, preventing C# from blowing up when one adds "unsafe code". 'Course I don't really belive anything like that would work, but hey, I'll give them the benifit of the doubt until I try it.
Complexity Happens
Pliant is a language that seems to have several of the same goals as C#. IMHO, Pliant is the language of the future. It is DFSG Free (GPL).
You can write modules in Pliant that allow for different syntaxes to be used. When enough of these exist, you will be able to choose to most efficient or desired syntax for each particular task of a project. Each part of the project, written in different "languages" will work together seamlessly because they are all the same language: Pliant.
I am, unfortunately, not very knowledgeable so please go to the website and read about it yourselves.
Uh-huh. And for what "innovative" reason did they place the oh-so-elegant break; after each block in a case statement so as to break continued execution in the switch instead of each case simply executing on it's own?? If C# was so well thought out, the would they please explain what the hell this is doing here?
*** Sigs are a stupid waste of bandwidth.
In the same octave, C# and Db are the same key on the piano, the same fingering on a saxophone, and the same fretting on a guitar. C# and Db will be equally out-of-tune. :) Okay, caveat: since the same note can often be played in 3-4 places on a guitar, this really doesn't apply. But the thought is the same.
That "perfect pitch" crap you refer to is the ability to name notes when heard out of context. Damn, is that guy still selling those "perfect pitch" tapes in the back of music magazines? :)
---------///----------
All generalizations are false.
--
I like to watch.
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.
A few interesting things:
- Microsoft's new cross-language GUI/DHTML api seems to have almost identical features to WFC, and an almost identical design, based on what the public has been exposed to at the PDC. [They're probably just porting it over to C#.]
- C#'s delegate keyword is identical to their Java extential in J++ 6.0 to do GUI event handling.
WFC was pretty good, using it for 6 months. Swing was more flexible, I found, but slower. That's changed with JDK 1.3 thankfully..
-Stu
Help help, I'm being hassled by Delphi coders.
It's a bit like being nibbled to death by an Okapi...
> How much of this stuff have you actually used, man?
WFC (which was truly appalling), MacApp (Photoshop is/was written almost entirely in MacApp), Pascal, and Java, although none of them anymore, exclusively C++, C, and EE/MIPS now.
> I use delphi as an example only because it's the only one of the above that I've used.
So that's 4/6 to me and 1/6 to you, not that I'm keeping score.
> By your ridiculous argument, java itself is only a hack of C++,
Java the language is. It's C++ with training wheels. Java the bytecode interpreter is something else. A knock off of p-code, ergo, another Pascal knock off.
> and therefore Sun=microsoft.
What? I dunno how you came to that conclusion. Nor what relevance it has to anything. Mind you, they're both peddling their own proprietary languages...
> I know I'm being extreme here, but I'm merely presenting to you the logical end of your argument.
Reductio ad absurdum, try and come up with a real argument rather than chasing your own tail. Or maybe you just have in inferiority complex regarding your use of a noddy language...;)
> Try to think your posts through more fully next time.
Patronising wanker. Go back to your grammar flames.
Jesus, it's getting so you can't even crack a joke round here anymore.
errr. in your example you say that the output for Java and C++ would be the same. This is simply false.
My mistake.
Just because you can't think of a use for a feature, does that mean it's a bad feature?
No, but I think the way C++ and C# handle the situation I presented is a bad idea. I prefer dynamic dispatch because it makes for clean, easy-to-read code. But that may just be my opinion.
But until that time I guess we're just stuck with these poor excuses for assembly languages.
I like C. C is a perfectly good language, and I like to work at a lower level now and then. If functional specs get you off, more power to ya. But from the code I see just floating around the web or coming from software firms that charge their clients shitloads of money, I think a lot of people could stand a few lessons in good program design. There's more to programming than the write-compile-debug loop.
> Mike
"There is no culture in computer science, only cults." - M. Felleisen
And your point is...?
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
The Danish "someone" who came up with it in the first place was... Anders! "More luck than skill", my ass.
Christian R. Conrad
My ISP is the Saunalahti company, of Finland.
Christian R. Conrad
mail me at iki.fi ; same user ID as here
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
How come everyone has to turn everything into a holy war? If it weren't for the folks at Microsoft we would probably all be writing COBOL and discussing DASD and flat files. This type of debate shows professionalism.
Maybe because someone mouths that question or something similar every single time C# is brought up, regardless of the actual treatment in the piece itself. But, I agree, it's a little inappropriate to mod as Redundant. Personally, I would've moderated it as Offtopic, since it had nothing to do with the article, save for the fact that the article and the comment both mention C#.
>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!
...Systems like MCL are compiling *everything* by default. CLICC is just a batch compiler.
How one accesses symbol values has nothing to do with interpretation or compilation. Why dont you just read a bit literature about Lisp compilation (like "Lisp In Small Pieces) and I guess things will be more clear. Variable access through symbol tables happens only if you are accessing global variables. Local variables are accessed directly from the current lexical or dynamic environment.
Common Lisp is a dynamic programming language - that means, a lot of things can be changed at runtime - Lisp implementations also have means to compile some of these dynamisms away. This is a language design decision and has nothing to do with being compiled or interpreted.
There are a lot Common Lisp compilers (see http://www.lisp.org) - especially many of them are available for Linux. Here are some Lisps with compilers: GCL, CMU CL, LispWorks, ACL, CLICC, CLisp, SCL, Liquid Common Lisp, MCL,