Re: Sadness in my heart...

There is already Cursive IDE for IntelliJ, maybe it could be extended to Common Lisp as well as Clojure?

My guess as to why things like slots/classes don't have special treatment in the IDE is that they are macroed and doing so would make any programmer-defined macro DSL become a "second class citizen" unless they also defined an IDE extension for it which would be extremely complicated.. unless there was some way of specifying IDE properties of a macro inside its definition, but even that would complicate the definition..

Mark

Re: Sadness in my heart...

On 4/29/16 Apr 29 -10:15 AM, Mark Green wrote:
> There is already Cursive IDE for IntelliJ, maybe it could be extended to
> Common Lisp as well as Clojure?
> 
> My guess as to why things like slots/classes don't have special
> treatment in the IDE is that they are macroed and doing so would make
> any programmer-defined macro DSL become a "second class citizen" unless
> they also defined an IDE extension for it which would be extremely
> complicated.. unless there was some way of specifying IDE properties of
> a macro inside its definition, but even that would complicate the
> definition..

FWIW, Allegro CL has a partial solution to this problem.  You can tell
the lisp environment about definition-creating macros, and their Emacs
Lisp Interface can use that information to find definitions.  I've often
wanted to see this ported to SLIME (but don't know enough about SLIME
hacking to do it myself).

Which brings me back to an earlier point: if we are talking about IDEs,
we are leaving the realm of Lispworks-specific discussion.  This
discussion would be more productive in a CL-wide, or possibly a SLIME,
forum.

cheers,
r

_______________________________________________
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 think it's more because Lisp IDEs, ironically, are ultimately TEXT editors and not SEXP editors (including Paredit and similar).. IntelliJ does a lot of parsing/compilation to infer things about your source code. In Lisp it should be easier to work with S-expressions directly and keep additional metadata, like this expression was loaded from file x at line y with this textual representation, but Emacs/SLIME work mostly on text, not code. Which is a shame.

On 29 April 2016 at 17:15, Mark Green <mark@antelope.nildram.co.uk> wrote:

There is already Cursive IDE for IntelliJ, maybe it could be extended to Common Lisp as well as Clojure?

My guess as to why things like slots/classes don't have special treatment in the IDE is that they are macroed and doing so would make any programmer-defined macro DSL become a "second class citizen" unless they also defined an IDE extension for it which would be extremely complicated.. unless there was some way of specifying IDE properties of a macro inside its definition, but even that would complicate the definition..

Mark

Re: Sadness in my heart...

Well, I was thinking about this and the problem is simply the flexibility of macros. Certainly the LW IDE and SLIME do perform some parsing of s-expressions as they're entered. But if you wanted to provide slot hints, you'd have to be able to expand any macro that reduced to defclass. And a macro can contain arbitrary code, so you need an entire LISP interpreter for that. The LW IDE should be ideally placed to do that since it is written in LW and runs LW in parallel (the same reason why IntelliJ is so good for Java, although it is getting better on other languages). But then you hit a security problem - a mischievous library could drop in a macro which performs "rm -rf ~" at expand time, and as soon as you started typing the name of that macro, the IDE would expand it for analysis and wipe out your home directory.

Mark

On Fri, Apr 29, 2016 at 4:41 PM, Alessio Stalla <alessiostalla@gmail.com> wrote:

I think it's more because Lisp IDEs, ironically, are ultimately TEXT editors and not SEXP editors (including Paredit and similar). IntelliJ does a lot of parsing/compilation to infer things about your source code. In Lisp it should be easier to work with S-expressions directly and keep additional metadata, like this expression was loaded from file x at line y with this textual representation, but Emacs/SLIME work mostly on text, not code. Which is a shame.

On 29 April 2016 at 17:15, Mark Green <mark@antelope.nildram.co.uk> wrote:
There is already Cursive IDE for IntelliJ, maybe it could be extended to Common Lisp as well as Clojure?

My guess as to why things like slots/classes don't have special treatment in the IDE is that they are macroed and doing so would make any programmer-defined macro DSL become a "second class citizen" unless they also defined an IDE extension for it which would be extremely complicated.. unless there was some way of specifying IDE properties of a macro inside its definition, but even that would complicate the definition..

Mark

Re: Sadness in my heart...

Here is the point. When I use a commercial IDE, *I don't need to think*
about these things. The IDE takes care for these details for me, and I'm
doing what I wanted to do - to write a code. I don't need to think about
how it is implemented in the _commercial_ IDE I'm using. As for
macro DSLs, this is a part of compiler job to do and determine it for
me, not my. It is a part of compiler _services_ it could provide me as a
servant to make my life easier. Let it be not precise and not accurate -
but there should be at least an _attempt_ to help me.
And it is not a wet dream - IntelliJ IDEA does this stuff already for
Java, which is supposedly the more inferior language. 

Mark Green <mark@antelope.nildram.co.uk> writes:

> There is already Cursive IDE for IntelliJ, maybe it could be extended to Common Lisp as well as Clojure?
>
> My guess as to why things like slots/classes don't have special treatment in the IDE is that they are
> macroed and doing so would make any programmer-defined macro DSL become a "second class
> citizen" unless they also defined an IDE extension for it which would be extremely complicated.. unless
> there was some way of specifying IDE properties of a macro inside its definition, but even that would
> complicate the definition..
>
> Mark
>
>

-- 
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...

As far as I am concerned, it is not the language – I have written programs in many languages for different purposes. When the objectives of the program are met, the language used is mostly inconsequential as long as I didn’t have to stand on my head to make the writing productive.

So, to me, it is the development tool that matters more – a good one is one that does not get in my way and allows me to write tight, functional and easily testable code.

Hence, I still believe that the finest, easiest, and by far the most productive development environment I ever programmed in was a Symbolics 3600 in the 1980’s.

Still has not been equaled, IMHO.

From: Alessio Stalla [mailto:alessiostalla@gmail.com]
Sent: Friday, April 29, 2016 08:42 AM
To: Mark Green <mark@antelope.nildram.co.uk>
Cc: Alexey Veretennikov <txm.fourier@gmail.com>; Robert Goldman <rpgoldman@sift.net>; Rangarajan Krishnamoorthy <ranga@mmsindia.com>; Syed Zaeem Hosain <Syed.Hosain@aeris.net>; Paul Tarvydas <paultarvydas@gmail.com>; David McClain <dbm@refined-audiometrics.com>; LispWorks <lisp-hug@lispworks.com>
Subject: Re: Sadness in my heart...

I think it's more because Lisp IDEs, ironically, are ultimately TEXT editors and not SEXP editors (including Paredit and similar). IntelliJ does a lot of parsing/compilation to infer things about your source code. In Lisp it should be easier to work with S-expressions directly and keep additional metadata, like this expression was loaded from file x at line y with this textual representation, but Emacs/SLIME work mostly on text, not code. Which is a shame.

On 29 April 2016 at 17:15, Mark Green <mark@antelope.nildram.co.uk> wrote:

There is already Cursive IDE for IntelliJ, maybe it could be extended to Common Lisp as well as Clojure?

My guess as to why things like slots/classes don't have special treatment in the IDE is that they are macroed and doing so would make any programmer-defined macro DSL become a "second class citizen" unless they also defined an IDE extension for it which would be extremely complicated.. unless there was some way of specifying IDE properties of a macro inside its definition, but even that would complicate the definition..

Mark

Re: Sadness in my heart...

Alexey Veretennikov <txm.fourier@gmail.com> writes:

> Here is the point. When I use a commercial IDE, *I don't need to think*
> about these things. The IDE takes care for these details for me, and I'm
> doing what I wanted to do - to write a code.

The problem is that so far "these things" are nothing, or not much.  Is
the loss of customizability worth having them?

And they're implemented only for some specific languages, not for lisp
or your own DSL.

Perhaps when we'll have Artifically Intelligent IDEs, that will debug
your code or just generate the correct code from the specification
document, perhaps then it'll be worthwhile losing customization and
choice of programming language.  But since in 2015 they are still
catching up with features you had in the "unix IDE", (and I'm not even
talking about the lisp environments), I still have strong doubts about
IDEs.

-- 
__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...

Just have to say it, as a matter of fact...none like lisp, done little with it though due to the urgency of delivering apps in Java and objective C for my organisation's mobile Apps...but the power in just fiddling with it amazes me...

Languages like obj c is cool, having a lot of dynamic capabilities like categories, cool serialisation API's(NSCoder and co), cool event API(GCD) but somehow noticed they all try to mimic one feature of lisp or the other...

How fortunate are you if you can harness the power of lisp.

Looking forward to ride the waves soon.

Seyi

On Sun, May 1, 2016 at 12:04 AM, Paul Tarvydas <paultarvydas@gmail.com> wrote:

I mostly agree with Pascal’s reservations about IDE’s.

AFAICT, the IDE was invented (enabled) in 1956 with the *language* Lisp 1.5.. The *language* contains the equivalents of LEX and YACC. The *language* can act on itself.

In my first Dr. Dobb’s article (1978/9?) I published source code for a SEXP editor and debugger in lisp.

Other *languages* got IDE-envy and have been struggling to catch up. Rather unsuccessfully, afaict. If the *language* doesn’t have “LEX and YACC” built into it, you have to jump through hoops to get an IDE that is 50% as good as a lisp environment.

Then, there’s the Unix (shell) environment, which makes things incredibly easy and simple. Around the same time as the Unix shell was invented, there was another development, called FBP (flow-based-programming) which is even better at piping than the Unix shell is. (Still actively discussed and developed - see google group flow-based-programming).

The modern IDE is necessitated by inferior languages designed by syntax fascists.

We should strive to getting rid of syntax and going back to simplicity.

[Other examples of such wonderful simplicity are Rebol and the Smalltalk Blue Book].

pt

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