Live data from Hacker News

Clojure will affect the way you think about programming

eli.thegreenplace.net

131–140 of 226 posts

Re: Clojure will affect the way you think about programming

#131

Earlier quoted context omitted.

I can occasionally get away with writing Clojure for "real" work, but for hobbying (and inshallah for real work someday) my goto is Racket. I feel like Racket is something of an optimum among the lisps in terms of brain expanding, modernity, tooling, libraries, docs, and community.

I tried Googling bcrypt; one C wrapper that hasn't been updated in 3 years pops for Racket, there's at least 3 recently updated libraries for Clojure. I'd suspect the library availability is gonna be similarly tilted in Clojure's favor in most domains. Clojure has lots of compelling and new stuff - Figwheel, re-frame, Neanderthal. What's Racket's killer library that's doing something no one else is?

It will eventually use Chez Scheme as a backend since CISCO open sourced it. Chez is really fast and lightweight.

Re: Clojure will affect the way you think about programming

#132
post #36
post #24

Earlier quoted context omitted.

wish that were true, but i doubt it. scala, prolog and erlang are all higher on tiobe index.

I personally don't view Scala as a FP language, it's a FP/OO hybrid. It's not opinionated in that regard, and a lot of code in it is written in traditional OO style or a mix of the two. Erlang is another widely used functional language, but it's not very widely used outside the telecom niche. Clojure has the advantage of running on the JVM, and makes it easy to target a much wider range of domains.

Clojure is also a hybrid. The other part is called Java or Javascript. This is claimed as an advantage, since there is already a lot of functionality in another language to be reused by a direct interface. Some stuff is simply deferred to the host language and since the other part is based on OOP, applications will then be a mix of more FP-oriented code calling OOP-oriented code.

Re: Clojure will affect the way you think about programming

#133

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has…

> it's very difficult to learn Clojure if you don't at least know Java

I'm curious why you think this is. As I've noted elsewhere in this thread, I've never written a line of Java in my life, and have worked as a Clojure dev since 2014. I also never write any code that interoperates with Java.

Seems to be a very common misconception that you must know Java to use Clojure.

Re: Clojure will affect the way you think about programming

#134
post #89

Earlier quoted context omitted.

> What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespac…

I've never seen anyone put more than one namespace in a single file in clojure. I don't think the compiler would even understand that... While you can define classes in clojure, it's not the common way to do things, and so namespaces take the role of classes insofar as compartmentalizing code. It's not normal to operate on data in another namespace directly... you can do it, but it doesn't feel natural in the languag…

> namespaces take the role of classes insofar as compartmentalizing code

Indeed! In fact, this is one of the sanest ways to do something resembling OO in Clojure.

Re: Clojure will affect the way you think about programming

#135

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has…

>> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure...

I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it).

For example, who maintains the code? How many Clojurists (is that a word?) can you find to work on the project? The bank would be better off by sticking to Java/Python/C#/etc.

Just because you can do it, doesn't mean that you should. That's a bad habit I've seen from many developers (honestly, I understand the interest to learn more languages and use them at work, but that often results in short-sightedness when building a project).

Re: Clojure will affect the way you think about programming

#136

Earlier quoted context omitted.

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has…

>> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure... I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it). For example, who maintains the code? How many Clojurists (is that…

> How many Clojurists (is that a word?) can you find to work on the project?

You don't need to look for Clojurians, you just need to look for developers. Getting to write in some slightly off-the-standard languages is a big draw for a lot of competent devs

Re: Clojure will affect the way you think about programming

#137
post #82

By far the most incredible thing for me was to see how far a few characters of code can go. Clojure is a very tight language where you can accomplish a lot in just one line of code. You end up suddenly having all this new, extra time to just think about your problem instead of coding it.

Another interesting side-effect of tight code, is that you become a lot less attached to it. When I worked in Java, it would often take 100s of lines of code to solve a simple problem, and once I wrote that code I'd be very hesitant to throw away or refactor it. With Clojure, it often takes 10 lines or less to solve problems that take 100s of lines of Java. This encourages a lot more experimentation and refactoring i…

The functional nature helps with the lack of fear of refactoring. Your Java code may have side effects reaching across the code base.

Re: Clojure will affect the way you think about programming

#138

Nothing I've used has the combination of ease of use and interactivity. It's pretty difficult to explain, but one can send both top level forms, or smaller pieces of code to the repl and get results without leaving the code one is working on. https://s3.us-east-2.amazonaws.com/photoblobs/screencast_201...

[deleted]

Re: Clojure will affect the way you think about programming

#139

Earlier quoted context omitted.

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has…

>> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure... I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it). For example, who maintains the code? How many Clojurists (is that…

> I think that had something to do with Clojure.

Were you on the Level team at Capital One? If so, oh hai and I hope all is well. Given all the changes there, you may want to be careful. You gotta know this is against policy if it goes much further. I know because I got in trouble over violating said policy once... If not: no. You're wrong. Headcount issues were largely unrelated to Clojure. Also, please stop pretending your best guess is some sort of calculus over complex corporate politics.

Staffing as a small startup bought by a big company is always a problem. Doubly so when you're on the leading edge of a corporate introduction into a new (and in many ways more fiercely competitive) labor market.

> can you find to work on the project? The bank would be better off by sticking to Java/Python/C#/etc.

I had no problem recrutin good clojure developers once I worked with the recruting team to help get the job postings in the right places.

> Just because you can do it, doesn't mean that you should.

The converse of this that is equally true: Just because you don't feel capable of doing it doesn't mean I should not. This is no idle speculation, we did it. We exited. We exited with a featherlight team, which turned a small and interesting project into a major opportunity for every employee.

Re: Clojure will affect the way you think about programming

#140

Earlier quoted context omitted.

Are we doing opinion threads now? Okay. I can do one too! I do like working with clojure. It's my favorite dynamically typed programming language by an easy margin. It's basically everything that was a good idea in Python and Ruby brought under the unifying role of a Lisp syntax, with a good Java FFI. This makes it slightly harder to learn (it's very difficult to learn Clojure if you don't at least know Java). It has…

> it's very difficult to learn Clojure if you don't at least know Java I'm curious why you think this is. As I've noted elsewhere in this thread, I've never written a line of Java in my life, and have worked as a Clojure dev since 2014. I also never write any code that interoperates with Java. Seems to be a very common misconception that you must know Java to use Clojure.

> I'm curious why you think this is. As I've noted elsewhere in this thread, I've never written a line of Java in my life, and have worked as a Clojure dev since 2014. I also never write any code that interoperates with Java.

You're quite fortunate, but I was not. In fact, the reason I choose clojure at Level's primary language was for Java interop with the fintech world.

In many cases if you want performant code that doesn't leak resources, you will need to appeal to at the very least java.util.concurrent. Clojure doesn't even really try to fill the gaps there.

And even if you do, a working knowledge of the JVM, java compilation, and build/deploy tooling is quite helpful. There is only so much lein can abstract for you.

Post reply on HN