Lisp HUG Maillist Archive

Sadness in my heart...

Hi All,

Since last August, I have been using a tool called PixInsight quite regularly. Perhaps some of you are familiar with it. It is an image processing tool, meant for reduction of stacks of astronomical images, to produce visual results. It is quite an elegant tool, written by an outstanding group of astronomers in Spain, and provides access to some of the most recent and powerful processing concepts - MURE denoising, wavelet transform filtering, etc. It is also largely open source. Non-scientists often describe PixInsight as having a vertical learning curve. But I take to it like a fish to water. I love it… almost...

But what saddens me deeply is that this brilliant crew spent so many hours slaving away in C++ and providing a JavaScript API at the user level for extensions. Their code is quite brilliant, but the system could have been written with far less effort, and made far more powerful at the user extension level, had they chosen to do their system in a Lisp.

It is shocking to see such bright minds ignorant of programming.

just my 2c…

- DM


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Hello David,

2016-04-27 18:51 GMT+03:00 David McClain <dbm@refined-audiometrics.com>:

Hi All,

Since last August, I have been using a tool called PixInsight quite regularly. Perhaps some of you are familiar with it. It is an image processing tool, meant for reduction of stacks of astronomical images, to produce visual results. It is quite an elegant tool, written by an outstanding group of astronomers in Spain, and provides access to some of the most recent and powerful processing concepts - MURE denoising, wavelet transform filtering, etc.. It is also largely open source. Non-scientists often describe PixInsight as having a vertical learning curve. But I take to it like a fish to water. I love it… almost...

But what saddens me deeply is that this brilliant crew spent so many hours slaving away in C++ and providing a JavaScript API at the user level for extensions. Their code is quite brilliant, but the system could have been written with far less effort, and made far more powerful at the user extension level, had they chosen to do their system in a Lisp.

It is shocking to see such bright minds ignorant of programming.

just my 2c…
Do you have any rationale for why so?

Re: Sadness in my heart...

David McClain <dbm@refined-audiometrics.com> writes:
> But what saddens me deeply is that this brilliant crew spent so many
> hours slaving away in C++ and providing a JavaScript API at the user
> level for extensions. 

Granted.

However since they already provide an API using JavaScript, it should be
rather easy to hook it with ECL (if it's an application, libecl.so) to
replace JavaScript, so at least you could use this system from Common
Lisp.

Then, as a C++ program you could integrate it with clasp, and then be
able to access the internal C++ classes in Common Lisp (if you wanted to
extend or further maintain the program).


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

David McClain <dbm@refined-audiometrics.com> writes:

> I have been toying with the idea of recreating it in Lisp. But I
> haven’t yet embarked on it.

And yes, of course, there's always this option.

And if you can provide a postmortem such as:

   rewrote alone in CL a system written by 100 C++ programmers in 1/100
   the time, and has more features and is more maintainable.

that'd be even better to popularize Common Lisp ;-) ;-)

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...


> On Apr 27, 2016, at 1:14 PM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> 
> 
> David McClain <dbm@refined-audiometrics.com> writes:
> 
>> I have been toying with the idea of recreating it in Lisp. But I
>> haven’t yet embarked on it.
> 
> And yes, of course, there's always this option.
> 
> And if you can provide a postmortem such as:
> 
>   rewrote alone in CL a system written by 100 C++ programmers in 1/100
>   the time, and has more features and is more maintainable.
> 
> that'd be even better to popularize Common Lisp ;-) ;-)

I wonder how well this works.

I’ve had a couple of experiences of working on large software projects where a smaller team using Lisp produced comparable or better results than a larger team using C or C++. There was little or no sign that the results persuaded anyone of anything.

I suspect that people’s language preferences tend to trump measurements of productivity.



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Language preferences trump reason and resourcefulness. In case anyone hasn't read Paul Graham's essay on this topic, here is the link: http://www.paulgraham.com/avg.html

On Wed, Apr 27, 2016 at 3:39 PM mikel evins <mevins@me.com> wrote:


> On Apr 27, 2016, at 1:14 PM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>
>
> David McClain <dbm@refined-audiometrics.com> writes:
>
>> I have been toying with the idea of recreating it in Lisp. But I
>> haven’t yet embarked on it.
>
> And yes, of course, there's always this option.
>
> And if you can provide a postmortem such as:
>
>   rewrote alone in CL a system written by 100 C++ programmers in 1/100
>   the time, and has more features and is more maintainable.
>
> that'd be even better to popularize Common Lisp ;-) ;-)

I wonder how well this works.

I’ve had a couple of experiences of working on large software projects where a smaller team using Lisp produced comparable or better results than a larger team using C or C++. There was little or no sign that the results persuaded anyone of anything.

I suspect that people’s language preferences tend to trump measurements of productivity.



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html

Re: Sadness in my heart...

mikel evins <mevins@me.com> writes:

> I wonder how well this works.
>
> I’ve had a couple of experiences of working on large software projects
> where a smaller team using Lisp produced comparable or better results
> than a larger team using C or C++. There was little or no sign that
> the results persuaded anyone of anything.

Perhaps you could document them on http://cliki.net/Performance (or a
subpage or link)?

> I suspect that people’s language preferences tend to trump measurements of productivity.

Possible.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...


> On Apr 27, 2016, at 2:50 PM, Michael Bentley <michael@stray-labs.com> wrote:
> 
> On one of those projects (or so I assume) I was persuaded that Common Lisp, though an amazing lever, should not be the sole reason for taking a job.
> 

If you’re talking about the product we both worked on, it isn’t one of the ones I meant. As far as I know, Lisp was always the only candidate for building that product—and, as you know, it performed like a champ.

But sure, you can’t conclude just from that fact that a company uses Lisp (or any other specific technology) that it is therefore a great place to work.



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...


> On Apr 27, 2016, at 2:52 PM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> 
> 
> mikel evins <mevins@me.com> writes:
> 
>> I wonder how well this works.
>> 
>> I’ve had a couple of experiences of working on large software projects
>> where a smaller team using Lisp produced comparable or better results
>> than a larger team using C or C++. There was little or no sign that
>> the results persuaded anyone of anything.
> 
> Perhaps you could document them on http://cliki.net/Performance (or a
> subpage or link)?

I’m not sure I want to. I’ve had those discussions ad infinitum, and in my experience they generate a lot of heat and very little light.



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...



2016-04-27 19:16 GMT+03:00 David McClain <dbm@refined-audiometrics.com>:
Why (what?) so? Ignorance of programming among brilliant scientists? Choice of JavaScript for user API? Writing it in C++?
I'm dubious that they don't know about Lisp. But they wrote in C++, and I'm curious
why so many software written in C++?..
Some articles describe how it nice to use both Lisp and C++, e.g..
http://franz.com/resources/educational_resources/clos_versus_other/cpp.lhtml

I'm working now on C++14 client library for PostgreSQL and plans to finish soon. And
I'm thinking about C API for FFI to call from other languages, including Lisp with hope
to be more productive. But I am not sure whether Lisp will solve my existing problems
related with C++, or will add new.

Re: Sadness in my heart...

mikel evins <mevins@me.com> writes:

