Topic: Programming

I guess I should make a thread for over-all programming. In the Petit Computer forums, a lot of people are talking about generic programming, and I'm afraid that descends into off-topic. So let's talk code everyone!
^_^

Special message to all new coders:

1. Manage your memory! This should be rule number one, and it's one that has been forgotten because our newer computers have massive memory so pointers and objects remain unchecked. People hate using Java apps, and wrongfully think Java is to blame, it's not, it's the coders. You can't create a million objects that live for a second and expect even the top of the line computer to run the app well. No other language fairs much better in that regard, but coders for many other languages are more likely to consider such things.

2. Test, test, and test again! Compilers cannot catch all errors, actually compilers can only catch syntax errors accurately. Reading through large batches of code may be annoying, but do it anyway. Every time you compile, test the program. If it's an interpreted language it's easier to test. This whole "let the user test it for us" is killing people's confidence in computers.

3. Don't expect other coders to like your methods, don't change for anyone else. If your code style works well, don't listen to the people who scream that their style is better, it's not. Actually, many common practices, often taught in schools now, result in really bad code. It would be better to have a million different styles of code and apps so the user can pick and choose which works best for them, than have everything broken because everyone is doing it the same broken way.

That's all I have to offer at this time. I am experienced in c/c++, Java, Python, PHP, MySQL, HTML (a small amount of HTML5), and really old ASM. So I will frequent this thread.

I've only recently run into this! The game I'm currently working on generates a temporary graphic on the pause menu, and generates several temporary files for accessing certain values while the game is running; I have to make sure that they all get deleted when they're supposed to.

in my programming class the rule number one is "no one uses goto nowadays, only broken programs use goto!" maybe because it's limited to C or because there's that guy who insists in asking for a class about goto every day.....

Manage your memory! This should be rule number one, and it's one that has been forgotten because our newer computers have massive memory so pointers and objects remain unchecked

hear hear! Hell hath no fury like a dangling pointer. And it's just sloppy programming not to check things... never assume!

Goto is a VERY important command! Ignore that any day!

@0Games really? it is said in my college goto is an archaic function that was dropped a long time ago... maybe that is only valid to engineers...

Goto by itself has been replaced with repeating event calls, but IF..GOTO lives on, under the guise of other words, but functionally the same.

1. Just allocate all memory in Initialization. Done. Deallocate when the program ends. No problem.
2. I hope you meant automated testing, instead of manual testing. But then you should be using the phrase "comprehensive test cases".
3. You're an OO programmer, aren't you? There's plenty of other programming languages that do not conform to OO paradigm. Why don't you check them out?

If you want to exchange FCs then contact me, so I can make sure to add you as well

I have your FC already. Probably from the other thread. Let me know if I should take it out.

Actually, with OOP now, the "goto" commands do break things, and ruin readability. However it is a necessity in ASM, it just doesn't look like "goto" anymore. We now call these "loops," and include everything from "if-then-else" to "for-each" and in between. Basically, the name of it has changed but it is still there. Likely the "goto" they are talking about are the old c goto commands, that were used prior to OOP, I forgot what they were exactly, but they were necessary at the time.

Yes, I do prefer the OOP style, myself, as I said though, if everyone follows the exact same style then what's broken will never be fixed. Your point 1 only works in some situations, computers are now dynamic, and that is what makes them as powerful as they are today and allows them to do more than older generations. My first computer was a TRS-80 COCO II, I bought it new from Radio Shack, saved up my allowance for months to afford it. Back then you had little to no memory to work with, and thus you simulated dynamic memory at the cost of reduced functionality in the program. If you allocate all available memory for one thing on a computer, you destroy the entire benefit of multithreaded operating systems, reducing them to old MS-DOS standards. If you cannot learn to manage dynamic memory, then computer programming is not something you should consider being a part of, stick with game consoles and ROMs.

Nothing wrong with manual testing, actually, manual testing has the benefit of discovering more flaws in the program, there are many games that could seriously benefit from more manual testing. It catches glitches that are not actual program errors, as well as flaws in the design and interface, which automated testing cannot even understand. So yes, I mean manual testing, it's the dependence on automated testing that forces the users to become the software testers as well, which is unfair to the user, especially if they paid for the program.

Oddly, I find this part of programming to be the most enjoyable, probably because the other aspects bore me. Trying to figure out how to work within the most common computer stats in use, while managing large amounts of temporary data, and then remembering to release it all to the system when finished, a puzzle that just steals my attention. I use to work on systems where you had so many restrictions, compared to today's standards, that even one forgotten pointer could destroy the entire program. I have seen a lot of modern libraries and programs that will allocate a temporary object within a loop, then call that loop several hundred times per second, even if that object is deleted at the end of the loop, the memory is not recycled immediately and thus it can kill the program on a lot of computers, but not all computers will be effected by that, just the most common ones in operation.

