Clojurians Log v2

Instead of making the users follow the link without knowing what it's about, could you please just copy and paste the post itself?

I think you should see the post if you have link preview enabled?

It's disabled for multiple domains, server-wide. I do have previews enabled and I don't see it for this URL.

> I’ve got a UK Filco Ninja Majestouch-2 keyboard to give away on a dāna basis — free, donations welcome. You’d just need to cover postage and packaging. UK only. Model: https://keyboardco.com/keyboard/uk-filco-ninja-majestouch-2-tenkeyless-nkr-tactile-action-keyboard.asp

My point is that it should be in the OP, to reduce indirection and inconvenience. :) A click on a thread is not that different from a click on a URL.

Since it's UK only, maybe post it in #clojure-uk instead of creating noise here?

@frank.rtf the best way is to join #hof-book and provide feedback in there. The boo

The current working title takes an academic approach which is formal and descriptive. From what I’ve read so far, I wonder if something more mythical and narrative would be a better fit…

Hi all, how is the reading going?

Thanks a lot. Yes, I even don't know why I put High, when everywhere else, I use Higher 😄

Alternative title would be something like: "Learn Higher Order Functions via Operations Research"

Hmm, "Operations Research" makes it sound like a topic I probably wouldn't be interested in. I like "Applied Higher-Order Functions".

Higher-Order Functions Applied (But that title almost gotta be used already. )

Awesome project and congrats on the rough draft! > Do you mind there is first piece of Clojure code on page 36? Do you mean to ask if that feels too early to dive into clj code, or not early enough? Also I’m assuming you mean page 15, (which is 36 physical pages into the book). I printed it out on white paper and read up until page 15. Personally, the code example didn’t feel too early. No way to know but I suspect the engagement for me might have been deeper if the first bit of sample code was introduced later, like page # 30 or so…

Hi @jiri.knesl, thank you for the book! What would be the best way for you to receive feedback?

Wow, that sounds very impressive. (and I am not the right person for that sorry). but would love to see it one day.

Happy to do that, as a former mathematician, and long-time Clojurian:grin: What's your timeline?

@thomas the current version can be downloaded here https://github.com/jiriknesl/books/blob/master/applied%20high%20order%20functions%20in%20clojure.pdf

@seancorfield Thanks a lot!!! At this moment, I think I am about 85% done, the rought writing is done. @pez is already looking into it, I have contacted an editor on Reedsy; and my former professor of operations research is advising me on how to make into a book (given he wrote a bunch). If things go right, I might be able to give you a printout on Conj.

I really think you should consider to not make it a book about Clojure. The content looks super relevant for any programmer out there. Clojure fits perfectly and I of course am not suggesting using some other language for the code.

Haha. The book is about Higher Order Functions mainly and primarily. It could be technically using some other FP language, like F#, or Haskell. But there are reasons: 1. I know Clojure better than any other FP language 2. I think Clojure is in fact ideal for operations research, it is very fast, 'symbolic' and has all the batteries included; generally, those >100 algorithms in the book are mainly just composition of HOFs that already exist in Clojure. 3. I want Clojure to grow. Like, nothing against F# or Haskell, I like those languages more than mainstream ones, but if one language should grow, it is Clojure.

Also, I have put already so much time into it, that is never going to pay off, that I just am not going to rewrite it to other programming language. 😄 😄

I of course am not suggesting using some other language for the code.

what tool did you use to write it? LateX ? or something more modern?

i'm reading through it. what kind of feedback would you want?

@thomas LateX.

@nbtheduke mainly, is the book understandable? Is maths there an issue in readability? My goal with it is to teach higher order functions more than operations research. It's just that I was looking for a bunch of algorithms where HOFs can be shown, and this field is very good for it.

just chiming in w/@pez as a rando in chat 🙂 . I don’t think there’s a need to say ‘in Clojure’ if ‘Applied Higher-Order Functions’ is the focus just b/c the examples are in the language. Lots of technical books don’t include Matlab, R, or Python or Haskell etc in the title despite unapologetically only using them (or occasional other pseudocode). I think there’s a bias to say ‘In Clojure’ b/c it’s a niche language, almost as a preemptive apology, or recognition that it might have more narrow appeal. Given influential books that even use their own specialized made up languages or DSLs, or pseudocode conventions, etc., I think it’s fine to justify the use of Clojure as the main language early on. Then use an appendix or preface/intro for getting the reader familiar enough, & maybe provide multiple language or pseudocode impl for a few examples.

@jiri.knesl amazing!

I get it! You mean, I should drop Clojure from the book title. Yep, intro to FP via Lambda Calculus also ends with something like Ocaml, but the book is not about Ocaml, nor has it in its title

cool, i'll read it with that in mind (and not copy editing mindset ("missing a space in this paragraph" etc))

In fact I would unfriend you if you changed the code to something else than Clojure, @jiri.knesl. It would be with a heavy heart, but it would have to be done. 😃

I would unfriend myself too. 😄

This looks incredible, really excited to dive into it (as an engineer with no math background but as someone who has always wanted to have a firmer theoretical grounding)

As you read it, the first thing is. Do you mind there is first piece of Clojure code on page 36?

Fantastic @jcoyle; yes, it is Page 15, but page 36 from the beginning.

Is the title of the book itself a typo? Currently it is “Applied High Order Functions in Clojure” … assuming it is meant to be “Higher”?

Heh, I mentioned that to him via DM -- it was like the first thing I saw when I opened the PDF... triggered my OCD 🙂

@seancorfield haha yeah I’m OCD about typos on book covers, which is weird because I’m actually a horrrible speller…

@jiri.knesl I agree with others^ that dropping “Clojure” from the title is an improvement. But I wonder if taking a completely different approach to the title might be worth thinking about, esp in terms of casting a wider net of potential readers.

It's familiar and pleases me aesthetically, but it's not an s-expression. It needs to be possible to manipulate in a macro.

Janet is also some prior art here (albeit dynamically typed, on the lisp-side) https://janet-lang.org/capi/wrapping.html

Thanks for the additional prior art to look at. Right now, I'm leaning either purely positional or reader macro. I'm favoring a "worse is better" design philosophy for this project, which those approaches fit.

This is over my head, but, name:type would seem to be a notation for literals, while on the other hand you might want to provide for a dynamic mechanism with the type supplied by a variable or an expression.. Even if it must boil down to a literal by the time C comes out the other end, macros (which are essentially code generators) will manipulate names and types as data. So I suppose the clunky s-expression notation is promising as a fundamental, and you could have a reader notation for literals. The backslash is under-utilized, isn't it?

Maybe we're thinking of the term literals differently. I think a literal is a readable representation of a value like 42 or "hello world". Variable names are symbols. Backslash is rarely used, perhaps because it reminds people of DOS and (again) PHP.

I should also note that while C compatibility is a goal, C is not the compilation target; LLVM IR is.

@zakwilson what about name : type (or ::) sugar for option 3?

Introducing spaces actually allows even more simplification. Any form that introduces variable names just takes a positional type argument. (defn main:int () ...) becomes (defn main int () ...) I'll have to think about that one a bit.

you could use clojure's style of (int foo)

and for coercion, you use ->int

common lisp uses the as the marker: (the integer foo)

I think chicken and shen schemes compile to c and may provide some prior art

@zakwilson one hunch I have is think about how you are going to do casting, then maybe there is one way to do both declaration and casting in one syntax. Just an idea, I may be wrong depending on how your lang works.

Currently, there's a cast special form. I'm inclined to eventually have a feature where a type in the call position is used for casts that should be safe and there's something more annoying to type like unsafe/cast for bare casts.

Have you looked at pre-Scheme?