here's one way to understand the gist of the argument: consider programming to
be the application of a specification to a protocol.
in the old old days, the
protocol was "bang bits" and the specification was "register transfer level"
(RTL) instructions.
in the old days, the protocol was "drive widgets w/ signals" and the
specification was "connect this to that" instructions. a lot of gui
programming is still done this way (lamentably).
in the less recent past, the drudgery of wiring things from the
ground up spawned observation that it is possible to regularize some of the
wiring; the protocol was still the same but the specification started looking
like "connect pre-packaged-this to pre-packaged-that".
in the more recent past, the protocol expanded to "connect
your-this to your-that" and the specification evolved to be able to generate
more fitly that which was formerly pre-packaged en masse, to "declare my-this
and my-that".
in the present day, the protocol is "your-connect your-this to
your-that" and the specification is "declare my-connect, my-this and my-that".
the last step (towards adaptive programming by machines) is to hook up an
inference engine that specializes on situation, in order to generate the
proper my-* bits (all of them). then the protocol is "teach the engine" and
the specification is "recognize situation-A and try my-bits-A".
one can up-scope and note the (still somewhat imperfect) congruence of the
last step w/ the original RTL... in any case (heh), the world is a better
place if more users understand the programming mindset if not the act of
programming, per se. what is a programmer but a cultivator of the machine?
what is a good person but a self-programming philanthropist? what is a great
hacker but a good person w/ skillz?
but unfortunately, that pile is not formatted to fit in a wallet, like the
other piles. it will be ignored w/ only the janitor cursing in the morning.
(please, be kind to our janitors.)
flame on: "right tool for the job" demonstrates this person isn't engaging
the first tool that's necessary: the brain! when using your brain, you notice
other people using their brain and what naturally follows is: the question!
which question, you ask? well, how about: why? if you use your brain and
respect that others use their brain, you don't bandy about phrases like "i
hope [insert personal prejudices here] and they are doing it instead because
it is the right tool for the job". let's kill this slovenly meme now.
do it in r5rs scheme, as implemented by
guile-1.4.x.
this helps
me improve guile (to the point of compilation) and helps you work
in a rapid prototyping fashion. screw the "joy of implementation",
get heady on the joy of design.
if your personal temperament allows working with other people,
design the core well and bask in the ensuing community effort.
if you are more the lone wolf, rapid prototyping (currently
incarnated under fad name "extreme programming") is even more
indicated (in the medical sense) because you can (re- re- re-)
design everything w/o undue discomfort. you could probably
post a complete app in a few days, why not?
(do it right and we'll hook it up to emacs, oh yes.)
get a guitar, form a band, get a girl, make some CDs, tour the bars.
lose the guitar, quit the band, marry the girl, archive the CDs,
write free software.
nowhere in the above advice do you need more bandwidth than what your
fingers (and toes (cf. girl)) can twiddle.
this is obviously an attempt by usloth (no legal entanglement from them
is interpretable as support) to dis-educate those programmers
stupid enough to continue developing on their platform. the goal is
simple: do to programming what has been done first to users and then
system administrators: make them dumb slaves forking over their freedom
(and money) for meager morsels of usloth approval.
when programming the usloth platform is akin to punching your microwave
oven, who needs to understand the great loss implied by a pay-per-view
(p-p-program, p-p-compile, p-p-*) mentality and practice? "it's only a
few cents (each time), boss, and i am so productive tickling the
mediaglyphs, just sign the check for the upgrade, please, PLEASE!"
programming is a craft, an art, a science (if done right). the usloth
approach does not cultivate society. usloth slaves are to be pitied.
first thing is to stop asking stupid yes/no questions. if i answered:
"YES", what have you learned? if i answered: "NO", what have you learned?
next, realize that the role your boss plays is akin to being a parent
(guess who's the child). do you think can be a better parent than your
parents? sure, and same goes with being a better boss than your boss.
this means whatever the root issues (sounds like ego) that are plaguing
the system, you can play a role at changing them by learning to manage
yourself. the upshot of all this is that you won't need the boss.
lastly, take heed of some of the trite but true words of the parent post.
realize you have to grow your life, not just "get one". spend the time
understanding the people and they will help your head in the long run,
much more so than these n-ary machines, no matter what the n.
(1.4.1.x
is work-in-progress precursor to 1.4.2, fyi.)
the trick here is to integrate texinfo (standard GNU documentation source
format) generation with
automake methodology
(which assumes
texinfo is hand-maintained). in the vein of foo2bar naming convention,
the TWERP (Texinfo With Eval-Requiring Predelictions:-) file is
processed to.texi with twerp2texi (which also handles indexing,
automatic dependency tracking a la depcomp, and Makefile prep).
here's a simple example (from doc/ref/scheme-compound.twerp):
If you are unfamiliar with the inner workings of hash tables, then this facility will probably be a little too abstract for you to use comfortably. If you are interested in learning more, see an introductory textbook on data structures or algorithms for an explanation of how hash tables are implemented.
The @twerpdoc directives expand to documentation on hashq
(from Scheme) and scm_hashq (from C), mined from libguile/hashtab.c,
and so forth. modify hashtab.c, do a "make" and the.texi (and.info and.html if enabled) is regenerated.
this differs from the article's system in that outline info (and document
organization in general)
is maintained in.twerp files, which "pull in" reference docstrings
and other bits as needed from source, rather than adhering to "one source"
doctrine. probably we will introduce more @twerpFOO directives (e.g., to
do bit-field diagram or embedded DAG layout) in the future. for more info,
see documentation on twerp2texi itself in the guile docs (in tarball above).
everything depends on the job in question, of course. i assume for
simple coding (i.e., very little algorithmic formulation required)
by the time you figure out who's good or not there will be some magic
code generator wizard thingy which would obsolesce any answers people
give here anyway.
so let's focus on jobs that require skills other than being able to
type into a keyboard fragments of caffeine-induced hype fallout, i.e.,
jobs that require some amount of analogy mapping aptitude (AMA for short).
an analogy is the layman's term for "model" which is what needs to be
clear in the Programmer's head at some point in the process, preferably
early on.
mapping is the translation of this model into some design and
eventually code. the mapping needs to be flexible because not all parts
of the model are architecture (fundamental to that class of models);
some parts are implementation (likely to change at the whim of your
customer). a good mapping produces two deliverables: the design and the
cleavage points (if you will) where a small tap can separate the architecture
from the implementation (to facilitate maintenance, don't forget about that:-).
lastly, aptitude is what you think it is: tractable ability honed
from either intuition or experience, preferably the latter. here, tractable
is the meta-ability to call forth the ability at will and also includes the
social skills of working with other people. the latter is (un)fortunately
outside the scope of this post, however.
so now that we've defined these
terms, how to go about assessing the candidate Programmer AMA?
here's a concrete suggestion: pick a process (say the hiring process or
the process of recycling glass bottles or the process of programming itself
(if you think the candidate is sufficently meta)). ask the candidate to
model it. check to see if the description includes all inputs/outputs
(interfaces). ask the candidate to redesign that process to optimize it
somehow (say, for less paperwork --- always a relatable goal!). check
to see if the interface breaks in the new design. if the interface breaks,
your candidate does not have Hacker nature, but may still be competent in
other ways. obviously if the candidate cannot do this redesign, or if
the new design doesn't work at all (after some encouraging re-iteration ---
no need to be hard-ass), your candidate may not be a worthy Programmer.
keep in mind, too, that sometimes people have ability to change themselves
in which case their (un)worthiness as a Programmer may improve. but that's
another post for another time...
yes, unfortunately neal stephenson was wrong in snow crash (although
his language is delightful anyway). america will probably lose the lead
in competitive software technologies (read: AI) in the next decade or so if
its government (by the people for the people, supposedly) adopts and supports
the proprietary software mindset. that just leaves pizza delivery and music,
and everyone knows the latter is crap already.
ok, all the "mike is so on crack" noises are in. whatever.
the point is that your tax money is funding oppression of someone
you should be caring about the most: YOU. anyone who likes to pay
taxes and get lied to keep your eyes closed, maybe ignorance truly
is bliss. this "best tool for the job" meme is a sorry excuse for
using that thing which separates you from the animals you so desperately
want to emulate, your brain. the best tool for the job of governing
yourself is to actually DO IT, which means you need to know yourself.
if you vest authority in some other party the best tool for their job
(of governing you) STILL is to know themselves. bottom line: you don't
know jack shit w/ proprietary software.
... is not a valid combination of concepts. trust is not an inherent property; it is neither "genuine" or "bogus". it is only "richly-supported" or "poorly-supported". (this is analogous to "security is a process not a state".)
well, the old guard is also responsible for putting into place societal structures that demean and exploit the young. not all old people can be trusted in the same way (if at all).
every generation has its cowards and its luminaries. you don't need to burn your books so much as keep them around for the rennaissance that must come at the end of the current cultural dark ages. if you write some free software, that's good too.
ummm, the government is using your tax dollars to let usloth walk all over you as it stands (and the kicker is that usloth pays no taxes). is this status quo really more acceptable to you than finding a system that's at it's heart more accountable, more stable and more immune from virus of the day? your tax dollars are going to usloth to put vulnerable (from a "cyber-warfare" point of view) machines into use. perhaps it's inherently treasonous to NOT demand change.
programmers are currently largely of the human variety, so whatever conceptual model you stumble upon in your quest is bound to have artifacts of that background. the usefulness of a human model for humans is natural, but did you ever think, is this model natural for non-humans? when computers try to program, what models do they use to communicate? serial protocols, mostly. imagine a drunk man on a very small planet (a la "little prince") shining a flashlight on and off to other planets, trying to control the heavens (and trying to remember why this is going on in the first place:-).
but even that is an (obvious) anthropomorphization of the modelling problem done by a human. it may be we never know how computers dream, which is a sad thing.
when an institution of learning says "do not share code" they really mean "do not share ideas because that's why you pay us -- to gently place them in your vacuous skull neatly dove-tailing w/ your societally-induced blindness to your own ability to go out and do the Deed (i.e., Learning) on your own w/o our premeditated premediated premedicated pablum".
if that's the kind of message you want to pay for, there's a cheaper method: watch TV.
look, you illustrate the OP point if you tell everyone where you grew up. 'nuff said. have you been to a city where there are People in the Square instead of Metered parking Slots? woah, what a concept! why your lame post was modded up is beyond me.
Slashdot Mirror
what does a company's association w/ free software have to do w/ the free software? free software can't die; your restriction of terms is artificial.
corporate control is concentrated by proxy, and is a separate concept from corporate ownership.
most valuable would be most subjective assessments, as long as the subject (the one making the asssement) is experienced.
if an assessment is most objective, it can be done by machine, but that is not useful in this case.
carry on...
one can up-scope and note the (still somewhat imperfect) congruence of the last step w/ the original RTL... in any case (heh), the world is a better place if more users understand the programming mindset if not the act of programming, per se. what is a programmer but a cultivator of the machine? what is a good person but a self-programming philanthropist? what is a great hacker but a good person w/ skillz?
what part of SCO is owned by usloth?
thi
you're welcome.
thi
thi
if your personal temperament allows working with other people, design the core well and bask in the ensuing community effort. if you are more the lone wolf, rapid prototyping (currently incarnated under fad name "extreme programming") is even more indicated (in the medical sense) because you can (re- re- re-) design everything w/o undue discomfort. you could probably post a complete app in a few days, why not?
(do it right and we'll hook it up to emacs, oh yes.)
good luck!
thi
nowhere in the above advice do you need more bandwidth than what your fingers (and toes (cf. girl)) can twiddle.
good luck!
thi
when programming the usloth platform is akin to punching your microwave oven, who needs to understand the great loss implied by a pay-per-view (p-p-program, p-p-compile, p-p-*) mentality and practice? "it's only a few cents (each time), boss, and i am so productive tickling the mediaglyphs, just sign the check for the upgrade, please, PLEASE!"
programming is a craft, an art, a science (if done right). the usloth approach does not cultivate society. usloth slaves are to be pitied.
thi
next, realize that the role your boss plays is akin to being a parent (guess who's the child). do you think can be a better parent than your parents? sure, and same goes with being a better boss than your boss. this means whatever the root issues (sounds like ego) that are plaguing the system, you can play a role at changing them by learning to manage yourself. the upshot of all this is that you won't need the boss.
lastly, take heed of some of the trite but true words of the parent post. realize you have to grow your life, not just "get one". spend the time understanding the people and they will help your head in the long run, much more so than these n-ary machines, no matter what the n.
the trick here is to integrate texinfo (standard GNU documentation source format) generation with automake methodology (which assumes texinfo is hand-maintained). in the vein of foo2bar naming convention, the TWERP (Texinfo With Eval-Requiring Predelictions :-) file is
processed to .texi with twerp2texi (which also handles indexing,
automatic dependency tracking a la depcomp, and Makefile prep).
here's a simple example (from doc/ref/scheme-compound.twerp):
The @twerpdoc directives expand to documentation on hashq (from Scheme) and scm_hashq (from C), mined from libguile/hashtab.c, and so forth. modify hashtab.c, do a "make" and the .texi (and .info and .html if enabled) is regenerated.
this differs from the article's system in that outline info (and document organization in general) is maintained in .twerp files, which "pull in" reference docstrings
and other bits as needed from source, rather than adhering to "one source"
doctrine. probably we will introduce more @twerpFOO directives (e.g., to
do bit-field diagram or embedded DAG layout) in the future. for more info,
see documentation on twerp2texi itself in the guile docs (in tarball above).
so let's focus on jobs that require skills other than being able to type into a keyboard fragments of caffeine-induced hype fallout, i.e., jobs that require some amount of analogy mapping aptitude (AMA for short). an analogy is the layman's term for "model" which is what needs to be clear in the Programmer's head at some point in the process, preferably early on.
mapping is the translation of this model into some design and eventually code. the mapping needs to be flexible because not all parts of the model are architecture (fundamental to that class of models); some parts are implementation (likely to change at the whim of your customer). a good mapping produces two deliverables: the design and the cleavage points (if you will) where a small tap can separate the architecture from the implementation (to facilitate maintenance, don't forget about that :-).
lastly, aptitude is what you think it is: tractable ability honed from either intuition or experience, preferably the latter. here, tractable is the meta-ability to call forth the ability at will and also includes the social skills of working with other people. the latter is (un)fortunately outside the scope of this post, however.
so now that we've defined these terms, how to go about assessing the candidate Programmer AMA?
here's a concrete suggestion: pick a process (say the hiring process or the process of recycling glass bottles or the process of programming itself (if you think the candidate is sufficently meta)). ask the candidate to model it. check to see if the description includes all inputs/outputs (interfaces). ask the candidate to redesign that process to optimize it somehow (say, for less paperwork --- always a relatable goal!). check to see if the interface breaks in the new design. if the interface breaks, your candidate does not have Hacker nature, but may still be competent in other ways. obviously if the candidate cannot do this redesign, or if the new design doesn't work at all (after some encouraging re-iteration --- no need to be hard-ass), your candidate may not be a worthy Programmer.
keep in mind, too, that sometimes people have ability to change themselves in which case their (un)worthiness as a Programmer may improve. but that's another post for another time...
the point is that your tax money is funding oppression of someone you should be caring about the most: YOU. anyone who likes to pay taxes and get lied to keep your eyes closed, maybe ignorance truly is bliss. this "best tool for the job" meme is a sorry excuse for using that thing which separates you from the animals you so desperately want to emulate, your brain. the best tool for the job of governing yourself is to actually DO IT, which means you need to know yourself. if you vest authority in some other party the best tool for their job (of governing you) STILL is to know themselves. bottom line: you don't know jack shit w/ proprietary software.
thi
every generation has its cowards and its luminaries. you don't need to burn your books so much as keep them around for the rennaissance that must come at the end of the current cultural dark ages. if you write some free software, that's good too.
thi
thi
but even that is an (obvious) anthropomorphization of the modelling problem done by a human. it may be we never know how computers dream, which is a sad thing.
best of luck understanding things!
thi
thi
if that's the kind of message you want to pay for, there's a cheaper method: watch TV.
thi
thi
thi