want to learn programming

[jamie01]

i want to learn programming,but dont know which language is easiest to learn.could anybody help

[mosquito]

I can recommend C# (c sharp), It's a new language heavily pushed by MS. If you want to program in C# you have to download the .NET framework SDK from Microsoft. If you want to learn a language that is platform independant, I suggest you learn java.

The easiest language to learn is Visual Basic, but I think it's a waste of time to learn Visual Basic because the language has been stretched beyond it's limits. Visual Basic 7 (based on the .NET engine) is available in beta, but it is completely different from Visual Basic 6. So you can better learn C# than VB.

here are some good links for C#
http://msdn.microsoft.com/net/
msdn.microsoft.com

[Edited by mosquito on 03-26-2001 at 03:25 AM]

[Paul Victorey]

I still prefer to always recommend C++. It is the most widely used language, and is very powerful, especially when you add GUI libraries like OWL to the mix.

My personal preference is to program in Borland C++ 5. OWL (Object Windows Library) makes programming a GUI *much* easier than using the traditional windows API. Borland 5's one drawback is its weak documentation and wierd help file system, but I've found there are more than enough net resources to help clear up the commands and messages that are badly documented.

I do program Java, but prefer C++ over it anyday. I'm still not too sure what to think about C#, it seems just to sit halfway between Java and C++. And as C++ alone is good enough for me, I'll probably stick with it.

[mosquito]

I would also recommend C++, but he asked for the "easiest" language, and C++ is definitely not easy.

[Paul Victorey]

I don't think C# is really easier... nor, really, is Java. They're just different. In fact, because of how Java does not support operator overriding, it is in some cases harder to use Java.

VB (Visual Basic) is probably the easiest language that is worthwhile learning. C++ is somewhat harder to learn, and requires that you use it properly, but once you get the hang of it it's not a difficult language to use.

If you do learn C++ I recommend getting a good book that focuses on object-oriented programming (OOP) -- any C++ programmer should know about classes, objects, polymorphism, and how to use them. A book specific to your compiler is also very helpful -- a Borland C++ book will talk a lot about Object Windows, which is essential to easy GUI construction in BC++.

Finally, any compiler worth its salt will have example projects -- these can be VERY helpful in learning good ways to program. I've learned any number of things by browsing example programs and taking note when I see a particularly clever or unusual way of doing things.

[mosquito]

I stand corrected. I agree that C# is not easier if you want to master it completely. But it is easier to get started with. But I think that when you start learning a programming language you should focus on console applications. I experience that when I write console applications the code is always better than when I write GUI applications. (I don't know if everybody has this, but I certainly do)

[mosquito]

My experience is also that once you know C++ you can master all other languages very easy.

[Paul Victorey]

It's because console and GUI are two totally different beasts. Most people learn console programming an have difficult transitions to GUI. I know I sure did, but I've got the hand of event-driven programming now.

The whole GUI paradigm is different. The idea of console programming is something like this:

Program starts -> step A -> step B -> ... -> end

It's a linear sequence of instructions. By contrast, most GUI programs will do NOTHING most of the time (most console programs wait in loops of their own creation, in windows, the operating system has event loops but the programs themselves don't)

Instead, you handle messages. When your program starts, there is the initialization stuff, but once it's done, NONE of your code is executing. It is only when the user does something, like clicks a control, or changes the text of some window, that any of your code is executed at all. When an event happens, the message is either processed by a default message processing function, or by your function, if you chose to receive this message.

Once you get the hang of the fact that messages, not function calls, are the predominant means of flow control, you can write some very clean stuff. I'm only now going through some of my programs and tweaking them, cleaning them up, etc. For example, I can make custom messages, and instead of each class' member functions needing pointers to other objects to call frequently used functions, I can use a custom message, sent to the main window of the app, and have the return value be a pointer to whatever kind of object I'm interested in.

[mosquito]

Indeed, messaging is the key to GUI programming. But unfortunately (due to the constantly changing user requirements) I keep ending up with messier code. I could clean up and organise the code very easy, but this task would not add any features and therefore I cannot justify this work to the product managers .
And now I just started a web centered project which is again a completely different story (but very interesting) and where message queueing is key.

[UncaDanno]

While organizing your code may not add features to the product, you could remind the product manager that it WOULD make the code more extensible and maintainable so adding features in the future or fixing bugs (heresy!) would not mean tearing down and rebuilding a substantial part of the house just to change a light fixture. Or having to dig through all the code just to find the spot where the bug needs to be exterminated or the hook inserted for the new/extended feature.
Organized code can reduce development costs substantially in the long run. Of course, that depends upon the product manager even being interested in "the long run"....

[mosquito]

The product managers always agree with all my arguments until the moment to assign the resources has come. And then they back out because of the cost. And like almost all product managers they only think short term.