|
unplugging...
"Janet" > wrote in message ... > Ellen K. wrote: > >> I'd love to hear why you thought C++ was the easiest, in many circles >> it's considered the only language "real" programmers use. > > Hah. "Real" programmers use assembler. <G> > Ha, you are right. :) |
unplugging...
Interesting to find out how much so many of us have in common besides
diabetes. Code writing is becoming something now that many employees simply must do. Learn how or perish. I think you spent much more time at this than I have. Like I said I had this fault of creating nested if thens that would make my head explode. I did solve a lot of these with the switch command. Solve is not the right answer, made better would be more accurate. Anyway Ellen, I am taking a break from ASD for a while. Reading through the posts, I often see the personal attack dogs at work and it is just something I don't want to be part of my life for a while. May you conquer your T2, live long, and prosper V Michael "Ellen K." > wrote in message ... > > "Boomer" > wrote in message > ... >> >> >> "Ellen K." > wrote in message >> ... >>> >>> "Boomer" > wrote in message >>> ... >>>> >>>> >>>> "Ellen K." > wrote in message >>>> ... >>>>> >>>>> "Boomer" > wrote in message >>>>> ... >>>>>> >>>>>> >>>>>> "Ellen K." > wrote in message >>>>>> ... >>>>>>> >>>>>>> "Janet" > wrote in message >>>>>>> ... >>>>>>>> Ellen K. wrote: >>>>>>>> >>>>>>>>> This is getting to be too many things to worry about. >>>>>>>> >>>>>>>> By doG, I thought you'd never get to that point. (I reached it long >>>>>>>> ago! <G>) Seriously, your attention to detail has awed me. You are >>>>>>>> made of sterner stuff than I. <G> >>>>>>>> >>>>>>> >>>>>>> It's just the nature of the beast. I've basically worked with data >>>>>>> most of my adult life. After 20 years in accounting and finance I >>>>>>> transitioned into software development and related work. >>>>>> >>>>>> Ellen, I see you have worked in software. I wrote applications in C++ >>>>>> as part of my job in engineering. What language did you use? >>>>>> >>>>>> Michael >>>>>>> >>>>> >>>>> SQL is my strong suit. Unlike procedural or object-oriented languages >>>>> it works with data setwise as opposed to with one instance of a data >>>>> object at a time. This is a very different way of thinking, and >>>>> extremely powerful when used as designed. Front-end programmers who >>>>> write SQL tend to use it to still only work with one instance of an >>>>> object at a time, then they wonder why the performance of the >>>>> application leaves so much to be desired. >>>>> >>>>> C was the first language I learned, then C++, but I never used either >>>>> of them in a production environment. I liked C because it was so >>>>> economical and because it gave the programmer full control. The >>>>> front-end programming I have done in a production environment was all >>>>> VB. >>>> >>>> Well, you know a lot more about programming than myself. >>> >>> I dunno how you figure that! >> >> Because of all the experience you have had. Most of my programming with >> C++ was done as a side issue to insure equipment worked easily for >> everyone. >> >>> >>>> My first experience was in the 60s with fortran used in the program for >>>> setting up the ballistic track for the missiles launched from subs. I >>>> only did one thing. Just the guidance programming. >>>> >>> >>> That's a very big deal! >> >> Well it might have been a big deal for some but for me it was a form of >> agony. I was only chosen because of my security clearance. They give you >> massive complicated charts to write code for certain targets. It was >> incredibly painstaking work. Back then it had to be done right on the >> boat. We did not take a floppy drive or something and then install it >> later after doing it leasurely in an office. At that time there was an >> extreme shortage of programmers. I had to work 6 days a week 12 hours per >> day. There was no one to check my work. I figured that if I made a >> mistake, no one would come look for me after the war. I realize that was >> rather callous but I knew it was the bottom line. >> >> All it had to do really was not show a fault when we went out for sea >> trials and went all the way to push the last button. If the autopilot >> went smoothly and no fault showed from the bird, all was well. >> > > The work I recently finished up included data quality analysis from which > it was painfully obvious that the "testing" performed on the homegrown > applications consisted of a) do the users see what they expect in the GUI; > and b) does anything crash, and as long as the answer to a) was yes and b) > was no, the app was accepted. Being a dinosaur, I really think > "information" is the important word in "information technology". > >>> >>>> I hated that work and moved on to electronics design. I realized in the >>>> 80s that I was not going to be much of an engineer unless I could do >>>> programming. So I taught myself the easiest one, C++. >>> >>> I'd love to hear why you thought C++ was the easiest, in many circles >>> it's considered the only language "real" programmers use. >> >> Also, if you program in a vacuum like I did, you assume every other >> programmer is better and faster than yourself. >> >> >> I read that it was considered easier to do than C. I looked at it and it >> made sense to me. However, I was the only programmer at the university. >> When things did not work, I had to figure it out myself. I really wanted >> someone to work with. No such budget existed. I suppose that C++ looked >> so much easier than Fortran too. Basically besides the hardware hooks, >> it is just a bunch of "if then else" stuff. My problem was often getting >> too many nested "if thens". I would disappear into a black hole way past >> the event horizon. > > Heh, a case could be made that most programming in ANY language is a > "bunch of if then else stuff". > >>> >>>> I did not write anything really large at all. Most were small little >>>> things for specific jobs at the medical school. I think the largest one >>>> I ever wrote had about 5 thousand lines of source code. >> >> The game writers are the real geniuses. > > They certainly have a lot more GUI stuff to manage. > >> I could never do that. A typical project for me was to integrate all the >> equipment in a surgical suite. That just meant bringing in all the serial >> control lines to a central computer and putting the information up on a >> touch panel. The surgical team could push touch panel buttons to make >> things happen. I also wrote little algorithms that the surgeons would >> give me. Like the warm up time for a heart patient coming out of being >> chilled. This would automate their work and insure that it was done as >> they wanted it done. This was always a moving target so these algorithms >> would be constantly changed. It was actually fairly simple. Sometimes it >> was tricky getting the serial lines talking. Setting buffers and parsing >> the incoming sometimes made me a little crazy. >>>> >>> >>> My big project for my last employer was over 100,000 lines, it was a >>> suite of analytical reports that were generated once a week. The >>> company's data resided at that time in an antiquated data store that >>> could not be addressed with any SQL beyond the most simple queries >>> (there was a tool that sat on top of it to enable SQL to be used *at >>> all*), so I had to write a lot of the logic in VB... the reports were >>> delivered as multi-sheet Excel workbooks so a lot of that code was just >>> using the Excel object model. IOW maybe more code than actual logic. >>> <g but serious> >> >> >> Oh God, I can't imagine sitting down to write a 100 thousand lines of >> code. > > > Well, I didn't sit down to write 100K lines of code, I sat down to create > the reports the directors wanted, the amount of code was just how much it > took to accomplish that goal. >>> >>>> Michael >>>>> >>> > |
unplugging...
"Janet" > wrote in message ... > Ellen K. wrote: > >> I'd love to hear why you thought C++ was the easiest, in many circles >> it's considered the only language "real" programmers use. > > Hah. "Real" programmers use assembler. <G> > > > That is probably true. I tried doing some of that. Yikes. I was quickly back to the comfortable safety of C++. Michael |
unplugging...
Janet > wrote:
> Ellen K. wrote: > > > I'd love to hear why you thought C++ was the easiest, in many circles > > it's considered the only language "real" programmers use. > > Hah. "Real" programmers use assembler. <G> Assembler is for wimps. Real programmers use machine language, entered through the switch register. -- Frank Slootweg |
unplugging...
Thank you for the good wishes and I wish the same back to you.
I hope you will come back soon, I enjoy corresponding with you. "Boomer" > wrote in message ... > Interesting to find out how much so many of us have in common besides > diabetes. Code writing is becoming something now that many employees > simply must do. Learn how or perish. I think you spent much more time at > this than I have. Like I said I had this fault of creating nested if thens > that would make my head explode. I did solve a lot of these with the > switch command. Solve is not the right answer, made better would be more > accurate. > > Anyway Ellen, I am taking a break from ASD for a while. Reading through > the posts, I often see the personal attack dogs at work and it is just > something I don't want to be part of my life for a while. > > May you conquer your T2, live long, and prosper V > > Michael > > "Ellen K." > wrote in message > ... >> >> "Boomer" > wrote in message >> ... >>> >>> >>> "Ellen K." > wrote in message >>> ... >>>> >>>> "Boomer" > wrote in message >>>> ... >>>>> >>>>> >>>>> "Ellen K." > wrote in message >>>>> ... >>>>>> >>>>>> "Boomer" > wrote in message >>>>>> ... >>>>>>> >>>>>>> >>>>>>> "Ellen K." > wrote in message >>>>>>> ... >>>>>>>> >>>>>>>> "Janet" > wrote in message >>>>>>>> ... >>>>>>>>> Ellen K. wrote: >>>>>>>>> >>>>>>>>>> This is getting to be too many things to worry about. >>>>>>>>> >>>>>>>>> By doG, I thought you'd never get to that point. (I reached it >>>>>>>>> long ago! <G>) Seriously, your attention to detail has awed me. >>>>>>>>> You are made of sterner stuff than I. <G> >>>>>>>>> >>>>>>>> >>>>>>>> It's just the nature of the beast. I've basically worked with >>>>>>>> data most of my adult life. After 20 years in accounting and >>>>>>>> finance I transitioned into software development and related work. >>>>>>> >>>>>>> Ellen, I see you have worked in software. I wrote applications in >>>>>>> C++ as part of my job in engineering. What language did you use? >>>>>>> >>>>>>> Michael >>>>>>>> >>>>>> >>>>>> SQL is my strong suit. Unlike procedural or object-oriented >>>>>> languages it works with data setwise as opposed to with one instance >>>>>> of a data object at a time. This is a very different way of >>>>>> thinking, and extremely powerful when used as designed. Front-end >>>>>> programmers who write SQL tend to use it to still only work with one >>>>>> instance of an object at a time, then they wonder why the performance >>>>>> of the application leaves so much to be desired. >>>>>> >>>>>> C was the first language I learned, then C++, but I never used either >>>>>> of them in a production environment. I liked C because it was so >>>>>> economical and because it gave the programmer full control. The >>>>>> front-end programming I have done in a production environment was all >>>>>> VB. >>>>> >>>>> Well, you know a lot more about programming than myself. >>>> >>>> I dunno how you figure that! >>> >>> Because of all the experience you have had. Most of my programming with >>> C++ was done as a side issue to insure equipment worked easily for >>> everyone. >>> >>>> >>>>> My first experience was in the 60s with fortran used in the program >>>>> for setting up the ballistic track for the missiles launched from >>>>> subs. I only did one thing. Just the guidance programming. >>>>> >>>> >>>> That's a very big deal! >>> >>> Well it might have been a big deal for some but for me it was a form of >>> agony. I was only chosen because of my security clearance. They give you >>> massive complicated charts to write code for certain targets. It was >>> incredibly painstaking work. Back then it had to be done right on the >>> boat. We did not take a floppy drive or something and then install it >>> later after doing it leasurely in an office. At that time there was an >>> extreme shortage of programmers. I had to work 6 days a week 12 hours >>> per day. There was no one to check my work. I figured that if I made a >>> mistake, no one would come look for me after the war. I realize that was >>> rather callous but I knew it was the bottom line. >>> >>> All it had to do really was not show a fault when we went out for sea >>> trials and went all the way to push the last button. If the autopilot >>> went smoothly and no fault showed from the bird, all was well. >>> >> >> The work I recently finished up included data quality analysis from which >> it was painfully obvious that the "testing" performed on the homegrown >> applications consisted of a) do the users see what they expect in the >> GUI; and b) does anything crash, and as long as the answer to a) was yes >> and b) was no, the app was accepted. Being a dinosaur, I really think >> "information" is the important word in "information technology". >> >>>> >>>>> I hated that work and moved on to electronics design. I realized in >>>>> the 80s that I was not going to be much of an engineer unless I could >>>>> do programming. So I taught myself the easiest one, C++. >>>> >>>> I'd love to hear why you thought C++ was the easiest, in many circles >>>> it's considered the only language "real" programmers use. >>> >>> Also, if you program in a vacuum like I did, you assume every other >>> programmer is better and faster than yourself. >>> >>> >>> I read that it was considered easier to do than C. I looked at it and it >>> made sense to me. However, I was the only programmer at the university. >>> When things did not work, I had to figure it out myself. I really wanted >>> someone to work with. No such budget existed. I suppose that C++ looked >>> so much easier than Fortran too. Basically besides the hardware hooks, >>> it is just a bunch of "if then else" stuff. My problem was often getting >>> too many nested "if thens". I would disappear into a black hole way past >>> the event horizon. >> >> Heh, a case could be made that most programming in ANY language is a >> "bunch of if then else stuff". >> >>>> >>>>> I did not write anything really large at all. Most were small little >>>>> things for specific jobs at the medical school. I think the largest >>>>> one I ever wrote had about 5 thousand lines of source code. >>> >>> The game writers are the real geniuses. >> >> They certainly have a lot more GUI stuff to manage. >> >>> I could never do that. A typical project for me was to integrate all the >>> equipment in a surgical suite. That just meant bringing in all the >>> serial control lines to a central computer and putting the information >>> up on a touch panel. The surgical team could push touch panel buttons to >>> make things happen. I also wrote little algorithms that the surgeons >>> would give me. Like the warm up time for a heart patient coming out of >>> being chilled. This would automate their work and insure that it was >>> done as they wanted it done. This was always a moving target so these >>> algorithms would be constantly changed. It was actually fairly simple. >>> Sometimes it was tricky getting the serial lines talking. Setting >>> buffers and parsing the incoming sometimes made me a little crazy. >>>>> >>>> >>>> My big project for my last employer was over 100,000 lines, it was a >>>> suite of analytical reports that were generated once a week. The >>>> company's data resided at that time in an antiquated data store that >>>> could not be addressed with any SQL beyond the most simple queries >>>> (there was a tool that sat on top of it to enable SQL to be used *at >>>> all*), so I had to write a lot of the logic in VB... the reports were >>>> delivered as multi-sheet Excel workbooks so a lot of that code was just >>>> using the Excel object model. IOW maybe more code than actual logic. >>>> <g but serious> >>> >>> >>> Oh God, I can't imagine sitting down to write a 100 thousand lines of >>> code. >> >> >> Well, I didn't sit down to write 100K lines of code, I sat down to create >> the reports the directors wanted, the amount of code was just how much it >> took to accomplish that goal. >>>> >>>>> Michael >>>>>> >>>> >> |
unplugging...
On 18/09/2010 5:14 AM, Boomer wrote:
> Interesting to find out how much so many of us have in common besides > diabetes. Code writing is becoming something now that many employees > simply must do. Learn how or perish. I think you spent much more time at > this than I have. Like I said I had this fault of creating nested if > thens that would make my head explode. Easy just bung in a goto instead :-) or better yet nested gotos :-) (- -) =m=(_)=m= RodS T2 Australia I did solve a lot of these with > the switch command. Solve is not the right answer, made better would be > more accurate. > > Anyway Ellen, I am taking a break from ASD for a while. Reading through > the posts, I often see the personal attack dogs at work and it is just > something I don't want to be part of my life for a while. > > May you conquer your T2, live long, and prosper V > > Michael > > "Ellen K." > wrote in message > ... >> >> "Boomer" > wrote in message >> ... >>> >>> >>> "Ellen K." > wrote in message >>> ... >>>> >>>> "Boomer" > wrote in message >>>> ... >>>>> >>>>> >>>>> "Ellen K." > wrote in message >>>>> ... >>>>>> >>>>>> "Boomer" > wrote in message >>>>>> ... >>>>>>> >>>>>>> >>>>>>> "Ellen K." > wrote in message >>>>>>> ... >>>>>>>> >>>>>>>> "Janet" > wrote in message >>>>>>>> ... >>>>>>>>> Ellen K. wrote: >>>>>>>>> >>>>>>>>>> This is getting to be too many things to worry about. >>>>>>>>> >>>>>>>>> By doG, I thought you'd never get to that point. (I reached it >>>>>>>>> long ago! <G>) Seriously, your attention to detail has awed me. >>>>>>>>> You are made of sterner stuff than I. <G> >>>>>>>>> >>>>>>>> >>>>>>>> It's just the nature of the beast. I've basically worked with >>>>>>>> data most of my adult life. After 20 years in accounting and >>>>>>>> finance I transitioned into software development and related work. >>>>>>> >>>>>>> Ellen, I see you have worked in software. I wrote applications in >>>>>>> C++ as part of my job in engineering. What language did you use? >>>>>>> >>>>>>> Michael >>>>>>>> >>>>>> >>>>>> SQL is my strong suit. Unlike procedural or object-oriented >>>>>> languages it works with data setwise as opposed to with one >>>>>> instance of a data object at a time. This is a very different way >>>>>> of thinking, and extremely powerful when used as designed. >>>>>> Front-end programmers who write SQL tend to use it to still only >>>>>> work with one instance of an object at a time, then they wonder >>>>>> why the performance of the application leaves so much to be desired. >>>>>> >>>>>> C was the first language I learned, then C++, but I never used >>>>>> either of them in a production environment. I liked C because it >>>>>> was so economical and because it gave the programmer full control. >>>>>> The front-end programming I have done in a production environment >>>>>> was all VB. >>>>> >>>>> Well, you know a lot more about programming than myself. >>>> >>>> I dunno how you figure that! >>> >>> Because of all the experience you have had. Most of my programming >>> with C++ was done as a side issue to insure equipment worked easily >>> for everyone. >>> >>>> >>>>> My first experience was in the 60s with fortran used in the program >>>>> for setting up the ballistic track for the missiles launched from >>>>> subs. I only did one thing. Just the guidance programming. >>>>> >>>> >>>> That's a very big deal! >>> >>> Well it might have been a big deal for some but for me it was a form >>> of agony. I was only chosen because of my security clearance. They >>> give you massive complicated charts to write code for certain >>> targets. It was incredibly painstaking work. Back then it had to be >>> done right on the boat. We did not take a floppy drive or something >>> and then install it later after doing it leasurely in an office. At >>> that time there was an extreme shortage of programmers. I had to work >>> 6 days a week 12 hours per day. There was no one to check my work. I >>> figured that if I made a mistake, no one would come look for me after >>> the war. I realize that was rather callous but I knew it was the >>> bottom line. >>> >>> All it had to do really was not show a fault when we went out for sea >>> trials and went all the way to push the last button. If the autopilot >>> went smoothly and no fault showed from the bird, all was well. >>> >> >> The work I recently finished up included data quality analysis from >> which it was painfully obvious that the "testing" performed on the >> homegrown applications consisted of a) do the users see what they >> expect in the GUI; and b) does anything crash, and as long as the >> answer to a) was yes and b) was no, the app was accepted. Being a >> dinosaur, I really think "information" is the important word in >> "information technology". >> >>>> >>>>> I hated that work and moved on to electronics design. I realized in >>>>> the 80s that I was not going to be much of an engineer unless I >>>>> could do programming. So I taught myself the easiest one, C++. >>>> >>>> I'd love to hear why you thought C++ was the easiest, in many >>>> circles it's considered the only language "real" programmers use. >>> >>> Also, if you program in a vacuum like I did, you assume every other >>> programmer is better and faster than yourself. >>> >>> >>> I read that it was considered easier to do than C. I looked at it and >>> it made sense to me. However, I was the only programmer at the >>> university. When things did not work, I had to figure it out myself. >>> I really wanted someone to work with. No such budget existed. I >>> suppose that C++ looked so much easier than Fortran too. Basically >>> besides the hardware hooks, it is just a bunch of "if then else" >>> stuff. My problem was often getting too many nested "if thens". I >>> would disappear into a black hole way past the event horizon. >> >> Heh, a case could be made that most programming in ANY language is a >> "bunch of if then else stuff". >> >>>> >>>>> I did not write anything really large at all. Most were small >>>>> little things for specific jobs at the medical school. I think the >>>>> largest one I ever wrote had about 5 thousand lines of source code. >>> >>> The game writers are the real geniuses. >> >> They certainly have a lot more GUI stuff to manage. >> >>> I could never do that. A typical project for me was to integrate all >>> the equipment in a surgical suite. That just meant bringing in all >>> the serial control lines to a central computer and putting the >>> information up on a touch panel. The surgical team could push touch >>> panel buttons to make things happen. I also wrote little algorithms >>> that the surgeons would give me. Like the warm up time for a heart >>> patient coming out of being chilled. This would automate their work >>> and insure that it was done as they wanted it done. This was always a >>> moving target so these algorithms would be constantly changed. It was >>> actually fairly simple. Sometimes it was tricky getting the serial >>> lines talking. Setting buffers and parsing the incoming sometimes >>> made me a little crazy. >>>>> >>>> >>>> My big project for my last employer was over 100,000 lines, it was a >>>> suite of analytical reports that were generated once a week. The >>>> company's data resided at that time in an antiquated data store that >>>> could not be addressed with any SQL beyond the most simple queries >>>> (there was a tool that sat on top of it to enable SQL to be used *at >>>> all*), so I had to write a lot of the logic in VB... the reports >>>> were delivered as multi-sheet Excel workbooks so a lot of that code >>>> was just using the Excel object model. IOW maybe more code than >>>> actual logic. <g but serious> >>> >>> >>> Oh God, I can't imagine sitting down to write a 100 thousand lines of >>> code. >> >> >> Well, I didn't sit down to write 100K lines of code, I sat down to >> create the reports the directors wanted, the amount of code was just >> how much it took to accomplish that goal. >>>> >>>>> Michael >>>>>> >>>> >> |
unplugging...
On Fri, 17 Sep 2010 14:15:57 -0500, Boomer wrote:
> "Janet" > wrote in message > ... >> Ellen K. wrote: >> >>> I'd love to hear why you thought C++ was the easiest, in many circles >>> it's considered the only language "real" programmers use. >> >> Hah. "Real" programmers use assembler. <G> >> >> >> >> > That is probably true. I tried doing some of that. Yikes. I was quickly > back to the comfortable safety of C++. > > Michael By that token I am - or was - a real programmer. I wrote a channel program for an IBM 360, to drive a paper tape punch. IBM had delivered the hardware, but no software :-) I can't remember what the OS was ... Most of the time I maintained and developed a largish CAD/CAM system written mostly in Fortran, with pieces first in assembler and later in C. |
unplugging...
In alt.support.diabetes RodS > wrote:
> On 18/09/2010 5:14 AM, Boomer wrote: >> Interesting to find out how much so many of us have in common besides >> diabetes. Code writing is becoming something now that many employees >> simply must do. Learn how or perish. I think you spent much more time at >> this than I have. Like I said I had this fault of creating nested if >> thens that would make my head explode. > Easy just bung in a goto instead :-) > or better yet nested gotos :-) >> I did solve a lot of these with >> the switch command. Solve is not the right answer, made better would be >> more accurate. Having to have a lot of complex exceptions to the main line of structured code is often a sign that you're trying to do the right thing, which is to follow the logic of the data structures with the procedural or subroutine delegation of the program code, but something's gone wrong. That data strucure following works very well when the data structure is categorically well structure. It fails when you have to deal with two parallel or independent kinds of data structures. In that case whichever data structure you follow with your code, the other has be dealt with by a patchwork of messy exceptions. Unless instead of subroutines you use (tada!) coroutines -- a very useful software control structuring trick available to the systems assembler programmer, but rarely reflected into higher level programming languages. It's a kind of simultaneous subroutine call and exit, which allows the co-existence of neatly programmed parallel control structures to follow parallel data structures. -- Chris Malcolm |
unplugging...
Ozlover wrote:
> Janet > wrote: >> Ellen K. wrote: >> >>> I'd love to hear why you thought C++ was the easiest, in many >>> circles it's considered the only language "real" programmers use. >> >> Hah. "Real" programmers use assembler. <G> > > Assembler is for wimps. Real programmers use machine language, > entered through the switch register. Why did I have the feeling that someone would say that! <G> |
unplugging...
On 9/18/2010 8:43 AM, Janet wrote:
> Ozlover wrote: >> > wrote: >>> Ellen K. wrote: >>> >>>> I'd love to hear why you thought C++ was the easiest, in many >>>> circles it's considered the only language "real" programmers use. >>> >>> Hah. "Real" programmers use assembler.<G> >> >> Assembler is for wimps. Real programmers use machine language, >> entered through the switch register. > > Why did I have the feeling that someone would say that!<G> It doesn't stop there, you know. The next iteration discusses hand punching Jacquard cards. |
unplugging...
On Sat, 18 Sep 2010 09:43:34 -0400, Janet wrote:
> Ozlover wrote: >> Janet > wrote: >>> Ellen K. wrote: >>> >>>> I'd love to hear why you thought C++ was the easiest, in many circles >>>> it's considered the only language "real" programmers use. >>> >>> Hah. "Real" programmers use assembler. <G> >> >> Assembler is for wimps. Real programmers use machine language, >> entered through the switch register. > > Why did I have the feeling that someone would say that! <G> <G> Been there, done that, well, almost. Programming the Bull Gamma 10 in machine code, albeit on punched cards, not switches. OTOH I did once patch a running program on the Gamma 10 from the programmer panel ... The Gamma 10 was a glorified tabulator with IIRC 4096 words memory, programmable partly via a plugboard and partly from punch cards loaded into memory. |
unplugging...
Alan S > wrote:
> On 17 Sep 2010 20:12:55 GMT, Ozlover > wrote: > > >Janet > wrote: > >> Ellen K. wrote: > >> > >> > I'd love to hear why you thought C++ was the easiest, in many circles > >> > it's considered the only language "real" programmers use. > >> > >> Hah. "Real" programmers use assembler. <G> > > > > Assembler is for wimps. Real programmers use machine language, entered > >through the switch register. > > > >-- > >Frank Slootweg > > I spent several weeks attempting to learn it in Darwin for our Message > Switch computer in 1979. Lda, Sty, counting in hexadecimal and all > that. > > I think I forgot it all by the time I got on the plane to go back to > Canberra. I still can't get my head around A being a number after 8:) Hex is for wimps. Real programmers use octal. -- Frank Slootweg |
unplugging...
On 19/09/2010 12:22 AM, outsider wrote:
> It doesn't stop there, you know. The next iteration discusses > hand punching Jacquard cards. But I really really hate knitting and weaving :-) (- -) =m=(_)=m= RodS T2 Australia |
unplugging...
"Chris Malcolm" > wrote in message ... > In alt.support.diabetes RodS > wrote: >> On 18/09/2010 5:14 AM, Boomer wrote: > >>> Interesting to find out how much so many of us have in common besides >>> diabetes. Code writing is becoming something now that many employees >>> simply must do. Learn how or perish. I think you spent much more time at >>> this than I have. Like I said I had this fault of creating nested if >>> thens that would make my head explode. > >> Easy just bung in a goto instead :-) >> or better yet nested gotos :-) > >>> I did solve a lot of these with >>> the switch command. Solve is not the right answer, made better would be >>> more accurate. > > Having to have a lot of complex exceptions to the main line of > structured code is often a sign that you're trying to do the right > thing, which is to follow the logic of the data structures with the > procedural or subroutine delegation of the program code, but > something's gone wrong. That data strucure following works very well > when the data structure is categorically well structure. It fails when > you have to deal with two parallel or independent kinds of data > structures. In that case whichever data structure you follow with your > code, the other has be dealt with by a patchwork of messy exceptions. > > Unless instead of subroutines you use (tada!) coroutines -- a very > useful software control structuring trick available to the systems > assembler programmer, but rarely reflected into higher level > programming languages. It's a kind of simultaneous subroutine call and > exit, which allows the co-existence of neatly programmed parallel > control structures to follow parallel data structures. > > -- > Chris Malcolm The situation you describe sounds like the very beginning of the process needs to separately define the possible cases, then provide separate handling for each one. |
unplugging...
"Bjørn Steensrud" > wrote in message g... > On Fri, 17 Sep 2010 14:15:57 -0500, Boomer wrote: > >> "Janet" > wrote in message >> ... >>> Ellen K. wrote: >>> >>>> I'd love to hear why you thought C++ was the easiest, in many circles >>>> it's considered the only language "real" programmers use. >>> >>> Hah. "Real" programmers use assembler. <G> >>> >>> >>> >>> >> That is probably true. I tried doing some of that. Yikes. I was quickly >> back to the comfortable safety of C++. >> >> Michael > > By that token I am - or was - a real programmer. I wrote a channel > program for an IBM 360, to drive a paper tape punch. IBM had delivered the > hardware, but no software :-) I can't remember what the OS was ... > Most of the time I maintained and developed a largish CAD/CAM system > written mostly in Fortran, with pieces first in assembler and later in C. > I'm impressed. :) |
unplugging...
"Bjørn Steensrud" wrote
> Boomer wrote: > By that token I am - or was - a real programmer. I wrote a channel > program for an IBM 360, to drive a paper tape punch. IBM had delivered the > hardware, but no software :-) I can't remember what the OS was ... BSD I think (Unix version), if not, System 5 comes to mind? They were still around in the early 80's and worked on them (among others). Now I just do SQL. |
unplugging...
"Alan S" wrote
> I think I forgot it all by the time I got on the plane to go back to > Canberra. I still can't get my head around A being a number after 8:) ;-) that's after 9. 6 7 8 9 A B C D F (F=15). The DEC series used it in boot routine. |
unplugging...
"Janet" wrote
> Ozlover wrote: >>> Hah. "Real" programmers use assembler. <G> >> Assembler is for wimps. Real programmers use machine language, >> entered through the switch register. > Why did I have the feeling that someone would say that! <G> LOL! POP AX is good enough for me! (and about all the assembler I remember!) |
unplugging...
On Sun, 19 Sep 2010 08:44:59 -0400, cshenk wrote:
> "Bjørn Steensrud" wrote >> Boomer wrote: > >> By that token I am - or was - a real programmer. I wrote a channel >> program for an IBM 360, to drive a paper tape punch. IBM had delivered >> the hardware, but no software :-) I can't remember what the OS was ... > > BSD I think (Unix version), if not, System 5 comes to mind? > > They were still around in the early 80's and worked on them (among > others). > > Now I just do SQL. DOS/VS or possibly an early MVS. This was the 360 series and I don't think they ever ran a Unix version. Later in life I wrote Perl scripts to run the SQL that other people wrote :-) |
unplugging...
On Sun, 19 Sep 2010 08:50:41 -0400, cshenk wrote:
> "Janet" wrote >> Ozlover wrote: > >>>> Hah. "Real" programmers use assembler. <G> > >>> Assembler is for wimps. Real programmers use machine language, >>> entered through the switch register. > >> Why did I have the feeling that someone would say that! <G> > > LOL! POP AX is good enough for me! (and about all the assembler I > remember!) BR 14 :-) |
unplugging...
"Bjørn Steensrud" wrote
> cshenk wrote: >>> Why did I have the feeling that someone would say that! <G> >> >> LOL! POP AX is good enough for me! (and about all the assembler I >> remember!) > BR 14 :-) Braker braker! (-*> |
unplugging...
"Bjørn Steensrud" wrote
> cshenk wrote: >>> program for an IBM 360, to drive a paper tape punch. IBM had delivered >>> the hardware, but no software :-) I can't remember what the OS was ... >> BSD I think (Unix version), if not, System 5 comes to mind? >> They were still around in the early 80's and worked on them (among >> others). > DOS/VS or possibly an early MVS. This was the 360 series and I don't > think they ever ran a Unix version. Um, sorry but they predate the creation of DOS. |
unplugging...
On Sun, 19 Sep 2010 12:03:50 -0400, cshenk wrote:
> "Bjørn Steensrud" wrote >> cshenk wrote: > >>>> program for an IBM 360, to drive a paper tape punch. IBM had >>>> delivered the hardware, but no software :-) I can't remember what >>>> the OS was ... >>> BSD I think (Unix version), if not, System 5 comes to mind? They were >>> still around in the early 80's and worked on them (among others). > >> DOS/VS or possibly an early MVS. This was the 360 series and I don't >> think they ever ran a Unix version. > > Um, sorry but they predate the creation of DOS. A different DOS. I see I should have written DOS/360. Yes, it predates the x86 CPUs. This is Disk Operating System, while the origin of MS-DOS was QDOS: Quick and Dirty Operating System :-P . By the time I was working on the assembler code it was DOS/VS. http://en.wikipedia.org/wiki/DOS/360 |
unplugging...
"Bjørn Steensrud" > wrote in message g... > On Sun, 19 Sep 2010 08:44:59 -0400, cshenk wrote: > >> "Bjørn Steensrud" wrote >>> Boomer wrote: >> >>> By that token I am - or was - a real programmer. I wrote a channel >>> program for an IBM 360, to drive a paper tape punch. IBM had delivered >>> the hardware, but no software :-) I can't remember what the OS was ... >> >> BSD I think (Unix version), if not, System 5 comes to mind? >> >> They were still around in the early 80's and worked on them (among >> others). >> >> Now I just do SQL. > > DOS/VS or possibly an early MVS. This was the 360 series and I don't > think they ever ran a Unix version. > > Later in life I wrote Perl scripts to run the SQL that other people > wrote :-) > And I once had a job where I wrote a program that generated SQL statements that were then SPUFI'd to the mainframe DB2 database by the mainframe folks since I wasn't allowed to directly address it. It ran once a month and each time it generated about 100 text files of 300 SQL statements each (because they wanted me to make a commit every 300 statements). I analyzed the data from a real-time clone that was propagated to an Oracle database running on one of the flavors of unix, can't remember which one now. It took my program about 24 hours to download the relevant data each month (made a bit faster by using two PC's, each doing half). |
unplugging...
"Ellen K." wrote
> "Bjørn Steensrud" wrote >>> Now I just do SQL. > And I once had a job where I wrote a program that generated SQL statements > that were then SPUFI'd to the mainframe DB2 database by the mainframe > folks since I wasn't allowed to directly address it. It ran once a month > and each time it generated about 100 text files of 300 SQL statements each > (because they wanted me to make a commit every 300 statements). I > analyzed the data from a real-time clone that was propagated to an Oracle > database running on one of the flavors of unix, can't remember which one > now. It took my program about 24 hours to download the relevant data each > month (made a bit faster by using two PC's, each doing half). Faster now by far to do it! I mostly either freehand or when doing batches, use a concatinated excel I made to make it easier. 'Fill in the blank' as I do alot of inserts. Updates I pretty much freehand and of course random queries are freehand to check things out. |
unplugging...
"cshenk" > wrote in message ... > "Ellen K." wrote >> "Bjørn Steensrud" wrote > >>>> Now I just do SQL. > >> And I once had a job where I wrote a program that generated SQL >> statements that were then SPUFI'd to the mainframe DB2 database by the >> mainframe folks since I wasn't allowed to directly address it. It ran >> once a month and each time it generated about 100 text files of 300 SQL >> statements each (because they wanted me to make a commit every 300 >> statements). I analyzed the data from a real-time clone that was >> propagated to an Oracle database running on one of the flavors of unix, >> can't remember which one now. It took my program about 24 hours to >> download the relevant data each month (made a bit faster by using two >> PC's, each doing half). > > Faster now by far to do it! > > I mostly either freehand or when doing batches, use a concatinated excel I > made to make it easier. 'Fill in the blank' as I do alot of inserts. > Updates I pretty much freehand and of course random queries are freehand > to check things out. > As noted, I was not allowed direct access to the mainframe DB2 database, that was why I had to generate the scripts. |
unplugging...
On Mon, 20 Sep 2010 07:51:29 +1000, Alan S wrote:
> On Sun, 19 Sep 2010 08:48:26 -0400, "cshenk" > wrote: > >>"Alan S" wrote >> >>> I think I forgot it all by the time I got on the plane to go back to >>> Canberra. I still can't get my head around A being a number after 8:) >> >>;-) that's after 9. 6 7 8 9 A B C D F (F=15). The DEC series used it >>in boot routine. > > I'll believe you. The last time I used it was 1978 and I successfully > forgot it ever since. I forget the crime, but the punishment was that "he and his successors shall read hex dumps for ever." Now we just start a debugger :-) |
unplugging...
In alt.support.diabetes Ellen K. > wrote:
> "Chris Malcolm" > wrote in message > ... >> In alt.support.diabetes RodS > wrote: >>> On 18/09/2010 5:14 AM, Boomer wrote: >> >>>> Interesting to find out how much so many of us have in common besides >>>> diabetes. Code writing is becoming something now that many employees >>>> simply must do. Learn how or perish. I think you spent much more time at >>>> this than I have. Like I said I had this fault of creating nested if >>>> thens that would make my head explode. >> >>> Easy just bung in a goto instead :-) >>> or better yet nested gotos :-) >> >>>> I did solve a lot of these with >>>> the switch command. Solve is not the right answer, made better would be >>>> more accurate. >> >> Having to have a lot of complex exceptions to the main line of >> structured code is often a sign that you're trying to do the right >> thing, which is to follow the logic of the data structures with the >> procedural or subroutine delegation of the program code, but >> something's gone wrong. That data strucure following works very well >> when the data structure is categorically well structure. It fails when >> you have to deal with two parallel or independent kinds of data >> structures. In that case whichever data structure you follow with your >> code, the other has be dealt with by a patchwork of messy exceptions. >> >> Unless instead of subroutines you use (tada!) coroutines -- a very >> useful software control structuring trick available to the systems >> assembler programmer, but rarely reflected into higher level >> programming languages. It's a kind of simultaneous subroutine call and >> exit, which allows the co-existence of neatly programmed parallel >> control structures to follow parallel data structures. >> >> -- >> Chris Malcolm > The situation you describe sounds like the very beginning of the process > needs to separately define the possible cases, then provide separate > handling for each one. The classic data structure problem which coroutines solve very neatly is the interleaved packaging problem which occurs in telecommunications. Suppose your comms protocol only allows maximum package sizes of 1 kilobyte at a time. So if you have lots of small emails to send then a dozen might be put into one package. So one package can will contain a number of emails. But if you have a large email of say 20 kilobytes to send, then your large email will contain lots of packages. So sometimes you have to unpack packages to get at the emails inside, and sometimes you have to unpack emails to get at the packages inside. That doesn't sound too hard a problem. But start adding in all sorts of exception conditions, retransmission requests, missing package problems, checksum failures at various levels, emails which contain attachments inside them, packages which are wrapped up inside larger transmission protocol packages, and it starts getting very messy. Hard to handle with classic data structures which insist on a simple categorical structures where for example emails must either be parts of a package, or alternatively packages must be parts of an email, but not both. The same goes for classic program control structuring methods such as procedural decomposition where control has the same strict hierarchy of delegatation and return of control. It would be like a management structure in which for some parts of the day your boss tells you what to do because he's your boss, and at other times you tell your boss what to do because you are his boss. -- Chris Malcolm |
unplugging...
"cshenk" > wrote in message
... > "Ellen K." wrote >> "Bjørn Steensrud" wrote > >>>> Now I just do SQL. > >> And I once had a job where I wrote a program that generated SQL >> statements that were then SPUFI'd to the mainframe DB2 database by the >> mainframe folks since I wasn't allowed to directly address it. It ran >> once a month and each time it generated about 100 text files of 300 SQL >> statements each (because they wanted me to make a commit every 300 >> statements). I analyzed the data from a real-time clone that was >> propagated to an Oracle database running on one of the flavors of unix, >> can't remember which one now. It took my program about 24 hours to >> download the relevant data each month (made a bit faster by using two >> PC's, each doing half). > > Faster now by far to do it! > > I mostly either freehand or when doing batches, use a concatinated excel I > made to make it easier. 'Fill in the blank' as I do alot of inserts. > Updates I pretty much freehand and of course random queries are freehand > to check things out. But...can they cook? Cheri |
unplugging...
"Chris Malcolm" > wrote in message ... > In alt.support.diabetes Ellen K. > > wrote: > >> "Chris Malcolm" > wrote in message >> ... >>> In alt.support.diabetes RodS > wrote: >>>> On 18/09/2010 5:14 AM, Boomer wrote: >>> >>>>> Interesting to find out how much so many of us have in common besides >>>>> diabetes. Code writing is becoming something now that many employees >>>>> simply must do. Learn how or perish. I think you spent much more time >>>>> at >>>>> this than I have. Like I said I had this fault of creating nested if >>>>> thens that would make my head explode. >>> >>>> Easy just bung in a goto instead :-) >>>> or better yet nested gotos :-) >>> >>>>> I did solve a lot of these with >>>>> the switch command. Solve is not the right answer, made better would >>>>> be >>>>> more accurate. >>> >>> Having to have a lot of complex exceptions to the main line of >>> structured code is often a sign that you're trying to do the right >>> thing, which is to follow the logic of the data structures with the >>> procedural or subroutine delegation of the program code, but >>> something's gone wrong. That data strucure following works very well >>> when the data structure is categorically well structure. It fails when >>> you have to deal with two parallel or independent kinds of data >>> structures. In that case whichever data structure you follow with your >>> code, the other has be dealt with by a patchwork of messy exceptions. >>> >>> Unless instead of subroutines you use (tada!) coroutines -- a very >>> useful software control structuring trick available to the systems >>> assembler programmer, but rarely reflected into higher level >>> programming languages. It's a kind of simultaneous subroutine call and >>> exit, which allows the co-existence of neatly programmed parallel >>> control structures to follow parallel data structures. >>> >>> -- >>> Chris Malcolm > >> The situation you describe sounds like the very beginning of the process >> needs to separately define the possible cases, then provide separate >> handling for each one. > > The classic data structure problem which coroutines solve very neatly > is the interleaved packaging problem which occurs in > telecommunications. Suppose your comms protocol only allows maximum > package sizes of 1 kilobyte at a time. So if you have lots of small > emails to send then a dozen might be put into one package. So one > package can will contain a number of emails. But if you have a large > email of say 20 kilobytes to send, then your large email will contain > lots of packages. So sometimes you have to unpack packages to get at > the emails inside, and sometimes you have to unpack emails to get at > the packages inside. > > That doesn't sound too hard a problem. But start adding in all sorts > of exception conditions, retransmission requests, missing package > problems, checksum failures at various levels, emails which contain > attachments inside them, packages which are wrapped up inside larger > transmission protocol packages, and it starts getting very messy. > > Hard to handle with classic data structures which insist on a simple > categorical structures where for example emails must either be parts > of a package, or alternatively packages must be parts of an email, but > not both. The same goes for classic program control structuring > methods such as procedural decomposition where control has the same > strict hierarchy of delegatation and return of control. It would be > like a management structure in which for some parts of the day your > boss tells you what to do because he's your boss, and at other times > you tell your boss what to do because you are his boss. > > -- > Chris Malcolm I've never worked with that type of thing, only applications working directly with business data, mostly financial. |
unplugging...
"Cheri" > wrote in message ... > "cshenk" > wrote in message > ... >> "Ellen K." wrote >>> "Bjørn Steensrud" wrote >> >>>>> Now I just do SQL. >> >>> And I once had a job where I wrote a program that generated SQL >>> statements that were then SPUFI'd to the mainframe DB2 database by the >>> mainframe folks since I wasn't allowed to directly address it. It ran >>> once a month and each time it generated about 100 text files of 300 SQL >>> statements each (because they wanted me to make a commit every 300 >>> statements). I analyzed the data from a real-time clone that was >>> propagated to an Oracle database running on one of the flavors of unix, >>> can't remember which one now. It took my program about 24 hours to >>> download the relevant data each month (made a bit faster by using two >>> PC's, each doing half). >> >> Faster now by far to do it! >> >> I mostly either freehand or when doing batches, use a concatinated excel >> I made to make it easier. 'Fill in the blank' as I do alot of inserts. >> Updates I pretty much freehand and of course random queries are freehand >> to check things out. > > But...can they cook? > > Cheri Carol looks to be quite expert at cooking! Back in the day people used to tell me I should open a restaurant but now I hardly cook anything any more. |
unplugging...
"Bjørn Steensrud" > wrote in message g... > On Mon, 20 Sep 2010 07:51:29 +1000, Alan S wrote: > >> On Sun, 19 Sep 2010 08:48:26 -0400, "cshenk" > wrote: >> >>>"Alan S" wrote >>> >>>> I think I forgot it all by the time I got on the plane to go back to >>>> Canberra. I still can't get my head around A being a number after 8:) >>> >>>;-) that's after 9. 6 7 8 9 A B C D F (F=15). The DEC series used it >>>in boot routine. >> >> I'll believe you. The last time I used it was 1978 and I successfully >> forgot it ever since. > > I forget the crime, but the punishment was that "he and his successors > shall read hex dumps for ever." Now we just start a debugger :-) <g> |
unplugging...
In alt.support.diabetes Ellen K. > wrote:
> "Chris Malcolm" > wrote in message > ... >> In alt.support.diabetes Ellen K. > >> wrote: >>> "Chris Malcolm" > wrote in message >>> ... >>>> Having to have a lot of complex exceptions to the main line of >>>> structured code is often a sign that you're trying to do the right >>>> thing, which is to follow the logic of the data structures with the >>>> procedural or subroutine delegation of the program code, but >>>> something's gone wrong. That data strucure following works very well >>>> when the data structure is categorically well structure. It fails when >>>> you have to deal with two parallel or independent kinds of data >>>> structures. In that case whichever data structure you follow with your >>>> code, the other has be dealt with by a patchwork of messy exceptions. >>>> >>>> Unless instead of subroutines you use (tada!) coroutines -- a very >>>> useful software control structuring trick available to the systems >>>> assembler programmer, but rarely reflected into higher level >>>> programming languages. It's a kind of simultaneous subroutine call and >>>> exit, which allows the co-existence of neatly programmed parallel >>>> control structures to follow parallel data structures. >>>> >>>> -- >>>> Chris Malcolm >> >>> The situation you describe sounds like the very beginning of the process >>> needs to separately define the possible cases, then provide separate >>> handling for each one. >> >> The classic data structure problem which coroutines solve very neatly >> is the interleaved packaging problem which occurs in >> telecommunications. Suppose your comms protocol only allows maximum >> package sizes of 1 kilobyte at a time. So if you have lots of small >> emails to send then a dozen might be put into one package. So one >> package can will contain a number of emails. But if you have a large >> email of say 20 kilobytes to send, then your large email will contain >> lots of packages. So sometimes you have to unpack packages to get at >> the emails inside, and sometimes you have to unpack emails to get at >> the packages inside. >> >> That doesn't sound too hard a problem. But start adding in all sorts >> of exception conditions, retransmission requests, missing package >> problems, checksum failures at various levels, emails which contain >> attachments inside them, packages which are wrapped up inside larger >> transmission protocol packages, and it starts getting very messy. >> >> Hard to handle with classic data structures which insist on a simple >> categorical structures where for example emails must either be parts >> of a package, or alternatively packages must be parts of an email, but >> not both. The same goes for classic program control structuring >> methods such as procedural decomposition where control has the same >> strict hierarchy of delegatation and return of control. It would be >> like a management structure in which for some parts of the day your >> boss tells you what to do because he's your boss, and at other times >> you tell your boss what to do because you are his boss. >> >> -- >> Chris Malcolm > I've never worked with that type of thing, only applications working > directly with business data, mostly financial. Type of data is irrelevant, it's what kind of structure it has. IIRC at least one airline ticket reservation system had this kind of problem and solved it with coroutines. -- Chris Malcolm |
unplugging...
"Cheri" wrote
> "cshenk" wrote >> I mostly either freehand or when doing batches, use a concatinated excel >> I made to make it easier. 'Fill in the blank' as I do alot of inserts. >> Updates I pretty much freehand and of course random queries are freehand >> to check things out. > > But...can they cook? Snicker, no but they can dance with Data! <--- ST Next Gen joke |
unplugging...
"Ellen K." wrote
> "Cheri" wrote >> But...can they cook? > Carol looks to be quite expert at cooking! Back in the day people used > to tell me I should open a restaurant but now I hardly cook anything any > more. Hehe I cook lots as does the hubby. Our rare arguements are because I got something special to try out and he got to it first. (grr!) I goofed and defrosted a duck in the fridge starting late Wed night once, figuring to try a new recipe come Friday when i got home but nooooo, he found it and made it before I got home (grumble, even if it was delicious). Oh we cook special needs diets for guests all the tiume too. The only ones i won't cater to is the 'picky eater just looking for attention/control the world' set. You know the sort probably from someplace. Not a diet related thing from a medical need but trying to make everyome else go 'ooh your poor baby' and center on their whims to make them feel important. We do mostly weekly neighborhood cookouts in my backyard (scan for Cshenk1 on Rec.food.cooking for a history and what times i bothered to typo up what we did). Picky eaters need not apply if they insist all foods suit them. Our ethics are simple. Don't like beets? Ignore the beet dish. |
unplugging...
"Chris Malcolm" > wrote in message ... > In alt.support.diabetes Ellen K. > > wrote: >> "Chris Malcolm" > wrote in message >> ... >>> In alt.support.diabetes Ellen K. > >>> wrote: >>>> "Chris Malcolm" > wrote in message >>>> ... > >>>>> Having to have a lot of complex exceptions to the main line of >>>>> structured code is often a sign that you're trying to do the right >>>>> thing, which is to follow the logic of the data structures with the >>>>> procedural or subroutine delegation of the program code, but >>>>> something's gone wrong. That data strucure following works very well >>>>> when the data structure is categorically well structure. It fails when >>>>> you have to deal with two parallel or independent kinds of data >>>>> structures. In that case whichever data structure you follow with your >>>>> code, the other has be dealt with by a patchwork of messy exceptions. >>>>> >>>>> Unless instead of subroutines you use (tada!) coroutines -- a very >>>>> useful software control structuring trick available to the systems >>>>> assembler programmer, but rarely reflected into higher level >>>>> programming languages. It's a kind of simultaneous subroutine call and >>>>> exit, which allows the co-existence of neatly programmed parallel >>>>> control structures to follow parallel data structures. >>>>> >>>>> -- >>>>> Chris Malcolm >>> >>>> The situation you describe sounds like the very beginning of the >>>> process >>>> needs to separately define the possible cases, then provide separate >>>> handling for each one. >>> >>> The classic data structure problem which coroutines solve very neatly >>> is the interleaved packaging problem which occurs in >>> telecommunications. Suppose your comms protocol only allows maximum >>> package sizes of 1 kilobyte at a time. So if you have lots of small >>> emails to send then a dozen might be put into one package. So one >>> package can will contain a number of emails. But if you have a large >>> email of say 20 kilobytes to send, then your large email will contain >>> lots of packages. So sometimes you have to unpack packages to get at >>> the emails inside, and sometimes you have to unpack emails to get at >>> the packages inside. >>> >>> That doesn't sound too hard a problem. But start adding in all sorts >>> of exception conditions, retransmission requests, missing package >>> problems, checksum failures at various levels, emails which contain >>> attachments inside them, packages which are wrapped up inside larger >>> transmission protocol packages, and it starts getting very messy. >>> >>> Hard to handle with classic data structures which insist on a simple >>> categorical structures where for example emails must either be parts >>> of a package, or alternatively packages must be parts of an email, but >>> not both. The same goes for classic program control structuring >>> methods such as procedural decomposition where control has the same >>> strict hierarchy of delegatation and return of control. It would be >>> like a management structure in which for some parts of the day your >>> boss tells you what to do because he's your boss, and at other times >>> you tell your boss what to do because you are his boss. >>> >>> -- >>> Chris Malcolm > >> I've never worked with that type of thing, only applications working >> directly with business data, mostly financial. > > Type of data is irrelevant, it's what kind of structure it has. IIRC > at least one airline ticket reservation system had this kind of > problem and solved it with coroutines. > > -- > Chris Malcolm Which is why I said the program needs to define the different possible cases at the beginning, then specify the handling for each. I really didn't think that was different regardless of the underlying substance, but you responded by telling me you were working with transmission of packets etc. Maybe what I'm calling defining the different possible cases at the beginning and then specifying the handling for each is what you're calling a coroutine, the fact that I've never heard that expression doesn't mean anything. |
unplugging...
In alt.support.diabetes Ellen K. > wrote:
> "Chris Malcolm" > wrote in message > ... >> In alt.support.diabetes Ellen K. > >> wrote: >>> "Chris Malcolm" > wrote in message >>> ... >>>> In alt.support.diabetes Ellen K. > >>>> wrote: >>>>> "Chris Malcolm" > wrote in message >>>>> ... >> >>>>>> Having to have a lot of complex exceptions to the main line of >>>>>> structured code is often a sign that you're trying to do the right >>>>>> thing, which is to follow the logic of the data structures with the >>>>>> procedural or subroutine delegation of the program code, but >>>>>> something's gone wrong. That data strucure following works very well >>>>>> when the data structure is categorically well structure. It fails when >>>>>> you have to deal with two parallel or independent kinds of data >>>>>> structures. In that case whichever data structure you follow with your >>>>>> code, the other has be dealt with by a patchwork of messy exceptions. >>>>>> >>>>>> Unless instead of subroutines you use (tada!) coroutines -- a very >>>>>> useful software control structuring trick available to the systems >>>>>> assembler programmer, but rarely reflected into higher level >>>>>> programming languages. It's a kind of simultaneous subroutine call and >>>>>> exit, which allows the co-existence of neatly programmed parallel >>>>>> control structures to follow parallel data structures. >>>>>> >>>>>> -- >>>>>> Chris Malcolm >>>> >>>>> The situation you describe sounds like the very beginning of the >>>>> process >>>>> needs to separately define the possible cases, then provide separate >>>>> handling for each one. >>>> >>>> The classic data structure problem which coroutines solve very neatly >>>> is the interleaved packaging problem which occurs in >>>> telecommunications. Suppose your comms protocol only allows maximum >>>> package sizes of 1 kilobyte at a time. So if you have lots of small >>>> emails to send then a dozen might be put into one package. So one >>>> package can will contain a number of emails. But if you have a large >>>> email of say 20 kilobytes to send, then your large email will contain >>>> lots of packages. So sometimes you have to unpack packages to get at >>>> the emails inside, and sometimes you have to unpack emails to get at >>>> the packages inside. >>>> >>>> That doesn't sound too hard a problem. But start adding in all sorts >>>> of exception conditions, retransmission requests, missing package >>>> problems, checksum failures at various levels, emails which contain >>>> attachments inside them, packages which are wrapped up inside larger >>>> transmission protocol packages, and it starts getting very messy. >>>> >>>> Hard to handle with classic data structures which insist on a simple >>>> categorical structures where for example emails must either be parts >>>> of a package, or alternatively packages must be parts of an email, but >>>> not both. The same goes for classic program control structuring >>>> methods such as procedural decomposition where control has the same >>>> strict hierarchy of delegatation and return of control. It would be >>>> like a management structure in which for some parts of the day your >>>> boss tells you what to do because he's your boss, and at other times >>>> you tell your boss what to do because you are his boss. >>>> >>>> -- >>>> Chris Malcolm >> >>> I've never worked with that type of thing, only applications working >>> directly with business data, mostly financial. >> >> Type of data is irrelevant, it's what kind of structure it has. IIRC >> at least one airline ticket reservation system had this kind of >> problem and solved it with coroutines. >> >> -- >> Chris Malcolm > Which is why I said the program needs to define the different possible cases > at the beginning, then specify the handling for each. I really didn't think > that was different regardless of the underlying substance, but you responded > by telling me you were working with transmission of packets etc. Not "what I was working with". I simply explained the classic simple data packaging and structuring problem which coroutines were first used to solve and which is usually used in teaching about them. > Maybe what > I'm calling defining the different possible cases at the beginning and then > specifying the handling for each is what you're calling a coroutine, the > fact that I've never heard that expression doesn't mean anything. There follows a page or two of explanation of coroutines and program code structuring which some may like to skip :-) The problem coroutines solve hasn't anything to do with how each individual data case is handled, it's to do with how the individual cases are related to each other, the data structuring. The normal relationship is either flat, where all cases are indepemdent, or it's hierarchical, where some cases are parts of other cases. That's how it is for example with text, where a letter is part of a word, a word is part of a sentence, a sentence is part of a paragraph, a paragraph might be part of a section, and a section might be part of a chapter. So in writing the program code to deal with displaying, formatting, and editing text, you'd call the subroutine which dealt with letters from inside the subroutine which dealt with words, call the subroutine which dealt with words from inside the subroutine which dealt with sentences, and so on. That's if you were programming in assembly code. If you were programming in a higher level language you'd nest your procedure definitions according to the nesting of the data types of word and sentence etc.. But there are some cases where that kind of simple hierarchical relationship breaks down. Such as when we introduce the printed page of text. A printed page contains a fixed maxumin number of lines. And a line contains a fixed maximum number of letters. But a line may break a word or sentence in half. And a page may break paragraphs and sentences, and is sometimes allowed to break words too, with a long word being hyphenated so it can break across a line boundary and sometimes a page boundary. Coroutines are a program writing and code structuring concept which can be used in assembly code. Subroutines are the elementary program code structuring element made available in computer hardware and assembly language. Subroutines can only exit when they're finished, when control passes up again to the calling code. Subroutines can call subroutines which can call subroutines etc., which requires a subroutine call address stack. In higher level languages procedures pass data along with the procedure call and return the data on exist which requires data stacking along with subroutine call stacking. The stacking of calls and data is such a useful and important basic program code structuring tool that some programming languages have been built around the concept, and some early computer processors were designed around stacking. Hewlett Packard calculators with their reverse Polish use of arithmetic operations brought the concept into the programming of programmable calculators. I'm sure some here remember them! Coroutines differ in a number of ways from subroutines. For example they're allowed to exit when they're only part finished, to be resumed from where they broke off when the next coroutine call is made. That allows a very natural and elegant programming solution to the kind of interleaved multiple data hierarchies I've been describing. Another way of handling the same kind of data structuring problem elegantly (but not quite as elegant as with coroutines) is by using software interrupts which invoke the hardware interrupt mechanisms of the computer by means of programmed software. In the early days of computers not all computers had such a facility in the hardware of the computer. These days (almost) all computers have it, but its use is usually restricted to the systems programmers who program the operating system. I brought in the idea of coroutines because folk were discussing esoteric aspects of certain kinds of programming such as programming in assembly language and hexadecimal. I just wondered if there were any folk around who'd done enough serious complicated assembly language coding to have heard of or even used coroutines. Seems not. Just wondered :-) -- Chris Malcolm |
unplugging...
On Sat, 25 Sep 2010 05:52:24 +0000, Chris Malcolm wrote:
> In alt.support.diabetes Ellen K. > > wrote: >> "Chris Malcolm" > wrote in message >> ... >>> In alt.support.diabetes Ellen K. > >>> wrote: >>>> "Chris Malcolm" > wrote in message >>>> ... >>>>> In alt.support.diabetes Ellen K. >>>>> > wrote: >>>>>> "Chris Malcolm" > wrote in message >>>>>> ... >>> >>>>>>> Having to have a lot of complex exceptions to the main line of >>>>>>> structured code is often a sign that you're trying to do the right >>>>>>> thing, which is to follow the logic of the data structures with >>>>>>> the procedural or subroutine delegation of the program code, but >>>>>>> something's gone wrong. That data strucure following works very >>>>>>> well when the data structure is categorically well structure. It >>>>>>> fails when you have to deal with two parallel or independent kinds >>>>>>> of data structures. In that case whichever data structure you >>>>>>> follow with your code, the other has be dealt with by a patchwork >>>>>>> of messy exceptions. >>>>>>> >>>>>>> Unless instead of subroutines you use (tada!) coroutines -- a very >>>>>>> useful software control structuring trick available to the systems >>>>>>> assembler programmer, but rarely reflected into higher level >>>>>>> programming languages. It's a kind of simultaneous subroutine call >>>>>>> and exit, which allows the co-existence of neatly programmed >>>>>>> parallel control structures to follow parallel data structures. >>>>>>> >>>>>>> -- >>>>>>> Chris Malcolm >>>>> >>>>>> The situation you describe sounds like the very beginning of the >>>>>> process >>>>>> needs to separately define the possible cases, then provide >>>>>> separate handling for each one. >>>>> >>>>> The classic data structure problem which coroutines solve very >>>>> neatly is the interleaved packaging problem which occurs in >>>>> telecommunications. Suppose your comms protocol only allows maximum >>>>> package sizes of 1 kilobyte at a time. So if you have lots of small >>>>> emails to send then a dozen might be put into one package. So one >>>>> package can will contain a number of emails. But if you have a large >>>>> email of say 20 kilobytes to send, then your large email will >>>>> contain lots of packages. So sometimes you have to unpack packages >>>>> to get at the emails inside, and sometimes you have to unpack emails >>>>> to get at the packages inside. >>>>> >>>>> That doesn't sound too hard a problem. But start adding in all sorts >>>>> of exception conditions, retransmission requests, missing package >>>>> problems, checksum failures at various levels, emails which contain >>>>> attachments inside them, packages which are wrapped up inside larger >>>>> transmission protocol packages, and it starts getting very messy. >>>>> >>>>> Hard to handle with classic data structures which insist on a simple >>>>> categorical structures where for example emails must either be parts >>>>> of a package, or alternatively packages must be parts of an email, >>>>> but not both. The same goes for classic program control structuring >>>>> methods such as procedural decomposition where control has the same >>>>> strict hierarchy of delegatation and return of control. It would be >>>>> like a management structure in which for some parts of the day your >>>>> boss tells you what to do because he's your boss, and at other times >>>>> you tell your boss what to do because you are his boss. >>>>> >>>>> -- >>>>> Chris Malcolm >>> >>>> I've never worked with that type of thing, only applications working >>>> directly with business data, mostly financial. >>> >>> Type of data is irrelevant, it's what kind of structure it has. IIRC >>> at least one airline ticket reservation system had this kind of >>> problem and solved it with coroutines. >>> >>> -- >>> Chris Malcolm > >> Which is why I said the program needs to define the different possible >> cases at the beginning, then specify the handling for each. I really >> didn't think that was different regardless of the underlying substance, >> but you responded by telling me you were working with transmission of >> packets etc. > > Not "what I was working with". I simply explained the classic simple > data packaging and structuring problem which coroutines were first used > to solve and which is usually used in teaching about them. > >> Maybe what >> I'm calling defining the different possible cases at the beginning and >> then specifying the handling for each is what you're calling a >> coroutine, the fact that I've never heard that expression doesn't mean >> anything. > > There follows a page or two of explanation of coroutines and program > code structuring which some may like to skip :-) > > The problem coroutines solve hasn't anything to do with how each > individual data case is handled, it's to do with how the individual > cases are related to each other, the data structuring. > > The normal relationship is either flat, where all cases are indepemdent, > or it's hierarchical, where some cases are parts of other cases. That's > how it is for example with text, where a letter is part of a word, a > word is part of a sentence, a sentence is part of a paragraph, a > paragraph might be part of a section, and a section might be part of a > chapter. > > So in writing the program code to deal with displaying, formatting, and > editing text, you'd call the subroutine which dealt with letters from > inside the subroutine which dealt with words, call the subroutine which > dealt with words from inside the subroutine which dealt with sentences, > and so on. That's if you were programming in assembly code. If you were > programming in a higher level language you'd nest your procedure > definitions according to the nesting of the data types of word and > sentence etc.. > > But there are some cases where that kind of simple hierarchical > relationship breaks down. Such as when we introduce the printed page of > text. A printed page contains a fixed maxumin number of lines. And a > line contains a fixed maximum number of letters. But a line may break a > word or sentence in half. And a page may break paragraphs and sentences, > and is sometimes allowed to break words too, with a long word being > hyphenated so it can break across a line boundary and sometimes a page > boundary. > > Coroutines are a program writing and code structuring concept which can > be used in assembly code. Subroutines are the elementary program code > structuring element made available in computer hardware and assembly > language. Subroutines can only exit when they're finished, when control > passes up again to the calling code. Subroutines can call subroutines > which can call subroutines etc., which requires a subroutine call > address stack. In higher level languages procedures pass data along with > the procedure call and return the data on exist which requires data > stacking along with subroutine call stacking. > > The stacking of calls and data is such a useful and important basic > program code structuring tool that some programming languages have been > built around the concept, and some early computer processors were > designed around stacking. Hewlett Packard calculators with their reverse > Polish use of arithmetic operations brought the concept into the > programming of programmable calculators. I'm sure some here remember > them! > > Coroutines differ in a number of ways from subroutines. For example > they're allowed to exit when they're only part finished, to be resumed > from where they broke off when the next coroutine call is made. That > allows a very natural and elegant programming solution to the kind of > interleaved multiple data hierarchies I've been describing. > > Another way of handling the same kind of data structuring problem > elegantly (but not quite as elegant as with coroutines) is by using > software interrupts which invoke the hardware interrupt mechanisms of > the computer by means of programmed software. In the early days of > computers not all computers had such a facility in the hardware of the > computer. These days (almost) all computers have it, but its use is > usually restricted to the systems programmers who program the operating > system. > > I brought in the idea of coroutines because folk were discussing > esoteric aspects of certain kinds of programming such as programming in > assembly language and hexadecimal. I just wondered if there were any > folk around who'd done enough serious complicated assembly language > coding to have heard of or even used coroutines. > > Seems not. Just wondered :-) I have read about coroutines, but never used them. However - a colleague, back in the '70s, managed to write recursive Fortran programs to parse a command language. Recursion depth was limited by the allocated size of the COMMON block used for stack memory, but we quickly found a size that handled all cases we ever encountered. (Of course someone could write a series of commands that would blow up the stack :-) ) |
unplugging...
On 9/16/2010 6:31 PM, Boomer wrote:
> > > "Ellen K." > wrote in message > ... >> >> "Boomer" > wrote in message >> ... >>> >>> >>> "Ellen K." > wrote in message >>> ... >>>> >>>> "Boomer" > wrote in message >>>> ... >>>>> >>>>> >>>>> "Ellen K." > wrote in message >>>>> ... >>>>>> >>>>>> "Janet" > wrote in message >>>>>> ... >>>>>>> Ellen K. wrote: >>>>>>> >>>>>>>> This is getting to be too many things to worry about. >>>>>>> >>>>>>> By doG, I thought you'd never get to that point. (I reached it >>>>>>> long ago! <G>) Seriously, your attention to detail has awed me. >>>>>>> You are made of sterner stuff than I. <G> >>>>>>> >>>>>> >>>>>> It's just the nature of the beast. I've basically worked with data >>>>>> most of my adult life. After 20 years in accounting and finance I >>>>>> transitioned into software development and related work. >>>>> >>>>> Ellen, I see you have worked in software. I wrote applications in >>>>> C++ as part of my job in engineering. What language did you use? >>>>> >>>>> Michael >>>>>> >>>> >>>> SQL is my strong suit. Unlike procedural or object-oriented >>>> languages it works with data setwise as opposed to with one instance >>>> of a data object at a time. This is a very different way of >>>> thinking, and extremely powerful when used as designed. Front-end >>>> programmers who write SQL tend to use it to still only work with one >>>> instance of an object at a time, then they wonder why the >>>> performance of the application leaves so much to be desired. >>>> >>>> C was the first language I learned, then C++, but I never used >>>> either of them in a production environment. I liked C because it was >>>> so economical and because it gave the programmer full control. The >>>> front-end programming I have done in a production environment was >>>> all VB. >>> >>> Well, you know a lot more about programming than myself. I programmed in several languages as part of my career. FORTRAN, BASIC, IBM 360 assembler, LOGIC 5, LASAR 6, and Verilog - mostly for electronic design. I've now decided to learn a few more so that I can help a few BOINC projects related to medical research and astronomy, so I'm learning C and preparing to learn C++. Robert Miles |
unplugging...
On 9/25/2010 12:52 AM, Chris Malcolm wrote:
> In alt.support.diabetes Ellen > wrote: >> "Chris > wrote in message >> ... >>> In alt.support.diabetes Ellen > >>> wrote: >>>> "Chris > wrote in message >>>> ... >>>>> In alt.support.diabetes Ellen > >>>>> wrote: >>>>>> "Chris > wrote in message >>>>>> ... [snip] > Coroutines differ in a number of ways from subroutines. For example > they're allowed to exit when they're only part finished, to be resumed > from where they broke off when the next coroutine call is made. That > allows a very natural and elegant programming solution to the kind of > interleaved multiple data hierarchies I've been describing. > > Another way of handling the same kind of data structuring problem > elegantly (but not quite as elegant as with coroutines) is by using > software interrupts which invoke the hardware interrupt mechanisms of > the computer by means of programmed software. In the early days of > computers not all computers had such a facility in the hardware of the > computer. These days (almost) all computers have it, but its use is > usually restricted to the systems programmers who program the > operating system. > > I brought in the idea of coroutines because folk were discussing > esoteric aspects of certain kinds of programming such as programming > in assembly language and hexadecimal. I just wondered if there were > any folk around who'd done enough serious complicated assembly > language coding to have heard of or even used coroutines. > > Seems not. Just wondered :-) I've used hexadecimal and done some assembly language programming, but that could have easily been before coroutines became known. I've never seen them mentioned before this thread. However, I have seen some multi-thread programs, not in assembler, that were written to have some parallel capability by being able to run on more than one core of a modern multi-core CPU at the same time. Perhaps a new name for the same thing? Robert Miles |
| All times are GMT +1. The time now is 09:53 PM. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
FoodBanter