Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Swift Griggs]

On Fri, 27 May 2016, Fred Cisin wrote:
> Ah, but the Crazy Cranky C Curmudgeons Classic Computer Talk list is a 
> subset of cctalk. But, there was a big crash a while back, and 
> separation of the lists hasn't been completely successful.

Yes, quite correct and the tagline for the list is:

"General Discussion: On-Topic and Off-Topic Posts"

I'm going to call discussions of the relative merits of C coding "general 
discussion" and we'll say the curmudgeon bits are "off topic" if you like. 
It still seems to fit the list quite nicely. 

Also, to be fair:

1. Some of that discussion spawns other threads about classic hardware. 
Observe folks talking about hardware memory tagging features in classic 
systems to aid with GC and other items of discussion. 

2. Programming and computers are a bit hard to separate. Classic computers 
had classic languages, too. Witness the discussions on BLISS, BCPL, and 
older implementations of FORTRAN and COBOL that runs on classic machines. 
My point is that it's not really all that off-topic. 

curmudgeon (noun):
a bad-tempered or surly person.

Wouldn't complaining that people are going off the rails qualify as surly? 
Just sayin'  :-)  

-Swift

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Fred Cisin]

On Fri, 27 May 2016, Josh Dersch wrote:

Oh, I see what's going on.  See, this is the "cctalk" (Classic Computing
Talk) mailing list.  I think what you're meaning to send this to is the
"ccctalk" (Cranky C Curmudgeons Talk) mailing list.  Could we maybe talk
about classic computing rather than go on endlessly about the lazy kids
these days with their saggy pants and their terrible loud programming
languages?


Ah, but the Crazy Cranky C Curmudgeons Classic Computer Talk list is a 
subset of cctalk.
But, there was a big crash a while back, and separation of the lists 
hasn't been completely successful.

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Fred Cisin]

On Fri, 27 May 2016, Paul Koning wrote:
["Demystification"]
Those first two titles sound reasonable.  The third sounds strangely 
touchy-feely rather than like an engineering course.
A touchy-feely nickname applied by those who personally wouldn't have 
anything to do with it.



They had a brilliant visionary concept of CS education.
I would not put it that way.  "Brilliant" is a term of praise, as is 
"visionary".


"insane"?  "out of touch with reality"?
sarcasm is always risky here.

They tried to change the entire paradigm of beginning CS education into 
their image.



I'm surprised that such people would be working at a supposedly highly 
regarded outfit like Berkeley.
an infra structure that may promote such, or may put "out of the way" in 
something uncared about, such as undergraduate lower-division.



To be fair, I haven't heard anything from them in decades, so I have no 
idea how successful they were, nor whether their goals have changed.



UC for awhile accepted our "Data Structures And Algorithms" class and our 
"Advanced Microcomputer Programming" for transfer as a substitute for 
their "Demystification" course, but then suddenly dropped them with a 
stated reason of "The CATALOG description of them does not mention 
interrupt handlers".  (no, their catalog is also not a complete list of 
course content)


Later, for a few years, they accepted my "Microcomputer Assembly Language" 
and my "Computer Math" as substitutes for other reasonably irrelevant 
courses.


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Paul Koning]

> On May 27, 2016, at 3:25 PM, Fred Cisin  wrote:
> 
> ...
> Anyway, back to, . . .
> Clancy and Harvey reworked the UC undergraduate lower division (first two 
> years) curriculum.  They setup a three course sequence at the core, 
> consisting of "Abstraction", "Data Structures", and "Demystification". They 
> called a meeting of local CS departments to tell us what we should switch 
> over to teaching.

Those first two titles sound reasonable.  The third sounds strangely 
touchy-feely rather than like an engineering course.

> ...
> They declared, "Nobody programs in Assembly language any more, nor ever will 
> again."
> ...
> They had a brilliant visionary concept of CS education.

I would not put it that way.  "Brilliant" is a term of praise, as is 
"visionary".

