Muzzy, why does Windows rule?

[Aloone_Jonez]

Qbasic was and still is a good newb language. I find it funney how everyone says assembly is so hard when I found it easier than C. perhaps Qbasic got me into lots of bad habits then when I tried C Qbasic had fucked with my brain! But as I'd been using assembly (MS-DOS debug.com) for some time in conjunction with Qbasic I didn't have that problem with assembly.

Well I have a friend, I was in class with him last year when I was going to a "specialist school" which was filled with kids with no other school to goto, or just in need of more basic education. Mostly kids with no other school to goto however. I was there because of, well I was just sick of school and it was only part time. (Worst mistake ive ever made). Nonetheless the work was so damn easy I found myself helping my friend learn to read better (he was dyslexic as well), however he was a lot worse then you are.

I didn't go to a special school but I went to the reading centre on a daily basis, (a place in our town dedicated to helping children with dyslexia), and I had to have a classroom support. I did suffer some bullying though because this made me different to the other children.

[jtpenrod]

Qbasic was and still is a good newb language.

An even better one is Python. Python has some advantages: it's object oriented, doesn't teach bad habits, can be learned quickly, like BASIC, it's interpreted so that you can see your mistakes right away. Furthermore, it's useful in its own right, not just something you learn on before moving onto something better.

I find it funney how everyone says assembly is so hard when I found it easier than C.

Good for you! Learning C/C++ is a real bitch if you aren't familiar with assembly. The big sticking point with C/C++ is pointers and references. It makes no sense if you have no idea what goes on "under the hood" when you do something like: int a= 10;  Using indirection and aliases is done quite commonly in assembly, and becomes second nature, so that C isn't really that big of a deal.

perhaps Qbasic got me into lots of bad habits then when I tried C Qbasic had fucked with my brain!

It sure won't do much to prepare you for C. Again, Python does better in that regard, as its syntax is quite like that of C.

[muzzy]

I personally find python to be an unholy language, not least because it uses indentation for flow control. Yea, and lisp constructs too. Some guys just can't learn a new language but have to submit patches to make it look like their favourite, and then some jerks don't have a vision over their language so they'll apply the said patches. Hmmmpphhhhh! Ohwell, at least we got python 3000, which will set things straight with expense of backwards compatibility.

Regarding C and C++, while pointers can be tough, they can be understood in the abstract sense without need to understand the lowlevel implementation. However, for debugging reasons it's always a good idea to understand how things are implemented, so strange bugs will make more sense. Anyway, in C++ you can code using only very little amount of pointers, so that's not quite a big as a stumbling block for a C++ programmer than it is to a C programmer.

I can't agree that python and C would be similar in any damn way. If you think the syntax is similar, you're smoking some stuff I'd like to try, too. Or perhaps you're writing your python code in strictly procedural fashion and referring to the paradigm? And ignoring very strongly present functional programming ideology that can "fuck with" the programmer's brain as well...

Anyway, I believe that every language that makes you think about programming differently is a good language, and as of such that includes QBasic as well.

[muzzy]

I often find myself reading posts several times before I understand them fully, this is worse for longer posts, and you're right I should have read your post a bit more carefully, perhaps because I find longer posts harder to read tend I concentrate more (some of muzzy's posts take nearly hour to read!) but I should also give short posts equal attention.

Ouch, I feel a little guilty about writing long posts now. Perhaps I should concentrate more to keep my posts short

[jtpenrod]

I personally find python to be an unholy language, not least because it uses indentation for flow control.

Python's use of white space for flow control has been controversial from day one. However, there is a plus side for the raw newbie. After using Python, he's more likely to write something like this:

Code: [Select]


     for (int i= 0; i < SomeInt; i++)
     {
          /* Do Something */
          /* Do Something */
          /* Do Something */
          /* Do Something */
     }

as opposed to something like this:

Code: [Select]


     for (int i= 0; i < SomeInt; i++) {
     /* Do Something */
     /* Do Something */
     /* Do Something */
     /* Do Something */
     /* Do Something */}


Having gotten use to using sane indentation, he'll be more likely to produce more easily readable code.

Regarding C and C++, while pointers can be tough, they can be understood in the abstract sense without need to understand the lowlevel implementation. However, for debugging reasons it's always a good idea to understand how things are implemented, so strange bugs will make more sense. Anyway, in C++ you can code using only very little amount of pointers, so that's not quite a big as a stumbling block for a C++ programmer than it is to a C programmer.

