How did you learn to program

[Adropac2]

Wish i had more time to learn programming.I think i have the basic understanding of how it works and have even written a snake program using c64 basic (wow) , but when your working on other stuff that takes just as much effort as programming clearly does , then it doesn't really leave you much time.I'd love it to be a hobby but that wouldn't make any money coming my way.I get quite envious of you programmers , it must surely rank as one of the coolest jobs on the planet.

[sarek2k]

@Snyp OO would that be object orientation??? And @ant152 i did think of hierarchical chain/tree etc but since i couldnt spell it i didn't say it also i thought of a tree as in dos tree etc i suppose nesting could be another name! That would be under Ray Norrish's Hedge approach

It's all quite obvious really think of the world cup currently about to start and how that is also a tree of which branches will be removed and how they will get fewer in number as the tournament goes on and how variables will break some of those branches off via an injury or from some other unknown quantity like a bent ref lol

Or Englands fave Penaltys

[musashi5150]

Originally Posted by Adropac2

it must surely rank as one of the coolest jobs on the planet.

It depends what you are programming I suppose. My job sucks ass

[ant512]

Originally Posted by musashi5150

It depends what you are programming I suppose. My job sucks ass

Mine's not great but it sure does pay well.

What distresses me most is programmers who don't know the basics of computer science. Data structures like trees are just one example of this. You can throw in linked lists, skip lists, search routines (bubble/quick/shear/etc), bitmasks, bitshifting... I went out of my way to learn all this stuff when it became apparent that I was constantly re-inventing the wheel every time I tried to write something complex (re-inventions include RLE, dictionary-based compression and trees).

Perhaps even more distressing than that are programmers who claim not to need to know any of this stuff. I've been told by a programmer that he didn't need to use classes in VBScript (ASP) because he couldn't see how they were relevant to his work. Every time he had a new website to build he started from scratch. I used classes instead, and gradually built up a whole library of frequently-used classes. He'd spend weeks coding, I'd just bolt classes together.

Bitmasks are another one. I use them all the time, but most programmers I talk to have no idea how the AND and OR operators work. I use them in SQL scripts too, and have encountered programmers who thought it was impossible to bitshift or use bitmasks in SQL. Imagine you want to store the opening days for a shop, for example. You could either have a table with seven rows for each shop, each row representing a day of the week, containing a single bit field (1 for open, 0 for closed), or you could have one row for the shop and store the open days as a bitmask converted to a decimal. The bitmask requires less storage space and considerably less code to process.

With VB.NET on the scene, I imagine that we'll have a whole subset of programmers whose only talent is to hunt through the IDE's intellisense to find the command they think they need. But what if System.Diagnostics.DoMyWorkForMe isn't a valid method?

[HCF]

To answer the original question, I was lucky to have experienced programmers as friends.

And with regard to the tree design, it might be a tree on paper but that does not mean that the different structures interact the same way. Recursion is another one of those "bad" things, especially if you have large amounts of data and a stack overflow can affect stability (yet, it is still popular in schools).
What I'd suggest is to completely rewrite the software since the more complexity is added the more chance for bugs there is.
In addition, C++ is more difficult to use, understand and maintain than any other language I know of (Java MIGHT be the exception). C is easier to work with (and more efficient) and has even the additional benefit that competent programmers are easier to come by.

[ant512]

Originally Posted by HCF

And with regard to the tree design, it might be a tree on paper but that does not mean that the different structures interact the same way. Recursion is another one of those "bad" things, especially if you have large amounts of data and a stack overflow can affect stability (yet, it is still popular in schools).

There isn't enough data in the tree to cause a stack overflow - the tree will never grow to more than 2 levels in depth due to the technical constraints of other systems on which mine is dependent. The tree structure is perfect - it provides me with a single entry point and unified interface to the most important data structure within the whole system. At the moment, I have three entry points, and once inside the structure I have to do a lot of jiggery-pokery to get at the objects I want to work with. The structure isn't self-maintaining and is a real pain to work with. Refactoring it into a tree will solve all of the problems.

Even if I wasn't going to use a tree, I'd still want a single entry point and a decent interface to the structure.

C++ isn't an option. The system was written in VB.NET, and there's no way the company will consider abandoning the work that's gone into it so far. If IT was a horse, my company would ride the horse at a gallop until it collapsed and died, at which point they'd pick the horse up and carry it. They wouldn't consider slowing down, and they certainly wouldn't consider replacing the horse. My current plan is to slowly build a car beneath the horse, then whip the horse off and *tada!* a system that works.

