New to programming, which language is better?
- Thread starter mtnbording
- Start date
jove
Member
wiz,
Good question. There is still a lot of code written in old languages for primarily three reasons.
Legacy systems need to be maintained and expanded. Too often the cost of a rewrite and retraining of existing personnel on a new language is over estimated; as a justification to keep things the way they are.
In other words, Maintenance, Cost, and Stubbornness
If you are new to programming, you should learn a simple structured language like Pascal, Basic, or ADA first. The fundamentals of those languages are transferable to any language. Object orientation is a form of modularization with some complicated concepts It should be layered on-top of knowledge of the fundamentals.
C does low level programming better than most languages. Fortran is a great number cruncher. Cobol is good at sorting and reporting. Primitive languages still fulfill needs.
Remember, the higher level a language is the more limited its applicable range is.
Good question. There is still a lot of code written in old languages for primarily three reasons.
Legacy systems need to be maintained and expanded. Too often the cost of a rewrite and retraining of existing personnel on a new language is over estimated; as a justification to keep things the way they are.
In other words, Maintenance, Cost, and Stubbornness
If you are new to programming, you should learn a simple structured language like Pascal, Basic, or ADA first. The fundamentals of those languages are transferable to any language. Object orientation is a form of modularization with some complicated concepts It should be layered on-top of knowledge of the fundamentals.
C does low level programming better than most languages. Fortran is a great number cruncher. Cobol is good at sorting and reporting. Primitive languages still fulfill needs.
Remember, the higher level a language is the more limited its applicable range is.
Easter
Cypherpunk
Hi Jove,
I'm not agree; you could learn Object Oriented Programming without to know others programming methods.
You could apply OO even on Assembly (the language just don't have support for complicated OO structures).
Why to learn "sequential" Analysis, Project, Programming if you could learn the Object Oriented version?
OO is an extension but is more difficult to change on OO than learn directly OO.
I'm in hurry ...
Bye_
I'm not agree; you could learn Object Oriented Programming without to know others programming methods.
You could apply OO even on Assembly (the language just don't have support for complicated OO structures).
Why to learn "sequential" Analysis, Project, Programming if you could learn the Object Oriented version?
OO is an extension but is more difficult to change on OO than learn directly OO.
I'm in hurry ...
Bye_
jove
Member
Hello,
The experimentation with the languages mentioned will help teach the basics. What is a collection of data? What are the most effective ways to store the data? And how do you most efficiantly process the data?
I understand your point. Making the OO logical jump is like Pointer Epiphany But what is the point of object usage without the above skills? I have seen many software developers who may be able to create a "working" OO design but couldn't construct decent process code to save thier lives.
OO concepts do not cover too common mistakes.
But then again the software industry is conducting the Shakespeare Experiment ;-)
The experimentation with the languages mentioned will help teach the basics. What is a collection of data? What are the most effective ways to store the data? And how do you most efficiantly process the data?
I understand your point. Making the OO logical jump is like Pointer Epiphany
But what is the point of object usage without the above skills? I have seen many software developers who may be able to create a "working" OO design but couldn't construct decent process code to save thier lives. OO concepts do not cover too common mistakes.
Code:
if ( obj->DoComplexThing() == 2 )
...
else if ( ( obj->DoComplexThing() == 3 )
...
for ( int i = 0; i < 10000; i++ )
{
if ( array[ i ] == 4 ) foundIndex = i;
}But then again the software industry is conducting the Shakespeare Experiment ;-)
Easter
Cypherpunk
Hi Jove,
you are a very expert and very very polite person ...
Happy to meet you!.
Again I'm not fully agree with you.
To learn Algorithm and Data Structures is independant from learning a programming paradigm. Indeed many OOP have libraries suitable to deal with complex data structures (STL in C++, standard packages in Java).
To optimize the code is another view ... you first have to build good programs than after you have to see IF it's not efficent and WHERE need optimizations.
So if someone is new to programming I think it's better to start (and continue) with OO methods.
OO Programming is a "superset" of Functional Programming so you can learn the same thing but with more "protection" given by objects.
OO is a different state of the mind.
Write good code need time using Functional or OO paradigm.
Anyway I'm not talking only about the Languages but, more important, Analysis and project.
But the question is: "what's the Shakespeare Experiment ???"
Bye_
you are a very expert and very very polite person ...
Happy to meet you!.
Originally posted by jove
Hello,
The experimentation with the languages mentioned will help teach the basics. What is a collection of data? What are the most effective ways to store the data? And how do you most efficiantly process the data?
I understand your point. Making the OO logical jump is like Pointer Epiphany
Again I'm not fully agree with you.
To learn Algorithm and Data Structures is independant from learning a programming paradigm. Indeed many OOP have libraries suitable to deal with complex data structures (STL in C++, standard packages in Java).
To optimize the code is another view ... you first have to build good programs than after you have to see IF it's not efficent and WHERE need optimizations.
So if someone is new to programming I think it's better to start (and continue) with OO methods.
OO Programming is a "superset" of Functional Programming so you can learn the same thing but with more "protection" given by objects.
OO is a different state of the mind.
Write good code need time using Functional or OO paradigm.
Anyway I'm not talking only about the Languages but, more important, Analysis and project.
But the question is: "what's the Shakespeare Experiment ???"
Bye_
jove
Member
I am sorry for making a vague cultural reference. There is an old saying...
If you put a group of monkeys in a room with a bunch of typewriters for an infinite amount of time, eventually, they will produce the complete works of Shakespeare (an author and playwright).
The statement is used to impress upon the listener what the concept of infinity means. My reference implies that businesses too often throw too many mediocre programmers at a single problem hoping for a workable solution; instead of doing proper analysis or design refactoring. The code listings in the previous post are just two small examples of bad programming I see all the time.
You are correct that optimizing, libraries, paradigm, and syntax are orthogonal. Remember when you were first learning something as basic as what a variable is. I remember at age 12 finally understanding the need and use of i=i+1. I was certainly in no state to learn when to use the template design pattern!
Recently I had a design discussion with two junior but very good programmers. They kept confusing design with language constructs. It is easy for the more experienced to separate the concepts.
I appreciate the compliment of being called an expert. But nobody is an expert in the computer industry It would be like calling myself an expert in Fish! Cooking? Catching? Breeding? Eating?
We have gotten way off track from the original question! Maybe we should agree to disagree.
If you put a group of monkeys in a room with a bunch of typewriters for an infinite amount of time, eventually, they will produce the complete works of Shakespeare (an author and playwright).
The statement is used to impress upon the listener what the concept of infinity means. My reference implies that businesses too often throw too many mediocre programmers at a single problem hoping for a workable solution; instead of doing proper analysis or design refactoring. The code listings in the previous post are just two small examples of bad programming I see all the time.
You are correct that optimizing, libraries, paradigm, and syntax are orthogonal. Remember when you were first learning something as basic as what a variable is. I remember at age 12 finally understanding the need and use of i=i+1. I was certainly in no state to learn when to use the template design pattern!
Recently I had a design discussion with two junior but very good programmers. They kept confusing design with language constructs. It is easy for the more experienced to separate the concepts.
I appreciate the compliment of being called an expert. But nobody is an expert in the computer industry
It would be like calling myself an expert in Fish! Cooking? Catching? Breeding? Eating?We have gotten way off track from the original question! Maybe we should agree to disagree.
As for starting out with no programming expericence. I really think you can't go wrong with RealBasic. This is how I started, and you would be amazed at the powerfull apps that can be compiled. The only downside I see to RB is that the linker is not yet "Smart" so the file sizes for a simple app can be large compared to a Cocoa app.
I initially tried to start with C++ and wow, I did not do very well with that. I would really love to learn ObJ-C and the Cocoa framework, but there doesnt seem to be a good way to learn it without first learninc C.
Anyway, RB is very easy to use and can make very powerfull apps. There are several Large apps that have been written in RB, Microsofts Query X tool, their Remote Desktop Conncetion tool, Kiplingers Taxcut, Typing Tutor, to name just a few.
I initially tried to start with C++ and wow, I did not do very well with that. I would really love to learn ObJ-C and the Cocoa framework, but there doesnt seem to be a good way to learn it without first learninc C.
Anyway, RB is very easy to use and can make very powerfull apps. There are several Large apps that have been written in RB, Microsofts Query X tool, their Remote Desktop Conncetion tool, Kiplingers Taxcut, Typing Tutor, to name just a few.
heh this is what i did.
i tried BASIC. wow thats a confusing language. Well not really. BASIC syntax languages are easy to learn. I understood the basics of programming through this language.
Then i got bored. I wanted to learn more. I looked at languages like C/C++ and Java. I was lost. All i saw was gibberish. But i heard great things about theses languages. This is what motivated me to learn them. I really wanted to make sense of all that code!
I sarted out with Java. That was fun and easy. I learnt that language at a remarkable speed. heh, 1 week. Considering I being just a beginner, that is a pretty good pace.
Then after understanding OOP concepts and trying them out. I decided to challenge myself with C++ (btw: this was a year later). I began reading a lot on it! It was fun as well.
then later on i decided to learn Perl. I learnt it as well. (useful language). Haven't mastered it though!
Now all i need to know is objective-c!
i tried BASIC. wow thats a confusing language. Well not really. BASIC syntax languages are easy to learn. I understood the basics of programming through this language.
Then i got bored. I wanted to learn more. I looked at languages like C/C++ and Java. I was lost. All i saw was gibberish. But i heard great things about theses languages. This is what motivated me to learn them. I really wanted to make sense of all that code!
I sarted out with Java. That was fun and easy. I learnt that language at a remarkable speed. heh, 1 week. Considering I being just a beginner, that is a pretty good pace.
Then after understanding OOP concepts and trying them out. I decided to challenge myself with C++ (btw: this was a year later). I began reading a lot on it! It was fun as well.
then later on i decided to learn Perl. I learnt it as well. (useful language). Haven't mastered it though!
Now all i need to know is objective-c!
If you just want to write a program and you don't care about the hows and whys of computer programming, then by all means, go with something like Java or even RealBASIC. High-level languages such as these let you do a lot with a comparatively low level of computer understanding.
But don't confuse higher level for more powerful. Sure, they automate all kinds of things, but the tradeoff is in control. Furthermore, in order to optimize high-level code, you need to understand what it's doing underneath the hood.
If you want to get serious about programming, you gotta get closer to the hardware to understand what makes things efficient. You have to learn C. From there it's a small step to understanding assembly language, and actual hardware implementation. Once you understand these things, you can learn ANY language comparatively quickly, because you understand the principles on which they are all based.
Objective-C and C++ are two OOP languages which are still as powerful as C (in fact they are just extensions to C). You won't be able to tackle them until you learn C, but that is OKAY. There is a lot of hype surrounding Object-Oriented Programming, but in reality, it solves bad programming practice issues by placing unwarranted restrictions on code and data. Now, before you respond with a knee-jerk argument about the benefits of OOP, please read and understand the articles
here.
The gist of the argument is this. Object-orientation looks good on paper, but it organizes data and code into a tree structure. In real life, data often is more accurately modeled by a set structure (like a relational database). For instance, object inheritance doesn't solve the problem of an object sharing traits of more than one 'parent' object. This is solved by kludgy redundancy of data in multiple objects, when defining 'objects' as sets of common data would be much more efficient.
In real-world scenarios, data architecture is subject to change. Normalized databases ammeliorate this problem from a data standpoint, but OOP can worsen the situation because of how tightly knit the data structures are to the code. All this would be acceptable if OOP provided some amazing benefit over procedural languages, but actually it just re-organizes things. Data encapsulation already exists in procedural languages (think local variables), and private functions can be handled at the compiler level.
That's not to say OOP doesn't have it's uses, but it is to say that you shouldn't blindly believe that it's benefits are unattainable in procedural languages. Perceived benefits are mostly due to a lot of focus on the development of OOP rather than improving procedural languages and compilers. At any rate, C will teach you more fundamental computer science concepts that will be applicable to any existing languages and also any future Turing-complete languages (quantum computation might introduce new concepts). It's an investment in your future.
But don't confuse higher level for more powerful. Sure, they automate all kinds of things, but the tradeoff is in control. Furthermore, in order to optimize high-level code, you need to understand what it's doing underneath the hood.
If you want to get serious about programming, you gotta get closer to the hardware to understand what makes things efficient. You have to learn C. From there it's a small step to understanding assembly language, and actual hardware implementation. Once you understand these things, you can learn ANY language comparatively quickly, because you understand the principles on which they are all based.
Objective-C and C++ are two OOP languages which are still as powerful as C (in fact they are just extensions to C). You won't be able to tackle them until you learn C, but that is OKAY. There is a lot of hype surrounding Object-Oriented Programming, but in reality, it solves bad programming practice issues by placing unwarranted restrictions on code and data. Now, before you respond with a knee-jerk argument about the benefits of OOP, please read and understand the articles
here.
The gist of the argument is this. Object-orientation looks good on paper, but it organizes data and code into a tree structure. In real life, data often is more accurately modeled by a set structure (like a relational database). For instance, object inheritance doesn't solve the problem of an object sharing traits of more than one 'parent' object. This is solved by kludgy redundancy of data in multiple objects, when defining 'objects' as sets of common data would be much more efficient.
In real-world scenarios, data architecture is subject to change. Normalized databases ammeliorate this problem from a data standpoint, but OOP can worsen the situation because of how tightly knit the data structures are to the code. All this would be acceptable if OOP provided some amazing benefit over procedural languages, but actually it just re-organizes things. Data encapsulation already exists in procedural languages (think local variables), and private functions can be handled at the compiler level.
That's not to say OOP doesn't have it's uses, but it is to say that you shouldn't blindly believe that it's benefits are unattainable in procedural languages. Perceived benefits are mostly due to a lot of focus on the development of OOP rather than improving procedural languages and compilers. At any rate, C will teach you more fundamental computer science concepts that will be applicable to any existing languages and also any future Turing-complete languages (quantum computation might introduce new concepts). It's an investment in your future.
heh,
but finally languages which help make maintenance and extensibility easier are the best of the lot.
Thus i find almost all correctly implemented OOP languages the best to use.
I mean seriously, the real world is a lot more complex then we can every imagine. To model the real world exactly and precisely is impossible. Hence all those arguments you stated against OOP, have no point to them.
but finally languages which help make maintenance and extensibility easier are the best of the lot.
Thus i find almost all correctly implemented OOP languages the best to use.
I mean seriously, the real world is a lot more complex then we can every imagine. To model the real world exactly and precisely is impossible. Hence all those arguments you stated against OOP, have no point to them.
Please read some of the articles on the Web site I cited. It requires a lot more explanation than one post. OBVIOUSLY the world can't be modeled perfectly.
I write software for a living, and I speak from experience when I say that the OOP provides stricter semantics and encapsulation at the expense of flexibility. Sure OOP is a great way of modeling static systems, and it can help beginners develop certain important ideas. I don't dispute that. But when you fundamentally understand those ideas, the strict syntax may end up leaving you with less expandable and less reuseable code. The benefits attained are mostly in the realm of readability, and can be achieved equally well with a procedural approach without compromising flexibility.
OOP is only more extensible in well-defined cases. But in real-world programming, data changes over time, and the key is you don't know HOW it will change before hand. So although in theory you can write an object to represent a piece of data, and if the data changes, you will only need to change that object right? WRONG. Because the whole application is built on a huge number of interactions between objects. Often times changes in data format will require many objects to behave differently. And because objects are rigidly defined collections of functions, sometimes many functions will have to be re-written in a single object just to support a relatively minor change.
If you instead have a collection of functions that do prescribed things to data, you only need change or add functions that directly relate to the change in data, rather than having to rewrite functions simply because they are associated with the data via a class definition or an object interface.
Sure you can design around these problems with OOP, but in the process you end up creating something that looks more and more procedural. This simply adds overhead.
Many times, a more flexible approach is to write functions that do specific things, then create sets of these functions to take care of higher-level tasks. These groups can be defined in a table like a relational database. The groups can also have an associated data structure if you like and you end up with what is basically the functional equivalent of an object. Why is this more maintainable and extensible? Because the interface of a very specific function is less likely to need to be changed than the complex interface of an object. It's akin the whole Unix philosophy, write programs that do one thing and do it very well.
The maintainability of OO programs is an illusion propogated by the lack of development of procedural languages and tools. Functions are just as much of black boxes as objects. A language could exist (or simply an IDE) that defined groups of functions and data structures in the way I described that would make program flow every bit as clear as (and remarkably similar to) an OO-language, except without the rigid coupling of methods and data.
I'm not saying that OOP isn't a valid way to conceptualize problems. It offers a different perspective, which is always valuable. My point, which is backed up by real world experience, is that the precise benefits of OOP can be achieved without the limitations. In a technical field such as programming, it's sad to see people blindly believe marketing hype without examining the theoretical basis of those claims.
I highly suggest you read and give serious consideration to: http://www.geocities.com/tablizer/top.htm
I write software for a living, and I speak from experience when I say that the OOP provides stricter semantics and encapsulation at the expense of flexibility. Sure OOP is a great way of modeling static systems, and it can help beginners develop certain important ideas. I don't dispute that. But when you fundamentally understand those ideas, the strict syntax may end up leaving you with less expandable and less reuseable code. The benefits attained are mostly in the realm of readability, and can be achieved equally well with a procedural approach without compromising flexibility.
OOP is only more extensible in well-defined cases. But in real-world programming, data changes over time, and the key is you don't know HOW it will change before hand. So although in theory you can write an object to represent a piece of data, and if the data changes, you will only need to change that object right? WRONG. Because the whole application is built on a huge number of interactions between objects. Often times changes in data format will require many objects to behave differently. And because objects are rigidly defined collections of functions, sometimes many functions will have to be re-written in a single object just to support a relatively minor change.
If you instead have a collection of functions that do prescribed things to data, you only need change or add functions that directly relate to the change in data, rather than having to rewrite functions simply because they are associated with the data via a class definition or an object interface.
Sure you can design around these problems with OOP, but in the process you end up creating something that looks more and more procedural. This simply adds overhead.
Many times, a more flexible approach is to write functions that do specific things, then create sets of these functions to take care of higher-level tasks. These groups can be defined in a table like a relational database. The groups can also have an associated data structure if you like and you end up with what is basically the functional equivalent of an object. Why is this more maintainable and extensible? Because the interface of a very specific function is less likely to need to be changed than the complex interface of an object. It's akin the whole Unix philosophy, write programs that do one thing and do it very well.
The maintainability of OO programs is an illusion propogated by the lack of development of procedural languages and tools. Functions are just as much of black boxes as objects. A language could exist (or simply an IDE) that defined groups of functions and data structures in the way I described that would make program flow every bit as clear as (and remarkably similar to) an OO-language, except without the rigid coupling of methods and data.
I'm not saying that OOP isn't a valid way to conceptualize problems. It offers a different perspective, which is always valuable. My point, which is backed up by real world experience, is that the precise benefits of OOP can be achieved without the limitations. In a technical field such as programming, it's sad to see people blindly believe marketing hype without examining the theoretical basis of those claims.
I highly suggest you read and give serious consideration to: http://www.geocities.com/tablizer/top.htm
binaryDigit
Registered
It's kinda funny, this whole "what's a better language to start off with" thing comes up over and over. I agree with BOTH Easter and telbij to a point. First let me say that I absolutely love C and love/hate C++ (I've done very, very little obj-c so can't comment). I also love assembly and have been programming for more years than many people on this board have been breathing.
That said, I personally don't think it really matters that much which language a person learns to program on. It just depends on what the person wants to accomplish. If you want a career as a software engineer, then look at what languages are in demand (e.g. C++, Java). If you are thinking more business support, then languages like VB are obviously more appropriate. If you care more about web stuff, then PERL, Python are more interesting. I think that the most important thing is to pick a language that solves your problems and then become good at it. Once that is done, pick another language from another field (i.e. VB then C++) to get a more rounded understanding of programming and problem solving.
Each language (and development paradigm) has it's strengths and weaknesses. With C (and derivatives) you have to deal more with the program structure and underlying details (such as pointers, yes even in C++) and so you spend more of your time building and understanding infrastructure and not necessarily solving "business logic". VB and other higher level languages allow you to focus on the higher level logic, but then you obviously miss some of the "what's really going on here". But in any case, LEARN YOUR STUFF. Yes "picking it up in a week" might sound impressive, whatever that means, but in a week, you really don't know squat other than some syntax and very basic stuff.
Which leads me to my most important point. Programming is to this day a learned craft. The only way to become a better programmer is to program. Doesn't matter which discipline you come from, you have to do it, and do it often. I know C/assembler hacks that can code a device driver in a nights session, but couldn't design a ui or a non convoluted database schema to save their lives. Then again I know the stereotypical VB guy who doesn't have a grasp on what a pointer is or memory allocation. But in both cases the bigger problem is not the language(s) they use (or design paradigm), it's the lack of exposure to a wide range of different languages paradigms.
So don't get too caught up in this whole OOP vs procedural, C++ vs Java, VB vs whatever. Just pick what is interesting/matters to you and dive in and learn it. Then pick something else and dive in to that.
So given that, the question really should be:
I want to write (a compiler/an image editor/a PIM/a web based backend/a device driver, etc), what language(s) are good to do that task.
That said, I personally don't think it really matters that much which language a person learns to program on. It just depends on what the person wants to accomplish. If you want a career as a software engineer, then look at what languages are in demand (e.g. C++, Java). If you are thinking more business support, then languages like VB are obviously more appropriate. If you care more about web stuff, then PERL, Python are more interesting. I think that the most important thing is to pick a language that solves your problems and then become good at it. Once that is done, pick another language from another field (i.e. VB then C++) to get a more rounded understanding of programming and problem solving.
Each language (and development paradigm) has it's strengths and weaknesses. With C (and derivatives) you have to deal more with the program structure and underlying details (such as pointers, yes even in C++) and so you spend more of your time building and understanding infrastructure and not necessarily solving "business logic". VB and other higher level languages allow you to focus on the higher level logic, but then you obviously miss some of the "what's really going on here". But in any case, LEARN YOUR STUFF. Yes "picking it up in a week" might sound impressive, whatever that means, but in a week, you really don't know squat other than some syntax and very basic stuff.
Which leads me to my most important point. Programming is to this day a learned craft. The only way to become a better programmer is to program. Doesn't matter which discipline you come from, you have to do it, and do it often. I know C/assembler hacks that can code a device driver in a nights session, but couldn't design a ui or a non convoluted database schema to save their lives. Then again I know the stereotypical VB guy who doesn't have a grasp on what a pointer is or memory allocation. But in both cases the bigger problem is not the language(s) they use (or design paradigm), it's the lack of exposure to a wide range of different languages paradigms.
So don't get too caught up in this whole OOP vs procedural, C++ vs Java, VB vs whatever. Just pick what is interesting/matters to you and dive in and learn it. Then pick something else and dive in to that.
So given that, the question really should be:
I want to write (a compiler/an image editor/a PIM/a web based backend/a device driver, etc), what language(s) are good to do that task.
I've been at the programming game now for 25 years - and I'm only 36 for krysake! In that time I've had to flow with so many different kinds of programming that it makes my head spin. But during that time I've gained an appreciation for programming at the lowest and highest levels. But when it comes to advising new programmers I can only relate my experience and give them some sense of the fascinating realm they're heading into.
I began programming in BASIC guided by a book from Radio Shack that was geared to the TRS-80. Since I had no computer I had to put my programs down on paper and follow the logic in my head. I probably kept this up for 6 months or more before I got hold of a computer to test them out on. Needless to say they were full of bugs and misunderstandings.
But I learned about: variables, flow control, decision logic, loops, etc.
I programmed BASIC for a long time - first on a Sinclair ZX-80, then on Apple II computers at a local radio shop, then on the (amazingly powerful) Atari 400. What kinds of programs did I write? Well, games of course! I wrote the kinds of programs I was interested in having at the end of the long - often tedious -process.
This is what I recommend first to all new programmers. Write the programs you really want to write. Your attention won't flag and you'll enjoy the process so much more.
One thing about writing games in BASIC is that as your ideas become more ambitious the language starts to show its limitations. I was fortunate that there weren't a lot of choices back in 1979. It was BASIC and Assembly Language and little else. There was this strange thing called 'C' I heard about back then but I had no clue what it was about. So when my games needed more speed I went on to 6502 Assembler using the awesome Atari Macro Assembler.
Through Assembly Language I learned about registers, stacks, storage, condition flags, test-and-branch, and memory-mapped devices. PEEK() and POKE() had hardly prepared me for the joy of controlling the processor and hardware directly.
I kept on with Assembly Language for a long while, and when I moved up to the Amiga computer I was well-prepared to start writing programs in 68000 Assembly Language. I kept on with the Amiga and 68000 Assembly for another good long time - until about 1990 or so.
Yes, I completely eschewed the horrid little gray-screened Mac because my wondrous Amiga had such powerful graphics and sound hardware.
I abandoned programming altogether for a few years - from 1990 to 1996 - and focused my attention on more essential aspects of life: music, poetry, and girls.
Then I got the itch to get back to programming again. I bought a cheap PC and wrote silly programs in QBASIC for awhile. When I finally had enough money I bought my first Macintosh, an 8500/150. My intention was to continue with 68000 Assembly and then move up to PowerPC Assembly. But when I started reading about the PowerPC it became clear that I needed to learn C. The reason for this is simple. Modern processors are just too complex for ordinary humans to program them efficiently in their native language!
Now I'm about to break my own rule and make a radical assertion, but bear with me:
C is the mother of all modern programming languages, and every serious programmer must learn it.
C was created with a very specific purpose in mind: To provide the most bare semantics for the things that CPUs do. C encapsulates - very elegantly - the standard operations of a "theoretical" processor. It deals directly with essential concepts of memory, conditions, and program flow. It gives the new programmer a foundation to understand what higher-level languages are doing "under the hood" at the most fundamental level. In my experience, knowing what's going on behind the scenes provides a kind of intuition that proves invaluable in many circumstances. And that kind of intuition "scales well" because the same fundamentals appear throughout the programming universe.
So I began programming my first Mac program in C, learning as I went along.
And that's another thing! Never, ever, in my 25 years of programming have I had the remotest clue what I was doing at the beginning. I had a basic idea of what I wanted to realize. I had enough knowledge to be dangerous. Every new project has been a leap of faith. You have to know ahead of time that you're going to get stuck, you're going to get lost, you're going to go a thousand lines in the wrong direction, you're going to have to scrap tons of work and start over. But you're going to get unstuck, you're going to find your way through, and you're going to write better stuff the next time around. Most of all you're going to discover something new at evey turn. Ah, how fondly I recall that shining day in my geeky youth when binary finally made sense....
So yeah, I eventually got the hang of C. I tried to do some things in C++ but OOP was so new and different that I kept getting stuck in self-doubt. Was I implementing my classes in the right way? Was I properly isolating my Model from my View from my Controller? Ach, the struggle of learning OOP was almost more than I could bear. I tried using frameworks like MacZOOP and MacApp but it was hard for me to use Someone Else's Code. I had never done that before! So I just stuck with C, kept revising my application - which had grown good enough to release as shareware - and occasionally toyed with REALbasic for quick prototyping.
Now, I had done programming as a job back in the early 90's, but it was very informal. Just a bunch of friends in a rented house making silly games. But in 1999 I got my first Real Programming Job making websites with Embedded Perl.
In my job interview I explained that I didn't know perl, but my interviewer knew about the aforementioned reality that programmers are used to being beginners and knew I'd pick it up quickly enough.
And I did. Perl is semantically identical to C. (For that matter, so is PHP, Javascript, and to a large degree Java.) The hardest thing to learn in perl was Regular Expressions. Anyhow, because I had learned C it was much easier to learn perl. I mastered the basics in less than a day. So my first Real Job as a programmer turned out okay.
I'm now on my second Real Job, still making websites, but now I code in PHP. It was another quick learning curve, except that my employer had already built an OOP framework for e-commerce websites.
Uh-oh! OOP was back and it wasn't going to go away this time. Fortunately I was surrounded by a dozen experienced programmers who could answer any of my newbie questions. And most of them didn't even know PHP, they just understood OOP. It also helped that the authors of the framework were at my disposal.
Now, when I was learning C the Internet was brand new. There weren't any web forums like this one. But there was UseNet, and I posted my questions there often. And there was the MOST mailing list. Still, you young whippersnappers don't know how good you've got it!
While I think you really ought to learn C and write some programs in it, those who say you should choose the right tool for the job are absolutely correct. I make websites using a wide range of programming languages now: Javascript for inline form validation, PHP for building pages and interacting with the database, SQL for database operations, Perl for server-centric periodic tasks, shell scripts for file management.... the list goes on. At home I'm using C++ with Simple DirectMedia Library (SDL) and OpenGL to write an action game that will be deployed on Windows, Mac, and Linux.
Did I mention I do all my work with Macs? My employers are total Mac-heads (unlike my last job where I brought in my own Mac to work on).
I believe you can learn to program - and program well - using any language. Each one has its strengths and shortcomings. You'll do best just to choose your project and jump right in. If you're going to make a real-time action game you'll get your best performance writing it in C or C++, but you can get acceptable performance using Objective-C, REALbasic, or even Java. You'll need to learn the appropriate APIs (Application Programming Interfaces) to do graphics and sound, and each language does it differently (but similarly). Again, knowing the C interfaces will give you the most direct view of what's "really" happening. I chose SDL because it makes it easy to write programs that can be written once and run on many platforms. I chose OpenGL over Quartz or QuickDraw for the same reason. If I'm going to spend a year or more on something I want the knowledge I gain to be broadly useful.
You're embarking on a real adventure, and I wish you the best. You're fortunate to have so many choices and to have access to such advanced hardware as we have these days. Sometimes I wonder just how it was that I could work on an Atari with 48K of RAM and a 56KHz processor. Someday you'll probably wonder the same thing about today's Multi-GHz processors!
I began programming in BASIC guided by a book from Radio Shack that was geared to the TRS-80. Since I had no computer I had to put my programs down on paper and follow the logic in my head. I probably kept this up for 6 months or more before I got hold of a computer to test them out on. Needless to say they were full of bugs and misunderstandings.
But I learned about: variables, flow control, decision logic, loops, etc.
I programmed BASIC for a long time - first on a Sinclair ZX-80, then on Apple II computers at a local radio shop, then on the (amazingly powerful) Atari 400. What kinds of programs did I write? Well, games of course! I wrote the kinds of programs I was interested in having at the end of the long - often tedious -process.
This is what I recommend first to all new programmers. Write the programs you really want to write. Your attention won't flag and you'll enjoy the process so much more.
One thing about writing games in BASIC is that as your ideas become more ambitious the language starts to show its limitations. I was fortunate that there weren't a lot of choices back in 1979. It was BASIC and Assembly Language and little else. There was this strange thing called 'C' I heard about back then but I had no clue what it was about. So when my games needed more speed I went on to 6502 Assembler using the awesome Atari Macro Assembler.
Through Assembly Language I learned about registers, stacks, storage, condition flags, test-and-branch, and memory-mapped devices. PEEK() and POKE() had hardly prepared me for the joy of controlling the processor and hardware directly.
I kept on with Assembly Language for a long while, and when I moved up to the Amiga computer I was well-prepared to start writing programs in 68000 Assembly Language. I kept on with the Amiga and 68000 Assembly for another good long time - until about 1990 or so.
Yes, I completely eschewed the horrid little gray-screened Mac because my wondrous Amiga had such powerful graphics and sound hardware.
I abandoned programming altogether for a few years - from 1990 to 1996 - and focused my attention on more essential aspects of life: music, poetry, and girls.
Then I got the itch to get back to programming again. I bought a cheap PC and wrote silly programs in QBASIC for awhile. When I finally had enough money I bought my first Macintosh, an 8500/150. My intention was to continue with 68000 Assembly and then move up to PowerPC Assembly. But when I started reading about the PowerPC it became clear that I needed to learn C. The reason for this is simple. Modern processors are just too complex for ordinary humans to program them efficiently in their native language!
Now I'm about to break my own rule and make a radical assertion, but bear with me:
C is the mother of all modern programming languages, and every serious programmer must learn it.
C was created with a very specific purpose in mind: To provide the most bare semantics for the things that CPUs do. C encapsulates - very elegantly - the standard operations of a "theoretical" processor. It deals directly with essential concepts of memory, conditions, and program flow. It gives the new programmer a foundation to understand what higher-level languages are doing "under the hood" at the most fundamental level. In my experience, knowing what's going on behind the scenes provides a kind of intuition that proves invaluable in many circumstances. And that kind of intuition "scales well" because the same fundamentals appear throughout the programming universe.
So I began programming my first Mac program in C, learning as I went along.
And that's another thing! Never, ever, in my 25 years of programming have I had the remotest clue what I was doing at the beginning. I had a basic idea of what I wanted to realize. I had enough knowledge to be dangerous. Every new project has been a leap of faith. You have to know ahead of time that you're going to get stuck, you're going to get lost, you're going to go a thousand lines in the wrong direction, you're going to have to scrap tons of work and start over. But you're going to get unstuck, you're going to find your way through, and you're going to write better stuff the next time around. Most of all you're going to discover something new at evey turn. Ah, how fondly I recall that shining day in my geeky youth when binary finally made sense....
So yeah, I eventually got the hang of C. I tried to do some things in C++ but OOP was so new and different that I kept getting stuck in self-doubt. Was I implementing my classes in the right way? Was I properly isolating my Model from my View from my Controller? Ach, the struggle of learning OOP was almost more than I could bear. I tried using frameworks like MacZOOP and MacApp but it was hard for me to use Someone Else's Code. I had never done that before! So I just stuck with C, kept revising my application - which had grown good enough to release as shareware - and occasionally toyed with REALbasic for quick prototyping.
Now, I had done programming as a job back in the early 90's, but it was very informal. Just a bunch of friends in a rented house making silly games. But in 1999 I got my first Real Programming Job making websites with Embedded Perl.
In my job interview I explained that I didn't know perl, but my interviewer knew about the aforementioned reality that programmers are used to being beginners and knew I'd pick it up quickly enough.
And I did. Perl is semantically identical to C. (For that matter, so is PHP, Javascript, and to a large degree Java.) The hardest thing to learn in perl was Regular Expressions. Anyhow, because I had learned C it was much easier to learn perl. I mastered the basics in less than a day. So my first Real Job as a programmer turned out okay.
I'm now on my second Real Job, still making websites, but now I code in PHP. It was another quick learning curve, except that my employer had already built an OOP framework for e-commerce websites.
Uh-oh! OOP was back and it wasn't going to go away this time. Fortunately I was surrounded by a dozen experienced programmers who could answer any of my newbie questions. And most of them didn't even know PHP, they just understood OOP. It also helped that the authors of the framework were at my disposal.
Now, when I was learning C the Internet was brand new. There weren't any web forums like this one. But there was UseNet, and I posted my questions there often. And there was the MOST mailing list. Still, you young whippersnappers don't know how good you've got it!
While I think you really ought to learn C and write some programs in it, those who say you should choose the right tool for the job are absolutely correct. I make websites using a wide range of programming languages now: Javascript for inline form validation, PHP for building pages and interacting with the database, SQL for database operations, Perl for server-centric periodic tasks, shell scripts for file management.... the list goes on. At home I'm using C++ with Simple DirectMedia Library (SDL) and OpenGL to write an action game that will be deployed on Windows, Mac, and Linux.
Did I mention I do all my work with Macs? My employers are total Mac-heads (unlike my last job where I brought in my own Mac to work on).
I believe you can learn to program - and program well - using any language. Each one has its strengths and shortcomings. You'll do best just to choose your project and jump right in. If you're going to make a real-time action game you'll get your best performance writing it in C or C++, but you can get acceptable performance using Objective-C, REALbasic, or even Java. You'll need to learn the appropriate APIs (Application Programming Interfaces) to do graphics and sound, and each language does it differently (but similarly). Again, knowing the C interfaces will give you the most direct view of what's "really" happening. I chose SDL because it makes it easy to write programs that can be written once and run on many platforms. I chose OpenGL over Quartz or QuickDraw for the same reason. If I'm going to spend a year or more on something I want the knowledge I gain to be broadly useful.
You're embarking on a real adventure, and I wish you the best. You're fortunate to have so many choices and to have access to such advanced hardware as we have these days. Sometimes I wonder just how it was that I could work on an Atari with 48K of RAM and a 56KHz processor. Someday you'll probably wonder the same thing about today's Multi-GHz processors!
Easter
Cypherpunk
Hi All,
I'm agree with you Slur ... there are the right tools for a work, not one do-all-works tool.
I'm either agree with you when you say that modern processors are too complex to program them in native language; that is necessarely only when is needed maximum efficiency (and that is require only on very small portions of code).
The C Language is just a little bit at higher level than Assemly so now that we have a very large choose of programming languages it's possible to use more "human friendly" languages (*always* "translated" to assembly machine code).
The same things apply to programming paradigms ... functional programming is always used (the processor execute sequential code ... with some enhancements like super-scalar but that is not the point ...); functional programming is more near processor "mode of work" than human ... a more abstraction in programming paradigms is Object Orientation, Patterns, etc ...
So it's more easy and less time consuming to use model near human thinking than machine model of "thinking". Again it will be more efficient stay near the processor but that is required only in small portions of a "normal business" work (we are not talknig about NASA control software, or life support, or industrial real-time control, etc ...).
I think:
That the better things to do is starting with something that it's easy to human work so, despite the programming language, the OOP it's better in building common user software.
A general purpose programming language that use massively OO is Java (if you have to do a specific type of software you have to chose specific languages and specific programming paradigms).
Once acquired OO concepts it's not difficoult to learn functional programming (but not the opposite), event and messages are somehow "embedded" in OOP but not in functional paradigm that use almost always sequential programming.
I end telling you that now that we have much powerful tools it's better to use them. (to "downgrade" is ever possible, to "upgrade" is not so easy).
Byez_
I'm agree with you Slur ... there are the right tools for a work, not one do-all-works tool.
I'm either agree with you when you say that modern processors are too complex to program them in native language; that is necessarely only when is needed maximum efficiency (and that is require only on very small portions of code).
The C Language is just a little bit at higher level than Assemly so now that we have a very large choose of programming languages it's possible to use more "human friendly" languages (*always* "translated" to assembly machine code).
The same things apply to programming paradigms ... functional programming is always used (the processor execute sequential code ... with some enhancements like super-scalar but that is not the point ...); functional programming is more near processor "mode of work" than human ... a more abstraction in programming paradigms is Object Orientation, Patterns, etc ...
So it's more easy and less time consuming to use model near human thinking than machine model of "thinking". Again it will be more efficient stay near the processor but that is required only in small portions of a "normal business" work (we are not talknig about NASA control software, or life support, or industrial real-time control, etc ...).
I think:
That the better things to do is starting with something that it's easy to human work so, despite the programming language, the OOP it's better in building common user software.
A general purpose programming language that use massively OO is Java (if you have to do a specific type of software you have to chose specific languages and specific programming paradigms).
Once acquired OO concepts it's not difficoult to learn functional programming (but not the opposite), event and messages are somehow "embedded" in OOP but not in functional paradigm that use almost always sequential programming.
I end telling you that now that we have much powerful tools it's better to use them. (to "downgrade" is ever possible, to "upgrade" is not so easy).
Byez_
Actually Java was not designed as solely a general purpose programming language, it was designed for programming embedded systems an the internet (Applets)! Well it has improved so much, it's functionality has extended.
I mean instead of PHP you could use JSP.
But then again ur sacrificing performance!
I mean instead of PHP you could use JSP.
But then again ur sacrificing performance!
Easter
Cypherpunk
Hello Wiz,
I'm not agree with you because actually Java has become very powerful (using Sun JDK and J2EE) and fast as a compiled C software (thanks to the JIT Compiler)
Nowadays the JVM is very optimized (except on Solaris-Sparc), and the stndard library offers many objects to deal with UI, Sond, Graphics etc ... There are some libraries to build real-time 3D games using Java (and OpenGL) ... and they do!!!
JSP code is "translated" to a servlet once the Web Application Server engine starts so it's fast as a "native" Java class; the JVM for server environments are optimized to deliver more performance than the standard client JVM so there is no difference between PHP, ASP, JSP about performance ... then use the language you prefers.
Bye, byeZ_
I'm not agree with you because actually Java has become very powerful (using Sun JDK and J2EE) and fast as a compiled C software (thanks to the JIT Compiler)
Nowadays the JVM is very optimized (except on Solaris-Sparc), and the stndard library offers many objects to deal with UI, Sond, Graphics etc ... There are some libraries to build real-time 3D games using Java (and OpenGL) ... and they do!!!
JSP code is "translated" to a servlet once the Web Application Server engine starts so it's fast as a "native" Java class; the JVM for server environments are optimized to deliver more performance than the standard client JVM so there is no difference between PHP, ASP, JSP about performance ... then use the language you prefers.
Bye, byeZ_
hey buddy PHP is hell a lot faster than JSP, or ASP.
as a matter of fact ASP is faster than JSP!!
BTW: i know the JVM is optimized. It is fast. VERY! But it still needs to improve. It's not like they reached The Limit or something. If you try out a complex GUI (swing) app you'll notice the difference in performance (speed, yess! speed).
But I must say, till now, the Java Platform is The Best development environment out there.
But then again ... there is .NET,,, AAAH!!!
as a matter of fact ASP is faster than JSP!!
BTW: i know the JVM is optimized. It is fast. VERY! But it still needs to improve. It's not like they reached The Limit or something. If you try out a complex GUI (swing) app you'll notice the difference in performance (speed, yess! speed).
But I must say, till now, the Java Platform is The Best development environment out there.
But then again ... there is .NET,,, AAAH!!!