Few newbie Quesions on C#

[heatlesssun]

Out of curiosity, how important do you rate SQL skills?

Extremely important, especially in enterprise IT.

 

[Dogs]

Keep in mind that you have to learn a lot of other crap, too. You just don't have the brain cycles to first learn a language you are going to toss.

Then why would you go and say something like this?

I also don't like it when people make the statement you just made, that all languages are very similar anyway. Sure, C++, C# and Java do, and the scripters not too far away. But if you want to be a really good programmer you need some exposure to something with a different approach, so that you give your brain some stretching. Prolog, ML, or Lisp used in a non-C manner.

You just said we don't have brain cells to waste on learning a language we're going to 'toss', and then advocated essentially just that. The fact that you've just contradicted yourself on such a level really is a glowing neon sign that says you're grasping for straws here.

I'm all for learning functional and non-imperative languages to broaden your ability to approach and solve a problem. But for precisely the same reason you can learn something like LISP, never use it once in your career, and still derive value from having done so, you can learn a language like C# and go straight into a career doing Java work.

And that doesn't begin to address the issue of personal libraries that you build. The only way to get away from that is if you do middleware things exclusively.

I don't have the privilege of being able to do that, because as soon as I use anything from my 'personal library' in the workplace it immediately becomes intellectual property of my employer, and it's been that way for every single employer I've ever worked for. So if I'm going to have to reproduce my 'library of tricks' from memory every time I want to use it anyways, recreating it in C# or Java doesn't really make a difference.

Out of curiosity, how important do you rate SQL skills?

SQL skills (as in, skills in the SQL language itself) are of no importance. It's just a domain specific language, and a simple one at that. Learning the SQL syntax should take anybody the better part of a day. It isn't really something people worry about doing, but if you wanted to you could use a different 'query language' to achieve the same results, and I'm sure this wouldn't cause you much stress.

What is important is having a strong understanding of the underlying relational database. And by that I mean set theory, relational algebra, data science, how indexing works (therefore, how B+ trees and hashing work, what is a clustered index, what is a non-clustered index), how databases develop execution plans and what they mean to the developer, the advantages and disadvantages of using features like triggers, stored procedures and prepared statements, etc.

Fortunately for people like college students, you're not expected to be experts in databases in order to get a job. It's important that you know enough computer science and have a rudimentary idea, but there should already be sufficient talent and expertise from the senior developers and the DBAs to help mentor you through the more advanced topics. If you're trying to get a senior position and you don't already have expertise in databases, that's going to raise some questions, but if you're going for an entry-level developer position, just a basic understanding will usually get you where you need to go.

 

[uOpt]

At least we agree on the SQL part

I think it is important that you stretch your brain with exotic language constructs, but you bind to one language like a natural speakers binds to the first natural language.

So, changing languages == wasted brainpower. Expanding your horizon by playing around with other languages == well invested brainpower.

 

[heatlesssun]

SQL skills (as in, skills in the SQL language itself) are of no importance. It's just a domain specific language, and a simple one at that. Learning the SQL syntax should take anybody the better part of a day. It isn't really something people worry about doing, but if you wanted to you could use a different 'query language' to achieve the same results, and I'm sure this wouldn't cause you much stress.

What is important is having a strong understanding of the underlying relational database. And by that I mean set theory, relational algebra, data science, how indexing works (therefore, how B+ trees and hashing work, what is a clustered index, what is a non-clustered index), how databases develop execution plans and what they mean to the developer, the advantages and disadvantages of using features like triggers, stored procedures and prepared statements, etc.

Fortunately for people like college students, you're not expected to be experts in databases in order to get a job. It's important that you know enough computer science and have a rudimentary idea, but there should already be sufficient talent and expertise from the senior developers and the DBAs to help mentor you through the more advanced topics. If you're trying to get a senior position and you don't already have expertise in databases, that's going to raise some questions, but if you're going for an entry-level developer position, just a basic understanding will usually get you where you need to go.