[FromWithin]

What's the obsession with trees? If you'd drawn that diagram for me, I wouldn't have had a clue what on earth you were getting at. I wouldn't have said the word "tree". Why? Because you'd just drawn one! Of course it's a tree! Look at it! I'd feel like you were patronising me. It's not that I have no knowledge of data structures, just that the answer is so ridiculously fundamental, I wouldn't expect you to ask something like that. Maybe it's just me.

Originally Posted by HCF

In addition, C++ is more difficult to use, understand and maintain than any other language I know of (Java MIGHT be the exception). C is easier to work with (and more efficient) and has even the additional benefit that competent programmers are easier to come by.

Wow, there's a whole load of misinformation, if I ever I saw it! I beg to differ greatly. It looks like you are from a C background, and have never made the full jump to C++. C is not more efficient than C++. I didn't think anyone subscribed to that idea anymore. It only came about because of the inefficiency of early C++ compilers. C++ is far easier to maintain than C when your code is packaged into classes instead of huge lists of functions, and the code is far more readable thanks to references, operator overloading, and all that. If you know what you're doing, or just learn from someone who does, it's far easier to write bug-free code in C++. The lack of type-safety in C is shocking, and for new programmers is the road to bugland. If you let it do it's thing, the compiler will catch a whole load of errors for you.

I would never recommend that anyone learn C instead of C++. C++ is easy to learn when you don't have the noose and bad habits of C knowledge around your neck.

[spiff]

Well.. I can't say I'm good at it, but most of what I know that's not script/google look-up is from Programming abstractions in C By roberts 2nd course. I got most of knowledge about background stuff there which is everyday now; stacks, queue, hashtable, sorting complexity and so on...

After that I just mostly do Java or C# stuff both have a structure/syntax that reminds me of C (never was a fan of basic) but a lot less hassle with memory management.

[HCF]

Don't know if this is still true but last I checked C programs compiled under both Borland and Microsoft C compilers were running faster. If you look at the run-time library source (back in the day, ok, it might be different now), you would see how much more complicated the startup/initialization routine was (for the beloved >> for example).
Never made the jump because there never was a need for it. There is nothing that can be done in C++, that cannot be done (most times better) in C.
The reason why people feel C++ classes are so much better is because programming style has improved and nowadays more planning goes into a project. C programs can be just as easily structured as well as the data stored.
Operator overloading is BTW a major problem with C++ since the smart programmer can overload anything causing big confusion when reading the source.
And Borland and Microsoft compilers catch invalid type assignments (it is displayed as a warning since it can be intentional though it is good style to typecast eliminating any issues, surprised ? ).
Not sure how you came to believe C++ is superior to C but I fear it is what most people believe.

Spiff, the best C reference is "The C Programming Language" (ISBN 0-13-110362-8) by Kernighan and Ritchie. It is a small book that pretty much contains the fundamentals.

[FromWithin]

Originally Posted by HCF

you would see how much more complicated the startup/initialization routine was (for the beloved >> for example).

Yes, using streams instead of stdio uses more complicated code - that you don't see, and shouldn't care about, and is far less prone to security issues. It makes the user's code much, much more easy to read. And startup/initialization is totally irrelevant. An extra 5ms while the program loads is not the end of the world. In a real world environment, good quality, readable code outweighs everything. The biggest speed changes come from design, not from semantics (unless your entire program consists of very tight loops, and if it does, that's probably a design flaw in itself), and in a commercial environment, cryptic code will cost the company far more in the long run when the time necessary to find and fix bugs is increased, or the programmer who wrote it is no longer available.

The reason why people feel C++ classes are so much better is because programming style has improved and nowadays more planning goes into a project. C programs can be just as easily structured as well as the data stored.

Bullshine. C++ classes are so much better because they enable simplicity, readability, greater flexibility, re-usable code, and more robust code. C programs can not be just as easily structured. To gain the same functionality as C++, you have to add lots of extra code, and extra code means greater potential for errors and makes it much more difficult to maintain.

Operator overloading is BTW a major problem with C++ since the smart programmer can overload anything causing big confusion when reading the source.

I think you're confusing the word "smart" with "stupid". The whole point of operator overloading is to make the source easier to read. People don't just put it in for a laugh. It's not a "major problem". I think you're just clutching at straws because you don't have enough experience in C++ to make a good judgment.

