I miss the text only reading era. This is a blog and should not need to have JavaScript enabled to render text to a page. I would rather not have to be annoyed by flavor of the month duplicate scroll bars, cookie banners, newsletter pop-ups 5 seconds in, scroll to the top pop-ups, idle overlays, highlight helper bars that break copy paste, etc. This blog didn't have all of those but had some. I'm sure the metrics look great because I had to load this page four times. First initially, and then disabling JavaScript and realizing it doesn't load anything at all. A third time re-enabling JavaScript and then deleting all the annoying elements, and then a fourth time to make sure my cosmetic filter is applied correctly. 4x the interactions! Must be doing something right.
I appreciate the sentiment, but this remark is far too common here. It does not address the content of the post and could apply to any submission from LessWrong. The author of the post has made none of those technical choices.
You are not alone! There is in fact a whole dedicated rule about this on hn:
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Clearly doesn't really move the needle much but sometimes it helps to tap the sign at people.
Charitably, we are all on our own timelines of getting to HTML zen, and its hard not to shout from the rooftops when it clicks for you and you have your plain text RSS setup on Gnus all chugging along nicely.
Funny, I assumed it was a subtle critique of how change always elicits haters. Though now I realize it was an honest non-sequiter to complain about his pet issue?
Agreed. When I redid my portfolio site recently, I specifically sought out a static site generator that wouldn't require JS, and picked a basic no-frills prebuilt theme. But I found out the theme didn't handle disabled JS gracefully.
The fussiest part of the whole site setup was getting light/dark mode to work in what I thought was the most obvious way. To me, if a website has light and dark modes, it should default the user's device's preferred color scheme, and as an added bonus for users with JS enabled, you might also have a toggle button. But by default, the theme just started in light mode no matter what until you clicked the toggle button, and they also didn't bother to make the button hidden if JS is disabled.
Same with the button for the built-in search feature; it would be visible even if it couldn't work. It's not that it was terribly hard to modify the theme and fix this – add `class="nojs"` to the body HTML, add a JS one-liner to remove nojs, and add a CSS rule to hide the buttons if they're inside `body.nojs`. It was just disheartening to see that this was the theme's default. Anyone making a website these days has to make extra effort to support what should be considered normal browser behavior.
A benefit to using the currying style is that you can do work in the intermediate steps and use that later. It is not simply a 'cool' way to define functions. Imagine a logging framework:
After each partial application step you can do more and more work narrowing the scope of what you return from subsequent functions.
;; Preprocessing the configuration is possible
;; Imagine all logging is turned off, now you can return a noop
(partial log conf)
;; You can look up the identifier in the configuration to determine what the logger function should look like
(partial log conf id)
;; You could return a noop function if the level is not enabled for the particular id
(partial log config id level)
;; Pre-parsing the format string is now possible
(partial log conf id level "%time - %id")
In many codebases I've seen a large amount of code is literally just to emulate this process with multiple classes, where you're performing work and then caching it somewhere. In simpler cases you can consolidate all of that in a function call and use partial application. Without some heroic work by the compiler you simply cannot do that in an imperative style.
I asked gemini a few months ago if getopt shifts the argument list. It replied 'no, ...' with some detail and then asked at the end if I would like a code example. I replied simply 'yes'. It thought I was disagreeing with its original response and reiterated in BOLD that 'NO, the command getopt does not shift the argument list'.
Gemini by default will produce a bunch of fluff / junk towards the very end of its response text, and usually have a follow-up question for the user.
I usually skip reading that part altogether. I wonder if most users do, and the model's training set ended up with examples where it wouldn't pay attention to those tail ends
Google had a feature in gmail for a long time that automatically sorts your email into categories like Promotions, Social, Updates, Forums, etc. It was automated and fairly effective imo. If you try to disable the 'smart' features they will then disable this categorization retroactively and dump thousands of emails in your inbox and then nag you about turning it back on.
Did the article intentionally start with a LLM cliche to filter out all the people who hate reading obviously generated content? I would say it worked.
I have been attempting to write a lot more with AI, but it's so gimmicky. It's always spitting lines like this: " it's not just about x – it's about y." like in this post. I find it so frustrating that no matter the prompt I throw at it, it eventually repeats itself again after some time. Good technical and succinct writing is almost impossible to iterate on with AI for me.
I like how my eyes went over the first sentence, barely parsing it and already discarding the information, because its obviously ai generated. Its like the circumstances we live in added a new layer of perception to my brain to guard itself against the flood of useless information!
It isn't AI generated it is just plain a vacuous cliche. Seriously what is with people who think 'they can always tell it is AI' when really AI is living rent free in their head and they fixate on anything they don't like and are oh so convinced it must be the AI they hate. They're exactly like Fundamentalists and the devil. Or Communists and how they think capitalism literally intentionally created everything as harmful as possible just to spite them.
I really hope it's intentional. The author is a smart, accomplished person. He even published books. It's sad if this kind of person thinks it's okay to just outsource their writing to AI.
Right, if there's no legal weight to any of their statements then they mean almost nothing. It's a very weak signal and just feels like marketing. All digital goods can and will be made worse over time if it benefits the company.
If I made a new, not-AI tool called 'correct answer provider' which provided definitive, incorrect answers to things you'd call it bad software. But because it is AI we're going to blame the user for not second guessing the answers or holding it wrong ie. bad prompting.
This feels like a case of guessing at something you could know. There are two types of allocations that each have a size and free method. The free method is polymorphic over the allocations type. Instead of using a tag to know absolutely which type an object it is you guess based on some other factor, in this case a size invariant which was violated. It also doesn't seem like this invariant was ever codified otherwise the first time a large alloc was modified to a standard size it would've blown up. It's worth asking yourself if your distinguishing factor is the best you can use or perhaps there is a better test. Maybe in this case a tag would've been too expensive.
Do you envision the development to track clojure as much as is possible, similar to how cljs was conceived to be clojure in js and not just clojure-ish js, or do you think you'll eventually diverge? I made a language a while ago that was like 90% clojure but hesitated to call it that because I didn't want there to be an expectation that the same code would run as-is in both languages. Seems like from the landing page you're going for more of a drop in replacement. Look cool, good luck!
jank is Clojure and will track upstream Clojure development. I'm working closely with the Clojure team and other dialect devs to ensure this remains the case. I am leading a cross-dialect clojure-test-suite to help ensure parity across all dialects: https://github.com/jank-lang/clojure-test-suite We have support or work ongoing for Clojure JVM, ClojureScript, Clojure CLR, babashka, Basilisp, and jank.
With that said, jank will do some trail blazing down other paths (see my other comments here about Carp), but they will be optional modes which people can enable which are specific to jank. Clojure compatibility will remain constant.
reply