Newbie questions 
Author Message
 Newbie questions

Quote:

> Oh, and while you're at it, why not define a standard parser for
> mathematical notation input.  Lots of people are used to mathematical
> notations and want to be able to program with them.

lisp has infix syntax.  while this may seem to be catering to the
machine, it is a small price to pay in order to reap the benefits of a
regular syntax.  (writing the reader/parser is easier with infix, but
that's not the reason for using it.)  you can make your own
`operators' (since they're all functions).  

C++ restricts you to overloading the existing set of operators or
making functions (which are infix in C++ too).  what if *two* (or
more) kinds of multiplication make sense?  e.g., let A and B be 3x3
matrices.  you might want to multiply them as matrices, or you may
wish to multiply element-wise.  matlab has * and .* operators to
handle this.  you can overload the * operator in C++ but good luck in
introducing a .* operator.  ok, so you make a function or cast the
matrices to element-wise beasts and * away on that.

so far it's just silly notations, but what happens when you want to
scale up and use templates or macros?  it is here that the
*everything* is infix in lisp that makes a big difference.  the
function/operator occupies the same slot (i.e., first in a list) no
matter what it does.  the lack of myriad special cases and syntax
contortions really pays off in the end since the macros can be more
ambitions in power and scope.

the annoymous functions and closures are also part of this.  it's not
a matter of namespace pollution so much as awkward syntax.  immagine a
C dialect in which you had no direct number constants, but were
obligated to first making a constant before you could use them.

instead of

   int x,y;

   ....

   y += x + 3

you had to do

   const int three = 3;
   int x,y;

   ....

   y += x + three;

it works the same.  but it's awkward.  the definition of three wanders
away from the point you need it.  and what if someone else made

   const double three = 3.0;

somewhere else?

why shouldn't you be able to just write a function in the same way you
can just stick in a regular number constant?  having to name every
function is just as tedious as having to name every numerical
constant.  it's exactly the same.

in C and C++, functions are very much second class citizens.  in lisp
they are bandied about just like any other kind of data.  this allows
a level of abstraction - you can program at a higher level.

in mathematical notation, you can just introduce a function.  many
times you operate on the functions as if they were mere elements.
consider, for example, functional analysis (to say nothing about more
esoteric abstraction such as you find in algebraic topology).

we could turn right around and ask of C++, why not define a standard
parser for mathematical notation input - like arbitrary functions.
Lots of people are used to mathematical notations - like functions -
and want to be able to program with them - just as easily as with
numbers or arrays of numbers.

--
johan kullstam



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> Ahem!  CLX?  Remember that in the beginning there were TWO
> implementations of X, C/Xlib and CL/CLX.

Weren't we talking about the server side of X?  Or have I again missed
something important?

Regs, Pierre.

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:


> > Well Bagheera didn't state the problem quite right.  The overall
> > point is that type checking saves you from tons and tons of late
> > night typos and logic errors.

> Nothing in CL forbids you from type-declaring every variable. Knock
> yourself out.  Don't forget to send bug reports when the compiler
> fails to use them well or flag problems, so your vendor will know
> you care.

It is true that one cannot fault the language for this. Nevertheless,
until vendors listen to and act on these 'bug reports' the problem
persists in practise. I agree strongly with Joshua that lack of static
type checking is one on the main disadvantages of (at least) the
commercial Common Lisp implementation I am familiar with.

Quote:
> But the language itself already supports this.  It's simply up to
> the market to decide if this is what stands between it and
> success. I doubt it is, but you're welcome to make the case
> otherwise.

Well, I tend to disagree. Adding static type checking (optional of
course) would go a long way towards convincing experienced C++/Java
programmers to take another look at Lisp. Of course, I can be certain
only about my own opinion, others may disagree. I have heard a
representative of a Lisp vendor seriously argue that Lisp code must
look as simple as Java code to be competitive. IMHO, static type
checking is an order of magnitude more important than that. :-)

Quote:
> I won't try to tell you not to write declarations if you won't try
> to tell me that I must write them.

Sure, there is no need to take away this flexibility.

Quote:
> > In code that rarely runs or isn't expected to run under
> > normal conditions, this sort of correctness checking is very
> > important.

> You don't say what your point is.

The point is probably this: A C++/Java compiler cannot catch all
errors, especially not design or logical errors, but at least it
catches most simple errors like typos, passing the wrong number of
arguments, passing a wrong argument, etc.  With existing Lisp
implementations many such errors are detected only at runtime even
when declarations are used. This is less problematic with mainline
code which is likely to be run by the developer anyway, but typos in
sections of the source code that are less frequently run have the
habit of crashing in the hands of a user, or the QA department if
you're lucky. Yes, you should test all your code, but the kind of bug
we're talking about is often introduced by changes that are so
'obvious' that many developers don't imagine a bug may have been
introduced.

Joachim

--




Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> > > Well Bagheera didn't state the problem quite right.  The overall
> > > point is that type checking saves you from tons and tons of late
> > > night typos and logic errors.

> > Nothing in CL forbids you from type-declaring every variable. Knock
> > yourself out.  Don't forget to send bug reports when the compiler
> > fails to use them well or flag problems, so your vendor will know
> > you care.

> It is true that one cannot fault the language for this. Nevertheless,
> until vendors listen to and act on these 'bug reports' the problem
> persists in practise. I agree strongly with Joshua that lack of static
> type checking is one on the main disadvantages of (at least) the
> commercial Common Lisp implementation I am familiar with.

Then you should use the power of the marketplace.  If you cannot get
enough people together to say that this is more important than other
things, then perhaps it is not.  I mean this seriously.  It is very
easy for people to complain about things CL doesn't do.  I believe it
is helpful if you make a list of the things that are promised in the
next release of your favorite vendor and tell the vendor your decision
to purchase future copies is premised on their doing this thing
instead of something they've promised.  I think most people either say
this and then purchase anyway (meaning they weren't really serious) or
aren't willing to say what they'd give up (meaning they think the
system has infinite resources).

Quote:
> > But the language itself already supports this.  It's simply up to
> > the market to decide if this is what stands between it and
> > success. I doubt it is, but you're welcome to make the case
> > otherwise.

> Well, I tend to disagree. Adding static type checking (optional of
> course) would go a long way towards convincing experienced C++/Java
> programmers to take another look at Lisp.

I really honestly and not facetiously think that if you believe this with
certainty, then you might consider getting a Lisp and putting your own
money and reputation on the line over this.  Because the Lisp vendors are
doing this day in and day out, and they do not casually assign their
resources away from the thing you describe.  They might be wrong, of course,
but if you really believe that there is a time-tested way to demonstrate
that.

Thought:

 Nothing in the world is "important" or "unimportant".
 Things are only "more important" and "less important" than other things.
 Say what you think is less important and you'll know what your leverage
 is to get this so-called more important thing.

Quote:
> Of course, I can be certain
> only about my own opinion, others may disagree. I have heard a
> representative of a Lisp vendor seriously argue that Lisp code must
> look as simple as Java code to be competitive. IMHO, static type
> checking is an order of magnitude more important than that. :-)

So you mean you'd pay an order of magnitude more money?  Or what do
you mean by that?

Quote:
> > I won't try to tell you not to write declarations if you won't try
> > to tell me that I must write them.

> Sure, there is no need to take away this flexibility.

> > > In code that rarely runs or isn't expected to run under
> > > normal conditions, this sort of correctness checking is very
> > > important.

> > You don't say what your point is.

> The point is probably this: A C++/Java compiler cannot catch all
> errors, especially not design or logical errors, but at least it
> catches most simple errors like typos, passing the wrong number of
> arguments, passing a wrong argument, etc.  With existing Lisp
> implementations many such errors are detected only at runtime even
> when declarations are used. This is less problematic with mainline
> code which is likely to be run by the developer anyway, but typos in
> sections of the source code that are less frequently run have the
> habit of crashing in the hands of a user, or the QA department if
> you're lucky. Yes, you should test all your code, but the kind of bug
> we're talking about is often introduced by changes that are so
> 'obvious' that many developers don't imagine a bug may have been
> introduced.

Then maybe you should switch vendors.  Tell other vendors that's what
it would take to get you to swtich.  But making this checking a
requirement of the language would just mean there are fewer
implementations (since it would define some implementations not to be
valid).  It would not suddenly create more resources to do these
changes.  Standards are about codifying de facto practice, not about
forcing practice.  The marketplace is where to make your feelings
known, either as a choosy purchaser or an aggressive vendor with a
vision.  If you are willing to be neither, then I suggest you might
ask yourself what it means to say you hold these beliefs strongly.  If
you think you are being one of those things (probably the choosy
customer) and you are finding it doesn't help, then perhaps you should
think about how to create a customer organization that better
represents your market segment, or think about whether there are
enough people for you really to be a market segment.

Markets are elusive.  Just because you can't prove one is there doesn't
mean it's not--I'm not saying it's an easy business.  But what I'm saying
is that wishing as you are doing doesn't make it so.  The game is all
about resources.  What resources vendors have and what products people give
financial resources in exchange for.  If you don't affect that, you will
affect nothing.  That is how markets work (and don't).

I apologize for the somewhat strained tone of this message.  I don't
mean to jump on you personally.  But this is kind of an exemplar of
something I hear from people from time to time that I never quite get
around to responding to and this was a good chance.



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> Then you should use the power of the marketplace.

Agreed. By posting my opinion about this matter I hope to influence my
current vendor who may have an interest in my continued interest in
their product, as well as my vendor's competitors who may want to get
my business.

Quote:
> If you cannot get enough people together to say that this is more
> important than other things, then perhaps it is not.

Certainly. But this is no reason to refrain form expressing ones
opinion.

Quote:
> I mean this seriously. It is very easy for people to complain about
> things CL doesn't do.

Well, sorry for coming across as somebody who is whining. I am
critical of all programming languages that I've come across so
far. This doesn't mean one can't get work done with them. But being
able to get work done with a programming language is also no reason
not to try improving it (or its implementations). I am currently using
Lisp and appreciate its advantages. Don't see why I should not express
my opinion about its weaknesses.

Quote:
> > I have heard a representative of a Lisp vendor seriously argue
> > that Lisp code must look as simple as Java code to be
> > competitive. IMHO, static type checking is an order of magnitude
> > more important than that. :-)
> So you mean you'd pay an order of magnitude more money?  Or what do
> you mean by that?

The decision to use Lisp, and to pay money for an implementation and
how much, wasn't for me to make in this case. In any case I am talking
here about mindshare. How can Lisp grow its user base? This is not
simply a question of who is willing to pay how much for which
features. It is more a question of how many potential developers are
comfortable with the idea of developing in Lisp. The static typing
issue is important in my opinion, others may disagree.

Quote:
> I apologize for the somewhat strained tone of this message.

No need to apologize, your response contained useful thoughts and was
quite civilized. But if I may say so, the same can't be said about
certain other posters in this thread. This is another point which can
easily put off some developers from considering a non-mainstream
language like Lisp. In C++ newsgroups one can have serious discussions
about possible language improvements, here one is attacked and called
an 'ignorant newbie' and worse names. Of course, one cannot blame the
language for this either... :-)

Joachim

--




Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

    Joachim> persists in practise. I agree strongly with Joshua that lack of static
    Joachim> type checking is one on the main disadvantages of (at least) the
    Joachim> commercial Common Lisp implementation I am familiar with.

Get another implementation?  I'm not that familiar with commercial
implementations on this topic, but certainly CMUCL can do a lot of
static type checking, roughly equivalent to any C/C++ compiler, and,
in some ways, a lot more.

    Joachim> Well, I tend to disagree. Adding static type checking (optional of
    Joachim> course) would go a long way towards convincing experienced C++/Java
    Joachim> programmers to take another look at Lisp. Of course, I can be certain
    Joachim> only about my own opinion, others may disagree. I have heard a

I always thought C++/Java programmers were turned off by the syntax,
not the lack of type checking.  As a C/C++ programmer, I rather enjoy
not having to type everything when writing in Lisp.

    Joachim> arguments, passing a wrong argument, etc.  With existing Lisp
    Joachim> implementations many such errors are detected only at runtime even
    Joachim> when declarations are used. This is less problematic with mainline

Get a better implementation?

    Joachim> you're lucky. Yes, you should test all your code, but the kind of bug
    Joachim> we're talking about is often introduced by changes that are so
    Joachim> 'obvious' that many developers don't imagine a bug may have been
    Joachim> introduced.

I would say your software engineering process is broken in this case,
and no language will protect you from this kind of problem.

Ray



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions


Quote:

>    Joachim> you're lucky. Yes, you should test all your code, but the kind of bug
>    Joachim> we're talking about is often introduced by changes that are so
>    Joachim> 'obvious' that many developers don't imagine a bug may have been
>    Joachim> introduced.

It's not about 'obviousness' so much as pressure an lack of time.

Quote:
>I would say your software engineering process is broken in this case,

Welcome to the real world.  The only time I've ever seen an office
where the programmers had all the time they needed for designing,
documenting, debugging and other 'engineering' process tasks was in a
government job.  But then I work in the games industry which is
entertainment after all - flakiness and ego are expected to be main
ingredients of both management and engineering here.  Not that I'm
complaining - for one thing I fit right in :)

Quote:
>and no language will protect you from this kind of problem.

>Ray

Oh, a language can help by making testing less necessary.  It's a good
thing for it to be doing in any case.

Joshua Scholar



Sun, 21 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])
On Wed, 05 May 1999 22:14:08 GMT, Joachim Achtzehnter

Quote:

>here about mindshare. How can Lisp grow its user base? This is not
>simply a question of who is willing to pay how much for which
>features. It is more a question of how many potential developers are
>comfortable with the idea of developing in Lisp. The static typing
>issue is important in my opinion, others may disagree.

I'm one of those who disagree.  I've talked to a lot of
people about Lisp, and about the possibility of using
it in place of languages such as C++.  None of them
ever mentioned static type checking to me as one of
their reasons for rejecting Lisp.  The overwhelmingly
most common reason is the perception that Lisp is a
special purpose language for academic projects where
efficiency doesn't matter.


Sun, 21 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])


Quote:
>On Wed, 05 May 1999 22:14:08 GMT, Joachim Achtzehnter

>>here about mindshare. How can Lisp grow its user base? This is not
>>simply a question of who is willing to pay how much for which
>>features. It is more a question of how many potential developers are
>>comfortable with the idea of developing in Lisp. The static typing
>>issue is important in my opinion, others may disagree.

>I'm one of those who disagree.  I've talked to a lot of
>people about Lisp, and about the possibility of using
>it in place of languages such as C++.  None of them
>ever mentioned static type checking to me as one of
>their reasons for rejecting Lisp.  The overwhelmingly
>most common reason is the perception that Lisp is a
>special purpose language for academic projects where
>efficiency doesn't matter.

This is like the old parable about measuring the Emperor's nose.  No
one has ever seen the Emperor, so any one person's opinion about the
length of his nose has no significance.  The joke is that you try gain
significance by averaging the answers of many people.

I have actual reasons for not being able to use Lisp and you're saying
those reasons are not important because the average programmer (who's
ignorance of what compilers can do is apparently greater than mine)
gives different reasons.  

So I'd think a better question than why people who don't know anything
about modern Lisp systems don't use them would be, what do Lisp
systems need in order to be useful to everyone who does know about
them.

There is nothing wrong with a Lisp being unsuited for many companies
except that the language could change so that it covers all needs.

Joshua Scholar



Mon, 22 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

| Welcome to the real world.  The only time I've ever seen an office where
| the programmers had all the time they needed for designing, documenting,
| debugging and other 'engineering' process tasks was in a government job.

  I love it when people think theirs is the only corner of the world that
  is worthy of the trademark Real World.  one usually doesn't need any more
  evidence to discard people than that.

  I have had the opportunity to do everything I have wanted to do for my
  client, and have been able to spend all the time I have wanted on what I
  think is important to the end goal: that I shall be able to leave the
  project and it shall continue to be operational for a long time to come.
  only when my management has decided on some particular deadline for some
  particular feature has this idyllic image been disturbed.  this is not a
  government project -- it's a financial news agency's distribution system,
  where we care more about accuracy and fault tolerance than anything else.

#:Erik



Mon, 22 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

+---------------
| lisp has infix syntax.
+---------------

I think you meant to say, "Lisp has PREFIX syntax".

(At least, I *hope* that's what you meant to say...)

-Rob

-----

Applied Networking              http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.          Phone: 650-933-1673
1600 Amphitheatre Pkwy.         FAX: 650-933-0511
Mountain View, CA  94043        PP-ASEL-IA



Mon, 22 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:


> +---------------
> | lisp has infix syntax.
> +---------------

> I think you meant to say, "Lisp has PREFIX syntax".

> (At least, I *hope* that's what you meant to say...)

I believe I remember seeing someone use an infix syntax package (in
this group?) and it looked something like #I(2 + foo * pi ...).

Christopher



Mon, 22 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software