macOS Programming: some people can, some people can't?

[superbovine]

I said "yesterday" in that post back in February, so I don't know if I can figure out what I was reading then, but I'll take some educated guesses and see if I can find it.

oh didn't look at the date, my bad. don't trouble yourself to much.

 

[MarkCollette]

I have "professional disagreements" with educators who think you should start with assembly language programming and work your way up. I agree with the "up" direction, but not with the starting point.

I think it's useful to learn about assembly language programming, and the fact that computers have registers, opcodes, instruction sequences, and what RISC, CISC, pipeline, multiprocessor, interrupt, and other terms mean, but I think it is not the best use of time for university students to spend weeks hand-writing their own SPARC code, as at least one university program I know currently favors. That's like having homebuilders grow the trees instead of starting by buying lumber. It's worth understanding low-level computer principles, but assembly-level coding, even for embedded systems, is less important each passing day and is better left for experts or specialists. It shouldn't be put there as an obstacle (which it often is) for beginning programmers.

I'd like to make a distinction between several aspects of low level programming. I think it can be divided into two groups:

1. Simple basics. Eg:

• Registers
• Opcodes
• Instruction sequences
• Memory
• Bits, bytes, 2's complement numerical representations

2. Advanced. Eg:

• RISC, CISC
• Pipeline
• Multiprocessor
• Interrupt

I believe that all programmers should start with the Simple basics. Some programmers in niche environments may well choose to pickup the Advanced low level stuff too.

That said, I think you appreciate and understand modern programming better when you understand what the machine actually does, what an interpreter like BASIC does, what a language like C or C++ is best (and worst for), and why languages like Java and Objective C have their current positions among our tools. To be well rounded, you should "experience" nonprocedural languages, scripting languages, etc., not to master each one, but to understand that programming is not limited to one language, tool, or approach.

Even those are all imperative languages. There are also languages from completely different paradigms, like functional languages. Apparently Python has done a good job of taking concepts from both worlds.

Students who start with Java and then learn lower-level languages may think of lesser languages as stupid or frustrating, whereas students who learn "going up" (which is approximately the same as learning about programming languages in a chronological order) get a better feeling for how the evolution of languages has added convenience and safety to what we do.

True. Although, although, as your say, it's not really chronological per se. Most programming concepts were discovered by the 1960s, and not much of anything new has happenned since the 1980s. It's just that some of these ideas have gone mainstream. For example, Lisp predates Basic and C.

 

[Doctor Q]

I'd like to make a distinction between several aspects of low level programming. I think it can be divided into two groups:

1. Simple basics. Eg:

• Registers
• Opcodes
• Instruction sequences
• Memory
• Bits, bytes, 2's complement numerical representations

2. Advanced. Eg:

• RISC, CISC
• Pipeline
• Multiprocessor
• Interrupt

I believe that all programmers should start with the Simple basics. Some programmers in niche environments may well choose to pickup the Advanced low level stuff too.

As long as it's only a survey of the meanings, the advanced concepts could be part of a single lecture. But that's a minor point. All of it would be useful for those majoring in computer science, but lots of business majors, English majors, etc. also take introductory computer science courses, and perhaps very little of this is relevant to them.

Even those are all imperative languages. There are also languages from completely different paradigms, like functional languages. Apparently Python has done a good job of taking concepts from both worlds.

Good point. Perhaps Prolog is a good choice, because it is straightforward and simple programs can be explained, or even written, in a very small amount of time.

True. Although, although, as your say, it's not really chronological per se. Most programming concepts were discovered by the 1960s, and not much of anything new has happenned since the 1980s. It's just that some of these ideas have gone mainstream. For example, Lisp predates Basic and C.

McCarthy's LISP had the amazing feature that it was extremely low level (dealing with registers) yet was a big leap forward in the development of programming languages. The phrase "lambda calculus" may scare some people away but the concept is still around in various other guises.

Only somebody familiar with LISP could explain why "caaadadadr" is a valid function in LISP despite having no hits in Google (until this post gets indexed, that is).

 

[barneygumble]

One of my University of Alberta CS professors, Alan Supynuk, said that what makes a great programmer is the ability to use both sides of the brain equally, the engineer and the artist. He explained this by asking us to imagine we are standing on the top of the CAB (Central Academic Building) (almost the center of campus, too) and looking north. On the left are mostly the scientific/engineering buildings and on the right are mostly arts buildings. This is quite analagous to how the brain works. And a great programmer is able to borrow heavily from both sides. Good programming isn't just a science, it's also an art.

