In any case, I agree - what you are saying about the possibility of having multi-inheritance built in at the IL level might make sense. Although I can't quite imagine the idea of C# and VB.NET, not being able to use it, but still having access to the interfaces of those objects. Is that possible? It seems to me that this would still basically deny C# and VB.Net access to any objects that carry interfaces inherited from multiple objects, unless it does some funny tricks underneath.
If you want to define "cross-language" as "languages that fit into this one paradigm", then yes, it's cross-language. You can make any statement true by redefining its terms.
Actually, I would define "cross-language" as supporting seamless integration of code from 2 or more languages. Obviously it is not meant to intend that it is "cross-all-languages". If.NET supports C# and VB.Net, then guess what, it has "cross-language" or "multi-language" support. I don't know why you are stuck on this idea that a multi-language technology must also cross all paradigm boundaries. If someone ever invents something capable of doing that (moreso than.NET already is, that is) I'll be impressed. It's just not possible to have complete seamless integration across all paradigms, and.NET makes no claim to do that.
Why implement in the dotnet framework in the first place?
For the sake of this discussion...
(1) to have an abstraction layer over the platform-specific assembly-instruction layer
(2) to have a shared set of services accessible to all applications written on the platform, in whatever language (and paradigm)
This seems fairly straightforward to me. I really don't see what something like multiple inheritance has to do with "The.NET Framework" or with "The CLR". Multiple inheritance is a high-level language concept, and it is up to the language implementor to include or exclude that feature. I cannot imagine why you would want to convolute anything at the assembly layer with such object-oriented concepts. Managed C++ does not require any additional support from the CLR or the framework in order to support multiple inheritance - it uses the same CLR and.NET Framework that C# uses. But it still has multiple inheritance, because it keeps it where it belongs - in the object-oriented language implementation. The exact same applies to Eiffel in this case. In fact, I would be suprised to learn that IL even has the concept of *single* inheritance.
FYI, Lahey and Fujitsu have released a.NET version of Fortran. Also I thought Digital was releasing their Fortran on.NET, but not sure...
(this is different from F#)
Prime-time quality? I'll believe it when I see it.
I'm not exactly clear what you're arguing against. That.NET's multi-language ability is now prime-time quality? That's exactly how I would put it - as I said, I've seen large-scale.NET enterprise projects developed successfully with modules spreading multiple languages seamlessly. I'm not sure what else we need to see before we can give this the "prime-time" badge.
Sun never intended the JVM for anything but Java.
That's all well and good, but at least since the advent of COM, MS *did* intend for it's platform to support multiple languages. I'm not claiming this is an "original" MS idea, but it is certainly the idea MS has had all along, at least since COM.
Thus the original poster's "subset of C#" description is not far off.
But it is in fact very far off. As another poster here noted, managed C++ (another ".NET language") supports a superset of functionality supported by C#, including the two OO features in question, multi-inheritance and templates. Additionally, as I claimed earlier, in many ways the functionality available in C# is a subset of of that in VB.Net.
Just because you can find one example of something from a language outside of C# which is not easily implementable on top of the CLR, it does not logically follow that C# is the superset of all possible CLR functionality. I can show you many examples of functionality in.NET languages, which are not available in C# - namely the two mentioned above in managed C++.
What I am saying is that one unique feature of Scheme, namely first-class continuations, cannot be done on the CLR without a huge performance hit.
I certainly won't debate that - I've tried to be very clear, and so have other posters here, that I think.NET is first and foremost directed at object-oriented languages. It is essentially an object-oriented framework. Let's not confuse "cross-language" with "cross-paradigm". It does claim to be the first, but not the second.
As a follow up, I am only vaguely familiar with my studies of functional languages, and perhaps I need to brush up - if you could provide a bit of info on first class continuations, I'd appreciate it...
More generally, I'm saying that the CLR provides little, if any, additional language independence compared to the JVM.
I'm certainly not disagreeing with you there. I'm responding more to the original point that (1) The CLR is really only built for C#, and therefore all other.NET languages are "subsets" of that functionality; and (2) That the CLR (or IL) prevents a.NET language from supporting certain OO concepts such as multi-inheritance or templates;
Forgive my ignorance on this "The JVM supports more languages than just Java" idea - any links you could refer me to would be enlightening.
If the discussion is about CLR vs. JVM, I think there are many more similarities than there are differences. Both are runtimes designed to support certain environments and scenarios, and while one or the other may be "better" in certain niche areas, generally the decision for CLR vs. JVM is not going to be a simply academic decision about which one supports more languages - it is going to be a decision about support for a specific language/platform/technology/toolset or whatever other factors are considered in choosing an overall set of technologies for a project. No one says "I want to do a project on the CLR, thus I choose.NET/C#!", just like no one says "I want to do a project on a JVM, thus I chose Java!".
I certainly don't want to give the impression that I believe interoperability between all OO languages on the.NET platform is seamless. There are certainly some issues. But in the overall scope of things, these issues are truly negligible. I have worked on fairly large enterprise-level.NET projects with a mixture of C# and VB.Net, and the minor cross-language issues have never been a hinderance to the success of these projects.
Here's why: from what I've seen (talking primarily C#/VB.Net/J# now), 100% of these issues are due to usage "non-standard" conventions allowed by a particular language - conventions which are technically not meant to be supported across all OO languages in.NET. IMO, VB.Net is the worst of these because it has carried over way too many stupid conventions from VB6 and before. For example, VB.Net allows you to do things like optional parameters, and it still allows you to call "built-in" functions such as Len(str) instead of calling the proper OO.NET Framework-supported str.Length which is available in all.NET langauges.
So if you're still with me, the point is that the incompatibilities and challenges faced are entirely due to stupid programmers using conventions they learned back in their VB days, and failing to "upgrade their skillset" to understand the "right" way to do these things in.NET.
It's not just VB, by the way - C# also has a few of these little things. So did MS make a mistake to allow these things to creep in to the languages? Possibly, but it was a huge tradeoff and a huge debate - if you remember back in the day a couple of years ago when the first VB.Net specs were released, there were HUGE debates over this. Some of us wish there were less incompatibilities, while some of us wish there was more backwards compatibility. The tradeoffs have been made, for better or for worse.
But these are certainly not fundamental issues with.NET, or the CLR - they are simply higher-level language choices, which could be changed at any time. And when a team uses a proper set of standards and conventions, I am confident that they can achieve 100% seamless interoperability between their.NET modules regardless of what language different parts of the team are working in. As many of us have seen from experience, the model works, and it works very well.
First, I'll ask you to please refer to my reply to ChannelX above, so that I don't have to copy and paste the same things again.
My main points are:
.NET favors OO languages, not just C#. There is as much, if not more, functionality and framework support available in VB.Net than there is in C#. Similarly, J# and C++ also have there own advantages. So if you are really talking about OO languages vs. everything else, then yes, perhaps I agree with you to some extent -.NET favors OO languages, because in many ways it is an Object-Oriented framework. But let's be clear about terminology.
That's why they get names like Scheme#, etc
Ah, now I see what you are getting at. In my opinion the reason a language like Scheme (or any other inherently non-OO language) gets a # at the end is primarily to distinguish it for the.NET-accessibility enhancements that have been added here. What I am really talking about is the additional functionality which has been added to the language in question in order to allow it to access objects. This is not a.NET concept, as much as it is simply a paradigm-bridging concept.
In any case, I don't see why this would be a negative thing (having the # added to the name). If we all agree that a framework such as.NET should be targeted at a specific paradigm, and that OO is probably the most relevant paradigm for today's age, then it is logical that any non-OO languages should have an indication to distinguish them from their counterparts. Otherwise, it could be very interesting for me to send you a helloworld.scheme file, and for you to see me referencing some framework objects using extended language syntax features.
You think this sounds like a bad idea? Then either don't use an object-oriented framework like.NET, or don't use a functional language like Scheme. You can't have your cake and eat it too. If you want to cross paradigms, I can't think of any way of doing that without some type of technical paradigm-bridging enhancements. If you're not happy with this particular implementation of the paradigm-bridging technology, that's fine - let's discuss it. But let's be clear about what we are discussing.
In the case of other languages, there are more obvious reasons that they have received modification marks to distinguish them from the original languages:
VB.Net - obviously important to distinguish from the non-object-oriented VB.
J# - Java is already object oriented, so obviously the biggest reason for a different name here is legal, because as far as I'm aware, MS can't throw a product out there and say, "this is Java, running on.NET!" However, from what I've seen, J# code looks identical to regular Java code. In fact, if you had the proper packages to replace the.NET framework (System.*, etc.), I would guess that 99% of J# code would compile with no problems and run on a JVM.
In any case, I still have no idea what any of these paradigm and framework issues have to do with the CLR. It's like arguing that Intel architecture really supports only C, and not any other languages.
I wouldn't really classify it as a problem of.NET. Obviously, if you have "objects" which are built to be accessible by an object-oriented language, you are going to have challenges in integrating those concepts with a language that operates on a different paradigm, such as functional (Scheme) or procedural (Fortran), etc. However, these are problems which are inherent in the gaps between different language paradigms, and are not a product of.NET or any other cross-language framework. In any case, the more relevant point is that these challenges clearly have little to do with the CLR, which is an abstraction of the assembly layer, not the OO-layer or whatever other paradigm-specific layer you have. Since assembly is built on top of the machine layer, presumably there is no paradigm which is "better" or "worse" suited to that layer. Of course some languages can give you more or less access to such low-level instructions, but that clearly is nothing new in the programming world.
The ".NET spin" is not saying that all languages now become interoperable at the OO-level - clearly not, because not all languages on.NET are OO languages..NET is about providing a common assembly instruction layer for cross-language development, not just an OO layer (although there is that too, for languages which will utilize it). If the point is that.NET prefers OO languages, I would certainly agree, but let's be clear on terminology then - let's not say "just C#" or whatever - VB.Net, C#, J#, C++, etc. all have approximately the same level of support and functionality in.NET, with certain language-specific advantages for each. Those advantages are primarily a product of the language developers, not the.NET framework, and certainly not the CLR!
How can this comment be (+5 Interesting) while each of the subsequent comments are 1's and 2's? When I first read this, I almost jumped to write a diatribe, and found that the other replies had already covered most of the important points very nicely. This comment should be marked (-1 : Ill-Informed) or some such rating, as it is highly misleading to anyone on/. who might be trying to learn about.NET.
As the others have mentioned here, the CLR is an abstraction of the assembly instruction layer, not the "object-oriented" layer. Thus, a statement such as "CLR does not support {select archaic c++ OO concept}" does not make any sense. This obviously applies for things like multiple inheritance, templates, etc.
Furthermore, the idea that the CLR "does not support multiple languages" is the most ridiculously malinformed statement I have ever heard about.NET, and trust me, I've heard plenty. One of the major objectives, if not the most important, is to bring to prime-time quality Microsoft's idea of supporting many languages on the same framework. They started this idea a long time ago with COM, and as it evolved, they realized all of the flaws in the COM architecture, and.NET is the next generation of multi-language support, in that sense..NET currently supports what, like 20+ languages? Not all of them developed by MS, btw... Many of these languages use different paradigms (scripting-oriented, functional-oriented, procedural, etc.), and they all have access to the full breadth of the.NET framework. If that's not "multi-language support", I don't know what is.
To assume that languages supported by.NET are "subsets of C#" is either naive or very malinformed. Anyone who knows the history of this knows that VB has always been Microsoft's baby, and C# is just the new kid on the block. Yes, now that C# has realized its potential, perhaps it is overtaking VB in popularity. But to claim that VB provides a "subset" of C#'s functionality is precisely backwards - in fact it is literally backwards - if anything, C# provides for the most part a subset of VB functionality, although technically the two provide somewhat intersecting but not fully overlapping sets of functionality - there are some things you can do in VB that you can't do in C#, and there are some you can do in C# that you can't do in VB. And the same goes for all languages on the.NET platform.
Features like templates and multiple inheritance are first and foremost a feature of a language at the OO-level of abstraction - not the assembly level. As one poster noted here, Eiffel is a good example of a.NET language which already supports these concepts. If you wan't to complain that C# doesn't support them, that's ok. But to complain that "CLR doesn't support them" really doesn't make sense. Get your argument straight first.
Of all of the amazing people I've met and had the fortune to work with in my career, if I make a subset of those I would really like to work with again, probably at least half would be Ph.D.s, several from the US. I have no problem with people with Ph.D.s, and I certainly don't think they are difficult to work with.
What I am talking about is simply the statistical probability of finding the right candidate on review of a RESUME with Ph.D. on it - that is where the bias is, and the bias is not just mine - just look around on this thread and you'll see numerous others with similar opinions or similar experience.
You may very well have a point - results are skewed because of higher levels of unavailability of actual desirable PhDs in the marketplace - in fact, given that I did most of my interviewing during 1997-2001, in that job market I would say that is almost certainly the case. Nevertheless, those were the results, and guess what - many other people who are reviewing resumes now have this similar experience during those years to look back on. Again, I am talking simply about the experience of reviewing resumes and conducting interviews, leading up to the hire. I am NOT talking about the post-hire working experience.
On the US born students thing - I'm not saying they are by definition inferior - but perhaps they are by circumstance statistically inferior. Honestly, I'm not an expert in the study of foreign versus domestic educational systems, but it's simply my theory to explain the skewed results I've seen favoring those PhDs originating from outside the US.
Numbers - we're certainly talking thousands or 10s of thousands of resumes, probably consisting of a few hundred PhDs, and less than a hundred actual interviews with PhDs. Personally, I only recall actually being involved in ultimately hiring 2 PhDs - most of the others I've worked with were either there before I got there, or came in through another interviewer/recruiter.
Well I'm not sure which camp you are putting me in - I assume the "non-Ph.D." camp, since the line is apparently so clearly drawn for you.
In any case, I certainly see what you are saying - many of those in the position to hire may very well be seeking those they can "dominate". However, as a potential job applicant, those are places I would try to filter out and avoid anyways - why would anyone be attracted to an environment like that? If this seems to be the norm to you, that sounds like either a very paranoid view, or a sad reflection on the state of things today.
But if you've read my posts here and this is all you are getting from it, I'm clearly not getting my point across. I'm not talking about managers with inferiority complexes or other issues like that - I'm simply talking about normal hiring managers with normal experience interviewing people from a variety of backgrounds. Under those circumstances, I am arguing that statistically, the probability is skewed such that there is a lower probability of finding a "good fit" in a pool of Ph.D. candidate, versus a pool of non-Ph.D. candidates, for "normal" or "non-super-specialized" positions.
I could theorize that this is an aggregated result of a number of factors, and I will still claim that this attitude you are clearly illustrating is one of the major factors. I would say that it is certainly NOT all about "control" - at least not in the real world outside of your mind. I'm sure that on the motivations that make you say this, you and I are not as different as it might seem - but I would imagine that it would be near impossible to ever be happy in any position in any real company, while continuing to think this way.
Every employee of every company reports to someone, except for the owner, and they report to stockholders or customers or whomever. And at every level from the lowest code-monkey up to the CEO, there is incompetence, and in many cases that incompetence rises to the top. I'll be the first to admit that I am capable of demonstrating a level of incompetence from time to time, but I'll also reinforce my claim - that level of incompetence certainly increases at levels above me in my organization. This is the nature of any working environment in real life - unless you are the most incompetent person in the organization, there is a high probability that someone at a level higher than you is going to be more incompetent than you.
And this is an excellent example to illustrate the difference between the "typical" Ph.D. candidate versus the "typical" non-Ph.D. candidate - in my experience, the non-Ph.D. candidate would statistically be better equipped to "deal" with this situation in a more professional, productive manner - the Ph.D. candidate would statistically be more likely to demonstrate problems dealing with this very common "real-world" scenario, such as the attitude you are displaying.
By the way you've phrased your comment, I'm not sure which side of the camp you're on - I can't tell if you're being facetious, or if you actually consider this viewpoint the more appropriate one.
We are talking about the real world, with real people, who have real experience, solving real problems. Unfortunately, these are things that a Ph.D. candidate is statistically less likely to be adept at. That combined with the type of statement you've made are exactly typical of a Ph.D. candidate with plenty of ego but lack of real world experience. Perhaps more importantly, a flagrant display of potential lack of respect for colleagues is a sure-fire losing strategy for an interview.
I think you've summed up very well one of the major concerns I have going into many Ph.D. interviews - this is an attitude which doesn't work in a professional environment. It often doesn't matter whether the individual is actually better or worse than the person above them - an appropriate level of respect is often more important than raw competency.
but i think you're missing my point - i am simply talking about statistical, empirical evidence based on my own experience. the fact is, to put it bluntly, the average Ph.D. in an interview for a non-academic position, for one reason or another, simply doesn't make the cut as often as the average non-Ph.D. candidate. In fact, I would say they don't even come close, and it usually has a lot to do with skills in fitting with the "real world".
On the other hand, the rare but exceptional Ph.D. candidate often far exceeds those with lesser degrees. But when you are hiring, sometimes the position just requires "good enough".
As I've tried to make clear - I am all for people doing post-grad work (as I did), and in general I have more respect for those who do. I am simply talking about whether it is a statistical impediment to getting a job.
The fact is that many people who read resumes always use "rule of thumb" hueristics to scan through them quickly, and unfortunately, interview experience often puts Ph.D.s in the "filter-out" category.
Good question - in fact, that's what I did during my graduate studies. Given the strange elements in my own background, obviously I try to give as much consideration as possible to every candidate, and people who work during their studies always get special consideration from me because I feel I can relate better to them. In fact, this would be something I personally look for. So unless I simply don't feel like going through a huge stack of resumes, of course I'm not going to just blindly filter out all the Ph.D.s.
But what I'm trying to give you here is a sense of my gut reaction - from a statistical risk perspective. Unless you make it blatantly clear on your resume (i.e. "1998 Ph.D. CS + WORKED FULL TIME!!!"), in my opinion you run the risk of getting filtered before someone notices or thinks to give you special consideration. Resume readers are probably the worlds most efficient speed readers, and depending on the reader's mood at that particular instant in time, there are plenty of keywords that statistically can get you immediately filtered out. Unfortunately, in my opinion, even with as much respect (and envy) as I have for many who have finished their Ph.D.s, that is a very high-risk thing to have on the resume.
If I actually make it far enough to consider your unique circumstances, you might very well be kept in the "yes" stack - but sometimes the trick is to get that far. Honestly, unless the position is very specialized and requests only Ph.D.s, if I'm reading your resume, having Ph.D. almost certainly will do nothing except automatically lower that initial "gut-reaction" score. It's high-risk, and almost always low-reward.
In the past I've been heavily involved in my firm's recruiting and interviewing, and during this time I've spoken to a fair number of people from varying levels of education. So here's my $0.02 based on my experiences:
By the time I finally felt I was comfortable as an interviewer, I had developed an automatic negative reaction to seeing Ph.D. on a resume - even now, I will often strike a Ph.D. resume without fully reading it. But of course, it depends on the role I'm hiring for - some roles really do require the expertise that only a seasoned expert can provide. But for most general roles, I found that the benefit is not worth the potential trouble, so most Ph.D.'s never made it to an interview with me. The reason is that my early experiences with Ph.D.'s were almost always decidedly negative - primarily from a personality/fit perspective. I'm sure most of these guys knew their stuff - but they simply weren't prepared for the "real world".
Before I make myself sound far too anti-Ph.D., let me say that this should in no way reflect my personal opinion of people with Ph.D.s - in fact, some of my best friends have Ph.D.s - people I highly respect, both academically and in the workplace. So the message I am trying to relay here is more about the "gut-reaction" of an interviewer/resume reviewer, than of the actual value of a doctorate-level education.
Let me also say something somewhat more controversial. Some time after I developed my initial impressions about Ph.D.s, I developed a new opinion - it is not simply all Ph.D.s, but perhaps Ph.D.s with a U.S. education background. I have more recently had excellent experience interviewing a number of candidates who completed their early schooling in Europe, and then came to America to do their Ph.D. Statistically, my experience has shown me that these individuals seem to be better rounded, and also more adept in their advanced study, in comparison to U.S. Ph.D. graduates. I'm not yet sure what this says about the U.S. education system, but take it for what it's worth - At this point, upon seeing a Ph.D. in a resume, I will consider a number of other factors before throwing it in the trash - most notably, previous educational experience. My interpretation is that Europeans on the whole are more driven to do post-graduate work as a normal part of their education, while in the U.S. post-graduate work is more exceptional and generally considered "unnecessary" - thus statistically, you don't get the well-rounded candidates at that level as often in the U.S., because you only see "academics".
For demographical purposes, I'm from the U.S, and I have a Masters - but I've always wished I had finished my Ph.D. - go figure...
"unlike others mentioned here, there is a nice replacement for Access: mysql (or postgresql for that matter). OpenOffice can pull data from ODBC data sources. Mysql and other databases support open source."
I think the point some people are trying to make here is not about simply using MS Access for accessing a database - obviously anyone building a real database app who knows what they are doing would never try to use access simply as a back-end database, because there are many much better options for that, both MS (SQLSvr, MSDE) and non-MS, ranging from free to cheap to expensive.
The point people are talking about here is being able to migrate *applications* that their users have built with access. That's the trick with Access - as a scalable or high-performance db, it isn't that great. But it's key advantage is that it allows you to very easily build data-entry applications to maintain relatively simple databases, without any programming or programming language, or even being aware that you are building an app that is connecting to a database.
we are talking about almost-mom-level simplicity in building custom data-entry apps here - and there is no other solution that provides that, that i am aware of. certainly mysql isn't targeted at that audience, and why would they want to be?
unfortunately, many, many businesses have vast amounts of data maintained in collections of ad-hoc "databases" built simply using Access. this is very similar to the Excel "application" dilemma - in order for open-office to really be successful with many businesses, it is going to need not only a seamless strategy for document migration, but also the full office suite replacement - and that includes both excel "applications" and access "applications".
Slashdot Mirror
But VB+C#=="multiple languages".
In any case, I agree - what you are saying about the possibility of having multi-inheritance built in at the IL level might make sense. Although I can't quite imagine the idea of C# and VB.NET, not being able to use it, but still having access to the interfaces of those objects. Is that possible? It seems to me that this would still basically deny C# and VB.Net access to any objects that carry interfaces inherited from multiple objects, unless it does some funny tricks underneath.
If you want to define "cross-language" as "languages that fit into this one paradigm", then yes, it's cross-language. You can make any statement true by redefining its terms.
.NET supports C# and VB.Net, then guess what, it has "cross-language" or "multi-language" support. I don't know why you are stuck on this idea that a multi-language technology must also cross all paradigm boundaries. If someone ever invents something capable of doing that (moreso than .NET already is, that is) I'll be impressed. It's just not possible to have complete seamless integration across all paradigms, and .NET makes no claim to do that.
Actually, I would define "cross-language" as supporting seamless integration of code from 2 or more languages. Obviously it is not meant to intend that it is "cross-all-languages". If
Why implement in the dotnet framework in the first place?
.NET Framework" or with "The CLR". Multiple inheritance is a high-level language concept, and it is up to the language implementor to include or exclude that feature. I cannot imagine why you would want to convolute anything at the assembly layer with such object-oriented concepts. Managed C++ does not require any additional support from the CLR or the framework in order to support multiple inheritance - it uses the same CLR and .NET Framework that C# uses. But it still has multiple inheritance, because it keeps it where it belongs - in the object-oriented language implementation. The exact same applies to Eiffel in this case. In fact, I would be suprised to learn that IL even has the concept of *single* inheritance.
For the sake of this discussion...
(1) to have an abstraction layer over the platform-specific assembly-instruction layer
(2) to have a shared set of services accessible to all applications written on the platform, in whatever language (and paradigm)
This seems fairly straightforward to me. I really don't see what something like multiple inheritance has to do with "The
FYI, Lahey and Fujitsu have released a .NET version of Fortran. Also I thought Digital was releasing their Fortran on .NET, but not sure...
(this is different from F#)
Prime-time quality? I'll believe it when I see it.
.NET's multi-language ability is now prime-time quality? That's exactly how I would put it - as I said, I've seen large-scale .NET enterprise projects developed successfully with modules spreading multiple languages seamlessly. I'm not sure what else we need to see before we can give this the "prime-time" badge.
.NET languages, which are not available in C# - namely the two mentioned above in managed C++.
.NET is first and foremost directed at object-oriented languages. It is essentially an object-oriented framework. Let's not confuse "cross-language" with "cross-paradigm". It does claim to be the first, but not the second.
I'm not exactly clear what you're arguing against. That
Sun never intended the JVM for anything but Java.
That's all well and good, but at least since the advent of COM, MS *did* intend for it's platform to support multiple languages. I'm not claiming this is an "original" MS idea, but it is certainly the idea MS has had all along, at least since COM.
Thus the original poster's "subset of C#" description is not far off.
But it is in fact very far off. As another poster here noted, managed C++ (another ".NET language") supports a superset of functionality supported by C#, including the two OO features in question, multi-inheritance and templates. Additionally, as I claimed earlier, in many ways the functionality available in C# is a subset of of that in VB.Net.
Just because you can find one example of something from a language outside of C# which is not easily implementable on top of the CLR, it does not logically follow that C# is the superset of all possible CLR functionality. I can show you many examples of functionality in
What I am saying is that one unique feature of Scheme, namely first-class continuations, cannot be done on the CLR without a huge performance hit.
I certainly won't debate that - I've tried to be very clear, and so have other posters here, that I think
As a follow up, I am only vaguely familiar with my studies of functional languages, and perhaps I need to brush up - if you could provide a bit of info on first class continuations, I'd appreciate it...
More generally, I'm saying that the CLR provides little, if any, additional language independence compared to the JVM.
.NET languages are "subsets" of that functionality; and (2) That the CLR (or IL) prevents a .NET language from supporting certain OO concepts such as multi-inheritance or templates;
.NET/C#!", just like no one says "I want to do a project on a JVM, thus I chose Java!".
I'm certainly not disagreeing with you there. I'm responding more to the original point that (1) The CLR is really only built for C#, and therefore all other
Forgive my ignorance on this "The JVM supports more languages than just Java" idea - any links you could refer me to would be enlightening.
If the discussion is about CLR vs. JVM, I think there are many more similarities than there are differences. Both are runtimes designed to support certain environments and scenarios, and while one or the other may be "better" in certain niche areas, generally the decision for CLR vs. JVM is not going to be a simply academic decision about which one supports more languages - it is going to be a decision about support for a specific language/platform/technology/toolset or whatever other factors are considered in choosing an overall set of technologies for a project. No one says "I want to do a project on the CLR, thus I choose
I couldn't agree more with what you are saying, Keeper.
Sorry, didn't finish my thoughts...
.NET platform is seamless. There are certainly some issues. But in the overall scope of things, these issues are truly negligible. I have worked on fairly large enterprise-level .NET projects with a mixture of C# and VB.Net, and the minor cross-language issues have never been a hinderance to the success of these projects.
.NET. IMO, VB.Net is the worst of these because it has carried over way too many stupid conventions from VB6 and before. For example, VB.Net allows you to do things like optional parameters, and it still allows you to call "built-in" functions such as Len(str) instead of calling the proper OO .NET Framework-supported str.Length which is available in all .NET langauges.
.NET.
.NET, or the CLR - they are simply higher-level language choices, which could be changed at any time. And when a team uses a proper set of standards and conventions, I am confident that they can achieve 100% seamless interoperability between their .NET modules regardless of what language different parts of the team are working in. As many of us have seen from experience, the model works, and it works very well.
I certainly don't want to give the impression that I believe interoperability between all OO languages on the
Here's why: from what I've seen (talking primarily C#/VB.Net/J# now), 100% of these issues are due to usage "non-standard" conventions allowed by a particular language - conventions which are technically not meant to be supported across all OO languages in
So if you're still with me, the point is that the incompatibilities and challenges faced are entirely due to stupid programmers using conventions they learned back in their VB days, and failing to "upgrade their skillset" to understand the "right" way to do these things in
It's not just VB, by the way - C# also has a few of these little things. So did MS make a mistake to allow these things to creep in to the languages? Possibly, but it was a huge tradeoff and a huge debate - if you remember back in the day a couple of years ago when the first VB.Net specs were released, there were HUGE debates over this. Some of us wish there were less incompatibilities, while some of us wish there was more backwards compatibility. The tradeoffs have been made, for better or for worse.
But these are certainly not fundamental issues with
First, I'll ask you to please refer to my reply to ChannelX above, so that I don't have to copy and paste the same things again.
.NET favors OO languages, not just C#. There is as much, if not more, functionality and framework support available in VB.Net than there is in C#. Similarly, J# and C++ also have there own advantages. So if you are really talking about OO languages vs. everything else, then yes, perhaps I agree with you to some extent - .NET favors OO languages, because in many ways it is an Object-Oriented framework. But let's be clear about terminology.
.NET-accessibility enhancements that have been added here. What I am really talking about is the additional functionality which has been added to the language in question in order to allow it to access objects. This is not a .NET concept, as much as it is simply a paradigm-bridging concept.
.NET should be targeted at a specific paradigm, and that OO is probably the most relevant paradigm for today's age, then it is logical that any non-OO languages should have an indication to distinguish them from their counterparts. Otherwise, it could be very interesting for me to send you a helloworld.scheme file, and for you to see me referencing some framework objects using extended language syntax features.
.NET, or don't use a functional language like Scheme. You can't have your cake and eat it too. If you want to cross paradigms, I can't think of any way of doing that without some type of technical paradigm-bridging enhancements. If you're not happy with this particular implementation of the paradigm-bridging technology, that's fine - let's discuss it. But let's be clear about what we are discussing.
.NET!" However, from what I've seen, J# code looks identical to regular Java code. In fact, if you had the proper packages to replace the .NET framework (System.*, etc.), I would guess that 99% of J# code would compile with no problems and run on a JVM.
My main points are:
That's why they get names like Scheme#, etc
Ah, now I see what you are getting at. In my opinion the reason a language like Scheme (or any other inherently non-OO language) gets a # at the end is primarily to distinguish it for the
In any case, I don't see why this would be a negative thing (having the # added to the name). If we all agree that a framework such as
You think this sounds like a bad idea? Then either don't use an object-oriented framework like
In the case of other languages, there are more obvious reasons that they have received modification marks to distinguish them from the original languages:
VB.Net - obviously important to distinguish from the non-object-oriented VB.
J# - Java is already object oriented, so obviously the biggest reason for a different name here is legal, because as far as I'm aware, MS can't throw a product out there and say, "this is Java, running on
In any case, I still have no idea what any of these paradigm and framework issues have to do with the CLR. It's like arguing that Intel architecture really supports only C, and not any other languages.
I wouldn't really classify it as a problem of .NET. Obviously, if you have "objects" which are built to be accessible by an object-oriented language, you are going to have challenges in integrating those concepts with a language that operates on a different paradigm, such as functional (Scheme) or procedural (Fortran), etc. However, these are problems which are inherent in the gaps between different language paradigms, and are not a product of .NET or any other cross-language framework. In any case, the more relevant point is that these challenges clearly have little to do with the CLR, which is an abstraction of the assembly layer, not the OO-layer or whatever other paradigm-specific layer you have. Since assembly is built on top of the machine layer, presumably there is no paradigm which is "better" or "worse" suited to that layer. Of course some languages can give you more or less access to such low-level instructions, but that clearly is nothing new in the programming world.
.NET are OO languages. .NET is about providing a common assembly instruction layer for cross-language development, not just an OO layer (although there is that too, for languages which will utilize it). If the point is that .NET prefers OO languages, I would certainly agree, but let's be clear on terminology then - let's not say "just C#" or whatever - VB.Net, C#, J#, C++, etc. all have approximately the same level of support and functionality in .NET, with certain language-specific advantages for each. Those advantages are primarily a product of the language developers, not the .NET framework, and certainly not the CLR!
The ".NET spin" is not saying that all languages now become interoperable at the OO-level - clearly not, because not all languages on
How can this comment be (+5 Interesting) while each of the subsequent comments are 1's and 2's? When I first read this, I almost jumped to write a diatribe, and found that the other replies had already covered most of the important points very nicely. This comment should be marked (-1 : Ill-Informed) or some such rating, as it is highly misleading to anyone on /. who might be trying to learn about .NET.
.NET, and trust me, I've heard plenty. One of the major objectives, if not the most important, is to bring to prime-time quality Microsoft's idea of supporting many languages on the same framework. They started this idea a long time ago with COM, and as it evolved, they realized all of the flaws in the COM architecture, and .NET is the next generation of multi-language support, in that sense. .NET currently supports what, like 20+ languages? Not all of them developed by MS, btw... Many of these languages use different paradigms (scripting-oriented, functional-oriented, procedural, etc.), and they all have access to the full breadth of the .NET framework. If that's not "multi-language support", I don't know what is.
.NET are "subsets of C#" is either naive or very malinformed. Anyone who knows the history of this knows that VB has always been Microsoft's baby, and C# is just the new kid on the block. Yes, now that C# has realized its potential, perhaps it is overtaking VB in popularity. But to claim that VB provides a "subset" of C#'s functionality is precisely backwards - in fact it is literally backwards - if anything, C# provides for the most part a subset of VB functionality, although technically the two provide somewhat intersecting but not fully overlapping sets of functionality - there are some things you can do in VB that you can't do in C#, and there are some you can do in C# that you can't do in VB. And the same goes for all languages on the .NET platform.
.NET language which already supports these concepts. If you wan't to complain that C# doesn't support them, that's ok. But to complain that "CLR doesn't support them" really doesn't make sense. Get your argument straight first.
As the others have mentioned here, the CLR is an abstraction of the assembly instruction layer, not the "object-oriented" layer. Thus, a statement such as "CLR does not support {select archaic c++ OO concept}" does not make any sense. This obviously applies for things like multiple inheritance, templates, etc.
Furthermore, the idea that the CLR "does not support multiple languages" is the most ridiculously malinformed statement I have ever heard about
To assume that languages supported by
Features like templates and multiple inheritance are first and foremost a feature of a language at the OO-level of abstraction - not the assembly level. As one poster noted here, Eiffel is a good example of a
We're not talking about the same thing.
Of all of the amazing people I've met and had the fortune to work with in my career, if I make a subset of those I would really like to work with again, probably at least half would be Ph.D.s, several from the US. I have no problem with people with Ph.D.s, and I certainly don't think they are difficult to work with.
What I am talking about is simply the statistical probability of finding the right candidate on review of a RESUME with Ph.D. on it - that is where the bias is, and the bias is not just mine - just look around on this thread and you'll see numerous others with similar opinions or similar experience.
You may very well have a point - results are skewed because of higher levels of unavailability of actual desirable PhDs in the marketplace - in fact, given that I did most of my interviewing during 1997-2001, in that job market I would say that is almost certainly the case. Nevertheless, those were the results, and guess what - many other people who are reviewing resumes now have this similar experience during those years to look back on. Again, I am talking simply about the experience of reviewing resumes and conducting interviews, leading up to the hire. I am NOT talking about the post-hire working experience.
On the US born students thing - I'm not saying they are by definition inferior - but perhaps they are by circumstance statistically inferior. Honestly, I'm not an expert in the study of foreign versus domestic educational systems, but it's simply my theory to explain the skewed results I've seen favoring those PhDs originating from outside the US.
Numbers - we're certainly talking thousands or 10s of thousands of resumes, probably consisting of a few hundred PhDs, and less than a hundred actual interviews with PhDs. Personally, I only recall actually being involved in ultimately hiring 2 PhDs - most of the others I've worked with were either there before I got there, or came in through another interviewer/recruiter.
Well I'm not sure which camp you are putting me in - I assume the "non-Ph.D." camp, since the line is apparently so clearly drawn for you.
In any case, I certainly see what you are saying - many of those in the position to hire may very well be seeking those they can "dominate". However, as a potential job applicant, those are places I would try to filter out and avoid anyways - why would anyone be attracted to an environment like that? If this seems to be the norm to you, that sounds like either a very paranoid view, or a sad reflection on the state of things today.
But if you've read my posts here and this is all you are getting from it, I'm clearly not getting my point across. I'm not talking about managers with inferiority complexes or other issues like that - I'm simply talking about normal hiring managers with normal experience interviewing people from a variety of backgrounds. Under those circumstances, I am arguing that statistically, the probability is skewed such that there is a lower probability of finding a "good fit" in a pool of Ph.D. candidate, versus a pool of non-Ph.D. candidates, for "normal" or "non-super-specialized" positions.
I could theorize that this is an aggregated result of a number of factors, and I will still claim that this attitude you are clearly illustrating is one of the major factors. I would say that it is certainly NOT all about "control" - at least not in the real world outside of your mind. I'm sure that on the motivations that make you say this, you and I are not as different as it might seem - but I would imagine that it would be near impossible to ever be happy in any position in any real company, while continuing to think this way.
Every employee of every company reports to someone, except for the owner, and they report to stockholders or customers or whomever. And at every level from the lowest code-monkey up to the CEO, there is incompetence, and in many cases that incompetence rises to the top. I'll be the first to admit that I am capable of demonstrating a level of incompetence from time to time, but I'll also reinforce my claim - that level of incompetence certainly increases at levels above me in my organization. This is the nature of any working environment in real life - unless you are the most incompetent person in the organization, there is a high probability that someone at a level higher than you is going to be more incompetent than you.
And this is an excellent example to illustrate the difference between the "typical" Ph.D. candidate versus the "typical" non-Ph.D. candidate - in my experience, the non-Ph.D. candidate would statistically be better equipped to "deal" with this situation in a more professional, productive manner - the Ph.D. candidate would statistically be more likely to demonstrate problems dealing with this very common "real-world" scenario, such as the attitude you are displaying.
By the way you've phrased your comment, I'm not sure which side of the camp you're on - I can't tell if you're being facetious, or if you actually consider this viewpoint the more appropriate one.
We are talking about the real world, with real people, who have real experience, solving real problems. Unfortunately, these are things that a Ph.D. candidate is statistically less likely to be adept at. That combined with the type of statement you've made are exactly typical of a Ph.D. candidate with plenty of ego but lack of real world experience. Perhaps more importantly, a flagrant display of potential lack of respect for colleagues is a sure-fire losing strategy for an interview.
I think you've summed up very well one of the major concerns I have going into many Ph.D. interviews - this is an attitude which doesn't work in a professional environment. It often doesn't matter whether the individual is actually better or worse than the person above them - an appropriate level of respect is often more important than raw competency.
penis envy for those who finished Ph.D.? perhaps.
but i think you're missing my point - i am simply talking about statistical, empirical evidence based on my own experience. the fact is, to put it bluntly, the average Ph.D. in an interview for a non-academic position, for one reason or another, simply doesn't make the cut as often as the average non-Ph.D. candidate. In fact, I would say they don't even come close, and it usually has a lot to do with skills in fitting with the "real world".
On the other hand, the rare but exceptional Ph.D. candidate often far exceeds those with lesser degrees. But when you are hiring, sometimes the position just requires "good enough".
As I've tried to make clear - I am all for people doing post-grad work (as I did), and in general I have more respect for those who do. I am simply talking about whether it is a statistical impediment to getting a job.
The fact is that many people who read resumes always use "rule of thumb" hueristics to scan through them quickly, and unfortunately, interview experience often puts Ph.D.s in the "filter-out" category.
Don't hate the playa - hate the game.
In my opinion, probably the best strategy. Honestly.
Good question - in fact, that's what I did during my graduate studies. Given the strange elements in my own background, obviously I try to give as much consideration as possible to every candidate, and people who work during their studies always get special consideration from me because I feel I can relate better to them. In fact, this would be something I personally look for. So unless I simply don't feel like going through a huge stack of resumes, of course I'm not going to just blindly filter out all the Ph.D.s.
But what I'm trying to give you here is a sense of my gut reaction - from a statistical risk perspective. Unless you make it blatantly clear on your resume (i.e. "1998 Ph.D. CS + WORKED FULL TIME!!!"), in my opinion you run the risk of getting filtered before someone notices or thinks to give you special consideration. Resume readers are probably the worlds most efficient speed readers, and depending on the reader's mood at that particular instant in time, there are plenty of keywords that statistically can get you immediately filtered out. Unfortunately, in my opinion, even with as much respect (and envy) as I have for many who have finished their Ph.D.s, that is a very high-risk thing to have on the resume.
If I actually make it far enough to consider your unique circumstances, you might very well be kept in the "yes" stack - but sometimes the trick is to get that far. Honestly, unless the position is very specialized and requests only Ph.D.s, if I'm reading your resume, having Ph.D. almost certainly will do nothing except automatically lower that initial "gut-reaction" score. It's high-risk, and almost always low-reward.
In the past I've been heavily involved in my firm's recruiting and interviewing, and during this time I've spoken to a fair number of people from varying levels of education. So here's my $0.02 based on my experiences:
By the time I finally felt I was comfortable as an interviewer, I had developed an automatic negative reaction to seeing Ph.D. on a resume - even now, I will often strike a Ph.D. resume without fully reading it. But of course, it depends on the role I'm hiring for - some roles really do require the expertise that only a seasoned expert can provide. But for most general roles, I found that the benefit is not worth the potential trouble, so most Ph.D.'s never made it to an interview with me. The reason is that my early experiences with Ph.D.'s were almost always decidedly negative - primarily from a personality/fit perspective. I'm sure most of these guys knew their stuff - but they simply weren't prepared for the "real world".
Before I make myself sound far too anti-Ph.D., let me say that this should in no way reflect my personal opinion of people with Ph.D.s - in fact, some of my best friends have Ph.D.s - people I highly respect, both academically and in the workplace. So the message I am trying to relay here is more about the "gut-reaction" of an interviewer/resume reviewer, than of the actual value of a doctorate-level education.
Let me also say something somewhat more controversial. Some time after I developed my initial impressions about Ph.D.s, I developed a new opinion - it is not simply all Ph.D.s, but perhaps Ph.D.s with a U.S. education background. I have more recently had excellent experience interviewing a number of candidates who completed their early schooling in Europe, and then came to America to do their Ph.D. Statistically, my experience has shown me that these individuals seem to be better rounded, and also more adept in their advanced study, in comparison to U.S. Ph.D. graduates. I'm not yet sure what this says about the U.S. education system, but take it for what it's worth - At this point, upon seeing a Ph.D. in a resume, I will consider a number of other factors before throwing it in the trash - most notably, previous educational experience. My interpretation is that Europeans on the whole are more driven to do post-graduate work as a normal part of their education, while in the U.S. post-graduate work is more exceptional and generally considered "unnecessary" - thus statistically, you don't get the well-rounded candidates at that level as often in the U.S., because you only see "academics".
For demographical purposes, I'm from the U.S, and I have a Masters - but I've always wished I had finished my Ph.D. - go figure...
"unlike others mentioned here, there is a nice replacement for Access: mysql (or postgresql for that matter). OpenOffice can pull data from ODBC data sources. Mysql and other databases support open source."
I think the point some people are trying to make here is not about simply using MS Access for accessing a database - obviously anyone building a real database app who knows what they are doing would never try to use access simply as a back-end database, because there are many much better options for that, both MS (SQLSvr, MSDE) and non-MS, ranging from free to cheap to expensive.
The point people are talking about here is being able to migrate *applications* that their users have built with access. That's the trick with Access - as a scalable or high-performance db, it isn't that great. But it's key advantage is that it allows you to very easily build data-entry applications to maintain relatively simple databases, without any programming or programming language, or even being aware that you are building an app that is connecting to a database.
we are talking about almost-mom-level simplicity in building custom data-entry apps here - and there is no other solution that provides that, that i am aware of. certainly mysql isn't targeted at that audience, and why would they want to be?
unfortunately, many, many businesses have vast amounts of data maintained in collections of ad-hoc "databases" built simply using Access. this is very similar to the Excel "application" dilemma - in order for open-office to really be successful with many businesses, it is going to need not only a seamless strategy for document migration, but also the full office suite replacement - and that includes both excel "applications" and access "applications".