Fork me on GitHub
#off-topic
<
2019-04-16
>
hipster coder02:04:17

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

👍 4
hipster coder02:04:46

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.

hipster coder02:04:57

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.

hipster coder02:04:58

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.

lilactown03:04:46

Erlang is more about fault tolerance in distributed system than efficiency. it so happens that some problems become very fast when you distribute them

Daniel Hines03:04:53

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.

didibus05:04:02

Slow? UX wise or performance?

didibus05:04:29

When I switched to Spacemacs holy mode with ivy, my performance issues with Emacs went away

didibus05:04:02

Because it heavily relies on lazy-loading, and Helm is just a slow plugin. Ivy is way faster

didibus05:04:46

Its still not Vim, but I now find it way faster then IntelliJ. Eclipse, VSCode, VisualStudio, and the likes

didibus05:04:26

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

didibus05:04:52

Which Rust doesn't sound like it can do that

mpenet06:04:36

+1 for ivy

mloughlin08:04:39

The author of Xi gave an interesting talk at Recurse Center https://www.recurse.com/events/localhost-raph-levien

mloughlin08:04:26

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

Daniel Hines11:04:24

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.

Daniel Hines11:04:45

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.

lilactown05:04:10

I think that Xi is about 20 years away from being as useful as Emacs is today

🙂 4
seancorfield06:04:43

"The One True Editor" 🙂

seancorfield06:04:22

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.

seancorfield06:04:12

And then I switched to Atom, and I much prefer it. bring on the hate 🙂

🙃 4
4
danieroux09:04:13

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 simple_smile

henrik10:04:51

How does figwheel-main relate to Atom?

danieroux12:04:35

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.

lilactown14:04:33

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.

lilactown14:04:15

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

lilactown14:04:19

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

lilactown14:04:36

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

hipster coder17:04:08

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.

hipster coder17:04:21

Can anyone tell me why VS Studio is so great? It’s the support for TypeScript?

lilactown17:04:37

do you mean VS Code?

hipster coder17:04:51

I am just skeptical. I’m afraid they will start charging $500 per year after they get everyone hooked.

hipster coder17:04:07

Ya, VS Code or whatever that name is… Microsoft product?

hipster coder17:04:24

They made the entire Studio Suite before for Visual Basic, Visual C++

lilactown17:04:49

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

hipster coder17:04:20

is Visual Studio Code = VS Code?

hipster coder17:04:13

What’s the best feature about it?

lilactown17:04:41

probably it's out-of-the-box support for web dev

hipster coder17:04:43

There’s only a few things I need from an IDE… debugger, auto complete, doc lookup… repl is good

hipster coder18:04:04

Does it scaffold your JS projects for you?

lilactown18:04:17

I don't know

hipster coder18:04:49

I will try VS Code this week. If it scaffold my JS stuff, maybe I will use it.

hipster coder18:04:38

Most IDE’s hurt my eyes because I can’t change the font sizes when I want. I love Spacemacs, Emacs, Vim

seancorfield18:04:52

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).

hipster coder07:04:45

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.

fellshard19:04:15

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.

henrik15:04:11

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.

✴️ 4
mpenet06:04:25

The basics didn't change that much yes but the ecosystem and the overall ux is much better nowadays

danieroux09:04:55

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.

jaihindhreddy13:04:51

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.

mloughlin10:04:15

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

danieroux10:04:10

@michael.e.loughlin thank you for sharing that

dronacharya10:04:28

@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

danieroux10:04:02

@dronacharya that looks perfect, thank you!

👍 4
victorb13:04:24

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

theeternalpulse20:04:08

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?

Lennart Buit20:04:04

clojure.spec.alpha did this, there is now also clojure.spec.alpha2

theeternalpulse20:04:53

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.

jaide20:04:12

The creator of #cljfx @U47G49KHQ wrote about his experience employing those principles in the wild https://vlaaad.github.io/2019-04-05/growing-cljfx

theeternalpulse20:04:43

interesting, yes it was the spec-ulation talk.

Alex Miller (Clojure team)20:04:57

what is there to implement?

theeternalpulse20:04:30

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

Alex Miller (Clojure team)20:04:06

in this scenario, there is no versioning system other than "an ordered series of versions"

Alex Miller (Clojure team)20:04:32

and the selection algorithm is "use the newest one"

theeternalpulse20:04:33

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

hiredman20:04:17

typically that already just works

Alex Miller (Clojure team)20:04:24

I suppose, although that sounds unnecessary

hiredman20:04:39

if you use maps, which are open, you can pass them to functions from whatever namespace

neupsh20:04:54

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?

Lennart Buit20:04:58

Thats actually a good question. The most cited book is “Clojure for the Brave and True”

Lennart Buit20:04:07

but; I read that as a programmer already

neupsh20:04:47

Yes, thats what I felt like.

Lennart Buit20:04:38