And Borland and Microsoft compilers catch invalid type assignments (it is displayed as a warning since it can be intentional though it is good style to typecast eliminating any issues, surprised ? ).

Yes, it's a warning, because yes it can be intentional and sometimes entirely necessary. But it also flags up many potential errors of truncation and incorrect addressing. Which is why C++ casting is so much more verbose; you should only be casting if you really need to because any casting has great potential for errors and security holes. It also enables easy searching for casts in the source (as bad casts can cause widespread errors), and provides a specific explanation of what the cast is for. For example, a reinterpret_cast is for pointers, whereas a static_cast is for data, a const_cast between const and non-const data, and dynamic_cast for extra compile-time and run-time type checking, should you be able to afford the overhead. For some types of casting, it simply won't allow it. It's totally unlike C-style casts where you can easily cast pretty much anything to anything else, and it gets lost in the code once it's there.

Never made the jump because there never was a need for it. There is nothing that can be done in C++, that cannot be done (most times better) in C.

Utter, utter nonsense. Define "better". There's nothing than can be done in C++ that can't be done in machine code. After all, that's what it compiles to. It's not about what can be done, but how it's done. If you can get the job done, and write reasonable code in C, then great. But you have no basis on which to go slagging off C++, because it's quite apparent that you know not of what you speak.

Not sure how you came to believe C++ is superior to C but I fear it is what most people believe.

Through experience.

[ant512]

Originally Posted by FromWithin

What's the obsession with trees? If you'd drawn that diagram for me, I wouldn't have had a clue what on earth you were getting at. I wouldn't have said the word "tree". Why? Because you'd just drawn one! Of course it's a tree! Look at it! I'd feel like you were patronising me. It's not that I have no knowledge of data structures, just that the answer is so ridiculously fundamental, I wouldn't expect you to ask something like that. Maybe it's just me.

Exactly right. If I'd asked you how you'd have modelled it in an OO language, you'd have told me that you'd use a single class to represent the entire structure, ie. a tree. Bingo! It's a simple question. You get the job.

Instead, the candidates I interviewed told me they'd use three classes, one for each level of the structure. So what happens when you need new levels? New classes. And how do you store this in the database? Three tables. New levels to the structure? New tables.

There's no obsession with trees - I'm looking for decent programmers that know the basic principles. The tree just happens to have been relevant to the project that the programmer would be working on.

How can something so ridiculously fundamental be so completely outside of the knowledge of three people with such lengthy development experience?

[FromWithin]

Originally Posted by ant512

Exactly right. If I'd asked you how you'd have modelled it in an OO language, you'd have told me that you'd use a single class to represent the entire structure, ie. a tree. Bingo! It's a simple question. You get the job.

If i just had the diagram and nothing else, I would have said three classes, one for each level, as that is the best way to represent that specific diagram. However, you did state that you explained that the depth of the hierarchy could be n, in which case I would, as you said, have suggested a single recursive class. A tree.

So maybe they didn't hear the part about n. Or something.

[HCF]

