All Things Microsoft > Microsoft Software
Muzzy, why does Windows rule?
muzzy:
Enforcing newbies to do "the right thing" is not always good idea. They might learn the habit, but they won't know why it's a good thing. The newbie will hate having to use { and } there, and there'll be plenty of quality time debugging badly indented code with stuff like "if (a) b; c;", as opposed to "if (a) { b; c; }"
Also, regarding "syntax similarity", the example of format strings has nothing to do with syntax, it has to do with the standard library. The syntax of the examples you gave is radically different, and the only common point is the semantics of the function used. Once the programmer has gotten used to python's lists, he'll be a fish out of water with C.
Orethrius:
You're assuming an awful lot there, nobody said we were "forcing" newbies to learn this per se. Indeed, they should know this offhand when learning to code, but that's not exclusive of the fact that they need to comprehend the virtues of clarity in coding. You also seem to see a degradation of coding practices when a newbie is told what to do, as well as when they're left in the dark. I refuse to discuss the matter further until you resolve this conflicting logic. :p
jtpenrod:
Once the programmer has gotten used to python's lists, he'll be a fish out of water with C.
Here are a couple of code fragments from a couple of apps I coded. Here's the one I did with Ruby (not Python, but Ruby uses the same type of lists and dictionaries)
--- Code: ---
# Create a Ruby hash for master list of all option menus, list boxes and
# spin buttons. (Use hash instead of array as the values for window
# IDs don't start with 0, and may change from one FOX release to another)
# Use the window IDs (FOX defined) as keys.
#
# Organize as 6X6 matrix.
@hshOptMenuList= {THEMES => [cbSpecies, omThemes, sbFurRate, omRelations, nil, nil],
PARTICIPATION => [omArt, omCons, omFursuiting, omContact, omMucking, nil],
REALISM => [omPlushies, omRealism, omTrans, omFanfic, omFanzines, nil],
PREFERENCES => [omFurryGender, omYiffRating, cbOccu, omRLAge, omTechSavvy, omOpSys],
REALLIFE => [omGames, omEduc, omRLFurriness, omHousing, nil, nil],
INTERESTS => [omTheNet, omAnime, omPets, omRLGender, omRLSex, nil]}
--- End code ---
I also did a C++ version of the same app, as C++ is a bit snappier on running it. Here's the same problem solved in C++:
--- Code: ---
/*
Initialize the Option Menu master list.
Note: This becomes necessary as the option menu buttons themselves
do not have a handle to receive messages. Must enable/disable
by calling the ancestor methods directly.
Store the pointers as FXObject*, and cast to type as needed.
*/
Index= THEMES - THEMES;
OptMenuList[Index][0]= FurrySpeciesCB;
OptMenuList[Index][1]= Themes;
OptMenuList[Index][2]= FurRateSB;
OptMenuList[Index][3]= Relations;
Index= PARTICIPATION - THEMES;
OptMenuList[Index][0]= Art;
OptMenuList[Index][1]= Cons;
OptMenuList[Index][2]= Fursuiting;
OptMenuList[Index][3]= Contact;
OptMenuList[Index][4]= Mucking;
Index= REALISM - THEMES;
OptMenuList[Index][0]= Plushies;
OptMenuList[Index][1]= Realism;
OptMenuList[Index][2]= Transform;
OptMenuList[Index][3]= Fanfic;
OptMenuList[Index][4]= Fanzines;
Index= PREFERENCES - THEMES;
OptMenuList[Index][0]= FurryGender;
OptMenuList[Index][1]= YiffRating;
OptMenuList[Index][2]= FurryJobsCB;
OptMenuList[Index][3]= RLAge;
OptMenuList[Index][4]= TechSavvy;
OptMenuList[Index][5]= OpSys;
Index= REALLIFE - THEMES;
OptMenuList[Index][0]= Games;
OptMenuList[Index][1]= Education;
OptMenuList[Index][2]= RLFurriness;
OptMenuList[Index][3]= Housing;
Index= INTERESTS - THEMES;
OptMenuList[Index][0]= Internet;
OptMenuList[Index][1]= Anime;
OptMenuList[Index][2]= Pets;
OptMenuList[Index][3]= RLGender;
OptMenuList[Index][4]= RLSexlife;
--- End code ---
Simply declare: FXObject *OptMenuList[6][6];
Then fill it with zeros while initializing. Fish out of water? Not hardly! In both cases, it's simply a 6X6 matrix. The main difference is that you don't have to declare the Ruby (or Python) list, with the Ruby hash, you don't have to subtract off the "THEMES" bias every time you want to use it (which is why I went with the hash, and not the list).
I don't see a problem here.
Calum:
--- Quote from: Orethrius ---You're assuming an awful lot there, nobody said we were "forcing" newbies to learn this per se. Indeed, they should know this offhand when learning to code, but that's not exclusive of the fact that they need to comprehend the virtues of clarity in coding. You also seem to see a degradation of coding practices when a newbie is told what to do, as well as when they're left in the dark. I refuse to discuss the matter further until you resolve this conflicting logic. :p
--- End quote ---
another apparent contradiction is that newbies will somehow resent being told how to do things correctly and legibly, and will turn out poorly formatted code in retaliation (!) The alternative would be not to tell them how to do this, which would certainly result in poorly formatted code anyway, yes?
i think (personally) that telling people how to do something in an easily understandable way is a *good idea* (TM) because if they are determined to code in an obfuscated fashion, they will do so anyway, regardless.
Aloone_Jonez:
Aren't interpreters very slow?
What would be cool if they could compile the code and then store it in memory then execute immediately. Then the only delay would be the start up time, and if this is a problem most of the code could be interpreted and the programmer could just have an option to pre-compile any routines that need more speed. This would dive you the best of both worlds.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version