Is "parameter passing" between methods/objects difficult for younger people to

bill190

I'm curious about something...

I finally got some time to begin reading the documentation on the Propeller I recently bought...

I was reading chapter 5 on methods and cogs in the Propeller Education Kit Labs book, and it discusses "parameter passing" between methods and objects, etc.... I was thinking... Yea, yea, yea...

Then·I suddenly realized this·concept might be quite difficult for a younger person to grasp! Someone who grew up with just windows computers and·never used MS-DOS or UNIX command line prompts?

Then I got to thinking... Older people used these systems everyday where you had a prompt, you would type a command, then something for that command to do. Something like this...

C:\>Print mytextdocument

...would print the file mytextdocument on the printer.

So this is easy for me to understand that you have a "program" or a "method" or whatever and you give that program "instructions" as to what it is to do...

But I would think this would be quite difficult to explain to someone who grew up with windows?

Computers these days are pretty far removed from the way things work inside.

So the question is, if I were young today and not exposed to command line "arguments" (as they are called), would I be totally baffled by the concept of "passing parameters" between methods/objects?

·

heater

@bill190: I look at it like this.

When I was a teenager the were no such things as computers. At least not in the experience of the vast majority of people. As a consequence there was no idea of programming in my mind, no programs, no instructions, functions, methods, parameters or any such concepts.

However after one week in technical school we had exposure to BASIC and were quite happily writing our first programs. I don't remember anyone having any major difficulty with those basic ideas.

Fast forward to today. There is no such thing as a computer. At least not in the experience of the vast majority of people. A crazy statement you may say given that the world is swimming in PCs. I don't think so. Most of those machines have no programming facilities on them. They have WEB browsers, they have games, etc etc but for all intents and purposes, out of the box, they are not computers. Unless someone is inspired to set themselves up with some dev tools.

So youg people today seem to be in much the same situation that I was all those years ago. The ones that some how get inspired to delve into programming or otherwise exposed to the idea will get along just as well as we did.

Now specifically talking about parameter passing.

From a very tender age we were studying algebra in school. So straight away we have such things as y = x * x.
That is the idea of variables is it not. Soon we are talking about functions y = f(x) and so on. The whole idea of "algorithms" is kicked of with a basic maths education, consider generating the fibonacci sequence for example. The basic idea of "program" is there already.

So anyone with a minimal education already has concepts of variable, functions, parameters in their mind. Transferring those concepts over to programming, variables, functions, methods, parameters is not a big leap.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

ErNa

It it always challenging to find the concepts behind the scene. Independent of age. "obvious" does not mean: easy. So there are two way to control the flow of workpieces in a factory: take a workpiece from the input, process it and send it to the next station. Or: take a workpiece from the previous station, process it and put it aside. This can be told: pushing and pulling. The same is true for programing paradigms: call a subroutine or wait, until a subroutine takes the input. It depends on the hardware available. In case of the propeller, a cog may wait for data to be ready, process that data, and place the result somewhere. Or you start a cog, pass parameter to it and stop after finished. In the first case, the cog may spin, but not work. In the second case, the cog has to be loaded, what consumes time, but is free, when not used. And there also might be a mixture of both concepts. Anyway, there has to be unused capacity and as it normally is not a big difference, if a cog is running or not (only power consumption), the propeller opens a way to have processes running and waiting for tasks to do.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

heater

Ah yes ErNa. Now you have taken us to the level of multi-processors and parallel execution where the original post started with just parameter passing to functions/methods.

Here we enter a whole world of extra complication. Much of that is inherent in the ideas of spreading some algorithm over many processors. For some algorithms that is easy. For other it is not, or perhaps an entirely different approach to the problem is required for a parallel solution. There are the issues of scheduling, communicating, sharing data etc etc.

Much of the complexity though exists at the implementation level. The mechanics of passing parameters from COG to COG, especially to PASM running COGs, and then having them communicate are quite primitive, low level and complicated to do in Spin/PASM. I would not expect youngsters, or anyone, to grasp any of that with out a good grounding in single CPU programming in Spin/PASM first.