>> On Apr 27, 2016, at 2:50 PM, Michael Bentley <michael@stray-labs.com> wrote:
>> 
>> On one of those projects (or so I assume) I was persuaded that
>> Common Lisp, though an amazing lever, should not be the sole reason
>> for taking a job.
>> 
>
> If you’re talking about the product we both worked on, it isn’t one of
> the ones I meant. As far as I know, Lisp was always the only candidate
> for building that product—and, as you know, it performed like a champ.
>
> But sure, you can’t conclude just from that fact that a company uses
> Lisp (or any other specific technology) that it is therefore a great
> place to work.

But the greatness of a workplace is not a scalar; being a lisp shop,
can compensate other dimensions.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Dmitry Igrishin <dfigrish@gmail.com> writes:

> 2016-04-27 19:16 GMT+03:00 David McClain
> <dbm@refined-audiometrics.com>:
>
>     Why (what?) so? Ignorance of programming among brilliant
>     scientists? Choice of JavaScript for user API? Writing it in C++?
>
> I'm dubious that they don't know about Lisp. But they wrote in C++,
> and I'm curious
> why so many software written in C++?..

The historical reason, being the "Object Oriented Successor of C".  (Also
some ad hominem reason, being developped at AT&T just like C, compared to
eg. Objective-C which was developped independently).

In any case, todays it's even more ironic, when so many people have come
to see Object Oriented Programming in a rather bad light.  (And then,
even "Agile" is dead, fads pass so fast nowadays…).



-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...


> On Apr 27, 2016, at 4:30 PM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> 
> 
> mikel evins <mevins@me.com> writes:
> 
>>> On Apr 27, 2016, at 2:50 PM, Michael Bentley <michael@stray-labs.com> wrote:
>>> 
>>> On one of those projects (or so I assume) I was persuaded that
>>> Common Lisp, though an amazing lever, should not be the sole reason
>>> for taking a job.
>>> 
>> 
>> If you’re talking about the product we both worked on, it isn’t one of
>> the ones I meant. As far as I know, Lisp was always the only candidate
>> for building that product—and, as you know, it performed like a champ.
>> 
>> But sure, you can’t conclude just from that fact that a company uses
>> Lisp (or any other specific technology) that it is therefore a great
>> place to work.
> 
> But the greatness of a workplace is not a scalar; being a lisp shop,
> can compensate other dimensions.

Only up to a point. There are existence proofs that the point can be exceeded.



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Hi,

I guess because they knew C++ on a level to be productive enough? They
have had a task and an instrument to solve this task. If they had
chosen CL, they would have been having not only the task but to get a
proficiency in CL as well.

CL is not a simple language and certainly not a smallest one, so instead
of spending a time on a new (huge) language they just concentrated on a
task. 

Why didn't they know CL beforehand? That is another question..

David McClain <dbm@refined-audiometrics.com> writes:

> Hi All,
>
> Since last August, I have been using a tool called PixInsight quite
> regularly. Perhaps some of you are familiar with it. It is an image processing
> tool, meant for reduction of stacks of astronomical images, to produce visual
> results. It is quite an elegant tool, written by an outstanding group of
> astronomers in Spain, and provides access to some of the most recent and
> powerful processing concepts - MURE denoising, wavelet transform filtering,
> etc. It is also largely open source. Non-scientists often describe PixInsight as
> having a vertical learning curve. But I take to it like a fish to water.. I love
> it… almost...
>
> But what saddens me deeply is that this brilliant crew spent so many hours
> slaving away in C++ and providing a JavaScript API at the user level for
> extensions. Their code is quite brilliant, but the system could have been
> written with far less effort, and made far more powerful at the user extension
> level, had they chosen to do their system in a Lisp.
>
> It is shocking to see such bright minds ignorant of programming.
>
> just my 2c…
>
> - DM
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
>

-- 
Br,
/Alexey

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Sadly, after 30+ years of thinking about programming, I’ve come to conclusion that the hatred for Lisp is due to …

Syntax.

99.999% of “programmers” think that they need to have a “structured” syntax.

Lisp is essentially a syntax-less language.  A bunch of concrete parse trees.  A high level assembler.

For me, Lisp is the back-end of a compiler, after the syntax has been stripped off.

I wrote ‘paraphrase' (experimental) https://github.com/guitarvydas/paraphrase to show that just about any syntax can be grafted onto Lisp.

I enjoy the freedom of writing in a high-level assembler.

Apparently, most programmers cannot handle this concept.

pt



> On Apr 27, 2016, at 11:51 AM, David McClain <dbm@refined-audiometrics.com> wrote:
> 
> 
> Hi All,
> 
> Since last August, I have been using a tool called PixInsight quite regularly. Perhaps some of you are familiar with it. It is an image processing tool, meant for reduction of stacks of astronomical images, to produce visual results. It is quite an elegant tool, written by an outstanding group of astronomers in Spain, and provides access to some of the most recent and powerful processing concepts - MURE denoising, wavelet transform filtering, etc. It is also largely open source. Non-scientists often describe PixInsight as having a vertical learning curve. But I take to it like a fish to water. I love it… almost...
> 
> But what saddens me deeply is that this brilliant crew spent so many hours slaving away in C++ and providing a JavaScript API at the user level for extensions. Their code is quite brilliant, but the system could have been written with far less effort, and made far more powerful at the user extension level, had they chosen to do their system in a Lisp.
> 
> It is shocking to see such bright minds ignorant of programming.
> 
> just my 2c…
> 
> - DM
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


RE: Sadness in my heart...

An interesting thread ...

My issue is the lack of an inexpensive (better: "FREE") robust Lisp environment/compiler where I can write and deliver programs for the little projects I do now for myself and a few others.

So, for what I have written recently, the Community version of Visual Studio is inexpensive (i.e., FREE!) and *works* well ... because these projects cannot justify my paying for a robust Lisp development system.

For this purpose, the $1500 cost of the 64-bit HobbyistDV edition is ridiculous, IMHO. 

And 64-bit Hobbyist is unusable because of the lack of a "deliver" function (momentarily ignoring the $750 cost). See http://www.lispworks.com/buy/prices-1h.html ...

My point is that Microsoft's Visual Studio Community edition _works_ for my needs (to distribute free programs for myself and a few others) ... LispWorks simply does *not*. I don't know of another robust Lisp environment that I _could_ use.

As a result, my programs are now all in C and C++ ... even though I would _much_ rather program in Lisp, of course! Till somebody makes a robust FREE delivery environment for Lisp, with free run-times delivery, this will remain the case.

Z