Someone who claims that "nobody programs in assembly language any more nor will 
ever again" does not merit those adjectives.  The correct adjectives would be 
"ignorant" and "myopic".  Those are the correct terms because their assertion 
is valid only if you limit yourself to a limited class of programmers, and 
ignore compiler writers, diagnostics programmers, BIOS engineers, bootloader 
programmers, or embedded systems developers, just to name a few.

I'm surprised that such people would be working at a supposedly highly regarded 
outfit like Berkeley.

paul

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Fred Cisin]

> I had words with Clancy and Harvey.  While need may be diminshed, 
> there is never a complete elimination of the need to pay attention to, 
> and optimize near, the level of hardware.


[top posted, with Swift's remarks below]

The Clancy and Harvey topic is about curriculum, and teaching of "computer 
science".  Clancy and Harvey were/are two lecturers at UC Berkeley, who 
ended up in charge of lower division under-graduate CS.



First, I'll explain OUR curriculum at the community college, since that is 
what I know.  We had a varied mix of re-entry of dropouts, job training, 
AA degrees, preparation for transfer to 4 year colleges, skills 
enhancement for people employed in related jobs ("I want to take a course 
in C"), and adult enrichment.


We started off with an extremely simple introductory course that did not 
assume that the student had ever seen a computer. (In 1980 or so, that was 
a necessary assumption).  Offered as a 6 week drive-by, but generally a 
full semester for those who intended to go further.  It had just enough 
programming in it that a student would successfully create a program. 
(often done with BASIC)


Then an Introduction To Programming, with basic principles and concepts. 
Illustrated with multiple languages, but concentrating on a language of 
the instructor's choice for some minor projects.


Then choices of courses in multiple languages: COBOL (2 semester levels), 
FORTRAN, BASIC, Pascal, RPG, C, Mainframe Assembly (360/370), 
Microcomputer Assembly (X86), and occasional ones for only a few years 
each including RPG, ADA, etc.  Not all classes offered every semester.

Also work skills classes in using Microsoft Office, etc.

Data Structures And Algorithms, with a prerequisite of at least one 
programming language, and taught in language of instructor's choice (I 
used C, but I let students substitute other languages).  When I taught it, 
I included iterative V recursive tree algorithms.


I also taught "Microcomputer Disk Operating Systems" (heavy on MS-DOS, but 
trying to actually teach the principles applicable to ANY), and "Advanced 
Microcomputer Programming" (prerequisite of C and Assembly) which included 
TSRs, device drivers, walking directory trees, mixed language programming 
and stackframe structure, etc.  One of the assignments was to write a 
program that would display a complete directory of the disk.  I taught 
with C, X86 ASM, and MS-DOS, but students were free to substitute 
other languages and unix, Mac, or whatever, for their assignments.


I tried to implement a basic information science course on access to 
online information resources, but our curriculum committee vetoed it and 
rewrote it into how to surf the web.
We had constant struggles with the administration, who wanted to, and 
eventually succeeded at, removal of all advanced courses and anything with 
a prerequisite.  They REALLY wanted our department to be nothing but 
remedial job training for the digital sweatshop.  They killed EVERYTHING 
that had been worthwhile!
By 2013, when I finally told them to take my 33 year job and shovel it, I 
had still been unable to get them to let me try to do a basic beginning 
Information Science course (DIK/W/E, relevance ranking, economics and 
legalities of IP, recall/precision interaction, social impact of access, 
search engine algorithms, SEO, etc.)




Anyway, back to, . . .
Clancy and Harvey reworked the UC undergraduate lower division (first two 
years) curriculum.  They setup a three course sequence at the core, 
consisting of "Abstraction", "Data Structures", and "Demystification". 
They called a meeting of local CS departments to tell us what we should 
switch over to teaching.


They chose Scheme (a LISP derivative) for the first course.  They thought 
that recursion should be the fundamental basis of computer programming, 
even down to COUNTING from 1 to 10.  I used to usually give an assignment 
of Fibonacci numbers as an exercise in loop controls, etc. - I was a 
little taken aback when somebody from UC thought that it meant that I was 
starting my students off with recursion!  They gave a small example, which 
they declared CAN NOT (not "must not") be done with anything except 
recursion.  While they were putting it on the board, I coded it on my 
notepad as a two dimensional array with a nested loop in C, BASIC, 
Fortran, and got partway through COBOL.  (I take offense at being told 
things are "impossible" to do in other languages - "difficult" or 
"inappropriate" are acceptable).


Their "Data Structures" class was to be taught using C.  I asked about 
their C class.  They didn't have one, and declared that all students are 
assumed to already know C before they arrived there!


Their "Demystification" would be the first time that the students would be 
made aware of existence of anything under the hood.


They declared, "Nobody programs in Assembly language any more, nor ever 
will again."


I asked about timeline for 

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Toby Thain]