On the other hand in some languages parallelism is a lot easier to grasp at the higher level. For example, to run two functions at the same time you might simply write:

par
{
    uartTX ( tx );
    uartRX ( rx );
    lcdDrive ( lcdData );
    kbListen ( keys );
}

and bingo you have your device drivers all up and running.

What are all those tx, rx, ... parameters. Well they are the means by which you will communicate with the device. Predefined "channels" that can be read or written just like variables.

This kind of high level language approach to parallelism makes the whole thing much easier to deal with than the mess of shared memory and pointer passing that we go through in Spin/PASM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

MagIO2

I think heater is right when he says that the youngsters have the same preconditions as we had. BUT I also believe that the expectations today are much higher. In early days of computers you were happy to have a text-display showing you the fibonacci sequence. Today computers are everywhere and do such amazing things ... they are rendering films ... they have reality like games ... you have touch screens and gestures ...
In short: You handy can run more sophisticated applications than you'd be able to program by yourself as a beginner.

If a youngster starts with programming he want's to do exactly that, not realizing that it's a long path down the road to learn all that. Many of them give up because they are dissappointe by what you can do as a beginner.
But here I think mikrocontrollers have a big advantage. You can start with a lot of little projects that are easy enough for youngsters but give you enough satisfaction straight away for going on on that long road. And you'll learn about the basic concepts that you'll later on need for bigger projects.

And the propeller is even better than all other mikrocontrollers for learners. You don't have to bother with interrupt programming - which is a PIA and is needed very soon to do something meaningfull on other uCs.

Writing these lines I think we should maybe start a "little projects"-page - maybe in the wiki? What do you think?

Post Edited (MagIO2) : 4/24/2010 12:59:12 PM GMT

sylvie369

MagIO2 said...

If a youngster starts with programming he want's to do exactly that, not realizing that it's a long path down the road to learn all that. Many of them give up because they are dissappointe by what you can do as a beginner.
But here I think mikrocontrollers have a big advantage. You can start with a lot of little projects that are easy enough for youngsters but give you enough satisfaction straight away for going on on that long road. And you'll learn about the basic concepts that you'll later on need for bigger projects.

I think you're hitting on an important thing here. I've come across people who just can't seem to get the point that all of those little boring things (lighting an LED, reading a switch status, putting a string on an LCD screen) add up eventually to interesting projects. You've seen 'em here - the folks who say "I'm just starting to get into electronics, and I want to know how to build a self balancing autonomous robot that is guided by GPS", and then get frustrated when someone tries to tell them something about turning on and off a motor.

On the flip side, there are the people (most of us, I assume) who get excited about successfully reading a switch status, because it means we can tick that task off in our heads as "accomplished", and move on to projects that put it to use. I've got a Ping here that I haven't touched in months, but I know I was able to get it to work, and to run that "Pingdar" program, so if I get to a point in a project at which I need to have my controller know the distance to something, I know how to do that. I built a rocket deployment controller circuit on a breadboard, and tested it, not because I'm working on something using that right now, but because I suspect I'm going to want to be able to do that sometime in the next year or so.

It's important to make the point that an interesting project is mostly a collection of boring little pieces, put together creatively. At the Carnegie Science Center in Pittsburgh earlier this week I played with one of those robots that interacts with your facial expression. It had a transparent head, and you could see how the servos moved the robot's mouth, eyes, and eyebrows. I think if I really wanted to, I could do that part of that project right now. But I know that I do not know how to get it to read a person's facial expression, so if my goal were to replicate that project, I know exactly what I'd need to learn before tackling it.

ErNa

Passing information between operators can be done in many ways, and there are always advantages and drawbacks. Therefor there is no "optimum". I prefer to have a single method and to accept drawbacks in terms of memory consumption, speed, ...

I do it this way:

The main process keeps all the variables and there is a "PCB" or Process control block for every started cog. This PCB is just an array of pointers, where the first pointer points to a command. Whenever a cog is started, he holds a local copy of the pointers and so has access to the global memory to exchange data. The command data allows synchronization, starting and stopping the processes, selecting different functions. The mechanism is the same for spin and asm processes:

