OSDev.org

B.E wrote: @Schol-R-LEA:

Start off learning HTML markup before getting into an actual programming language; it is structured quite similarly to many programming languages, but is much easier to learn.

HTML has nothing to do with programming. Moreover, there is no flow control constructs of the language (except JavaScript, but it is a difference language).

That was actually the reason I recommended it - it has a structure similar to a programming language, with nested statements, attribute assignments, etc., but is static, and thus somewhat easier for a novice to understand. My idea was that one could get familiar with the idea of coding first before actually learning a programming language.

I suggest learning DOS because it gets you ready for ASM. Then learn JavaScript because it gets you ready for C. Then learn VB because it gets you use to API/GUI Design. Then learn C because it gets you used to having power. Then learn ASM because it gives you true power. Then learn PIC because it makes you leet. Then learn AI because you can make rad automatons. Then die because your life is complete.

I would say that doesn't make your life complete, as I've gone on beyond that point and grew up.

Do you have pics of your automaton or any robot you have made?

Omega wrote:I suggest learning DOS because it gets you ready for ASM. Then learn JavaScript because it gets you ready for C. Then learn VB because it gets you use to API/GUI Design. Then learn C because it gets you used to having power. Then learn ASM because it gives you true power. Then learn PIC because it makes you leet. Then learn AI because you can make rad automatons. Then die because your life is complete.

Note: Omega that in the future there be a program or assembly\compiler more powerful then today and this will be never ending.

How many people actually learnt via baby steps? (Learn HTML, learn Javascript, learn Bash scripting, learn Basic, learn C#, learn C..)

Let them jump straight into C (or C++).. I think it'll be much easier learning the language you want to learn, since there are a lot of tutorials out there for beginners. I found it much harder going from procedure programming to object oriented programming than if I jumped straight in to OOP.

Let them jump straight into C (or C++).. I think it'll be much easier learning the language you want to learn, since there are a lot of tutorials out there for beginners. I found it much harder going from procedure programming to object oriented programming than if I jumped straight in to OOP.

I'm becoming more and more tempted to say: "Learn Haskell First".

I think a scripting languages like JavaScript or Ruby is a great starting point to get into C/C++. I think there should be some sort of intermediate step as the 'diving right in' approach doesn't always work.

I learnt with HTML, BASIC or .bat first (can't remember), then JS, PHP and finally on to C before learning other langs (Perl, Pascal and others)

I also learned QBASIC first, then C++ , without a computer from a book . I did not have a computer at that point of time . I had to wait for nearly 2 years more to get hands on experience , then proceeded to learn Java,VB 6.0 , C# , Python,perl, Pascal , C ,x86 asm ( also PDP -11 , CRAY-1 , Mk 68000 , VAX , Power PC -- but do not rembember anything now , learned them for the exams ) , 8085 and interfacing as well . I can even create a language now if i want to [ ] .

Regards
Sandeep

I'm an advocate of jumping right in. Every day that I type "=" instead of "==", or type "then" at the end of my conditional statements is a day I regret learning visual basic. It didn't really teach me anything that other languages can't, and it would've saved me getting out of a lot of bad habits.

This is kind of getting off topic btw!

Advice to new programmers: The only question its appropriate to ask another programmer is: "What should I google to find X". Also www.projecteuler.net is awesomesauce for learning a new language.

At least for me, I think its best to start at the beginning with assembly and then go into procedural and then OOP. The reason is that I started with Java, but I was always so curious as to how things actually worked within the computer, which led me to C which let me understand things better, then finally to assembly, where I felt I finally "got" how programs work on the computer. Also, once I went back to C and then back to Java, I could really appreciate what they could do and what they are best for after I had some experience with the lower level languages.

yemista wrote:Also, once I went back to C and then back to Java, I could really appreciate what they could do and what they are best for after I had some experience with the lower level languages.

I certainly agree with you here. I myself started with C then a little bit of C++, then some Java experience and for some time C# also but when learned assembly realized how much complex things are at low level languages which one tends to neglect without the knowledge of assembly language. For me the way to learn should be first assembly then C and higher(..call me traditional is you may so... )


Cheers.

I started programming with TI BASIC (for the TI-83+) but never truly got into programming until I started z80 ASM (also for the TI-83+). Then I went to C++, and working with ASM definitely helped me grasp pointers. I actually learned C++ by working on the GBA. It was great, because anything you did with the graphics hardware was immediately visible, and getting everything set up was just a few lines of code. z80 ASM and GBA C++ are both what make me want to write an OS, because with both, you had complete control, and if you didn't want to deal with an annoying API, you didn't have to because the hardware was right there.

I wouldn't recommend it for a novice programmer though, as not everyone grasps logic with the ease I do (sometimes).

My advice for a novice programmer is this:

If you already have a grasp of the basics of your chosen language, make a game.
Otherwise, learn the basics of your chosen language, then see previous statement.

Well I'm new to these boards and don't have a kernel, OS, or anything to brag about, so with that caveat out of the way, here's my advice


I'm actually going to recommend the exact opposite of the OP. I think as a beginner you should decide what you want to do, pick your language based on that, and then learn it deeply.

The rationale for this is that once you learn something that deeply, the underlying design is more apparent to you than it is if you know it superficially. You'll see the good, the bad, and the why. Understanding the tradeoffs in the design of your language of choice will be invaluable for you, even if you're using other languages.

So generally, while abstractions and reuse are definitely good things, I would first write specific cases, and only when I see myself repeating the same pattern over and over again (sometimes twice is enough), I turn it into an abstraction instead.

quoted because it bears repeating.

Don't do something because it 'feels' right. The KISS principle. Lots of people quote it, few do it, and that's a shame.




Think about what you're doing.
Think about how you're doing it.

You wouldn't believe how much time I've seen people waste because they're afraid to waste time. If a script needs to be written to automate something write the damned script. If you find youself spending a lot of time maintaining documentation, project scheduling, etc, stop and think about how to lessen that.

You'll find youself more productive in the long run.

last but not least.

If you're building a system you've never built before, don't think about it, just build the damned thing. You're going to muck it up. You're going to do things you regret. That's what experience is, doing lots of crap you wish you hadn't.

It's more important to jump in, get your feet wet, and learn from the mistakes then it is to not make the mistakes.

And related to this, if you're not struggling, you're not really learning. Set your goals higher.