On 2016-05-27 12:54 PM, Josh Dersch wrote:

On Fri, May 27, 2016 at 7:59 AM, Swift Griggs  wrote:


On Thu, 26 May 2016, Fred Cisin wrote:
...
I'm not saying the state of the art can't be improved. I only assert that
there are some strategies for doing so that seem flawed from the start
because they start with unrealistic (or downright silly) founding
principles.



Oh, I see what's going on.  See, this is the "cctalk" (Classic Computing
Talk) mailing list.  I think what you're meaning to send this to is the
"ccctalk" (Cranky C Curmudgeons Talk) mailing list.


I think what you are observing is the non trivial intersection. :)

--Toby

> Could we maybe talk

about classic computing ...

- Josh





-Swift

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[jwsmobile]

On 5/27/2016 9:08 AM, Swift Griggs wrote:

While I don't formally do agile, what I do do is in line with many of
>the principles behind agile - things like "release early, release
>often", short iterations, and constant customer involvement.

I can appreciate some of the elements, also. It's just irritating when
they start turning it into meeting (oh wait... scrumm) hell and folks are
more focused on pushing the methodology than completing the project.
I had the task of doing mouse firmware for a project that ws a huge 40 
person C++ object oriented mass of crap with all the stuff that goes 
with that.


Note Customer here means the entity that consumes or engages your end 
product.  In this case there were other bits involved that were also 
large blank page projects, since this was an aircraft product. The 
hardware, manufacturing, test program, and even business and marketing 
were all formal, with little of the bullshit you'd think of as random 
operations in especially marketing and sales.


But in my tiny corner they were all blockheads about what I had to do to 
be "agile" and I just basically said go f yourselves.  I was basically 
expanding a manufacturer supplied sample code set, and I always work 
iteratively, but a lot of the things I had to do had to respond to 
things that were not planned.


The model of formally planning out the stuff that Agile has sometimes 
doesn't work.  Especially in places where embedded programming is 
involved.  But if the managers would look at what you have to do, 
frequently it is a modified version of that.


In this case the manager had never touched low level programming which 
was part hardware and software ever, and didn't get how much had to be 
"tried" and modified.  Luckily there were people who got the problem and 
eventually it was a good project.


Thanks
jim

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Swift Griggs]

On Fri, 27 May 2016, Mouse wrote:
> Agile and XP are less about programming productivity in isolation and 
> more about customer interfacing - and therefore productivity in terms of 
> producing happy customers

Well, as you suspected, I wasn't really thinking about that. That's the 
convenience of not having to run a business, I suppose. However, I do see 
your point. I feel sorry for the folks who have to live at the tip of the 
customer spear, so to speak. 

> No, if you're idolzing lone-wolf coders producing one-person projects on 
> their own (or even very small teams, if they already know one another 
> well), agile will be somewhere between irrelevant and obstructionist.

You definitely have me nailed on this one, too. That's exactly who I'm 
thinking of. I mentioned Carmak. He's sort of the poster child. No degree, 
no management BS, and has actual successful releases and REAL code that 
works extremely well and is very well written. However, yes, he's a wizard 
in a cave (and nowadays seems more interested in rockets anyway).

> I will hazard a guess that the projects/companies you're talking about 
> were not producing code for a customer, but were producing something for 
> themselves which, once produced, turned out to be appreciated.

