@jon920 > What are the most common IDEs and editors? This post has a full list https://betweentwoparens.com/clojure-text-editors

You probably meant prefix (Polish) notation.

I'm not sure. Clojure doesn't have a Truffle based implementation. I'm not sure Truffle is appropriate either, since Clojure is compiled. But if Truffle based lang can interrop with Java, they should be able to interop with Clojure as well.

I'd say so. Atom with Chlorine is popular as well.

Nice :thumbsup:

But unfortunately it's a bit dead as of now.

oh really? thats a shame, i really liked it when i used it.

Last time I checked it was still using some deprecated Electron with multiple issues due to that and with no workforce to rewrite it.

The LightTable code is great! Thank you.

cljfmt and zprint would be the main ones. I use cljfmt personally. Simple and straightforward.

aside from many other major differences in philosophy, scala is big on static typing while clojure is dynamic

I tried introducing Scala at work back in '09 but the long edit-compile-deploy-test cycle didn't sit well with folks here who had worked with dynamic languages, so we switched to Clojure.

Scala is a hybrid language so you can use it as just a "better Java" without leveraging the FP aspects. It's a very complex language too.

I'm not a fan of Scala

So I can't recommend it. Implicits are the worst language constructs I've ever seen

Scala has also suffered from a lot of backward compatibility problems over various releases, often forcing you to upgrade your entire toolchain just to use a newer version of the compiler (the 2.7 to 2.8 upgrade in particular was just horrendous!).

I'd sooner choose Kotlin as a "better Java" before I'd choose Scala.

Yup, I'll agree on implicits. They seem so, so convenient but they make code really hard to understand and reason about. So much "magic".

Yup, I'll agree on Kotlin too. I think it's a much nicer language than Scala. That said, I haven't used Kotlin in production (but I have used Scala).

Java is going to subsume all of those languages besides Clojure

Oh no Scala has a long compile time? I can’t go back after seeing what is possible with Go.

I can see Kotlin thriving due to Android

lol. with regards to that. we chose java over scala for that reason. "oh java 10+ gives us all the stuff we want from scala anyway". but now we can only use java 8 because we need spark and spark is written in a version of scala that only supports java 8 and it's a massive project to rewrite of spark in a newer version of scala that supports a newer version of java so that we can write spark code in modern java 😆

I find Scala is a bit of a monster. It does OOP, it does FP, it tries to add extra typing to the JVM, the combination feels a bit chaotic. Like a jack of all trade, master of none.

I've heard second hand that with prudent use, Scala can be your ideal language, until you need to interact with someone else's Scala lib (and their ideal language is a different subset of Scala) - sounds a lot like the situation with C++

And Java interrop isn't very good as well

As someone who spent nearly a decade doing C++ (and was on the ANSI Standards committee for eight years), I don't think C++ even comes close to the complexity and multiple-dialects that Scala suffers from...

one major benefit with Clojure is that interop works great both ways - it's designed to be simple to use Java libs from Clojure and to be simple to use Clojure libs from Java

And Clojure supports basic OOP concepts if you want them.. this shouldn't be OOP lang vs non-OOP lang

that's true, so long as you agree with me and other right thinking people that enheritance is not a core OOP feature :D

I don't even know what OOP is anymore

Most reasonable people avoid the original OOP concepts. OOP nowaways sounds like "this is OOP, therefore everything must live in a class, classes everywhere!"

Had a big convo with noisesmith about this just the other day 😛

I think of OOP as objects everywhere

A little meta: I think classes/objects by default is what people consider casually as "it supports OOP". ie mandatory classes = safe, OOP

I think we're saying the same things

I see an object as a self-referential collection of fields and methods. Like a data-structure that stores key/vals where vals can be values or functions. And where the functions inside the values have a magical implicit reference to the object, so it can refer to other keys in the object and make use of them.

Oh, a mutable data-structure as well.

And then OOP languages, are those who build upon this fundamental data structure

They don't have to have classes

Its actually quite a tricky structure. I think to make objects really concrete in your head, it helps to try and implement one. That self-referential property isn't obvious.

And it is what separates an object from a mutable Map

