This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-16
Channels
- # beginners (81)
- # calva (6)
- # cider (21)
- # clj-kondo (2)
- # clojure (62)
- # clojure-austin (3)
- # clojure-europe (3)
- # clojure-italy (20)
- # clojure-nl (39)
- # clojure-russia (4)
- # clojure-spec (19)
- # clojure-uk (23)
- # clojurescript (76)
- # cursive (6)
- # data-science (9)
- # datomic (12)
- # defnpodcast (1)
- # figwheel-main (3)
- # fulcro (8)
- # jackdaw (5)
- # jobs (1)
- # jobs-discuss (18)
- # joker (1)
- # leiningen (2)
- # liberator (2)
- # off-topic (148)
- # onyx (5)
- # pedestal (39)
- # planck (7)
- # re-frame (5)
- # reagent (3)
- # reitit (37)
- # shadow-cljs (165)
- # tools-deps (1)
- # yada (19)
I watched this video from start to end. I usually dislike panel formats. But these people have infinite wisdom… https://www.youtube.com/watch?v=khFDJi3Xxn0
and they said Clojure was the first elegant solution for STM, Shared Transactional Memory. Most STM has IO, read cache and scaling problems in the past.
I am also going to reference Tony Arcieri… which is saying they hit a 15 cpu core max when scaling. And that yes indeed, because Erlang/Elixir copies your memory per heap for each process (actors) that its bad at memory management. In comparison, the panel in the video above talk about STM, Clojure and Azul. And how Azul can scale to 1000 multi cores. But that’s about the limit for Azul.
I wonder if it’s just coincidence that Amdahl’s law which predicts how many times a system will speed up based on how parallel the code can be… considering Clojure with pure functions could be parallelized quite a bit… I wonder if that relates to the 15 core max on Erlang. I don’t know if Erlang has gone past that limit.
Erlang is more about fault tolerance in distributed system than efficiency. it so happens that some problems become very fast when you distribute them
Thoughts on this editor? Seems well thought out. I’m sure it’s user error, but it’s really frustrating how slow emacs can be for me.
When I switched to Spacemacs holy mode with ivy, my performance issues with Emacs went away
Because it heavily relies on lazy-loading, and Helm is just a slow plugin. Ivy is way faster
Its still not Vim, but I now find it way faster then IntelliJ. Eclipse, VSCode, VisualStudio, and the likes
I also don't believe any editor can ever equal emacs, unless it also is a live programming environment with hot code reload for itself
The author of Xi gave an interesting talk at Recurse Center https://www.recurse.com/events/localhost-raph-levien
they've made a number of interesting architectural choices. I'm not sure how their "bring your own language" plugin system will turn out ecosystem-wise
Re: Language agnostic - I found that interesting as well - could open up a door for Clojure to swoop in and start pwning things as it does.
Re: Ivy - I’ll definitely check that out. I’ve always ran the defaults for Spacemacs, but I think I’ll try to start paring down my config.
"The One True Editor" 🙂
It's funny you should mention "20 years" @lilactown -- I used Emacs back in the day, 17.x, 18.x and the very beginning of 19.x then I used other editors and IDEs until I came back to Emacs because I was using Clojure... about 20 years after I'd last used Emacs... and it really hadn't changed at all.
Based on your advocacy I'm interested in Atom, mostly because it gives a compelling story for the non-Java people I work with.
There's no figwheel-main yet, so now the story is on hiatus
Chlorine uses a socket REPL, so doesn't get to use the nREPL piggieback middleware. Chlorine works well with shadow-cljs, and it can be made to work with figwheel-main.
I’m not convinced Emacs is anything more than a local maximum right now. I hope other editors will supplant it. Editors like Atom and VS Code I think are approaching the point where they could replace Emacs for me. I used VS Code as my daily driver before I went to Emacs.
for me, my daily driver is all about integration with whatever language I use. Emacs gives me bar none the best integration with Clojure(Script). I also really enjoy Evil mode
secondary to that is the ability to extend the editor easily. I don’t know of any editor that can come close to supplanting Emacs right now. but I’ll happily give that up for better/easier integration
my point was pretty snarky above, but I seriously think that Xi’s approach is one that is technically interesting. but the value it provides right now is not very high, and the rate they’re going isn’t promising. it’s a small project with ambitious goals, but they’re a long way from CIDER or VS Code’s intellisense with TypeScript
I like Vim and Emacs because it is closer to the command line. I’ve had real life experiences where my IDE crashes from memory leaks, the internet silently fails or the debugger crashes etc… I went to try Visual Studio and the screen share does not work on OSX El Capitan. My system is 2-3 years old and it’s not supported. Should just use a tested tool that does screen share. Even though VS Studio does look nice doing it inside the editor.
Can anyone tell me why VS Studio is so great? It’s the support for TypeScript?
I am just skeptical. I’m afraid they will start charging $500 per year after they get everyone hooked.
Ya, VS Code or whatever that name is… Microsoft product?
They made the entire Studio Suite before for Visual Basic, Visual C++
VS Code is an open source, cross-platform editor and committed to being a free product. Visual Studio is a licensed IDE for Windows development that costs money
is Visual Studio Code = VS Code?
What’s the best feature about it?
There’s only a few things I need from an IDE… debugger, auto complete, doc lookup… repl is good
Does it scaffold your JS projects for you?
I will try VS Code this week. If it scaffold my JS stuff, maybe I will use it.
Most IDE’s hurt my eyes because I can’t change the font sizes when I want. I love Spacemacs, Emacs, Vim
I've never needed/wanted a debugger in my editor/IDE. My "needs" list for a Clojure editor are pretty minimal: syntax highlighting, code assist/auto complete, parens-aware (I have both paredit and parinfer installed), REPL connection, load file, eval top-level form, eval current form, show docs, show source. That's about it. Having the eval results and the docs shown inline, directly in the editor is a high priority "want" since I mostly have the REPL buffer minimized/obscured. And I use REBL for data visualization/navigation so some sort of connection there is also important (Chlorine has "inspect" versions of eval current/top-level forms that send the value to REBL as well as display inline and in the REPL).
I just tried VS Code. And it’s not finding all my directories on OSX. hmm. I think I will just stay with Spacemacs for now.
The ink-based Clojure plugins for Atom worked pretty well, back when I was using them. But stopped using Atom because the memory bloat was just too much. If the VSCode version reaches that level of maturity, I might hop to that. That said, I've really gotten used to Spacemacs + org-mode, and used emacs exclusively during Advent of Code this year, and feel a lot more comfortable with it now: (almost) everything just works.
Every time I approach Emacs, it feels like an 80 story point side project of its own. I realize it's probably worth it in the end.
The basics didn't change that much yes but the ecosystem and the overall ux is much better nowadays
If you want to introduce Clojure to a young Java developer (about 5 years of developing) to give them an overview of what it is, what would you use? (not to teach them, just to give them a broad stroke overview) "Simple Made Easy" is what I use for older developers that have battle scars. It doesn't feel appropriate in this case.
I just jurned 22, and I found Simple Made Easy to be extremely useful. I watched all talks by the Clojure core team, and Simple Made Easy is what made everything click, because it lays out the principles underneath the design of Clojure. Most of the arguments I've been in (or seen) about languages ultimately boiled down to statements like "use the right tool for the job" or "all languages are turing-equivalent". And separating the constructs from the artifacts they generate was invaluable. That being said, I didn't understand half of the talk the first time I watched it. After watching other stuff like "The value of values" and the conversation b/w Rich Hickey and Brian Beckman and then revisiting Simple Made Easy, I gained much more from it. You might wanna consider "Clojure for Java Programmers" by Rich Hickey.
Thank you @UBU6QCSJH
I first watched Simple Made Easy when I'd been developer for about 4 years and I got a lot out of it. I'd previously been given the space to build small-but-overengineered type systems, and seen enough legacy codebase abusing inheritance, the C# type system, ORM entity models & 100s of 'model' classes whose only purpose is to map from one to another
@michael.e.loughlin thank you for sharing that
@danie Not 100% sure if this is what you’re looking for, but I’ve found Stuart Halloway’s ‘Introduction to Clojure’ talk to be a really nice whirlwind tour of Clojure’s philosophy, syntax and major features: https://vimeo.com/68375202
I'm betting a lot of people here have experience about Open Source and especially governance of open source projects. I'm looking for feedback on my own governance of a open source project that just got started. https://github.com/open-services/open-registry/blob/master/docs/governance.md
I was wondering if there is any formalized implementation of the "versioning" that was outlined by Rich in one of his talks (I'm still trying to remember the name of which). His idea was that symver is flawed because it hasn't been good at enforcing what is a minor/major/hotfix change, and it can simply be that additions to an api would require no real change to the namespace, while breaking changes are just done in another namespace. Has there been any written formalization or even code implementation of this say as a library?
clojure.spec.alpha did this, there is now also clojure.spec.alpha2
right, I was actually curious if he was going to "practice what he preached" with spec since this was the only library I've seen get a namespace update. What idea I had, which I started to explore but put on the back burner was this: * Have your namespace, implement an api. if you add to the namespace that's great, keep adding. • When removing or modifying, create another namespace and and declare what is being removed, and redeclare modified functions. • The orchestrator would do a merge of the ns vars, removing/redeclaring what is in the new ns This was mainly because my understanding was that you'd essentially copy and paste the implementation, or import all and expose that didn't change in the new ns.
The creator of #cljfx @U47G49KHQ wrote about his experience employing those principles in the wild https://vlaaad.github.io/2019-04-05/growing-cljfx
interesting, yes it was the spec-ulation talk.
what is there to implement?
probably nothing, I looked into "implementing" something more formalized, but ultimately realized that it's probably better formalized by a simply worded specification of the versioning system
in this scenario, there is no versioning system other than "an ordered series of versions"
and the selection algorithm is "use the newest one"
right, my other thought was that if you didn't want to duplicate an entire code base for the next version ns, something would allow for a melding of much of the implementation from one ns to another
I suppose, although that sounds unnecessary
I thought so to
if you use maps, which are open, you can pass them to functions from whatever namespace
What is the best way to get a non-programmer (absolute beginner) learn a functional language like clojure? Are there any course/tutorials that make it fun to learn the concepts/language without making it too complicated?
Thats actually a good question. The most cited book is “Clojure for the Brave and True”
but; I read that as a programmer already
is it for yourself, or who is your audience?
Some people like small problem solving, maybe thats something to look at? I think they are often referred to as “koans”.
… but again, I am not quite sure how easy that is when starting to program
I am thinking of creating a basic project (may be a simple game) and may be guide her to complete it
yeah, there is play-clj for a game library
This is not going to be the most popular answer, but I think Racket would be a really strong choice. It has an IDE with REPL\Preview built in, it’s a self-hosted language, and has a large variety of learning material often aimed at people who may be entirely new to programming.
For instance https://nostarch.com/realmofracket.htm goes from simple FP concepts while writing number guessing games in a terminal, to games with networking and graphics.
I was looking at https://sekao.net/lightmod/
Looks solid as well, there’s also http://nightcoders.net/ if that helps.
I don't know about the functional bit, but I'd start someone out with "hello circle" and "hello square" in P5.js . I could probably teach a lot of the same material in clojure/quil but then I'd have to recreate the megaton of learning material that exists in P5.js
Remember there is the #programming-beginners channel here set up to help people who are learning how to program with Clojure as their first language. Kind of quiet these days though.
I just figured "If I thought about it, at least 10 people had as well"
so you can implement half of the new api in a new namespace, and use the old api for the other half
yeah, this is one example. I thought of making an orchestrator specified by some dsl and do all that with the standard way you would code already, instead of creating maps with function declarations and such
it may offend the sensibilities of some, but just copying code into a new namespace is really easy
cool. I have no problems with that, was just exploring this and it always pops into my mind, especially when I see the spec library. I haven't seen too many examples of this in any libraries I use normally other than spec
I could see some kind of convention evolving (like spec has and has changed) for specifying that a namespace is larval
the reason I stopped going too far down simply was that if you create a namespace with say, one change/deletion with my solution, you'd just have one function specifying that a function from a previous version was changed/deleted, and nothing else, making looking through the code scale poorly
so copying the code base is the most practical
if you're just changing one function, you can just rename that function
true, and with copying the code-base it wouldn't be awkward
one scenario I'm curious about @alexmiller, if you have an addition unrelated to breaking changes in the next ns, would you propogate it to all namespaces.
to make it available to any version
or once you make another version, you only add to that
I'd say that's at the discretion of the lib owner and what they want to support
for spec, are all new additions only to spec2?
sorry for grilling you, I think that's my last q
at the moment, we are only working on spec2, not currently planning on going back to do anything on spec 1
but we could
we may end up renaming everything again before spec 2 is "released" to a non-alpha ns
there are enough things still to do that that transition is not something I'm worried about right now
kind of depends how it aligns with clojure releases too
this style of accretive change is not unheard of - I believe the old Eclipse code did this, and certainly they used to do stuff like this in the old Windows COM/OLE days
I see, I figured most things I recently discover have been discovered long before I started programming 🙂
When I was actively evolving clojure.java.jdbc
once thing I did when I deprecated a slew of functions was that I copied the whole of clojure.java.jdbc
to clojure.java.jdbc.deprecated
and then modified clojure.java.jdbc
into the new API style. That made that release breaking-but-easily-fixable (by a quick find'n'replace of the namespace). With hindsight, it would have been better to leave clojure.java.jdbc
alone and add the new API in clojure.java.jdbc2
(or some new namespace) so that there was no actual breaking release. But Rich hadn't given his Spec-ulation talk at that point 🙂
That's why next.jdbc
is starting off, from scratch, in a brand new namespace (and, currently, a brand new library) and I'll decide where to put it once I've finished experimenting with the API.
I like that, that's kind of what I was thinking, separate breaking changes from additions, merge along the way.
The next.jdbc
API is completely different to clojure.java.jdbc
but I'll probably provide an API shim that is mostly compatible with clojure.java.jdbc
once things stabilize. If I end up putting next.jdbc
into Contrib, I will probably reimplement the current clojure.java.jdbc
functions on top of the next.jdbc
core as it is significantly faster.
what an annoying problem to solve, versions and breakage… there never seems to be a silver bullet
The bottom line, as I discovered working on clojure.java.jdbc
, is that breaking changes are disruptive in ways you might not imagine. There were a lot of books and tutorials out there written around the original API (that leveraged a dynamic *db*
Var) and folks don't pay much attention to library versions when they're learning so they often try to run the books' code on the latest version of each library...
true, I do think the ns versioning is pretty easy to do, even without formlization
as long as you have a ns mechanism it should be easy to implement.
Not yet @dpsutton
the idea of making a compatibility shim for the old stuff to work on based on the new stuff seems to kind of run counter to the idea of accretion only
when you make the decision i'd love to read a blog post of the arguments you weighed. i have an opinion and would love to hear your opinion when you are making it
with accretion only you can say "hey, new stuff is going on over here, but the old stuff is still over there if you want it" and then ignore the old stuff and let it hum along, once you do the shim thing you still have to maintain both and now they are tied to each other
@hiredman I'll only do it if I can a) make it completely compatible and b) the performance gains are worth the pain 🙂 I sort of already have a partial shim in next.jdbc
but I'm still undecide as to where those functions will ultimately live.
@dpsutton https://github.com/seancorfield/next-jdbc/blob/master/README.md has a lot of my thinking around next.jdbc
written down.
Ah, true, I haven't discussed that in writing yet -- only https://github.com/seancorfield/next-jdbc/issues/3 as a placeholder for that discussion. I have had random chats about it in both #sql here and on Zulip.
on dutch clojure days, Bozhidar Batsov talked about why nrepl was moved out of contrib so you (@dpsutton) may be interested in that!
(video not yet there tho)
Yeah, I've heard Bozhidar complain about Contrib on many occasions 🙂
yeah, not saying that he was right or wrong, just putting it out there ^^!
yeah i want to see someone's case for contrib. As I don't see too many arguments in that direction
Contrib pros: existing, proven CI/build/test infrastructure; "authority" of Maven and org.clojure
group; visibility through autodoc and http://clojure.github.io docs.
Also visibility through http://clojure.org e.g., https://clojure.org/community/contrib_libs
i read these earlier and now again and meant to thank you for your thoughts, @U04V70XH6
The pros I guess are that the contribution workflow is something you have to get used to and a bit slower - apart from Sean the current contrib maintainers as active - ymmv. About the visibility point, not really sure it is a thing because, for instance, I was not really aware of many contrib libs .. until I wanted to contribute to them and find some hurdle...my experience at least was that. Just reporting it..m
@U0C8489U6 Always interesting to hear a counter-opinion to the "reach" of Contrib -- I'm just surprised when I hear that since Contribs have all their documentation linked from the core Clojure docs, and they're all in the same GitHub organization. How can folks not be aware of those libs? (that's not rhetorical -- what could Contrib libs do to be more visible?)
Yes you are right I don't see any main visible approach than that. I have to say that now that you dedicated #announcements to its current use things are way better...some of the contrib libs never got "announced" maybe? In any case I rarely check the website, I should do it more often...not used to it maybe?
Most of the Contribs have existed way longer... maybe that's the problem? I took over clojure.contrib.sql
and turned it into clojure.java.jdbc
back in 2011 🙂
Perhaps we need to periodically re-announce these things? 🙂
Yeah maybe that's it? I like the idea
Contrib pros: existing, proven CI/build/test infrastructure; "authority" of Maven and org.clojure
group; visibility through autodoc and http://clojure.github.io docs.