many years ago i did a short course in 8086 assembly language and i picked up a 2nd hand copy of barry's book "pc architecture & assembly language".
i only ever got to a mediocre level of assembly programming, & have forgotten most of it, but am curious if barry still delves into such low-level stuff.
also i was curious if the book was still available, & yes amazon has copies. they've also got his "Flow design for embedded systems". if you ever browse these nether regions of puppy barry, i wonder what you think of the OO paradigm with programming languages, (me being a committed proceduralist).
barry's assembly pedigree
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
The "revised 5th edition" was the last and best of that book.
Maybe I should scan the pages and put it online, as now have lots of space on servage.net.
I've toyed with the idea of getting back into assembly language programming on Linux, but Bash/Ash is commandling all of my attention.
A little while ago I downloaded the asm Linux programming tools that I could find, but after looking at a few example apps, the odd thought came up, "but it doesn't do piping".
It's a higher-level construct, but I'm addicted to piping. It's the greatest thing about Bash/Ash. Whenever I look at any other language, I ask my self, "yeah, but does it do piping?"
I'm probably thinking very much inside the square -- I'm probably elevating piping beyond what it really is. I'm just being a bit obsessed right now.
And I keep discovering new things, how to use bash/ash better.
OO? yeah, it's okay. For knocking up small scripts, not necessary.
Maybe I should scan the pages and put it online, as now have lots of space on servage.net.
I've toyed with the idea of getting back into assembly language programming on Linux, but Bash/Ash is commandling all of my attention.
A little while ago I downloaded the asm Linux programming tools that I could find, but after looking at a few example apps, the odd thought came up, "but it doesn't do piping".
It's a higher-level construct, but I'm addicted to piping. It's the greatest thing about Bash/Ash. Whenever I look at any other language, I ask my self, "yeah, but does it do piping?"
I'm probably thinking very much inside the square -- I'm probably elevating piping beyond what it really is. I'm just being a bit obsessed right now.
And I keep discovering new things, how to use bash/ash better.
OO? yeah, it's okay. For knocking up small scripts, not necessary.
yes barry,
the linux plumbing system of pipes is great.
regarding OO i like this quote, from http://www.paulgraham.com/articles.html,
I don't predict the demise of object-oriented programming, by the way. Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations. Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
also this on different progging languages:-
http://www.paulgraham.com/fix.html
the linux plumbing system of pipes is great.
regarding OO i like this quote, from http://www.paulgraham.com/articles.html,
I don't predict the demise of object-oriented programming, by the way. Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations. Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
also this on different progging languages:-
http://www.paulgraham.com/fix.html
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
I'm still a Bash/Ash learner. Probably should read the HOWTOs and Bash tutorials are bit more.
I often need to iterate through a text file, reading one line at a time, and I had real clumsy and slow code to do. Used that clumsy method on pupget and other scripts.
Then just recently I discovered:
That's it, darn simple using piping.
Probably all you other Puppy bash scripters already knew that technique.
I often need to iterate through a text file, reading one line at a time, and I had real clumsy and slow code to do. Used that clumsy method on pupget and other scripts.
Then just recently I discovered:
Code: Select all
cat atextfile |
while read ONELINE
do
echo "$ONELINE"
...or whatever
doneProbably all you other Puppy bash scripters already knew that technique.
-
costal martignier
- Posts: 198
- Joined: Sat 28 Jan 2006, 15:55
i know the problem of dooing it the wrong way 
i'm dooing this with php a long time..
first it's hard to find a solution for a problem, once you found one, mostly you take it another time when you have the same problem
so you keep your wrong code with you, because it works and because there is not enough time to really learn how it's better/faster
once i finished with my webenvironment project for puppy i'm really happy that i can use php for my scripting tasks in puppy, because i'm mor familiar with php than with bash scripting
regards
costal
ps"as usual, sorry for my horrible english"
i'm dooing this with php a long time..
first it's hard to find a solution for a problem, once you found one, mostly you take it another time when you have the same problem
so you keep your wrong code with you, because it works and because there is not enough time to really learn how it's better/faster
once i finished with my webenvironment project for puppy i'm really happy that i can use php for my scripting tasks in puppy, because i'm mor familiar with php than with bash scripting
regards
costal
ps"as usual, sorry for my horrible english"
-
BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Yes, I quickly realised that. It solves the problem of dealing with directory and filenames with spaces:MU wrote:the
command | while read ONELINE
also has the advantage, that it can read lines with spaces.
"for" can't do that.
So
ls | while read THEFILE;do
cp "$THEFILE" /whereever/
done
can for example copy files like "musician - the ugly song from my ugly XP.mp3"
Mark
Code: Select all
find ----options here---- |
while read ONEFILESPEC
do
doneHmm... I'm a bit confused now. Is this quote talking good or bad about OO?muggins wrote:yes barry,
the linux plumbing system of pipes is great.
regarding OO i like this quote, from http://www.paulgraham.com/articles.html,
I don't predict the demise of object-oriented programming, by the way. Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations. Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today.
also this on different progging languages:-
http://www.paulgraham.com/fix.html
I've only done programming for one semester (using Java), and I quite like the object-oriented approach.
Are there any special reasons against it?
I hated OO , because I never understood it.
It is hard to understand, when teachers (Fachinformatik) talk about crap like cats and dogs, instead of real stuff like windows.
Then I learned Gtk::perl, and since then I understood the concepts better.
If you use any modern widgetset like Gtk or QT or wx, you use OO.
You use (create a window):
frame=new wxFrame()
That means you use a class.
You use (modify it's size):
frame.setsize(400,200)
That means you overload a class for the object "frame" to modify it to your needs.
I think without OO you would be able to create just very limited GUIs.
Mark
It is hard to understand, when teachers (Fachinformatik) talk about crap like cats and dogs, instead of real stuff like windows.
Then I learned Gtk::perl, and since then I understood the concepts better.
If you use any modern widgetset like Gtk or QT or wx, you use OO.
You use (create a window):
frame=new wxFrame()
That means you use a class.
You use (modify it's size):
frame.setsize(400,200)
That means you overload a class for the object "frame" to modify it to your needs.
I think without OO you would be able to create just very limited GUIs.
Mark
several years back i started a computer science degree & had an OO class in eiffel. one particular assignment we had to do we were given a mark made up of the square root out of 100% for it working times sq. root out of 100% for OO style.
i got 98/100 for it working, but was severely marked down for my missing style.i formed the idea that OO is really designed to foster team efforts but that some people, like myself, don't think like that.
i like that thought experiment where you're on a plane that crashes in desert & you have to pick 10 thing out of a list of 20 for your survival. first you do it solo, then you do it in a group.
the idea is that it's supposed to show you the strength of teamwork because your score, as decided by some army survival expert, should be higher with the group than by yourself. everytime i've done it i get reverse effect!
anyway, back on OO, we had another assignment we had to do in eiffel. it would have been piece of cake to do it in c or pascal, but i couldn't get my head around it in eiffel. i dropped out of course.
funniest thing i remember in course was a tutor telling us about an eiffel program replicating a post office & how you could have a program called postbox, with classes called postbox. as he tried to explain all this to us he started getting confused between his classes & program names & had to sit down to collect himself.
but you might have no problem with OO, i just know my brain don't work that way. likewise we always had to do flowcharts & pseudocode before we wrote our programs & submit them with our assignments.
i like to think about my program AS i'm doing it so i always wrote my code first, then retrofitted some flowcharts & pseudocode to fit it!
i got 98/100 for it working, but was severely marked down for my missing style.i formed the idea that OO is really designed to foster team efforts but that some people, like myself, don't think like that.
i like that thought experiment where you're on a plane that crashes in desert & you have to pick 10 thing out of a list of 20 for your survival. first you do it solo, then you do it in a group.
the idea is that it's supposed to show you the strength of teamwork because your score, as decided by some army survival expert, should be higher with the group than by yourself. everytime i've done it i get reverse effect!
anyway, back on OO, we had another assignment we had to do in eiffel. it would have been piece of cake to do it in c or pascal, but i couldn't get my head around it in eiffel. i dropped out of course.
funniest thing i remember in course was a tutor telling us about an eiffel program replicating a post office & how you could have a program called postbox, with classes called postbox. as he tried to explain all this to us he started getting confused between his classes & program names & had to sit down to collect himself.
but you might have no problem with OO, i just know my brain don't work that way. likewise we always had to do flowcharts & pseudocode before we wrote our programs & submit them with our assignments.
i like to think about my program AS i'm doing it so i always wrote my code first, then retrofitted some flowcharts & pseudocode to fit it!
i haven't had a looked at java, although a mate of mine thinks it's the bee's knees. i'm a bit daunted by the size of the JVM you have to install to run programs, which is as large as puppy! and the few times i have tried installing the engine & running programs they seem to run in slow-mo.
perhaps another conspiracy to render old machines obsolescent & require you to upgrade?
perhaps another conspiracy to render old machines obsolescent & require you to upgrade?
-
Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
I did a course in Fortran one semester (which I enjoyed) and the next it was C++ which was awful.
In fortran I'd sit with a pencil and paper, work out what I wanted to do and write the program- and it'd work when I typed it!
C++ was all about sitting in front of the computer and fiddling to get things working. And, yeah, by nature it's obviously bloated.
In fortran I'd sit with a pencil and paper, work out what I wanted to do and write the program- and it'd work when I typed it!
C++ was all about sitting in front of the computer and fiddling to get things working. And, yeah, by nature it's obviously bloated.
being of a sceptical mind i thought i'd check out "hello world" in c & c++. i got similar results to what i'd read on web, c was about 16K & c++ was about 110K. there are probly optimizations etc but should still be of same order.
digressing, 31 years ago i dropped out of a course doing cobol & fortran, and next fortnight i'm back at same uni doing progging course in the dreaded c++ & java!
diverging to my, flash's & lobster's fave prog language, forth, how is it that 4th can have smaller programs than equivalent assembly?
digressing, 31 years ago i dropped out of a course doing cobol & fortran, and next fortnight i'm back at same uni doing progging course in the dreaded c++ & java!
diverging to my, flash's & lobster's fave prog language, forth, how is it that 4th can have smaller programs than equivalent assembly?
-
Guest
The relative merit of various programming languages
Someone once told me "It is easier to write a program than to read one". I wish that was my original thought and I'm sorry I can't give credit to the proper person. If we were to compare two languages, I would say the best is "the easiest to read" (comprehend the original intent of the programmer).
Brooks "Mythical Man Month" gets very enlightening if your task requires multiple programmers. Brooks headed the development of OS/360 which was a very large efort. The whole Linux effort is based on collaboration, which must mean that someone did a good job of laying out the principles which so many collaborators followed so that everything actually worked.
A further complication is style; certain coding styles make it much easier to follow the logic of the program. Does this mean that style is more important than language choice?
A friend recently gave me a program listing for some code she was working on. My first impression was the very large number of comments from multiple programmers about their 'maintenance tasks' over a number of years. I was impressed with the sheer volume of changes that were made to this program. This says that the comprehensibilty (sp?) of this program is very important
So when do you drop to assembly language? The usual arguments are speed and OS/interface requirements. I like assembly language; I also like the tasks that typically require it. It might be easier for me to do some task in ASM that would normally be done in a HLL because my skills are much more developed in ASM. But if this task is something that should be around for a long time, then maybe someone else with a more developed skill in a HLL should do it.
Brooks "Mythical Man Month" gets very enlightening if your task requires multiple programmers. Brooks headed the development of OS/360 which was a very large efort. The whole Linux effort is based on collaboration, which must mean that someone did a good job of laying out the principles which so many collaborators followed so that everything actually worked.
A further complication is style; certain coding styles make it much easier to follow the logic of the program. Does this mean that style is more important than language choice?
A friend recently gave me a program listing for some code she was working on. My first impression was the very large number of comments from multiple programmers about their 'maintenance tasks' over a number of years. I was impressed with the sheer volume of changes that were made to this program. This says that the comprehensibilty (sp?) of this program is very important
So when do you drop to assembly language? The usual arguments are speed and OS/interface requirements. I like assembly language; I also like the tasks that typically require it. It might be easier for me to do some task in ASM that would normally be done in a HLL because my skills are much more developed in ASM. But if this task is something that should be around for a long time, then maybe someone else with a more developed skill in a HLL should do it.
The main problem is not with OO. It's with using the right tool for the right problem.
The OO paradigm is not a silver bullet. OO is just a way of handling complexity. Its a way for creating abstractions, for analyzing at different levels of abstraction.
The OO model is superior to the functional model as much as the functional model is superior to spaguetti code.
To develop OO you must think differently than programing functional. In OO you don't start from the solution domain, but from the problem domain. OO allows to very elegantly do things that would be a mess in programming it functionally.
I do believe that polymorphism helps simplifying the code. when you deal with interfaces and not implementations you have an application that can evolve faster, that's easier to maintain.
Of course, the examples that can be explored in a programming course are simple and OO seems like overengineering, but in real applications you can substantially reduce the number of lines of code required.
The main problem with people new to OO is that they tend to overengineer the solution. I would hardly blame OO for that. I am a believer for coding to your current requirements and refactor if those requirements change in the future.
When I train people in OO, the first thing I mention is that there are different levels of OO understanding. You first understand the concepts, then you can understand other peoples work and just after much trying you can start designing meaningfull object structures.
OO practices have evolved substantially since I started 14 years ago. Before inheritance ruled, now we know that delegation is a cleaner model.
Well, those were my two cents.
The OO paradigm is not a silver bullet. OO is just a way of handling complexity. Its a way for creating abstractions, for analyzing at different levels of abstraction.
The OO model is superior to the functional model as much as the functional model is superior to spaguetti code.
To develop OO you must think differently than programing functional. In OO you don't start from the solution domain, but from the problem domain. OO allows to very elegantly do things that would be a mess in programming it functionally.
I do believe that polymorphism helps simplifying the code. when you deal with interfaces and not implementations you have an application that can evolve faster, that's easier to maintain.
Of course, the examples that can be explored in a programming course are simple and OO seems like overengineering, but in real applications you can substantially reduce the number of lines of code required.
The main problem with people new to OO is that they tend to overengineer the solution. I would hardly blame OO for that. I am a believer for coding to your current requirements and refactor if those requirements change in the future.
When I train people in OO, the first thing I mention is that there are different levels of OO understanding. You first understand the concepts, then you can understand other peoples work and just after much trying you can start designing meaningfull object structures.
OO practices have evolved substantially since I started 14 years ago. Before inheritance ruled, now we know that delegation is a cleaner model.
Well, those were my two cents.
Last edited by rarsa on Sat 25 Mar 2006, 17:18, edited 1 time in total.
i just had to correct something that i'd posted on the first page of this thread...that was that when i compiled "hello world!" in c++ it was 10X the size of same in c.
i don't know how that occurred but the editor i used seems to added the extra bloat. i just did same "hello world" compilation & c weighs in at 12k compared to c++ at 13k. a neglible difference.
sorrry if i missled anybody...i'll go & stand in the corner now!
i don't know how that occurred but the editor i used seems to added the extra bloat. i just did same "hello world" compilation & c weighs in at 12k compared to c++ at 13k. a neglible difference.
sorrry if i missled anybody...i'll go & stand in the corner now!