John Stevenson

If you are connected to the Internet you can simply use BootstrapCDN - its bootstrap on the Internet, so you get the web address (URL) instead of having to worry about your folder structure

See http://www.bootstrapcdn.com/ for details:

Basically you use the following code in your html file:

<link href="//netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css" rel="stylesheet">
<script src="//netdna.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.min.js"></script>

If you dont intent changing anything in bootstrap, then its a nice approach.

Thanks
John.

Hello,
Do you include any tips for including live coding demos in your presentation?

I practice live coding demos several times until I can do it off by heart. I found crib sheets tended to slow me down, as does trying to talk and type. If anyone can share any tips on how to talk and type at the same that would be most welcome.

As I backup I'll sometimes create a screencast of the demo, especially if the demo needs a good internet connection or its a relatively new demo.

I try and avoid cut & paste or typing of a lot of code, although some times its unavoidable. So am also experimenting with git and branches to see if that is a good way to keep things going at a decent pace.

As ever, I continue to pray to the demo gods before every live coding session

Thanks
John.
@jr0cket

Chris Creed wrote:Good evening

Was wondering what the target audience of this book would be, or how "simple" will it be? Is it geared towards those that have experience in another functional language? Any coding experience at all? Completely raw right off the street? Will it explain why Clojure could offer that other language such as Scala and Java cannot?

The book requires no prior knowledge of functional programming, the aim is to help any one understand the basics of Clojure. You should be able to write simple Clojure applications and quickly evaluate for yourself if you are ready to invest more time in learning Clojure.

There are many great books out there that go into Clojure in a great depth, although they can be hard going for those new to functional programming. So Clojure Made Simple aims to grow curiosity about Clojure and encourage you to go and learn more.
a
In 100 pages its not possible to introduce all of Clojure, never mind draw comparisons to other languages. If you want a comparison, then this has been done very well in the book 7 languages in 7 weeks, so there seemed no need to repeat that.

Thanks
John.

Sunderam Goplalan wrote:Hi John,

Coming from a Java Background, when I learnt Java Script, I liked many features that Java script offers that are not available in Java. For instance, the power comes from Java Script being a
dynamically typed language and functions are first class objects. i.e. they can be passed around seamlessly. I believe the same is true in Clojure. And JavaScript is a functional language too,
like Clojure.

Even though Clojure and Java Script may not be directly comparable as they solve different goals, would it be reasonably accurate to say Clojure SHARES most of the features of JavaScript?
If NOT, how is Clojure fundamentally different from JavaScript?

Thanks
GS

Hello Sunderam,
JavaScript is taking over the world it seems and its a language that is useful to know for all programmers. There are common concepts in place between the two languages, although I'd suggest that the design and thinking process is quite different. There is also ClojureScript to consider. ClojureScript allows you to write Clojure where otherwise you would write client-side JavaScript. So just as JavaScript is heading into the server side with nodejs, Clojure is venturing into the client side with ClojureScript.

Probably the most obvious difference is in the data structures core to each of the languages. Clojure has sequences (immutable lists, vectors, maps and sets) and I am not aware of constructs in the JavaScript language that provide similar immutable data structures.

One common design approach in Clojure is to create a very clear data structure (often a big map) and define functions that act upon that data structure. With good design you can infer much of the concepts about an application by first looking at the data structure. If all the functions access the data structure without changing its state, then there is greater certainty as to what a function will do. In mathematical terms, given the same data in to a function, you should get the same result out. This is also true when your data structure is immutable.

For those times when you do need to change state, this can be easily managed in Clojure under the hood using software transactional memory (STM). STM is kind of like having an in-memory transactional database for your data, so that only one function can change state at any one time. Even when you do make a change, you are really creating a new data structure. This new data structure is efficient as it points back to original and only contains changes.

On a much smaller note, I personally find the Clojure syntax more elegant and concise compared to JavaScript, especially when writing non-blocking code.

Hope this gives you a few ideas, there is so much more detail to go into (you could write a book on it)

Thanks
John.

Sean Corfield wrote:There's a very nice library called Seesaw that makes building desktop Swing applications almost pleasant: https://github.com/daveray/seesaw

I haven’t done much desktop Java with Clojure, although the little I have done I found it much easier than using Java itself. There is a function in Clojure called doto that helps you chain functions together, making your code much easier to follow and cleaner than the GUI code you need to write in Java. Is it following the functional programming idiom, possibly not in a pure way, but I'd consider it a more attractive option that writing all that GUI code in Java. However, there were quite a few GUI applications developed in Scheme over the years, so it would be interesting to see if there are any good concepts functional GUI development to discover.

I would certainly recommend using Seesaw if you wanted to develop Java desktop applications, along with the Netbeans platform.

Thanks
John.

Mike Gage wrote:Is there an advantage to using Clojure rather than Groovy?

In many ways Clojure and Groovy are closer in syntax than Clojure and Java. If you take the Class definitions out of Groovy and just have functions, you would see many similarities in syntax. However, (please correct me if I am wrong), Grovvy is still based around an OOP approach rather than a functional programming approach. Not that you cant write functional code in Groovy I am sure, I just havent seen the language constructs that make it a natural thing to do. For parallelism, there is a great library for Groovy called GPars, but have not worked with this or looked at the code.

The immutable nature of Clojure is certainly different from what I understand of Groovy. With Clojure, immutable data structures (list, map, vector, set) are baked into the language. When you define one of these data structures (collectively know as sequences) it is immutable, you dont need to qualify it with anything else. In Groovy (and Java) you have to explicitly define something as immutable (using final / final static).

For example, if you create a list with the contents (a, b, c) then the contents of that list cant change. If you want to change that list then Clojure actually creates a new list for you under the covers, so anyone code still processing the original list will remain unaffected. You can change the names you use to reference a list, but the underlying list cant change.

Both Clojure and Groovy are dynamic and have a runtime environment (REPL). Use of the REPL is something that Clojure developers make use of heavily, I have not seen as much of this with Groovy developers, but that’s just my experience. Tooling support is good for both languages in IDE's such as Netbeans, Eclipse and Intellij. Many Clojure developers use Emacs or Vim as a lighter weight development environment that IDE's. Clojure and Groovy both have great build tools, Leiningen for Clojure and Graddle for Groovy (and other languages).

There are probably many similarities and differences between Clojure and Groovy, although my Groovy is a bit too rusty to offer a more in-depth comparison. I'd state that the main one is the paradigm each language uses, functional vs OOP.

Thank you
John Stevenson

Runrioter Wung wrote:I have never learnt Clojure and just heard about it.And I know it is the same as Java based on JVM.I doubt how Clojure makes a difference. Compared with Java or other languages based on JVM? And make what simple?
Looking forward to your reply.

As others have mentioned here, although both Clojure and Java run on the Java Virtual Machine (JVM), the are both very different languages in terms of syntax and paradigm. Java is a procedural language based on OOP and Clojure is a declarative language based on functional programming.

Clojure encourages you to create code where you do not change state (immutable variables) as in this way it is simpler to write applications that scale through parallelism. This is one reason why Clojure is great for working with big data sets. As Clojure is dynamically typed, it also means it is great for working with very adhoc and unstructured data sets (unfortunately which most data sets are).

The great thing about both languages running on the JVM is that its pretty easy to call code written in Java from code written in Clojure (and vice versa). So you dont have to throw away any Java code you already have (unless you want to).

What am I trying to make simple with the book? I hopefully have made it easier to understand the value of Clojure and give developers new to the language a good kickstart. I have kept the book "simple" so that this can be done relatively quickly.

Thanks
John Stevenson