I agree with you, but don't underestimate the subtle complexities of SQL. I've worked for a number of large banks for a long time and large relational databases are the heart and souls of these institutions and they typically have tons of heterogeneous platforms that have to interoperate with each other and reporting on that data drives much of the technical operations.

 

[Dogs]

but you bind to one language like a natural speakers binds to the first natural language.

I don't think that's ever been empirically demonstrated to be the case. And anecdotally, I first learned to write software with Visual Basic 5.0, and I certainly spent enough time with it for it to be my 'first language'. Many moons have passed since then, and if anything is my natural language it certainly isn't VB5. Sitting down in front of VB feels just like sitting down in front of Pascal, or any other language I don't use regularly. Certainly I can still work with it if the need arises, but I need just as much refreshing as I would any other language. That doesn't seem very 'binding' to me.

I agree with you, but don't underestimate the subtle complexities of SQL. I've worked for a number of large banks for a long time and large relational databases are the heart and souls of these institutions and they typically have tons of heterogeneous platforms that have to interoperate with each other and reporting on that data drives much of the technical operations.

Don't get me wrong. I'm not saying working with the data isn't important. I'm just saying I'd rather employ someone who can understand why a poorly written query has the database engine doing a table scan instead of an index seek and figure out a way to tune the query to correct the problem than employ someone who can recite every difference between the ANSI SQL standard and Microsoft Access's SQL implementation. If those are the two selling points I have to pick from, that's what I'm going to value.

Furthermore, I think if the data model and all of the integration was done well in the first place, it will make it easier to use things like SAP BusinesObjects to deal with the reporting and help keep some of the responsibility of reporting out of the developers hands.

 

[uOpt]

I don't think that's ever been empirically demonstrated to be the case. And anecdotally, I first learned to write software with Visual Basic 5.0, and I certainly spent enough time with it for it to be my 'first language'. Many moons have passed since then, and if anything is my natural language it certainly isn't VB5. Sitting down in front of VB feels just like sitting down in front of Pascal, or any other language I don't use regularly. Certainly I can still work with it if the need arises, but I need just as much refreshing as I would any other language. That doesn't seem very 'binding' to me.

Well, Basic and Turbo Pascal had much of things to remember in the libraries, not the language itself. They probably don't do the mother hen binding as much.

But today is the age of C++ template metaprogramming, knowing the memory model of your language (if any) out of hand, compile-time computing in Common Lisp and all kinds of new iterator concepts (mainly Python). That is a different caliber, and it's not libraries.

And then there is performance. If you want native speed without much language overhead you will quickly bind to your language. C++ in particular can have nasty performance traps. The knowledge about them is extensive baggage to first accumulate and then keep swapped in.

 

[Dogs]

The knowledge about them is extensive baggage to first accumulate and then keep swapped in.

Only if your strategy for this is simply brute-force memorization of these 'performance traps'. There are technical reasons for these performance traps, not 'sorcery', and understanding why they have the impact on performance that they do is the appropriate way to deal with avoiding them.

I don't know about you, but I don't like to make assumptions about what my code is doing. If I don't know how a library or class or language construct works, I'm going to consult the documentation or a trusted reference book, and I'm going to do this regardless of whether I'm writing in a language I use all the time or a language I just picked up. In severe cases of uncertainty, you can usually rely on the disassembler. If between my colleagues, the docs, the reference materials and the disassembler the performance problem wasn't pointed out to me or predicted simply based on the details I manage to uncover, then it probably isn't a very common or obvious pitfall and I could have easily made a similar mistake in a language I use all the time. I like to believe that this has saved me from running into problems more than any amount of 'language baggage' has. If I'm not confident that I have a strong picture of what the code I just wrote actually says, I'm not confident checking it in and calling it done.


None of this, of course, has any relevance to your previous statement, though. Certainly there are many details you should become aware of in whatever implementation language you're working with. That has nothing to do with someone 'binding' to their first language.

 

[heatlesssun]

