Imagine if you took everything you knew about C, C++ and Java and fixed it. What would you have? You would have 'D'.
No, I really wouldn't.
The reason so few people mention D -- and, I promise you, plenty of us have looked into it -- is that it has no compelling advantage. Java wasn't much of a step up from C++, and indeed was a step in the wrong direction in many areas, which is why so many people still use C++. It does at least have some clear advantages for some applications/environments, though. Ditto for C#. Where is D's niche? What can it do so much better than these other tools to justify buying into a small language from a small company with a small community?
And, C# *IS* an ISO standard. Version 1 was ratified by the ECMA and was then "fast tracked" and accepted by ISO. Version 2 has (as of July) been accepted by the ECMA and is now on the fast track to ISO.
Which is interesting, because normally ISO won't allow updates to a standard without a certain length of time between them to ensure stability. I can't remember the exact spacing required for different categories, but I'd be surprised if the C# "standard" could really be supplied to and approved by ISO three times in such a short space of time. I'm deeply suspicious of ECMA, and of this whole "fast tracking" process.
Not in any country I know of. In some places, there are fair use exemptions to copyright law, but that's not the same thing at all.
which is sacrosanct.
Again, not in any country I know of. Many places now have laws that make circumvention of copy protection mechanisms a crime in its own right, regardless of whether you would otherwise be allowed to copy the material. This is why things like the DMCA and EUCD are such bad law: they created a loophole through which fair use exemptions could be eliminated.
You might wish it to be different -- and I'm sure you would not be alone -- but wishing does not make it so, and I'm afraid shouting all over Slashdot in bold capitals that it is just makes you sound ill-informed.
Trick 1: It's relatively easy to qualify for an OEM version.
Trick 2: A lot of people have access to Office cheaply, and just don't realise it. For example, my employer (that is, the reasonably large US corp that owns the small subsid I work for) has a bulk deal with Microsoft to use Office on all its machines. As part of that deal, I would qualify to install a full version of Office on my home PC as well, in exchange for some nominal fee. Similarly, a lot of people studying or working in the academic world can get an academic licence much more cheaply than the off-the-shelf price. The catch with these is usually that the licence is restricted, and ceases when you leave the employer/stop studying/whatever, but I guess that's not an issue for a lot of people.
IIRC, this was discussed around these parts a few weeks back, and the number of active external coders at the time was four. One of those four developers posted (sorry, can't find the link now) about how basically it's a Sun show, and almost impossible for anyone who's not in the Sun management team to have any influence over the direction of the project at all.
Professional typesetters are not idiots and have been studying and refining such things for a very long time. LaTeX defaults to the same margins you'll find in professionally typeset books and other publications - the same margins professional typesetters have come to use after years and years of experience and refinement.
I like LaTeX, but you know the default presentation in the standard document classes was only meant to be a quick demo, right? It was assumed that serious writers/publications would all create their own classes using sensible typesetting preferences. In reality, the demo proved to be "good enough" for a lot of people, hence the large number of obviously LaTeX'd articles in circulation among some scientific communities. The layout in the standard classes isn't bad in terms of typography, but it's nothing special, and some aspects are truly awful.
Of course, a lot of professionally typeset books have truly awful typography as well these days, either through using poor technique, or through trying to be a bit too clever.:-(
Well, obviously you should read the interface for any function you're using to see what data it wants and what it gives back. Nothing about inferred typing precludes that; in simple cases, it simply saves typing a few characters and cluttering your code with type names you don't really need.
Regarding the final questions in your post, I'll simply note that if you get the types wrong, a strongly typed language will point that out immediately anyway, so you're in no more danger with inferred typing than you would be any other time you made bad assumptions about an interface you were using.
If you're pasting, say, a dozen lines of code at different places all around your program, what happens when you realize one of those lines was wrong? You have to go find every place where you pasted it and make a small change. Better to move the code into a method, where you only need to change it once.
No argument there, but how does this affect the question of whether inferred type information is useful or not?
Another poster has kindly pointed me in the direction of the limited version of Passport. That sounds more like what I'm looking for, and isn't something I've encountered before; I long since ruled out using any site with the words Microsoft and Passport on it, on privacy grounds. I'll look into the limited version.
If I don't get anywhere with that, I'll drop you an e-mail when time allows and let you know why. In any case, you might like to suggest to your colleague that a one-liner on your feedback site indicating that you can get a Passport without giving up personal information wouldn't go amiss. As I said, I'm happy to contribute, but in light of past bad experiences, I surely would never have looked for that possibility if it hadn't been pointed out to me here.
One of us is misunderstanding here, but I'm afraid it's not me.
There is nothing about inferred typing that requires things to be of some base "object" type. Indeed, in many languages that use it, there is no base type, nor even necessarily the concept of inheritance.
In the case of the code we were discussing:
foreach (var item in collection) { Console.WriteLine(item); }
it would be normal to deduce the type of item from the type of collection and the behaviour of the foreach... in... construct. That type would then be checked against the requirements for WriteLine, and an error generated at compile time if the types were incompatible. Whether C# specifically will be doing this, I don't know, not having read the specs for the new features in detail. There's no reason the use of type inferencing techniques generally can't, though.
You seem to be looking at this from the point of view of C# and its current generics features only, and in that restricted context, perhaps there is indeed some silly performance hit. I'm looking at the pros and cons of inferred types generally, and in that more general context, there is no need for the clutter of generic syntax, and many languages work quite happily without it.
BTW, even if your platform does implement this naively by using a universal base type, a performance hit of 500% for doing so is appalling, and suggests you have far deeper problems on that platform than how generics are handled!
I think there's a lot of truth in what you wrote there. That said, while specialist languages have their place, I'm increasingly wondering why no-one has yet produced the next great general purpose language.
Why can't we have a simple, elegant syntax like much of Haskell or Python, with punctuation frenzies reserved for things like regular expressions and printf formats where history shows they work well? Why can't we have a grammar that's amenable to parsing by automated tools, to make it easy for IDEs to provide refactoring aids, consistent formatting, etc? Why can't I have an imperative language that still supports higher-order functions and the like? Why can't I have proper disjunctive types and pattern matching in a language that supports OO with RTTI/reflection capabilities anyway?
I don't do professional compiler design, but I'm fairly familiar with the theory, and none of this seems to be prohibitively difficult. Indeed, most of it has been done in some form or other, somewhere. I just don't see why none of the places that invests so much in programming languages has managed to produce something like this yet. If they did, I don't see any reason we couldn't have a language suitable for a wide variety of applications, offering a clean, powerful syntax, yet still generating code that performs at a comparable speed to that from a low level language.
The technology seems to exist, it's just the language that (bizarrely) doesn't yet. We seem to be stuck in a rut where the only languages that are willing to risk major departures from common syntactic conventions and tool sets are new scripting languages and academic research, and so far each of them has had some significant drawbacks when it comes to industrial-strength, large-scale projects.
Why bother with C# 3.0, when there's a.NET language that can be considered advanced enough to be C# 4.0; it's called Nemerle.
Because Microsoft's weight is heavily behind C#, but not Nemerle. Ask any Visual J++ developer how much you can count on Microsoft's long-term support for proprietary languages that aren't their current pet. Caveat programmor.:-)
As a Java programmer, it is exciting to see these developments in C#, it makes me wonder whether Java is destined to fall behind C# - it sure looks like that is happening....
Perhaps. But then again, Java evolved very fast in its first few years, and a lot of what it evolved was crap, particularly the numerous poorly-considered additions to the library that now have to be supported pretty much forever. Policies on language features were made on evangelical grounds -- "We don't need templates!" springs to mind -- and a decade or so later, people are eating their words (as more conservative/deep-thinking programming communities have been telling them they would all along).
There is a lot of merit to stability in programming languages that are used by real people for real jobs. Some languages go too slowly, IMHO: I think C++ is drifting off into specialist worlds with a single really active supporter at the expense of useful mainstream stuff with no champion, but that's more a result of the way the standards committees are set up than anything else. Likewise, Perl 6 is becoming almost a completely different language, which is no longer recognisable as an evolution of Perl 5. But at least there's time for people to keep up, and in the meantime, everyone's able to use a solid baseline in C++03/Perl5 for real work.
These developments in a mainstream language like C# have potential to bring useful programming techniques into the mainstream, for the first time in some cases. Still, when most of the C# world is still exploring version 2, I can't help feeling that they'll either lose support or develop a community full of keen but under-informed developers producing naff code because they didn't have time to learn everything at once. Sometimes exciting isn't the best thing.
If you're changing the type of the collection, a few foreach loops are the least of your concerns - what about all the code that actually manipulates the items' methods and properties?
It will fail to compile if it really doesn't make sense. See my other post for comments on the danger of logic errors that remain here.
And if you're using a snippet like that so much that you're tempted to paste it over and over to work with collections of different types, you should really change it to a generic method:
Why? As far as I can see, your code provides no advantage over his, and in general your approach will be more cumbersome. The difference is just that in one case, types must be specified explicitly by default but can be treated collectively via templates/generics, while in the other case, code is generic by default, but types can be specified explicitly where it's useful for sanity checking purposes.
Do you actually have any solid information to support your claims here, or are you just expressing your personal opinion as fact?
Almost all of the posters objecting to type inferencing here quote examples like your
var y = SomeFunction()
as an illustration of how code is less readable without a type. Guess what? Code isn't very readable if you call your functions SomeFunction anyway, and writing
int y = SomeFunction()
or
SystemLibrary.MathModule.FloatingPoint.LongDouble y = SomeFunction()
really doesn't help.
On the other hand, if your functions and variables have meaningful names, you probably don't care whether the value returned is a float or a double most of the time. Type inference makes your code more generic, without losing any particularly useful information (if it is useful, you can still specify it), and the type safety of the system prevents the sort of
double -> float -> loss of precision
errors typical in languages like C.
In other words, I see a lot of scare-mongering in this thread, but very little evidence that it's justified, other then people saying, "It's unfamiliar and I don't like it". Do you have anything more for us?
You state, repeatedly, that large programs "without typing" or "without type checking" cannot be maintained. I think you're missing the point.
Most of the languages we're talking about here are strongly typed, and their code is naturally highly generic. Type inferencing doesn't leave a gap for run-time errors in this context, because you can't have type mismatches in the first place. This framework also avoids implicit conversions yielding accidental type coercion, a significant class of programmer error in some other languages.
The drawback to type inferencing is that it does leave scope for logic errors, where you wind up calling a function that doesn't do quite what you think it does with the type of data you've supplied, yet compiles quite happily because the syntax makes sense for all the types involved. As another poster noted, even with type inferencing, it can be useful to declare the interface to some key functions explicitly as a sanity check.
BTW, several large-scale applications have been written and maintained in such languages; many of them have web sites that list examples.
Sure. But if a few hundred people are bitching about a relatively high-end bit of kit failing in the same way within days or weeks of purchase, that's not routine bad luck. Even if it were, there would still be no excuse for the fobbing off many of them report receiving from Apple and its associated supporting companies.
Actually, that wasn't the problem I was referring to, though it seems to be almost as bad!
When I looked at buying one of these beasties a year or two back, there was some major problem that caused part of the screen to go really dim. IIRC, it was something to do with a failed board and the backlight. This was everywhere over the web when I looked before. See this page for an example that's still there. (I love the comment at the top about Apple deleting the posts.)
As the office geek when it comes to new VS versions and customising the set-up, I'm happy to offer such feedback as I can. In fact, I had a very interesting e-mail discussion mail with Dan Moseley a while back, after we "met" here on Slashdot. We talked about various UI possibilities in some detail, particularly about visualising data in the debugger. I'm very pleased to see that VS 2005 supports several improvements along the lines I (and presumably other people) suggested, and the UI bugs I mentioned from older versions seem to be fixed in the 2005 beta.
It's a real shame you guys insist on messing up your feedback centre with Passport, though. I'm very picky about giving out personal information on-line, and Passport's reputation is... less than favourable... so there's no way you'll ever get me to use that site.:-( Give it a simple, privacy-friendly log-in like everyone else on the web, and I'll be happy to contribute.
My seconday display (only have one) is probably at about a 20-30 degre angle towards me. If I try to look at the monitor without moving my head I really have to strain, so naturally I just turn my head a little.
Which, if you use the monitor a lot, can be just as bad: neck pains start creeping in after a while, IME.
What we've found at my office, where several of the guys have a second monitor, is that as long as you use one monitor for your main stuff and keep the others for things like toolbars and background tasks, it's fine (but people need to turn their head rather than glance, as you say).
If you're going to be using multiple monitors with "equal weighting" in which one you want to be using, I think you really need an arc-shaped work area and a high quality rotating chair. You also need some means of getting the input devices to be in the right place for each monitor, either by having a separate keyboard and mouse in front of each main screen, or by having a way of rotating them with the chair so they're always in a natural, centred position for your hand and arm position. People do make supremo workstations for this sort of stuff; there was a great link to one such company posted on Slashdot in a previous discussion a few weeks ago, but now I can't find it, so if anyone remembers the one I mean, please post it!
Slashdot Mirror
No, I really wouldn't.
The reason so few people mention D -- and, I promise you, plenty of us have looked into it -- is that it has no compelling advantage. Java wasn't much of a step up from C++, and indeed was a step in the wrong direction in many areas, which is why so many people still use C++. It does at least have some clear advantages for some applications/environments, though. Ditto for C#. Where is D's niche? What can it do so much better than these other tools to justify buying into a small language from a small company with a small community?
/me glances at current sig, smiles, and walks on.
Which is interesting, because normally ISO won't allow updates to a standard without a certain length of time between them to ensure stability. I can't remember the exact spacing required for different categories, but I'd be surprised if the C# "standard" could really be supplied to and approved by ISO three times in such a short space of time. I'm deeply suspicious of ECMA, and of this whole "fast tracking" process.
Again, not in any country I know of. Many places now have laws that make circumvention of copy protection mechanisms a crime in its own right, regardless of whether you would otherwise be allowed to copy the material. This is why things like the DMCA and EUCD are such bad law: they created a loophole through which fair use exemptions could be eliminated.
You might wish it to be different -- and I'm sure you would not be alone -- but wishing does not make it so, and I'm afraid shouting all over Slashdot in bold capitals that it is just makes you sound ill-informed.
Trick 1: It's relatively easy to qualify for an OEM version.
Trick 2: A lot of people have access to Office cheaply, and just don't realise it. For example, my employer (that is, the reasonably large US corp that owns the small subsid I work for) has a bulk deal with Microsoft to use Office on all its machines. As part of that deal, I would qualify to install a full version of Office on my home PC as well, in exchange for some nominal fee. Similarly, a lot of people studying or working in the academic world can get an academic licence much more cheaply than the off-the-shelf price. The catch with these is usually that the licence is restricted, and ceases when you leave the employer/stop studying/whatever, but I guess that's not an issue for a lot of people.
Switch off Clippy effectively? :o)
Install the Yahoo! toolbar?
IIRC, this was discussed around these parts a few weeks back, and the number of active external coders at the time was four. One of those four developers posted (sorry, can't find the link now) about how basically it's a Sun show, and almost impossible for anyone who's not in the Sun management team to have any influence over the direction of the project at all.
I like LaTeX, but you know the default presentation in the standard document classes was only meant to be a quick demo, right? It was assumed that serious writers/publications would all create their own classes using sensible typesetting preferences. In reality, the demo proved to be "good enough" for a lot of people, hence the large number of obviously LaTeX'd articles in circulation among some scientific communities. The layout in the standard classes isn't bad in terms of typography, but it's nothing special, and some aspects are truly awful.
Of course, a lot of professionally typeset books have truly awful typography as well these days, either through using poor technique, or through trying to be a bit too clever. :-(
Can you name a language that resolves overloading based on return type?
Well, obviously you should read the interface for any function you're using to see what data it wants and what it gives back. Nothing about inferred typing precludes that; in simple cases, it simply saves typing a few characters and cluttering your code with type names you don't really need.
Regarding the final questions in your post, I'll simply note that if you get the types wrong, a strongly typed language will point that out immediately anyway, so you're in no more danger with inferred typing than you would be any other time you made bad assumptions about an interface you were using.
No argument there, but how does this affect the question of whether inferred type information is useful or not?
Thanks for the reply.
Another poster has kindly pointed me in the direction of the limited version of Passport. That sounds more like what I'm looking for, and isn't something I've encountered before; I long since ruled out using any site with the words Microsoft and Passport on it, on privacy grounds. I'll look into the limited version.
If I don't get anywhere with that, I'll drop you an e-mail when time allows and let you know why. In any case, you might like to suggest to your colleague that a one-liner on your feedback site indicating that you can get a Passport without giving up personal information wouldn't go amiss. As I said, I'm happy to contribute, but in light of past bad experiences, I surely would never have looked for that possibility if it hadn't been pointed out to me here.
One of us is misunderstanding here, but I'm afraid it's not me.
There is nothing about inferred typing that requires things to be of some base "object" type. Indeed, in many languages that use it, there is no base type, nor even necessarily the concept of inheritance.
In the case of the code we were discussing:
it would be normal to deduce the type of item from the type of collection and the behaviour of the foreachYou seem to be looking at this from the point of view of C# and its current generics features only, and in that restricted context, perhaps there is indeed some silly performance hit. I'm looking at the pros and cons of inferred types generally, and in that more general context, there is no need for the clutter of generic syntax, and many languages work quite happily without it.
BTW, even if your platform does implement this naively by using a universal base type, a performance hit of 500% for doing so is appalling, and suggests you have far deeper problems on that platform than how generics are handled!
I think there's a lot of truth in what you wrote there. That said, while specialist languages have their place, I'm increasingly wondering why no-one has yet produced the next great general purpose language.
Why can't we have a simple, elegant syntax like much of Haskell or Python, with punctuation frenzies reserved for things like regular expressions and printf formats where history shows they work well? Why can't we have a grammar that's amenable to parsing by automated tools, to make it easy for IDEs to provide refactoring aids, consistent formatting, etc? Why can't I have an imperative language that still supports higher-order functions and the like? Why can't I have proper disjunctive types and pattern matching in a language that supports OO with RTTI/reflection capabilities anyway?
I don't do professional compiler design, but I'm fairly familiar with the theory, and none of this seems to be prohibitively difficult. Indeed, most of it has been done in some form or other, somewhere. I just don't see why none of the places that invests so much in programming languages has managed to produce something like this yet. If they did, I don't see any reason we couldn't have a language suitable for a wide variety of applications, offering a clean, powerful syntax, yet still generating code that performs at a comparable speed to that from a low level language.
The technology seems to exist, it's just the language that (bizarrely) doesn't yet. We seem to be stuck in a rut where the only languages that are willing to risk major departures from common syntactic conventions and tool sets are new scripting languages and academic research, and so far each of them has had some significant drawbacks when it comes to industrial-strength, large-scale projects.
Because Microsoft's weight is heavily behind C#, but not Nemerle. Ask any Visual J++ developer how much you can count on Microsoft's long-term support for proprietary languages that aren't their current pet. Caveat programmor. :-)
Perhaps. But then again, Java evolved very fast in its first few years, and a lot of what it evolved was crap, particularly the numerous poorly-considered additions to the library that now have to be supported pretty much forever. Policies on language features were made on evangelical grounds -- "We don't need templates!" springs to mind -- and a decade or so later, people are eating their words (as more conservative/deep-thinking programming communities have been telling them they would all along).
There is a lot of merit to stability in programming languages that are used by real people for real jobs. Some languages go too slowly, IMHO: I think C++ is drifting off into specialist worlds with a single really active supporter at the expense of useful mainstream stuff with no champion, but that's more a result of the way the standards committees are set up than anything else. Likewise, Perl 6 is becoming almost a completely different language, which is no longer recognisable as an evolution of Perl 5. But at least there's time for people to keep up, and in the meantime, everyone's able to use a solid baseline in C++03/Perl5 for real work.
These developments in a mainstream language like C# have potential to bring useful programming techniques into the mainstream, for the first time in some cases. Still, when most of the C# world is still exploring version 2, I can't help feeling that they'll either lose support or develop a community full of keen but under-informed developers producing naff code because they didn't have time to learn everything at once. Sometimes exciting isn't the best thing.
It will fail to compile if it really doesn't make sense. See my other post for comments on the danger of logic errors that remain here.
Why? As far as I can see, your code provides no advantage over his, and in general your approach will be more cumbersome. The difference is just that in one case, types must be specified explicitly by default but can be treated collectively via templates/generics, while in the other case, code is generic by default, but types can be specified explicitly where it's useful for sanity checking purposes.
Do you actually have any solid information to support your claims here, or are you just expressing your personal opinion as fact?
Almost all of the posters objecting to type inferencing here quote examples like your
as an illustration of how code is less readable without a type. Guess what? Code isn't very readable if you call your functions SomeFunction anyway, and writing or really doesn't help.On the other hand, if your functions and variables have meaningful names, you probably don't care whether the value returned is a float or a double most of the time. Type inference makes your code more generic, without losing any particularly useful information (if it is useful, you can still specify it), and the type safety of the system prevents the sort of
errors typical in languages like C.In other words, I see a lot of scare-mongering in this thread, but very little evidence that it's justified, other then people saying, "It's unfamiliar and I don't like it". Do you have anything more for us?
You state, repeatedly, that large programs "without typing" or "without type checking" cannot be maintained. I think you're missing the point.
Most of the languages we're talking about here are strongly typed, and their code is naturally highly generic. Type inferencing doesn't leave a gap for run-time errors in this context, because you can't have type mismatches in the first place. This framework also avoids implicit conversions yielding accidental type coercion, a significant class of programmer error in some other languages.
The drawback to type inferencing is that it does leave scope for logic errors, where you wind up calling a function that doesn't do quite what you think it does with the type of data you've supplied, yet compiles quite happily because the syntax makes sense for all the types involved. As another poster noted, even with type inferencing, it can be useful to declare the interface to some key functions explicitly as a sanity check.
BTW, several large-scale applications have been written and maintained in such languages; many of them have web sites that list examples.
It would be nice if trying to load that screencast didn't take out Firefox. :-(
I'd rather have unbreakable Office, but I guess you have to start somewhere.
Sure. But if a few hundred people are bitching about a relatively high-end bit of kit failing in the same way within days or weeks of purchase, that's not routine bad luck. Even if it were, there would still be no excuse for the fobbing off many of them report receiving from Apple and its associated supporting companies.
Actually, that wasn't the problem I was referring to, though it seems to be almost as bad!
When I looked at buying one of these beasties a year or two back, there was some major problem that caused part of the screen to go really dim. IIRC, it was something to do with a failed board and the backlight. This was everywhere over the web when I looked before. See this page for an example that's still there. (I love the comment at the top about Apple deleting the posts.)
As the office geek when it comes to new VS versions and customising the set-up, I'm happy to offer such feedback as I can. In fact, I had a very interesting e-mail discussion mail with Dan Moseley a while back, after we "met" here on Slashdot. We talked about various UI possibilities in some detail, particularly about visualising data in the debugger. I'm very pleased to see that VS 2005 supports several improvements along the lines I (and presumably other people) suggested, and the UI bugs I mentioned from older versions seem to be fixed in the 2005 beta.
It's a real shame you guys insist on messing up your feedback centre with Passport, though. I'm very picky about giving out personal information on-line, and Passport's reputation is... less than favourable... so there's no way you'll ever get me to use that site. :-( Give it a simple, privacy-friendly log-in like everyone else on the web, and I'll be happy to contribute.
Which, if you use the monitor a lot, can be just as bad: neck pains start creeping in after a while, IME.
What we've found at my office, where several of the guys have a second monitor, is that as long as you use one monitor for your main stuff and keep the others for things like toolbars and background tasks, it's fine (but people need to turn their head rather than glance, as you say).
If you're going to be using multiple monitors with "equal weighting" in which one you want to be using, I think you really need an arc-shaped work area and a high quality rotating chair. You also need some means of getting the input devices to be in the right place for each monitor, either by having a separate keyboard and mouse in front of each main screen, or by having a way of rotating them with the chair so they're always in a natural, centred position for your hand and arm position. People do make supremo workstations for this sort of stuff; there was a great link to one such company posted on Slashdot in a previous discussion a few weeks ago, but now I can't find it, so if anyone remembers the one I mean, please post it!