On Fri, 2010-12-17 at 09:50 -0700, Patrick Kobly wrote: > On 12/17/2010 5:10 AM, Parshwa Murdia wrote: > > You say correctly, 'The "best" programming language, is the one you > > feel most comfortable with, obviously.' As I am new and starting > > just, so I guess (with all the suggestions I get and from searching > > too) that either Python or C language would be a good start. Pascal > > is now less used. > > The thing to keep in mind here is what is the purpose of the language > you're choosing for this step in your journey. You are clearly not > going to be writing production software for some time. You are > choosing a language that will serve as a canvas for early-stages > learning. At this point, you probably want to evaluate your tools in > terms of their pedagogic advantages, rather than practical advantages > for implementing working production software. > > Keep in mind that many first year programming / computing science > classes use toy languages - purposely kept small to illustrate a few > programming concepts without distracting you with other concepts. > > IMHO, a first learning language should introduce concepts including: > * Variables > * Typing of variables (strong typing) > * Arrays > * Data structures > * Boolean logic expressions > * Flow control and looping (if, then, else ; while ; for,to) > * Procedure and / or function calls > * Formal parameters vs. actual parameters > * Recursion > * Equivalence of recursion and iteration > * Compilation > * Compile-time vs. Run-time errors > A first programming language should avoid concepts like: > * Pointers (at least in the C conception of them, breaking the > typing system) > * Dynamic typing > * Polymorphism > * Inheritance > That in mind, my suggestion for a first language would generally be > more similar to Pascal or Modula-2 than C, Python, C++, Java,... > > > However, I agree with you that programing principles remain the same > > for any language, indeed. > > Principles remain the same for particular collections of languages. > The principles at play in functional languages (LISP, Prolog,...) are > different than those of procedural languages (Pascal, Modula-2, C) > which are different still from OO languages (C++, Java, SmallTalk, > Python) - though OO shares more with procedural than functional > languages. > I see a lot of complaints about pointers in all these messages, telling this novice to avoid them. But the fact is that all languages rely on pointers. Even the beloved scripting languages so many tout, cannot exist without pointers. The fact is that all data in the computer resides in memory or on disk or some other file system. Every file system depends on pointers. If you look for example (using one of the oldest and free forms that is easily accessible) FAT 16, The base structure starts with the location 0, which is a pointer to a data store describing the disk. In turn, from that you find pointers to the partition table. From that you find pointers to the FAT table itself, and to the data. From the fat table you get an array of indexed pointers to data segments which are pointers to boundaries of data blocks, and from the partition table you get a description of the sector layout, the retrieval blocking and other information about the structure, which allow you to decode the FAT table and extract the data. The beloved object oriented folks have pointers built in, that are used to access the procedures that affect the objects. The objects are in fact structures, which are created in blocks and again pointers are used to reference that information. When you use an array, that is an indexed offset from a pointer. Someone said pointers break the typing. That is not true, if you do not break pointer typing to begin with. That is a pointer can be typed, and moreover someone who uses an integer for a pointer is voiding type control in his program. No knowing pointers means not having any clue to how the underlying structure works and leads to weak programming. I strongly encourage every beginning programmer to learn pointers, pointer usage and pointer math to understand some of the mechanisms that make programs break. A programmer who doesn't understand the strengths and weaknesses of pointers is like a plumber who doesn't know how pipes work and what makes a manifold. He can hack around, but he cannot diagnose when plumbing makes noises, doesn't flow correctly or even backflows. That is my opinion. Maybe I am out to lunch, but has anyone seen any language that didn't access memory? Regards, Les H -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