Don't get me wrong. I'm not saying working with the data isn't important. I'm just saying I'd rather employ someone who can understand why a poorly written query has the database engine doing a table scan instead of an index seek and figure out a way to tune the query to correct the problem than employ someone who can recite every difference between the ANSI SQL standard and Microsoft Access's SQL implementation. If those are the two selling points I have to pick from, that's what I'm going to value.

Furthermore, I think if the data model and all of the integration was done well in the first place, it will make it easier to use things like SAP BusinesObjects to deal with the reporting and help keep some of the responsibility of reporting out of the developers hands.

I agree with what you're saying here. I my thought is that most people having the skills you place importance on are typically SQL experts.

 

[Dogs]

I agree with what you're saying here. I my thought is that most people having the skills you place importance on are typically SQL experts.

Chances are, yes, people with strong database skills are going to have SQL skills. But the inverse is not necessarily true...You can know your way around SQL and still write crappy database queries and build crappy data models.

In other words, if you're interviewing a college grad or an entry level developer, I would say the following: Having someone write some SQL to iterate over every item in a result set without explicitly using a cursor is not a measure of how valuable an asset they are as a developer. Giving someone an example of a few related database tables and the problem they model and asking them what they'd use as a primary key, what indexes and constraints they'd use, etc. and their reasoning for their choices on the other hand, would be more insightful. It's not the question of their SQL skills that's interesting, but their understanding of databases themselves.

 

[heatlesssun]

Chances are, yes, people with strong database skills are going to have SQL skills. But the inverse is not necessarily true...You can know your way around SQL and still write crappy database queries and build crappy data models.

In other words, if you're interviewing a college grad or an entry level developer, I would say the following: Having someone write some SQL to iterate over every item in a result set without explicitly using a cursor is not a measure of how valuable an asset they are as a developer. Giving someone an example of a few related database tables and the problem they model and asking them what they'd use as a primary key, what indexes and constraints they'd use, etc. and their reasoning for their choices on the other hand, would be more insightful. It's not the question of their SQL skills that's interesting, but their understanding of databases themselves.

This might be where the disagreement is. Sure anyone can write a select statement with a where clause, maybe a few joins. But as you start to add more elements like unions, multiple joins, grouping, etc., it starts to become very complex very quickly with large databases and it's not just about understanding SQL syntax, especially when you write that query that takes an hour to run that needs to run in a second.

 

[Dogs]

especially when you write that query that takes an hour to run that needs to run in a second.

Again, this isn't an SQL problem. SQL concerns are things like 'Will this query give me the data I'm trying to ask for?" (and even in some sense, these can be abstracted to be domain relational calculus problems). Questions like "Why does this query take an hour when I want it to take less than a minute?" are deeper topics. SQL is simply a means by which to talk to the database. If you ask the database to do the same thing, but in a different language like LINQ-to-SQL or QUEL, it's still going to be slow. This is because it isn't the SQL that's the problem. You could be writing perfectly valid SQL...but what you're asking the database is a bad idea, and that's why your query is slow. Maybe your just asking too much of a relational database, and what you really need to solve your problem well is Hadoop and Pig, and know amount of knowing how to write Cartesian joins and SQL triggers is going to help you with that.

In the same sense, things like fast matrix multiplication or fast fourier transforms aren't Java problems, even if you use Java to instruct the machine on how to solve these problems. If I'm going to hire someone to write a Java library to do fast matrix math and signal processing, I'd rather hire someone who has implemented Strassen's algorithm correctly in C and has never touched Java than somebody who has been writing ticketing systems and websites in Java for 15 years but isn't even familiar with the naïve algorithm for matrix multiplication.

In other words, I don't really think the SQL is itself the important skill when working with databases. In the exact same way, I don't believe programming language knowledge is as important as knowledge of algorithms and design patterns and good problem solving skills. Naturally, someone who is an expert on both would be ideal, but SQL skills alone aren't of much value if the developer doesn't have a strong grasp on how the database they're querying works, much like how knowing Java isn't very useful if you've only ever used it to solve trivial problems.

 

