Hard to help people

3v0,

"Many of the modern languages run on virtual machines to expressly divorce them from the physical machine. "

I already acknowledged that assembler requires a knowledge of the CPU architecture, so the above statement is not pertinent to this discussion.

NorthGuy,

"It is hard to mix Assembler (or anything else for that matter) with Java because they designed Java this way. Thay wanted to abstract from the hardware, and if you want it, that's what are you going to get with Java. "

Yes, and C is somewhat independent from the hardware also. Maybe that is why they decided to support that combination. Anyway, they are sacrificing performance for portability, which is OK if that is what they want to do.

MisterT,

"Ok.. so, how would you implement dependency injection in embedded applications? Sometimes it is hard to separate hardware from software, but it can be done if you are smart enough.. right? "

What is "dependency injection"? By writing a separate compiler for each different CPU, and using a standard set of functions for the defined language, it should be possible to implement this language on any computer.

Ratch

I think this thread is diverting from the original first post here

Ratchit said:

What is "dependency injection"?

Click to expand...

It is a very powerful design pattern.. or programming philosophy.. whatever you want to call it.
https://en.wikipedia.org/wiki/Dependency_injection

Inquisitive said:

I think this thread is diverting from the original first post here

Click to expand...

Quite right!! Please respect 3V0 and lets get back to the topic at hand!!! Any more off topic posts will be deleted!!!

It may be hard but it still can be done.
I would want help despite any limitations I may have.

Hi,

I think that if you are going to teach C++ you should start with the basics like what you find in C alone, then progress to OOP. That is because i believe OOP is a natural extension of a language after what was added before that. If we look at the evolution of a language we see that it starts out (more or less) with constants, then variables, then structs, and these all reside in source files. Then we find that often we have to use certain variables with certain data and so we group these into separate files. Then we find that we have to call certain functions to operate on certain data and at the same time achieve encapsulation which helps us organize our programs, so we see OOP emerge.
So chronologically OOP came last in the list, so it makes sense to progress in that same order when learning how this all fits together. Not only that but i think that the real beauty of OOP can not be appreciated fully unless one knows how to program using a less efficient method.

As to using assembler, there is more to the question of just whether to use it or not. The issue of program maintenance means it's not a matter of choice in many cases. Often we have hundreds or even thousands of programs that are already written in C or another language. There's no way we can practically convert these all to assembler complete with the necessary annotations.

My first encounter with a real computer was using punched cards for a mainframe. Next i ran into numerical coding where we would actually have to know the hex code for various instructions. After that i found assembler to be a blessing because i didnt have to remember the numerical codes. After that i found assembler API's where the existing body of code included many asm function calls that did most of the low level machine work like file op's. After that i ran into higher level languages which were nice, and made it much faster to make a big program.

So bottom line is OOP is nice but i think it should come after the more basic things like pointers and lower level stuff like that. If they already know that stuff then that is different. Also, they may have a fear of OOP at first not knowing what it is or how it works or what some of the other strange nomenclature associated with OOP really is.

I do agree. Seems to me the objects first people have not made their case.

Of course the people who started programming 30 years ago had to follow historical path in their learning. OOP didn't really exist until mid 90-s, so it couldn't be any other way.

However, I'm not sure that the people who learn anew should follow the same path.

The advantage of the OOP is that it puts data and functions together. This is done to let someone access the object without any knowlegde of data organization inside the object. The knowledge of inner working of the objects is not only unnesseary, but it may be harmful, because object may change its inner working, or even some other object may be substituted in the future. Good OOP programmer will write his programs that still work well even if the objects he uses start behaving differently. OOP program must be abstract and robust.

Assembler programming is quite different. It is often used when you need to do something efficiently or fast. Good Assembler programmer will know all the pecularities of the processor so that he could use them to his advantage. Tricky (and sometimes dirty) solutions are very common here.

I would say that the set of skills is quite different. A good OOP programmer may not know anything abut Assembler, while good Assembler programmer may not know anything about OOP.

Hello again,

The reason i presented my view as following the chronological order of the way languages progressed was not just for the sake of following the timeline for no reason other than that's the way it happened, but because OOP subsumes everything else that came before it.

For example if a newcomer does not know how to write a function or organize their data then they can never write an efficient OOP object. We have to know how everything inside an object should work before we can create an object of any reasonable usefulness.

MrAl said:

For example if a newcomer does not know how to write a function or organize their data then they can never write an efficient OOP object. We have to know how everything inside an object should work before we can create an object of any reasonable usefulness.

Click to expand...

My son, who's not a programmer at all, had to design an Android application for his work. It took him few days to get started and, according to him, his application works well. Since that's where he started, the OOP vision is native to him. It's totally different perception than mine. I rather see an object as a collection of underlaying structures, data, virtual functions, interfaces, tables of pointers. In my mind, I rather decompose objects, see how they're built, then act accordingly. I'm pretty sure he doesn't do that and looks at the object as a whole.