is it for yourself, or who is your audience?

neupsh20:04:45

Its for my wife 🙂 She wants to learn programming but she is from Medical background

Lennart Buit20:04:38

Some people like small problem solving, maybe thats something to look at? I think they are often referred to as “koans”.

Lennart Buit20:04:48

… but again, I am not quite sure how easy that is when starting to program

neupsh20:04:53

I am thinking of creating a basic project (may be a simple game) and may be guide her to complete it

neupsh21:04:18

If I find nothing out there. I am not very good at teaching though 😄

Lennart Buit21:04:02

yeah, there is play-clj for a game library

jaide21:04:20

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.

jaide21:04:09

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.

neupsh21:04:49

Yeah that looks like a good book.

neupsh21:04:15

this does provide a single tool with all build tools baked in for beginners

jaide21:04:17

Looks solid as well, there’s also http://nightcoders.net/ if that helps.

Eric Ervin22:04:24

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

orestis03:04:56

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.

theeternalpulse20:04:55

I just figured "If I thought about it, at least 10 people had as well"

hiredman20:04:58

so you can implement half of the new api in a new namespace, and use the old api for the other half

theeternalpulse20:04:25

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

Alex Miller (Clojure team)20:04:40

it may offend the sensibilities of some, but just copying code into a new namespace is really easy

theeternalpulse20:04:29

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

hiredman20:04:13

I could see some kind of convention evolving (like spec has and has changed) for specifying that a namespace is larval

theeternalpulse20:04:33

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

theeternalpulse20:04:40

so copying the code base is the most practical

Alex Miller (Clojure team)20:04:59

if you're just changing one function, you can just rename that function

theeternalpulse20:04:27

true, and with copying the code-base it wouldn't be awkward

theeternalpulse20:04:53

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.

theeternalpulse20:04:05

to make it available to any version

theeternalpulse20:04:16

or once you make another version, you only add to that

Alex Miller (Clojure team)20:04:39

I'd say that's at the discretion of the lib owner and what they want to support

theeternalpulse20:04:07

for spec, are all new additions only to spec2?

theeternalpulse20:04:25

sorry for grilling you, I think that's my last q

Alex Miller (Clojure team)20:04:55

at the moment, we are only working on spec2, not currently planning on going back to do anything on spec 1

Alex Miller (Clojure team)20:04:41

we may end up renaming everything again before spec 2 is "released" to a non-alpha ns

Alex Miller (Clojure team)20:04:21

there are enough things still to do that that transition is not something I'm worried about right now

Alex Miller (Clojure team)20:04:46

kind of depends how it aligns with clojure releases too

Alex Miller (Clojure team)20:04:49

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

theeternalpulse20:04:02

I see, I figured most things I recently discover have been discovered long before I started programming 🙂

seancorfield20:04:03

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 🙂

seancorfield21:04:11

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.

theeternalpulse21:04:38

I like that, that's kind of what I was thinking, separate breaking changes from additions, merge along the way.

seancorfield21:04:36

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.

Lennart Buit21:04:59

what an annoying problem to solve, versions and breakage… there never seems to be a silver bullet

seancorfield21:04:57

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...

💯 8
theeternalpulse21:04:00

true, I do think the ns versioning is pretty easy to do, even without formlization

dpsutton21:04:13

you haven't made a decision about contrib or not?

theeternalpulse21:04:17

as long as you have a ns mechanism it should be easy to implement.

hiredman21:04:38

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

dpsutton21:04:04

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

hiredman21:04:59

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

seancorfield21:04:06

@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.

dpsutton21:04:59

i mean when you choose contrib or not

dpsutton21:04:41

i'm sure the code will be thoughtful and deliberate

seancorfield21:04:13

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.

Lennart Buit21:04:32

on dutch clojure days, Bozhidar Batsov talked about why nrepl was moved out of contrib so you (@dpsutton) may be interested in that!

Lennart Buit21:04:02

(video not yet there tho)

seancorfield21:04:04

Yeah, I've heard Bozhidar complain about Contrib on many occasions 🙂

Lennart Buit21:04:02

yeah, not saying that he was right or wrong, just putting it out there ^^!

dpsutton21:04:14

yeah i want to see someone's case for contrib. As I don't see too many arguments in that direction

seancorfield22:04:12

Contrib pros: existing, proven CI/build/test infrastructure; "authority" of Maven and org.clojure group; visibility through autodoc and http://clojure.github.io docs.

dpsutton03:04:12

i read these earlier and now again and meant to thank you for your thoughts, @U04V70XH6

richiardiandrea03:04:02

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

seancorfield04:04:09

@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?)

richiardiandrea05:04:12

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?

seancorfield05:04:21

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 🙂

seancorfield05:04:16

Perhaps we need to periodically re-announce these things? 🙂

richiardiandrea05:04:04

Yeah maybe that's it? I like the idea