The Fundamental Problems of Lisp - lisp

This is a discussion on The Fundamental Problems of Lisp - lisp ; Fundamental Problems of Lisp Perm url: http://xahlee.org/UnixResource_dir/w..._problems.html plain text version follows. ---------------------------------------------- ... Since i'm writing... n i wrote a lot in the past on diverse issues scattered in various essays... i'll sum some fundamental problems of lisp. • Lisp ...

+ Reply to Thread
Page 1 of 12 1 2 3 11 ... LastLast
Results 1 to 10 of 111

The Fundamental Problems of Lisp

  1. Default The Fundamental Problems of Lisp

    Fundamental Problems of Lisp

    Perm url:
    http://xahlee.org/UnixResource_dir/w..._problems.html

    plain text version follows.

    ----------------------------------------------
    ...

    Since i'm writing... n i wrote a lot in the past on diverse issues
    scattered
    in various essays... i'll sum some fundamental problems of lisp.

    • Lisp relies on a regular nested syntax. However, the lisp syntax has
    several
    irregularities, that reduces such syntax's power and confuses the
    language
    semantics. (i.e. those «' # ; ` ,» chars.) (and whenever i tried to
    get some
    technical answer about this to clarify at least my own understanding,
    the lisp
    fuckheads muck and obfuscate the truth)

    • Lisp's irregular syntax those «' # ; ` ,» things, are practically
    confusing
    and made the lang less powerful. i.e. in elisp, there's no form of
    comments in
    matching delimiters (and consequently no nested comment). The reliance
    on EOL
    chars as part of the syntax semantics is one of the major fuckup to
    the power
    of pure nested syntax.

    • Lisp relies on a regular nested syntax. Because of such regularity
    of the
    syntax, it has very powerful consequences, at least theoretically.
    (and
    practically, lispers realized just one: the lisp macros) For example,
    since
    the syntax is regular, one could easily have alternative, easier to
    read
    syntaxes as a layer. (the concept is somewhat known in early lisp as
    M-expression) Mathematica took this advantage (probably independent of
    lisp's
    influence), so that you really have easy to read syntax, yet fully
    retain the
    regular form advantages. Lisp, on the other hand, such alternative
    syntax has
    been done and tried here and there in various forms or langs, but
    never caught
    on due to largely social reasons. Part of these reasons are political.
    (thanks
    to, in part, the Lisp old hats that suppresses it.)

    • One of the advantage of pure fully functional syntax is that a
    programer
    should never, ever need to format his source code (i.e. pressing tabs,
    returns) in coding, and save the hundreds hours of labor, guides,
    tutorials,
    advices, publications, editor tools, on what's known as “coding style
    convention”, because the editor can trivially reformat the source code
    on the
    fly based on a simple lexical scan. This is done in Mathematica
    version 3
    (~1996). In coding elisp, i'm pained to no ends by the manual process
    of
    formatting lisp code. The lisp community, established a particular way
    of
    formatting lisp code as exhibited in emacs's lisp modes and written
    guides in
    conventions. The recognization of such convention further erode any
    possibility and awareness of automatic, uniform, formatting.

    • Lisp relies on a regular nested syntax. One of the power of such
    pure syntax
    is that you could build up layers on top of it, so that the source
    code can
    function as markup of conventional mathematical notations (i.e. LaTeX)
    and or
    as a word-processing-like file that can contain structures, images,
    yet lose
    practical nothing. This is done in Mathematica in ~1996 with release
    of
    Mathematica version 3.

    Further readings:

    * The Concepts and Confusions of Prefix, Infix, Postfix and Fully
    Functional
    Notations
    * The Harm of Hard-wrapping Lines
    * A Text Editor Feature: Syntax Tree Walk
    * A Simple Lisp Code Formatter

    The above are some of the damages lispers has done to themselfs, with
    respect
    to its nested functional syntax. The other major one is the cons
    business.

    • Lisp at core is based on functional programing on lists. This is
    very
    powerful. However, for historical reasons, lisp's list is based on the
    hardware concept of “cons” cell. This fundamentally handicapped the
    advantages
    of power of list processing.

    Lisp being historically based the cons for like 2 or 3 decades. The
    cons (and
    cdr, car, caadar etc) are fundamentally rooted in the lisp langs, is
    thus not
    something that can be easily fixed. Quite unfortunate. However, this
    situation
    could be improved. But, whenever i discuss this, you can see that the
    lisper
    slaves here, their mentality, prevents any possible improvement. (in
    general,
    this is because, lispers usually do not have serious experience or
    investment
    in other functional langs, such as Mathematica, Haskell, etc.)

    One of the myth that are quickly embedded into budding lispers, is
    that cons
    are powerful. Powerful my ass. It is powerful in the sense any
    assembly lang
    is powerful. Lisp's cons is perhaps the greatest fuck up in the
    history of
    computer languages.

    Further readings:

    * Lisp's List Problem
    * My First Encounter And Impression Of Lisp
    * The Jargon “Lisp1” vs “Lisp2”

    Will Lisp ever be Popular?

    Mathematica today sells for over 2 thousands dollars. Its sales
    record,
    throughout its history, is probably more than ALL commercial lisps
    combined.
    Such a illuminating social fact, in not known in lisp communities.
    These
    fuckheads thinks that lisp is more popular.

    10 years ago, in the dot come days (~1998), where Java, Javascript,
    Perl are
    screaming the rounds. It was my opinion, that lisp will inevitably
    become
    popular in the future, simply due to its inherent superior design,
    simplicity,
    flexibility, power, whatever its existing problems may be. Now i don't
    think
    that'll ever happen as is. Because, due to the tremendous
    technological
    advances, in particular in communication (i.e. the internet and its
    consequences, e.g. Wikipedia, youtube, youporn, social networks sites,
    Instant
    chat, etc) computer languages are proliferating like never before.
    (i.e.
    because the abundance of tools, libraries, parsers, existance of
    infrastructure) New langs, basically will have all the advantages of
    lisps or
    lisp's fundamental concepts or principles. I see that, perhaps in the
    next
    decade, as communication technologies further hurl us forward, the
    proliferation of langs will reduce to a trend of consolidation (e.g.
    fueled by
    virtual machines such as Microsoft's .NET. (and, btw, the breaking of
    social
    taboo of cross communication led by Xah Lee)).

    There is one slight hope for Lisp the lang as we understood it, and
    that is
    emacs lisp. Due to, it being deeply rooted in the industry as a
    powerful text
    editor, and the embedded lisp have major practical impact in getting
    people to
    know lisp and also actually use it for practical need. (this
    satisfying
    prospect is however mar'd by the tech geekers. e.g. the Common
    Lispers, and
    Scheme Lispers, perennially inject snide and sneer at emacs lisp that
    harms
    its progress, while the fucking emacs priests, want to coffin emacs
    perpetually in its 1980s UI and terminologies.)

    Xah
    http://xahlee.org/



  2. Default some corrections Re: The Fundamental Problems of Lisp


    On Sun, 13 Jul 2008 07:53:38 -0700 (PDT), "xahlee@gmail.com" <xahlee@gmail.com> said:
    | ...
    | i.e. in elisp, there's no form of comments in matching delimiters
    | (and consequently no nested comment).

    That is not entirely true. XEmacs, at least, implements the `#+'
    syntax, which can be used to comment out well-formed S-expressions
    without relying on newlines, and such constructs do nest: if we
    start with

    (foo)
    (bar)
    (baz)
    (quux)

    then in

    (foo)
    #+(or) (
    (bar)
    (baz)
    )
    (quux)

    (FOO) and (BAR) are effectively commented out, and then in

    #+(or) (
    (foo)
    #+(or) (
    (bar)
    (baz)
    )
    (quux)
    )

    the whole thing is commented out.

    | ...
    | since the syntax is regular, one could easily have alternative,
    | easier to read syntaxes as a layer. (the concept is somewhat known
    | in early lisp as M-expression)

    M-expressions are not an "alternative syntax as a layer". Rather,
    they are an (abstract) algorithmic language, which can be translated
    into S-expressions as forms in the Lisp programming language.

    M-expressions make an extensive appearance in John Allen's
    _Anatomy of LISP_ (recommended reading whether or not the reader is
    interested in M-expressions). I don't have a good pointer to an
    Internet source (as of this writing, the Wikipedia article is not
    much to go by).

    ---Vassil.


    --
    Peius melius est. ---Ricardus Gabriel.

  3. Default Re: The Fundamental Problems of Lisp

    On Jul 13, 10:53am, "xah...@gmail.com" <xah...@gmail.com> wrote:
    > Fundamental Problems of Lisp
    >
    > Perm url:http://xahlee.org/UnixResource_dir/w..._problems.html
    >
    > plain text version follows.
    >


    > Will Lisp ever be Popular?
    >
    > Mathematica today sells for over 2 thousands dollars. Its sales
    > record,
    > throughout its history, is probably more than ALL commercial lisps
    > combined.


    You infer that Mathematica is popular due to its syntax as a
    programming language and ignore that it was the first user-friendly
    symbolic math system and gained its user base on that strength. Much
    of that base is people who are far more interested in the math than
    the programming language aspect. I'm neither a Lisp nor a Mathematica
    zealot. But I've used both. Mathematica has its own warts, and a
    long list of them at that, thought its good enough for what it does.
    As a general purpose programming language, it would be a failure.

  4. Default Re: The Fundamental Problems of Lisp

    xahlee@gmail.com breaking news:
    > Fundamental Problems of Lisp


    Xah, I love you, we should become friends!

    There seems to be no real contents in your postings, only some pseudo
    scientific Lisp bashing.
    Exactly the same art I'm specialized in.

    Congrats, keep up your good work! Together we will win them all!

    Jon Harrop

  5. Default Re: The Fundamental Problems of Lisp


    "xahlee@gmail.com" <xahlee@gmail.com> writes:

    Lisp relies on a regular nested syntax. However, the
    lisp syntax has several irregularities, that reduces
    such syntax's power and confuses the language
    semantics. (i.e. those «' # ; ` ,» chars.)

    I am not a lisp expert. My understanding is that the
    standard quote, as in 'foo is syntactic sugar for (quote
    foo), and that the correspondence is one-to-one. So you
    could, if you liked, simply write all your code without it.
    You could, of course, also write all your code without
    comments, as well. You might like using a more "pure" (so
    to speak) dialect of lisp than Common Lisp or even Emacs
    Lisp. I wish there was a port of Lisp 1 or Lisp 1.5
    available for common modern systems (is there?) to play
    with, but I do believe there a few lisps available based on
    such a model. Or perhaps you could write one.

    [...] in elisp, there's no form of comments in matching
    delimiters (and consequently no nested comment). The
    reliance on EOL chars as part of the syntax semantics is
    one of the major fuckup to the power of pure nested
    syntax.

    I don't know how the built-in documentation mechanism works,
    but I gather that it has to do with the fact that a defun
    only returns its last value. Maybe that concept could be
    extended to work with other embedded strings, as in:

    (defun foo (slaz)
    "This function grovels the slaz. Then returns t"
    (grovel slaz) "This is a comment"
    "This functions like a comment too."
    t)

    Of course this adds the comments to your lisp image, but
    then maybe it would allow for "literate programming" style
    practices. Maybe some of the most common operators could be
    programed to take an optional throw-away argument where you
    could plug in comments.

    But really, unless your purpose is to make those comments
    available in your image, what difference does it make? The
    comments are there for humans reading the code, so what
    difference does it make if EOL is made the comment end syntax?

    since the syntax is regular, one could easily have
    alternative, easier to read syntaxes as a layer. (the
    concept is somewhat known in early lisp as M-expression)

    It's debatable whether M syntax is easier to read than S
    syntax. But it is interesting that, that having been the
    initial intent of McCarthy et al, there was never enough
    motivation to actually implement it. Certainly I prefer
    lisp syntax to that of any other language I have dabbled
    with. And then I believe that a number of macro-based
    alternate syntaxa /have/ been implemented in lisp. (What is
    the plural of syntax, anyway?)

    One of the advantage of pure fully functional syntax is
    that a programer should never, ever need to format his
    source code (i.e. pressing tabs, returns) [\ldots]

    That sounds nice. I believe it is the CADR lisp machine
    (not sure) that I once played with (under QEMU, I believe)
    that had a nice feature that once you typed a final end
    parenthesis for a form, the form was evaluated without you
    having to hit enter. I implemented that for myself with
    slime a while back for fun. But that is really a REPL
    feature, not a language feature per se. Where your
    interface to the language interpreter is through an editor,
    as is obviously the case with Emacs lisp, it is arguable
    that code grinding or formatting or whatever it is called is
    an editor feature, not a language feature. Granted, the
    syntax of the language can make implementing that more or
    less difficult. Using EOL for comment ends makes having the
    editor parse it and reformat it more difficult, but I
    wouldn't think impossible.

    I guess my point is that it is not really possible (as I
    understand it) or convenient to build a programming language
    that is absolutely nothing but lambda calculus. You still
    need some things like an eval function, and a means of
    telling it when to evaluate code or not, and a way to embed
    comments in code, and so on. In order to be useful, the
    language has to solve some problems of a purely practical
    nature that aren't really part of the core concept of the
    language. I'm no language designer, so I readily admit I
    may not know what I'm talking about here. But having said
    that, there are automatic code formatters out there for
    languages like C; I would be surprised there are not for
    lisp, precisely because it /does/ have such a generally
    regular syntax.

    Lisp relies on a regular nested syntax. One of the power
    of such pure syntax is that you could build up layers on
    top of it, so that the source code can function as
    markup of conventional mathematical notations
    (i.e. LaTeX) and or as a word-processing-like file that
    can contain structures, images, yet lose practical
    nothing.

    I may not understand what you are saying here, but available
    for at least Common Lisp are packages that turn
    s-expressions into xml/html/sgml, etc, and into some kind of
    (La)TeX I believe.

    Lisp being historically based the cons for like 2 or 3
    decades. The cons (and cdr, car, caadar etc) are
    fundamentally rooted in the lisp langs, is thus not
    something that can be easily fixed. Quite
    unfortunate.

    It is not immediately obvious to me why cons is a bad
    thing. It's also not immediately obvious to my why it's a
    good thing, either, so I would be interested in exactly what
    it is that is bad about it.

  6. Default Re: some corrections Re: The Fundamental Problems of Lisp

    Vassil Nikolov <vnikolov+usenet@pobox.com> wrote:
    +---------------
    | That is not entirely true. XEmacs, at least, implements the `#+'
    | syntax, which can be used to comment out well-formed S-expressions...
    ....
    | #+(or) (
    | (bar)
    | (baz)
    | )
    | (FOO) and (BAR) are effectively commented out...
    +---------------

    Ever since a long-ago thread [in which Erik Naggum was an active
    participant, so that tells you how long ago it was!!] in which
    this style was presented as a better alternative to #+NIL [which
    can break if :NIL ever got onto *FEATURES*], I've found it rather
    distasteful -- *not* because there's anything technically "wrong"
    with it [there's not], but because of the cognitive dissonance of
    the "+" implying the exact *opposite* of what you're trying to do!!
    Ditto "#-(or)" to un-comment something -- flat-out backwards! So
    ever since then I've been using Erik's suggestion from that thread:

    #+(and) to *enable* an S-expression.

    #-(and) to "comment out" an S-expression.

    Now the "+"/enable and "-"/disable semantics line up:

    #-(and) ( ;turn off (BAR) & (BAZ)
    (bar)
    (baz)
    )

    Yes, using AND is one character longer than using OR, but
    reading it [by humans!] is simply more reliable.


    -Rob

    p.s. O.k., confession time: Even more recently I've started getting
    a bit lazy and using "#-+" to enable and "#+-" to comment out.
    My mnemonic is that "#-+" represents a "rising edge", that is,
    goes "from off to on" (enables), while the "falling edge" "#+-"
    goes "from on to off" (*dis*ables). Yes, it depends upon
    (INTERSECTION '(:+ :-) *FEATURES*) being NIL, but that's
    really, *really* unlikely to be violated.

    -----
    Rob Warnock <rpw3@rpw3.org>
    627 26th Avenue <URL:http://rpw3.org/>
    San Mateo, CA 94403 (650)572-2607


  7. Default Re: some corrections Re: The Fundamental Problems of Lisp


    On Sun, 13 Jul 2008 20:36:01 -0500, rpw3@rpw3.org (Rob Warnock) said:
    | ...
    | the cognitive dissonance of
    | the "+" implying the exact *opposite* of what you're trying to do!!
    | Ditto "#-(or)" to un-comment something -- flat-out backwards! So
    | ever since then I've been using Erik's suggestion from that thread:

    | #+(and) to *enable* an S-expression.

    | #-(and) to "comment out" an S-expression.

    | Now the "+"/enable and "-"/disable semantics line up:

    | #-(and) ( ;turn off (BAR) & (BAZ)
    | (bar)
    | (baz)
    | )

    | Yes, using AND is one character longer than using OR, but
    | reading it [by humans!] is simply more reliable.

    You may well be right that `#-(AND)' is cognitively safer; myself,
    not only had I forgotten that particular part about preferring
    `#-(AND)' to `#+(OR)', but I didn't perceive the plus sign as one
    for "adding" anything in this context, either, but applied the
    (private) mnemonic that the latter is like "'hash-sign' and 'or'",
    i.e. `#|'.

    (Until one starts perceiving this idiomatically, working out #-(AND)
    involves working out a double negation, of which I am not a
    particularly big fan, but that probably matters little. In other
    words, I'd prefer ``(WHEN false ...)'' (`#+(OR)') to ``(UNLESS true ...)''
    (`#-(AND)').)

    ---Vassil.

    P.S. Sadly, Erik Naggum will not be explaining how wrong I am (and I
    am not being sarcastic here).


    --
    Peius melius est. ---Ricardus Gabriel.

  8. Default Re: some corrections Re: The Fundamental Problems of Lisp

    Vassil Nikolov <vnikolov+usenet@pobox.com> writes:

    > On Sun, 13 Jul 2008 20:36:01 -0500, rpw3@rpw3.org (Rob Warnock) said:
    > | ...
    > | the cognitive dissonance of
    > | the "+" implying the exact *opposite* of what you're trying to do!!
    > | Ditto "#-(or)" to un-comment something -- flat-out backwards! So
    > | ever since then I've been using Erik's suggestion from that thread:
    >
    > | #+(and) to *enable* an S-expression.
    >
    > | #-(and) to "comment out" an S-expression.
    >
    > | Now the "+"/enable and "-"/disable semantics line up:
    >
    > | #-(and) ( ;turn off (BAR) & (BAZ)
    > | (bar)
    > | (baz)
    > | )
    >
    > | Yes, using AND is one character longer than using OR, but
    > | reading it [by humans!] is simply more reliable.
    >
    > You may well be right that `#-(AND)' is cognitively safer; myself,
    > not only had I forgotten that particular part about preferring
    > `#-(AND)' to `#+(OR)', but I didn't perceive the plus sign as one
    > for "adding" anything in this context, either, but applied the
    > (private) mnemonic that the latter is like "'hash-sign' and 'or'",
    > i.e. `#|'.
    >
    > (Until one starts perceiving this idiomatically, working out #-(AND)
    > involves working out a double negation, of which I am not a
    > particularly big fan, but that probably matters little. In other
    > words, I'd prefer ``(WHEN false ...)'' (`#+(OR)') to ``(UNLESS true ...)''


    You could also use:
    '(
    #+(and) x
    #+(not (and)) y
    )

    --
    __Pascal Bourguignon__ http://www.informatimago.com/

    "Remember, Information is not knowledge; Knowledge is not Wisdom;
    Wisdom is not truth; Truth is not beauty; Beauty is not love;
    Love is not music; Music is the best." -- Frank Zappa

  9. Default Re: some corrections Re: The Fundamental Problems of Lisp

    On Sun, 13 Jul 2008 20:36:01 -0500, Rob Warnock wrote:

    > Vassil Nikolov <vnikolov+usenet@pobox.com> wrote:
    > +---------------
    > | That is not entirely true. XEmacs, at least, implements the `#+'
    > | syntax, which can be used to comment out well-formed S-expressions...
    > ...
    > | #+(or) (
    > | (bar)
    > | (baz)
    > | )
    > | (FOO) and (BAR) are effectively commented out...
    > +---------------


    > Ever since a long-ago thread [in which Erik Naggum was an active
    > participant, so that tells you how long ago it was!!] in which
    > this style was presented as a better alternative to #+NIL [which
    > can break if :NIL ever got onto *FEATURES*], I've found it rather
    > distasteful -- *not* because there's anything technically "wrong"
    > with it [there's not], but because of the cognitive dissonance of
    > the "+" implying the exact *opposite* of what you're trying to do!!


    But it's not; #+(or) is like (when nil ...), which is exactly what I
    would write if I ever wanted to write that sort of thing; also, #+xxx
    is normally "special" (i.e., likely-to-be-disabled) case, so if you
    start using #-(and) and #+(and) you're suddenly reversing the normal
    sense of #+ and #- ... that's not good.

    > Yes, using AND is one character longer than using OR, but
    > reading it [by humans!] is simply more reliable.


    Not by this human!

    > p.s. O.k., confession time: Even more recently I've started getting
    > a bit lazy and using "#-+" to enable and "#+-" to comment out.


    At least it uses #+ the right way around


    --
    Tact is the ability to tell a man he has an open mind when he has a
    hole in his head.

    (setq reply-to
    (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

  10. Default Re: The Fundamental Problems of Lisp

    Xah Lee wrote:
    «
    Fundamental Problems of Lisp
    http://xahlee.org/UnixResource_dir/w..._problems.html
    »

    Jon Harrop wrote:
    > Xah, I love you, we should become friends!
    >
    > There seems to be no real contents in your postings, only some pseudo
    > scientific Lisp bashing.
    > Exactly the same art I'm specialized in.
    >
    > Congrats, keep up your good work! Together we will win them all!


    I must say, sometimes i lookup to your courage in frequent cross
    posting, even though i consider your posts are proper with respect to
    the various forum's explicit or implicit charters. (though, i do see
    your tendency to peddle your website, and freely inject your little
    personal gripes about Mathematica or whatever)

    When i cross post, and if my subject or opinion is controversial, and
    or my writting demeanor is to be non-conformal, i limit myself to
    maybe 1 post per week or month, as a matter of self-imposed discipline
    and respect for the larger community. I've been following this more or
    less since about 2004.

    And, when i post controversial or non-conformal ways, i made sure i
    spend great time on it. (1 or 2 hours is typical. 6 hours composition,
    broken into multiple days, is not unusual) I almost never, do a post
    that's trivial like just few lines. (i've been gradually relaxing this
    rule in recent years, however.)

    For example, some of these philosophies i've written publically before
    (often with the result of being ostracized from the community).

    • Philosophies of Netiquette
    http://xahlee.org/UnixResource_dir/w...etiquette.html

    • “Old School Netiquette (The traffic of Well-written vs One-liner
    posts)”
    http://xahlee.org/UnixResource_dir/w...etiquette.html

    My own dilemma in recent years, is whether i shall keep aloof with
    some sense of immaculateness in limiting sensitive posts to a few, yet
    persistent possibly until i die. Or, should i just “relax”,mix-in,
    adapt more of a every-body-is-a-friend writing style, and post
    profusely, like multiple posts per day, with just one or two line per
    post (like “thanks, but i don't agree.”), like them.

    The litanies of nagging has its powers.

    For example, in recent years i have spent great energy in emacs lisp.
    I spent several months out of my decade long keyboarding experience to
    have deviced a ergonomic shortcut for emacs (or any text editing tasks
    on computer keyboard). (been thinking of patent it) By my usual
    practice, i would put it on my web page (so it's public), make a
    announcement in appropriate forums once, and never speak of it again.
    The basic philosophy is that I, don't do peddling. If it is good, let
    people come to it. Marketing is a necessity, but its not something I,
    shall deign to do. Like, if Einstein invented relativity, and nobody
    belived it, that's their problem. History, will possibly eventually
    recognize good things, possibly a while after the inventor is dead.
    (long list of examples here... e.g. Dvorak keymap in our context.
    (btw, Richard Stallman, is somewhat aloof like this, however, he
    invented the the Gnu General Public (viral) License, Free Software
    Foundation, full-fledged with laws and lawers, which in the end made
    him and his ideas successful, as opposed to the huge number of free-
    spirited software such as BSDs etc. (Richard Stalman, also, freely
    abused English words such as “hacker”, “freedom”, to sell his
    ideas.)))

    But, i have second thoughts. Fame, power, leadership, seduces me. For
    example, instead of my aloof behavior, i could just be like a “normal”
    human animal. When i see people asking about difficult emacs
    keybindings in emacs forums, which happens frequently maybe at least
    once a month, i could just say, “hey, by chance i did this keymap. Try
    it out, maybe it'll help!”. And whenever i did minor update to my page
    about it, or have some minor thoughts about my keymap design, i'll
    just post: “hi guys, thanks a lot for previous feedback. Recently i've
    been thinking xyz design, what do you think?” Usually, the more
    trivial the question, the more numerous the reply. People, especially
    in modern society, in particular the tech geekers, are a very lonely
    bunch. They are EAGER to help, contribute their opinions. We NEED the
    emontional touch. (every book on friendship, leadership or politics,
    will tell you about the importance of establishing supporters) Also,
    avoid making a post that's more than, say, 2 short paragraphs long, or
    construct very logical sentences, or use big words. That makes you
    less approachable.

    I'm not sure Socrates or Plato would approve such relationship style.
    But by Allah, didn't Goddess Fortuna put Socrates to death by poison
    drinking?

    Ok, 2.5 hours went into this post. I shall make a stop and post what i
    have now, lest i become unapproachable.

    Xah
    http://xahlee.org/



+ Reply to Thread
Page 1 of 12 1 2 3 11 ... LastLast