Similarly, people look at their cars as a whole - an object designed to drive - they don't care how it's built, they care how it drives. For a mechanical engineer, the car is an assembly of pistons, carburators, wheel bearings etc. When he drives, he listen to the enginne and feels how parts work together. But you totally don't have to know all that stuff to drive a care. Same with OOP. You can use objects without worrying about their composition. You can be a driver, not an engineer.

Hey, guys:

How about moving this thread to a discussion of OOP since it appears to be diverging a bit. It might turn out to be a useful thread in the end. I might be missing some essential piece of OPP information to make the transition from a conventional language to OOP. e.g. C to C++.

Maybe call it "Transitioning to OOP" or "Thinking with OOP in mind when programming"

I'd like to see this sort of thread as sort a blog by many. What do you guys think?

Hi again,

I thought it was more about teaching OOP, some points about that.

NorthGuy:
Yes i see your point of view and agree that one aspect of OOP is that we should be able to use the object without knowing how the contents are arranged. My view on this however is that although i agree with that i dont believe that is the way to begin teaching except maybe to show some particular points about OOP. It may be possible to catch the subjects attention so that they get curious enough to want to delve in further, but there's also the possibility that they might get lazy and just want to use other peoples objects from now on and never develop their own.

But this kind of discussion starts to find it's way into the waters of opinion: what is best in teaching programming. There are various opinions and most notable i think is whether or not to teach someone to use a "goto" rather than a more structured program layout. There are opinions both ways on the subject of "goto's" and people argue for hours about this. Some say use goto's and dont worry, others say dont use goto's but use more structured programming, others say use goto's with discretion.

I'll try to stick closely to the teaching rather than OOP in general.

I agree that teaching should be differ for different people. And frankly, it is very hard for me to figure out how other people think. I know that my programming skills come from my way of thinking. 80% of my programming time go into thinking through different what-if scenarios. I can imagine that a person may have different mentality so that if I tried to pass my skills head on they wouldn't be of any real help.

With programming, I believe in "learning as you go". You strat creating your own programs. You need to perform some tasks, so you need to find some information in books, courses, online. Then you apply this information. If person learns that way, his skills will be adapted to his own mentality, as well as to the range of tools available at the moment. IMHO, the biggest mistake would be to learn theoretically.

When people (costudents, coworkers) could not get a program to work, all i had to do was ask them to explain their program to me. In about 99% of the vases, they found their own error. I didn't even have to listen. It still worked.

The 1% were for things like zeros and O's. Lowercase/upper case.

Logic problems were best found by just asking them to explain their program.

===

Agreed, having a concert explained and then having to use the concept works pretty well although I can't get it out of my head that learning assembly language makes things easier. Not sure though, because I learned BASIC pretty much on my own and assembly language concurrently (4 year span of events).

Most of the other projects were having to do "something" using this language.

One guy I worked with kept telling me to "look it up" when I asked a question concerning syntax or whatever.

Things have to be a little different now.

KeepItSimpleStupid said:

One guy I worked with kept telling me to "look it up" when I asked a question concerning syntax or whatever.
Things have to be a little different now.

Click to expand...

Yeah.. some people don't even know that there is a thing called "documentation" and "datasheets". That is a big problem.

NorthGuy said:

...
With programming, I believe in "learning as you go". You strat creating your own programs. You need to perform some tasks, so you need to find some information in books, courses, online. Then you apply this information. If person learns that way, his skills will be adapted to his own mentality, as well as to the range of tools available at the moment. IMHO, the biggest mistake would be to learn theoretically.

Click to expand...

All I asked the guy to do was to spend a few minutes reading an article that explained the basic concepts of OO: Classes, inheritance, polymorphism etc. It would have prevented the 100 or so questions as he was later learning by doing.

One guy I worked with kept telling me to "look it up" when I asked a question concerning syntax or whatever.

Click to expand...

I once had a similar problem with an error report from a mini-computer hardware diagnostic program, I asked the "expert", he just blew me off with a read the documentation remark.
The problem was, I had already read the documentation and it was not very good and did not make sense.
I never bothered asking him anything ever again.

JimB

JimB said:

I once had a similar problem with an error report from a mini-computer hardware diagnostic program, I asked the "expert", he just blew me off with a read the documentation remark.
The problem was, I had already read the documentation and it was not very good and did not make sense.
I never bothered asking him anything ever again.

JimB

Click to expand...

Which may have been the desired result on his part.

The situation was not quite as simple as that.

A couple of weeks later I went to work at a remote site for three years, and gained a lot of good experience.
On my return to head office, it became obvious that the "expert" was just full of crap and bluster!

JimB