RE: Functional Paradigm popularity and Maths (Was: XML as a transition to s-expr)

["David Simmons" <address@hidden>]

P.S.,

I should also add that I would not want nor would I be very interesting
in hiring a language designer/implementor who did not have solid "real"
experience and skills in writing and thinking in assembly language. 

I would prefer it even more if they had EE skills in digital logic and
the microprocessor systems. Modern processor caching architectures and
related instruction scheduling issues are non-trivial and play a
fundamental role in compiler/language design and implementation.

I.e., These skills are invaluable in the design of a compiler
architecture (especially for optimization and design of
front-end/intermediate-language/back-end architectures).

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org


> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
[mailto:owner-ll1-discuss@ai.mit.edu]
> On Behalf Of David Simmons
> Sent: Friday, December 21, 2001 5:04 PM
> To: jmarshall@mak.com; 'Guy Steele - Sun Microsystems Labs'
> Cc: David.Simmons@smallscript.net; ll1-discuss@ai.mit.edu
> Subject: RE: Functional Paradigm popularity and Maths (Was: XML as a
> transition to s-expr)
> 
> > -----Original Message-----
> > From: owner-ll1-discuss@ai.mit.edu
> [mailto:owner-ll1-discuss@ai.mit.edu]
> > On Behalf Of jmarshall@mak.com
> > Sent: Friday, December 21, 2001 1:16 PM
> > To: Guy Steele - Sun Microsystems Labs
> > Cc: David.Simmons@smallscript.net; ll1-discuss@ai.mit.edu
> > Subject: Re: Functional Paradigm popularity and Maths (Was: XML as a
> > transition to s-expr)
> >
> > Guy Steele - Sun Microsystems Labs <gls@labean.East.Sun.COM> writes:
> >
> > >    > So why should I "always" need to hire a person with a
> > "solid/formal"
> > >    > foundation in computer science for working on a given
software
> > >    > problem.
> > >
> > >    Because you would not hire a nurse whose only experience with
> > medicine
> > >    is anecdotal.  Because you would not hire a cook that did not
> > >    understand that incorrectly prepared food can be fatal.
> > >
> > > Thanks for an excellent parable.  Let's explore it further.
> > >
> > > Rather than hiring an expert chef who has been trained and
> > > certified in the art of removing the poisonous parts from
> > > a blowfish (fugu), leaving only enough toxin in the flesh
> > > that I (probably) won't die from it, I think I'd rather hire
> > > the guy who's just a basic short-order cook who doesn't try
> > > to get fancy.
> > >
> > > If I *had* to eat fugu for some exotic reason, I'd want the
expert.
> > > But for everyday breakfasts, I'm willing to settle for an omelet,
> > > hash browns, and OJ.  Getting the eggs to be fully cooked isn't
> > > that hard, and (more to the point) I can easily tell when it
hasn't
> > > been done right.
> >
> > Ok, I guess the question comes down to whether `understanding lists
> > and recursion' is more along the lines of removing poison from fugu
or
> > making hash and eggs over easy.  Perhaps I'm a computer snob, but I
> > put sausage links and linked lists in the same category.
> >
> > I don't expect a new hire to understand lattices and retracts, but
he
> > better understand a linked list.
> 
> Personally, if we're prioritizing valuable skills for a desirable
> generic industry "hire":
> 
> a) How to *never* break a team build. And that goes hand-in-hand with
> understanding what it means to be on a team; and understanding what
> commercial quality software production really means.
> 
> b) Bug reporting, tracking, and escalation management [based on
managed
> processes and business constraints/priorities].
> 
> c) Quality Assurance Processes - not the least of which is beginning
> with consistent "team" practices for style and naming conventions.
> 
> d) Feature set management. Ability to compromise under a schedule.
> Ability to create "safe" workaround solutions when a bug/design
problem
> cannot be resolved within scheduled time/budget.
> 
> e) Understanding of what "ship-date" means, and the phases of
mastering
> software and lockdowns to get there.
> 
> f) Experience with foreign (human) languages and cultural issues.
> Understanding of necessary design infrastructure for globalization and
> localization.
> 
> g) Experience with multiple language paradigms. Experience with
multiple
> platforms (operating systems, windowing/graphic systems). Ability to
> design for cross/multi-platform architectures and deployment.
> 
> h) Experience with design [and implementation] of: real-time software,
> embedded software (devices), shrink-wrap applications, device-drivers,
> re-usable documented libraries, server systems, mainframe
architectures
> and environments, etc.
> 
> i) Experience and understanding of modularization and versioning
issues
> in the "real-world". I.e., ability to design and/or create
architectures
> for patching and updating software elements in view of legacy
software,
> backward compatibility, or unanticipated configurations of related
> elements and deployment environments.
> 
> j) Ability to read and critique code in a "constructive" manner to
> improve the level of the entire teams efforts. Understanding and
> patience for working with and getting the most out of "star" players
and
> skill in integrating them into a team (or in being one on a team).
> 
> So, yeah, formal-linguistic training in recursion and thinking in
terms
> of s-expressions; for me, that pales in comparison. The point being
that
> software is (or should be) "engineered" [as opposed to being
researched,
> theorized, and proven].
> 
> And, I'll say it again, real understanding of recursion and the
ability
> to think in terms of lists (or more properly a solid grasp on discrete
> mathematics) is not essential. While such skill/ability is highly
> desirable, it is also not a realistically available skill in the
average
> worker within the software field and it does not get the same rewards
as
> other skills such as those I mentioned (nice run-on sentence, ehh).
> 
> The foundational building blocks for software are another issue
entirely
> (they are where "art & science" take center stage).
> 
> For a "hiring" (based on my hiring of employees to create, maintain,
> support, and deliver software), it is the ability to "deliver" a valid
> solution that meets/achieves business/organizational requirements and
> objectives that matters. For a "researcher" or "architect", I would
have
> different skill requirements which would include both the
aforementioned
> set *and* formal (or solid self-taught) computer-science and software
> engineering design skills.
> 
> Making the "best" software is a personal, artistic motivation that
may,
> or may not, be relevant for a given project. I use the phrase "best",
> because it is, in fact, a very subjective term which is often
> conditioned based on preconceived ideas and the
> experiential/preferential basis of those forming such an opinion of
> "best".
> 
> -- Dave S. [SmallScript LLC]
> 
> SmallScript for the AOS & .NET Platforms
> David.Simmons@SmallScript.com | http://www.smallscript.org
> 
> 
>