I want a simple timeline component (like in video editing software) for a clojure/seesaw app and I am wondering if it is a good approach to implement this directly with clojure and seesaw or if I should write it in java and make my clojure wrapper around it.
Or more generally: is a functional programming language optimal for writing UI widgets? I cannot imagine doing that without a lot of state involved. And wasn't OO invented for UI-development in the first place?
You could go either way. On Overtone, we've built a number of custom graphical components directly in Clojure with Seesaw. Many times, an atom and (seesaw.core/canvas) is sufficient for this kind of thing.
Depending on how fancy you're going to get, one reason to do it in Clojure is you can extend Seesaw's protocols (selection, binding, etc) to the new widget so it works seamlessly with Seesaw. Another consideration is whether your widget needs to make use of Clojure data from other parts of the app. This will be much cleaner from Clojure than Java.
That said, if you're comfortable in Swing/Java, you can do it there and Seesaw will be perfectly happy to work with a custom widget built in Java. Good luck!
FP is good for doing UI programming but for that the underlying UI framework should also be based on FP concepts like FRP etc. In your case the underlying UI framework (Swing) is OO based and hence it would be more easy to implement it in Java but you can still do it in seesaw.
All else being equal (i.e. assuming you know both Clojure and Java), I would probably write this as a custom Swing component in Java.
Reasons:
Swing is fundamentally a Java-based OOP framework and is a better fit with Java in terms of paradigm
Mutable state is easier in Java than in Clojure
If you write it in Java, you can use it elsewhere more easily (e.g. as a library from other Java code)
It's easy to wrap a Swing component in Clojure after you have created it
Of course, for the application logic itself I would certainly prefer Clojure.
Related
There are several packages out there that help in automating the task of writing bindings between C\C++ and other languages.
In my case, I'd like to bind Python, some options for such packages are: SWIG, Boost.Python and Robin.
It seems that the straight forward process is to use these packages to create C\C++ linkable libraries (with mostly static functions) and have the higher language be extended using them.
However, my situation is that I already have a developed working system in C++ therefore plan to embed Python into it so that future development will be in Python.
It's not clear to me how, and if at all possible, to use these packages in helping to extend embedded Python in such a way that the Python code would be able to interact with the various Singleton instances already running in the system, and instantiate C++ classes and interact with them.
What I'm looking for is an insight regarding the design best fitted for this situation.
Boost.python lets you do a lot of those things right out of the box, especially if you use smart pointers. You can even inherit from C++ classes in Python, then pass instances of those back to your C++ code and have everything still work. My favorite resource on how to do various stuff is this (especially check out the "How To" section): http://wiki.python.org/moin/boost.python/ .
Boost.python is especially good if you're using smart pointers or intrusive pointers, as those translate transparently into PyObject reference counting. Also, it's very good at making factory functions look like Python constructors, which makes for very clean Python APIs.
If you're not using smart pointers, it's still possible to do all the things you want, but you have to mess with various return and lifetime policies, which can give you a headache.
To make it short: There is the modern alternative pybind11.
Long version: I also had to embed python. The C++ Python interface is small so I decided to use the C Api. That turned out to be a nightmare. Exposing classes lets you write tons of complicated boilerplate code. Boost::Python greatly avoids this by using readable interface definitions. However I found that boost lacks a sophisticated documentation and dor some things you still have to call the Python api. Further their build system seems to give people troubles. I cant tell since i use packages provided by the system. Finally I tried the boost python fork pybind11 and have to say that it is really convenient and fixes some shortcomings of boost like the necessity of the use of the Python Api, ability to use lambdas, the lack of an easy comprehensible documentation and automatic exception translation. Further it is header only and does not pull the huge boost dependency on deployment, so I can definitively recommend it.
Why would it be better to use classes while programming in ASE than just using object oriented programming? Can you give me some good real world sittuations of when you should use classes? I'm asking this question because I want to better understand why I should use classes in flash apps I'm going to make and am making.
If you're just using AS code on frames, you're not using object oriented programming per-se, you're just running procedural scripts affecting objects.
The advantages for flash are the same for any other class-based OOP paradigm:
Separation of code into understandable hierarchy
"easy" code reuse
All design patterns that are associated with OOP
inheritance and extension
(for more just google "advantages of Object Oriented Programming")
I find that the advantages of OOP don't seem to make a difference during the first iteration. You're writing the same essential code either way. The advantage really comes out in the second or third similar project where you can start to reuse stuff that you made before, tweak a few parameters, extend a few classes, and have a different looking flash program without rewriting all the code.
If you make enough projects, eventually you'll find yourself with a library or framework of classes that you can easily reuse to make very powerful applications.
I just started using clojure today (however , I have used Java a lot and know of functional paradigms) and I was wondering if it was a good idea to build a clojure app with a reasonable complex interface (dragging, dropping, panning, zooming,...) using Swing?
I can imagine that a lot of the normal swing logics (especially concerning OO) has to be bypassed one way or the other..
I asume that all is possible , but is it possible in a way that justifyable?
I mean wouldn't it be like hitting a nail with a screwdriver in stead of with a hammer?
Has anyone here have experience in building GUI's with Clojure (and of Course : is Swing the ideal candidate for that?)
Thanks !
I've found it relatively easy to use Swing to build decent user interfaces in Clojure. You have a couple of options about how to do it however:
Write the code pretty much as you would in Java, just using the Java interop from Clojure to call the relevant Swing APIs. This article does a good job of explaining how, with a bit of macro magic as well to make your life easier.
Use a Clojure GUI wrapper for Swing, e.g. seesaw or clj-swing. My take is that these tools have the potential to help you write some really neat GUI code in idiomatic Clojure
One really cool feature of Clojure's software transactional memory subsystem is that it allows you to set watches on variables: whenever the variable is changed (by anything), your callback gets executed. This lends itself to a powerful sort of GUI programming where the GUI updates itself automagically based on the state of your variables.
A short but non-trivial Swing GUI example is described in detail at http://www.paullegato.com/blog/swing-clojure-gui-black-scholes/ .
Since others are mentioning swing related answers, I'll ask you one question: Is Swing a requirement. Although writing Swing code in clojure is more pleasant then in Java, it is still Swing, with all its verbosity and annoyances, especially in complex application with hard set requirements.
Have you considered web UI, where Clojure fits much more natural? Or SWT or QT Jambi, which also can be made to work using Clojure.
Do they have any common concepts like C++ and Java do? So that, anyone who learn either gets the basics of other? Like C++ and Java share some common concepts of OOP. You learn them in Java, you can apply them in C++ too and vice versa. Do, Qt and Swing has such property?
Since I have used both Swing and QT, I think that they do have some commons and being familiar with one can help you to learn the other faster. A good example is layouts. For example a grid layout is a grid layout no matter whether QT or Swing (or any other GUI library I guess) is used. The fundamental difference between the two frameworks is the event based nature of Swing (basically implementing listeners for everything and catching the generated events that interest you) vs. the slots and signals mechanism of QT.
All the web frameworks that I have seen mostly follow the OO paradigm. Are there any web frameworks in Python or Ruby which follow the FP style?
Like python itself, you'll probably find web frameworks in python that blend the functional and object oriented paradigms. Django is a great example. Django follows a model-view-controller design, which they label as model-template-view. The interesting thing is that the three layers operate very differently.
Model is object-oriented. It isn't necessary to make it a stellar example of everything OOP can be. You can be dirt simple with your models: you name it, extend a base model class, and declare a few properties. This, I think, is as it ought to be, and I'll be fascinated to learn of other frameworks that are significantly less object-oriented at the model-layer. Your database needs table declarations, and your site needs to generate rows of data. This is extremely analagous to Classes and Instances no matter how you look at it.
Template is not python. It's supposed to look as much like html as possible, with some pretty ways to insert data that gets passed to it.
View is very functional. It can be coerced into an OO paradigm, and it can rely on the models to do the heavy lifting if it wants. But at core there are function declarations that execute some action. These function declarations are passed as arguments to a url config function.
I happen to like this blend of paradigms because I believe it does what works well for each given level. Some might call it inconsistent; others might say that the distinction between between model and presentation logic should be as sharp as possible to emphasize the distinction.
If you don't care much for OOP but can function in python, this framework might work well for you. Unless you're trying to leverage the default admin interface. Then metaclasses and formsets will make your head a'splode.