Phil Hobbs wrote on 8/7/2017 6:56 PM:> On 08/07/2017 06:35 PM, rickman wrote: >> Phil Hobbs wrote on 8/7/2017 5:30 PM: >>> On 08/07/2017 04:47 PM, rickman wrote: >>>> Phil Hobbs wrote on 8/7/2017 3:27 PM: >>>>> On 08/07/2017 03:18 PM, rickman wrote: >>>>>> Phil Hobbs wrote on 8/7/2017 12:40 PM: >>>>>>> On 08/06/2017 07:21 PM, rickman wrote: >>>>>>>> Tom Gardner wrote on 8/6/2017 3:13 PM: >>>>>>>>> On 06/08/17 17:51, rickman wrote: >>>>>>>>>> John Devereux wrote on 8/6/2017 9:40 AM: >>>>>>>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>>>>>>> >>>>>>>>>>>> On 03/08/17 16:03, Phil Hobbs wrote: >>>>>>>>>>>>> On 08/01/2017 09:23 AM, Tom Gardner wrote: >>>>>>>>>>>>>> On 01/08/17 13:55, Phil Hobbs wrote: >>>>>>>>>>>>>>> On 07/30/2017 02:05 PM, Tom Gardner wrote: >>>>>>>>>>>>>>>> On 30/07/17 17:05, Phil Hobbs wrote: >>>>>>>>>>>>>>>>> Another thing is to concentrate the course work on stuff >>>>>>>>>>>>>>>>> that's hard >>>>>>>>>>>>>>>>> to pick up >>>>>>>>>>>>>>>>> on your own, i.e. math and the more mathematical parts of >>>>>>>>>>>>>>>>> engineering >>>>>>>>>>>>>>>>> (especially signals & systems and electrodynamics). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Agreed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Programming you can learn out of books without much >>>>>>>>>>>>>>>>> difficulty, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The evidence is that /isn't/ the case :( Read comp.risks, >>>>>>>>>>>>>>>> (which has an impressively high signal-to-noise ratio), or >>>>>>>>>>>>>>>> watch the news (which doesn't). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dunno. Nobody taught me how to program, and I've been doing it >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> I was a >>>>>>>>>>>>>>> teenager. I picked up good habits from reading books and other >>>>>>>>>>>>>>> people's code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, but it was easier back then: the tools, problems >>>>>>>>>>>>>> and solutions were, by and large, much simpler and more >>>>>>>>>>>>>> self-contained. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not so sure. Debuggers have improved out of all recognition, >>>>>>>>>>>>> with two >>>>>>>>>>>>> exceptions (gdb and Arduino, I'm looking at you). Plus there are >>>>>>>>>>>>> a whole >>>>>>>>>>>>> lot of >>>>>>>>>>>>> libraries available (for Python especially) so a determined >>>>>>>>>>>>> beginner >>>>>>>>>>>>> can get >>>>>>>>>>>>> something cool working (after a fashion) fairly fast. >>>>>>>>>>>> >>>>>>>>>>>> Yes, that's all true. The speed of getting something going >>>>>>>>>>>> is important for a beginner. But if the foundation is "sandy" >>>>>>>>>>>> then it can be necessary and difficult to get beginners >>>>>>>>>>>> (and managers) to appreciate the need to progress to tools >>>>>>>>>>>> with sounder foundations. >>>>>>>>>>>> >>>>>>>>>>>> The old time "sandy" tool was Basic. While Python is much >>>>>>>>>>>> better than Basic, it is still "sandy" when it comes to >>>>>>>>>>>> embedded real time applications. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Seems as though youngsters mostly start with Python and then >>>>>>>>>>>>> start in >>>>>>>>>>>>> on either >>>>>>>>>>>>> webdev or small SBCs using Arduino / AVR Studio / Raspbian or >>>>>>>>>>>>> (for >>>>>>>>>>>>> the >>>>>>>>>>>>> more >>>>>>>>>>>>> ambitious) something like BeagleBone or (a fave) LPCxpresso. >>>>>>>>>>>>> Most >>>>>>>>>>>>> of my >>>>>>>>>>>>> embedded work is pretty light-duty, so an M3 or M4 is good >>>>>>>>>>>>> medicine. >>>>>>>>>>>>> I'm much >>>>>>>>>>>>> better at electro-optics and analog/RF circuitry than at MCUs or >>>>>>>>>>>>> HDL, >>>>>>>>>>>>> so I do >>>>>>>>>>>>> only enough embedded things to get the whole instrument working. >>>>>>>>>>>>> Fancy >>>>>>>>>>>>> embedded >>>>>>>>>>>>> stuff I either leave to the experts, do in hardware, or hive off >>>>>>>>>>>>> to an >>>>>>>>>>>>> outboard >>>>>>>>>>>>> computer via USB serial, depending on the project. >>>>>>>>>>>> >>>>>>>>>>>> I wish more people took that attitude! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> It's certainly true that things get complicated fast, but they >>>>>>>>>>>>> did in >>>>>>>>>>>>> the old >>>>>>>>>>>>> days too. Of course the reasons are different: nowadays it's the >>>>>>>>>>>>> sheer >>>>>>>>>>>>> complexity of the silicon and the tools, whereas back then it was >>>>>>>>>>>>> burn-and-crash >>>>>>>>>>>>> development, flaky in-system emulators, and debuggers which (if >>>>>>>>>>>>> they even >>>>>>>>>>>>> existed) were almost as bad as Arduino. >>>>>>>>>>>> >>>>>>>>>>>> Agreed. The key difference is that with simple-but-unreliable >>>>>>>>>>>> tools it is possible to conceive that mortals can /understand/ >>>>>>>>>>>> the tools limitations, and know when/where the tool is failing. >>>>>>>>>>>> >>>>>>>>>>>> That simply doesn't happen with modern tools; even the world >>>>>>>>>>>> experts don't understand their complexity! Seriously. >>>>>>>>>>>> >>>>>>>>>>>> Consider C++. The *design committee* refused to believe C++ >>>>>>>>>>>> templates formed a Turing-complete language inside C++. >>>>>>>>>>>> They were forced to recant when shown a correct valid C++ >>>>>>>>>>>> program that never completed compilation - because, during >>>>>>>>>>>> compilation the compiler was (slowly) emitting the sequence >>>>>>>>>>>> of prime numbers! What chance have mere mortal developers >>>>>>>>>>>> got in the face of that complexity. >>>>>>>>>>> >>>>>>>>>>> I don't think that particular criticism is really fair - it >>>>>>>>>>> seems the >>>>>>>>>>> (rather simple) C preprocessor is also "turing complete" or at >>>>>>>>>>> least >>>>>>>>>>> close to it e.g,. >>>>>>>>>>> >>>>>>>>>>> https://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Or a C prime number generator that mostly uses the preprocessor >>>>>>>>>>> >>>>>>>>>>> https://www.cise.ufl.edu/~manuel/obfuscate/zsmall.hint >>>>>>>>>>> >>>>>>>>>>> At any rate "Compile-time processing" is a big thing now in modern >>>>>>>>>>> c++, >>>>>>>>>>> see e.g. >>>>>>>>>>> >>>>>>>>>>> Compile Time Maze Generator (and Solver) >>>>>>>>>>> https://www.youtube.com/watch?v=3SXML1-Ty5U >>>>>>>>>> >>>>>>>>>> Funny, compile time program execution is something Forth has done >>>>>>>>>> for >>>>>>>>>> decades. >>>>>>>>>> Why is this important in other languages now? >>>>>>>>> >>>>>>>>> It isn't important. >>>>>>>>> >>>>>>>>> What is important is that the (world-expert) design committee >>>>>>>>> didn't understand (and then refused to believe) the >>>>>>>>> implications of their proposal. >>>>>>>>> >>>>>>>>> That indicates the tool is so complex and baroque as to >>>>>>>>> be incomprehensible - and that is a very bad starting point. >>>>>>>> >>>>>>>> That's the point. Forth is one of the simplest development tools you >>>>>>>> will ever find. It also has some of the least constraints. The only >>>>>>>> people who think it is a bad idea are those who think RPN is a problem >>>>>>>> and object to other trivial issues. >>>>>>>> >>>>>>> >>>>>>> I used to program in RPN routinely, still use RPN calculators >>>>>>> exclusively, and don't like Forth. Worrying about the state of the >>>>>>> stack is something I much prefer to let the compiler deal with. It's >>>>>>> like C functions with ten positional parameters. >>>>>> >>>>>> If you are writing Forth code and passing 10 items into a definition, >>>>>> you have missed a *lot* on how to write Forth code. I can see why you >>>>>> are frustrated. >>>>>> >>>>> I'm not frustrated, partly because I haven't written anything in Forth >>>>> for over 30 years. ;) >>>>> >>>>> And I didn't say I was passing 10 parameters to a Forth word, either. >>>>> It's just that having to worry about the state of the stack is so 1975. >>>>> I wrote my last HP calculator program in the early '80s, and have no >>>>> burning desire to do that again either. >>>> >>>> You clearly mentioned 10 parameters, no? >>> >>> Yes, I was making the point that having to keep the state of the stack >>> in mind was error prone in the same way as passing that many parameters >>> in C. It's also annoying to document. In C, I don't have to say what >>> the values of the local varables are--it's clear from the code. >> >> Yes, it is error prone in the same way adding numbers is to a fourth >> grader. So use a calculator... but that's actually slower and can't be >> done if you don't have a calculator! That's the analogy I would use. >> Dealing with the stack is trivial if you make a small effort. > > Fortunately I don't need to fight that particular war, because there are > excellent C++ implementations for just about everything. > > "Back when I was young, we used to defrag hard disks by hand, with magnets." > >> >> Once I was in a discussion about dealing with the problems of debugging >> stack errors which usually are a mismatch between the number of parameters >> passed to/from and the number the definition is actually using. This is >> exactly the sort of problem a compiler can check, but typically is not >> done in Forth. Jeff Fox simply said something like, this proves the >> programmer can't count. I realized how simple the truth is. When >> considered in the context of how Forth programs are debugged this is >> simply not a problem worth dealing with by the compiler. If you learn >> more about Forth you will see that. >> >> The stack is not the problem. > > Fanbois always say that stuff. It's dumb. A C fanboi would probably make > the same crack about someone who got two parameters backwards in that > 10-parameter function we were talking about. "C does what you tell it, so > if you get it wrong, you're a poopyhead who doesn't have The Right Stuff > like us 733t h4x0r$." > > The complexity of software is bad enough without that sort of nonsense, from > whichever side. Time is money, so if you have a compiler that catches > errors for you, use it. Doing otherwise is pure fanboiism. (Nice coinage, > that.) ;) > >>>> I get that you don't fully understand Forth. When I said "The only >>>> people who think it is a bad idea are those who think RPN is a problem >>>> and object to other trivial issues" by other trivial issues I was >>>> referring to the use of the stack. >>> >>> Well, the fact that you think of Forth's main wart as a trivial issue is >>> probably why you like it. ;) >> >> Yes, I expect you would call this a wart too... >> >> https://k30.kn3.net/AB653626F.jpg >> >> I think Forth's biggest problem is people who can't see the beauty for the >> mark. > > Well, that poor girl unfortunately wasn't so pretty inside. The mark had > very little to do with it. > > Maybe if I had more alcohol it would help me see the inner beauty of Forth. > Dunno if it would last though. As the wise man said, "I came home at 2 with > a 10, and woke up at 10 with a 2." ;)You have a strange perspective on life. -- Rick C
Engineering degree for embedded systems
Started by ●July 27, 2017
Reply by ●August 7, 20172017-08-07
Reply by ●August 7, 20172017-08-07
On 08/07/2017 07:02 PM, rickman wrote:> Phil Hobbs wrote on 8/7/2017 6:56 PM: >> On 08/07/2017 06:35 PM, rickman wrote: >>> Phil Hobbs wrote on 8/7/2017 5:30 PM: >>>> On 08/07/2017 04:47 PM, rickman wrote: >>>>> Phil Hobbs wrote on 8/7/2017 3:27 PM: >>>>>> On 08/07/2017 03:18 PM, rickman wrote: >>>>>>> Phil Hobbs wrote on 8/7/2017 12:40 PM: >>>>>>>> On 08/06/2017 07:21 PM, rickman wrote: >>>>>>>>> Tom Gardner wrote on 8/6/2017 3:13 PM: >>>>>>>>>> On 06/08/17 17:51, rickman wrote: >>>>>>>>>>> John Devereux wrote on 8/6/2017 9:40 AM: >>>>>>>>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>>>>>>>> >>>>>>>>>>>>> On 03/08/17 16:03, Phil Hobbs wrote: >>>>>>>>>>>>>> On 08/01/2017 09:23 AM, Tom Gardner wrote: >>>>>>>>>>>>>>> On 01/08/17 13:55, Phil Hobbs wrote: >>>>>>>>>>>>>>>> On 07/30/2017 02:05 PM, Tom Gardner wrote: >>>>>>>>>>>>>>>>> On 30/07/17 17:05, Phil Hobbs wrote: >>>>>>>>>>>>>>>>>> Another thing is to concentrate the course work on stuff >>>>>>>>>>>>>>>>>> that's hard >>>>>>>>>>>>>>>>>> to pick up >>>>>>>>>>>>>>>>>> on your own, i.e. math and the more mathematical parts of >>>>>>>>>>>>>>>>>> engineering >>>>>>>>>>>>>>>>>> (especially signals & systems and electrodynamics). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Agreed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Programming you can learn out of books without much >>>>>>>>>>>>>>>>>> difficulty, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The evidence is that /isn't/ the case :( Read comp.risks, >>>>>>>>>>>>>>>>> (which has an impressively high signal-to-noise ratio), or >>>>>>>>>>>>>>>>> watch the news (which doesn't). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Dunno. Nobody taught me how to program, and I've been >>>>>>>>>>>>>>>> doing it >>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>> I was a >>>>>>>>>>>>>>>> teenager. I picked up good habits from reading books >>>>>>>>>>>>>>>> and other >>>>>>>>>>>>>>>> people's code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, but it was easier back then: the tools, problems >>>>>>>>>>>>>>> and solutions were, by and large, much simpler and more >>>>>>>>>>>>>>> self-contained. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not so sure. Debuggers have improved out of all >>>>>>>>>>>>>> recognition, >>>>>>>>>>>>>> with two >>>>>>>>>>>>>> exceptions (gdb and Arduino, I'm looking at you). Plus >>>>>>>>>>>>>> there are >>>>>>>>>>>>>> a whole >>>>>>>>>>>>>> lot of >>>>>>>>>>>>>> libraries available (for Python especially) so a determined >>>>>>>>>>>>>> beginner >>>>>>>>>>>>>> can get >>>>>>>>>>>>>> something cool working (after a fashion) fairly fast. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, that's all true. The speed of getting something going >>>>>>>>>>>>> is important for a beginner. But if the foundation is "sandy" >>>>>>>>>>>>> then it can be necessary and difficult to get beginners >>>>>>>>>>>>> (and managers) to appreciate the need to progress to tools >>>>>>>>>>>>> with sounder foundations. >>>>>>>>>>>>> >>>>>>>>>>>>> The old time "sandy" tool was Basic. While Python is much >>>>>>>>>>>>> better than Basic, it is still "sandy" when it comes to >>>>>>>>>>>>> embedded real time applications. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Seems as though youngsters mostly start with Python and then >>>>>>>>>>>>>> start in >>>>>>>>>>>>>> on either >>>>>>>>>>>>>> webdev or small SBCs using Arduino / AVR Studio / Raspbian or >>>>>>>>>>>>>> (for >>>>>>>>>>>>>> the >>>>>>>>>>>>>> more >>>>>>>>>>>>>> ambitious) something like BeagleBone or (a fave) LPCxpresso. >>>>>>>>>>>>>> Most >>>>>>>>>>>>>> of my >>>>>>>>>>>>>> embedded work is pretty light-duty, so an M3 or M4 is good >>>>>>>>>>>>>> medicine. >>>>>>>>>>>>>> I'm much >>>>>>>>>>>>>> better at electro-optics and analog/RF circuitry than at >>>>>>>>>>>>>> MCUs or >>>>>>>>>>>>>> HDL, >>>>>>>>>>>>>> so I do >>>>>>>>>>>>>> only enough embedded things to get the whole instrument >>>>>>>>>>>>>> working. >>>>>>>>>>>>>> Fancy >>>>>>>>>>>>>> embedded >>>>>>>>>>>>>> stuff I either leave to the experts, do in hardware, or >>>>>>>>>>>>>> hive off >>>>>>>>>>>>>> to an >>>>>>>>>>>>>> outboard >>>>>>>>>>>>>> computer via USB serial, depending on the project. >>>>>>>>>>>>> >>>>>>>>>>>>> I wish more people took that attitude! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> It's certainly true that things get complicated fast, but >>>>>>>>>>>>>> they >>>>>>>>>>>>>> did in >>>>>>>>>>>>>> the old >>>>>>>>>>>>>> days too. Of course the reasons are different: nowadays >>>>>>>>>>>>>> it's the >>>>>>>>>>>>>> sheer >>>>>>>>>>>>>> complexity of the silicon and the tools, whereas back then >>>>>>>>>>>>>> it was >>>>>>>>>>>>>> burn-and-crash >>>>>>>>>>>>>> development, flaky in-system emulators, and debuggers >>>>>>>>>>>>>> which (if >>>>>>>>>>>>>> they even >>>>>>>>>>>>>> existed) were almost as bad as Arduino. >>>>>>>>>>>>> >>>>>>>>>>>>> Agreed. The key difference is that with simple-but-unreliable >>>>>>>>>>>>> tools it is possible to conceive that mortals can /understand/ >>>>>>>>>>>>> the tools limitations, and know when/where the tool is >>>>>>>>>>>>> failing. >>>>>>>>>>>>> >>>>>>>>>>>>> That simply doesn't happen with modern tools; even the world >>>>>>>>>>>>> experts don't understand their complexity! Seriously. >>>>>>>>>>>>> >>>>>>>>>>>>> Consider C++. The *design committee* refused to believe C++ >>>>>>>>>>>>> templates formed a Turing-complete language inside C++. >>>>>>>>>>>>> They were forced to recant when shown a correct valid C++ >>>>>>>>>>>>> program that never completed compilation - because, during >>>>>>>>>>>>> compilation the compiler was (slowly) emitting the sequence >>>>>>>>>>>>> of prime numbers! What chance have mere mortal developers >>>>>>>>>>>>> got in the face of that complexity. >>>>>>>>>>>> >>>>>>>>>>>> I don't think that particular criticism is really fair - it >>>>>>>>>>>> seems the >>>>>>>>>>>> (rather simple) C preprocessor is also "turing complete" or at >>>>>>>>>>>> least >>>>>>>>>>>> close to it e.g,. >>>>>>>>>>>> >>>>>>>>>>>> https://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Or a C prime number generator that mostly uses the preprocessor >>>>>>>>>>>> >>>>>>>>>>>> https://www.cise.ufl.edu/~manuel/obfuscate/zsmall.hint >>>>>>>>>>>> >>>>>>>>>>>> At any rate "Compile-time processing" is a big thing now in >>>>>>>>>>>> modern >>>>>>>>>>>> c++, >>>>>>>>>>>> see e.g. >>>>>>>>>>>> >>>>>>>>>>>> Compile Time Maze Generator (and Solver) >>>>>>>>>>>> https://www.youtube.com/watch?v=3SXML1-Ty5U >>>>>>>>>>> >>>>>>>>>>> Funny, compile time program execution is something Forth has >>>>>>>>>>> done >>>>>>>>>>> for >>>>>>>>>>> decades. >>>>>>>>>>> Why is this important in other languages now? >>>>>>>>>> >>>>>>>>>> It isn't important. >>>>>>>>>> >>>>>>>>>> What is important is that the (world-expert) design committee >>>>>>>>>> didn't understand (and then refused to believe) the >>>>>>>>>> implications of their proposal. >>>>>>>>>> >>>>>>>>>> That indicates the tool is so complex and baroque as to >>>>>>>>>> be incomprehensible - and that is a very bad starting point. >>>>>>>>> >>>>>>>>> That's the point. Forth is one of the simplest development >>>>>>>>> tools you >>>>>>>>> will ever find. It also has some of the least constraints. >>>>>>>>> The only >>>>>>>>> people who think it is a bad idea are those who think RPN is a >>>>>>>>> problem >>>>>>>>> and object to other trivial issues. >>>>>>>>> >>>>>>>> >>>>>>>> I used to program in RPN routinely, still use RPN calculators >>>>>>>> exclusively, and don't like Forth. Worrying about the state of the >>>>>>>> stack is something I much prefer to let the compiler deal with. >>>>>>>> It's >>>>>>>> like C functions with ten positional parameters. >>>>>>> >>>>>>> If you are writing Forth code and passing 10 items into a >>>>>>> definition, >>>>>>> you have missed a *lot* on how to write Forth code. I can see >>>>>>> why you >>>>>>> are frustrated. >>>>>>> >>>>>> I'm not frustrated, partly because I haven't written anything in >>>>>> Forth >>>>>> for over 30 years. ;) >>>>>> >>>>>> And I didn't say I was passing 10 parameters to a Forth word, either. >>>>>> It's just that having to worry about the state of the stack is so >>>>>> 1975. >>>>>> I wrote my last HP calculator program in the early '80s, and have no >>>>>> burning desire to do that again either. >>>>> >>>>> You clearly mentioned 10 parameters, no? >>>> >>>> Yes, I was making the point that having to keep the state of the stack >>>> in mind was error prone in the same way as passing that many parameters >>>> in C. It's also annoying to document. In C, I don't have to say what >>>> the values of the local varables are--it's clear from the code. >>> >>> Yes, it is error prone in the same way adding numbers is to a fourth >>> grader. So use a calculator... but that's actually slower and can't be >>> done if you don't have a calculator! That's the analogy I would use. >>> Dealing with the stack is trivial if you make a small effort. >> >> Fortunately I don't need to fight that particular war, because there are >> excellent C++ implementations for just about everything. >> >> "Back when I was young, we used to defrag hard disks by hand, with >> magnets." >> >>> >>> Once I was in a discussion about dealing with the problems of debugging >>> stack errors which usually are a mismatch between the number of >>> parameters >>> passed to/from and the number the definition is actually using. This is >>> exactly the sort of problem a compiler can check, but typically is not >>> done in Forth. Jeff Fox simply said something like, this proves the >>> programmer can't count. I realized how simple the truth is. When >>> considered in the context of how Forth programs are debugged this is >>> simply not a problem worth dealing with by the compiler. If you learn >>> more about Forth you will see that. >>> >>> The stack is not the problem. >> >> Fanbois always say that stuff. It's dumb. A C fanboi would probably >> make >> the same crack about someone who got two parameters backwards in that >> 10-parameter function we were talking about. "C does what you tell >> it, so >> if you get it wrong, you're a poopyhead who doesn't have The Right Stuff >> like us 733t h4x0r$." >> >> The complexity of software is bad enough without that sort of >> nonsense, from >> whichever side. Time is money, so if you have a compiler that catches >> errors for you, use it. Doing otherwise is pure fanboiism. (Nice >> coinage, >> that.) ;) >> >>>>> I get that you don't fully understand Forth. When I said "The only >>>>> people who think it is a bad idea are those who think RPN is a problem >>>>> and object to other trivial issues" by other trivial issues I was >>>>> referring to the use of the stack. >>>> >>>> Well, the fact that you think of Forth's main wart as a trivial >>>> issue is >>>> probably why you like it. ;) >>> >>> Yes, I expect you would call this a wart too... >>> >>> https://k30.kn3.net/AB653626F.jpg >>> >>> I think Forth's biggest problem is people who can't see the beauty >>> for the >>> mark. >> >> Well, that poor girl unfortunately wasn't so pretty inside. The mark had >> very little to do with it. >> >> Maybe if I had more alcohol it would help me see the inner beauty of >> Forth. >> Dunno if it would last though. As the wise man said, "I came home at >> 2 with >> a 10, and woke up at 10 with a 2." ;) > > You have a strange perspective on life. >It's called "teasing", Rick. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●August 7, 20172017-08-07
Am 08.08.2017 um 01:08 schrieb Phil Hobbs:> On 08/07/2017 07:02 PM, rickman wrote: >> Phil Hobbs wrote on 8/7/2017 6:56 PM: >>> On 08/07/2017 06:35 PM, rickman wrote: >>>> Phil Hobbs wrote on 8/7/2017 5:30 PM: >>>>> On 08/07/2017 04:47 PM, rickman wrote: >>>>>> Phil Hobbs wrote on 8/7/2017 3:27 PM: >>>>>>> On 08/07/2017 03:18 PM, rickman wrote: >>>>>>>> Phil Hobbs wrote on 8/7/2017 12:40 PM: >>>>>>>>> On 08/06/2017 07:21 PM, rickman wrote: >>>>>>>>>> Tom Gardner wrote on 8/6/2017 3:13 PM: >>>>>>>>>>> On 06/08/17 17:51, rickman wrote: >>>>>>>>>>>> John Devereux wrote on 8/6/2017 9:40 AM: >>>>>>>>>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/08/17 16:03, Phil Hobbs wrote: >>>>>>>>>>>>>>> On 08/01/2017 09:23 AM, Tom Gardner wrote: >>>>>>>>>>>>>>>> On 01/08/17 13:55, Phil Hobbs wrote: >>>>>>>>>>>>>>>>> On 07/30/2017 02:05 PM, Tom Gardner wrote: >>>>>>>>>>>>>>>>>> On 30/07/17 17:05, Phil Hobbs wrote:[...]>> You have a strange perspective on life. >> > > It's called "teasing", Rick. ;)Guys, that makes about 300 lines of unmodified quote, for one line of reply. In other words, you've now dropped to effectively a 1:300 signal-to-noise ratio. So, could either one of you _please_ clip irrelevant quoted materiel from their replies, at least every once in a while? Pretty please?
Reply by ●August 7, 20172017-08-07
On 08/07/2017 07:30 PM, Hans-Bernhard Bröker wrote:> Am 08.08.2017 um 01:08 schrieb Phil Hobbs: >> On 08/07/2017 07:02 PM, rickman wrote: >>> Phil Hobbs wrote on 8/7/2017 6:56 PM: >>>> On 08/07/2017 06:35 PM, rickman wrote: >>>>> Phil Hobbs wrote on 8/7/2017 5:30 PM: >>>>>> On 08/07/2017 04:47 PM, rickman wrote: >>>>>>> Phil Hobbs wrote on 8/7/2017 3:27 PM: >>>>>>>> On 08/07/2017 03:18 PM, rickman wrote: >>>>>>>>> Phil Hobbs wrote on 8/7/2017 12:40 PM: >>>>>>>>>> On 08/06/2017 07:21 PM, rickman wrote: >>>>>>>>>>> Tom Gardner wrote on 8/6/2017 3:13 PM: >>>>>>>>>>>> On 06/08/17 17:51, rickman wrote: >>>>>>>>>>>>> John Devereux wrote on 8/6/2017 9:40 AM: >>>>>>>>>>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/08/17 16:03, Phil Hobbs wrote: >>>>>>>>>>>>>>>> On 08/01/2017 09:23 AM, Tom Gardner wrote: >>>>>>>>>>>>>>>>> On 01/08/17 13:55, Phil Hobbs wrote: >>>>>>>>>>>>>>>>>> On 07/30/2017 02:05 PM, Tom Gardner wrote: >>>>>>>>>>>>>>>>>>> On 30/07/17 17:05, Phil Hobbs wrote: > [...] >>> You have a strange perspective on life. >>> >> >> It's called "teasing", Rick. ;) > > Guys, that makes about 300 lines of unmodified quote, for one line of > reply. In other words, you've now dropped to effectively a 1:300 > signal-to-noise ratio. So, could either one of you _please_ clip > irrelevant quoted materiel from their replies, at least every once in a > while? Pretty please? > > >I think we're probably done--Rick likes Forth, and I don't, is about the size of it. Sorry about your 300-baud connection. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●August 7, 20172017-08-07
On Mon, 7 Aug 2017 19:02:15 -0400, rickman <gnuarm@gmail.com> wrote:>> Maybe if I had more alcohol it would help me see the inner beauty of Forth. >> Dunno if it would last though. As the wise man said, "I came home at 2 with >> a 10, and woke up at 10 with a 2." ;) > >You have a strange perspective on life.Could both of you learn to trim your posts? Then I might read enough of them to be interested. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441 web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●August 7, 20172017-08-07
Phil Hobbs wrote on 8/7/2017 7:08 PM:> On 08/07/2017 07:02 PM, rickman wrote: >> Phil Hobbs wrote on 8/7/2017 6:56 PM: >>> >>> Well, that poor girl unfortunately wasn't so pretty inside. The mark had >>> very little to do with it. >>> >>> Maybe if I had more alcohol it would help me see the inner beauty of Forth. >>> Dunno if it would last though. As the wise man said, "I came home at 2 with >>> a 10, and woke up at 10 with a 2." ;) >> >> You have a strange perspective on life. >> > > It's called "teasing", Rick. ;)I guess you hit a nerve calling Monroe ugly inside. I've always felt bad about the way many people end their lives. If people have broken limbs we hurry them to the hospital for treatment. When they have mental issues we tell them they should get some help and even if they do it often isn't of much value. -- Rick C
Reply by ●August 7, 20172017-08-07
On 08/07/2017 07:53 PM, rickman wrote:> Phil Hobbs wrote on 8/7/2017 7:08 PM: >> On 08/07/2017 07:02 PM, rickman wrote: >>> Phil Hobbs wrote on 8/7/2017 6:56 PM: >>>> >>>> Well, that poor girl unfortunately wasn't so pretty inside. The >>>> mark had >>>> very little to do with it. >>>> >>>> Maybe if I had more alcohol it would help me see the inner beauty of >>>> Forth. >>>> Dunno if it would last though. As the wise man said, "I came home >>>> at 2 with >>>> a 10, and woke up at 10 with a 2." ;) >>> >>> You have a strange perspective on life. >>> >> >> It's called "teasing", Rick. ;) > > I guess you hit a nerve calling Monroe ugly inside. I've always felt > bad about the way many people end their lives. If people have broken > limbs we hurry them to the hospital for treatment. When they have > mental issues we tell them they should get some help and even if they do > it often isn't of much value. >I wasn't blaming her for it, because I have no idea how she got to that place. Getting involved with Frank Sinatra and Jack Kennedy probably didn't help. For whatever reason, clearly she was very unhappy. But you're the one who brought in the downer, not I. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●August 7, 20172017-08-07
On 08/07/2017 07:49 PM, Stephen Pelc wrote:> On Mon, 7 Aug 2017 19:02:15 -0400, rickman <gnuarm@gmail.com> wrote: > >>> Maybe if I had more alcohol it would help me see the inner beauty of Forth. >>> Dunno if it would last though. As the wise man said, "I came home at 2 with >>> a 10, and woke up at 10 with a 2." ;) >> >> You have a strange perspective on life. > > Could both of you learn to trim your posts? Then I might read enough > of them to be interested. > > Stephen >Hit "end" when you load the post. Works in Thunderbird at least. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●August 7, 20172017-08-07
upsidedown@downunder.com wrote:> On Sun, 6 Aug 2017 09:53:55 -0500, Les Cargill > <lcargill99@comcast.com> wrote: > >>> I have often wondered what this IoT hype is all about. It seems to be >>> very similar to the PLC (Programmable Logic Controller) used for >>> decades. >> >> Similar. But PLCs are more pointed more at ladder logic for use in >> industrial settings. You generally cannot, for example, write a socket >> server that just does stuff on a PLC; you have to stay inside a dev >> framework that cushions it for you. > > In IEC-1131 (now IEC 61131-3) you can enter the program in the format > you are mostly familiar with, such as ladder logic or structured text > (ST), which is similar to Modula (and somewhat resembles Pascal) with > normal control structures. >It may resemble Pascal, but it's still limited in what it can do. It's good enough for ... 90% of things that will need to be done, but I live outside that 90% myself.> IEC-1131 has ben available for two decades > > >-- Les Cargill
Reply by ●August 8, 20172017-08-08
On 07/08/17 23:56, Phil Hobbs wrote:> Fanbois always say that stuff. It's dumb. A C fanboi would probably make the > same crack about someone who got two parameters backwards in that 10-parameter > function we were talking about. "C does what you tell it, so if you get it > wrong, you're a poopyhead who doesn't have The Right Stuff like us 733t h4x0r$."C/C++ fanbois do precisely that, usually quite vehemently :(> The complexity of software is bad enough without that sort of nonsense, from > whichever side. Time is money, so if you have a compiler that catches errors > for you, use it. Doing otherwise is pure fanboiism. (Nice coinage, that.) ;)Precisely.