Rule of thumb, develop for computers that are about 10 years old, because it takes about that long before the majority of users will have anything newer. It also forces you to consider memory management and do a better job of it.

That's actually a very valid and important point. Good for you to point it out.

ramstrong wrote:

1. Just allocate all memory in Initialization. Done. Deallocate when the program ends. No problem.
2. I hope you meant automated testing, instead of manual testing. But then you should be using the phrase "comprehensive test cases".
3. You're an OO programmer, aren't you? There's plenty of other programming languages that do not conform to OO paradigm. Why don't you check them out?

Yes, I do prefer the OOP style, myself, as I said though, if everyone follows the exact same style then what's broken will never be fixed. Your point 1 only works in some situations, computers are now dynamic, and that is what makes them as powerful as they are today and allows them to do more than older generations. My first computer was a TRS-80 COCO II, I bought it new from Radio Shack, saved up my allowance for months to afford it. Back then you had little to no memory to work with, and thus you simulated dynamic memory at the cost of reduced functionality in the program. If you allocate all available memory for one thing on a computer, you destroy the entire benefit of multithreaded operating systems, reducing them to old MS-DOS standards. If you cannot learn to manage dynamic memory, then computer programming is not something you should consider being a part of, stick with game consoles and ROMs.

Well, I just picked up bash scripting, and there's no OOP there, I can tell you.
Computers are not dynamic. OS is dynamic. I have always been suspicious about dynamic memory allocation. There are languages where that is done automatically. All OO languages, certainly. Scheme/Lisp does it too. What I do, is allocate the memory in the beginning of the program, then manage that memory myself, explicitly. It's not for everybody, but it's very solid, multi-threaded or no, regardless of language. I have had bad experience in depending upon OS for stability, so I speak from experience here.

Not a fair criticism claiming I shouldn't program on PC, when I do more than normal PC programmers. That's like saying I shouldn't use C++ when I manage recursion explicitly, instead of implicitly.

Nothing wrong with manual testing, actually, manual testing has the benefit of discovering more flaws in the program, there are many games that could seriously benefit from more manual testing. It catches glitches that are not actual program errors, as well as flaws in the design and interface, which automated testing cannot even understand. So yes, I mean manual testing, it's the dependence on automated testing that forces the users to become the software testers as well, which is unfair to the user, especially if they paid for the program.

That's the difference between white box/black box testing methodologies. If indeed manual testing discover more flaws in the program than automated, then obviously the automated testing technique is flawed. You need better coders.

That's probably the result of programmers depending on tools/platform to do their job for them. Pretty common, actually.

Obviously automated testing cannot catch bad design, but you shouldn't start programming without having good design in the first place. It's just good design principles to do a design run-through without implementing any technical consideration.

Let's consider an example, and this is not even one as extreme as a game would be, Blender. Without dynamic memory management, Blender would be unusable beyond simple polygon models, and the limitations on vertice count would render it useless, if all the memory was pre-allocated to suite the average computer. It would render the entire program useless, because for complex scenes there is literally no way to predetermine the amount of memory required for anything.

Bash scripting is not intended for full scale programs, it's akin to a more versatile BAT system, though originally it was exclusive to *nix OSes. I am not saying depend on the OS for stability, quite the opposite, managing your memory allocation and deallocation is doing precisely the opposite of that, OOP reduces a lot of redundant code as well, thus why it's now the standard. Nay-say as you want, but OOP is the way of the future, and the next generation of electronics will likely require it, transistor technology is advancing almost to it's ceiling point.

As for testing, there are actions and events the user will do which cannot be anticipated by any one program, and that is what would be required for an automated testing, which means that the testing app would replace the need for user, we simply cannot do that yet as it would require an advanced AI that can imitate user needs and wants. The most common break in any program is, ironically, the interface. Just because there is no segfault, does not mean there are no glaring problems with the program. Often these are called glitches in games, usually they don't break the game, but no automated test program could ever hope to discover these glitches, ever. The automated testing is inherently flawed, basically, though getting better programmers will never correct that.

The reason I state you should consider programming for consoles instead of computers is because, as I pointed out, computer technology depends on dynamic memory now. It's a standard that allows for more capable and versatile programs. Nothing wrong with programming consoles instead, actually, we need more console programmers. Consoles have a set memory amount, the best ones do at least, and thus you have to pre-allocate everything anyway, and cartridge programs demand this even more so. Don't be so hasty as to assume I was meaning it to be insulting, it's just two different types of systems, like apples and oranges, both are fruits, but you eat them both in different ways.

