I’d suggest looking at the ClojureBridge material. Here’s an early workshop built around learning enough Clojure to draw stuff on the screen using Quil: ClojureBridge/drawing: Experimental capstone app for ClojureBridge curriculum using Quil (github.com) but that repo has several other “beginner-friendly” curriculum outlines.
3 Likes
I used Tim Pratley’s Power Turtle with a middle schooler as an activity during 2020 quarantine and the kid liked it. Immediate gratification from the graphics and the time-tested Logo turtle worked well. Lo and behold, he didn’t care about the parens lol. I think it’s a good base to build on IMO, although the lessons trail off (they do get into fp concepts maps and stuff).
https://power-turtle.com/#lesson/1-beginner/1-welcome.md
Also had a similar training exercise derived from clojurebridge materials (one of which leveraged quil + turtle graphics) and custom curricula for adults of various background (about 4/5 non-programmers). Worked great.
3 Likes
I think the core team is talking in a ‘rude’/‘direct’ fashion, which sometime make people uncomfortable. This style is quite different from other tech communities. I don’t think core team are bad people and actually they are great, but the ‘communication style’ will never get mainstream.
Straight to the point, can talk more in depth are the good side of this style.
Most of the people get bad feeling and many topics would be dismissed from the beginning are the flip side of this style.
2 Likes
Maybe. I just think that as time went on, the issues became less technical and more about style and standards. And because there was always just one overwhelming voice, most of the ‘minnows’ that got in the way pretty much went their own way.
–
I would love it if there were a fork of the language to feature a stripped-down, easily parsable, easily portable subset of the language. ie: no reader macros, no stm, no agents, no transducers, no protocols, no :: keywords.
Basically, a standard to define an immutable lisp without all the fancier clojure features.
–
I’d love it if there was something similar to the SRFI - where features are grouped and can be optionally added by the implementer on their own platform. So that some or all of those features can then be added back in.
Then, there could be a runtime running on wasm through intermediary language like c.
There’s already a bunch of work done already with experimental clojure implementations on other platforms. What would be really great is if someone can do a survey of what’s out there, group these implementations by features and come up with this minimum subset.
–
Maybe then when a document has been drawn up, the community can convince those implementers that it’ll be worthwhile to change their code a little to conform to that standard.
I dunno. It’s a lot of work. But to me, it’d definitely be worth it if we will be able to get a optional-gc clojure that we can repl into.
And I think they’re too nice! See, you just can’t please everyone.
There’s an old story - Plato’s Symposium, some 2300 years ago - where Phaedrus holds a meeting, and everyone promises not to get too drunk (since that’s usually what they do) and discuss the nature of Eros, the God of Love. Like many things with Plato, the climax of the story is Socrates’ speech, which happened to follow Agathon’s. Agathon’s oration on Eros was full of eloquence and beautiful praise in adulation of the supremacy and power of the God of Love. Like many Gods at the time, Eros was a reflection of our own emotions, love being one of the most profound.
But when Socrates had to follow Agathon’s beautiful prose, he had to pause and ask Phaedrus permission to proceed. Normally, he said, he would speak of the truth, but after such deep praise for Eros in Agathon’s words, he was reluctant to speak of the truth about the God with such religious intonations in the air. Before getting on to his speech, Socrates squirmed and postured, admonishing Phaedrus against letting him speak and checking with everyone to make sure they didn’t mind him speaking the truth on such matters. Eventually, he agreed to proceed with his speech.
Mind you, Socrates was eventually killed for speaking the truth - for heresy against the Gods, etc, etc. But among his peers, at the symposium, even still, he postured and qualified his arguments with deference and platitudes, softening the truth with prologues on how wonderful he thought their sentiments towards the deity of love were.
For the record, I love love. But, personally, I find all the posturing loathsome and dry. All the qualifications and precautions and, “Oh, I may be wrong, but…” we know you might be wrong! We all might be, get on with what you’re saying!
We’ve come a long way since then, but IMO we’re still too careful for the sake of not offending. Take off the white gloves, put on some thicker skin, and let Socrates get to the fricken point! lol
So there’s MAL. There’s already almost a hundred reference implementations in various languages and all they’re missing, mostly, is persistent data-structures implemented in MAL. An SRFI around that, towards Clojure proper, would be neat, but that seems like a thing more appropriate in a few decades or more, IMO. I’m interested in seeing where clojure.core takes the core semantics, before solidifying it all into some permenant reference. That’s one of the benefits of Clojure over other lisps IMO. That’s why we’re not all using CL. You’ve got this dynamic core team, hyper focused on ensuring the shape of thing solves real world problems, not theoretical ones decided by a committee. Maybe in a few years or decades when they’re ready to hand it over to a “community,” that might be interesting, but personally until then I’m more excited to see where clojure.core evolves without such constraints.
2 Likes
I’m just putting it out there as to what I would like to see happening in the world of clojure as someone had asked. I would be very hesitant to tell people ‘just wait around for the core team to decide what’s best for you’ because I don’t think it’s that impactful for anyone.
I’m not talking about anything theoretical, I’m talking about looking at what’s out there already, grouping them and sorting it out by things that are were tricky to implement, things that are non-essential and things that are essential.
I listed what I thought were non-essential and hard to implement features. I’d like to see others give it a go. Clojure derivatives are happening. For example, babashka and the newest borkdude compiler - GitHub - borkdude/cherry: Experimental ClojureScript to ES6 module compiler
doesn’t support protocols. Is it clojure? I don’t know. Is it a fork? I don’t know. Would I want to use it over cljs? Absolutely.
MAL is a great starting point. It’s got a terrific test suite and a standard for implementations - but It’s not immutable by default. A list of features for an ‘immutable lisp’ gives a really good reference point if I or anyone else wanted to implement something that is more portable but still conforms to a set of generally agreed upon features.
2 Likes
I’m really curious which other tech community you’re a part of, because Clojure is some of the nicest one I’ve been in.
Some communities are just full of beginners talking to each other, which stays inconspicuous, but if you get into the "higher spheres, like near the committees or the mailing lists, be ready to be insulted.
Everyone probably has their own impression/experience, but one thing I like about Clojure personally is how inclusive and ready to help people are. In no other language do I have a free direct line of support from the core team that answers my questions in 10min or less.
I’ve seen so many people abuse that, by trying to push their own opinions, because the core team is listening, some people seem open to let them know what they believe isn’t good about Clojure and what they’d want the core team to do instead. I find that really rude. Suggestions and constructive criticism is fine, but pushing that before having established good will, a trust, or without even putting effort to bring a well thought out analysis of the options and implications, I find that rude. Other communities solve that by having a much bigger hierarchy where you simply never seem to be heard by anyone from the core team.
Clojure Core members also run what I consider the best standing Tech conference of them all: StrangeLoop, which also has a reputation for being the most inclusive, not just in people, but also in new ideas, so many cool fringe tech ideas discussed at StrangeLoop.
5 Likes
I’ve never needed to interact with the core team because there seemed to be an answer for any type of technical question on platforms like Stackoverflow. Actually, no. A long time back, I asked a core member to check out my library I had spent a bit of time on and was basically told straight up by the individual that they had no time, to go write a blog post and maybe if enough people tweeted about my blog post, they would then come back take a look. Each have their own experiences I guess.
There’s countless discord communities out there that are thriving because the lead dev/team are answering all the questions. Not 10 mins mind you, but usually pretty quick.
I don’t think forking clojure is fringe tech idea. However, I’ve seen enough of dead/zombie forks to know that there better be a damn good reason to do so.
For me, a smaller runtime with more basic features will solve a pain that I’m currently experiencing. I find that the tooling sometimes breaks down on larger sized projects. For example, on the current project I’m working on, clojure is not used a production runtime but as a build tool. There may be memory leaks due to repeated reevaluation of vars and namespaces. Sometimes macro expansion runs out of memory due to JVM byte code restrictions. This is tolerable and does not affect production code. If it gets painful enough and if I have the time, then I would definitely think more about it.
What I wrote down was how I’d go about ‘forking clojure’. That would probably be the first thing I would do as I tend to like to see what others are doing before making a decision. Finding common ground between all the clojure derivatives out there would be a pretty good start. Others might have a more straight forward approach. Either way, I should think that people interested in such things will definitely find it more productive than trying to convince others that the language is easy.
Can you give me one for a programming language? Where I’ve hung out for Rust, C++, Java, C#, JavaScript, Go, Python, Ruby, Scala, Haskell, Kotlin, I never saw a core member available to answer questions/issues directly and have a back and forth conversation about it in chat.
To me that kind of access is a big plus, so I’d be interested in a language that had that, granted the language is already production ready and stable.
I don’t see much value in a fork personally, or the subset of Clojure you describe. At least for myself and my use of the language.
check out vlang and raylib discords.
even the elusive mike pall who maintains luajit is pretty reachable via github. i’ve always managed to get to a few redis folks. julia is also pretty friendly. so is guile.
most blockchain projects are relatively good. For a clj flavored project try convex lisp with michael, the author of the clj matrix library.
1 Like
Well, I don’t think it’s very hard to convince people that Clojure is easy, comparatively speaking.
But have at it, for sure. It’d probably be fun. Have you heard about Jank?
Where jank differs from Clojure is that its host is C++ on top of an LLVM-based JIT.
Not sure what the GC story is going to be there yet, but seems interesting.
I know of GitHub - Zelex/jo_clojure: Fast Embeddable Clojure in C/C++, not jank.
I’d say non of them will take off - mostly because the ecosystem will be starting from scratch. If I want an LLVM based language, I’d probably look for an existing one - for example Julia, copy an immutable datastructure codebase and then write a few macros to make it easier to use.
The embedded angle is probably the best one given the developments around WASM. I would consider targeting luajit byte code or looking more into DynASM API Documentation. The dude posting about Clojure should consider MoarVM as a backend is actually right in some respects. I was just calling him out because he obvious never coded in his life but the MoarVM is actually built with luajit/DynASM. So maybe that is a good target.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.