You might want to have a look at: https://orgpad.com/s/iByMMbKLBnq for a comparison of lazy seq fizzbuzz approach and some other playful ideas :-)

@U01BXSTEB2S Thanks for the pointer. I noticed two implementations of FizzBuzz, but am unable to find more. I noticed both those versions use println, which I consider to be a deeply problematic choice in Clojure FizzBuzz. https://www.evalapply.org/posts/n-ways-to-fizzbuzz-in-clojure/#le-fizzbuzz-classique attempts to illustrate the trouble with println-infused fizzbuzzes.

It just illustrates two approaches. One "traditional" and the other with lazy seqs which for many novices seems rather less intuitive. The whole OrgPage is suitable as an interactive introduction to Clojure thanks to @U0L91U7A8 and @UFHE11C83.

Aaaaah ok!!! Since it was in reply to my oddball tour through Clojureland using FizzBuzz as a device, I thought that it was some sort of deep dive into FizzBuzzery! :) --- Aside: personally, I stay away from println when introducing Clojure to novices, for reasons noted in the post above.

I ended up reading about WebMIDI in some detail and found that what I wanted to do was dead simple. You get complete access to MIDI devices and I was able to successfully send a bunch of notes from my browser console to my DAW.

Cool! Thanks.

Yeah, it was a great trip! Now I have two weeks of backlog to wade through to catch up, of course 🙂

We put 920 miles on a brand new rental car (and only did the south of England part!).

I’m also a little bit of a video game enthusiast and watched some of his lectures. I think there is quite some interesting overlap between what he says and the Clojure philosophy. There is a recent one discussing Conway’s Law and some of its implications. It then goes further and expands it with evolution of code over time. Worth a watch!

Definitely. One thought I had throughout the video was a lot of this optimization is similar to stuff I've done, in clj-fast for example. What he did was just compile it in his head. Fetching and calculating data in advance, eliding access patterns, could a smart enough rewriting inlining compiler do the same?

I don’t think a compiler typically has enough context

maybe if one would provide more meta data / annotations or something. JITs however do some really crazy things. Though I never had time to dive into this topic unfortunately.

I think something like the Haskell compiler could figure out at least everything until getting the triangles out directly

Is this the one where he talks about the map editor tool in The Witness?

specifically the grass placement algorithm and how he improved it from 10s to near real time

Ah right. Much of it was basically destroying unnecessary indirection. Ironically I think macros can be a tool for that as they are somewhat of a mini-compiler.

Exactly. But what I really want is "polymorphic" macros, sort of like the inline meta but more aggressive and flexible

polymorphic on the ability to evaluate the code

@U01EFUL1A8M are you talking about his “Killing the Walking Monster” talk? I just watched that

If you boil what he did to "prefetch, precompute, reduce dimensionality", I think I touched on it in my talk in reClojure. The code can end up less straightforward unless you just use arrays or something

have to take into account there might be a sampling bias, too. Some people really don't take to Clojure. If you don't work with the REPL, you're going to hate Clojure's guts, spit and curse. The very fact of a large code base is suspicious. What state was it in? Was it written in a large company which recruited developers by the bushel and trained them poorly, resulting in a poor experience for everyone?

> and (more importantly) organizational skills of the owners +1 Perniciously underrated and undervalued trait.

Would you be able to estimate a lower boundary of loc when introducing Polylith would be worth it?

I'd say it's worth it pretty much as soon as you have a monorepo that builds more than two distinct uberjar artifacts from a set of subprojects 🙂

Huh, then I'll never have to use it. :D

From the same page: > cowboy type astronautics Feels like a good premise for a webcomic. :D

I'm reminded of the Bjarne S. quote - "two languages - ones everyone complains about, and ones no one uses" (clojure exempted of course 😂 ) - the link was an interesting read, although personally I like how easy it is to do some data digging via SQL - I had a small project I did on my own of pulling records (API entries) from the nintendo e-shop - however, instead of worrying about how to write in code the things I wanted to check and display (best deal by sale etc.) I just imported all the API records into a sqlite3 database and wrote a couple small SQL queries to do it for me (https://github.com/ahungry/ahungry-eshop) - I don't think even clojure could express the record selection by criteria/sorting in a more concise manner