Such a PCB looks like this:

CON      NmbDrGePar = 12 ' Number of pointers of the rotary encoder process
Dat PCB_DrGe long  @DrGeCmd,  @DrehGeb,  @DrGeOfs,  @DrGeRes,  @DrGeVTim, @DrGeVCnt, @DrGeTiSl, @DrGeSens
             long  @DrGeTiBa, @ScVal053, @ScVal054, @ScVal055

The process is started:

DrGeCmd  := NmbDrGePar     ' Tell the start routine the number of entries in the table PCB
  i        := DrG.start(@PCB_DrGe, @@0) -1 ' start the incremental encoder routine
  if DrGeRes == 0                          ' if resolution of encoder not known
    ActState := CmdInvoc (@DrGeCmd, DetReso, i)  'when returning: Resolution determined, zero detected, Process running
  else
    ActState := CmdInvoc (@DrGeCmd, FreeRun, 255)  ' Start the process

The start routine just copies the pointers:

PUB Start( GlobPtr, AddrOffs) | i 

  Stop  ' Start can restart, therefore stop a possibly running cog first
  ' Create a local copy of the global pointer array and do the address correction "quick and dirty"
  repeat i from 0 to LONG[noparse][[/noparse]LONG[noparse][[/noparse]GlobPtr +   0]+AddrOffs]-1        ' The first parameter is the number of parameters
    LONG[noparse][[/noparse]@LoclPtr + (i<<2)] := LONG[noparse][[/noparse]GlobPtr + (i<<2)] + AddrOffs ' all pointers are 32 bit, the pointer address is byte oriented
      
  ifnot ID_cog
    ID_cog := cognew(CogProc, @Sk) + 1
  Result := ID_Cog 

PRI Stop
  if ID_cog
    cogstop(ID_cog~ - 1)

The pointer array of the process looks like this:

LoclPtr  ' Alle Pointer auf den Globalspeicher
CommandPtr    long      0       ' Pointer to the command
DreGebPtr     long      0       ' Pointer to the global encoder value
DreGOfsPtr    long      0       ' Pointer to an offset to "adjust" encoder position
DrGeResPtr    long      0       ' Pointer to the number of increments per resolution
DrGVelTPtr    long      0       ' Pointer to a speed value (time between counts, slow speed)
DrGVelCPtr    long      0       ' Pointer to a speed value (increments per time, high speed)
DrGTiSlPtr    long      0       ' Pointer to duration of time slice for speed measurement
DrGSensPtr    long      0       ' Pointer to rotational direction
DrGTiBaPtr    long      0       ' Pointer to timebase value, if encoder is simulated
ScVal53Ptr    long      0       ' Test
ScVal54Ptr    long      0       ' Test
ScVal55Ptr    long      0       ' Test

Using such a technique, the processes can communicate quite simple and as this mechanism is the only one, I use, I do not produce to much errors. And changing the number of parameters is just a modification of the table. And the data can be somewhere in memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

bill190

Perhaps McDonalds hamburger restaurants could be an analogy for this?

Each *restaurant* a "cog".

Each *worker* in a restaurant a "method".

Then you would have a worker/method who would only need to be called to do a task - like the person working at the drive thru window. A simple "ding" that a car has arrived, then the person takes the order. Just need to "call" that worker.

Then other workers like the person handling french fries. If you just "called" this worker and said french fries, the person would not know what to do! You need to·call "french fries" along with additional information. So "french_fries(2, medium)". Then the worker knows they want 2 medium french fries.


Taking this a bit further...

McDonalds corporation provides global or overall functions like the "I" part of I/O, EEPROM, and RAM. (Supplies and instruction.)

Customers being the "O" part of I/O.

smbaker

Back when I was in junior high school (a good long time ago), I had to teach the the math teacher pascal, his first post-basic programming language. I recall him having a devil of a time understanding parameter passing and I'm not sure he ever did get it. The young brain is more agile than our older brains. Give a motivated youngster the proper documentation and they'll learn something faster and better than we do.

