>> > Expressing algorithms in a language that doesn't provide any
>> > metaprogramming facilities is still considered programming, so why
>> > shouldn't it be considered programming if you do exactly the same in
>> > Lisp?
>> programming, yes; lisp programming, no.
>> Should someone who cannot write his own classes be considered a
>> competent C++ programmer? Should someone who doesn't know how to
>> process text files with Perl be considered a competent Perl programmer?
>> I don't think so even though it's perfectly possible to express some
>> algorithms without writing one's own classes or processing text files.
> Writing significant macros is not at the same level as writing classes
> or processing files. It's comparable to writing templates in C++, or
> dynamic proxies in Java, or - I'm sure even if I don't know Haskell -
> some complex monadic thing in Haskell. I.e. stuff that experts use
> when needed, but that juniors are not expected to know. One can be a C+
> + programmer even if he doesn't write templates - not an expert C++
> programmer, but still. Why Lisp should be different?
Because that's the point of lisp, being a homoiconic meta programming
programming language, to use the exact same language to meta program as
to program. Contrarily to C++ where the template language is completely
different from the base C++ language.
Writing significant macros is exactly at the same level as writing
classes or processing files. All macros can be written as:
(defmacro example (&rest arguments)
(generate-example arguments))
with generate-example being just a norma lisp function, that takes in a
list whatever argument the macro takes, and that returns a lisp form
(which is a mere lisp sexp).
Therefore there is absolutely no (technical) difficuly in writing lisp
macro, and anybody who calls himself lisp programmer should be able to
write lisp macros. And vice-versa, anybody who's unable to write a lisp
macro, just is not a lisp programmer.
* Pascal Costanza <9deog9Fdv...@mid.individual.net> :
Wrote on Thu, 15 Sep 2011 18:47:05 +0200:
| On 14/09/2011 23:13, Tim Bradshaw wrote:
|> On 2011-09-14 18:36:22 +0100, Alessio Stalla said:
|>
|>> And what's wrong with that?
|>
|> Nothing. I'd just rather such people call themselves Lisp users not
|> programmers, as I call myself a microprocessor user not designer.
|
| Programming has different complexity levels. Expressing algorithms in
| a language that doesn't provide any metaprogramming facilities is
| still considered programming, so why shouldn't it be considered
| programming if you do exactly the same in Lisp?
The OP does not seem to understand the basic "code is data" concept that
facilitates macro programming in Common Lisp. There is nothing
analogous to this concept in microprocessors, which leads to the faulty
conclusion expressed above.
> The OP does not seem to understand the basic "code is data" concept that
> facilitates macro programming in Common Lisp. There is nothing
> analogous to this concept in microprocessors, which leads to the faulty
> conclusion expressed above.
Programming in Lisp without writing macros is more like using an FPGA.
Lisp programming is *programming* the FPGA. In fact, Lisp kind of is the FPGA of programming languages.
> Eric Wolf <e...@boese-wolf.eu> writes:
[...]
>> therefore each employee must be fungible.
>> It would be irresponsible to depend the existence of a company (and
>> therefore the jobs of the other employees) on a single employee. (Thats
>> what it means having a not fungible employee.)
... So, the big risk companies have to proactively figth is that of a fungible employee becoming not fungible >-!
> I don't think the article said otherwise.
> It established: F ⇒ ¬ L
> You are saying: C ⇒ F
> Therefore: C ⇒ ¬ L
> which is what we are observing, > and what the article explained:
> No lisp in companies.
There is of course one way off the whole problem : teaching.
But in that process of leaving companies
you all forgot the terminating case, viz that of a single man company ; if he decides to leave nobody will be unconvenienced not even him since it is its own decision.
Morale : Lisp is for singletons. But there is more
[1]> (defun randbool () (= 0 (random 2)))
(defmacro either (x &optional y) `(if (randbool) ,x ,y))
(defparameter employee_count 0)
(defun leaving_process (is_fungible) (decf employee_count)
(case employee_count (-1 (cerror "one employee will enter and a 0 count shall be restaured." "") (incf employee_count))
(0 "Wasn't much company then in this company, but then again nobody was ever unhappy of anybody leaving.")
(t (princ (case is_fungible ('fungible "Bye! ")
('not_fungible "Grr! ")))
(either (incf employee_count))
(leaving_process (either 'fungible 'not_fungible)))))
RANDBOOL
[2]> EITHER
[3]> EMPLOYEE_COUNT
[4]> LEAVING_PROCESS
[5]> "First see how a singleton company is no place for discontent."
(setf employee_count 1)
(leaving_process 'not_fungible)
[7]> "Wasn't much company then in this company, but then again nobody was ever unhappy of anybody leaving."
[8]> "Second, see how a non singleton campany is a place for discontent and how it is deemed to end as a singleton company."
(setf employee_count 11)
(leaving_process 'fungible)
[10]> Bye! Grr! Bye! Grr! Grr! Grr! Grr! Bye! Grr! Bye! Grr! Bye! Grr! Bye! Grr! Grr! Bye! Bye! Grr! Grr! "Wasn't much company then in this company, but then again nobody was ever unhappy of anybody leaving."
And since Lisp is for singleton ...
-- Take it Easy Don't Hurry Be Happy
Thierry
I see conses within conses. - Third stage guild navigator.
> On 2011-09-15 16:47:05 +0000, Pascal Costanza said:
>> Expressing algorithms in a language that doesn't provide any
>> metaprogramming facilities is still considered programming, so why
>> shouldn't it be considered programming if you do exactly the same in
>> Lisp?
> programming, yes; lisp programming, no.
> Should someone who cannot write his own classes be considered a
> competent C++ programmer? Should someone who doesn't know how to process
> text files with Perl be considered a competent Perl programmer? I don't
> think so even though it's perfectly possible to express some algorithms
> without writing one's own classes or processing text files.
> If one doesn't have any competence in the distinguishing feature of a
> language one can't claim to be a competent programmer in that language,
> even though one may know how to express algorithms in some proper subset
> of that language.
You're not playing a fair game here. ;) You suddenly added the adjective 'competent'...