[heatlesssun]

In other words, I don't really think the SQL is itself the important skill when working with databases. In the exact same way, I don't believe programming language knowledge is as important as knowledge of algorithms and design patterns and good problem solving skills. Naturally, someone who is an expert on both would be ideal, but SQL skills alone aren't of much value if the developer doesn't have a strong grasp on how the database they're querying works, much like how knowing Java isn't very useful if you've only ever used it to solve trivial problems.

SQL is domain specific, it's not general purpose in any way shape or form. It's brilliance is that is tersely expresses relational database solutions. I just don't think I've ever met anyone in all my years in enterprise IT that understood SQL well that didn't have at least a decent understanding of relational databases.

 

[pedant]

I'm going to chuck my 2 pennies in to this derailed thread....
I've worked at a few banks, and they, like many other places are starting to explore other options to relational databases. I think this is a good thing as despite having a reasonable amount of experience of databases, I'm not fond of SQL.
You'd think this would make finding people with suitable skill sets more difficult, but in reality I believe most people can surpass their (baseline okay) sql skills fairly rapidly with other query languages.

 

[uOpt]

I'm going to chuck my 2 pennies in to this derailed thread....
I've worked at a few banks, and they, like many other places are starting to explore other options to relational databases. I think this is a good thing as despite having a reasonable amount of experience of databases, I'm not fond of SQL.
You'd think this would make finding people with suitable skill sets more difficult, but in reality I believe most people can surpass their (baseline okay) sql skills fairly rapidly with other query languages.

Myself I work in environments that are mostly read, rarely write.

We would never consider using SQL. The speed compared to mmapped read-to-use structures is just not there. And finding records is a well understood programming problem. I find it more valuable to study how to do that well than being just another SQL hacker.

I also intensively dislike mixing syntaxes. SQL in strings in a different language is terrible, almost as much as every other way to do it.

 

[heatlesssun]

We would never consider using SQL. The speed compared to mmapped read-to-use structures is just not there. And finding records is a well understood programming problem. I find it more valuable to study how to do that well than being just another SQL hacker.

I don't think you've ever dealt with relational databases saying this. SQL is a language, it really has nothing to do with the underlying implementation of how data is stored or retrieved.

 

[uOpt]

I don't think you've ever dealt with relational databases saying this. SQL is a language, it really has nothing to do with the underlying implementation of how data is stored or retrieved.

Of course. You are still not going to beat a custom persistent hashtable or whatever you end up picking.

Once you write and need very predictable writes that goes out of the window, but there are many things that don't require that.

 

[Dogs]

Of course. You are still not going to beat a custom persistent hashtable or whatever you end up picking.

In some cases, that works. In other cases, I can't see it really see something like that work. What if you have 50 billion related records (not all in one table) corresponding to transaction data? It's certainly a neat idea, but I think the space of problems where you can get away without a relational database is very small.

I also intensively dislike mixing syntaxes. SQL in strings in a different language is terrible, almost as much as every other way to do it.

In many ways I think that's a silly thing to say. Do you go to great lengths to avoid regular expressions and pattern matching, then? Because those are the same idea: domain specific languages.

 

[uOpt]

In some cases, that works. In other cases, I can't see it really see something like that work. What if you have 50 billion related records (not all in one table) corresponding to transaction data? It's certainly a neat idea, but I think the space of problems where you can get away without a relational database is very small.

I am doing this kind of thing for decades. It's not an idea. At some point in performance work the problem of making joins a bit easier becomes trivial compared to all the other stuff you have to do.

In many ways I think that's a silly thing to say. Do you go to great lengths to avoid regular expressions and pattern matching, then? Because those are the same idea: domain specific languages.

Yes. Currently popular regular expressions are terrible in many ways and a majority of uses in practices doesn't actually require them.

But even if you use regular expressions in string literals, I think that is much better than putting SQL. Plus you can do some statics testing on your regular expressions in string literals (just grep for them in the source code and test whether they compile). SQL statements are usually not literals, you mix in data at runtime. So you fail at runtime.

 