P.S. He also joked at our grad party that only a programmer would read the instructions on a shampoo bottle and think, "This is an infinite loop": Lather, rinse, repeat.

That explains why C++ was my worst subject at uni, the art part of my brain does not function. I am the least creative person in the world!!!

 

[MarkCollette]

As long as it's only a survey of the meanings, the advanced concepts could be part of a single lecture. But that's a minor point. All of it would be useful for those majoring in computer science, but lots of business majors, English majors, etc. also take introductory computer science courses, and perhaps very little of this is relevant to them.

I was thinking of a few solutions to the problem of how to handle non-majors taking intro courses.

First off, I wouldn't change the program for the majors, to cater to the non-majors. If it has to be suboptimal for one, then it should be for the outsiders.

Next we have to decide, what is the goal? What are we trying to teach to the business majors, etc.? Is it simply how to use a computer, or how to write software? Where I went to school, there were computer science classes specifically for non-majors, which could not count towards a degree in computer science. Those classes taught how to use MS Office, and Windows, etc.

But what about science or math majors, who need to write simple mathematical programs? Then probably some courses that teach simple structured programming would be best. Maybe offered in variants for C, non-OOP C++, or Fortran.

Maybe the non-major programming courses could build up to enough OOP understanding to cover some Javascript or VBScript.

But in no way should those focussing on computer science receive this watered down approach.

Good point. Perhaps Prolog is a good choice, because it is straightforward and simple programs can be explained, or even written, in a very small amount of time.

McCarthy's LISP had the amazing feature that it was extremely low level (dealing with registers) yet was a big leap forward in the development of programming languages. The phrase "lambda calculus" may scare some people away but the concept is still around in various other guises.

Only somebody familiar with LISP could explain why "caaadadadr" is a valid function in LISP despite having no hits in Google (until this post gets indexed, that is).

I was sitting there for a few minutes, when writing my post, trying to remember a Logical language, like Prolog, as you mentionned. Had to give up. Thanks for the reminder.

I'm one of those guys who will never make assumptions about operator precedence. I just put the brackets in. If I see someone using a functional language's lack of brackets to delimit nested function calls, then I take out my pocket protector and beat them to death with it

 

[darkwing]

You are right. Some people can, most people can't. Some of the posts in this thread prove my point entirely. Anyone can learn syntax. Very few people seem able to really understand and grasp the concepts of what's going on and how to do things the most efficient way. What I've found in my professional career is that all the people who are on time with fast efficient code agree with everything I say and vice versa.

I wrote my first program when I was 6. I learned BASIC on an Apple II on my own as soon as someone showed me how to list and edit my own files. The simple fact is, I was fascinated with it and I saw patterns in the syntax. The knowing of what went on behind the scenes came later, but it did come.

Now, I'm a professional in the medical device industry who does a lot of hard realtime systems (everything built on my Mac, but often cross compiled to x86 linux) and when you're dealing with software where microseconds count, you have to be good. However, if you want to hobby around with it you should do ok just ask people for help where it's needed. If you have any C++ or Java questions, feel free to contact me privately and i'd be happy to spend a little time with you discussing things online.

OOP is not a syntax. It's a set of ideals. The best thing you can do if you want to learn is what you've already done. Admit you suck. The second you think you know everything, you'll stop growing. I know I have a lot of things to learn and I don't kid myself about it. I also consider myself "good" though.

Steven

 

[Doctor Q]

I'm one of those guys who will never make assumptions about operator precedence. I just put the brackets in.

That's a good habit for nontrivial expressions. Not only does it keep you from having to remember the precedence order for whichever language you are using, but it helps someone reading your program too.

You've reminded me of a very old thread about a precedence case I tripped over.

The APL programming language (which stands for "A Programming Language") has an extremely simple but at the same time unusual precedence rule. It's sensible given that there are way too many operators (note: actually called "functions" in the language's terminology) to assign an order to. It can be a source of confusion for beginners but after a while becomes quite natural to use. Expressions of the form

value operator value operator value operator value operator value ...

are treated as follows (unless parentheses override):

