4 ms·

McCLIM 0.9.7 "Imbolc" release

67 points by jackdaniel 9y ago

carry_bit 9y ago
Is there anything like CLIM available for JavaScript? My time playing with McCLIM years ago made an impact. I've made things inspired by it over the years, but nothing close to the framework itself.
- lf-non 9y ago
  Can you elaborate what you would expect from such a system ? As someone not having much familiarity with CLIM or common lisp, I seem to be lacking the perspective to appreciate the relevance of this technology in 2018. Things like support for truetype rendering, bezier curves, tab layout etc. are not exactly cutting edge advancements.
  - jackdaniel 9y ago
    These things are just improvements to catch up with rendering and things people require from toolkits currently. Where CLIM really shines is its model of presenting things (and this is something developed long time ago). UI is not just a rectangular area where you slap things (which may be eventually clicked). It is rather a representation of the application state and possible interactions with it. In McCLIM presented objects have types and inner state. When you activate command you may select arguments (which are typed) on the screen or by doing a particular gesture. Same object may be presented differently based on a view. Relevance is not about sexy new things from the last month. I don't know JS well, but my impression is that rotation of technologies in its ecosystem is pretty big, what may be a clue, that abstractions may be just so-so. CLIM is a specification which covers many concepts required to build efficient and extensible user interfaces.
    - lf-non 9y ago
      The rotation of technologies that depend on (and attempt to simply) the abstractions exposed by the browser's host APIs may be quite frequent, however the underlying DOM model seems very similar to what you are describing here. The web standards have a stellar track record of backward compatibility. > UI is not just a rectangular area where you slap things (which may be eventually clicked) Web developers (or application developers) in present day world don't write routines to draw things on canvas (although you can if you really have a use case [1]). We program against the dynamic DOM tree, which presents our application state. We have sophisticated data binding libraries [2] to bind javascript models with the DOM tree. The emergent web component standard appears very similar to what you describe as "presented objects having types and inner state". > Relevance is not about sexy new things from last month When asking the question my objective was not to deride the effort that has gone behind this project. It is just that the current application homepage does not do a very good job of convincing a present day developer the appeal of developing GUI systems using common lisp. Also an X server is required to run the applications, which, excluding linux users, is not something most people have installed now a days. [1] For example paper.js implements a scene graph model on top of canvas. [2] Mobx is a popular library for transparent functional reactive programming in javascript.
      - carry_bit 9y ago
        React gets you close. I've thought about trying to write a library to add a command loop and presentations to React, but haven't gotten around to it.
      - aidenn0 9y ago
        I'm probably more familiar with JS than Dan is, so let me address some things: You could, eventually, implement something similar to CLIM presentations with web components. You could also implement something a lot like webcomponents with CLIM presentations. They are quite different though. I have not used MobX, but I just browsed the intro page (yes it's way better at explaining what it is than CLIM is). CLIM doesn't really compare apples-to-apples with React/MobX, since the abstractions used are different, but they are both approaches to providing simple ways of presenting and manipulating domain state with a gui. In particular MobX actions and CLIM commands have some similarities, but also significant differences. Also, (assuming MobX doesn't change this) React is typically used to provide declarative rendering of the full application state. CLIM allows you to do this, but it is more common to have each bit of state declaratively rendered, while treating the UI state imperatively. This was absolutely necessary 20 years ago, and is still often a good idea today (look at some of the gymnastics Netflix has had to do to make long-lists render efficiently in React; with imperative state you can just keep appending and CLIM doesn't care because non-visible state won't get re-rendered until it is needed; granted some of that is also because the DOM is a different level of abstraction than a local GUI window...). On the other hand, after doing some javascript GUIs, I think I'll be more intentional about when I make this divide in CLIM applications; declarative GUIs are almost always easier to reason about.
    - lf-non 9y ago
      I just found your demo video about McCLIM (https://www.youtube.com/watch?v=kfBmRsPRdGg https://www.youtube.com/watch?v=kfBmRsPRdGg) and found it to very helpful to put things you outlined into perspective. I have linked to it in a top level comment.
  - cat199 9y ago
    > the perspective to appreciate ... basically, clim is like a way to manipulate language objects directly.. so you kind of build an object model & functions in lisp, and the ui to manipulate runtime state.. while in a rough sense the same could be said for any gui, with clim + a lisp repl the two are much more tightly coupled - think of it as like a graphical repl sort of thing.. the UI and object definitions can be manipulated while the program is run (each from the other) .. e.g a gui to call a function which generates a new gui based on some modified parameters and then generate a new function becomes possible and even trivial.. as far as base UI or building basic 'applications', no, this will give you buttons, etc just like any other; as for an 'interactive runtime environment', it is quite something else. as for 2018.. this is pretty irrelevant - "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. "
  - aidenn0 9y ago
    TTF, bezier curves &c. are just things for modernizing the look of McCLIM, which is itself just one implementation of CLIM 2. The most interesting thing about it is probably the presentations. It's very similar to MVC in that there is an object, a visualization, and things you can perform on the object, but it's different in that CLIM does a lot of the heavy lifting for you. All things that have different presentations are considered distinct types so if a command expects e.g. a distance, then objects on the screen representing distances would be active, but other numeric objects would not be. CLIM treats the GUI as just a visual representation to program state, and then mouse and keyboard actions are just visual ways of manipulating the program state. Other toolkits have tried similar things, but most of them fail to be useful for practical applications. CLIM has been shown to be very useful for certain practical applications (e.g. various types of debuggers/state inspectors are almost trivial to write in it), and it is also great for converting command-line programs into GUI programs. I don't use McCLIM mainly because it is right now tied into X11 (also until the past few years it wasn't clear that there was any place to submit bugfixes to). However, I am very glad I explored using it, because it has affected the way I think about GUIs. If you've heard of "Perlis languages," then this is a "Perlis library"
  - carry_bit 9y ago
    Pretty much what jackdaniel mentioned. This is another good summary: http://random-state.net/files/how-is-clim-different.html http://random-state.net/files/how-is-clim-different.html Being able to interact with graphical, living objects makes for a really nice experience. Notebook-style interfaces are another variation on it.