SQL is in that particular area where it's easy to do simple things, but much, much harder to do anything non-trivial. Even with a layer of e.g. HoneySQL on top. Your repo is a good showcase of that "simple things" part. But notice how you yourself had to use WHERE 1=1. :D The article I linked mentions e.g. Pandas - similar things there are just as simple. Somewhat related - % and _ in a search query in your project would lead to potentially unexpected results, but maybe it's not that important there.

hah very true 🙂 (and thanks for the heads up about the lack of useful sanitation on the params part of the query - probably not ideal) - I think what you say also applies to a lot of frameworks in other languages that do 99% of the hand-holding for you (contrasted to clojure luminus, where it's more of a pick-and-choose) - very easy to go from 0 to 60 when staying in the predefined guard-rails - but swimming upstream when you need to deviate outside those rails

Right, this analogy can definitely be made. But SQL is even worse here, because the swimming becomes upstream even within the guardrails. :) For years, I've been very conservative when it comes to SQL. This article has helped me realize that my conservatism was towards relational data and not SQL itself.

This felt cathartic. I have encountered almost every of the issues discussed at some point and then begrudgingly wrote some workaround (some of them I’m not particularly proud of). Good to read these from such an expert. And I agree, it’s such a nice tool if everything is “schoolbook” SQL. Ad-hoc queries especially. But beyond that I had my fair share of “this cannot be the way to do this” and “I wish it would allow me to pass this as a parameter” and so on.

A couple of other things: migrations (even with a nice tool) always feel much more dangerous than they should. Nesting in SQL feels much more mentally taxing (per level) than in a general purpose language. And views have more restrictions than I like.

Wow. Thanks for sharing this. I'm going to have to chew over the whole thing. > The success of GraphQL shows that these pains are real and that people really do want to issue rich queries directly from the client. Compared to SQL, GraphQL is substantially easier to implement, easier to cache, has a much smaller attack surface, has various mechanisms for compressing common patterns, makes it easy to follow foreign keys and return nested results, has first-class mechanisms for interacting with foreign code and with the outside world, has a rich type system (with union types!), and is easy to embed in other languages.. > It has a smaller attack surface sure, but that's comparaing apples to oranges right? Graphql has to be backed by an actual database language. I feel it wouldn't be hard to create a restricted interface to sql that clients could use. White list queries then validate args and all same things we do on the backend. Basically use macros to make it look like your thing m writing browser code but then put the query on the server.

> but that's comparaing apples to oranges right? No, because they are both QL - query languages. It's oranges to oranges. > Graphql has to be backed by an actual database language It has to be backed by a database. Whether interaction with the database is done via a different QL is another question. Apart from that, such an abstraction would be able to prevent common security issues with the underlying QL. > I feel it wouldn't be hard to create a restricted interface to sql that clients could use. White list queries then validate args and all same things we do on the backend. Basically use macros to make it look like your thing m writing browser code but then put the query on the server. And now you're embarking on a process of creating a new QL. :) Superficially, it seems easy. In the end, if you want to have something as expressive and useful as GraphQL or SQL, you will invariably end with something just as complex.

I should avoid metaphors. Apples and oranges have a lot in common....

Well, it's a common saying. Comparing GraphQL to REST is apples to oranges. :) But GraphQL to SQL is definitely oranges to oranges in the context of comparing query languages at large.

Ah, i see the distinction you're making. I was bundling sql with the database. I should have said postgres. I suppose i would be interested to hear why people used graphql when it wrapped only one ql+database. I was saying the browser ql would ideally be the db ql, only secured. I don't think the goal of graphql is to unify the fe and be, but to provide a uniform interface across multiple services and dbs.

I'm not sure the last part is correct.

It might be used in such scenario - just like SQL (depends on the backend)! - but it's not the goal.