I think this is one of my favorite features that we've added to Light Table recently and it shows one of the benefits of being connected to a running process of the language you're working with: you can use the tools of that language to write code for you. There's nothing that makes this Clojure specific - you could do these same things in any other language too.
actually the tools for doing this in other languages have gotten a lot better than they used to be. Using esprima you can do some pretty neat code rewriting in JavaScript and Python includes ast tools in the standard lib. Plus if more new languages start to include things like gofmt by default then we'll end up with more of this stuff as first class. Either way though, it's nearly always the case that the platform itself has the best tools for doing this, so at the very least if gives you the best possible chance. :)
If someone is interested in how kibit is implemented I've got some slides at http://jonase.github.io/kibit-demo/. It's quite easy and a good (I think) introduction to core.logic.
I've been wanting to learn Clojure and recently bought the book Clojure Programming (not to be confused with Programming Clojure) and I'm curious to know if others believe it is a good idea for a Clojure novice such as myself (lisp and JVM novice too) to use kibit while learning. Any advice would be greatly appreciated. Thanks.
You're new to Lisp and JVM? (Perhaps new even to Emacs?) The activation energy required to get going in Clojure can be a bit daunting. Cool tool that it may be, I think that kibit should wait until you can drive around with some confidence. Premature optimization and all that, y'know.
Yup, new to Lisp and JVM. All of my experience, brief as it has been, is in Ruby. I've only taken a cursory glance at the book I purchased and frankly I think I'll be ok picking up Clojure. It just may require a lot of focus. Is Emacs the typical editor Clojuristas use? I use vim though I have recently switched to Sublime.
I use emacs for anything with S-expressions and vim for everything else, but you should be careful with information overload. It's very easy to get started with LightTable if you want to play with Clojure, so I'd recommend that approach to work through book examples.
If you're new to Lisp, I'd recommend working through Land of Lisp [1], and pg's On Lisp [2] in order. They're both Common Lisp books, but they will introduce you to and expand your mind on (respectively) what's possible with all the power Lisp gives you. Virtually everything you learn in those books will be very nice tools to have in your toolbox as a Clojure dev.
As for the best starting Clojure book, Clojure Programming [3] is excellent. It has great OOP -> FP examples, is fairly extensive and well-written.
Vim can work very well with Clojure (I use it). Look into ScreenSend, which lets you send code from the editor to a repl. You can use it with Python as well, and anything with interactive evaluation. You might also want to install paredit, which keeps your parentheses sorted out for you.
Correction, you must install paredit (and spend half a day familiarizing yourself with how it works). It'll make your learning experience 10x easier.
As for Emacs vs Vim, I also use Vim for Clojure development. There's definitely a bias toward Emacs in the community, but that doesn't mean that you have to go with Emacs. In fact, there are now useful plugins/packages to work with Clojure in Vim, Sublime, IntelliJ, Eclipse, as well as Emacs. There's even two editors written in Clojure itself: Clooj (https://github.com/arthuredelstein/clooj) and the afore-linked LightTable.
(Confession: I am a novice to clojure/scheme/JVM myself.)
I admit that I have not tried kibit yet. However, LightTable/REPL is a great tool for this endeavour. If only clojure could have an error tracking report that would be comparable to the wonderful implementation that can be found with the python IDLE.. but I guess that is too much to ask?
Can you elaborate on what you mean by "error tracking report" in IDLE? Either I'm missing something cool about IDLE or I am totally misunderstanding. Thanks!
Sorry, what I meant was the TraceBack. It helped a great deal when learning programming and hunt those nasty bugs:
Traceback (most recent call last):
File "C:/Users/wuschel/Desktop/error-track.py", line 3, in <module>
newstrin = teststrin + 3
TypeError: cannot concatenate 'str' and 'int' objects
In clojure, you get those error reports in java lingo - I don't know how fast you can get use to that kind of error messages when you do not know Java. Now, this one is obvious, but it just should serve as an example:
clojure.lang.Compiler$CompilerException:
java.lang.RuntimeException: clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Unable to resolve symbol: b in this context, compiling:(null:4:1)
Kibit looks neat, I haven't tried it. I think the generally applicable advice is to get comfortable with the core first, then add tools and libraries at the speed you're comfortable with, making sure that you understand what each component does.
Running `lein kibit` is super low effort once you've got lein set up, and even having used clojure for years it still reminds of features of clojure.core that I forgot pretty regularly. I think as a noob it would really help you in learning the core lib.
Quite often my experience when learning a new language is "Am I doing this right? Or even close to right?"
If kibit can turn your code into idiomatic Clojure then you have a tool for exploring your solutions and how close they look to Clojure as it might be written by a native.
It can also prompt questions "Why do it this way rather than this way?" which could be a good learning opportunity.
I think it would only be good if its used as a learning tool and not a code-writing tool, compare:
write the best code you can -> run kibit -> spend an hour reading the docs and every blog post you can find about a feature you didn't know about -> repeat
write the best code you can -> run kibit -> show off your awesome code, you're a rockstar!
I agree with you although I think that's an unlikely scenario.
kibit, so far as I understand it, is a pattern matching solution that can replace one structure with another - more idiomatic - structure. It doesn't add anything and, hence, can't actually solve your problems for you.
It's easy to get carried away with everything. My advice: start with an editor you know and use everything vanilla. You'll appreciate better tools more once you spend some time and get a feel for the pain points.
That is quite impressive. I wish I'd have known about kibit 6 months ago. Since I'm still a Clojure novice, I guess I still stand to benefit from it. Moving from "can bang out technically workable code" to "effectively uses the whole range of core functions" is a long slog. Next time I'm writing Clojure I'll definitely be running kibit over it.
I find LightTable to be a great tool when it comes to get a first impression of clojure. Installing, configuring and getting the grasp of emacs, or configuring Sublime Text with SublimeREPL can be a lot of hassle under Windows based OS. LightTable helped me to save a lot of time here.
It's probably super relevant that the percentage of the community who has the ability to comment about neat Clojure code is extremely limited (1% maybe? perhaps even less) compared to the percentage that can comment on some techno-political drivel.
Does LightTable have autocompletion for Clojure or might it in the future?
How does autocompletion work for Lisp-like languages? I'm wondering if the verb-subject ordering makes it more difficult to build effective autocompletion.
In languages with a syntax like C, code phrases benefiting from autocompletion focus on a particular thing in subject-verb-object order:
obj.method(param);
Consequently I can engage auto-completion by typing the following, where <cursor> is the location of the text cursor in the editor:
obj.<cursor>
I type variable name and the "dot" (or equivalent), and the IDE can make informed suggestions about methods to show: methods defined on obj, or methods taking obj's type as their first input.
When writing code, I usually know what object I'm working on (autocompleting the variable name is useful but not crucial, since it's usually on preceding lines). What I want to know, and the area in which autocompletion helps me most, is finding out what methods are relevant to that specific object (e.g. defined by the object).
When I'm writing quick prototype code, I use an approach that's almost like single static assignment:
A a = new A();
B b = a.foo();
C c = b.bar();
Using autocomplete, I can explore objects and methods while staying within the IDE. When combined with in-IDE documentation, writing new code is extremely effective.
How do you effectively autocomplete in a Lisp language?
(<cursor>
If I type that, there's no object yet, so what autocompletions can show up? A list of all functions?
(<cursor> obj ...)
If I type this line and move my cursor back to the first parenthesis, then it makes sense that autocompletion could understand the context, but moving the cursor backwards is inconvenient. It's not a fluent way to write code.
I have not used autocompletion in Lisp-based languages. How do IDEs or REPLs solve this problem? It seems like a similar problem will affect pure-style functional programming languages like Haskell. Static typing is not the criterion, since Python has effective REPL autocompletion.
Does the lack of a natural opportunity to present relevant autocompletion information inhibit the development of advanced editors for these languages?
I'm not sure how LightTable works, but I can talk about how it works in Cursive. There's really not a lot of magic but there are a lot of tricky details. It seems like you're mostly talking about object method calls there - you're right that in the most common case (start typing the method name without putting the object after it first) you really can't do much. Currently in that case we propose all methods for all available classes, which is everything in java.lang and everything that's imported - I think most Clojure solutions do this. However this still misses some cases like (warning: totally invented api):
(let [entry (.getEntry my-map)
key (.getK|
Here you can't easily tell that you want the key of your map entry here since the MapEntry class isn't imported. I'm planning some improvements where I'll walk up the AST from the completion point and get the types of all variables on the way and propose all methods from them, but that requires type inference which I don't have yet (although it's on the list). IntelliJ has also really shown how you can push the bar here with some lateral thinking, they propose chained method calls etc based on the type, so there's a lot of cleverness you can do with a little thought (and a good test suite).
Completion for functions etc is obviously easier although in the case of protocols the problem is similar - you'll get all the protocol methods suggested since they're just fancy functions, but you won't get proper context-sensitive completion unless you've put the object implementing the protocol after the symbol you're completing - the most you can hope for is some sort of error message later that what you've entered doesn't look consistent.
Edit: one thing I forgot to mention is that in the completion list for methods we show the full signature as well as the list of all classes that have a method with that signature, which helps a lot in choosing the right method.
Erik Meijer has complained about this in the past. The answer is that it require a change in thinking. Object-oriented programming encourages the programmer to think about objects first (duh) and later ask what methods are available to them. Functional programming is the opposite. You think of the verbs first; the nouns themselves are interchangeable. So the simple answer is this:
(fo<cursor>
Pressing tab (or whatever invokes your auto-complete) would pop up a list of options such as this:
(foo
(foo-bar
(foo-bar-baz
As for exploration, Clojure has tools such as doc and find-doc to help you search for a particular function.
So the noun is encoded after the verb. I've seen scheme libraries like this, and makes me wonder there really are some non trivial purely verb libraries out there for functional languages?
Although I see your point, I think it's being a bit unfair because I could tell you the same thing:
new <cursor>
What would tab show you? All the possible objects?
You at least need a base to get started.. in lisp, it's not uncommon to have functions defined as (character-move), so (character-<tab>) works well. But even without that, since lisps use functions at its root instead of objects, it makes sense to know the ones you want to use.
Not to mention that Symbolics Zmacs already did this. It for example has code conversions built-in to change code between various UI libraries or Lisp variants.
I hope that with the recent addition of plugins, LightTable will also be able to provide code inspection à la IntelliJ IDEA, since that's the feature I miss most.
You could try Cursive (http://www.cursiveclojure.com). It's pretty new but it's based on IntelliJ so we get a lot of features for free. We don't have a lot of inspections yet but they're coming soon (including kibit-in-the-editor type inspections).
thing is if you take a modern language and add s-expressions, then you may as well add macros and at that point there's a good chance it just became a lisp
You don't need s-exps to have pattern matching on ast or macros, especially hygienic, pattern based ones. There's sweet.js and macros for python as examples. All you really need is an API for manipulating AST, be it built-in or 3rd party. S-exps are especially nice if you want defmacro-style macros, but I don't believe they should be used very much.
Hmm every form I try and evaluate seems to be reduced to a one line function. Is this working as intented?
Even in the example given it's reduced the function to a 1 liner, I assumed because it was short enough that it's still legible. Is this trying to tell me my functions are too long?
Clojure doesn't have a real code formatter unfortunately. I posted a slightly better version that preserves formatting if nothing changes and tries to use the clojure pprinter to format as best as it can.