> -----Original Message-----
> From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-
> hug@lispworks.com] On Behalf Of Paul Tarvydas
> Sent: Wednesday, April 27, 2016 05:17 PM
> To: David McClain <dbm@refined-audiometrics.com>
> Cc: LispWorks <lisp-hug@lispworks.com>
> Subject: Re: Sadness in my heart...
> 
> 
> Sadly, after 30+ years of thinking about programming, I’ve come to
> conclusion that the hatred for Lisp is due to …
> 
> Syntax.
> 
> 99.999% of “programmers” think that they need to have a “structured”
> syntax.
> 
> Lisp is essentially a syntax-less language.  A bunch of concrete parse trees.  A
> high level assembler.
> 
> For me, Lisp is the back-end of a compiler, after the syntax has been stripped
> off.
> 
> I wrote ‘paraphrase' (experimental)
> https://github.com/guitarvydas/paraphrase to show that just about any
> syntax can be grafted onto Lisp.
> 
> I enjoy the freedom of writing in a high-level assembler.
> 
> Apparently, most programmers cannot handle this concept.
> 
> pt
> 
> 
> 
> > On Apr 27, 2016, at 11:51 AM, David McClain <dbm@refined-
> audiometrics.com> wrote:
> >
> >
> > Hi All,
> >
> > Since last August, I have been using a tool called PixInsight quite regularly.
> Perhaps some of you are familiar with it. It is an image processing tool, meant
> for reduction of stacks of astronomical images, to produce visual results. It is
> quite an elegant tool, written by an outstanding group of astronomers in
> Spain, and provides access to some of the most recent and powerful
> processing concepts - MURE denoising, wavelet transform filtering, etc. It is
> also largely open source. Non-scientists often describe PixInsight as having a
> vertical learning curve. But I take to it like a fish to water. I love it… almost...
> >
> > But what saddens me deeply is that this brilliant crew spent so many hours
> slaving away in C++ and providing a JavaScript API at the user level for
> extensions. Their code is quite brilliant, but the system could have been
> written with far less effort, and made far more powerful at the user
> extension level, had they chosen to do their system in a Lisp.
> >
> > It is shocking to see such bright minds ignorant of programming.
> >
> > just my 2c…
> >
> > - DM
> >
> >
> > _______________________________________________
> > Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com
> > http://www.lispworks.com/support/lisp-hug.html
> >
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Hi,
I am familiar with a few languages including C++, Java and Lisp. I agree
C++ is notoriously ³hard" (note that these qualifiers depend on the
individual and so are highly subjective), much harder than Lisp. Even
though I am ³comfortable² with Lisp, I find certain parts (concepts)
tougher to understand and use. This is true of most languages, I guess.

My main point is that (other than what Syed has expressed about VC++) even
the ³expensive² environments such as LispWorks or even Allegro Lisp (I use
both of them) do not have as capable an IDE (with ³rich² GUI Designer
built-in) as for example VC++ or Embarcadero RAD Studio. These days GUIs
are very important and rich UI frameworks and libraries are available for
C++ and Java. RAD Studio allows you to target multiple platforms (VC++ 15
has such a support now). You can very quickly build and deploy a simple
multi-platform application in RAD Studio. My only wish is that Lisp
environments must rise upto this level. The ³language" alone is not the
issue these days.

Those who have been working in Lisp IDEs must take a look at the above
IDEs. Of course, I should definitely mention IntelliJ IDEA for Java!
Simply adorable!!

-Rangarajan
http://rangakrish.com


On 28/04/16 6:56 am, "Syed Zaeem Hosain" <Syed.Hosain@aeris.net> wrote:

>
>An interesting thread ...
>
>My issue is the lack of an inexpensive (better: "FREE") robust Lisp
>environment/compiler where I can write and deliver programs for the
>little projects I do now for myself and a few others.
>
>So, for what I have written recently, the Community version of Visual
>Studio is inexpensive (i.e., FREE!) and *works* well ... because these
>projects cannot justify my paying for a robust Lisp development system.
>
>For this purpose, the $1500 cost of the 64-bit HobbyistDV edition is
>ridiculous, IMHO. 
>
>And 64-bit Hobbyist is unusable because of the lack of a "deliver"
>function (momentarily ignoring the $750 cost). See
>http://www.lispworks.com/buy/prices-1h.html ...
>
>My point is that Microsoft's Visual Studio Community edition _works_ for
>my needs (to distribute free programs for myself and a few others) ...
>LispWorks simply does *not*. I don't know of another robust Lisp
>environment that I _could_ use.
>
>As a result, my programs are now all in C and C++ ... even though I would
>_much_ rather program in Lisp, of course! Till somebody makes a robust
>FREE delivery environment for Lisp, with free run-times delivery, this
>will remain the case.
>
>Z
>
>> -----Original Message-----
>> From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-
>> hug@lispworks.com] On Behalf Of Paul Tarvydas
>> Sent: Wednesday, April 27, 2016 05:17 PM
>> To: David McClain <dbm@refined-audiometrics.com>
>> Cc: LispWorks <lisp-hug@lispworks.com>
>> Subject: Re: Sadness in my heart...
>> 
>> 
>> Sadly, after 30+ years of thinking about programming, I¹ve come to
>> conclusion that the hatred for Lisp is due to Š
>> 
>> Syntax.
>> 
>> 99.999% of ³programmers² think that they need to have a ³structured²
>> syntax.
>> 
>> Lisp is essentially a syntax-less language.  A bunch of concrete parse
>>trees.  A
>> high level assembler.
>> 
>> For me, Lisp is the back-end of a compiler, after the syntax has been
>>stripped
>> off.
>> 
>> I wrote Œparaphrase' (experimental)
>> https://github.com/guitarvydas/paraphrase to show that just about any
>> syntax can be grafted onto Lisp.
>> 
>> I enjoy the freedom of writing in a high-level assembler.
>> 
>> Apparently, most programmers cannot handle this concept.
>> 
>> pt
>> 
>> 
>> 
>> > On Apr 27, 2016, at 11:51 AM, David McClain <dbm@refined-
>> audiometrics.com> wrote:
>> >
>> >
>> > Hi All,
>> >
>> > Since last August, I have been using a tool called PixInsight quite
>>regularly.
>> Perhaps some of you are familiar with it. It is an image processing
>>tool, meant
>> for reduction of stacks of astronomical images, to produce visual
>>results. It is
>> quite an elegant tool, written by an outstanding group of astronomers in
>> Spain, and provides access to some of the most recent and powerful
>> processing concepts - MURE denoising, wavelet transform filtering, etc.
>>It is
>> also largely open source. Non-scientists often describe PixInsight as
>>having a
>> vertical learning curve. But I take to it like a fish to water. I love
>>itŠ almost...
>> >
>> > But what saddens me deeply is that this brilliant crew spent so many
>>hours
>> slaving away in C++ and providing a JavaScript API at the user level for
>> extensions. Their code is quite brilliant, but the system could have
>>been
>> written with far less effort, and made far more powerful at the user
>> extension level, had they chosen to do their system in a Lisp.
>> >
>> > It is shocking to see such bright minds ignorant of programming.
>> >
>> > just my 2cŠ
>> >
>> > - DM
>> >
>> >
>> > _______________________________________________
>> > Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com
>> > http://www.lispworks.com/support/lisp-hug.html
>> >
>> 
>> 
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> lisp-hug@lispworks.com
>> http://www.lispworks.com/support/lisp-hug.html
>
>
>_______________________________________________
>Lisp Hug - the mailing list for LispWorks users
>lisp-hug@lispworks.com
>http://www.lispworks.com/support/lisp-hug.html
>



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

David McClain <dbm@refined-audiometrics.com> wrote:

> Just an afterthought… but so far in my own experience, Lisp is the
> only language in which I have been able to write useful libraries of
> code and continue using them unchanged for more than 20 years. All of
> my prior C code has deteriorated through bit-rot. There is something
> of a timeless quality to code written in Lisp.

  That is because Lisp is probably the only programming language that
  behaves like a natural language rather than like a programming
  language. See this lightning keynote of mine:

https://www.lrde.epita.fr/~didier/research/verna.12.accu-lightning-keynote.pdf
  

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

David McClain <dbm@refined-audiometrics.com> wrote:

> Hi Didier,
>
> Very clever viewpoiint! 

  BTW, I just found out that the talk was recorded (free account needed
  tho): https://skillsmatter.com/skillscasts/3504-lightning-talk-dider-verna-death-by-obesity#showModal?modal-signup-complete

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

David McClain <dbm@refined-audiometrics.com> wrote:

> I remember reading a treatise written back in the 80’s from a fellow
> who did an analysis of languages

  I'm interested if you can ever put your hands back on it.

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Hey, my 2 cents. :-)

I created a Lisp-based version of a multi-dimensional calc engine my company had created. It ran ~6 times faster than the Delphi-based (think: Pascal-based) version, and had ~1/10th the number of lines of code.

I created a Scheme-based web app that compiled user queries to native code for execution against a Scheme-based database. The worst-case query evaluation time for certain "large" data sets was measured in microseconds. That was on very low-end hardware, which was exactly the point; we wanted to be able to scale out very cheaply.

Another nice aspect of the Scheme-based web app: the Scheme we were using allowed you to limit modules to specific Scheme "languages". We used that ability to create a mutation-free variant of Scheme. The web server was fully multi-threaded. Mutation was allowed during initialization (full language), but not during request handling (restricted language). We had ~3 threading defects in ~6 years.

But.

The strength of Lisp and Scheme is also its weakness. It allows you to create a language to tackle a problem. How well is that language documented? How well do programmers on a team align in their little language thinking and skills? How easy is it to drop someone new into that web of little languages, and how easy is it to share those little languages with people not on the team?

If you're a mechanic you can probably figure out any car pretty quickly. (Well, before they became computers. :-) If you're a builder, especially within a particular geography like the US, you can probably figure out any building pretty quickly. In both cases it's like the language of construction has a restricted syntax—just as in C or Python where conditionals look like *this*, functions like *that*. If cars and buildings were constructed using tools like Lisp and Scheme the cars and buildings might be "better", but the industries around them couldn't scale; engines might not *look* like engines, and walls might not *look* like walls (in terms of, say, their internal structure).

Isn't that the point of Richard Gabriel's worse-is-better? From the Wikipedia summary:

===

Worse is better, also called New Jersey style, was conceived by Richard P. Gabriel to describe the dynamics of software acceptance, but it has broader application. The idea is that quality does not necessarily increase with functionality. There is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.

===


On Thu, Apr 28, 2016 at 10:36 AM, Tim Bradshaw <tfb@tfeb.org> wrote:
On 28 Apr 2016, at 14:53, Keith Corbett <kmcorbett@gmail.com> wrote:

One of the arguments against DSSSL was about syntax: developers don't like to use "lots of insidious parentheses". Apparently, developers are more comfortable with lots of curly braces, dots, commas and semicolons, etc. Microsoft and Netscape promulgated this FUD. The rest is history.

Well, what is actually history is different than the history we are lead to believe is the case.  Where I work (and in much of science in general) Python Has Won.  I deeply hate Python for reasons too boring to go into here, but what it is not is a language with lots of squiggles, especially compared with C-derived languages.

Re: Sadness in my heart...

I don't think "worse is better" applies in this case, and while I don't have professional experience with it, I believe that Lisp is actually *simpler* most of the time than the alternatives I know (Java, .NET). Of course you can complicate things at will in Lisp. I guarantee you though that, in spite of their constrained syntax and their reliance on frameworks that "guide" the structure of the software, in any middle to big Java application you'll find at least some obscure, reflection-based part that will be hard to grasp at first, some half-baked DSL based on XML, or some complicated and undocumented designs, etc. I've never been able to figure out someone else's software as quickly as I'd have liked. Whereas in Lisp (open source projects) I'm generally able to move around without wandering too much, even if IDEs are less sophisticated and projects tend to be organized more freely. Sure, it requires a bit of learning, using SLIME, macroexpand, etc. - you can't just click on buttons and see what happens or follow wizards and copy-paste. That's a positive thing, however ;)

On 28 April 2016 at 17:22, Michael Lenaghan <michaell@dazzit.com> wrote:
Hey, my 2 cents. :-)

I created a Lisp-based version of a multi-dimensional calc engine my company had created. It ran ~6 times faster than the Delphi-based (think: Pascal-based) version, and had ~1/10th the number of lines of code.

I created a Scheme-based web app that compiled user queries to native code for execution against a Scheme-based database. The worst-case query evaluation time for certain "large" data sets was measured in microseconds. That was on very low-end hardware, which was exactly the point; we wanted to be able to scale out very cheaply.

Another nice aspect of the Scheme-based web app: the Scheme we were using allowed you to limit modules to specific Scheme "languages". We used that ability to create a mutation-free variant of Scheme. The web server was fully multi-threaded. Mutation was allowed during initialization (full language), but not during request handling (restricted language). We had ~3 threading defects in ~6 years.

But.

The strength of Lisp and Scheme is also its weakness. It allows you to create a language to tackle a problem. How well is that language documented? How well do programmers on a team align in their little language thinking and skills? How easy is it to drop someone new into that web of little languages, and how easy is it to share those little languages with people not on the team?

If you're a mechanic you can probably figure out any car pretty quickly. (Well, before they became computers. :-) If you're a builder, especially within a particular geography like the US, you can probably figure out any building pretty quickly. In both cases it's like the language of construction has a restricted syntax—just as in C or Python where conditionals look like *this*, functions like *that*. If cars and buildings were constructed using tools like Lisp and Scheme the cars and buildings might be "better", but the industries around them couldn't scale; engines might not *look* like engines, and walls might not *look* like walls (in terms of, say, their internal structure).

Isn't that the point of Richard Gabriel's worse-is-better? From the Wikipedia summary:

===

Worse is better, also called New Jersey style, was conceived by Richard P. Gabriel to describe the dynamics of software acceptance, but it has broader application. The idea is that quality does not necessarily increase with functionality. There is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.

===


On Thu, Apr 28, 2016 at 10:36 AM, Tim Bradshaw <tfb@tfeb.org> wrote:
On 28 Apr 2016, at 14:53, Keith Corbett <kmcorbett@gmail.com> wrote:

One of the arguments against DSSSL was about syntax: developers don't like to use "lots of insidious parentheses". Apparently, developers are more comfortable with lots of curly braces, dots, commas and semicolons, etc. Microsoft and Netscape promulgated this FUD. The rest is history.

Well, what is actually history is different than the history we are lead to believe is the case.  Where I work (and in much of science in general) Python Has Won.  I deeply hate Python for reasons too boring to go into here, but what it is not is a language with lots of squiggles, especially compared with C-derived languages.


Re: Sadness in my heart...

David McClain <dbm@refined-audiometrics.com> writes:

> Lisp, on the other hand, seems to have done well to adhere to a core
> standard ever since 1990, as far as I can tell. Code that abides with
> that standard has never needed any maintenance. Standard syntax
> remains simple and unchanged. Code that uses Lisp extensions has
> required minor, but infrequent, maintenance when using the Lispworks
> Lisp.