value operator (value operator (value operator (value operator value ...))

The operations are performed left-to-right but grouping is right-to-left. Therefore, when you start an expression with

2 x ...

the result is guaranteed to be twice whatever the rest of the expression is, no matter what operators it uses. For example, if you know that the perimeter of a rectangle is twice something about the sides, you can write

2 x

and then figure out the formula required

2 x width + height

without having to add parentheses. If you are used to APL, it reads naturally. If you aren't, it can be misleading.

 

[Omen88]

I'm one of those guys who will never make assumptions about operator precedence. I just put the brackets in. If I see someone using a functional language's lack of brackets to delimit nested function calls, then I take out my pocket protector and beat them to death with it

Well then you probably love the prefix notation of Scheme and Lisp.

But I gotta say you're right, I use braces too for non-trivial operations.

 

[Doctor Q]

Do you have a link for that article?

I found it! It was an old article I had come across again.

The article was named "Everything is Fortran, in its own way", by Alan Creak, and was in the April 2003 issue of ACM SIGPLAN Notices. I found the ACM web page for it, where SIGPLAN members (like me) can download it. You can find other sites that mention it by Googling the article title.

 

[whooleytoo]

Hehehe.. Yes, thanks. I typed it all out on the fly, so I hope I didn't miss to many things.

Thank you! It was an interesting read. As someone who used to have to debug other people's code in assembly, it nearly brought a tear to my eye! (How sad am I???)

 

[superbovine]

I found it! It was an old article I had come across again.

The article was named "Everything is Fortran, in its own way", by Alan Creak, and was in the April 2003 issue of ACM SIGPLAN Notices. I found the ACM web page for it, where SIGPLAN members (like me) can download it. You can find other sites that mention it by Googling the article title.

thanks doc

 

[whooleytoo]

While this is slightly OT, I believe the nature of software development is starting to change too. If you look at the way Apple and Microsoft are plugging the gaps in the market (mail clients, web browsers, movie/photo editing tools etc.). Hence I believe small, independent developers are going to be doing more plug-in development (internet plug-ins, widgets etc.), and customisation (say, Webkit based browsers with a specific purpose/client in mind), while Apple provides the 'services' (movie & sound playback/editing - QuickTime, Internet browsing - Webkit etc.).

This could potentially change the skill set required for up and coming developers, where scripting and design abilities might be more relevant than low-level knowledge and experience (though IMO they should always be present).

 

[yellow]

5300cs, I'm with you. I cannot seem to learn programming from a book. I always seem to get to a point and then get stuck. Never tried it in a classroom setting. And I'm not a dunce...

 

[jazzmfk]

I wish man. 8 years of piano, and 6 years of percussion/drums. 5 years of all-county/all-state band.

...Didn't help one bit in my programming -_-.

I've heard it said that back in the "early days", tech people actually recruited music majors because of the similarities between composition and programming. Evidently it isn't the years spent in performance, but the analysis, study of form and structure, and the combination left brain/right brain that are utilized both in composition and in programming.

In grad school back in the early 90's, we learned Turbo Pascal and C++, and some other object-oriented thing that was developed by our prof at columbia. I really liked it, but I didn't feel my music background helped as much as the simple fact that it felt like I was solving a puzzle. It worked something like this:
visualize what you want to do
try it
get annoyed when it doesn't work
revise it to make it work
visualize the next step - but think deeper to avoid wasting time
try it
- vamp 'til completion -
go celebrate!

Kinda like playing with a Rubik's cube but without the satisfaction one gets by chucking it across the room in frustration....that gets expensive with your computer.

MFK

 

[MarkCollette]

That's a good habit for nontrivial expressions. Not only does it keep you from having to remember the precedence order for whichever language you are using, but it helps someone reading your program too.

You've reminded me of a very old thread about a precedence case I tripped over.

The APL programming language (which stands for "A Programming Language") has an extremely simple but at the same time unusual precedence rule. It's sensible given that there are way too many operators (note: actually called "functions" in the language's terminology) to assign an order to. It can be a source of confusion for beginners but after a while becomes quite natural to use. Expressions of the form

value operator value operator value operator value operator value ...

are treated as follows (unless parentheses override):