Yes, you are right. That's the kind of thing I'm thinking of, not customer 
driven, customer facing type of projects. While I've been a part of those 
types of efforts, I think for myself personally, it's definitely not the 
right place for me. However, I certainly won't gainsay you on the benefits 
of certain methods of interacting with them. It's just not something high 
on my personal value-system.

> There, too, because there is no customer during coding and thus no 
> changing requirements during coding, and no customer to be kept happy 
> during coding, agile and XP are irrelevant.  If that's the only kind of 
> coding you care about, or what to do, or whatever, yes, you should 
> ignore them.

That's where I'm coming from, exactly. I know it's not the only 
perspective, it's just mine.

> A nontrivial fraction of the code I write falls into such categories. 
> But there is also a nontrivial fraction of the code I write that _does_ 
> have a separate customer, with changing requirements.

That's probably why you have a more nuanced and mature philosophy on such 
things. Jobs I've had which were more "customer facing" generally didn't 
last long. I have a truth and directness problem (read: lack of subtlety) 
that doesn't usually endear me to those types of gigs. So, I mostly ignore 
those types of "opportunities". Nonetheless, I'm probably poorer for it.

> While I don't formally do agile, what I do do is in line with many of 
> the principles behind agile - things like "release early, release 
> often", short iterations, and constant customer involvement.

I can appreciate some of the elements, also. It's just irritating when 
they start turning it into meeting (oh wait... scrumm) hell and folks are 
more focused on pushing the methodology than completing the project. That 
and the forced social interaction are negatives for me, personally. 
However, I might be describing my own "issues" here more than any formal 
argument or philosophy.

-Swift

Re: ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

[Mouse]

> I've worked under Agile and XP regimes and I hate both with a
> passion.  They were both a *huge* productivity drag (ever actually
> tried "pair programming"?)

Yes.  I've done agile and XP and even a little pair programming.

And...I agree and I disagree.

If you have a small project, something one person can do and you are
content with the result being in only one person's head, agile and XP
and the like are exactly what you say: a significant productivity lose.

But if you need the result to be in more than one person's head, or if
the project is such that one person can't handle it (too big, needs to
be done too fast, whatever), pair programming is - well, can be - a
substantial win overall.  It impairs _individual_ productivity for the
sake of _overall_ productivity.

Agile and XP are less about programming productivity in isolation and
more about customer interfacing - and therefore productivity in terms
of producing happy customers (where "customer" should be interpreted
liberally, not necessarily as "arm's-length entity that pays money").
If you're building something for yourself, if you're doing a
well-defined and highly predictable "here's the task, go away and come
back when it's done" job, they are of little to no use.  But if you're
building something where there's a nontrivial chance of the
requirements changing mid-job, and the coders and the consumer are
different, I find them to be of significant value - and that's a larger
fraction of the coding jobs than one might wish.

> It also seems to me that all the "greats" (incredible coders)

No, if you're idolzing lone-wolf coders producing one-person projects
on their own (or even very small teams, if they already know one
another well), agile will be somewhere between irrelevant and
obstructionist.

> and software projects or companies I loved or respected weren't
> "Agile".

Possibly.  I'd have to know which ones you have in mind to have any
chance of saying anything of value - and probably not even then, as
it's unlikely that whatever you have in mind is something I know
anything about the internals of.

I will hazard a guess that the projects/companies you're talking about
were not producing code for a customer, but were producing something
for themselves which, once produced, turned out to be appreciated.
(Perhaps they did so expecting that result, perhaps not - the critical
point is that there was no customer before/during coding.)  There, too,
because there is no customer during coding and thus no changing
requirements during coding, and no customer to be kept happy during
coding, agile and XP are irrelevant.  If that's the only kind of coding
you care about, or what to do, or whatever, yes, you should ignore
them.

A nontrivial fraction of the code I write falls into such categories.
But there is also a nontrivial fraction of the code I write that _does_
have a separate customer, with changing requirements.  While I don't
formally do agile, what I do do is in line with many of the principles
behind agile - things like "release early, release often", short
iterations, and constant customer involvement.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B