since 1960!
http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

I don't buy this point. There are other languages old enough (namely FORTRAN, APL
etc) which are still in use right now and the libraries written long
time ago are still in use (BLAS for FORTRAN as an example. Alternatively
I can type in any expression from "APL Idioms List 82" to my latest
version of  Dyalog APL interpreter as well as GNU APL and have no
problems running them).

As for C/C++, at least GCC supports older standards. Right now I
maintain the C++ code written in 1999 without any significant problems (it
was not written for particular C++ vendor compiler).

David McClain <dbm@refined-audiometrics.com> writes:

> Just an afterthought… but so far in my own experience, Lisp is the only language
> in which I have been able to write useful libraries of code and continue using
> them unchanged for more than 20 years. All of my prior C code has deteriorated
> through bit-rot. There is something of a timeless quality to code written in
> Lisp.
>
> - DM
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
>

-- 
Br,
/Alexey

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...


> On Apr 28, 2016, at 4:24 PM, David McClain <dbm@refined-audiometrics.com> wrote:
> 
> 
> Wow! I had no idea that people still used APL. I thought it died when the old IBM terminals and their foreign keyboards went away. But do you seriously offer APL as a viable solution to the wide variety of current day problem domains, not just math twiddling?
> 
> [ I do know that back in the early 80’s when i worked for IBM, the chip IC database was managed with APL. So it is possible to do some kind of database in APL, but not sure it would match today’s expectations of a database manager. ]

APL and its offspring J and K are pretty heavily used in finance and investing. One of the most widely-used databases for time-series data (like the data from stock tickers) is kdb, a database built into and implemented in k.

The APL lineage of languages is very much alive and well and in heavy active use.



_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Here while I agree what C++ is somewhat harder than CL, I couldn't agree
it is much harder. I'm toying around CL and Emacs Lisp for a few years
already and still stumble upon problems with understanding the
necessity of things like alexandria:switch (when we have 'case' in a
standard), different comparison functions
(eq/eql/equal/equalp/string=/string-equal), different svref/aref/nth,
different (maybe historical)  idiosyncrasies like remembering at which argument position in the hash
table should be in gethash, syntax for LOOP (I guess it will require
years to master it, and in most cases it is easier to just write
something from scratch), syntaxes for defpackage, defclass and others
alike (which of arguments should be a list of lists or just a list and
so on) and so on and so on. CL is not a small language and certainly not
without a hishorical legacy.

But about lack of IDEs I agree with you absolutely. I used only
Emacs/Slime and LW IDE. However they certainly lack some
features of modern IDEs or other image-based languages
which I would love to use. Where is reliable
"jump to definition"? (I can't jump to definition of the slot from
with-slots for instance)? How can I get a documentation of the function
hovering a mouse above it? How could I rename a slot and all places
where it is used including its readers/writers and their use? How do I
just rename a method (for example if the method has ubiquitous name but unique in a
package of course)? Where is incremental compilation? Conditional
breakpoints? Hopefully the graphical stepper exists only in LW IDE,
common, insert "format" or "break" around the code in 21st century?
Where are "debug/release" modes, why I have to write it manually in
delivery script? Where is a dependency tracking, why I have to write
asdf :serial or count which file is used from which manually ? Even gcc
supports -M? family of flags etc to generate dependencies? Why we don't
have syntax highlighting in neither SLIME nor LW Listener? Why I can't
open a definition of the function I've just evaluated like I can in APL
or Smalltalk? Why I can't read the documentation on a slot I've defined?

I guess a some of these complains cannot be implemented because of the
dynamic nature of the language. But most of it could be implemented to
some extent anyway.


Rangarajan Krishnamoorthy <ranga@mmsindia.com> writes:

> Hi,
> I am familiar with a few languages including C++, Java and Lisp. I agree
> C++ is notoriously ³hard" (note that these qualifiers depend on the
> individual and so are highly subjective), much harder than Lisp. Even
> though I am ³comfortable² with Lisp, I find certain parts (concepts)
> tougher to understand and use. This is true of most languages, I guess.
>
> My main point is that (other than what Syed has expressed about VC++) even
> the ³expensive² environments such as LispWorks or even Allegro Lisp (I use
> both of them) do not have as capable an IDE (with ³rich² GUI Designer
> built-in) as for example VC++ or Embarcadero RAD Studio. These days GUIs
> are very important and rich UI frameworks and libraries are available for
> C++ and Java. RAD Studio allows you to target multiple platforms (VC++ 15
> has such a support now). You can very quickly build and deploy a simple
> multi-platform application in RAD Studio. My only wish is that Lisp
> environments must rise upto this level. The ³language" alone is not the
> issue these days.
>
> Those who have been working in Lisp IDEs must take a look at the above
> IDEs. Of course, I should definitely mention IntelliJ IDEA for Java!
> Simply adorable!!
>
> -Rangarajan
> http://rangakrish.com
>
>
> On 28/04/16 6:56 am, "Syed Zaeem Hosain" <Syed.Hosain@aeris.net> wrote:
>
>>
>>An interesting thread ...
>>
>>My issue is the lack of an inexpensive (better: "FREE") robust Lisp
>>environment/compiler where I can write and deliver programs for the
>>little projects I do now for myself and a few others.
>>
>>So, for what I have written recently, the Community version of Visual
>>Studio is inexpensive (i.e., FREE!) and *works* well ... because these
>>projects cannot justify my paying for a robust Lisp development system.
>>
>>For this purpose, the $1500 cost of the 64-bit HobbyistDV edition is
>>ridiculous, IMHO. 
>>
>>And 64-bit Hobbyist is unusable because of the lack of a "deliver"
>>function (momentarily ignoring the $750 cost). See
>>http://www.lispworks.com/buy/prices-1h.html ...
>>
>>My point is that Microsoft's Visual Studio Community edition _works_ for
>>my needs (to distribute free programs for myself and a few others) ...
>>LispWorks simply does *not*. I don't know of another robust Lisp
>>environment that I _could_ use.
>>
>>As a result, my programs are now all in C and C++ ... even though I would
>>_much_ rather program in Lisp, of course! Till somebody makes a robust
>>FREE delivery environment for Lisp, with free run-times delivery, this
>>will remain the case.
>>
>>Z
>>
>>> -----Original Message-----
>>> From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-
>>> hug@lispworks.com] On Behalf Of Paul Tarvydas
>>> Sent: Wednesday, April 27, 2016 05:17 PM
>>> To: David McClain <dbm@refined-audiometrics.com>
>>> Cc: LispWorks <lisp-hug@lispworks.com>
>>> Subject: Re: Sadness in my heart...
>>> 
>>> 
>>> Sadly, after 30+ years of thinking about programming, I¹ve come to
>>> conclusion that the hatred for Lisp is due to Š
>>> 
>>> Syntax.
>>> 
>>> 99.999% of ³programmers² think that they need to have a ³structured²
>>> syntax.
>>> 
>>> Lisp is essentially a syntax-less language.  A bunch of concrete parse
>>>trees.  A
>>> high level assembler.
>>> 
>>> For me, Lisp is the back-end of a compiler, after the syntax has been
>>>stripped
>>> off.
>>> 
>>> I wrote Œparaphrase' (experimental)
>>> https://github.com/guitarvydas/paraphrase to show that just about any
>>> syntax can be grafted onto Lisp.
>>> 
>>> I enjoy the freedom of writing in a high-level assembler.
>>> 
>>> Apparently, most programmers cannot handle this concept.
>>> 
>>> pt
>>> 
>>> 
>>> 
>>> > On Apr 27, 2016, at 11:51 AM, David McClain <dbm@refined-
>>> audiometrics.com> wrote:
>>> >
>>> >
>>> > Hi All,
>>> >
>>> > Since last August, I have been using a tool called PixInsight quite
>>>regularly.
>>> Perhaps some of you are familiar with it. It is an image processing
>>>tool, meant
>>> for reduction of stacks of astronomical images, to produce visual
>>>results. It is
>>> quite an elegant tool, written by an outstanding group of astronomers in
>>> Spain, and provides access to some of the most recent and powerful
>>> processing concepts - MURE denoising, wavelet transform filtering, etc.
>>>It is
>>> also largely open source. Non-scientists often describe PixInsight as
>>>having a
>>> vertical learning curve. But I take to it like a fish to water. I love
>>>itŠ almost...
>>> >
>>> > But what saddens me deeply is that this brilliant crew spent so many
>>>hours
>>> slaving away in C++ and providing a JavaScript API at the user level for
>>> extensions. Their code is quite brilliant, but the system could have
>>>been
>>> written with far less effort, and made far more powerful at the user
>>> extension level, had they chosen to do their system in a Lisp.
>>> >
>>> > It is shocking to see such bright minds ignorant of programming.
>>> >
>>> > just my 2cŠ
>>> >
>>> > - DM
>>> >
>>> >
>>> > _______________________________________________
>>> > Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com
>>> > http://www.lispworks.com/support/lisp-hug.html
>>> >
>>> 
>>> 
>>> _______________________________________________
>>> Lisp Hug - the mailing list for LispWorks users
>>> lisp-hug@lispworks.com
>>> http://www.lispworks.com/support/lisp-hug.html
>>
>>
>>_______________________________________________
>>Lisp Hug - the mailing list for LispWorks users
>>lisp-hug@lispworks.com
>>http://www.lispworks.com/support/lisp-hug.html
>>
>
>
>
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
>