value operator (value operator (value operator (value operator value ...))

The operations are performed left-to-right but grouping is right-to-left. Therefore, when you start an expression with

2 x ...

the result is guaranteed to be twice whatever the rest of the expression is, no matter what operators it uses. For example, if you know that the perimeter of a rectangle is twice something about the sides, you can write

2 x

and then figure out the formula required

2 x width + height

without having to add parentheses. If you are used to APL, it reads naturally. If you aren't, it can be misleading.

I think that's called "right associative". Luckily most languages now-a-days just follow math rules, otherwise I'd go crazy.

 

[zimv20]

yes, i'm reviving an old thread, but i only just read through it. lots of stuff i agree, lots i don't, but this post really captures it:

First, the question of whether programming is for you:

- Do you look at the world around you with curiosity?
- Do you think about how every large thing is composed of smaller and smaller parts?
- Can you plan something out, methodically, step by step?
- Can you take each of those steps, that anyone would take for granted as being completely obvious, and break them up into even smaller steps, so that a complete and utter idiot (computer) could get it done?
- Can you take multiple competing criteria, and find a solution that meets all needs?
- Can you compromise?
- Would you be comfortable describing yourself as a professional problem solver?
- Can you think analytically, scientifically, and logically?
- Do you want to spend the rest of your life learning new things?
- Can you, given a good book or website, teach yourself?
- Do you want to create?

i often see people confuse "learning to progam" with "learning a programming language". though related, they're not the same, just as learning to speak is not the same as learning a language.

i've got a computer science degree and years of professional experience. here are some traits i've seen in good* developers:

1. the ability to abstract
2. the ability to simultaneously consider multiple levels of detail
3. the ability to context switch
4. an obsessive attention to detail
5. a healthy dose of irreverance
6. a desire to go back and improve what's already working

* meaning roughly 1 in every few hundred i come across

these are things which pretty much can't be taught, only improved upon. imo, good programmers are born, not taught.

 

[Fender2112]

Motivation is the key in programming. Motivation, patience, and logic. All the rest is just syntax.

Well put.

 

[caveman_uk]

...
I've been trying to learn programming for a long, long time. The problem is that I just don't get it (I suck at it.) I've tried Perl, Java and C++ and find them extremely complicated.
...


I am currently working under Windows, Linux, Mac Os X, Pocket PC using C, C++, C# and Java. I also had been developing for 5 years with Turbo Pascal (from 4.0 to 8.0)...

I used a simple method to learn a language:

1) identify a small initial application, which covers various "problems", like user interface, database or data archiving. A simple addreess book could be a quite good example.

2) Focus on a language initially. C is quite hard for someone which is not used to "pointers". I guess Java could be an easy language, since it is well documented and there is a GREAT LOAD OF SAMPLES and forums around the web.
I also suggest you to use Eclipse as IDE. It's fast and free.

3) Go to a bookstore with a good computer science section. Look at a good book with contents about your current objective. A book with MANY pages is not always a BIG book... Choose carefully.

4) Now you have a basic guide to follow. Read it and begin to build your "wanted" application. Try to break the application into "small" applications/functions (like saving a text file, opening a window, etc) and solve them in a separated way. Then put together all these small results to obtain your big final result. This is called "Divide Et Impera".

Your first application usually looks like an "experimental" app... but you will also be satisfied.

I found this the best way to pick up Objective-C/Cocoa. You can read as much as you want but you'll learn so much just doing a small application (not too trivial though - think address book not temperature converter ).

 

[Cue]

yes, i'm reviving an old thread, but i only just read through it. lots of stuff i agree, lots i don't, but this post really captures it:

Good thing you did! I was sucked into it right until I reached your reply and noticed the date!

Someone commented on whether CS is considered to be Science or Art. I was once asked the same question on an interview when looking for a placement!

Since there is already a lot of input in this thread I'll just say this.

Programming is like painting.
Anyone can paint, not everyone is a painter.

 

[darkwing]

edit: i'm not going on the forum before 6 am anymore..i just typed all this up on a thread that's over a year old. *sigh*

I think some people can, and some people can't. When I was 6 years old, someone showed me on an Apple II how to do:

10 ? "hello"

From there, I looked at other files and after about 2 weeks wrote my first game. It was a series of illogical yes/no questions, but it was a game nonetheless. Ever since then I knew what I wanted to do..write software! And as a software engineer now who is 1 quarter and 2 weeks from a masters degree in computer science, I guess that's what I've become. I wrote my first shareware app at age 14 (datasnd, a program to convert VOC/WAV files to system 7 double clickable sounds..anyone remember that? only three of you jerks regged it) and I was doing odd jobs for schools or businesses since age 12.

One thing I have learned is that anyone can learn a syntax, but not everyone can learn the concepts. This even applied to me at one time. I've gone from "let's see if this will work" to knowing before I type a single line of code if something will work, in most cases. (This isn't the case for some lab related algorithms, where say I'm trying to control the temperature 5 cm away from an RF electrode immersed in jello, or something. That requires testing and tweaking.)

