On 6/20/2017 3:07 PM, Ed Prochak wrote:>>> have a great day >> >> Too late -- 119F today. > > Wow, it cooled off a bit here, back to the 70's. > Well try to stay cool.Our highs aren't expected to fall below 110 for at least a week. Night-time lows are 80+. Hopefully this will pass before Monsoon starts (in a few weeks)
Hi Ed, On 6/19/2017 6:48 AM, Ed Prochak wrote:> On Wednesday, June 14, 2017 at 2:58:42 AM UTC-4, Don Y wrote:>> The "real machine" fixes values to all those constants (K) in the >> O()-evaluation. And, can muck with the decision making process >> in certain sets of constraints. > > Exactly right! > > The BIG-O notation too often is depicted as O() when it is > really O(n) where n is the input set size. What get lost sometimes > is people treat O(n) as a comparison at a given set size. and that > is the error. (I don't think you fall into this error, Don.)It's helpful for evaluating the *relative* costs of different algorithms where you assign some abstract cost to particular classes of operations. It is particularly effective in a classroom setting -- where newbies haven't yet learned to THINK in terms of the costs of their "solutions" (algorithms). For example, one way to convert a binary number to an equivalent decimal value is to count the binary value down towards zero (i.e., using a "binary subtract 1") while simultaneously counting the decimal value *up* (i.e., using a "decimal add 1"). Clearly, the algorithm executes in O(n) time (n being the magnitude of the number being converted). Other algorithms might perform an operation (or set of operations) for each bit of the argument. So, they operate in O(logs(n)) time (i.e., a 32b value takes twice as long to process as a 16b value). This is great for a "schoolbook" understanding of the algorithms and an idea of how the "work" required varies with the input value and/or range of supported values (i.e., an algorithm may work well with a certain set of test values -- yet STUN the developer when applied to *other* values). But, when it comes to deciding which approach to use in a particular application, you need to know what the "typical values" (and worst case) to be processed are likely to be. And, what the costs of the operations required in each case (the various 'k' that have been elided from the discussion). If you're converting small numbers, the cost of a pair of counters can be much less than the cost of a "machine" that knows how to process a bit at a time. So, while (in general) the counter approach looks incredibly naive (stupid), it can, in fact be the best approach in a particular set of conditions!> BIG-O analysis allows you do do some testing at a data set size n1 > and then make a rough estimate of the run time for n2 > n1. > this can be done for the hardware and processor instruction set. > Its purpose is to avoid the naive estimate: > "I ran this on a data set of 100 and took 0.5 microseconds, > so on the production run of 1,000,000 it should only less > than a minute (50 seconds)."If O(n), you'd expect it to be done in 5ms (0.5us*1,000,000/100). By thinking in terms of HOW the algorithm experiences its costs, you can better evaluate the types of operations (implementations) you'd like to favor/avoid. If you know that you are intending to deploy on a target that has a particular set of characteristics for its operations, you might opt for a different algorithm to avoid the more expensive operators and exploit the cheaper ones. Many years ago, I wrote a little piece of code to exhaustively probe a state machine (with no buried state) to build a state transition table empirically with only indirect observation of the "next state" logic (i.e., by looking at the "current state" and applying various input vectors and then tabulating the resulting next state). [This is actually a delightfully interesting problem to solve! Hint: once you've applied an input vector and clocked the machine, you've accumulated knowledge of how that state handles that input vector -- but, you're no longer in that original "current state". And, you still have other input vectors to evaluate for it!] How do you evaluate the efficacy of the algorithm that "walks" the FSM? How do you determine how long it will take to map a FSM of a given maximum complexity (measured by number of states and input vector size)? All you know, /a priori/ is the time that it takes to apply a set of inputs to the machine and observe that *one* state transition... [Exercise left for the reader.]> Hopefully, folks here are not that naive to depend on just O(n). > Your point is very important and worth repeating: > the analysis of algorithms can be more precise when it can > take into account the features of the implementation environment. > (I hope I phrased that close to what you meant.)The more interesting cases are O(1), O(n^2), etc. And, how to downgrade the cost of an algorithm that *appears*, on its surface, to be of a higher order than it actually needs to be.> have a great dayToo late -- 119F today.
On Wednesday, June 14, 2017 at 2:58:42 AM UTC-4, Don Y wrote:> On 6/13/2017 10:26 PM, Reinhardt Behm wrote: > > AT Wednesday 14 June 2017 12:57, Don Y wrote: > > > >> Correct. But, it's only "order of" assessments. I.e., is this > >> a constant time algorithm? Linear time? Quadratic? Exponential? > >> etc. > >> > >> There's a lot of handwaving in O() evaluations of algorithms. > >> What's the relative cost of multiplication vs. addition operators? > >> Division? etc. > > > > I found many of such evaluation grossly wrong. We had some iterative > > solutions praised as taking much fewer iterative steps than others. But > > nobody took into account that each step was much more complicated and took > > much more CPU time, than one of the solutions that took more steps. > > And quite often the simpler solution worked for the more general case > > whereas the "better" worked only under limited conditions. > > That doesn't invalidate the *idea* of modeling algorithms using some > set of "abstract operation costs". > > But, it points to the fact that the real world eventually intervenes; > and, its a "bitch". :> Approximations have to eventually give way to > REAL data! >[]> > The "real machine" fixes values to all those constants (K) in the > O()-evaluation. And, can muck with the decision making process > in certain sets of constraints.Exactly right! The BIG-O notation too often is depicted as O() when it is really O(n) where n is the input set size. What get lost sometimes is people treat O(n) as a comparison at a given set size. and that is the error. (I don't think you fall into this error, Don.) BIG-O analysis allows you do do some testing at a data set size n1 and then make a rough estimate of the run time for n2 > n1. this can be done for the hardware and processor instruction set. Its purpose is to avoid the naive estimate: "I ran this on a data set of 100 and took 0.5 microseconds, so on the production run of 1,000,000 it should only less than a minute (50 seconds)." Hopefully, folks here are not that naive to depend on just O(n). Your point is very important and worth repeating: the analysis of algorithms can be more precise when it can take into account the features of the implementation environment. (I hope I phrased that close to what you meant.) have a great day ed
On 6/13/2017 10:26 PM, Reinhardt Behm wrote:> AT Wednesday 14 June 2017 12:57, Don Y wrote: > >> Correct. But, it's only "order of" assessments. I.e., is this >> a constant time algorithm? Linear time? Quadratic? Exponential? >> etc. >> >> There's a lot of handwaving in O() evaluations of algorithms. >> What's the relative cost of multiplication vs. addition operators? >> Division? etc. > > I found many of such evaluation grossly wrong. We had some iterative > solutions praised as taking much fewer iterative steps than others. But > nobody took into account that each step was much more complicated and took > much more CPU time, than one of the solutions that took more steps. > And quite often the simpler solution worked for the more general case > whereas the "better" worked only under limited conditions.That doesn't invalidate the *idea* of modeling algorithms using some set of "abstract operation costs". But, it points to the fact that the real world eventually intervenes; and, its a "bitch". :> Approximations have to eventually give way to REAL data! For example, I rely heavily on the (paged) MMU in the way my RTOS handles "memory objects". I'll map a page into another processes address space instead of bcopy()-ing the contents of the page across the protection boundary. A win, right? "Constant time" operation (instead of a linear time operation governed by the amount of data to be bcopied). But, there's a boat-load of overhead in remapping pages -- including a trap to the OS to actually do the work. So, what you'd *think* to be a more efficient way of handling the data actually is *less* efficient. (Unless, of course, you can escalate the amount of data involved to help absorb the cost of that overhead) OTOH, there are often "other concerns" that can bias an implementation in favor of (what appears to be) a less efficient solution. E.g., as I work in a true multiprocessing environment, I want to ensure a caller can't muck with an argument for which it has provided a "reference" to the called function WHILE the called function is (potentially) using it. So, the MMU lets me mark the page as immutable (even though it *should* be mutable) UNTIL the called function has completed. [This allows the caller to *access* the contents of the page concurrently with the called function -- but, lets the OS intervene if the caller tries to alter the contents prematurely. The "write lock" has value that couldn't be implemented with the bcopy() approach -- think of large objects -- and is "cheaper" to implement once you've already decided to take the hit for manipulating the page tables] The "real machine" fixes values to all those constants (K) in the O()-evaluation. And, can muck with the decision making process in certain sets of constraints.
AT Wednesday 14 June 2017 12:57, Don Y wrote:> Correct. But, it's only "order of" assessments. I.e., is this > a constant time algorithm? Linear time? Quadratic? Exponential? > etc. > > There's a lot of handwaving in O() evaluations of algorithms. > What's the relative cost of multiplication vs. addition operators? > Division? etc.I found many of such evaluation grossly wrong. We had some iterative solutions praised as taking much fewer iterative steps than others. But nobody took into account that each step was much more complicated and took much more CPU time, than one of the solutions that took more steps. And quite often the simpler solution worked for the more general case whereas the "better" worked only under limited conditions. -- Reinhardt
Hi Ed, On 6/13/2017 2:24 PM, Ed Prochak wrote:>>>> But you can't examine algorithms and characterize their behaviors, >>>> costs, etc. without being able to reify them. >>> >>> To a 1st approximation, you can. E.g., given just an equation, you >>> can count the arithmetic operations and approximate the number of >>> operand reads and result writes. >> >> Yes, but only for evaluating *relative* costs/merits of algorithms. >> It assumes you can "value" the costs/performance of the different >> operators in some "intuitive" manner. > > I'm jumping in late here so forgive me if you covered this. > > Algorithmic analysis is generally order of magnitude (the familiar > Big O notation) and independent of hardware implementation.Correct. But, it's only "order of" assessments. I.e., is this a constant time algorithm? Linear time? Quadratic? Exponential? etc. There's a lot of handwaving in O() evaluations of algorithms. What's the relative cost of multiplication vs. addition operators? Division? etc. With O() you're just trying to evaluate the relative merits of one approach over another in gross terms.>> This doesn't always hold. E.g., a more traditionally costly operation >> might be "native" while the *expected* traditional operation has to be >> approximated or emulated. > > I'm not quite sure what you are saying here, Don. > What's the difference between "native" and *expected*? > > Is it that you *expected* the system to have a floating point > multiply, but the "native" hardware does not so it is emulated?Or, exactly the reverse: that it had the more complex operator but not the "simpler" (expected) one. We *expect* integer operations to be cheap. We expect logical operators to be <= additive operators <= multiplication, etc. But, that's not always the case. E.g., having a "multiply-and-accumulate" instruction (common in DSP) can eliminate the need for an "add" opcode (i.e., multiplication is as "expensive" as addition). I've designed (specialty) CPU's that had hardware to support direct (native) implementation of DDA's. But, trying to perform a simple "logical" operation would require a page of code (because there were no logical operators so they'd have to be emulated). Atari (?) made a processor that could only draw arcs -- never straight lines (despite the fact that line segments SHOULD be easier). Limbo initially took the approach of having five "base" data types: - byte - int ("long") - big ("long long") - real ("double") - string (These are supported directly by the underlying VM) No pointer types. No shorts, short-reals (floats), etc. If you want something beyond an integer, you go balls out and get a double! The haughtiness of always relying on "gold" instead of "lead" proved impractical, in he real world. So, there are now things like native support for Q-format -- and beyond (i.e., you can effectively declare the value of the rightmost bit AND a maximum value to representable by that particular "fixed" type): hourlyassessment: type fixed(0.1, 40.0); timespentworking, timeinmeetings: hourlyassessment; LETTER: con 11.0; DPI: con 400; inches: type fixed(1/DPI, LETTER); topmargin: inches; Likewise, the later inclusion of REFERENCES to functions as a compromise in the "no pointers" mentality. (you don't *need* references as you can map functions to integer identifiers and then use big "case" statements (the equivalent of "switch") to invoke one of N functions as indicated by that identifier; just far less efficiently (enough so that you'd make a change to the LANGUAGE to support it?) While not strictly on-topic, it's vindication that "rough" approximations of the cost of operators can often be far enough astray that you need to refine the costs "in practice". I.e., if "multiplication" could just be considered to have *a* cost, then there's be no need for all those numerical data types. So... you can use O-notation to compare the relative costs of different algorithms on SOME SET of preconceived available operators and data types. You have some implicit preconceived notion of what the "real" machine is like. But, mapping this to a real implementation is fraught with opportunities to come to the wrong conclusions (e.g., if you think arcs are expensive as being built from multiple chords, you'll favor algorithms that minimize the number of chords used)> first: >>>> You can't just magically invent an abstract language that supports: >>>> solve_homework_problem(identifier) >>> > second: >>> You can invent it ... you just [currently] can't implement it. >> > third: >> Sure you can! You just have to find someone sufficiently motivated to >> apply their meatware to the problem! There's nothing specifying the >> *time* that the implementation needs to take to perform the operation! > > I'm confused here too, Don, unless the quotation levels are off. > Is it you that said the first and third comments above?Yes.> They seem contradictory. (or else you are referencing > different contexts?)Read them again; the subject changes: 1. You can't invent that magical language that allows you to solve homework assignments with a single operator <grin> 2. You can INVENT it, but can't IMPLEMENT it (i.e., its just a conceptual language that doesn't run on any REAL machine) 3. You *can* IMPLEMENT it; find a flunky to do the work FOR you! (tongue firmly in cheek)
On Tuesday, June 13, 2017 at 1:42:17 AM UTC-4, Don Y wrote:> On 6/12/2017 8:27 PM, George Neuner wrote: > > On Sun, 11 Jun 2017 00:39:41 -0700, Don Y > > <blockedofcourse@foo.invalid> wrote:[]> > >> But you can't examine algorithms and characterize their behaviors, > >> costs, etc. without being able to reify them. > > > > To a 1st approximation, you can. E.g., given just an equation, you > > can count the arithmetic operations and approximate the number of > > operand reads and result writes. > > Yes, but only for evaluating *relative* costs/merits of algorithms. > It assumes you can "value" the costs/performance of the different > operators in some "intuitive" manner.I'm jumping in late here so forgive me if you covered this. Algorithmic analysis is generally order of magnitude (the familiar Big O notation) and independent of hardware implementation.> > This doesn't always hold. E.g., a more traditionally costly operation > might be "native" while the *expected* traditional operation has to be > approximated or emulated.I'm not quite sure what you are saying here, Don. What's the difference between "native" and *expected*? Is it that you *expected* the system to have a floating point multiply, but the "native" hardware does not so it is emulated? [] first:> >> You can't just magically invent an abstract language that supports: > >> solve_homework_problem(identifier) > >second:> > You can invent it ... you just [currently] can't implement it. >third:> Sure you can! You just have to find someone sufficiently motivated to > apply their meatware to the problem! There's nothing specifying the > *time* that the implementation needs to take to perform the operation!I'm confused here too, Don, unless the quotation levels are off. Is it you that said the first and third comments above? They seem contradictory. (or else you are referencing different contexts?) [lots of other interesting stuff deleted] ed
On 6/12/2017 8:27 PM, George Neuner wrote:> On Sun, 11 Jun 2017 00:39:41 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> On 6/10/2017 6:01 PM, George Neuner wrote: >>> On Fri, 9 Jun 2017 22:50:31 -0700, Don Y <blockedofcourse@foo.invalid> >>> wrote: > >> [I was recently musing over the number of SOIC8 devices that could fit >> on the surface of a sphere having a radius equal to the average distance >> of Pluto from the Sun (idea came from a novel I was reading). And, how >> much that SOIC8 collection would *weigh*...] > > Reading about Dyson spheres are we? So how many trillion-trillion > devices would it take?Matrioshka Brain -- "concentric" Dyson spheres each powered by the waste heat of the innermore spheres. I didn't do the math as I couldn't figure out what a good representative weight for a "wired" SOIC SoC might be...>> But you can't examine algorithms and characterize their behaviors, >> costs, etc. without being able to reify them. > > To a 1st approximation, you can. E.g., given just an equation, you > can count the arithmetic operations and approximate the number of > operand reads and result writes.Yes, but only for evaluating *relative* costs/merits of algorithms. It assumes you can "value" the costs/performance of the different operators in some "intuitive" manner. This doesn't always hold. E.g., a more traditionally costly operation might be "native" while the *expected* traditional operation has to be approximated or emulated.> Certain analyses are very sensitive to the language being considered. > E.g., you'll get different results from analyzing an algorithm > expressed in C vs the same algorithm expressed in assembler because > the assembler version exposes low level minutia that is hidden by the > C version. > >> You can't just magically invent an abstract language that supports: >> solve_homework_problem(identifier) > > You can invent it ... you just [currently] can't implement it.Sure you can! You just have to find someone sufficiently motivated to apply their meatware to the problem! There's nothing specifying the *time* that the implementation needs to take to perform the operation!> And you probably even can get a patent on it since the USPTO no longer > requires working prototypes. > >>>> I just can't imagine how you could explain "programming" a machine to a >>>> person without that person first understanding how the machine works. >>> >>> Take a browse through some classics: >>> >>> - Abelson, Sussman & Sussman, "Structure and Interpretation of >>> Computer Programs" aka SICP >>> >>> - Friedman, Wand & Haynes, "Essentials of Programming Languages" >>> aka EOPL >> >> All written long after I'd graduated. :> > > SICP and EOPL both were being written during the time I was in grad > school. I had some courses with Mitch Wand and I'm sure I was used as > a guinea pig for EOPL.Having not seen SICP, its possible the notes for GS's class found their way into it -- or, at least, *shaped* it.> I acquired them later because they subsequently became famous as > foundation material for legions of CS students. > >> Most (all?) of my college >> CS courses didn't have "bound textbooks". Instead, we had collections >> of handouts coupled with notes that formed our "texts". In some cases, >> the handouts were "bound" (e.g., a cheap "perfect binding" paperback) >> for convenience as the instructors were writing the texts *from* >> their teachings. > > I'm not *that* far behind you. Many of my courses did have books, but > quite a few of those books were early (1st or 2nd) editions.Its not just *when* you got your education but what the folks teaching opted to use as their "teaching materials". Most of my "CS" professors obviously considered themselves "budding authors" as each seemed unable to find a suitable text from which to teach and opted, instead, to write their own. OTOH, all my *other* classes (including the "EE" ones) had *real* textbooks.> I have a 1st edition on denotational semantics that is pre-press and > contains inserts of hand drawn illustrations. > >> Sussman taught one of my favorite courses and I'm chagrined that >> all I have to show for it are the handouts and my notes -- it would >> have been nicer to have a lengthier text that I could explore at >> my leisure (esp after the fact). > > I met once Gerry Sussman at a seminar. Never had the opportunity to > take one of his classes.Unfortunately, I never realized the sorts of folks I was surrounded by, at the time. It was "just school", in my mind.>> I actually considered altering the expression syntax to deliberately >> render parens unnecessary (and illegal). I.e., if an expression >> can have two different meanings with/without parens, then ONLY the >> meaning without parens would be supported. > > Indentation sensitive syntax (I-expressions) is a recurring idea to > rid the world of parentheses. > > Given the popularity of Python, iexprs may eventually find a future. > OTOH, many people - me included - are philosophically opposed to the > idea of significant whitespace. > > If you want syntax visualization, use a structure editor.Still doesn't work without *vision*!>> But, this added lots of superfluous statements just to meet that >> goal *and* quickly overloads STM as you try to keep track of >> which "component statements" you've already encountered: >> area = (width_feet+(width_inches/12))*(length_feet+(length_inches/12) >> becomes: >> width = width_feet + width_inches/12 >> length = length_feet + length_inches/12 >> area = length * width >> [Imagine you were, instead, computing the *perimeter* of a 6 walled room!] > > ??? For what definition of "STM"? > > Transactional memory - if that's what you mean - shouldn't require > refactoring code in that way.How many nested levels of parens can you keep track of if I'm dictating the code to you over the phone and your eyes are closed? Will I be disciplined enough to remember to alert you to the presence of every punctuation mark (e.g., paren)? Will you be agile enough to notice when I miss one?>>> ... identifying required >>> functionality, designing program logic, evaluating and choosing >>> algorithms, etc. ... all may be *guided* in situ by specific knowledge >>> of the target machine, but they are skills which are independent of >>> it. >> >> But I see programming (C.A.E) as having moved far beyond the sorts of >> algorithms you would run on a desktop, mainframe, etc. Its no longer >> just about this operator in combination with these arguments yields >> this result. > > As long as you don't dismiss desktops and servers, etc. > > [Mainframes and minis as distinct concepts are mostly passe. Super > and cluster computers, however, are very important]."Mainframe" is a colloquial overloading to reference "big machines" that have their own dedicated homes. The data center servicing your bank is a mainframe -- despite the fact that it might be built of hundreds of blade servers, etc. "Desktop" is the sort of "appliance" that a normal user relates to when you say "computer". He *won't* think of his phone even though he knows its one. He certainly won't think of his microwave oven, furnace, doorbell, etc.> Despite the current IoT and BYO device fads, devices are not all there > are. Judging from some in the computer press, you'd think the legions > of office workers in the world would need nothing more than iPads and > Kinkos. That isn't even close to being true. > >> I.e., there are just too many details of successful program deployment >> that don't work when you get away from the rich and tame "classroom >> environment". This is especially true as we move towards scenarios >> where things "talk to" each other, more (for folks who aren't prepared >> to deal with a malloc/printf *failing*, how do they address "network >> programming"? Or, RPC/RMI? etc.) > > Again: CS is about computation and language theory, not about systems > engineering. > > I got into it while ago with a VC guy I met at a party. He wouldn't > (let companies he was backing) hire anyone more than 5 years out of > school because he thought their skills were out of date. > > I told him I would hesitate to hire anyone *less* than 5 years out of > school because most new graduates don't have any skills and need time > to acquire them. I also said something about how the average new CS > grad would struggle to implement a way out of a wet paper bag.I think it depends on the "pedigree". When I was hired at my first job, the boss said, outright, "I don't expect you to be productive, today. I hired you for 'tomorrow'; if I wanted someone to be productive today, I'd have hired from the other side of the river -- and planned on mothballing him next year!" From the few folks that I interact with, I have learned to see his point. Most don't know anything about the "history" of their technology or the gyrations as it "experimented" with different things. They see "The Cloud" as something new and exciting -- and don't see the parallels to "time sharing", centralized computing, etc. that the industry routinely bounces through. Or, think it amazingly clever to turn a PC into an X terminal ("Um, would you like to see some REAL ones?? You know, the idea that you're PILFERING?") Employers/clients want to know if you've done THIS before (amusing if its a cutting edge project -- that NO ONE has done before!) as if that somehow makes you MORE qualified to solve their problem(s). I guess they don't expect people to LEARN...> Obviously there is a component of this that is industry specific, but > few (if any) industries change so fast that skills learned 5 years ago > are useless today. For me, it was a scary look into the (lack of) > mind of modern business.A lady friend once told me "Management is easy! No one wants to take risks or make decisions so, if YOU will, they'll gladly hide behind you!" /Pro bono/ day tomorrow. Last sub 100F day for at least 10 days (103 on Wed climbing linearly to 115 next Mon with a LOW of 82F) so I'm hoping to get my *ss out of here bright and early in the morning! <frown> 45 and raining, you say... :>
On Sun, 11 Jun 2017 00:39:41 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 6/10/2017 6:01 PM, George Neuner wrote: >> On Fri, 9 Jun 2017 22:50:31 -0700, Don Y <blockedofcourse@foo.invalid> >> wrote:>[I was recently musing over the number of SOIC8 devices that could fit >on the surface of a sphere having a radius equal to the average distance >of Pluto from the Sun (idea came from a novel I was reading). And, how >much that SOIC8 collection would *weigh*...]Reading about Dyson spheres are we? So how many trillion-trillion devices would it take?>But you can't examine algorithms and characterize their behaviors, >costs, etc. without being able to reify them.To a 1st approximation, you can. E.g., given just an equation, you can count the arithmetic operations and approximate the number of operand reads and result writes. Certain analyses are very sensitive to the language being considered. E.g., you'll get different results from analyzing an algorithm expressed in C vs the same algorithm expressed in assembler because the assembler version exposes low level minutia that is hidden by the C version.>You can't just magically invent an abstract language that supports: > solve_homework_problem(identifier)You can invent it ... you just [currently] can't implement it. And you probably even can get a patent on it since the USPTO no longer requires working prototypes.>>> I just can't imagine how you could explain "programming" a machine to a >>> person without that person first understanding how the machine works. >> >> Take a browse through some classics: >> >> - Abelson, Sussman & Sussman, "Structure and Interpretation of >> Computer Programs" aka SICP >> >> - Friedman, Wand & Haynes, "Essentials of Programming Languages" >> aka EOPL > >All written long after I'd graduated. :>SICP and EOPL both were being written during the time I was in grad school. I had some courses with Mitch Wand and I'm sure I was used as a guinea pig for EOPL. I acquired them later because they subsequently became famous as foundation material for legions of CS students.>Most (all?) of my college >CS courses didn't have "bound textbooks". Instead, we had collections >of handouts coupled with notes that formed our "texts". In some cases, >the handouts were "bound" (e.g., a cheap "perfect binding" paperback) >for convenience as the instructors were writing the texts *from* >their teachings.I'm not *that* far behind you. Many of my courses did have books, but quite a few of those books were early (1st or 2nd) editions. I have a 1st edition on denotational semantics that is pre-press and contains inserts of hand drawn illustrations.>Sussman taught one of my favorite courses and I'm chagrined that >all I have to show for it are the handouts and my notes -- it would >have been nicer to have a lengthier text that I could explore at >my leisure (esp after the fact).I met once Gerry Sussman at a seminar. Never had the opportunity to take one of his classes.>The books that I have on the subject predate my time in college >(I attended classes at a local colleges at night and on weekends >while I was in Jr High and High School). Many of the terms used >in them have long since gone out of style (e.g., DASD, VTOC, etc.) >I still have my flowcharting template and some FORTRAN coding forms >for punched cards... I suspect *somewhere* these are still used! :>I have the Fortran IV manual my father used when he was in grad school. <grin>>I actually considered altering the expression syntax to deliberately >render parens unnecessary (and illegal). I.e., if an expression >can have two different meanings with/without parens, then ONLY the >meaning without parens would be supported.Indentation sensitive syntax (I-expressions) is a recurring idea to rid the world of parentheses. Given the popularity of Python, iexprs may eventually find a future. OTOH, many people - me included - are philosophically opposed to the idea of significant whitespace. If you want syntax visualization, use a structure editor.>But, this added lots of superfluous statements just to meet that >goal *and* quickly overloads STM as you try to keep track of >which "component statements" you've already encountered: > area = (width_feet+(width_inches/12))*(length_feet+(length_inches/12) >becomes: > width = width_feet + width_inches/12 > length = length_feet + length_inches/12 > area = length * width >[Imagine you were, instead, computing the *perimeter* of a 6 walled room!]??? For what definition of "STM"? Transactional memory - if that's what you mean - shouldn't require refactoring code in that way.>> ... identifying required >> functionality, designing program logic, evaluating and choosing >> algorithms, etc. ... all may be *guided* in situ by specific knowledge >> of the target machine, but they are skills which are independent of >> it. > >But I see programming (C.A.E) as having moved far beyond the sorts of >algorithms you would run on a desktop, mainframe, etc. Its no longer >just about this operator in combination with these arguments yields >this result.As long as you don't dismiss desktops and servers, etc. [Mainframes and minis as distinct concepts are mostly passe. Super and cluster computers, however, are very important]. Despite the current IoT and BYO device fads, devices are not all there are. Judging from some in the computer press, you'd think the legions of office workers in the world would need nothing more than iPads and Kinkos. That isn't even close to being true.>I.e., there are just too many details of successful program deployment >that don't work when you get away from the rich and tame "classroom >environment". This is especially true as we move towards scenarios >where things "talk to" each other, more (for folks who aren't prepared >to deal with a malloc/printf *failing*, how do they address "network >programming"? Or, RPC/RMI? etc.)Again: CS is about computation and language theory, not about systems engineering. I got into it while ago with a VC guy I met at a party. He wouldn't (let companies he was backing) hire anyone more than 5 years out of school because he thought their skills were out of date. I told him I would hesitate to hire anyone *less* than 5 years out of school because most new graduates don't have any skills and need time to acquire them. I also said something about how the average new CS grad would struggle to implement a way out of a wet paper bag. Obviously there is a component of this that is industry specific, but few (if any) industries change so fast that skills learned 5 years ago are useless today. For me, it was a scary look into the (lack of) mind of modern business. YMMV, George
On 6/10/2017 6:01 PM, George Neuner wrote:> On Fri, 9 Jun 2017 22:50:31 -0700, Don Y <blockedofcourse@foo.invalid> > wrote: > >> On 6/9/2017 7:14 PM, George Neuner wrote: >>> On Fri, 9 Jun 2017 00:06:05 -0700, Don Y wrote: >>> >>>> ..., if you'd a formal education in CS, it would be trivial to >>>> semantically map the mechanisms to value and reference concepts. >>>> And, thinking of "reference" in terms of an indication of WHERE >>>> it is! etc. >>> >>> But only a small fraction of "developers" have any formal CS, CE, or >>> CSE education. In general, the best you can expect is that some of >>> them may have a certificate from a programming course. >> >> You've said that in the past, but I can't wrap my head around it. >> It's like claiming very few doctors have taken any BIOLOGY courses! >> Or, that a baker doesn't understand the basic chemistries involved. > > Comparitively few bakers actually can tell you the reason why yeast > makes dough rise, or why you need to add salt to make things taste > sweet. It's enough for many people to know that something works - > they don't have a need to know how or why.I guess different experiences. Growing up, I learned these sorts of things by asking countless questions of the vendors we frequented. Yeast vs. baking soda as leavening agent; baking soda vs. powder; vs. adding cream of tartar; cake flour vs. bread flour; white sugar vs. brown sugar; vege shortening vs. butter (vs. oleo/oil); sugar as a "wet" ingredient; etc. Our favorite baker was a weekly visit. He'd take me in the back room (much to the chagrin of other customers) and show me the various bits of equipment, what he was making at the time, his "tricks" to eek a bit more life out of something approaching its "best by" date, etc. [I wish I'd pestered him, more, to learn about donuts and, esp, bagels as he made the *best* of both! OTOH, probably too many details for a youngster to commit to memory...] The unfortunate thing (re: US style of measurement by volume) is that you don't have as fine control over some of the ingredients (e.g., what proportion of "other ingredients" per "egg unit") [I've debated purchasing a scale just to weigh eggs! Not to tweek the amount of other ingredients proportionately but, rather, to select a "set" of eggs closest to a target weight for a particular set of "other ingredients". Instead, I do that "by feel", presently (one of the aspects of my Rx's that makes them "non-portable -- the other being my deliberate failure to upgrade the written Rx's as I improve upon them. Leaves folks wondering why things never come out "as good" when THEY make them... <grin>]> WRT "developers": > > A whole lot of "applications" are written by people in profressions > unrelated to software development. The become "developers" de facto > when their programs get passed around and used by others. > > Consider all the scientists, mathematicians, statisticians, etc., who > write data analysis programs in the course of their work. > > Consider all the data entry clerks / "accidental" database admins who > end up having to learn SQL and form coding to do their jobs. > > Consider the frustrated office workers who study VBscript or > Powershell on their lunch hour and start automating their manual > processes to be more productive. > > : < more examples elided - use your imagination > > > Some of these "non-professional" programs end up being very effective > and reliable. The better ones frequently are passed around, modified, > extended, and eventually are coaxed into new uses that the original > developer never dreamed of. > > Then consider the legions of (semi)professional coders who maybe took > a few programming courses, or who learned on their own, and went to > work writing, e.g., web applications, Android apps, etc. > > It has been estimated that over 90% of all software today is written > by people who have no formal CS/CE/CSE or IS/IT education, and 40% of > all programmers are employed primarily to do something other than > software development. > > Note: programming courses != CS/CE/CSE educationAnd these folks tend to use languages (and tools) that are tailored to those sorts of "applications". Hence the reason I include a scripting language in my design; no desire to force folks to understand data types, overflow, mathematical precision, etc. "I have a room that is 13 ft, 2-1/4 inches by 18 ft, 3-3/8 inches. Roughly how many 10cm x 10cm tiles will it take to cover the floor?" Why should the user have to normalize to some particular unit of measure? All he wants, at the end, is a dimensionless *count*. [I was recently musing over the number of SOIC8 devices that could fit on the surface of a sphere having a radius equal to the average distance of Pluto from the Sun (idea came from a novel I was reading). And, how much that SOIC8 collection would *weigh*...]>>> I knew someone who was taking a C programming course, 2 nights a week >>> at a local college. After (almost) every class, he would come to me >>> with questions and confusions about the subject matter. He remarked >>> on several occasions that I was able to teach him more in 10 minutes >>> than he learned in a 90 minute lecture. >> >> But I suspect you had a previous relationship with said individual. >> So, knew how to "relate" concepts to him/her. > > In this case, yes. But I also had some prior teaching experience. > > I rarely have much trouble explaining complicated subjects to others. > As you have noted in the past, it is largely a matter of finding > common ground with a student and drawing appropriate analogies.Exactly. I had a lady friend many years ago to whom I'd always explain computer-related issues (more typ operational ones than theoretical ones) using "kitchen analogies". In a playful mood, one day, she chided me for the misogynistic examples. So, I started explaining things in terms of salacious "bedroom activities". Didn't take long for her to request a return to the kitchen analogies! :>>>> CS programs don't teach programming - they teach "computer science". >>> For the most part CS students simply are expected to know. >> >> I guess I don't understand the difference. >> >> In my mind, "programming" is the plebian skillset. > > Only sort of. Programming is fundamental to computer *engineering*, > but that is a different discipline. > > Computer "science" is concerned with > - computational methods, > - language semantics, > - ways to bridge the semantic gap between languages and methods, > - design and study of algorithms, > - design of better programming languages [for some "better"] > - ... > Programming per se really is not a requirement for a lot of it. A > good foundation of math and logic is more necessary.Petri nets, lamda calculus, S-machines, etc. But, to become *practical*, these ideas have to eventually be bound to concrete representations. You need ways of recording algorithms and verifying that they do, in fact, meet their desired goals. I know no one who makes a living dealing in abstractions, entirely. Even my physics friends have lives beyond a blackboard.>>> CSE programs are somewhat better because they [purport to] teach >>> project management: selection and use of tool chains, etc. But that >>> can be approached largely in the abstract as well. >> >> This was an aspect of "software development" that was NOT stressed >> in my curriculum. Nor was "how to use a soldering iron" in the >> EE portion thereof (the focus was more towards theory with the >> understanding that you could "pick up" the practical skills relatively >> easily, outside of the classroom) > > Exactly! If you can't learn to solder on your own, you don't belong > here. CS regards programming in the same way.But you can't examine algorithms and characterize their behaviors, costs, etc. without being able to reify them. You can't just magically invent an abstract language that supports: solve_homework_problem(identifier)>> I just can't imagine how you could explain "programming" a machine to a >> person without that person first understanding how the machine works. > > Take a browse through some classics: > > - Abelson, Sussman & Sussman, "Structure and Interpretation of > Computer Programs" aka SICP > > - Friedman, Wand & Haynes, "Essentials of Programming Languages" > aka EOPLAll written long after I'd graduated. :> Most (all?) of my college CS courses didn't have "bound textbooks". Instead, we had collections of handouts coupled with notes that formed our "texts". In some cases, the handouts were "bound" (e.g., a cheap "perfect binding" paperback) for convenience as the instructors were writing the texts *from* their teachings. Sussman taught one of my favorite courses and I'm chagrined that all I have to show for it are the handouts and my notes -- it would have been nicer to have a lengthier text that I could explore at my leisure (esp after the fact). The books that I have on the subject predate my time in college (I attended classes at a local colleges at night and on weekends while I was in Jr High and High School). Many of the terms used in them have long since gone out of style (e.g., DASD, VTOC, etc.) I still have my flowcharting template and some FORTRAN coding forms for punched cards... I suspect *somewhere* these are still used! :> Other texts from that period are amusing to examine to see how terminology and approaches to problems have changed. "Real-time" being one of the most maligned terms! (e.g., Caxton's book)> There are many printings of each of these. I happen to have SICP 2nd > Ed and EOPL 8th Ed on my shelf. > > Both were - and are still - widely used in undergrad CS programs. > > SICP doesn't mention any concrete machine representation until page > 491, and then a hypothetical machine is considered with respect to > emulating its behavior. > > EOPL doesn't refer to any concrete machine at all. > >>> What would you have done differently if C were not available for >>> writing your applications? How exactly would that have impacted your >>> development? >> >> The applications are written in Limbo. I'd considered other scripting >> languages for that role -- LOTS of other languages! -- but Limbo already >> had much of the support I needed to layer onto the "structure" of my >> system. Did I want to invent a language and a hosting VM (to make it >> easy to migrate applications at run-time)? Add multithreading hooks >> to an existing language? etc. >> >> [I was disappointed with most language choices as they all tend to >> rely heavily on punctuation and other symbols that aren't "voiced" >> when reading the code] > > Write in BrainF_ck ... that'll fix them. > > Very few languages have been deliberately designed to be read. The > very idea has negative connotations because the example everyone jumps > to is COBOL - which was too verbose.Janus (Consistent System) was equally verbose. Its what I think of when I'm writing SQL :< An 80 column display was dreadfully inadequate!> It's also true that reading and writing effort are inversely related, > and programmers always seem to want to type fewer characters - hence > the proliferation of languages whose code looks suspiciously like line > noise.Yes, but if you're expecting to exchange code snippets with folks who can't *see*, the imprecision of "speaking" a program's contents is fraught with opportunity for screwups -- even among "professionals" who know where certain punctuation are *implied*. Try dictating "Hello World" to a newbie over the phone... I actually considered altering the expression syntax to deliberately render parens unnecessary (and illegal). I.e., if an expression can have two different meanings with/without parens, then ONLY the meaning without parens would be supported. But, this added lots of superfluous statements just to meet that goal *and* quickly overloads STM as you try to keep track of which "component statements" you've already encountered: area = (width_feet+(width_inches/12))*(length_feet+(length_inches/12) becomes: width = width_feet + width_inches/12 length = length_feet + length_inches/12 area = length * width [Imagine you were, instead, computing the *perimeter* of a 6 walled room!]> I don't know about you, but I haven't seen a teletype connected to a > computer since about 1972.Actually, I have one :>>> You obviously have to understand the CONCEPT of "multiplication" in >> order to avail yourself of it. But, do you care if it's implemented >> in a purely combinatorial fashion? Or, iteratively with a bunch of CSA's? >> Or, by tiny elves living in a hollow tree? > > Rabbits are best for multiplication.Or, Adders and log tables! (bad childhood joke)>> In my case, you have to understand that each function/subroutine invocation >> just *appears* to be a subroutine/function invocation. That, in reality, >> it can be running code on another processor in another building -- concurrent >> with what you are NOW doing (this is a significant conceptual difference >> between traditional "programming" where you consider everything to be a >> series of operations -- even in a multithreaded environment!). >> >> You also have to understand that your "program" can abend or be aborted >> at any time. And, that persistent data has *structure* (imposed by >> the DBMS) instead of being just BLOBs. And, that agents/clients have >> capabilities that are finer-grained than "permissions" in conventional >> systems. >> >> But, you don't have to understand how any of these things are implemented >> in order to use them correctly. > > Which is one of the unspoken points of those I books mentioned above: > that (quite a lot of) programming is an exercise in logic that is > machine independent. > > Obviously I am extrapolating and paraphrasing, and the authors did not > have device programming in mind when they wrote the books. > > Nevertheless, there is lot of truth in it: identifying required > functionality, designing program logic, evaluating and choosing > algorithms, etc. ... all may be *guided* in situ by specific knowledge > of the target machine, but they are skills which are independent of > it.But I see programming (C.A.E) as having moved far beyond the sorts of algorithms you would run on a desktop, mainframe, etc. Its no longer just about this operator in combination with these arguments yields this result. When I was younger, I'd frequently use "changing a flat tire" as an example to coax folks into describing a "familiar" algorithm. It was especially helpful at pointing out all the little details that are so easy to forget (omit) that can render an implementation ineffective, buggy, etc. "Wonderful! Where did you get the spare tire from?" "The trunk!" "And, how did you get it out of the trunk?" "Ah, I see... 'I *opened* the trunk!'" "And, you did this while seated behind the wheel?" "Oh, OK. 'I got out of the car and OPENED the trunk'" "While you were driving down the road?" "Grrr... 'I pulled over to the shoulder and stopped the car; then got out'" "And got hit by a passing vehicle?" Now, its not just about the language and the target hardware but, also, the execution environment, OS, etc. Why are people surprised to discover that it's possible for <something> to see partial results of <something else's> actions? (i.e., the need for atomic operations) Or, to be frustrated that such problems are so hard to track down? (In a multithreaded environment,) we all know that the time between execution of instruction N and instruction N+1 can vary -- from whatever the "instruction rate" of the underlying machine happens to be up to the time it takes to service all threads at this, and higher, priority... up to "indefinite". Yet, how many folks are consciously aware of that as they write code? A "programmer" can beat on a printf() statement until he manages to stumble on the correct combination of format specifiers, flags, arguments, etc. But, will it ever occur to him that the printf() can fail, at RUNtime? Or, the NEXT printf() might fail while this one didn't? How many "programmers" know how much stack to allocate to each thread? How do they decide -- wait for a stack fence to be breached and then increase the number and try again? Are they ever *sure* that they've got the correct, "worst case" value? I.e., there are just too many details of successful program deployment that don't work when you get away from the rich and tame "classroom environment". This is especially true as we move towards scenarios where things "talk to" each other, more (for folks who aren't prepared to deal with a malloc/printf *failing*, how do they address "network programming"? Or, RPC/RMI? etc.) Its easy to see how someone can coax a piece of code to work in a desktop setting -- and fall flat on their face when exposed to a less friendly environment (i.e., The Real World). [Cookies tonight (while its below 100F) and build a new machine to replace this one. Replace toilets tomorrow (replaced flange in master bath today).]