[heatlesssun]

SQL statements are usually not literals, you mix in data at runtime. So you fail at runtime.

Not exactly what you mean here. SQL statements from an application perspective are generally parameterized like most function calls in any language. Indeed most modern RDMS have programmability extensions beyond SQL in the form of stored procedures and functions and those can even be written in other languages, though that's rare, though useful in some cases.

 

[Dogs]

SQL statements are usually not literals, you mix in data at runtime. So you fail at runtime.

If you go the way of PHP developers and just slap in an untested SQL statement, convert your parameters into strings and substitute them in, and then run the application without unit testing anything, then sure, that might be a problem for you.

In the professional world, though, we have a number of practices that make that a non-issue. For starters, I generally test my query against a local or development database before I even put it into my application to make sure it does what I want. Second, prepared statements in conjunction with type safety will catch a lot of the problems you could run into at compile time. If I'm using a prepared statement, the query has already been prepared, and there's placeholders waiting to receive values. In Java, to fill those values you need to use a method like 'setInt' or 'setString', and if I'm giving a string to setInt, that's going to be caught by code analysis in my IDE before it even makes to to compile time, but certainly it wouldn't compile. Additionally, I'm going to unit test whatever code is supplying the parameters to make sure they're behaving as I would expect. I'm also going to use mocks or stubs in my unit test of the code that owns the prepared statement so that I can make sure the parameters I'm giving that piece of code are the same parameters being set on the prepared statement. And when I put it all together, I'm going to have integration tests and regression tests. Whatever code that interacts with the database (I'm usually in Javaland, where this would be a DAO) is going to be a separate project, and with any acceptable amount of test coverage, it's fairly easy to make sure that you're going from your interface to your SQL queries correctly. If you're doing things in a sound way, when problems occur they're going to be caused by the application that's using your database access code giving it bad data, not with the query yourself.

In other words, the only problems you're really ever going to run into are where the application is asking the wrong question with valid SQL. And if the application is asking the wrong question, you're going to get the wrong answer whether you're using SQL or something else, or whether the SQL lives in your code or somewhere else. If you're checking in code that has bad SQL statements in it, you're doing it wrong in a variety of ways: No gated check-ins? No code reviews? Bad test coverage? Not sufficiently testing the code locally before calling it done?

Indeed most modern RDMS have programmability extensions beyond SQL in the form of stored procedures and functions and those can even be written in other languages, though that's rare, though useful in some cases.

We use stored procedures everywhere (unfortunately), and even then, you're usually going to have some sort of domain specific code to call those stored procedures in your application layer. In our case, this doesn't really look much different (in the way that uOpt is complaining) than having an ad-hoc query would.

 

[Bigbacon]

Still waiting for listing any major website using C#.

If you want to squeeze more developers into a shrinking market more power to you.

One of the largest home builders, NVR, uses C# for both their public and internal web sites and applications.

 

[uOpt]

One of the largest home builders, NVR, uses C# for both their public and internal web sites and applications.

I'm still thinking more of major Internet businesses as opposed to non-Internet businesses that happen to have a website.

 

[wonderfield]

If you wanted "major internet businesses as opposed to non-internet businesses that happen to have a website" — for whatever reason — perhaps you should not have requested "any major website using C#".

That "any" word is kind of a big one.

 

[uOpt]

If you wanted "major internet businesses as opposed to non-internet businesses that happen to have a website" — for whatever reason — perhaps you should not have requested "any major website using C#".

That "any" word is kind of a big one.

I think we are fighting words now.

Fact is that the real players in the internet business use neither Windows nor C#.

 

[MrWizard6600]

Certainly, then, you must have come to love lambda expressions too. LINQ in conjunction with lambdas is a very powerful pair. So you're probably disappointed by the fact that Java still doesn't have lambdas. I can't tell you how annoying it is to write crap like this:

interface Invoke {
    void invoke(Connection con);
}

class SomeClass {
...
    public void doDatabaseStuff(Invoke i) {
        Connection c = this.connectionFactory.getConnection();
        try {
            i.invoke(c);
        } catch (SQLException ex) {
            //Exception handling goes here
        } finally {
            c.close();
        }
    }
...
}

...

SomeClass something = new SomeClass(ConnectionFactory.getInstance())

something.doDatabaseStuff(new Invoke() {
        //Enter your lambda-esque function here
    });

All that boiler plate just to approximate lambdas.

And it's not just the absence of big features that gets annoying. All of the little stuff adds up to make something that's less elegant and less productive than C#.

For example, why can't I do this?

public int someMethodWithDefaultArgument(Argument1 a1, Argument2 a2=Argument2.BrownArgument){
    //Method code goes here
}

Since Java doesn't offer default arguments, I have use this much boilerplate just to get the same effect:

public int someMethodWithDefaultArgument(Argument1 a1, Argument2 a2){
    //Method code goes here
}

public int someMethodWithDefaultArgument(Argument1 a1){
    return someMethodWithDefaultArgument(a1, Argument2.BrownArgument);
}

I really like C#
Though I like Scala more than F#, I still really like the .net framework.
the await keyword in C# 5 with WinRT is a masterstroke... though WinRT is kind've a clusterfuck.

Anyways, this seems like an excellent time to plug my soon-to-be-on-maven library:

Linq-A-Like

The following is legal Java-8 code:

Queryable<CustomerWithAge> seniorsViaLinq = sampleData.where(customer -> customer.CanClaimSeniorsDiscount());

You can get the Release-Candidate of Java-8 from oracle here.

I'll publish under linq-a-like on maven as soon as I'm happy with my test fixtures! please give it a look!

Worth noting, Java-8 lambda's don't approach LINQ Expressions, they are akin to Action and Func only. You cannot inspect a Java lambda and get the abstract syntax tree back from it. With liberal use of annotations and a pre-processor I might be able to some extra-language integration. Hardly elegant.

Oh, and while we're on the topic of bashing this guy:

Still waiting for listing any major website using C#.

If you want to squeeze more developers into a shrinking market more power to you.

A bunch of products you've never heard of from iqmetrix.com are all backed by C# services (in fact a couple use F#). It's a "big" service because about 40% of the phones sold in the united states are sold through RQ4, which itself is written in C# and hits a number of C# web services.

 

[Dogs]

This seems like an excellent time to plug my soon-to-be-on-maven library:

Linq-A-Like

I will keep this in mind for when Java 8 is more mature.

 

[MrWizard6600]

Fact is that the real players in the internet business use neither Windows nor C#.

real players in the internet business. What are you talking about?

Pick the best tool for the job. Regardless of your choice, you'll have challenges.

One of my favorite stacks to work on was Windows, IIS, Mongo and .net. Now I'm writing GUI's in Java for Linux with our model persisted in flat XML files. Would I want to use SQL in the latter? Christ no. Would I want to use flat-files in the former? Absolutely not!

I'm sure that at some point in my career I'll be back in embedded systems land writing drivers in ANSI-C, and when I'm there maybe I'll need your memory-mapped database, maybe that will be a crazy solution. You have to choose the tool that best fits the job

To write off the entire Microsoft ecosystem as you are doing severely limits your choice of tools.

 

[wonderfield]

I think we are fighting words now.

No, I don't think that's the case. As I said earlier, I think you're simply moving argumentative goalposts because you're unwilling to concede the point that C# has a place in various ecosystems. Whether it should have a place is an entirely different argument, but you can't realistically take a revisionist stance on C#/.NET industry usage just because you're against platform lock-in on general principle.

To write off the entire Microsoft ecosystem as you are doing severely limits your choice of tools.

Which is, ironically, the very thing he argues against. Although there are socio-political issues inherent in any platform or toolchain, they are not engineering issues. Discarding potential solutions without evaluating them for their merits just isn't good engineering.

 

[Zangmonkey]

So what happens if you start programming today, in C#, and it turns out you are really good at it? You gonna apply for a job at Google with C# only in your backpack?

It worked for Jon Skeet....

 

[uOpt]

To write off the entire Microsoft ecosystem as you are doing severely limits your choice of tools.

I specifically recommend *against* languages that bind you to OSes. So I *enable* windows.

The who's-running-windows side track in this thread only came from that being an easier way to see what the base for C# might be. Of course lots of things that use windows use Java on top.

 

[pxc]

Which *language* is it "that bind(s) you to OSs" in this discussion?

/prepares for incoming goal post moving again
/adds another pointless user to ignore list
/day just got a bit better

 

[Bigbacon]

I'm still thinking more of major Internet businesses as opposed to non-Internet businesses that happen to have a website.

except that the website is a HUGE basis for their entire business. They spend A LOT of money and time on it because it brings in sales.

 

[uOpt]

except that the website is a HUGE basis for their entire business. They spend A LOT of money and time on it because it brings in sales.

And that makes it comparable to Google or Yahoo?

Re the "binding" thing, you are going to run C# in Mono?

 

[mikeblas]

Practically all of the points raised in this thread aren't relevant to a beginner.

 

[uOpt]

Practically all of the points raised in this thread aren't relevant to a beginner.

Complete disagreement here, but we went over this before.

If you do exclusively middleware or other things where the work is limited to looking up what library they want you to use today, the language is just a tiny bit of glue between library calls, there are no complicated algorithms and you don't have to make your own code (as opposed to the library calls) fast, sure. Then it doesn't matter.

For personal productivity, for implementing complicated algorithms in acceptable machine speed, for code reuse over decades, sure it matters. And you won't get any of the really cool jobs without all of these.

 

[mikeblas]

I didn't say language doesn't matter in general. I said that, in this thread, the points being raised aren't relevant to a beginner.

 

[uOpt]

I didn't say language doesn't matter in general. I said that, in this thread, the points being raised aren't relevant to a beginner.

Why would you recommend to a beginner to use a language of limited professional use?

How do you know that particular individual will have the required free brain cycles to learn just another language after discovering they can't use the first one in whatever they heck they want to do with their life? They might have plenty other things to learn or to do at the same time.

 

[heatlesssun]

Why would you recommend to a beginner to use a language of limited professional use?

The thing is C# isn't as nearly limited in professional use as you're trying to claim. There are plenty of well paying jobs using C# across a broad spectrum of industries and companies. You're simply refusing to acknowledge the truth.

 

[uOpt]

The thing is C# isn't as nearly limited in professional use as you're trying to claim. There are plenty of well paying jobs using C# across a broad spectrum of industries and companies. You're simply refusing to acknowledge the truth.

So there are for C++ and you don't limit yourself to windows shops. Same argument can be made for Java but of course Java sucks so you would want combat pay.

Plus there is an awful lot of windows-only programmers of some form or another.

While I'm not going to make statements about the relative size of the windows market today versus past it is clear to everybody that other markets are growing faster right now, namely mobile (java for android and a C derivative for IOS), javascript even server side (via node), javascript client side with all the new toys in html5, with canvas, svg, mobile opengl, local storage and all those other toys, shops that model themselves after google by just using whatever the apache project has for what they say is google-like technologies, general Unix server-side programming (usually C but also Python, not much C# there). Heck, even game development has made a drastic step toward things compatible with Unix just recently. And networking. All C. You gonna hack up the TCP/IP stack in OpenBSD with a C# background?

And you are recommending that *more* people squeeze into the limited windows market? Do you realize that isn't only bad for the new guy, it's also bad for everybody who's already in there?

I begin some people here are actually Linux hackers and want to keep the n00bs out

 

[heatlesssun]

And you are recommending that *more* people squeeze into the limited windows market? Do you realize that isn't only bad for the new guy, it's also bad for everybody who's already in there?

Again, the notion that the Windows market is "limited" is just nonsensical.