Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
To what extent Common Lisp is relevant in 2019?
153 views
Skip to first unread message
Bigos
Jan 22, 2019, 5:34:19 PM1/22/19
to
I have been playing on and off with CL for the last several years. Most
of my efforts were a hobby and tinkering with programming puzzles.
A while ago I have tried with using Lisp for desktop UI. I had the most
success with shinmera's qtools and then something was broken in the
updates and it has no longer worked. Also, I had mixed success with Gtk
based libraries. In the past, they worked flawlessly on Linux and on
Windows I had a freeze when I wanted to move or resize the window of the
example application. Recently, when I tried Gtk based examples on Linux
nothing has worked.
I have looked recently at the various options of working with C
libraries and saw the light at the end of the tunnel. I have looked at
grovel but did not make any progress with my simple example. The
documentation is not good. The only post on the internet that gave me
some information is here
https://www.reddit.com/r/lisp/comments/61efpo/tutorials_or_in_depth_examples_on_how_to_use/
Grepping ~/quicklisp/dists/quicklisp/software gave me some idea, how to
use it but that is far from one could expect from normal programming
languages.
So I wonder if there any point of trying to use Lisp in situations where
you have to nontrivially interoperate with any complex C libraries. Do
the advantages of Lisp still outweigh the problems encountered? Is it
worth to invest in proprietary paid for implementations? I was using
SBCL on Linux in my experiments is there any implementation that would
do better in those circumstances?
of my efforts were a hobby and tinkering with programming puzzles.
A while ago I have tried with using Lisp for desktop UI. I had the most
success with shinmera's qtools and then something was broken in the
updates and it has no longer worked. Also, I had mixed success with Gtk
based libraries. In the past, they worked flawlessly on Linux and on
Windows I had a freeze when I wanted to move or resize the window of the
example application. Recently, when I tried Gtk based examples on Linux
nothing has worked.
I have looked recently at the various options of working with C
libraries and saw the light at the end of the tunnel. I have looked at
grovel but did not make any progress with my simple example. The
documentation is not good. The only post on the internet that gave me
some information is here
https://www.reddit.com/r/lisp/comments/61efpo/tutorials_or_in_depth_examples_on_how_to_use/
Grepping ~/quicklisp/dists/quicklisp/software gave me some idea, how to
use it but that is far from one could expect from normal programming
languages.
So I wonder if there any point of trying to use Lisp in situations where
you have to nontrivially interoperate with any complex C libraries. Do
the advantages of Lisp still outweigh the problems encountered? Is it
worth to invest in proprietary paid for implementations? I was using
SBCL on Linux in my experiments is there any implementation that would
do better in those circumstances?
Pascal J. Bourguignon
Jan 22, 2019, 7:02:14 PM1/22/19
to
Bigos <ruby....@googlemail.com> writes:
> I have been playing on and off with CL for the last several
> years. Most of my efforts were a hobby and tinkering with programming
> puzzles.
>
> A while ago I have tried with using Lisp for desktop UI. I had the
> most success with shinmera's qtools and then something was broken in
> the updates and it has no longer worked. Also, I had mixed success
> with Gtk based libraries. In the past, they worked flawlessly on Linux
> and on Windows I had a freeze when I wanted to move or resize the
> window of the example application. Recently, when I tried Gtk based
> examples on Linux nothing has worked.
> I have looked recently at the various options of working with C
> libraries and saw the light at the end of the tunnel. I have looked at
> grovel but did not make any progress with my simple example. The
> documentation is not good. The only post on the internet that gave me
> some information is here
> https://www.reddit.com/r/lisp/comments/61efpo/tutorials_or_in_depth_examples_on_how_to_use/
> Grepping ~/quicklisp/dists/quicklisp/software gave me some idea, how
> to use it but that is far from one could expect from normal
> programming languages.
> So I wonder if there any point of trying to use Lisp in situations
> where you have to nontrivially interoperate with any complex C
> libraries.
Clearly, either you buy a commercial implementation, or else, it is
> I have been playing on and off with CL for the last several
> years. Most of my efforts were a hobby and tinkering with programming
> puzzles.
>
> A while ago I have tried with using Lisp for desktop UI. I had the
> most success with shinmera's qtools and then something was broken in
> the updates and it has no longer worked. Also, I had mixed success
> with Gtk based libraries. In the past, they worked flawlessly on Linux
> and on Windows I had a freeze when I wanted to move or resize the
> window of the example application. Recently, when I tried Gtk based
> examples on Linux nothing has worked.
> I have looked recently at the various options of working with C
> libraries and saw the light at the end of the tunnel. I have looked at
> grovel but did not make any progress with my simple example. The
> documentation is not good. The only post on the internet that gave me
> some information is here
> https://www.reddit.com/r/lisp/comments/61efpo/tutorials_or_in_depth_examples_on_how_to_use/
> Grepping ~/quicklisp/dists/quicklisp/software gave me some idea, how
> to use it but that is far from one could expect from normal
> programming languages.
> So I wonder if there any point of trying to use Lisp in situations
> where you have to nontrivially interoperate with any complex C
> libraries.
definitely no batteries included. You have to deal with those problems
yourself.
> Do the advantages of Lisp still outweigh the problems
> encountered?
most notably this will often brink you back down to the level of C
debugging.
> Is it worth to invest in proprietary paid for
> implementations?
perhaps you could try with biz.plan.accounting.
> I was using SBCL on Linux in my experiments is there
> any implementation that would do better in those circumstances?
will probably choose to avoid clisp, since it doesn't compile to native
code, and we use CFFI for portability anyways.
On macOS, you would use ccl.
--
__Pascal J. Bourguignon__
http://www.informatimago.com
Kaz Kylheku
Jan 22, 2019, 8:03:47 PM1/22/19
to
On 2019-01-22, Bigos <ruby....@googlemail.com> wrote:
> I have been playing on and off with CL for the last several years. Most
> of my efforts were a hobby and tinkering with programming puzzles.
>
> A while ago I have tried with using Lisp for desktop UI. I had the most
> success with shinmera's qtools and then something was broken in the
> updates and it has no longer worked. Also, I had mixed success with Gtk
> based libraries. In the past, they worked flawlessly on Linux and on
> Windows I had a freeze when I wanted to move or resize the window of the
> example application. Recently, when I tried Gtk based examples on Linux
> nothing has worked.
> I have looked recently at the various options of working with C
> libraries and saw the light at the end of the tunnel. I have looked at
> grovel but did not make any progress with my simple example.
I don't see how grovel can generate correct FFI in all cases, since it's
> I have been playing on and off with CL for the last several years. Most
> of my efforts were a hobby and tinkering with programming puzzles.
>
> A while ago I have tried with using Lisp for desktop UI. I had the most
> success with shinmera's qtools and then something was broken in the
> updates and it has no longer worked. Also, I had mixed success with Gtk
> based libraries. In the past, they worked flawlessly on Linux and on
> Windows I had a freeze when I wanted to move or resize the window of the
> example application. Recently, when I tried Gtk based examples on Linux
> nothing has worked.
> I have looked recently at the various options of working with C
> libraries and saw the light at the end of the tunnel. I have looked at
> grovel but did not make any progress with my simple example.
just going after declarations. I wouldn't use anything of this sort.
C functions have semantics that isn't revealed by the type signature,
like which pointers are in, out or in-out parameters, who allocates
what, and so on.
Speaking of this topic and Gtk, the libraries in Gnome have a system
("GObject Introspection") whereby semantic information about library
API's exported in libraries in XML form, stored in accompanying .gir
files. (Look for these on your Ubuntu or what have you and take a look
inside.)
If you can grok this XML, you should be able to generate more-or-less
correct FFI definitions from it.
Spiros Bousbouras
Jan 22, 2019, 11:54:54 PM1/22/19
to
On Wed, 23 Jan 2019 01:02:09 +0100
"Pascal J. Bourguignon" <p...@informatimago.com> wrote:
> I find the FFI in clisp better than in other implementations, but you
> will probably choose to avoid clisp, since it doesn't compile to native
> code, and we use CFFI for portability anyways.
Who's "we" ?
"Pascal J. Bourguignon" <p...@informatimago.com> wrote:
> I find the FFI in clisp better than in other implementations, but you
> will probably choose to avoid clisp, since it doesn't compile to native
> code, and we use CFFI for portability anyways.
Pascal J. Bourguignon
Jan 23, 2019, 4:50:25 AM1/23/19
to
Madhu
Jan 23, 2019, 11:36:59 AM1/23/19
to
* Kaz Kylheku <201901221...@kylheku.com> :
Wrote on Wed, 23 Jan 2019 01:03:42 +0000 (UTC):
> I don't see how grovel can generate correct FFI in all cases, since
> it's just going after declarations. I wouldn't use anything of this
> sort.
there is magic in github.com/rpav/c2ffi. It is dependent on the
vagaries of clang and it cannot handle bitfields in structs but afaik is
the best thing for generating ffi bindings from C.
Of course since you're working with the C-library you are expected to be
intimately familiar with the C API. There is a the wrapper that can put
a nice lisp-level interface over the C. To see that wrapper you have to
go look at yourself in a mirror.
> C functions have semantics that isn't revealed by the type signature,
> like which pointers are in, out or in-out parameters, who allocates
> what, and so on.
>
> Speaking of this topic and Gtk, the libraries in Gnome have a system
> ("GObject Introspection") whereby semantic information about library
> API's exported in libraries in XML form, stored in accompanying .gir
> files. (Look for these on your Ubuntu or what have you and take a look
> inside.)
cl-gobject-introspection in lisp is workable but very rough. (I
submitted some patches but the commits incorporated errors into the
patches and there are still some serious problems.)
The optimized syntax of cl-gobject-introspection is problematic, since
methods are called on objects there is no way to hack up eldoc editor
help for code one happens to be writing. The big advantage of using gir
here would be in assisting the programmer by doing introspection and
presenting completions structure which at code-writing time, that is
presently not workable with the present syntax.
> If you can grok this XML, you should be able to generate more-or-less
> correct FFI definitions from it.
The whole point of gir is that there are language bindings for lisp.
generating FFI definitions from gir xml is pointless, and they are
themselves generated from header and source file comments in a way
similar to a groveller.
Wrote on Wed, 23 Jan 2019 01:03:42 +0000 (UTC):
> I don't see how grovel can generate correct FFI in all cases, since
> it's just going after declarations. I wouldn't use anything of this
> sort.
vagaries of clang and it cannot handle bitfields in structs but afaik is
the best thing for generating ffi bindings from C.
Of course since you're working with the C-library you are expected to be
intimately familiar with the C API. There is a the wrapper that can put
a nice lisp-level interface over the C. To see that wrapper you have to
go look at yourself in a mirror.
> C functions have semantics that isn't revealed by the type signature,
> like which pointers are in, out or in-out parameters, who allocates
> what, and so on.
>
> Speaking of this topic and Gtk, the libraries in Gnome have a system
> ("GObject Introspection") whereby semantic information about library
> API's exported in libraries in XML form, stored in accompanying .gir
> files. (Look for these on your Ubuntu or what have you and take a look
> inside.)
submitted some patches but the commits incorporated errors into the
patches and there are still some serious problems.)
The optimized syntax of cl-gobject-introspection is problematic, since
methods are called on objects there is no way to hack up eldoc editor
help for code one happens to be writing. The big advantage of using gir
here would be in assisting the programmer by doing introspection and
presenting completions structure which at code-writing time, that is
presently not workable with the present syntax.
> If you can grok this XML, you should be able to generate more-or-less
> correct FFI definitions from it.
generating FFI definitions from gir xml is pointless, and they are
themselves generated from header and source file comments in a way
similar to a groveller.
Jon Atack
Jan 23, 2019, 11:40:18 AM1/23/19
to
In reply to the question in your subject header, I reckon its relevance is up to you.
After decades of working in assembly, C, and Ruby, I'm now writing my projects in Common Lisp: Mostly web APIs and database stuff with some statistics, math, and algorithms. Time will tell if that is naive, but so far I like what I see.
As a side note, I find Quicksearch (https://github.com/tkych/quicksearch) very handy for finding CL libraries.
After decades of working in assembly, C, and Ruby, I'm now writing my projects in Common Lisp: Mostly web APIs and database stuff with some statistics, math, and algorithms. Time will tell if that is naive, but so far I like what I see.
As a side note, I find Quicksearch (https://github.com/tkych/quicksearch) very handy for finding CL libraries.
Bigos
Jan 23, 2019, 2:01:55 PM1/23/19
to
0 new messages