Anything can be understood in an "abstract sense" if you work at it hard enough. However, every book on C/C++ has always introduced the subject of pointers and references with an apology, and an admonition to keep at it with the promise that he'll eventually "get it". It's a helluvalot easier if you've had some experience with assembly, and know how the various addressing modes work.

Still, there are plenty of occasions to use pointers in C++. That's especially true concerning objects and the infamous "this" pointer. Another good thing about Python is that Python class methods make explicit use of self referential pointers.

I can't agree that python and C would be similar in any damn way. If you think the syntax is similar, you're smoking some stuff I'd like to try, too.

Oh really? I'd say that this:

Code: [Select]


     print "%s\n" % ("Hey there, dude!")

is quite similar to this:

Code: [Select]


     printf("%s\n", "Hey there, dude!");


At least if one has seen the former, the latter won't look completely unfamiliar. Start with Python, and it will be easier to pick up C/C++. Jumping straight into C is not a good idea. It can be done, but not easily.

Or perhaps you're writing your python code in strictly procedural fashion and referring to the paradigm? And ignoring very strongly present functional programming ideology that can "fuck with" the programmer's brain as well...

I've used it both ways. Done the same with C++ as well. So?

[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: [Select]


#              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]}


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: [Select]


/*
       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;


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]

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

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.

[jtpenrod]

This would dive you the best of both worlds.

Actually Python (but not Ruby) does have an option much like that. Python source can be compiled to byte code that runs faster. Usually, the interpreter takes care of doing this with the modules the program loads. You can also override that behaviour and byte compile whatever Python source you want.

Both Python and Ruby make provisions for using add-ons made from compiled C/C++ code. After all, this is how these interpreted languages are able to make use of GUI toolkits written in C/C++.

[Orethrius]

That kinda reminds me of the old "scene" productions, the ones that took up about 500KB of space initially and used nothing but DirectDraw instruction files in ultra-compressed archives (that were unpacked on-the-fly) to create beautiful landscapes.  Whatever happened to those?

[muzzy]

That kinda reminds me of the old "scene" productions, the ones that took up about 500KB of space initially and used nothing but DirectDraw instruction files in ultra-compressed archives (that were unpacked on-the-fly) to create beautiful landscapes.  Whatever happened to those?

Runtime texture generation and stuff isn't same as compression. With compression, you have the result data and try to represent it through a compression algorithm. Procedural generation of stuff is different, as the data is generated on the fly. And 500kB is large by some standards, there are 64K and 4K intros out there that look quite quite amazing.

[muzzy]

Anyway, jtpenrod, when I was talking about python's lists I was thinking about the ease of manipulating them and doing stuff with them. For example:

Code: [Select]

s = "some squares:"
for i in [x*x for x in range(1,15)]:
  s = "%s %d" % (s, i)
print s
Go ahead, move to C after getting used to doing things like that. And that's an example from the simple end. Let's take another one, with a little more trickery, still basic stuff:

Code: [Select]

s = "this is a silly stupid test sentence"
print ' '.join([x.capitalize() for x in s.split(' ') if len(x)>4])
This example outputs "Silly Stupid Sentence", i.e. capitalized words from the string, for which length of word is greater than 4. Got it? Moving to C after having power like this, it's going to be excessively frustrating.

[jtpenrod]

Look, Muzzy, I'm not interested in your little pissing contest. Sure, Python includes lots of features that aren't included in C/C++, such as reg ex support. That isn't the point. That first example is obviously contrived as there's a simpler way to get the job done:

Code: [Select]


s= "Some squares: "
for i in range(1, 15) : print "%s %d\n" % (s, i * i)


As for the second, sure, it's nice to have built-in reg ex support and string manipulation methods. However, there is nothing to prevent anyone from installing equally capable string class and reg ex libs that will work with any C++ program. If you're talking about C programs, the GTK libs also include these string "objects".

You can contrive all sorts of weird examples and peculiar situations, however, how often do these situations occur in most programming situations? Or is it your contention that programming n00bs are to st00pid to make whatever adjustments are needed in going from an introduction to Python to some other language?

Now you want to consider this a concession of defeat, go ahead and knock yourself out. I don't care. However, I will reiterate that I would encourage anyone who wants to pick up programming, having never done it before, to start with Python, and not C/C++ for the reasons I have already stated. :p