Yak Shaving #-1: The good news, the bad news and the Yak Shaving.

The good news are: I have definitely decided that GTK is not worth fighting with it, facing a Qt as an alternative. The difficulties to find a documentation/explanations (and alive people who would have had the knowledge and were willing to help) were so big that I decided to cancel the complete topic altogether.
The bad news is the other side of the good one: I gave up on GTK and if I want to implement any GUI stuff, Qt is an option as it just has more clear future.
But the ugly news is the fact that there is no sense to do anything based on Qt for GIMP. Or at least it sounds a bit perversely. I am not sure I want to touch it even with a 10-meter stick.

Ah yes, and one more thing. I see no place for lisp there anymore.

Hopefully Yak Shaving is over.

For those who are interested, the original idea was to introduce the non-destructive editing into GIMP. After fighting with the GTK+ (and a little bit with Lisp world, too, because I cannot imagine any good reason for developing a graphics editor on plain C in 2015), and also after confirming that there are proprietary but inexpensive alternatives to Photoshop (like Bloom) with aforementioned non-destructive abilities, I decide to give up on this topic as on not interesting. In my opinion it has no or too less potential.

Balm for my wounds

Just in time I have discovered beautiful source of the information: planet lisp. Yes, I didn't see it before.

Anyway, there after digging into old archives, I have found this: Starting to Hack on SBCL.

It is exactly what I need now. The motivational article with a number of pragmatic guidelines and examples.

Just in time, just in time...

Rants on GTK+, Common Lisp, and Emacs

TL;DR: I think I'm going to give up trying Common Lisp for prototyping related to the GIMP development despite the topic still looks extremely attractive.

After looking at the GIMP source code I've got an idea to introduce the non-destructive editing feature to the GIMP editor. Unfortunately, the architecture of the GIMP is not that flexible in case I want to stay compatible to the previous version of the GIMP. So I was thinking of utilising the "parasites", which are some form of the "comment" field on some objects in the GIMP land. As this is still a subject to explore plus my ideas could have changed during the development, I concluded to give the Lisp a try as it seems to fit the requirements of the exploratory programming. The main reason to switch the language in the first place was enormous amount of the boilerplate code for GTK+ in C and the fact that the C language being kind of a cross-platform assembler, is good for some low-level tasks, but not for everything. I would put it in the way that C is good for final polishing and Lisp is good for initial rough strokes. My tasks seem to be pretty high-level and... rough.

Now let me explain the problems I have faced.

First off, if you are a so-called mainstream developer, the chances are high that you are accustomed to  some tools and approaches like use of particular IDE, toolchains, frameworks and so on. With CL (Common Lisp) it seems to be completely different world which needs to be explored and understood. Usually this problem is referred to as the "steep learning curve" of the Lisp. But I would like to get rid of the general words and to present the exact problems. So, in detail it looks as follows:

1. First off, one needs to learn the language itself, I mean the syntax, the concepts and so on. The power of the CL language is enormous and cannot be underestimated. I've got a feeling that for the programmer this power serves as a carrot in front of the donkey. It is very strong motivation and rightfully so.
2. Coming back to the earth, one has to set up the working environment. And here almost everything related to CL is bad, because you cannot use the "general purpose" IDE like Eclipse or similar. You have to use either Emacs+SLIME, or solutions from Allegro. For other possibilities I can say nothing as the aforementioned two are most popular. Looking at these two it is clear that choosing Allegro means choosing not only the IDE, but also the set of the libraries, which is not acceptable in my case. So I had really only one choice: Emacs+SLIME. Well, long story short I've dealt with this task more or less successfully. But it took both time and motivation.
3. Anyway, now with IDE it seems we can see the CL it its shiny glory, right? Right? Well, not really. You know, the language itself is almost nothing without the necessary libraries unless we are talking about some very specific tasks of extremely low-level hacking. So, what about the libraries? Looking at the specification of the CL I had a hope that it can be perfectly integrated with C code as both languages have well-defined ABI and FFI. After all, we have a CFFI in CL, which is exactly the means to integrate with C code. It works well for simple examples. But I need the support of the GTK+ in my research. Moreover, the latest GTK3 version. And GTK+ is all but the simple thing. I mean, the ideas behind are simple, but the implementation is unpleasantly complex. I have to admit that it is not over engineered in terms of the run time, but still it is complex, it even has an internal garbage collector. It is really strange thing: OOP with GC implemented in plain C.
   Now, the main problem with CL+GTK is that it does not work. Even worse, it works, but sometimes crashes. So you run the code, it works. You try run it again, it does nothing. You run it for the third time, it hangs and after all should be killed by the OS. Now, you restart the lisp system(!) as it disconnected from the Emacs, and the code cannot be compiled because of some strange error. Then you kill all Emacs buffers and restart the lisp from the scratch and you are again on the first step of this sequence.