I hate to keep revisiting your possible anti-OOP stance, however, it's really important that new programmers realize old school coders like me are dinosaurs. Honestly, I feel more comfortable with pure ASM, I can code pure ASM better, more readable, and with fewer errors than even my code in Java. I have come to accept my being obsolete a long time ago, my only position in technology now is offering advice based on personal experiences and decades of study because I cannot shake the drive to return to ASM techniques. Even console programming uses OOP compilers now, though you can get away with only ASM techniques because of the memory system being less dynamic. Yeah, change can suck, it can be scary, it can even make you feel useless at times, but you cannot stop it, and it always produces a better tomorrow.

GOTO lives on in SmileBASIC. We would know. (Yep, Petit Computer reference.)
I'm learning C++! Yay! I even found a PDF that I can read, and I've already started reading it!
That isn't sarcasm if it looks like it. Anyway, does Visual C++ use normal C++ or it's own modified version? In that case if it's C++ then I should use CodeBlocks...

yep it's old C programming(the first year in computer engineering in my college the programming classes are only about C)

[quote=ramstrong]

Well, it came across that way because you're assuming the worst case scenario. Obviously, I'm not taking ALL available memory. The program itself takes a certain nominal amount. The data can take as much as they want. Yes, that means loading data involves dynamic memory allocation. But the program itself does not depend on free system memory being available on demand.

I think you're confusing design and programming. Even user interface requires automated testing. No human will randomly click/drag buttons all across the screen. An automated testing would. Testing for robustness requires comprehensive action, and that can only be achieved with automated ones. As far as aesthetics are concerned, of course you need human judgement. But I consider that design issues, not programming issues.

I'm not anti OOP. I just don't see the value in it. It's an alternative form of programming, but most computer programs don't need it. I don't see why you can't shake off being an ASM programmer. If you're really good, you can take the abstract view of program design, and do that. Whenever I design my program, I always see it down to underlying hardware, so I don't see a problem with being ASM programmer. It's the inability to see the whole design-implementation continuum that is a problem. And if you work at it, you should be able to master it, eventually.

I'm going Raspberry Pi route. That's hardware. I'm a software guy doing hardware. Why? Because I'm always learning new things. That's a must. You should too. Don't accept being dinosaur. Keep pushing!

As a long-time programmer I have to jump in here...

In my 30+ years of programming experience, manual unit testing of the low-level modules (especially error handling) is essential to creating high-quality code and will uncover problems that will never be found with "black-box" functional testing. It's also the most boring part of programming. Nevertheless, I can't emphasize strongly enough how essential this is, and it's true in any language, OO or otherwise.

Also, while they may have an occasional place in programming, use of "GOTO" statements usually make it impossible to understand program flow, let alone to test all possible conditions. Loops or if-then-else conditionals are not GOTO statements and do not create these difficulties.

When you do your testing, do you input random numbers into the parameters? Yes, it's boring. It's also necessary. So that's the value of automated testing. Let the computer do the boring stuff for you!

I even went so far as taking the floppy out of the drive, scratch it at the appropriate place with a pin, and put it back in. The program hung. That kind of test can only be done manually, so manual testing is important, too. But let's not ignore automated testing just because you have manual testing in place.

If you cannot see case/if else in GOTO form, then I feel sorry for you.

I agree with the case for automated testing, and we do plenty of that. But manual unit testing isn't about testing the parameters passed into the program, it's about testing the stuff you can't get to with automated testing, such as unexpected error conditions. There's no way to reliably reach some of that code without manual unit testing, often in a debugger, sometimes by changing variables and return codes within the debugger. That's especially true for race conditions between threads in multi-threaded applications. And if your code is being exercised millions or billions of times every day, that code will get executed at some point, whether you test it or not.

Case and if/then/else statements allow very specific control to well-defined pieces of code. That's not the same as a GOTO statement, which allows change of control to any point in a program at any time. Unless you've got incredible self discipline in using them, good luck finding a subtle bug in a program with lots of GOTO statements!

Floppy disks, those bring back memories. I haven't used one of those in many years...

Point taken. And you're a photographer? in Colorado? What are you doing computer programming? (so says a truck driver in Colorado)

Did I just date myself? Oh dear. Well. I'm not saying whether it's an 8 incher or 5.25.
Edit: I meant 3.5. Yeah, that's the one I meant to say. ^_^;

I'm a programmer/software designer/DBA/etc. by trade. Photography is just a hobby (one of too many), I think it would be challenging to make a living in it these days.

I'm happy I can't date myself to the days of punch cards, I never had the pleasure of using those!