First off, I worked with embedded systems and every byte can count when you need to squeeze things in. Performance is also affected because the more inefficient code is linked (I know, printf isn't THAT much better...)

Ok, so streams offer less security issues ? I remember when I was playing with a C++ compiler, I used << to get keyboard input and not sure what I pressed (while back) but the program crashed (was Borland I believe). So much for reliability or security (I think I just hit enter or something).
Whether you write in C or C++ you will not use standard input functions simply because a good programmer checks before storing the value.

Again, I agree cryptic code is not a good thing. It can be required for speed-relevant tasks though I usually link them as assembler sub-routines.
Documentation is everything and a "good" program should be understood by everybody and not win some obfuscated C code prize...lol

Now you keep saying that I am wrong and classes are so great. What extra code do you feel you have to add to gain the same benefits ?
And yes, but operator overloading can be an issue if you have different operations for the operator and trying to find out what is going on right now in a program. But of course that is just my opinion and I am sure I could get used to it if I had to. Not the last straw for me but why don't we discuss an example so you could show me what I could gain by using classes that can only be done with very complicated routines in C ?!

Next point:
Type-casting allows easier operations. A byte, a char and a short int (on 16 BIT) are all the same size, 8 BIT. I can either do it very complicated by creating a union (or whatever C++ would do) or I can type-cast.
It is more flexible to accomodate any type into memory. If I had a structure that can contain any type of information, this would be an easy way to go (ok, lame example but it is kinda early here..lol).

And last but not least, better defines the time it takes to write and test the software as well as the time it takes to perform the task. Assembly language CAN be more efficient but only if the programmer knows what he or she is doing. Bad assembler coding can cause performance decreases compared to a C equivalent. Furthermore, assembler code takes longer to develop (but you know all this).

And yes, OO languages call for separation and isolating tasks. That's why many programs are twice as long, the definitions take up so much room and ant512 isn't even happy...

[BippyM]

and you have all gone completely off-topic!

[ant512]

Originally Posted by bippym

and you have all gone completely off-topic!

That's true, but it is vaguely relevant in a real-world coding kind of way. To get things back on topic, I started coding in BASIC on a Dragon 32 via trial-and-error. I switched to coding Speccy BASIC via trial-and-error (and the manual), then AMOS, then Blitz (with a manual). From there, I played with (to varying degrees) E, AREXX, LOGO, RM-BASIC, QBASIC, C, C++, Java, VBScript, Modula-II, VB, PHP, SQL, VB.NET, C#.NET, and I'm currently trying to learn 68K asm. I've coded for the Spectrum, Dragon, PC, Mac, Amiga, Cybiko, GBA, C64 and GP32, and the Java and Flash VMs.

For a very long time I was an abysmal coder, mainly because everything I did was trial-and-error. I had difficulty getting hold of any books about programming at all, and the ones I did get didn't make any sense. It's only in the past half a dozen years or so that I've graduated from "abysmal" to "bad", simply because I can research on the internet now.

I'm firmly of the opinion that writing games gives you the best grounding in coding. If you start out writing business applications in VB you'll learn bad habits. If you start out writing tight code for ambitious games on underpowered hardware, you'll learn better techniques. Writing apps is a very different experience to writing games, though, so you won't be able to jump from one to the other immediately. Games demand fast code; apps demand readable code. However, I'm certain that the average game coder will be able to adapt to app programming faster than the average app coder could adapt to writing games.

[musashi5150]

Originally Posted by ant512

However, I'm certain that the average game coder will be able to adapt to app programming faster than the average app coder could adapt to writing games.

Here here!

[Calgor]

@ant512

What distresses me most is programmers who don't know the basics of computer science.

This too distresses me, unless you are a gun ASM coder! The knowledge of all those concepts of trees, BSTs, linked lists, information hiding, module coupling etc are good to have when designing, but most important when working with a larger development team or writing code to be taken over by someone else with minimal hand holding.

I give my vote to C over C++, only cos I don't know C++ that well, but do realise that you have to be careful in C, b/c it does not enforce those information hiding and interdependency/module coupling concepts due to no default concept of classes/objects - you are free to make good or bad design as you wish! And the more talented programmers probably don't need to follow any of the concepts/rules to make their programs work without bugs.
Not saying I am great, but probably the ppl in this thread are better than the average at work.

Back on topic, I first learned C on the humble old A1000 Lattice C compiler K/S 1.1, from a Waite Group C Primer Plus textbook. Good read with nice cartoons Guess that fun to read book and the Amiga 1000 combo eventually made me make a living from software engineering. Had to write my own custom boot floppy to copy the whole disks and include libraries into RAD: to speed up the compiling! Back in those days I guess the 80286 was better at compiling...... but I have never coded C on a PC so wouldn't know. Only use Unix.

Never learned ASM, since they didnt use it at school/uni/work, but have always wanted to just so I could do cool things on my Amiga. Which is why it is great bippym is driving that!

[FromWithin]

Originally Posted by HCF

First off, I worked with embedded systems and every byte can count when you need to squeeze things in. Performance is also affected because the more inefficient code is linked (I know, printf isn't THAT much better...)

Well that's an important caveat that you failed to mention. For embedded/small footprint systems, the closer to assembler you can get, the better. I understand your performance considerations for something like that. However the issues surrounding type-safety still stand, and C++ is not inefficient. Only poor implementations are. For every instance of C producing faster code than C++, there is another instance of C code compiled with a C++ compiler running faster than with from the C compiler.

Ok, so streams offer less security issues ? I remember when I was playing with a C++ compiler, I used << to get keyboard input and not sure what I pressed (while back) but the program crashed (was Borland I believe). So much for reliability or security (I think I just hit enter or something).
Whether you write in C or C++ you will not use standard input functions simply because a good programmer checks before storing the value.

Once again, you are basing your assumption on an old compiler, or maybe Borland's implementation of the standard library was just poor. I should have not restricted my reply to streams really, as the security is only relevant when related to the rest of the standard library. For example, a cin streamed to a std::string is far more secure than a scanf to a char array. There is far less chance for error. Of course, a good C programmer can write a correct implementation, but this is a large part of my point about C++ being better than C. In C++ you don't need to worry about that sort of thing, which means less code, which means less errors.

Now you keep saying that I am wrong and classes are so great. What extra code do you feel you have to add to gain the same benefits? And yes, but operator overloading can be an issue if you have different operations for the operator and trying to find out what is going on right now in a program. But of course that is just my opinion and I am sure I could get used to it if I had to. Not the last straw for me but why don't we discuss an example so you could show me what I could gain by using classes that can only be done with very complicated routines in C ?!

It doesn't have to be a case of very complicated routines in C. Any extra code that you have to write in C over what you would need in C++ is a bad thing. Especially because C is not a strongly-typed language. Anything that requires C++-like functionality would require extra code. For example, to replicate inheritance you would need a jump table. You'd have to write the jump table code, which means more data, more code, more potential errors. If you are replicating a lot of C++ functionality, that's whole lot of extra code.

Type-casting allows easier operations. A byte, a char and a short int (on 16 BIT) are all the same size, 8 BIT. I can either do it very complicated by creating a union (or whatever C++ would do) or I can type-cast.
It is more flexible to accomodate any type into memory. If I had a structure that can contain any type of information, this would be an easy way to go (ok, lame example but it is kinda early here..lol).

As I mentioned before, in certain instances this is entirely necessary. It's the sort of thing I occasionally do for audio streams. But I know what I'm doing, and the C++ compiler knows that I know what I'm doing because I have to be very explicit about it. Casts are explicitly defined, and unions are made more difficult to use. A C compiler would let you do whatever you like. I greatly frown upon a structure that can contain any type of information. That sounds like bad practice to me. It might a quick and easy way to do something, but bad practice, neverthless. But that's because I have a strongly-typed mentality.

And last but not least, better defines the time it takes to write and test the software as well as the time it takes to perform the task. Assembly language CAN be more efficient but only if the programmer knows what he or she is doing. Bad assembler coding can cause performance decreases compared to a C equivalent. Furthermore, assembler code takes longer to develop (but you know all this).

In this answer, it strikes me that you are a lone programmer (feel free to correct me if I'm wrong on this). You work on projects alone, and rarely consider any external factors in what you are doing. So you have the luxury of basically doing whatever you like. Your code and design can be as weird as you like because nobody else ever has to look at it. Why use C++ when you are happy with C and produce working products? Have you ever worked on a single large project with multiple programmers? If you had, and you'd used C++, you would see the benefits of C++ a lot more clearly. In C++, you generally worry more about architecture than specifics, and only when the architecture is correct should you then optimize the specifics.

[Galahad/FLT]

For embedded systems, I cannot logically think why anyone would ever go down the high level language route. ASM every time for such space critical components as embedded.

[HCF]

All new compilers call themselves C++ compilers. I do not believe that there is a dedicated C compiler still being developed. Speed is always important and should not be neglected. Granted, crappy Visual BASIC code runs fine since computers are powerful enough to camouflage bad coding. But, I have seen "serious" VB software that was written inefficiently, stealing code and the programmer not understanding why he was doing something.

The compiler I was referring to was Borland C++ for Windows, not exactly the newest version anymore but not the oldest either. It also doesn't take that much effort to check input in C. With Windows handling most of the I/O, it can be difficult to do either way...

Next point, the C++ functionality. Well, maybe not everything has to be done the way C++ does it and it can still be as effective ?!
Why would you need a jump table though ? You don't need a jump table, just a function pointer for the object to inherit.

And the type casting is not really a bad thing at all. You just have to realize why C is so tolerant and just because you can doesn't mean you have to. And a generic buffer is a good example. You can use the buffer for keyboard input, disk I/O...etc

Yes and no. I did/do both, programming alone and in a team. Like I said before, it is very important for the code to be readable. Also worked on planning some projects, funny how you'd tell me how to structurize...
And the reason why not everything is done in assembler is because maintenance costs are lower for C and if the programmer is not good at it, the code can be worse and harder to debug.