-- 
Br,
/Alexey

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

This isn't a SLIME forum, so I won't go into details, but several of the
features that you say are not available in SLIME are, in fact, available
(e.g., incremental compilation).  Others should be easy to add (hover
over documentation display).  And so forth....

On 4/28/16 Apr 28 -4:47 PM, Alexey Veretennikov wrote:
> 
> Here while I agree what C++ is somewhat harder than CL, I couldn't agree
> it is much harder. I'm toying around CL and Emacs Lisp for a few years
> already and still stumble upon problems with understanding the
> necessity of things like alexandria:switch (when we have 'case' in a
> standard), different comparison functions
> (eq/eql/equal/equalp/string=/string-equal), different svref/aref/nth,
> different (maybe historical)  idiosyncrasies like remembering at which argument position in the hash
> table should be in gethash, syntax for LOOP (I guess it will require
> years to master it, and in most cases it is easier to just write
> something from scratch), syntaxes for defpackage, defclass and others
> alike (which of arguments should be a list of lists or just a list and
> so on) and so on and so on. CL is not a small language and certainly not
> without a hishorical legacy.
> 
> But about lack of IDEs I agree with you absolutely. I used only
> Emacs/Slime and LW IDE. However they certainly lack some
> features of modern IDEs or other image-based languages
> which I would love to use. Where is reliable
> "jump to definition"? (I can't jump to definition of the slot from
> with-slots for instance)? How can I get a documentation of the function
> hovering a mouse above it? How could I rename a slot and all places
> where it is used including its readers/writers and their use? How do I
> just rename a method (for example if the method has ubiquitous name but unique in a
> package of course)? Where is incremental compilation? Conditional
> breakpoints? Hopefully the graphical stepper exists only in LW IDE,
> common, insert "format" or "break" around the code in 21st century?
> Where are "debug/release" modes, why I have to write it manually in
> delivery script? Where is a dependency tracking, why I have to write
> asdf :serial or count which file is used from which manually ? Even gcc
> supports -M? family of flags etc to generate dependencies? Why we don't
> have syntax highlighting in neither SLIME nor LW Listener? Why I can't
> open a definition of the function I've just evaluated like I can in APL
> or Smalltalk? Why I can't read the documentation on a slot I've defined?
> 
> I guess a some of these complains cannot be implemented because of the
> dynamic nature of the language. But most of it could be implemented to
> some extent anyway.
> 
> 
> Rangarajan Krishnamoorthy <ranga@mmsindia.com> writes:
> 
>> Hi,
>> I am familiar with a few languages including C++, Java and Lisp. I agree
>> C++ is notoriously ³hard" (note that these qualifiers depend on the
>> individual and so are highly subjective), much harder than Lisp. Even
>> though I am ³comfortable² with Lisp, I find certain parts (concepts)
>> tougher to understand and use. This is true of most languages, I guess.
>>
>> My main point is that (other than what Syed has expressed about VC++) even
>> the ³expensive² environments such as LispWorks or even Allegro Lisp (I use
>> both of them) do not have as capable an IDE (with ³rich² GUI Designer
>> built-in) as for example VC++ or Embarcadero RAD Studio. These days GUIs
>> are very important and rich UI frameworks and libraries are available for
>> C++ and Java. RAD Studio allows you to target multiple platforms (VC++ 15
>> has such a support now). You can very quickly build and deploy a simple
>> multi-platform application in RAD Studio. My only wish is that Lisp
>> environments must rise upto this level. The ³language" alone is not the
>> issue these days.
>>
>> Those who have been working in Lisp IDEs must take a look at the above
>> IDEs. Of course, I should definitely mention IntelliJ IDEA for Java!
>> Simply adorable!!
>>
>> -Rangarajan
>> http://rangakrish.com
>>
>>
>> On 28/04/16 6:56 am, "Syed Zaeem Hosain" <Syed.Hosain@aeris.net> wrote:
>>
>>>
>>> An interesting thread ...
>>>
>>> My issue is the lack of an inexpensive (better: "FREE") robust Lisp
>>> environment/compiler where I can write and deliver programs for the
>>> little projects I do now for myself and a few others.
>>>
>>> So, for what I have written recently, the Community version of Visual
>>> Studio is inexpensive (i.e., FREE!) and *works* well ... because these
>>> projects cannot justify my paying for a robust Lisp development system.
>>>
>>> For this purpose, the $1500 cost of the 64-bit HobbyistDV edition is
>>> ridiculous, IMHO. 
>>>
>>> And 64-bit Hobbyist is unusable because of the lack of a "deliver"
>>> function (momentarily ignoring the $750 cost). See
>>> http://www.lispworks.com/buy/prices-1h.html ...
>>>
>>> My point is that Microsoft's Visual Studio Community edition _works_ for
>>> my needs (to distribute free programs for myself and a few others) ...
>>> LispWorks simply does *not*. I don't know of another robust Lisp
>>> environment that I _could_ use.
>>>
>>> As a result, my programs are now all in C and C++ ... even though I would
>>> _much_ rather program in Lisp, of course! Till somebody makes a robust
>>> FREE delivery environment for Lisp, with free run-times delivery, this
>>> will remain the case.
>>>
>>> Z
>>>
>>>> -----Original Message-----
>>>> From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-
>>>> hug@lispworks.com] On Behalf Of Paul Tarvydas
>>>> Sent: Wednesday, April 27, 2016 05:17 PM
>>>> To: David McClain <dbm@refined-audiometrics.com>
>>>> Cc: LispWorks <lisp-hug@lispworks.com>
>>>> Subject: Re: Sadness in my heart...
>>>>
>>>>
>>>> Sadly, after 30+ years of thinking about programming, I¹ve come to
>>>> conclusion that the hatred for Lisp is due to Š
>>>>
>>>> Syntax.
>>>>
>>>> 99.999% of ³programmers² think that they need to have a ³structured²
>>>> syntax.
>>>>
>>>> Lisp is essentially a syntax-less language.  A bunch of concrete parse
>>>> trees.  A
>>>> high level assembler.
>>>>
>>>> For me, Lisp is the back-end of a compiler, after the syntax has been
>>>> stripped
>>>> off.
>>>>
>>>> I wrote Œparaphrase' (experimental)
>>>> https://github.com/guitarvydas/paraphrase to show that just about any
>>>> syntax can be grafted onto Lisp.
>>>>
>>>> I enjoy the freedom of writing in a high-level assembler.
>>>>
>>>> Apparently, most programmers cannot handle this concept.
>>>>
>>>> pt
>>>>
>>>>
>>>>
>>>>> On Apr 27, 2016, at 11:51 AM, David McClain <dbm@refined-
>>>> audiometrics.com> wrote:
>>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Since last August, I have been using a tool called PixInsight quite
>>>> regularly.
>>>> Perhaps some of you are familiar with it. It is an image processing
>>>> tool, meant
>>>> for reduction of stacks of astronomical images, to produce visual
>>>> results. It is
>>>> quite an elegant tool, written by an outstanding group of astronomers in
>>>> Spain, and provides access to some of the most recent and powerful
>>>> processing concepts - MURE denoising, wavelet transform filtering, etc.
>>>> It is
>>>> also largely open source. Non-scientists often describe PixInsight as
>>>> having a
>>>> vertical learning curve. But I take to it like a fish to water. I love
>>>> itŠ almost...
>>>>>
>>>>> But what saddens me deeply is that this brilliant crew spent so many
>>>> hours
>>>> slaving away in C++ and providing a JavaScript API at the user level for
>>>> extensions. Their code is quite brilliant, but the system could have
>>>> been
>>>> written with far less effort, and made far more powerful at the user
>>>> extension level, had they chosen to do their system in a Lisp.
>>>>>
>>>>> It is shocking to see such bright minds ignorant of programming.
>>>>>
>>>>> just my 2cŠ
>>>>>
>>>>> - DM
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com
>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Lisp Hug - the mailing list for LispWorks users
>>>> lisp-hug@lispworks.com
>>>> http://www.lispworks.com/support/lisp-hug.html
>>>
>>>
>>> _______________________________________________
>>> Lisp Hug - the mailing list for LispWorks users
>>> lisp-hug@lispworks.com
>>> http://www.lispworks.com/support/lisp-hug.html
>>>
>>
>>
>>
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> lisp-hug@lispworks.com
>> http://www.lispworks.com/support/lisp-hug.html
>>
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Very good,
so please name what from the list I've mentioned already exists. The
only thing I know
is magit(which has nothing to do with a SLIME), no problems with it.

