"It's user-hostile, why did you think this was a good idea?"
I'm Manning's Publisher and I thought it was a good idea. We obviously implemented it badly if you guys think it is "hostile." Also, we have failed to explain WHY it's done this way: by getting scrambled content first and unscrambling as you scroll you are able to look at any piece of the book that you choose--you're not forced to look at the one or two chapters selected by the publisher and offered for free. The mechanism allows that without giving away the entire content for free. If you do look at it in scrambled form, you still get a sense of what it covers because much of it remains unscrambled: the heads of all levels, all code, all figures and code, and figure/code comments and captions.
After seeing this discussion we changed the unscrambling animation--it's not a rotation anymore but simply a replacement. Let us know. Also, the amount of time we let people read unscrambled content is limited. Maybe it needs to be longer?
We keep trying ideas that we hope will please our readers; sometimes we are going to fail.
This book is my attempt to make Clojure more accessible for newcomers.
The book teaches at a digestible pace the syntax and the main concepts of the language, in particular data immutability which is at the core of the language.
This is part of a "Get Programming" series by Manning, which means that the reader is guided from concrete to abstract until the ideas are fully integrated.
This book takes a pragmatic down to earth approach:
- Lots of code snippets in each Lesson
- Several exercises at the end of each Lesson
- A Capstone Project at the end of each Unit
The book is in MEAP (Manning Early Access Program) stage which means that for now only the digital version is available and 5 out of 16 Units are published. (When a new Unit is published, the reader gets notified.)
Hopefully you'd find interest in this book whether you are a Clojure beginner and want to learn the basics of Clojure in a structured way or a Clojure experienced developer and want to help your friends or teammates in their Clojure journey.
I am very interested in hearing comments (in particular improvement suggestions) both about the approach and the realisation.
OP @viebel is the inventor of Klipse, highly recommend everyone try it out! Really great integration of multiple programming languages into a simple front end API.
Here is the link to Klipse on github: https://github.com/viebel/klipse
Klipse is a Javacript plugin for embedding interactive code snippets in tech blogs.
And here is a link to my blog where I make an extensive usage of Klipse to embed interactive code snippets into my articles.
One missing link (or unfilled need) in Clojure books is a strong, robust guide on dealing with JVM's ecosystem and its associated shenanigans.
A guide is needed for interfacing with Java beyond simple method to dot notation interop that only works for the simplest of cases and only with well designed libraries that exposes clean APIs. Most significant projects in Java are built as massive frameworks with all sorts of weird tooling and dependencies. E.g. Minecraft Forge, Android Dalvik. Clojure has this 'small libraries good, big frameworks bad' mentality and expects everyone to be of high calibre software developers. You have to start somewhere and if you are not an Java developer experienced in wrangling with JVM intricacies then anything interesting can't be done with Clojure. You have to spend weeks on the IRC and mailing lists in the hopes of finding someone who either cares to help you with your problem or just builds the bindings for you. The company driving Clojure development (Cognitect) is small so I suppose their hands-off approach can be excused. But the community really need to pick up the slack for users coming to Clojure who are not experienced Java Devs. E.g. Go/C++/Common Lisp developers who wants to integrate a application written in JRuby and built with a custom Groovy Gradle build script with Clojure. For Java this is very common use case since it's the lowest denominator in the JVM. But good luck for Clojure. There is a huge need for a good book on this. Most Clojure books are generally: how to reinvent a web framework, 101 ways to process a text file using Clojure concurrency features and sequences with a dose of functional programming.
Clojure's error messages (or JVM stack traces for better or worse) are infamously terrible compared to similarly "hip" languages like Elm and Rust that have wonderful error messages. (Version 1.10 improved on this area though there's still plenty of room to grow to reach Rust-level of developer UX) It would also be nice to let users know early on when starting to use the language that Clojure libraries needs minimal maintenance and are almost always completely reverse compatible. (Whether this really is good practice or not when most large software projects are 'evergreen' with 'living documentation' is besides the point. A white lie to users won't hurt anyone. It would be terrible if a person reading a blog post on constraint solving in Core.Logic realizes it hasn't seen a major update in 3 years, gives up on Clojure, and ends up using miniKanren in Python instead.)
I myself would be interested in writing something like this, but I am not sure that enough people would want to buy that?
Would YOU buy that book if it was available today?
I would definitely buy this book. With so many things that leverage the JVM, and with new things like GraalVM, learning the JVM ecosystem from the perspective of a non-Java developer would be very useful.
Maybe it's just me, but what I've found most difficult about clojure isn't the language itself, it's the java ecosystem around it. I found clojurescript to be much easier to start working with, and I can only assume it's the javascript backend.
In my brief experience (so take my opinion with a grain of salt), it's the Clojure ecosystem around Clojure that is the problem, not the Java one it interops with. There is hardly any unification for anything except that it looks like Ring is the main HTTP lib (just for http; beyond that, how many routing libraries are there now?), and edit: there is a lot of library churn that goes with that, which to me totally conflicts with the language's reputation for being evolutionary and stable. Most libraries I have seen are written and maintained by a single author. 50% or so of the libraries I have seen are just plain dead questionably dead, including stuff written by Cognitect. It's not a healthy situation. It's a shame, because the language itself is awesome.
As a lisp I think the language is quite simple. I remember having a little trouble wrapping my head around immutability, but that was mainly it. It took me a year or so to grok macros.
Though when I learned Clojure, I was already familiar with Java and much less so with Javascript. Probably as a result, Clojurescript actually feels much more complicated to me.
I had neither Java not JavaScript background, but I found Clojure easier. Nevertheless, I did most of my learning in ClojureScript due to the visual feedback being the right learning tool for me.
While I am big fan of Clojure and even more ClojureScript...
The problem is: Once an ecosystem is stagnating or on the decline it's a huge risk to enter this space. It's not just your own market value you might be destroying, it's hard to find resources and to scale development.
Besides this, what I really want is strong competition between lib authors in order to keep the ecosystem evolving. Even current blockbusters like React face problems in this regard, like the react-router monopoly where maintainer Michael Jackson buys competitors from the market to keep his leadgen machine running. I know this is OT but a language without a huge OR trending ecosystem is worthless.
I think what you are stating is that the Clojure ecosystem is stagnating.
I'm moving more and more of our company's stack over to the Clojure ecosystem because I see a lot of innovation and excitement in it. More importantly, it takes fewer people to be more productive in it.
I know some high-profile people have left the language for various reasons, but there are lots of people I know personally who are joining it. We should expect some churn.
I won't try to convince you that it isn't stagnating, but I want to put out an alternate perspective from someone who is investing a lot in the ecosystem.
> I know this is OT but a language without a huge OR trending ecosystem is worthless.
Anecdotally speaking, I'm not sure I agree that the Clojure ecosystem is stagnating (it's relatively small and likely always will be) but a big draw of ClojureScript is the way it piggy backs on the Node/NPM community.
I recently spun up a React/Reagent UI paired with a Clojurescript node.js server. I was pleasantly surprised how easy it was to do ClojureScript <--> JS interop in Shadow-Cljs projects.
My team uses it almost exclusively. I know Walmart uses it a lot, they even maintain a GraphQL open source framework for it. There's other medium to small shops that are either using it or exclusively using it.
I'm trying to publish new guides on my blog. So I'm interested in the out of date setup you found. Can you link to some, it would be nice to see what kind of content you were looking for and if I can put out an updated version. Cheers!
The Tools page under ClojureScript site doesn't mention Sublime Text 3 or VS Code at all (in typing this I realize Emacs would probably be the most common editor while working with a lisp like Clojure...).
https://clojurescript.org/tools/repls
LightTable hasn't been updated in forever, but they're cognizant of that and are working on it.
The repl.it Clojure instance is very old, but that's not unique to Clojure.
Clojure looks to be a very good language, and I enjoyed playing with it a few years ago, and I understand it's improved a lot since then, especially in error handling, which is why I bounced off back then. I was just worried it was more like Objective-C (an apparently declining language with a clear successor) than Rust (a small but passionate community). Good to hear it's still going strong!
I'll see if I can help on any of that. The fact that tooling guides lag behind will the hardest, because Clojure tooling evolves fast, and is currently in a lot of flux with many good options.
I'm wondering, since the explosion of Javascript frameworks, is there any staistics about how many backend devs move away from their stack into the JS stack ?
Once nice thing with Clojure is that it targets both the JVM and Js runtimes. All the devs on my team work on full stack, because we don't really see the separation. It's the same language, same tooling, and often same libraries.
On top of that, Clojure ecosystem is a lot more stable than Js. Library APIs don't keep randomly changing, there isn't an explosion of frameworks. My team has been using Reagent/re-frame for the past 4 years, and it just works. Whenever a new version comes out we just bump up the dependency.
What's more interesting is that Reagent is built on top of React, and React itself went through many breaking changes over the years. Yet, Reagent API remained stable throughout that time. I think that's a testament to how well it was designed from the start.
I completly agree with yoghtos.
One of the main reasons, Clojure is not as famous as it could be in the developer community, because it has a reputation of a language that is hard to learn.
I hope that my book will attract many non-Clojure devs inside our wonderful Clojure community.
I don't know. But if it helps, I did not. And I know of zero colleague or friend who moved away from a traditional backend environment into a JS one. I've been a backend dev in Java and C# for a good 5 years now. Just one data point though.
I did see people move to say Scala, Clojure, Kotlin, Rust, Go, F#, Erlang and the likes, which are arguably other mainly backend languages and ecosystems.
Edit: For front end yes. Like I myself know JavaScript/HTML/CSS and use ClojureScript as well for frontend work. I understood your question more as if any backend dev had moved to using Node.js. away from more traditional backend systems.
Scala developer unwittingly switched over to Angular + Typescript.
I would love to code Scala across the board but the value proposition that frontend frameworks provide is too compelling to ignore -- code splitting/lazy loading, strong UI support (via Ionic), fantastic tooling (VS Code + Angular CLI), standard app structure, etc.
Now the backend is a fairly dumb API that just shovels JSON to/from database with some Akka messaging mixed in here and there for websocket based content.
Never would have imagined leaving Scala.js, which is amazing in its own right, but the vast majority of frontend work has migrated to Typescript for a reason.
How is this trending on Show HN? The text is unreadable. The letters lock, unlock and rotate. Can there be a more user hostile way of offering a free preview?
From the Show HN guidelines:
> If your work isn't ready for people to try out yet, please don't do a Show HN.
There is clearly no way to try out this book. The "Show HN:" prefix should be removed from the title so that this post can belong to the list of regular posts.
As far as I can tell the gibberish text eventually becomes readable. So the book exists and can be tried out, but with some annoyance. That still qualifies for Show HN. For books, people usually put a free chapter or two up, which is arguably less annoying, but there is room for different approaches.
The intention of the "try out" guideline is to make sure that the work actually exists and that people can play with it to get an idea of what's there. It's not intended to force Show HN projects to all be free.
An obvious improvement would be to show the actual text of the book on the web pages, instead of showing gobbledygook and then (eventually) triggering a pointless animation that converts the mess into the real words.
It's user-hostile, why did you think this was a good idea?
I have already purchased this book, and I'm a big fan of Manning Publications in general. But I do acknowledge that their preview mechanism, where you exchange "points" for unscrambling either paragraphs or sections of a book, is both cumbersome and annoying. I'd much prefer sample chapters in the same way that Pragmatic Programmers does it.
That said, it's pretty evident that Manning and PragProg have taken the lead in tech-book publishing that O'Reilly ceded when they went to all-subscription for their e-book offerings.
I have no problem about people selling books. Put free snippets of the book (or the whole thing) online, or don't. Either is fine. But putting the text online and making it hard to read is just stupid.
While I agree with you, it's worth pointing out that the author (viebel) has no say in how the publisher distributes free samples. It is simply a given, they don't ask, and the only thing that the author can do about it is to publish with someone else.
When you self publish, that aspect is easier. You simply do what you think is best, listen to the audience, and make it better whenever possible. Now I'll shamelessly put a link to samples of my Clojure book here. It is not competing with the OP's Clojure book, since mine is about Deep Learning and high performance computing. I simply put several chapters as PDFs for free, and if you like it, you can subscribe to the whole book (still a WIP, so you get drafts as they are written).
Of course, this requires manual maintenance, something that I can do, but is too much hassle for big publishers that have to deal with many books and even more readers at the same time.
After seeing this discussion we changed the unscrambling animation--it's not a rotation anymore but simply a replacement. Let us know. Also, the amount of time we let people read unscrambled content is limited. Maybe it needs to be longer?
We keep trying ideas that we hope will please our readers; sometimes we are going to fail.