On 08/06/2017 05:35 AM, Tom Gardner wrote:> 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. > > Another example is that C/C++ is routinely used to develop > multi threaded code, e.g. using PThreads. That's despite > C/C++ specifically being unable to guarantee correct > operation on modern machines! Most developers are > blissfully unaware of (my *emphasis*): > > Threads Cannot be Implemented as a Library > Hans-J. Boehm > HP Laboratories Palo Alto > November 12, 2004 * > In many environments, multi-threaded code is written in a language that > was originally designed without thread support (e.g. C), to which a > library of threading primitives was subsequently added. There appears to > be a general understanding that this is not the right approach. We provide > specific arguments that a pure library approach, in which the compiler is > designed independently of threading issues, cannot guarantee correctness > of the resulting code. > We first review why the approach *almost* works, and then examine some > of the *surprising behavior* it may entail. We further illustrate that > there > are very simple cases in which a pure library-based approach seems > *incapable of expressing* an efficient parallel algorithm. > Our discussion takes place in the context of C with Pthreads, since it is > commonly used, reasonably well specified, and does not attempt to > ensure type-safety, which would entail even stronger constraints. The > issues we raise are not specific to that context. > http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdfInteresting read, thanks. I started writing multithreaded programs in 1992, using IBM C/Set 2 on OS/2 2.0. My only GUI programs were on OS/2. My biggest effort to date is a clusterized 3-D EM simulator, which is multithreaded, multicore, multi-box, on a heterogeneous bunch of Linux and Windows boxes. (I haven't tested the Windows version in awhile, so it's probably broken, but it used to work.) It's written in C++ using the C-with-classes-and-a-few-templates OOP style, which is a really good match for simulation and instrument control code. The optimizer is a big Rexx script that functions a lot like a math program. A pal of mine wrote an EM simulator that plugs into Matlab, but his isn't clusterized so I couldn't use it. My stuff is all pthreads, because std::thread didn't exist at the time, but it does now, so presumably Boehm's input has been taken into account.> > >> I still have nightmares about the horribly buggy PIC C17 compiler for the >> PIC17C452A, circa 1999. I was using it in an interesting very low >> cost infrared >> imager <http://electrooptical.net#footprints>. I had an ICE, which >> was a help, >> but I spent more time finding bug workarounds than coding. > > There are always crap instantiations of tools, but they > can be avoided. I'm more concerned about tools where the > specification prevents good and safe tools. > > >> Eventually when the schedule permitted I ported the code to HiTech C, >> which was >> a vast improvement. Microchip bought HiTech soon thereafter, and PIC >> C died a >> well deserved but belated death. >> >> My son and I are doing a consulting project together--it's an M4-based >> concentrator unit for up to 6 UV/visible/near IR/thermal IR sensors >> for a fire >> prevention company. He just got the SPI interrupt code working down >> on the >> metal a couple of minutes ago. It's fun when your family understands >> what you >> do. :) > > Lucky you -- I think! I've never been convinced of the > wisdom of mixing work and home life, and family businesses > seem to be the source material for reality television :)Well, being Christians helps, as does being fond of each other. He'll probably want to start running the business after he finishes grad school--I want to be like Zelazny's character Dworkin, who spends his time casually altering the structure of reality in his dungeon. ;) 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
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/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. Cheers Phil "existence proof" 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/06/2017 10:15 AM, upsidedown@downunder.com wrote:> > Now that there is a lot of multicore processors, this is a really > serious issue. > > > But again, should multitasking/mutithreading be implemented in a > multitasking OS or in a programming language is a very important > question. > > To the OP, what you are going to need in the next 3 to 10 years is > hard to predict. >The old Linux threads library used heavyweight processes to mimic lightweight threads. That's a mess. Pthreads is much nicer. 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 07/08/17 17:36, Phil Hobbs wrote:> On 08/06/2017 05:35 AM, Tom Gardner wrote: >> 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.References, containing the red-flag words "discovered" and "accident", plus some offending code: "...TMP is something of an accident; it was discovered during the process of standardizing the C++..." https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP http://aszt.inf.elte.hu/~gsd/halado_cpp/ch06s04.html#Static-metaprogramming>> Another example is that C/C++ is routinely used to develop >> multi threaded code, e.g. using PThreads. That's despite >> C/C++ specifically being unable to guarantee correct >> operation on modern machines! Most developers are >> blissfully unaware of (my *emphasis*): >> >> Threads Cannot be Implemented as a Library >> Hans-J. Boehm >> HP Laboratories Palo Alto >> November 12, 2004 * >> In many environments, multi-threaded code is written in a language that >> was originally designed without thread support (e.g. C), to which a >> library of threading primitives was subsequently added. There appears to >> be a general understanding that this is not the right approach. We provide >> specific arguments that a pure library approach, in which the compiler is >> designed independently of threading issues, cannot guarantee correctness >> of the resulting code. >> We first review why the approach *almost* works, and then examine some >> of the *surprising behavior* it may entail. We further illustrate that >> there >> are very simple cases in which a pure library-based approach seems >> *incapable of expressing* an efficient parallel algorithm. >> Our discussion takes place in the context of C with Pthreads, since it is >> commonly used, reasonably well specified, and does not attempt to >> ensure type-safety, which would entail even stronger constraints. The >> issues we raise are not specific to that context. >> http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf > > Interesting read, thanks.It is, isn't it.> I started writing multithreaded programs in > 1992, using IBM C/Set 2 on OS/2 2.0. My only GUI programs were on OS/2. > > My biggest effort to date is a clusterized 3-D EM simulator, which is > multithreaded, multicore, multi-box, on a heterogeneous bunch of Linux > and Windows boxes. (I haven't tested the Windows version in awhile, so > it's probably broken, but it used to work.) It's written in C++ using > the C-with-classes-and-a-few-templates OOP style, which is a really good > match for simulation and instrument control code. The optimizer is a > big Rexx script that functions a lot like a math program. A pal of mine > wrote an EM simulator that plugs into Matlab, but his isn't clusterized > so I couldn't use it. > > My stuff is all pthreads, because std::thread didn't exist at the time, > but it does now, so presumably Boehm's input has been taken into account.I'm told C/C++12 /finally/ has a memory model, so perhaps that will (a few decades too late) ameliorate the problem. We'll see, but I'm not holding my breath. > Well, being Christians helps, as does being fond of each other. Depends on the Christian :( My maternal grandmother and my ex's grandmother were avowedly Christian and pretty horrible specimens to boot. My grandmother used to write poison-pen letters, my ex's used to viciously play favourites. So, the "fond of each other" didn't come into play :( > He'll > probably want to start running the business after he finishes grad > school--I want to be like Zelazny's character Dworkin, who spends his > time casually altering the structure of reality in his dungeon. ;) :) I'll content myself with defining the structure of reality to be what I want it to be. (Just like many denizens of this group :) And then I'll find a way of going out with my boots on.
Reply by ●August 7, 20172017-08-07
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. -- Rick C
Reply by ●August 7, 20172017-08-07
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. 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
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? 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. -- Rick C
Reply by ●August 7, 20172017-08-07
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.> > 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. ;) 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
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. 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.>> 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. -- Rick C
Reply by ●August 7, 20172017-08-07
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." ;) 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
