Re: Seeking computer-programming job (Sunnyvale, CA)

[Kaz Kylheku]

And you're back where you started. If you pasted that code into the
editor from this news-post, saved it to a file, and compiled it,
that'd be three separate #:xs there.

Then you'd have to RTFM about *print-circle*.

See, you keep assuming that there isn't any more to Lisp than what you have
read so far in this Usenet thread.

Not relevant. It does not matter how the macro computes an output such
as

(let ((#:x value)))
...
(func(#:x))

(#:x) means call the function called #:x, rather than evaluate
the variable #:x.

all that matters is that when the compiler compiles the above source
code the #:xs will not be the same.

We don't know that. Two #:x symbols could be the same symbol or could
not. If the code is machine generated by a macro, the #:x will be the same
symbol because the macro would have done this:

(let ((x-sym (gensym)))
`(let ((,x-sym value))
(func ,x-sym)))

I.e it would allocate a single symbol and stick it into multiple places
in the generated code. When that code is printed, those will all look like
#:x.

Yes, woe to you if you try to cut and paste that code back into Lisp.

If you want that to work reliably, then you will just have to learn about the
*print-circle* variable in the Lisp printer.

Here is how you can write a Lisp list with three occurences of #:x which really
are the same object:

[1]> '(#1=#:x #1# #1#)
(#:X #:X #:X)

[2]> (eq '#1=#:x '#1#)
T

#1= OBJ means ``the notation of OBJ is to be read normally, but also
remembered by an association with the number 1''.

#1# means ``regurgitate the object that was previously associated with 1''.

And so things like circular references, and multiple occurences of homeless
symbols can be reprented at read-time.

When you enable *print-circle*, the Lisp printer will render objects into this
notation.

[1]> (setf *print-circle* t)
T
[2]> (let ((x (cons 1 2))) (setf (cdr x) x))
#1=(1 . #1#)

See, *print-circle* shows us that circular list has itself as its tail. The ##
notation is capable of backpatching. The whole object can be associated with
#1, but #1# can also occur inside that object. Here, the object is a single
cons notated with the dot notation, and the CDR slot of the cell is the
cell itself (backpointer).

 

[Tim X]

Series, you have said on numerous occasions that your here to debate
matters and are not interested in personal attacks. Thats all good and I
hope you can accept the following as an attempt to correct your
misunderstanding [rest of personal attack, and rest of post, deleted
unread]

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim and Arne.

Yeh, you keep saying that whenever someone points out your errors.

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, Tim.

Can't help but notice you cut my text just before the bit where I said
this was *not* a personal attack

That was a lie. I have little interest in reading lies. If I ever do
develop an inexplicable urge to read lies, I will visit whitehouse.gov
or a similar politician-run site.

OK, I see, its ok for you to personally attack me by claiming I lied,
but to criticise you for being completely wrong in your statements about
emacs is a personal attack. Nice double standard you have there.

have a good life and enjoy your blissful ignorance and I hope it
continues to keep you in your warm comfortable existance of deluded
superiority .

 

[Paul Donnelly]

I tried using that beast maybe ten years ago myself. It sucked. From
the sounds of this, things may have changed. Has it now got a user
interface a Windows user could get used to and be productive in
reasonably quickly, or does it still require a cheat sheet and weeks
of looking things up in the help to use effectively?

That depends... how good is your memory? Emacs definitely isn't for
people who never want to learn anything, ever.

But if you thought it sucked ten years ago, you'll think it sucks
now. It's got the same mature interface it's had for the last few
decades and will have for the next few.

Lacking In Syntax and Types.

Hmm, that implies that syntax is a good thing (and also that Lisp isn't
full of types...).

Language Implicated in Shortage of Parentheses.

That's a good one.

Lacking Infix Syntax for Plus.

I believe you've misquoted that one. It's, "Lacking Infix Syntax *a* Plus".

 

[thomas.mertes]

I don't consider all warnings as harmless. I was referring to
specific warnings which were mailed by John B. Matthews. When
compiling with gcc (which is also used also under Mac OS X) I use
the following options to get as much warnings as possible: [example warnings]

I've seen major bugs, in C programs and other languages, that were
revealed "only" through warnings.
The attitude that "warnings are harmless" is a major problem in the
software industry and one that needs to be stomped hard.  It's
nothing but carelessness.  Well, laziness.  Negligence, regardless.

I agree. OTOH I am not sure that it is possible to get rid of all
warnings.

The large number of warnings is confounding, although that may be a
limitation of the implicit conversions provided by the implementation
language. A later version of the compiler (4.3.4) finds more than 500
such warnings; it's hard to see a new warning when it arises.

It would be nice to get your help to examine all warnings.

Often, that requires rather close reading of preprocessor directives,
detailed understanding of external libraries, and even trying to infer
the programmer's intent.

I look forward to upcoming releases of seed7.

I just released seed7_05_20090524.tgz.
In the function filGets I used your limit of 0.5 MB.
Maybe I will reduce this limit further, since big mallocs
which are later realloced to something small may have
a negative impact on the heap structure.

I did many changes to reduce the number of C warnings, but
there are still some of them. Since I don't have gcc 4.3.4 it
would be helpful to get a List of its warnings.

Thanks in advance for your efforts.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[Pascal J. Bourguignon]

That's a good one.

Only if you forget than most other languages have more parentheses
than Lisp. Java being C-like syntax-wise, I'd bet it uses more
parentheses than Lisp. C does.

 

[thomas.mertes]

In the function filGets I used your limit of 0.5 MB.

I actually use your limit of 0x1FFFFFFF.
So it is ~0.5 GiB not 0.5 MB.
Sorry for the typo.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[John B. Matthews]

I look forward to upcoming releases of seed7.

I just released seed7_05_20090524.tgz.
In the function filGets I used your limit of 0.5 [GiB].
Maybe I will reduce this limit further, since big mallocs
which are later realloced to something small may have
a negative impact on the heap structure.

I did many changes to reduce the number of C warnings, but
there are still some of them. Since I don't have gcc 4.3.4 it
would be helpful to get a List of its warnings.

Thanks in advance for your efforts.

The new gets limit appears to be effective. For reference: compiling
seed7_05_20090524 on Mac OS X 10.5.7, using gcc version 4.0.1 (Apple
Inc. build 5490), I obtained 75 warnings [emailed]. This is about half
of the number in the previous version. In contrast, gcc version 4.3.4
20090225 (prerelease) offers 482 warnings [emailed].

 

[gugamilare]

This is impossible.

Oh, of course you're right. This is actually a shot of NetBeans with
the fonts and colors changed, the text pane fully expanded, a fake
menu that explicitly mentions Emacs and a superimposed Emacs-like mode
line and minibuffer. That's the only possible rational explanation...
that doesn't go against your religious dogma that Emacs has no GUI.

I've already posted screenshoots of Emacs, and not some windows
running on my machine, but rather the official ones, taken from the
official Emacs page. And Series Expansion only deleted them when he
replied. He also deleted wikipedia's links to places that say that
Emacs runs on X since 198*.

Any reasonable computer user (not even a programmer) who had thought
that Emacs is still terminal-based application and who read your post
(or any post that says otherwise - and there has been lots of them)
would either believe on what you are saying or look for Emacs official
web page or, in worst scenario, he would install Emacs to see it with
his own eyes. Obviously, he has done neither. And note that he
explicitly called you a liar while he does not even allow someone to
say that he is wrong about something without accusing that person of
making a "personal attack". He's been doing this forever.

The only explanation I can conclude from this is that he is indeed
doing this on purpose. There isn't another explanation. He must have a
very strange obsession on posting lies to make people angry. Now I am
glad I quit this thread long ago (with exception of one or two very
small posts).

 

[gugamilare]

Ah! And here is the ultimate proof of what I said in the last post.
He's just misquoted you, just like that. Why would he do this? To make
you angry, that's why!

 

[duane]

Only if you forget than most other languages have more parentheses
than Lisp.  Java being C-like syntax-wise, I'd bet it uses more
parentheses than Lisp.  C does.

Maybe not more, but certainly more wisely. Have a look at
http://www.eecs.berkeley.edu/~fateman/papers/lispfloat.ps and note in
section 3.5 (bottom of p9, top of p10) the discussion about the use of
parens. This was one of our first "fight back" forays into dispelling
some of the myths of Lisp.

Duane

 

[Seamus MacRae]

Irrelevant.

Not irrelevant, because so broadly applicable.

Emacs has been upgraded since the 70's.

You earlier claimed a complete rewrite, and a port to a whole new
platform. Which was it, a mere upgrade or a complete rewrite?

 

[Scott Burson]

Lost In Stupid Parentheses.
[...]

The thing I don't get is this. Lots of people have negative reactions
to Lisp's syntax and aren't shy about saying so. Leaving aside the
fact that these opinions are almost never grounded in substantial
experience, the thing that really weirds me out is that I don't hear
the same obloquy directed towards XML, which is MUCH WORSE than Lisp!
Not only is it full of paired delimiters, these delimiters are much
harder to type than simple parentheses (I'm referring to the strings
like "<element>" and "</element>"; the angle brackets themselves are
not delimiters so much as meta-delimiters). XML-based languages are
far uglier than I could possibly imagine Lisp seeming to anyone.
XSLT, for instance, is just hideous. And yet, I run into more and
more of these things, and hardly anybody seems to complain about
them. It's absolutely unfathomable.

Whatever you think of S-expressions, they're a much better solution to
the problem of representing arbitrary trees than XML, and they existed
decades ago.

-- Scott

P.S. This will be my only post on this topic.

 

[Alessio Stalla]

Ah! And here is the ultimate proof of what I said in the last post.
He's just misquoted you, just like that. Why would he do this? To make
you angry, that's why!

Yes, I know he does like that only to make me angry. Unfortunately,
it's hard to make me angry, I'm very stubborn, and I can't stand
people telling blatant lies and presenting them as objective truth.
(Though being Italian I'm very accustomed to that kind of behavior).

That said, I'm getting tired of this thread, and probably now it's so
huge that no one will ever want to read it, so no one has any chance
to become convinced by Series and Seamus' lies... so, mission
accomplished!

 

[Seamus MacRae]

Lost In Stupid Parentheses.
[...]

The thing I don't get is this. Lots of people have negative reactions
to Lisp's syntax and aren't shy about saying so. Leaving aside the
fact that these opinions are almost never grounded in substantial
experience, the thing that really weirds me out is that I don't hear
the same obloquy directed towards XML, which is MUCH WORSE than Lisp!

"Lots of Stupid Angle Brackets" doesn't quite have the same ring to it,
nor does its initials spell "XML".

But if you insist that an attempt be made:

eXtremely Muddled Language.

Whatever you think of S-expressions, they're a much better solution to
the problem of representing arbitrary trees than XML, and they existed
decades ago.

Perhaps the ability of cons cells to represent, directly, only binary
trees, and cons trees' use of position instead of name as lookup key,
could have something to do with it?

 

[Paul Donnelly]

Perhaps the ability of cons cells to represent, directly, only binary
trees, and cons trees' use of position instead of name as lookup key,
could have something to do with it?

That likely is what a person who didn't know anything about
s-expressions might think. Good point.

 

[java.oke]

[brain ****]

42

 

[Robert Maas, http://tinyurl.com/uh3t]

But such skills as needed to hussle a job under the current system

are irrelevant to many kinds of work, such as computer programming.
It really sucks that good skilled people with lots of other skills
are neglected for employment because they don't have that one
specific skill job-hustling and none of the employment agencies are
willing to do their supposed job.

From: Tim X <[email protected]>
A lot depends on what you define as job-huslling, but good peple [sic]
skills and communication skills are still important even for
programmers.

Agreed for some kinds of "people skills", but hustling to convince
total strangers to put out money to take a chance on hiring me
isn't at all the type of "people skills" needed by a software
programmer to interact with supervisor and co-designers. Lumping
the two grossly different kinds of skill-sets into a single label
"people skills", and thereby attempting to equate the two, does a
disservice to this discussion.

While much of the work you do as a programmer involves sitting at
a terminal cutting code, this is only part of the job.

Agreed. There's listening to the supervisor to learn what kind of
task must be automated, and brainstorming with that supervisor and
possibly other software designers to work out what's possible and
feasible and what needs changing to become feasible and what's most
cost effective in a general sense of being truly worth the effort,
and reporting partial work to the supervisor, and occasionally
engaging in debates as to the best way to accomplish a task. But
all of this is in a context of the software programmer *already*
being on the payroll, so there's incentive for everyone to
cooperate. Furthermore the various people already somewhat know
each other and have some existing trust between them. By
comparison, job hustling requires converting a hostile stranger
into making a major investment to put the new person on the
payroll, which involves a lot of cost even before the first
paycheck, and then locks the employer into a longterm situation
until and unless the employer can find a really good reason to fire
the new employee. True the new employer is usually on a
probationary period of three to six months during which firing is
easier than it would be later, but still it's a lot easier to just
not hire somebody in the first place than fire after hiring.
Convincing a stranger to take such a big risk on my behalf,
convincing that stranger that somehow the cost will reap greater
rewards, is far beyond the normal job duties of a software
programmer. It's ridiculous to say that somebody who doesn't have
advanced skills to hustle a new job during the worst recession in
70 years is consequently incapable of the "people skills" involved
in software programming work.

The days of a programmer being given a task and then they just go
off to wherever they do their work, code like mad and then deliver
the finished solution are gone (actually, I'm not even sure they
ever really existed).

At this point you're beating a dead horse, or straw man, reader's choice.

These days, programmers need to have good communications and
people skills to extract the true requirements of the software from
the client and to work well with others on the team.

I believe I could do all of that. During my prior work, I never was
allowed to talk directly with the actual customer, who was any of
several high school students who would be participating in our
experimental computerized course in college-level Calculus as soon
as we finished getting our software finished. I discussed
requirements only with my supervisor (on a regular basis) and with
a couple other top management people (occasionally). In terms of
requirements, it was these management people, not the actual
high-school student user, who needed to be accomodated. However
more recently I have become familiar with "use cases" and related
matters of true-customer requirements-determination, and I am
enthusiastically favoring such methodology and believe I could do
it quite well, if only some customer ever wanted me to write
software for him/her.

In fact, to some extent this has become an even more difficult
task as the general level of computer literacy has increased. Now,
more often than not, in addition to system requirements, you also
get clients telling you how to program the solution.

I clearly understand the difference between user requirements
(including both functionality and timing) and methods to accomplish
such requirements. I believe I could tease out what the customer
really needs, and why he/she feels some particular method would be
needed, and propose *other* methods which I feel would be better if
I can see a significant difference where the customer was in fact
mistaken, and hopefully I can either convince the customer to allow
me to implement *his/her* true needs using *my* judged best
methods, or otherwise just yield to the customer, with full
disclosure that in my opinion the customer's decision was a mistake
but the customer is paying for my labor and can order anything
possible.

often the requirements are difficult to identify because they
have presented you with what they think is the solution rather than
describing what they want.

IMO breaking down the system into "use cases" should go far in
resolving this kind of communication problem. I'll either ask the
customer which use cases ar required, or I'll guess what the
customer wants and propose my own set of use cases and allow the
customer to amend my guess, or a combination of the two approaches.
If the customer doesn't even understand the concept, I can re-word
my "guesses" as direct questions, such as "do you want this
software to allow a user to log into the system?" etc., and after a
series of YES answers I ask "is there anything else the system must
allow the user to do", and hopefully the user will finally either
agree my use cases are complete or say something I overlooked.

By the way, my current estimate of time needed is one use case per
half day (if programming in Common Lisp) or per full day (if
programming in Java or PHP), plus additional time for any totally
new algorithms that I need to craft from scratch. If the customer
agrees with me that six use cases are needed for a minimal (no
"bells and whistles") operational system, and I can get a prototype
system up and running in three days (using Common Lisp) for the
customer to play with to get a feel for both user interface and
"what's missing here", I expect the customer to be reasonably
satisfied.

You need good peple skills so that you can extract the real
requirements from what the client gives you - you can't just accept
what they tell you, implement exactly that and then expect they
will be satisfied with the result.

Agreed. I think my discussion just above covers that.

You need to make them feel comfortable enough that you can
discuss the problem they want to solve, feel free to ask questions
and be able to extract what you need without making them feel
uncomfortable, threatened or concerned that perhaps your not
terribly sane or don't understand the problem.

Whether the customer feels "comfortable" or not is partly a
psychological matter. Perhaps you would be willing to play customer
with me, making up a ficticious task you'd pretend-like to have
implemented, and we can then discuss use-cases and you tell
everyone whether you felt comfortable or not brainstorming the use
cases with me? If for any reason you don't feel comfortable, we can
discuss the psychological problems, and somebody can recommend
improvement. But if you *do* feel comfortable brainstorming with
me, then you can withdraw your apparent objection to this aspect of
my "people skills".

(snipped excessive verbage and rehashing)

Good communications skills are also required because fewer and
fewer programming jobs represent just a single developer working in
isolation. More often than not, there will be a team - possibly a
small team of only a couple of people or maybe a large team of 30
or more. To actively participate in the team, you need to be able
to communicate with them and you need the people skills necessary
to fit into the team.

My previous major job, that computer-Calculus course, had appx. ten
people on the project, so I think this issue is resolved already.

The first thing I'd want to know is why they haven't had a job
for 17 years.

Because during the first three years i was unemployed, nobody was
hiring, so the agencies wouldn't even *try* to match me with a job.
After the first three years, everyone had the ready excuse that I
had no recent employment, and that excuse has continued for an
additional 14 years.

Also because I don't know anybody. Getting hired is more a matter
of who you know than what skills and experience you have. If you
don't know anyone, all the skills and experience in the world are
of nearly zero help in getting hired. Recently I tried several
"networking" groups, including CSix, LinkedIn, etc., but so-far
none of them have resulted in even one person willing to get
connected to me for purpose of "networking".

The second thing I'd possibly want to know is what they had been
doing over that 17 years

A whole bunch of stuff. For the first several years I was spending
full time doing classical job search (writing and re-writing my
resume, scanning job ads, answering some job ads, contacting
employment agencies asking for their help) to the point where I got
emotionally burned out. During that time I kept careful records of
all my efforts, which now total 9.3 megabytes. Any time you want to
come over and look at it all and admit I ****really**** made an
effort to find employment, contact me for an appointment. Even
better, perhaps you could analyze what I did right and wrong, and
give me "strokes" for what I did right, and offer suggestions for
improvements of what I did wrong. Maybe after looking at all my 9.3
megabytes of SeekJob effort you can write a succinct explanation of
why none of that immense labor resulted in getting any employment
except for 60 hours of contract work I got in 1992.

I've also done lots of software work on my own, both traditional
software (programs/applications) and Web pages to organize and
present information. Highlights include my sort/merge utility and
use of it for file maintainance, my flashcard-drill application,
the "MaasInfo" indexes, and various CGI and PHP applications. For
more details from 1995 onward, see <http://tinyurl.com/352wo4>,

and what they had done to try and get a job

You can see those 9.3 megabytes of detailed notes any time you want.

The problem I would have with employiing anyone who had been
unemployed for 17 years is with the fact that if they couldn't
solve their unemployment problem for that length of time, can I
have any confidence they will be able to solve any of the problems
they are likely to run into while working for me.

Those are completely unrelated skill sets needed to solve those
very different kinds of problems.

(snipped strawman discussion of people in prison)

Whatever the case, I suspect you are more likely to find someone
who is willing to give you a chance once they understand why you
haven't worked for a long time and that there is a good reason for
it.

I have yet to find even one person who is willing to read those 9.3
megabytes of SeekJob notes to try to understand why none of that
immense effort (plus years of accomplishments on my own as noted
above) have failed to materialize into a paying job. Perhaps you
will volunteer to be the first.

Good people get screwed over all the time and bastards are often
very successful. What is important to realise is that the
individual plays a significant role in determining what their
situation is. Very few are simply passive victims.

I haven't been passive at all. See those 9.3 megabytes of direct
SeekJob efforts, and see those many many accomplishments on my own,
and tell me what at all I've ever done wrong. I'm willing to learn,
if you teach me, but so-far I haven't been able to find anyone
willing to network with me or give me one-on-one diagnosis of my
past efforts and suggestions for changes in the future.

It is how you handle the situation you find yourself in that
matters more than the causes of what put you there.

Read the 9.3 megabytes and tell me if I mis-handled anything whatsoever.

While it is positive to see someone wanting to get something
happening by starting their own projects and lookinig for others to
help, I do have to wonder why not just join an existing project.

I'm not aware of any other existing project of this type, anything
that will provide employment for *everyone*, allowing *anyone* to
become an employer despite not having money to begin with, thus
escaping from those who already have money dictating employment for
the rest of us. If you know of any such project, I'd be glad to
learn about it.

Establishing a new project, particularly one with multiple
contributors, is a difficult and time consuming process.

Less time-consuming than trying to do a ten man-years of work all
by *myself* fast enough to make the recession moot.

You will be able to get far more mileage out of working and
contributing to an existing recognised project in a much shorter
time than you will with starting your own project.

You're repeating yourself there. Please suggest a suitable project
I might join.

For the record, I do believe the way job interviews are handled
and the way applications are processed is fundamentally flawed. My
personal preference for assessing someone for a job is to give them
a simple task that will take about a week to complete and assess
how they deal with it and what they come up with.

I'm game. Please suggest such a project I could do for *you* during
the next week, some Web application. If it's just programming, I'll
do it in Lisp, while if it requires use of a relational database
I'll use PHP. But except for the URL you use to get it
(something.cgi or something.php respectively), you won't be able to
easily tell the difference.

This lets me see how well they fit in with the rest of the staff,

I don't see how accomplishig such a task shows anything to do with
fitting in with other staff. Please explain the connection.

how well they handle obstacles

That'll be covered in the preliminary discussion of use cases.
Before I start coding, I'll know the task is doable within
approximately that one week of time allowed.

and whether they actually can deliver the goods.

Yes. Let me prove it.

It may cost a weeks wages to find this out,

It won't cost you anything, except "pie in your face" if you claim
at the outset I'll fail but in fact I prove you wrong. Are you
willing to take that risk?

... arbitrary assessments based on an interview where all you can
tell is whether the person is a good interviewer or not.

Sometimes a good interviewer will ask a question about how to solve
some problem, basically asking for an informal algorithm to be
invented (or remembered/adapted) on the fly. For example, when I
interviewed for RSA Data Security, the interviewer asked me how I
achieved efficient modular exponentiation, and I described my
algorithm, and he agreed it was efficient but said his company used
a more efficient algorithm, and he described his proprietary
algorithm, and it seemed to indeed be more efficient in some
special cases but not essentially more efficient than what I
already devised appx. fifteen years previously. i fully expected to
be hired, but they never called me back even for a second
interview, and I have no idea why, because AFAIK I was fully
qualified for the job and in fact more than qualified, and they
never even had the decency to tell me why they didn't hire me.
- Good interviewer. Stupid hiring manager. -

Unfortunately, too many employers are worried about doing tis in
case they get problems with litigators, unions or government
beurocracy concerning hiring and firing - though this varies a lot
from country to country.

If you negotiate with me to assign a reasonable one-week project
for me to demonstrate my abilities, and I accept the task, I won't
later sue you for some aspect of the task you assigned me, OK?
Stop being so paranoid!

 

[Robert Maas, http://tinyurl.com/uh3t]

From: (e-mail address removed)

Don't expect some unrealisic change of the economic system.

You're mistaken on two counts. I'm making an effort *myself* (and
soliciting collabators to share the workload) to make a *realistic*
change.

The evolution will not allow that kapitalism (For europeans: free
market economy) to be replaced by something weaker.

I have no intention of getting rid of free market, in fact I want
to *enhance* free market to be more divisible, where *anyone* can
put their labors directly on the market, rather than only companies
and other well-established individuals having that capability.

What I plan to *replace* (as a growing share of the market, not as
a one-shot revolution as occurred in Marxist Russia) is the unit of
monetary exchange, getting rid of $money$ which only some people
have, and using instead *labor* which just about everyone has in
abundance any time there's sufficient incentive for them to develop
(produce) it. Anybody with lots of money and no time can contribute
$money$ to my system any time they want, purchasing *labor* at the
legal minimum wage. If any such $money$ is introduced into my
system, then per any restrictions that may be attached to that
$money$ somebody may later be able to "cash out" their *labor*
credits to get some of that $money$.

Survival of the fittest will not allow a weaker replacement (at
least not permanently, see Russia).

There's nothing weaker about my proposed new econonic system.

Take my advice: Try to adopt to the needs (people skills and
other things) and try to be successful in the current
world/economic system.

17+ years of effort per your advice haven't been successful. Your
advice is worthless. Please come over and read the 9.3 megabytes of
detailed notes about my attempts to follow your advice.

In companies I write C++ programs under Windows. This enables my [sic]
to help changing the world into a place were people write Seed7
programs under Linux.

Are you aware of that spelling mistake?
It doesn't look like a keystroke error, but a genuine English mistake.

 

[Kaz Kylheku]

You're mistaken on two counts. I'm making an effort *myself* (and
soliciting collabators to share the workload) to make a *realistic*
change.


I have no intention of getting rid of free market, in fact I want
to *enhance* free market to be more divisible, where *anyone* can
put their labors directly on the market, rather than only companies
and other well-established individuals having that capability.

But it's a consequence of the free market that well-established individuals and
companies have an edge; the market naturally prefers those individuals. You
seem to want to impose some rules which will take away that edge. Any such
rules take away freedom from the market.

The free market necessarily has certain entry barriers which arise
from its freedom. An entry barrier perceived by an individual vying
in the free market is a consequence of the free choice made by many other
individuals not to do business with him, for whatever reasons, none of which
necessarily indicate that there is any problem with the market itself.

 

[Paul Foley]

The only explanation I can conclude from this is that he is indeed
doing this on purpose. There isn't another explanation. He must have a

He's pretty clearly insane.