Anyways, that's only my chosen taxonomy. But I find it makes for a good model, and what I like about it, is from that angle, it makes sense that JS, Python, Java, are OOP, and that Clojure is not.

I consider Scala an anti-pattern for many of the above mentioned reasons. I’ve seen several shops that programmed themselves in a corner when it comes to comprehensability, being able to hire etc.

I’d add there that for instance Kotlin and Swift which look very much the same are already worlds apart. Swift has a lot stronger guarantees on immutability.

I’m looking to add another tool to my kit to invest in long term. Right now I have Go for CPU bound tasks and easy deploy. Ruby for general purpose. Erlang/Elixir for distributed and web performance. Javascript when forced to, or in the future when it gets pipelines and pattern matching. At this moment I’m actively working in Ruby, and spending a great deal of time learning Erlang/Elixir on the side. I’m already sold on keeping a close eye on Clojure for sure, just trying to get a grip on differentiators from sidelines without actually programming it yet.

What does it compile to again?

JVM bytecode or JavaScript or .NET IR depending if you are using Clojure, ClojureScript or ClojureCLR

Ah that way. So you have Clojure compiled or you have the same code interpreted in the REPL?

Clojure compilation happens at runtime. So the REPL compiles the code as it is being sent to the repl.

Clojure is never interpreted -- yeah, what he said.

The Clojure compiler works on a form-by-form basis, not a file, so the REPL and "running a program" work the exact same way.

That's why you can REPL into a live, running process -- even a production process -- and redefine functions on-the-fly, and it updates the bytecode (compiled, in-memory).

The REPL also compiles to byte code every time you type something in?

Yes it does, like Sean said before, Clojure is never interpreted, always compiled.

@URK0TMXDG Stu Halloway talks about this in, I think, his REPL-Driven Development talk. He says we don't really need files etc since we could just feed our entire program to the Clojure REPL, one form at a time, in the right order, and it would have exactly the same semantics as Clojure "running" the program from the files.