While some people are more "natural" at it than others, there's always the matter of practice makes perfect. If it's something you truly love and are passionate about, you'll figure it out eventually. However, I work with a lot of so-called PhDs who can't even understand OOP. (Let alone simple operations.) The industry is full of those who say they can, but can't. I've only worked with one programmer I consder very good, and it was this guy who came here right out of UC Berkeley and was rather bad, until he worked with me for about a year and took the approach that "wow maybe I can learn something." That was always my biggest problem growing up...thinking I knew everything.

If only I could work with people better than me, I would become even better.

You have a good resource...the forum! There seem to be a lot of competent programmer types here. Ask away.

 

[macdong]

I think one of the major hurdle that programmer faces is the lack of preparation works before "attacking the code". You've got to spend time doing Organigram and Flow chart. Work on your logic on paper. Visualize your program. You can even write speudo-code before "Coding".

For some, the preparation phase is all in their heads : It's a given talents. For others, thoses previous steps are necessary for making it.

(BTW, I've also starting to learn japanese, not that hard when you put your mind into it.)

i think you are getting a bit too far down the way

 

[ChrisA]

You may be going at it backwards

I've been trying to learn programming for a long, long time. The problem is that I just don't get it (I suck at it.) I've tried Perl, Java and C++ and find them extremely complicated.

Here is the problem: There is a difference between programming and learning Perl or C++

Just like with natural languages. Learning to write is not like learning German. Writing is organizing your presentation in a logical order and adding facts to make a point or writing is making a story that people will want to read. Learning German is just rembering which of der, dos and so on to use and when plus a mess of vocabulary.

So it is the same with programming. To write a progam you must fist have a very clear understanding of what it is to do. You write it down (in English) and draw pictures and show it to the client and say "this is what I'm going to build. It this what you want?" finaly you agree. Next you think of all the parts and how they relate and interact and the functions that the parts have and the type of data that get passed around. Once you have this worked out you can think about C++ or Perl.

When it gets to wrinting code, there is no why around it. You just have to kow tons of trivia, mostly about the environment the code will run in. The Window system, the OS the libraries you will use. But this is easy if you already know you want to (say) display a warnnng in a dialog box you can hunt down an example of doing that. the hard part is working out when these warning need to go up

Mostly when peole fail it's becaue they don't know in detail what it is they are settig out to build and what parts they will useto build it.

The way to learn is start small with a very well defind project like writting a program that wil print the words "Hello World" and then terminate. then modify it to say ask for your name then say "Hello <yournamehere>".

The programming language does not matter. Whatever you lern will go out of style and they will invent new ones. Te trick is to learn to program and you will just "suck up" the languge in the process, lke you learn natural langue by just trying to communicate and you pick up vacabulary and grammer in the process.

 

[paddy]

I'm in the process of deciding which course to do for college. I am in secondary (High) school and I am considering computer science. What I need to know is, how important is Higher level maths, or how important is it to have a good understanding of maths?

If its any help in our aptitude tests I scored highly in the mechanical and language tests, but poorly in the math tests.

 

[superbovine]

I'm in the process of deciding which course to do for college. I am in secondary (High) school and I am considering computer science. What I need to know is, how important is Higher level maths, or how important is it to have a good understanding of maths?

If its any help in our aptitude tests I scored highly in the mechanical and language tests, but poorly in the math tests.

Computer Science is defined as the application of math, hence higher level math is pretty important. Calculus, stat, linear algebra, discrete math, logic, diff equations (maybe) are all required to get a CS degree.

Having a good math background will help you express problems programmatically in the most efficient way, or just plain solving a problem might require you to bust out some math. For example, rotating a cube 90 degree in 3 space. How about if someone asked you to write part of a program that has to produce statistic on data points? What about calculating the most efficient way to sort a set a data?

 

[Chacala_Nayarit]

Haha object-oriented. Everytime I hear that word it makes me cringe. Like listening to my Java prof droning on and on, while everyone nods.

Then when you ask a question, he denounces you publically in front of the whole class. In a word: Weeder course. I don't know how I did it, but I pulled an A- in that class, but I will forever hate programming for the kinda sh*t I had to go through. Not fun.

Side note:

I take classes, like Java, online. No reason to put up with arogant ****wits.