Same... the light bulbs lit up for me after working through chapter 1 of SICP.

I'm grateful a bunch of obnoxious loudmouths on obscure forums kept shouting I should read SICP, wouldn't be here otherwise

Jank in usage of this in Javascript sums it up pretty well 😄

@U0K064KQV > What do you expect happens here? What do you expect happens here? Does (var i 3) ... Hard to guess because you have apparently created your own private language, but not provided us the specs. ClojureScript does not have this var form, you describe. (Maybe you defined it in a macro? Then what "happens" depends on macro expansion.) The closest thing to a let block in JavaScript would be invoking an anonymous function, where I would expect function-semantics to apply, along with var's overly loose semantics. At no point would i be immutable.

var i = 1

(i => {
  console.log(i) // -> 2
  var i = 3
  return i
})(2)            // -> 3

console.log(i)   // -> 1

(i => {
  i = 3      // okay
  let i = 4  // 💣
)(2)

(defn memoize [f]
    ;; mutable cache
    (let [cache (atom {})]
      ;; close over
      (fn [x]
        ;; return from cache if exists
        (or (get @cache x)
             ;; else mutate cache
            (let [y (f x)]

              (swap! cache #(assoc % x y))
              y)))))

> should a Closure capture a mutable variable? What about const array that has mutable variables inside? There is no absolute answer to this question because language author may decide to copy the variable or to use a pointer. You can do this thing with mutable arrays in Clojure just fine. It doesn't mean you should but you can.

That's exactly my point, there's no logical semantics. That's what tricky about it. Immutability in contrast doesn't beg these questions, it's much simpler. In Java for example it errors if you try to capture a mutable variable in a Clojure. In JavaScript it doesn't. Then capturing a mutable variable is different from capturing a mutable container. And then in JavaScript var and let have all kind of non intuitive interaction. Which is why people now say to never use var. Etc.

> In Java for example it errors if you try to capture a mutable variable in a Clojure. In JavaScript it doesn't. Interesting. I would guess Java side of that is an unfortunate side effect from tacking on lambda support so late in the game. Realistically though, there is no meaningful difference between int i = 1; i = 2 and MyContainer<int> i = MyContainer<>(1); i.set(2);, besides yet more boilerplate in an already long-winded language. (That is why I felt no hesitation in using Clojure's atom for my example above about mutating inside a closure.) > Which is why people now say to never use var. As I just said, letand const are intended to deprecate var . The reason people say not to use var has nothing specifically to do with weird interactions with let. The design of var is pretty universally considered a mistake, but changing it would break backwards compatibility. let and const were specifically intended to replace var from the outset. Unless you find yourself working in legacy JavaScript, you should not need to know or care about what var does. > there's no logical semantics. Patently untrue. Those semantics are laid out in excruciating detail here. https://www.ecma-international.org/publications-and-standards/standards/ecma-262/ There are holes in the logic, but that is unavoidable. I challenge you to name any language in which you cannot find some case of unspecified and/or explicitly undefined behavior. None of those holes relate to the discussion brought up so far. I certainly agree the semantics of JS are far too complex, with too many surprising rules. Not sure how much of that is due to mutability and how much is due to other factors like: • JS was created in only a week and a half, with a mandate to make it look like Java even though it was a derived mainly from Scheme. • For most of the last 30 years, numerous competing parties have haphazardly tacked features onto JS with the intent of standing out in the market. Standards were then occasionally re-specified to conform to in-the-wild usage of all these competing JS supersets. (Only recently did major browser vendors choose to mostly work together here.) • Every new version of the spec prioritizes backward-compatibility above all else. Up through ES6 that would frequently include canonicalizing broken implementations of older specs (because presumably some website somewhere is dependent on that breakage). Anywhere one major vendor implemented a feature correctly while another one did not, all reasonable effort was made to support both implementations in parallel. • The spec is written by commitee, generally leading to subpar compromises that don't quite satisfy anybody, but is hopefully better than not making any changes. Don't misunderstand me, I 💯 agree that immutability adds simplicity. But it's not a lack of semantics that make it difficult to manage state.

I think you might have missed my point 😂. You can define many possible semantics, that's why it's complex. No semantic are arguably correct, they're just what they are. This is because the mutability and the interplay with scopes and execution timing adds complexity and creates weird edge cases that you have to make a decision as to what to do about it. Different languages will make different decisions. I'm using JS as an example, where they had one set of semantics for mutable variable using var for many years, and recently thought ok maybe those create too many programming mistakes and is too confusing, and now attempted a second set of semantics with let/const. This does create some new edge cases which they also had to make decisions about, that's what my example shows. Vars are function scoped, you could choose to allow defining a function variable inside a let block, or you could choose it would be too confusing and not allow it. Both would be correct, it's just a design decision. Now the thing is as a user, it's not intuitive which will have been chosen by different languages. Again, that's my point, too many edge cases and decisions of how the language should handle them, so as a user, it's very confusing and you're kind of left wondering often, wait, so here what's going to happen? And it's not always obvious what will.

My point isn't that the semantics are not properly documented, just that there's a lot of edge cases, and therefore it makes the semantics complicated, which in turn means a lot of ambiguity is created as to figuring out which semantics apply and how it'll behave.

> JS was created in only a week and a half What about standards and all other development? I wouldn't call this "week" or even year, or even 10 years. Wikipedia says it's there for 26 years. So no, it's not a week and they had time to rethink it completely.

@U028ART884X See the other bullet points: "numerous competing parties have haphazardly tacked features onto JS", "written by commitee", "prioritizes backward-compatibility above all else". Yes. JavaScript has changed over the years. But the original work is mostly still there, enshrined in all it's glory. (Ignoring that initial attempts to actually implement it in Netscape probably forced some early refinements) the history of JS is largely one of non-uniform additions, (via conformance of hostilely competing forks) and conformance of the spec to reclassify implementation bugs as valid. Any attempt at "Wouldn't it be better if...?" is traditionally met with either dogged ideological disagreement or "Oh God! Yes! That would be so much better... Except we know of at least N existing websites that would break if we did that." This means you either get no change or a new feature living beside the old. Or worse, you get new behavior squashed on top of old behavior in an unholy way, with lots of weird new edge cases to worry about.

Wouldn't LSP server try to simply "work"? :thinking_face:

I have no idea about what LSP does for .java files (presumably clojure-lsp does nothing - it's not its job) also, I'm primarily looking for something I'd set up in CI.

I was thinking about Java's LSP server. But probably it wouldn't work because to find that Clojure classes exist (:gen-class) it needs to build the JAR and generate classes :thinking_face:

I can imagine it working, .java files are just .java files. One could just specify one's java source paths to LSP and pretend the rest of the clojure project doesn't exist.

That's what I was thinking too. But then Clojure wouldn't be readchable and the integration point would constantly show errors.

oh I often use .java files for low-level stuff with no clj integration whatsoever

I didn't try this and I talk here on purely theoretical level 😄

#cursive does that 👀 BTW, you can find a few "java" topics in clojure-lsp changelog https://github.com/clojure-lsp/clojure-lsp/issues/762 Simple things like autocomplete for java class in clojure file and go-to-definition from clj to java should work.

my question is different :) the tldr is "what's a good linter for .java files". clj has almost nothing to do with this

Hey Lyn. on the code again may interest you. Some recent episodes are exactly what you describe. https://www.youtube.com/c/onthecodeagain https://www.youtube.com/watch?v=0mrguRPgCzI https://www.youtube.com/watch?v=V-dBmuRsW6w

Thanks. Doesn't look like a podcast?

I'm not sure podcast is a good medium for whT you are asking. The closest one I can think of would be Functional Design in Clojure

https://clojuredesign.club/ . Not exactly deep. But mostly sticks to "This is how I might build X."

No new episodes since 2020 though. 🤷

Cool. Yeah podcasts are not ideal but some pull it off, mobycast comes to mind in the aws space.

nice idea actually, I would consider paying a patreon account to someone who writes or shows mundane stuff like "how to create a cron replacement in clojure" or "handling promises with error handling and cancellation with cljs"

Tried out functional design in clojure last night, that one's really good, thanks everybody.

Yeah it's the best, I love that podcast