Posts

  • A Cornucopia of nREPL Updates

    When I wrote about nREPL 0.7 last week I mentioned that some really exciting things were happening in the broader nREPL/Clojure community and today I want to expand a bit on those. The general theme today is that nREPL is getting more mindshare and broader tool support. The subtheme is that many tools can end up being able to support more programming languages due to nREPL’s language-agnostic nature.

    The format I’ve adopted for this post is a bit chaotic and unstructured, but I hope you’ll forgive me. So, here we go.

    iced-vim Adds support for nREPL’s Sideloader

    We didn’t have to wait long for some editor to adopt the new sideloading functionality in nREPL 0.7 - iced-vim 1.3 did this only a couple of days after nREPL was released.

    You can check out iced-vim’s sideloader documentation for more details.

    So, which client will be next?

    Chlorine Adds Alpha Support for nREPL

    After the demise of Proto REPL, Chlorine has been the undisputed Clojure ruler of the realm of Atom. Chlorine has historically relied on unrepl to power its functionality, but the recently released version 0.5 added alpha support for nREPL!

    Chlorine’s author, Mauricio Szabo, wrote a couple of cool blog posts on the topic that I can heartily recommend:

    I’m pretty sure Chlorine’s support for nREPL will improve a lot in the months to come.

    Conjure Adds Support for nREPL

    In other (amazing) news - Oliver Caldwell has been working on a rewrite of Conjure, that’s powered by nREPL and may (will?) support other programming languages besides Clojure!

    The project is off to a very promising start and I’m very excited about it!

    Calva’s new Debugger

    Calva, CIDER’s dear sibling, now has an interactive debugger! It utilizes cider-nrepl and VS Code’s debugger extension API. This work has been done as part of the Clojurists Together Q1 2020 funding period.

    I’m super excited to finally see another editor reusing CIDER’s debugger, and I’m looking forward to seeing which editor will be next!

    Babashka Now Ships with a Native nREPL Server

    These days everyone has been raging about the awesome babashka, that increased the reach of Clojure almost as much as ClojureScript did a few years ago. Scripting in Clojure is a dream come true for so many people!

    The industrious Michiel Borkent (a.k.a. borkdude) recently unveiled native nREPL support for babashka in version 0.0.79. What’s more - he did such a great job that the new server works pretty well with CIDER and you’ll even get code completion! Michiel shared with me earlier today a short presentation he did for the Amsterdam Clojure User Group on the subject.

    Somewhat amusingly, all of this was achieved with 231 lines of code. I think that’s a great testament to the simplicity of nREPL.

    Arcadia’s nREPL Server is a New Hope for ClojureCLR

    Early on nREPL was ported to ClojureCLR. That port, named nREPL CLR, was a 1:1 reimplementation of the Clojure version, and was off to a pretty strong start. Unfortunately, this port was abandoned relatively quickly, and probably doesn’t even work these days. The lack of an nREPL server for ClojureCLR meant that its users could not take advantage of many of the most popular editor plugins and IDEs for Clojure, but this is finally changing.

    Arcadia’s team have implemented a pretty solid nREPL server for the CLR. I’m hoping that as it matures it will lead to a much improved access to top-notch Clojure dev tooling for ClojureCLR. I’m hoping that the server will be extracted from Arcadia’s codebase soon and will be distributed as a standalone project for the benefit of the entire ClojureCLR community.

    Even though the server is written in C#, its entire code is something like 500 lines of code. If you’re into ClojureCLR I’d encourage you to check out the project and try to help.

    nREPL for ClojureScript

    I guess most people know that nREPL has supported ClojureScript for ages via Piggieback. Piggieback is a pretty cool solution, but it comes with a few quirks and with one important limitation - it doesn’t work with self-hosted ClojureScript, as it’s written in Clojure. This means that if you’re into Lumo and Planck you can’t use with them with your favourite nREPL client. This, however, might change soon as well…

    Chris Badahdah has been working for a while on a native nREPL implementation in ClojureScript, which won’t have this limitation. If you’re into ClojureScript, I’d encourage you to help him with the project.

    Misc

    Let’s wrap things up with several smaller news:

    As usual - I welcome help with everything nREPL-related! Don’t be shy, we’ve got fun, challenging and rewarding tasks for everyone!

    Epilogue

    What a wild ride! I don’t know about you, but so much new things happening in nREPL’s world feels like Christmas to me! I think it’s reasonably safe to say that nREPL’s community is bursting with energy and ideas these days and I’m very optimistic about the future. We’ve achieved a lot already, but I feel the best is yet to come…

    Keep hacking! May the (n)REPL be with you always!

  • Clojure Weekly

    In today’s super dynamic world of programming it’s hard to keep track of everything important going on in any programming community. Too much information, too many information channels (e.g. reddit, Twitter, Slack, Hacker News, RSS), too little time. I’ve always been a big fan of the weekly newsletter format, ever since I’ve first encountered it in the Ruby community some 15 years ago. Newsletters are typically short, they focus on everything important that happened recently and have a predictable cadence.

    Clojure has had several similar initiatives so far. First there was the Clojure Gazette1 by Eric Normand, then we got The REPL from Daniel Compton. While working on this article I also learned about The Def Newsletter, which I had somehow missed completely in the past. Unfortunately it seems it has been abandoned for a while now.

    In the past few years “The REPL” was my go to source for everything important that happened in the Clojure world, but unfortunately Daniel had a lot on his hands lately and “The REPL” lost some of its traction. Fortunately, a couple of weeks ago Aleksandar Simic (a.k.a. @dotemacs) launched Clojure Weekly, a curated set of Clojure-related news. I really enjoyed the first 3 editions and I’ve already learned quite a few cools things from there. I even took some action items for my projects:

    • Remove support for Nashorn from Piggieback (ClojureScript dropped support for Nashorn recently)2
    • Check out Lambda Island’s Clojure Style Guide and see if I can mine some useful ideas for the Community Style Guide.

    It was also nice to read all the nREPL-related announcements for the past couple of weeks, but I’m obviously quite biased on that topic.

    Funny enough, the launch of “Clojure Weekly” coincided with “The REPL” coming out of hibernation, but you can never have enough information about Clojure. Looking forward to their next editions!

    P.S. If you’re into Emacs I can heartily recommend Emacs News by Sacha Chua. It’s a fantastic newsletter for Emacs users of every skill level!

    1. Sadly, it has been defunkt for a while now. 

    2. You can find more details here

  • nREPL 0.7

    It has been a little over a year since the release of nREPL 0.6. Moreover, it has been over nine months since I wrote that nREPL 0.7 was getting a native EDN transport. So, where the heck is going with nREPL? Is it stuck again so soon after its revival? I can assure it that’s definitely not the case and despite the lack of new releases nREPL has been making some good progress. I’m also extremely happy to announce that nREPL 0.7 is finally here! COVID-19 did a lot of bad things, but it also cleared my busy schedule rather dramatically, so lately I’ve been trying to catch up on all of my important projects. There has to be something good coming out of this horrible madness, right?

    So, what’s new and noteworthy? I already wrote about the EDN transport, so I guess I can skip that part. There are two other big additions:

    • Clients can now inject code remotely in a running server on demand. This probably doesn’t make any sense to most of you, but it’s insanely cool and powerful. We’re calling this feature “side-loading”, following the example of unrepl, which pioneered it.
    • nREPL responses are now covered with clojure.spec.

    Let me expand a bit on the sideloader, as I think it’s the most interesting addition in 0.7. In simple terms it will allow a client to provide missing code on demand. Here’s a short example:

    ;; -> init sideloading
    {:op      "sideloader-start"
     :id      "1"
     :session "x"}
    
    ;; -> try to require a missing namespace
    {:op      "eval"
     :id      "2"
     :session "x"
     :code    (quote (require '[foo.bar :as bar])
                     (bar/qaz))}
    ;; <- lookup for foo.bar
    {:id      "1"
     :session "x"
     :status  :sideloader-lookup
     :type    "resource"
     :name    "foo/bar.clj"}
    ;; -> providing resource
    {:id      "3"
     :session "x"
     :op      "sideloader-provide"
     :type    "resource"
     :name    "foo/bar.clj"
     :content "<base64 package>"}
    ;; <- ack of provided resource
    {:id      "3"
     :session "x"
     :status  :done}
    ;; <- result of eval
    {:id      "2"
     :session "x"
     :value   "Qaz"
     :status  :done}
    

    What’s happening here? The client tries to require foo.bar, but the library is not available locally. That’s why nREPL asks the client to provide the missing library. The client responds with a Base64 encoded payload that’s the missing resource in question, this gets loaded in nREPL and the evaluation continues. The potential to utilize this is huge, because now clients can enhance running servers (e.g. with code completion) without the need to include additional dependencies when booting nREPL. I wanted to implement this in CIDER first, but I was crazy busy the past few months, so there’s a good chance that some other client author is going to be beat me to it. That is totally fine! Please, beat me to this and build something cool with the sideloader!1 There’s a bit of documentation about it here.

    There have been other small tweaks and improvements in the latest release as well. For all the gory details you should check out the release notes. One thing that’s not covered there is that nREPL’s documentation got some love, so it’s better than ever. Still, there’s a lot of room for improvement, especially when it comes to the protocol’s specification, so it’s easier for folks to build alternative implementations and new clients.

    I already have some (modest) plans for nREPL 0.8 - the main focus there is going to be the addition of built-in completion and info ops, so that clients would have access to even more useful functionality out-of-the-box. You can read more about this here. There are also plenty of other open tickets, so if you’d like to help out you’ll have your pick of some mighty fine options (many of which are (somewhat) beginner friendly).

    I’m hoping that the improvements in nREPL 0.7 and the planned improvements for nREPL 0.8 are going to contribute to the creation of more and better clients for nREPL in the years to come.

    I’ll also use this post to share some cool general updates about nREPL:

    • Chris Badahdah is working on a ClojureScript port of nREPL.
    • Michiel Borkent is working on a Babashka port of nREPL. His basic nREPL implementation is also a good example of how easy it is to implement the nREPL protocol.
    • Maurício Szabo is considering adding nREPL support to Chlorine.
    • Oliver Caldwell is considering adding nREPL support to Conjure.
    • Pratik Karki announced at IN/Clojure that LightTable will be dropping their custom nREPL and adopting the modern nREPL + everything in CIDER’s Orchard.

    Such developments make me extremely happy and reaffirm my belief that nREPL will continue to play a central part in the future of Clojure’s development tooling (and hopefully beyond Clojure). By the way, you might also want to check out my recent IN/Clojure presentation on that topic.

    Time to wrap it up now. Special thanks go to Shen Tian for his work on the EDN transport and the sideloader. Christophe Grand also deserves a lot of credit of coming up with the sideloader in the first place and building a prototype for nREPL. Thanks a lot, guys! You rock!

    That’s all I have for you today! Keep hacking!

    P.S. If you haven’t spent all of your money on toilet paper, you might consider supporting nREPL via GitHub Sponsors and OpenCollective.

    1. A couple of days after I wrote this post vim-iced became the first editor that added support for the side-loading functionality! You can find more details here

  • Adjusting RuboCop's Defaults

    Since the beginning of time certain people have been unhappy with RuboCop’s defaults. I guess that’s one of the universal truth in life - no matter how hard you try you can never please everyone. Especially the users of a lint tool.

    Still, with RuboCop 1.0 just around the corner, I’ve decided to run a short survey so we can see if some defaults really don’t make sense. The survey covers only the topics that I remember had generated the most heated discussions throughout the years (e.g. single-quoted vs double-quoted strings), but I’ve also added an open-ended question that allows you to share whatever else frustrations you might have with the default configuration.

    We’ve avoided changing the defaults in the past couple of years (part of our general effort to reduce the friction of RuboCop’s upgrades) and we’ll really limit those after RuboCop 1.0. It seems that’s our final opportunity to make some sweeping changes and make people royally pissed.

    I’ll leave the survey open for a couple of weeks1 and might potentially extend the list of questions if I notice some trends in the answers to the open-ended question. Once the survey is closed I’ll publish the results online, as I assume they will be of interest to many people.

    Note that changes to RuboCop’s defaults will be made only if the survey results indicate a significant difference between a current default and its alternatives (e.g. >10%). If we’re looking at numbers like 48% to 52% it’s not worth doing any updates as any of the values would be just as good of a default. No point in breaking anyone’s setup without a solid reason to do so.

    Please, share the survey around - the more responses we get, the better our actions are going to be. That’s everyone’s simplest way to influence the future direction of RuboCop!

    That’s all I have for you today! Keep hacking!

    1. Currently I plan to close the survey on the 12th of April, but this date might change depending on daily number of the respondees by then. 

  • The Books That Every Programmer Should Read

    I read relentlessly.

    – Rich Hickey, creator of Clojure

    Several years ago1 I did a talk at HackConf titled “The Books That Every Programmer Should Read”2. Back then the conference was geared mostly towards young aspiring software engineers, so I wanted to present on a topic that they’d find useful. Early on in my career access to high-quality educational resources on programming was very limited - the Internet was quite barren by modern standards and there were very few online resources, foreign books were very hard to procure in Bulgaria, and there weren’t that many experience people to learn from. I’d tackle every book I could lay my hands onto, and as a result I wasted a lot of valuable time that I could have utilized better. On the bright side - after a while I could immediately tell if some book was going to help me level up my skills or not. I wanted to share my experience and help others prevent some of my mistakes, even if we live in a very different world today, and books might be starting to lose some of their relevance.

    While, I didn’t feel that my talk was particularly special in any way, it became one of my greatest hits and I’ve been often asked to discuss certain aspects of it. Another thing that I’ve been asked to do was to put all the “good” books I mentioned during the talk in a list that people can easily refer to.

    The Central Message

    The central message of my talk was very simple - there are plenty of programming books out there, but the majority of them are not worth your time and you’d probably not learn much from them. I tried to give everyone a simple recipe to spot great books and hone in on them. A good book:

    • ages very well
    • covers topics that are applicable in a broad spectrum of programming languages and frameworks
    • is written by practitioners (as opposed to academics/professional writers)
    • goes way beyond the basics and teaches you how to effectively use a certain technology
    • explains complex concepts in simple terms
    • challenges the way you think and pushes you to expand your mind

    I made the case that in general no one should read more than 1 reference per some technology (and for frameworks even this might be too much) and that usually there are only a couple of references in a certain domain that are much better than everything else out there.

    I’ve also tried to make the point that after a certain point it doesn’t pay off very well to dig deeper and deeper into the same subject matter, and that you should consider expanding your knowledge horizontally - e.g. if you’re an OOP expert you should start exploring functional or logical programming; if you’re a back-end developer you should learn about the front-end technologies and so on. Ultimately, ideas matter much more than any concrete implementation of those ideas.

    The Reading List

    It was probably not apparent in my talk, but I had picked some of my favourite books in all the areas that I consider essential for the success of a programmer - e.g. CS fundamentals, operating systems, effective usage of a language/technology stack, software design, etc. Just to be clear - you don’t really need to read a dozen books on CS fundamentals or operating systems. Furthermore - some of the books listed in each section cover more or less the same ground. Just pick whatever seems most interesting to you.

    One really important thing to understand is that the list that follows is just a sampling of the type of books that any (good) programmer should read. This article (and the talk) could have easily been named “The Type of Books that Every Programmer should Read” or “The Makings of a Good Book on Programming”. Still, naming remains the hardest problem in our industry and some titles are more catchy than others. I’ve noticed that too many people focus on the fact that some particular technologies are mentioned (e.g. Unix, C and Ruby). Obviously not all developers should know C and Ruby, but when discussing what makes a good reference book some concrete examples are always useful.

    Bellow is a listing of all the “good”3 books my talk, grouped by categories.

    CS Fundamentals

    Operating Systems

    References

    Note: Please ignore the specific technologies references here. My point was to simply list a few good reference books as a baseline for all of you, not to promote any particular languages.4 Still, I do believe that’s it valuable for everyone to gain some insight into the languages that shaped our industry (e.g. Lisp, C, Smalltalk), even if you’re never going to use them directly/professionally. Understanding the history and the circumstances that lead to some modern development is certainly going to make you a better programmer.

    Effective Usage

    Note: Again, please ignore the references to specific programming languages. They are here for illustrative purposes only.

    Software Design

    Productivity

    Project Management

    Meta

    The Greatest Hits

    I realize the list looks daunting and probably few people will have the time to go over all the books in it. Many of them are definitely not light bedside reading material. I have to admit there are some (many) books on the list that I didn’t finish myself. If I had to narrow down the list to the 3 most important (impactful) books there those would be:

    • Structure and Interpretation of Computer Programs
    • The Elements of Style
    • Code Complete
    • Thinking, Fast and Slow

    Seems, I’ve made an off-by-one error, but you’ll forgive me.

    The Sequel

    There are many great books that I didn’t mention in my HackConf talk (mostly due to time constraints). I’ll guess I’ll have to do a follow-up blog post for them. Generally speaking, I wanted to give people an idea of what a quality book means and I was certain they’d be able uncover more of those. Teach a person to fish and all that jazz…

    That being said, I wouldn’t mind following up on my original talk with a sequel that expands on the basic ideas I outlined there and refines the list of books presented. There were a couple of topics that I intentionally avoided (peopleware/soft skills, leadership), so there’s definitely some more ground to cover. Not to mention I read quite a few other great books since 2015. And I should probably do it in English next time!

    Epilogue

    I think this is the only blog post that I’ve planned to write for 5 years before it became a reality. Better late than never, right? It took me quite a while to get to it, but this gave me extra time to reflect on my talk. Sometimes even I manage to find a different message in my presentations after ruminating on them for a while.

    I hope this post will inspire you to do some quality reading during the lockdown5 and introduce a bit of joy in your life. It’d be nice of something good came out of it. By the way, why don’t you share in the comments your favourite books? I’d love to get some reading ideas myself!

    1. Way back in 2015. 

    2. You can find a recording of the talk here. (it’s in Bulgarian) 

    3. In the talk I kept comparing some books that I consider “bad” to books that I consider “good”. 

    4. I’m actually quite fond of promoting Lisp(s) - it’s an amazing and rather underappreciated language. 

    5. As I write this in Spring 2020, much of the world’s population is under lockdown, because of the ongoing COVID-19 pandemic. 

Subscribe via RSS | View Older Posts