I think others have touched on the more significant issue though, motivation. Most college-level programming students are thoroughly insulated from the the low level hardware. They don't understand how the hardware works, or why they should care how it works. Colleges are transitioning away from programming languages like assembly or C and into languages with more high-level abstrations and less low-level connection to the actual hardware. One of my friends, a professor, told me that he expects the future of computer programming to be more associated with assemling the right pre-written building blocks using GUI tools and much less actually writing your own code.

If you think about it the same thing probably happened with us hardware guys. There were probably transistor guys watching the development of the microprocessor, thinking about how the next generation would simply assemble microprocessors and peripherals and the construction of circuits out of transisters would be a lost art. Before them, the vacuum tube guys were thinking the same about the transistor guys. Today the phrase "build your own computer"·means ordering the right cpu, motherboard, and power supply from newegg.

I guess it's called "progress".

heater

smbaker: Well yes. Except someone, somewhere, somehow has to know this stuff. How to make a transistor on a piece of silicon or whatever technology. And why you might want to do that. How to assemble those transistors into gates and flip flops. How to make a CPU out of all that. How to make an efficient multiplier etc etc etc. Who are those people? Where do they come from? How did they get motivated to do all of that now a days?

Fortunately there are still people like this around www.youtube.com/watch?v=GcDshWmhF4A

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

MagIO2

Well ... if you want to do complex things you have to learn the basics ... whether you build a radio with transistors or you build a quadcopter with a propeller or you wanna write a game for a PC. And I think the basics in the transistor era were much simpler and/or less than the basics you need today. And to be honest ... I hope there will always be some guys who really still know the basic basics.

What I meant is that youngsters nowadays - if they really have the idea to build something by themselves - directly want to build an iPhone without learning the basics. They are used to consume and not used to put energy in doing - I suppose.

ErNa

On point is, there are so many competing technologies! And when teaching, we often go the historical road again. Doing this, we see yesterdays challenges and not those of the future! Then we discuss, what the right controller is. Learning "computer" with the propeller is different, it means: you can start with the parallel programming paradigm and instead of learning if then else .... and taking care that a program runs step by step, one can go the more natural way: processes are running in parallel and there is communication to synchronize the activities. And the conventional programming is just a tool to do this. But that will be forever: All beginning is difficult.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

heater

ErNa: "...you can start with the parallel programming paradigm and instead of learning if then else..."

Nice idea but I don't think so. There is no way anyone is going to start programming anything without the fundamental ideas of "instruction", "sequence", "operands", "operators", "variables", "if", "then", "else" etc etc under their belt first.

Admittedly getting into the idea of parallelism may be a tad easier on the Prop in Spin than on some systems I have seen.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

MagIO2

@ErNa: Could you please give an example of a technology which is not based on some basics found before?
I learned electronics 30 years ago and I never learned something about tubes. Transistors are still needed, so you won't get rid of em the next decade in education.
Even if you directly want to start with parallel programming you have to know the basics of programming, datastructures, algorithms ... . And please note ... the parallel programming era has just begun. Changing the paradigms takes a while in all areas .. for professional programmers as well as for education.

SRLM

I first learned how to program a few years ago as a Junior in HS, and didn't have a problem with parameters and arguments (although I couldn't remember which was which). Last year I tutored university freshman non-CS majors in their first programming class, and they understood the technicalities of functions without any difficulty. However, they struggled with when to use a function. Most of my students tended to have an enormous main function and only the functions required by the assignment.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm

James Newman

I'm only 24 btw. I find things like this to be quite easy to understand once you know the details behind it. It's all just pushing and popping values onto/offof a stack. (well in most programming languages anyway) A little more complex with pass by reference (mem address)... but still simple.

I personally don't like analogies and black box Smile... just show me what is actually happening and I'm good.


