kruptof

even if they teach you c# i think your institute would have the course material (compilers) installed on their local machines,so you can work of there, and some like mine actually have different versions for students to download of their websites for free, this is properly due to some agreements or payouts to the vendor of the software.

way off topic:
I take it you don't do this for everything, well iam too poor aswell so i gues i should buy a ski mask($$ pm) and go and rob mr barclays, lol

__________________

Jimbo

Pegasus, since there are free alternatives, I have no sympathy for you. You may find that various other members will feel the same way. I refer you to this thread for a discussion we once had on the subject.

__________________
<insert disclaimer here>
<insert shameless plug for Visual Studio here>

Arla

Why should they? I like C#, I do use it for "play" work applications I need to write (applications that are for my own testing of work things) however in school/college I think it's far more important to learn the fundamentals of how to write good programs rather than any specific language, I learnt Pascal, C, Fortran, Prolog and Edinburgh ML (don't ask) in School/College, I never use any of them anymore, at work it's either Cobol, COOL:Gen or C#, home use it's all C#, but it doesn't matter, because I understand the basic concepts and have a good grasp of how to write programs the only REAL difference is what functions are available and syntax for basic statements.

Unless the language is very different from current languages like C# it really doesn't matter at all which of them you learn at College (at least that's my take).

Jimbo

As far as I see it, there's two ways to teach programming. One is a very hands-on approach, teaching a specific language and it's associated libraries. This won't necessarily leave you with a large skillset for anything outside of your honed skill but at least you'll have mastered the one. Another way to teach is to use a variety of languages focusing on different paradigms. This sort of curriculum would assume that you'll be able to pick up the syntactic nuances and libraries of a language somewhat trivially; in exchange, you'll be able to move from one environment to another with great ease, and as you do you'll gain experiences with specific languages as you go. I guess you could summarize it as "jack of all trades, master of [none, some]" depending on how much you experience you've gained. Personally, I prefer the second approach.

__________________
<insert disclaimer here>
<insert shameless plug for Visual Studio here>

pegasus001

Sometimes is better to know one perfectly than to know some at a low level.
I guess that you can use what you gained from both of them to be a good programmer. But power has its consequences. :p

PS. Thanx for the thread.

__________________
You never test the depth of a river with both feet.
The believer is happy. The doubter is wise.
Free speech carries with it some freedom to listen.
The next generation will always surpass the previous one. It`s one of the never ending cycles of life.

Arevos

I can't think of many situations where this would be the case. Knowing how to program well is more important than knowing the intricacies of an individual language. And the best way to learn about programming, in my opinion, is to be exposed to as many different programming languages and paradigms as possible.

pegasus001

But dont forget that high level languages are almost the same. So this means that the idea is the same. You have classes in c++/c#/java, which have the same method for accesing its member ie. private, protected, public(C# has some more), but the idea is the same.

When moving to another language all you need to get used to is the relatively new syntax and its library. Thats why some programmers find it difficult to programm in assembly because it is way different from high level programming, and thats why HLA was invented(i dont do assembly yet, but plan to).

Now a friend of mine learnt first paskal and then moved to c++. He loved the language. Than he left school and went to a small programming company and they there programmed in vb. So he found moving from c++ to vb somewhat easy, but needed sometimes studying the libraries.

It is true though that as many paradigms as possible is good for your programming part of the brain.

__________________
You never test the depth of a river with both feet.
The believer is happy. The doubter is wise.
Free speech carries with it some freedom to listen.
The next generation will always surpass the previous one. It`s one of the never ending cycles of life.

Arevos

Popular high level languages are almost all the same. However, there are many high level languages that have little in common with C# or Java.

For instance, if you were coming from C# and trying to learn Lisp, you'd probably understand the concept of functions (methods) and lambda forms (delegates), but I suspect syntactic macros would be a far more difficult idea to grasp, simply because there's nothing even close to them in C#.

Likewise, if you were going from Java to Haskell, you might, uh, well, I can't really think of many things that Java and Haskell have in common. Even things that seem the same, such as types and functions, act in very different ways. And that's not even covering the topics of function composition, lazy evaluation, monads or comprehensions.

There are high level languages that are as different from C#/Java as assembly is. Indeed, an assembly programmer may find it easier to switch to Java than a Java programmer would find switching to a more exotic high level language, like Haskell or Clean or Prolog. At least Java and assembly are both imperative.

Mad_guy

Not particularly. Moving from a HLL to another HLL that might be in a different paradigm, or even support different models of the same concept can be very different (ex: Erlang is a highly concurrent language; but there is no notion of 'threads' as a concept in the language. It is based on a different model of concurrency than others: the actor model. Haskell can use Software Transactional Memory for synchronization; you would probably be accustomed to 'locking' mechanisms such as semaphores or a mutex.) Declarative languages such as Haskell and Erlang require different ways of thinking about how to write your program as opposed to imperative ones such as C or Ruby.

In some cases, it can require a completely different way of thinking about how to write your program. Haskell racked my brain the first time I tried it several years ago (when I was still fairly novice.) After approaching it again just very recently, it has made much more sense due to my exposure to different styles and paradigms plus different ways of learning to think about writing a program, etc..

__________________
os: mac os 10.5.4
revision control: git
editor: emacs

site