4. Now, one can say that the problem is not in the CL, but in the developer. I can accept that taking into account that there are successful CL programmers in the wild. But if one wants to learn something which is done by other people, he should get the information from somewhere. Normally from books or their equivalents like blogs and so on. And here CL is really in bad condition. Maybe it is because the community is small, I don't know. But the fact is that there are no practical sources of information for the topics I am interested in. In case you are not interested in graphics or in low-level stuff, there is "Practical Common Lisp" by Peter Seibel. I've also read the "Artificial Intelligence Programming" by Peter Norvig and "OOP in CL" by Sonya E. Keene, and "SICP" and others I could find. There are not so many in fact. Maybe I am annoyed with the fact that I cannot get the environment with "batteries included". I have a feeling that batteries are discharged, disassembled and buried. And yes, I have forgotten to mention that there are many libraries for the very same things so in case one wants a solution for something, you will have some moments of the analysis paralysis trying to compare all the available libraries for the same stuff. In case someone says I could have taken Allegro it has "batteries included", I can comment that it is possible of course. But it is very difficult for me to accept the fact that in case I have to switch from Allegro, I have to rewrite the code again to use different libraries. Plus, why the heck did I invest so much time into learning the Emacs then? Isn't it ironic?
5. Now, all described problems are just preliminary tasks before the integration of CL and GIMP, which itself is complex. To be fair, I even did not touch this problem at all, despite this is the goal and initially looking at some inspiring videos by Zach Beane and by Marco Baringer. I have a feeling that in CL I can use a top-down development approach moving down from the final target to the final implementation using its interactive capabilities to implement the necessary functionality step-by-step. Even more, people like Zach demonstrate this. I would really like to know how he got to that point. I am not sure he knew everything from the very beginning. It is really important to know how to learn this. Alas, this information is not available. In the past (199x-200x) when I faced the problems like this with other languages/technologies, I could always ask the community. Usually I could do it in real world, not online, which is very important for efficiency at least. Even if people did not know the answer, which was very often, they anyway provided some information which I could analyse and as a result, I knew more and more. With CL, even if we ignore the "real world", the community is somehow not that much helping.

I am not giving up completely now as the carrot in front of me looks extremely tasty, but I am really annoyed with amount of slowing me down unnecessary difficulties which I get on my way.

I remember the ease of use of the first Delphi back in nineties, it was so easy, so intuitive. I had to think only about the programming only about the real task, and IDE delivered the concentrated joy letting me not to think about GUI. Delphi took away the difficulty of programming the GUI, it just made all that stuff move off my way. Again, the Delphi was the moment of "quantum leap" as I have got rid of a lot of the headache in one step, not more, not less.

I recalled the Delphi simply because the current situation seems to be perfectly opposite: every possible and impossible difficulty comes between me and the final goal. Actually these memories are exactly the reason I learned the Emacs, as I was promised so many times that Emacs is a silver bullet for programming / text editing. Recalling the silver bullet from the past (the Delphi) I could imagine the ease of use of the tool and therefore invested the time into learning it. Now I know the Emacs to the level I think I can teach it. But you know, if I compare it to say Sublime, in reality it is on par. Yes, it is programmable and so on, but Sublime is also not that bad.

To summarise, the complexity still grows and the chosen tools (Common Lisp plus friends) are not helping to decrease it yet. Moreover, they add their own complexity. But the hope remains. I hope that at some moment I will be able to automate all the tasks so that I will be able to concentrate only on the interesting topic.