- kryptiskt 9y ago
  Lively Kernel attempts to do a direct manipulation UI built on web technologies: https://github.com/LivelyKernel https://github.com/LivelyKernel https://lively-web.org/welcome.html https://lively-web.org/welcome.html
jf 9y ago
It took me a while to find, examples of user interfaces made with CLIM can be found by scrolling down on this page: https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html
lf-non 9y ago
For the uninitiated, McCLIM demo [1] by Jack Daniel is a very good introduction to REPL driven GUI programming using Common Lisp and McCLIM. [1] https://www.youtube.com/watch?v=kfBmRsPRdGg https://www.youtube.com/watch?v=kfBmRsPRdGg
- IronBacon 9y ago
  There's also a video by Jeremiah Stoddard that shows a live programming session based on McCLIM where he codes a "snake" game https://www.youtube.com/watch?v=Rdb17YDRTVc https://www.youtube.com/watch?v=Rdb17YDRTVc

67 points by jackdaniel 9y ago

Is there anything like CLIM available for JavaScript? My time playing with McCLIM years ago made an impact. I've made things inspired by it over the years, but nothing close to the framework itself.

lf-non 9y ago
Can you elaborate what you would expect from such a system ? As someone not having much familiarity with CLIM or common lisp, I seem to be lacking the perspective to appreciate the relevance of this technology in 2018. Things like support for truetype rendering, bezier curves, tab layout etc. are not exactly cutting edge advancements.
- jackdaniel 9y ago
  These things are just improvements to catch up with rendering and things people require from toolkits currently. Where CLIM really shines is its model of presenting things (and this is something developed long time ago). UI is not just a rectangular area where you slap things (which may be eventually clicked). It is rather a representation of the application state and possible interactions with it. In McCLIM presented objects have types and inner state. When you activate command you may select arguments (which are typed) on the screen or by doing a particular gesture. Same object may be presented differently based on a view. Relevance is not about sexy new things from the last month. I don't know JS well, but my impression is that rotation of technologies in its ecosystem is pretty big, what may be a clue, that abstractions may be just so-so. CLIM is a specification which covers many concepts required to build efficient and extensible user interfaces.
  - lf-non 9y ago
    The rotation of technologies that depend on (and attempt to simply) the abstractions exposed by the browser's host APIs may be quite frequent, however the underlying DOM model seems very similar to what you are describing here. The web standards have a stellar track record of backward compatibility. > UI is not just a rectangular area where you slap things (which may be eventually clicked) Web developers (or application developers) in present day world don't write routines to draw things on canvas (although you can if you really have a use case [1]). We program against the dynamic DOM tree, which presents our application state. We have sophisticated data binding libraries [2] to bind javascript models with the DOM tree. The emergent web component standard appears very similar to what you describe as "presented objects having types and inner state". > Relevance is not about sexy new things from last month When asking the question my objective was not to deride the effort that has gone behind this project. It is just that the current application homepage does not do a very good job of convincing a present day developer the appeal of developing GUI systems using common lisp. Also an X server is required to run the applications, which, excluding linux users, is not something most people have installed now a days. [1] For example paper.js implements a scene graph model on top of canvas. [2] Mobx is a popular library for transparent functional reactive programming in javascript.
    - carry_bit 9y ago
      React gets you close. I've thought about trying to write a library to add a command loop and presentations to React, but haven't gotten around to it.
    - aidenn0 9y ago
      I'm probably more familiar with JS than Dan is, so let me address some things: You could, eventually, implement something similar to CLIM presentations with web components. You could also implement something a lot like webcomponents with CLIM presentations. They are quite different though. I have not used MobX, but I just browsed the intro page (yes it's way better at explaining what it is than CLIM is). CLIM doesn't really compare apples-to-apples with React/MobX, since the abstractions used are different, but they are both approaches to providing simple ways of presenting and manipulating domain state with a gui. In particular MobX actions and CLIM commands have some similarities, but also significant differences. Also, (assuming MobX doesn't change this) React is typically used to provide declarative rendering of the full application state. CLIM allows you to do this, but it is more common to have each bit of state declaratively rendered, while treating the UI state imperatively. This was absolutely necessary 20 years ago, and is still often a good idea today (look at some of the gymnastics Netflix has had to do to make long-lists render efficiently in React; with imperative state you can just keep appending and CLIM doesn't care because non-visible state won't get re-rendered until it is needed; granted some of that is also because the DOM is a different level of abstraction than a local GUI window...). On the other hand, after doing some javascript GUIs, I think I'll be more intentional about when I make this divide in CLIM applications; declarative GUIs are almost always easier to reason about.
  - lf-non 9y ago
    I just found your demo video about McCLIM (https://www.youtube.com/watch?v=kfBmRsPRdGg https://www.youtube.com/watch?v=kfBmRsPRdGg) and found it to very helpful to put things you outlined into perspective. I have linked to it in a top level comment.
- cat199 9y ago
  > the perspective to appreciate ... basically, clim is like a way to manipulate language objects directly.. so you kind of build an object model & functions in lisp, and the ui to manipulate runtime state.. while in a rough sense the same could be said for any gui, with clim + a lisp repl the two are much more tightly coupled - think of it as like a graphical repl sort of thing.. the UI and object definitions can be manipulated while the program is run (each from the other) .. e.g a gui to call a function which generates a new gui based on some modified parameters and then generate a new function becomes possible and even trivial.. as far as base UI or building basic 'applications', no, this will give you buttons, etc just like any other; as for an 'interactive runtime environment', it is quite something else. as for 2018.. this is pretty irrelevant - "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. "
- aidenn0 9y ago
  TTF, bezier curves &c. are just things for modernizing the look of McCLIM, which is itself just one implementation of CLIM 2. The most interesting thing about it is probably the presentations. It's very similar to MVC in that there is an object, a visualization, and things you can perform on the object, but it's different in that CLIM does a lot of the heavy lifting for you. All things that have different presentations are considered distinct types so if a command expects e.g. a distance, then objects on the screen representing distances would be active, but other numeric objects would not be. CLIM treats the GUI as just a visual representation to program state, and then mouse and keyboard actions are just visual ways of manipulating the program state. Other toolkits have tried similar things, but most of them fail to be useful for practical applications. CLIM has been shown to be very useful for certain practical applications (e.g. various types of debuggers/state inspectors are almost trivial to write in it), and it is also great for converting command-line programs into GUI programs. I don't use McCLIM mainly because it is right now tied into X11 (also until the past few years it wasn't clear that there was any place to submit bugfixes to). However, I am very glad I explored using it, because it has affected the way I think about GUIs. If you've heard of "Perlis languages," then this is a "Perlis library"
- carry_bit 9y ago
  Pretty much what jackdaniel mentioned. This is another good summary: http://random-state.net/files/how-is-clim-different.html http://random-state.net/files/how-is-clim-different.html Being able to interact with graphical, living objects makes for a really nice experience. Notebook-style interfaces are another variation on it.
kryptiskt 9y ago
Lively Kernel attempts to do a direct manipulation UI built on web technologies: https://github.com/LivelyKernel https://github.com/LivelyKernel https://lively-web.org/welcome.html https://lively-web.org/welcome.html

jf 9y ago

It took me a while to find, examples of user interfaces made with CLIM can be found by scrolling down on this page: https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html

lf-non 9y ago

For the uninitiated, McCLIM demo [1] by Jack Daniel is a very good introduction to REPL driven GUI programming using Common Lisp and McCLIM. [1] https://www.youtube.com/watch?v=kfBmRsPRdGg https://www.youtube.com/watch?v=kfBmRsPRdGg

IronBacon 9y ago
There's also a video by Jeremiah Stoddard that shows a live programming session based on McCLIM where he codes a "snake" game https://www.youtube.com/watch?v=Rdb17YDRTVc https://www.youtube.com/watch?v=Rdb17YDRTVc