If you type in (defn foo [n] (inc n)), it compiles immediately to a class named user$foo (assuming you're in a REPL in the user ns). You can see that by typing (class foo). If you type (ancestors (class foo)) you'll see all the interfaces implemented by that class and all the classes that are extended by it...

And what does Clojurescript compile to then?

ClojureScript transpiles to JavaScript @URK0TMXDG (I don't use cljs so I can't provide more details than that).

You can use: http://app.klipse.tech/ too see what ClojureScript compiles too.

In the above case, (defn foo [n] (inc n)) becomes

cljs.user.foo = (function cljs$user$foo(n){
  return (n + (1));
});

And in JavaScript, functions are already Objects. So in both cases, functions get compiled down to Objects of the underlying language.

Much as I'd like to consider JS to be the "assembly language of the web", the pedant in me has a hard time describing ClojureScript as a compiled language (hence my use of "transpiled") 🙂

Some people consider GCC a transpiler 😋

But in this case I just didn't want to confuse with semantic squabbles

I personally like the answer here https://stackoverflow.com/a/44932758/172272

(compilers, transpilers, and interpreters is what I used to do for a living back in the late 1980s which is why I'm a bit pedantic about it)

I think the official ClojureScript doc calls itself a compiler. And so does the Google Closure library and for example Babel. And all these things just output JavaScript. So I feel the line between compiler and transpiler has really blured and it seems more and more those are used interchangeably. Even Emscripten calls itself a compiler, but it actually compiles C/C++ into JavaScript! So its actually going from a lower level to a higher level language 😛

Crazy times we live in

https://www.youtube.com/watch?v=ROor6_NGIWU

The Language of the System - Rich Hickey

I need to re-watch that one, don't remember the content!

Maybe January 2020 I'll have myself a little Rich Hickey maraton 😛

basically what you just said

just linked it as a reference for drilling down

Hope he has a new talk this year haha, I need my Rich Hickey fix

If you prefer reading to listening/watching, and want a few extra references/links thrown in for good measure, there are transcripts of most of his talks here: https://github.com/matthiasn/talk-transcripts/tree/master/Hickey_Rich

https://clojure.org/about/state#actors - prob best summary from Rich

I think Dotty is a great thing. They recently announced feature completeness of the new compiler.

Dotty = new compiler for Scala

Multiprocessing story of Ocaml is quite weak though.

I see F# as more practical ML implementation. Even syntactically is less bizarre.

Rust make you ❤️ garbage collector 🙂

C even more so 🙂

Some people talk nicely about Nim https://nim-lang.org

The thing is that Rust has a claim that unlike Haskell, I believe in. Trade some convenience for the borrow checker, and you get memory safety without overhead.

When this is what you need, it is pretty awesome

Haaskell says, trade some convenience for pedantic static type checking and have less bugs, but I don't believe it truly reduces bugs, so I don't find that trade to be a good one. Rust on the other hand makes a trade that I can see taking.

I tell you what the problem is here. I was talking to Phil Wadler when he was in Prague. I asked him what he thinks about linear types. That's what Rust is based around. And he replied that "it's not worth it". Of course this is argument by authority and maybe he would even dismissed my quotation as it is written here. But I actually have feeling it's huge and inconvenient trade off.

Some even simple things are unnecessary complex with Rust. And their Result type is leaky because of unwrap etc.

But I'm not expert at all. I wish Rust shiny future, because it is quite modern compiler. It would be nice if it succeeds!

That's fair. I mean, for many things, a GC is just better. But when you need something more performant, that's when I feel it could be worth it. Also, Rust types are affine, slightly more convenient to use then linear types. Some people might argue that, something like C++ unique_ptr is enough, so you lean on move semantics only when needed, instead of Rust's default to move semantics. We'll see, every new release of Rust they make it slightly more ergonomic. Lets see how far they can take it.

My personal fav is hardware accelerated GC. I hope this becomes standard in the future. I saw some paper on it, and they achieve such better performance, almost eliminate completely the GC overhead.

there's no digits function, IIRC this is one of the puzzles from http://4clojure.com

looks like the question was edited to include the digits function

@U051SS2EU thanks for pointing that out, totally missed that

I suspect the issue is with converting - to _, but I'm not sure where that _ needs to be replaced

Yeah, right now depstar doesn't do that translation. I'll create an issue to address that...

much better in 0.5.1

And clj-new updated to 0.8.4 to include the fixed depstar too!

Thanks for spotting that!

yw

there's some java interop builder stuff I'm trying to work with, but I'm tired of writing (.something ,,,) over and over and I'd rather just use data

there's definitely prior art to doing things this way

got any links?

I mean, for that specific case, a function should do

@U0K064KQV I think the intention here is that the :foo-bar keyword be translated to a .fooBar setter method

@U0FEHF1RS I looked but didn't see it in the place I expected

Oh I see, like an auto-mapper thingy

the camel-snake-kebab library does the kind of key - method name translation you'd want at least https://github.com/clj-commons/camel-snake-kebab

then it's just a question of doing that parsing / translation to build the final form (you might want eval too here...)

I have no experience in writing macros. Can you explain why an eval is needed?

macros can only operate on literal data in a source form, in order to construct method calls out of keywords that are not literals (eg. if they come from some var or data somewhere else), you need eval (as new method calls can't be created at runtime without expensive and complex reflection)

I have a working version of clojure.java.data in git that supports this:

org.clojure/java.data
{:git/url ""
 :sha "20d8562bf451f41bf58ac0b38401648ba21232a3"}

(require '[clojure.java.data.builder :as builder])
(builder/to-java java.util.Locale {:language "en"})

@seancorfield: how would I call (builder/to-java ,,, if my builder is actually initialized like this: (ABC/builder) instead of (new ABC$Builder) ?

I get this error: > Error: > Execution error (InstantiationException) at sun.reflect.InstantiationExceptionConstructorAccessorImpl/newInstance (InstantiationExceptionConstructorAccessorImpl.java:48).

A static method on the parent class?

in this case, yes: https://github.com/oneops/infoblox-java/blob/master/src/main/java/com/oneops/infoblox/InfobloxClient.java#L89

Thanks. Yeah, I'm going to need to support building on an instance in cases where I can't just construct the builder class... gimme a few...

OK, the latest version on GitHub supports (builder/to-java ABC (ABC/builder) props opts) so you can pass in a builder instance if it can't be directly constructed from a class.