Ohhh and some of us still use command line, and to a much greater degree. Except for my web cruising time, I would say atleast half of my time in Linux is quick command line stuff. I do all of my file management via command line, and nothing beats awk/grep/etc for some quick down and dirty data manipulation.

ErNa

Everything is based on something else. So we do not start from scratch, but we have own experiences and we are taught. The best way to learn is, find some who helps to identify the structure of the own experience.
The world is running in parallel. But computers were machines, depending on serial execution of instructions. Therefor computer science focus on serializing parallel things. Now, computers start to be parallel even in hardware. This process is ongoing for some time, but was not available to the public. But as an individual, the natural way of acting is serial. Therefore, we always have to take care, what the character of the problem is. Then we we have to fit the problem to the abilities or vice versa. I just want to say: we should first try the second. Changing the problem means: doing something different from what was intended first.

One of the advantages of processes like a web browser is, that they do not expect certain data, but that they are able to analyze the data stream, as this stream is self describing. And the process is flexible enough to react.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away

El Marco

I've been using a BoeBot with a BS2 since my 9 year old son showed an interest in robots.
Once we got the kit I was suprised that he didn't get disappointed that we didn't build the mobile chassis right away, and was amazed it could do math. He actually spent time learning, with help, how to get it to solve his math homework and for the first time ever was interested in something like this. He just 'got it', accepted lots of concepts without question and loved every moment. When something didn't work, we checked the program and fixed it, he was learning some good troubleshooting skills without realising it.

He was making servos run and got two working together by duplicating code and trial and error rather than using the book and once the bot was built (cool bit of kit by the way - well done!) he was experimenting away in no time.
He was predicting things and flowcharting ideas at school and asking me how we could get it working, but, participating and entering all the code himself.

The key thing here is that he was interested.
He guessed that lots of things 'must' be there or doable from his requuirements for them to be there and wrote a program to reverse turn depending on which whisker was triggered more or less single handed, all in his spidery hand wrriten 'flowchart psuedocode' that I helped him turn into real code - but there was nothing wrong with his concept.

He isn't a child genius and struggles at school, but he is bright and that he can now code in Pbasic is a great thing, which has had a major impact on his confidence.

I am now learning the propeller based stuff as he wants to branch out and build more complex things, and Jake is now planning some wild and dangerous robots to take over the world with this new power, while I am planning on replacing a dead controller in a robot vacuum cleaner as a first project. I'm looking forward to working on many more projects with him for years to come.

Don't limit kids imaginations by worrying how they learn, just be there to guide them and they'll do fine.

Phil Pilgrim (PhiPi)

Compared with PBASIC, parameter passing in Spin does involve an additional level of abstraction, which some beginners may find hard to comprehend at first. In PBASIC, all variables are global. To call a subroutine using GOSUB, you explicitly set its argument variables, if any, ahead of time. This process is out in the open and very simple to understand. With method calls, the values in parentheses get transfered to the method's formal parameters, as if by magic. It's not something that's seen explicitly, it just happens behind the scenes. To whatever extent beginners might wrestle with this kind of abstraction, parameter passing will be a harder concept to communicate. In the meantime, it might be best to start with all global variables in a single cog and introduce parameter passing once the student has a reason to do things better and recognizes its advantages. Necessity is always a better motivator than force-feeding.

-Phil

Microcontrolled

Being young and a 2 year+ Propeller user, I say that yes, it is a little difficult at first. However after doing anything worthwhile with the SPIN or any programming language that uses this you catch on quickly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my new website!!

Use the Propeller icon!!

Follow me on Twitter! Search "Microcontrolled"

bdickens

I actually don't think the issue is "experience". I've been at this for a while (6502 days), albeit causually at this level. I still find languages like C,C++ and to some extent Spin are very confusing on their direct memory operators. Explaining why something was an variable here and the address of variable there gets annoying. Oddly enough, it's usually easier to explain assembler occasionally.

I prefer things like "global" definitions and niceties like "struct". Indirection isn't my friend. Do I understand why ? Sure. Do I like it, no. Cogs seem to confuse the issue. Not wholly sure why, but they do.

just my opinion.