But all other issues, which of them
exists? Jump to slot definition was not possible for me in Slime
connected to LispWorks (we are in the LW users list remember, I don't know
if it is available for SBCL). Can't see the slot documentation either
(granted what you don't have an access to it despite of the keyword in
CL standard, but anyways). Incremental compilation I meant the
background compilation like in IntelliJ IDEA (or Emacs flymake), so at
any particular point of time the parse tree is available helping syntax
highlighting, showing potential errors, smart code completion etc. Maybe
it is available in SLIME, but I can't recall it the last time I used it.
For example, defining method like

(defmethod on-candidates-menu-delete ((self main-window))
  (with-slots (proposal-table ...
 
I would like to press tab in the place of dots and have a list of all
slots in the class main-window, and the incremental compilation seems to
be the only way to do it (if the main-window class is already defined
with all the necessary slots). I can't have it now, neither in SLIME nor
in LW IDE.

Can't see any breakpoint-related items in SLIME menu either. Maybe in
documentation somewhere?

Can't recall method/slot renaming in SLIME either as other refactoring capabilities.
Anyway since it is a LW HUG list I would expect to have these features in
LW IDE mostly, not in SLIME.


Robert Goldman <rpgoldman@sift.net> writes:

> This isn't a SLIME forum, so I won't go into details, but several of the
> features that you say are not available in SLIME are, in fact, available
> (e.g., incremental compilation).  Others should be easy to add (hover
> over documentation display).  And so forth....
>
> On 4/28/16 Apr 28 -4:47 PM, Alexey Veretennikov wrote:
>> 
>> Here while I agree what C++ is somewhat harder than CL, I couldn't agree
>> it is much harder. I'm toying around CL and Emacs Lisp for a few years
>> already and still stumble upon problems with understanding the
>> necessity of things like alexandria:switch (when we have 'case' in a
>> standard), different comparison functions
>> (eq/eql/equal/equalp/string=/string-equal), different svref/aref/nth,
>> different (maybe historical) idiosyncrasies like remembering at which argument
>> position in the hash
>> table should be in gethash, syntax for LOOP (I guess it will require
>> years to master it, and in most cases it is easier to just write
>> something from scratch), syntaxes for defpackage, defclass and others
>> alike (which of arguments should be a list of lists or just a list and
>> so on) and so on and so on. CL is not a small language and certainly not
>> without a hishorical legacy.
>> 
>> But about lack of IDEs I agree with you absolutely. I used only
>> Emacs/Slime and LW IDE. However they certainly lack some
>> features of modern IDEs or other image-based languages
>> which I would love to use. Where is reliable
>> "jump to definition"? (I can't jump to definition of the slot from
>> with-slots for instance)? How can I get a documentation of the function
>> hovering a mouse above it? How could I rename a slot and all places
>> where it is used including its readers/writers and their use? How do I
>> just rename a method (for example if the method has ubiquitous name but unique
>> in a
>> package of course)? Where is incremental compilation? Conditional
>> breakpoints? Hopefully the graphical stepper exists only in LW IDE,
>> common, insert "format" or "break" around the code in 21st century?
>> Where are "debug/release" modes, why I have to write it manually in
>> delivery script? Where is a dependency tracking, why I have to write
>> asdf :serial or count which file is used from which manually ? Even gcc
>> supports -M? family of flags etc to generate dependencies? Why we don't
>> have syntax highlighting in neither SLIME nor LW Listener? Why I can't
>> open a definition of the function I've just evaluated like I can in APL
>> or Smalltalk? Why I can't read the documentation on a slot I've defined?
>> 
>> I guess a some of these complains cannot be implemented because of the
>> dynamic nature of the language. But most of it could be implemented to
>> some extent anyway.
>> 
>> 
>> Rangarajan Krishnamoorthy <ranga@mmsindia.com> writes:
>> 
>>> Hi,
>>> I am familiar with a few languages including C++, Java and Lisp. I agree
>>> C++ is notoriously ³hard" (note that these qualifiers depend on the
>>> individual and so are highly subjective), much harder than Lisp. Even
>>> though I am ³comfortable² with Lisp, I find certain parts (concepts)
>>> tougher to understand and use. This is true of most languages, I guess.
>>>
>>> My main point is that (other than what Syed has expressed about VC++) even
>>> the ³expensive² environments such as LispWorks or even Allegro Lisp (I use
>>> both of them) do not have as capable an IDE (with ³rich² GUI Designer
>>> built-in) as for example VC++ or Embarcadero RAD Studio. These days GUIs
>>> are very important and rich UI frameworks and libraries are available for
>>> C++ and Java. RAD Studio allows you to target multiple platforms (VC++ 15
>>> has such a support now). You can very quickly build and deploy a simple
>>> multi-platform application in RAD Studio. My only wish is that Lisp
>>> environments must rise upto this level. The ³language" alone is not the
>>> issue these days.
>>>
>>> Those who have been working in Lisp IDEs must take a look at the above
>>> IDEs. Of course, I should definitely mention IntelliJ IDEA for Java!
>>> Simply adorable!!
>>>
>>> -Rangarajan
>>> http://rangakrish.com
>>>
>>>
>>> On 28/04/16 6:56 am, "Syed Zaeem Hosain" <Syed.Hosain@aeris.net> wrote:
>>>
>>>>
>>>> An interesting thread ...
>>>>
>>>> My issue is the lack of an inexpensive (better: "FREE") robust Lisp
>>>> environment/compiler where I can write and deliver programs for the
>>>> little projects I do now for myself and a few others.
>>>>
>>>> So, for what I have written recently, the Community version of Visual
>>>> Studio is inexpensive (i.e., FREE!) and *works* well ... because these
>>>> projects cannot justify my paying for a robust Lisp development system.
>>>>
>>>> For this purpose, the $1500 cost of the 64-bit HobbyistDV edition is
>>>> ridiculous, IMHO. 
>>>>
>>>> And 64-bit Hobbyist is unusable because of the lack of a "deliver"
>>>> function (momentarily ignoring the $750 cost). See
>>>> http://www.lispworks.com/buy/prices-1h.html ...
>>>>
>>>> My point is that Microsoft's Visual Studio Community edition _works_ for
>>>> my needs (to distribute free programs for myself and a few others) ....
>>>> LispWorks simply does *not*. I don't know of another robust Lisp
>>>> environment that I _could_ use.
>>>>
>>>> As a result, my programs are now all in C and C++ ... even though I would
>>>> _much_ rather program in Lisp, of course! Till somebody makes a robust
>>>> FREE delivery environment for Lisp, with free run-times delivery, this
>>>> will remain the case.
>>>>
>>>> Z
>>>>
>>>>> -----Original Message-----
>>>>> From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-
>>>>> hug@lispworks.com] On Behalf Of Paul Tarvydas
>>>>> Sent: Wednesday, April 27, 2016 05:17 PM
>>>>> To: David McClain <dbm@refined-audiometrics.com>
>>>>> Cc: LispWorks <lisp-hug@lispworks.com>
>>>>> Subject: Re: Sadness in my heart...
>>>>>
>>>>>
>>>>> Sadly, after 30+ years of thinking about programming, I¹ve come to
>>>>> conclusion that the hatred for Lisp is due to Š
>>>>>
>>>>> Syntax.
>>>>>
>>>>> 99.999% of ³programmers² think that they need to have a ³structured²
>>>>> syntax.
>>>>>
>>>>> Lisp is essentially a syntax-less language.  A bunch of concrete parse
>>>>> trees.  A
>>>>> high level assembler.
>>>>>
>>>>> For me, Lisp is the back-end of a compiler, after the syntax has been
>>>>> stripped
>>>>> off.
>>>>>
>>>>> I wrote Œparaphrase' (experimental)
>>>>> https://github.com/guitarvydas/paraphrase to show that just about any
>>>>> syntax can be grafted onto Lisp.
>>>>>
>>>>> I enjoy the freedom of writing in a high-level assembler.
>>>>>
>>>>> Apparently, most programmers cannot handle this concept.
>>>>>
>>>>> pt
>>>>>
>>>>>
>>>>>
>>>>>> On Apr 27, 2016, at 11:51 AM, David McClain <dbm@refined-
>>>>> audiometrics.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Since last August, I have been using a tool called PixInsight quite
>>>>> regularly.
>>>>> Perhaps some of you are familiar with it. It is an image processing
>>>>> tool, meant
>>>>> for reduction of stacks of astronomical images, to produce visual
>>>>> results. It is
>>>>> quite an elegant tool, written by an outstanding group of astronomers in
>>>>> Spain, and provides access to some of the most recent and powerful
>>>>> processing concepts - MURE denoising, wavelet transform filtering, etc.
>>>>> It is
>>>>> also largely open source. Non-scientists often describe PixInsight as
>>>>> having a
>>>>> vertical learning curve. But I take to it like a fish to water. I love
>>>>> itŠ almost...
>>>>>>
>>>>>> But what saddens me deeply is that this brilliant crew spent so many
>>>>> hours
>>>>> slaving away in C++ and providing a JavaScript API at the user level for
>>>>> extensions. Their code is quite brilliant, but the system could have
>>>>> been
>>>>> written with far less effort, and made far more powerful at the user
>>>>> extension level, had they chosen to do their system in a Lisp.
>>>>>>
>>>>>> It is shocking to see such bright minds ignorant of programming.
>>>>>>
>>>>>> just my 2cŠ
>>>>>>
>>>>>> - DM
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks..com
>>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lisp Hug - the mailing list for LispWorks users
>>>>> lisp-hug@lispworks.com
>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>
>>>>
>>>> _______________________________________________
>>>> Lisp Hug - the mailing list for LispWorks users
>>>> lisp-hug@lispworks.com
>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Lisp Hug - the mailing list for LispWorks users
>>> lisp-hug@lispworks.com
>>> http://www.lispworks.com/support/lisp-hug.html
>>>
>> 
>

-- 
Br,
/Alexey

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Sadness in my heart...

Didier Verna <didier@lrde.epita.fr> writes:

> David McClain <dbm@refined-audiometrics.com> wrote:
>
>> Just an afterthought… but so far in my own experience, Lisp is the
>> only language in which I have been able to write useful libraries of
>> code and continue using them unchanged for more than 20 years. All of
>> my prior C code has deteriorated through bit-rot. There is something
>> of a timeless quality to code written in Lisp.
>
>   That is because Lisp is probably the only programming language that
>   behaves like a natural language rather than like a programming
>   language. See this lightning keynote of mine:
>
> https://www.lrde.epita.fr/~didier/research/verna.12.accu-lightning-keynote.pdf

I don't think so, at least no exclusivly. Just look at Smalltalk and
you'd have to thing the "special" thing over. It's not named by chance
Smalltalk. 








-- 
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim 
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Updated at: 2020-12-10 08:32 UTC