This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile as applications language


16-Jul-00 15:11 you wrote:
> I've been thinking very seriously of Guile Scheme as an applications
> language -- one language for both ``development'' and ``extension,''
> reflecting a belief that extension is just distributed development.

I think it's good point. Guile is actually good application development
language. In fact I can not see intrinsic difference between application
development language and extension language. Just do not try to make it
"application language for time-critical applications". If application is
not very compilacted and/or must run VERY quickly the guile is obviously
not very good choice. But there are A LOT OF applications where main goal
is NOT to "make it run fast" but more like "make it run AT ALL without
crashes and lookups". For that type of applications guile is perfact choice:
usually there are A LOT OF logic which can be [relatively] slow and few
pieces (like playing embedded video-clips in tutorial :-) where you REALLY
need C.

> This recent talk reasserting the role of Guile as purely an extension
> language for apps otherwise written in C has made me have second
> thoughtss about trying to do serious app development in Guile. :)

> I think Guile is actually quite close to being a serious application
> development language, and one that would tend to result in nicely
> extensible apps.  Emacs has long been a model for extensible software,
> and I've found Emacs Lisp and its programming tools such as the Lisp
> Interaction mode and Edebug to be a surprisingly productive platform for
> apps work.  Of course Emacs Lisp has several major shortcomings as an
> applications language, since it wasn't designed to be one, and I see
> Guile addressing those shortcomings by having:

>   * Lots of Guile instances in small native OS processes/tasks, rather
>     than one large monolithic process.

Yes. It's vital for lots of things.

>   * Faster execution, perhaps with a compiler.

This is important to some extent but not THAT important. Emacs lisp is quite
slow in fact and still Emacs works fast enough on curent PCs.

>   * Dynamic-linking of native code modules for those few things that
>     really should be written in C or that are already written in C
>     (e.g., low-level system interfacing, high-performance graphics
>     libraries, legacy code libraries).

Of course.

>   * Good libraries for things such as parsing HTML and XML, Web
>     spidering, full-featured GUI programming (e.g., GTK+, GtkHtml, Gnome
>     Canvas), CGI, fast Apache integration, database integration, etc.

For that we need module system and GOOPS - it's in "should be ready really soon
now" state for year or so, right? :-((( And of course just binding/libraries
itself - someone should just sit and write GTK+ binding, HTML/XML parser
(perhaps with usage of libxml and such). There are already exist some bindings
though.

>   * Some language improvements, such as lexical scoping, module system, etc.

>   * Standard, easy-to-use, sufficiently-fast interprocess communication
>     mechanism, or distributed object system.  (OK, this is a wishlist
>     item.)

>   * Standard and fast object system for OO programming.

> Please note that this is just what I as one programmer would like to see
> from Guile; I couldn't presume to say what is the best role for Guile in
> the broad GNU Project.

> What do you think?


> P.S., If Guile does turn into an applications language soon, my own
>       contribution would probably be in the form of libraries for
>       Web-related things and such.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]