Hacker Newsnew | past | comments | ask | show | jobs | submit | Antibabelic's commentslogin

> There is only one formula for healthy and refreshing sleep: Go to sleep only when you are very tired. Not earlier. Not later. Wake up naturally without an alarm clock.

This is very easy to say when you're not suffering from insomnia and other sleep disorders.


Advice like this turns almost everybody's normal state into a disorder.

"Go to sleep only when you are very tired" is a child's approach to sleep, it's what we all want to do, and by adulthood we learn that it's counterproductive. But we still want it so much that we regularly test it and are reminded why we don't operate that way.

It reminds me of the intuitive eating folks who say, "Ignore standard diet advice, just listen to your body and feed it what it knows you need," but then when you overeat, they say, "You aren't listening properly, you aren't in tune with your body." Then if you ask, "How will I know when I'm in tune with my body and listening to it properly?" they say, "When what it asks for matches standard diet advice."


He does go on to say “this is basically impossible if you want to live in society”, but yeah the order in which the information is communicated isn’t optimal for skimming.

>> sleep only when you are very tired

This flies in the face of all sleep research done at the Stanford Health Care’s Sleep Medicine Center.

You're confusing treatment for insomnia with recommendations for general sleep hygiene.


Wake up without an alarm clock is surely beneficial regardless of when you go to sleep?

I try to explain this to my wife, my baby, and my dayjob but they refuse to listen.

I'm sure it is. It's difficult with a full time job though. Yes, in principle it can be made easier by going to bed earlier... but that's not simple either.

or have even a single obligation in the morning

"The TIOBE index measures how many Internet pages exist for a particular programming language."

For some reason I doubt this is in any way representative of the real world. Scratch, which is a teaching language for children, bigger than PHP? Which is smaller than Rust? Yeah, these are results you get when you look at the Internet, alright.


Sure that index isn't great (I think it's basically a regurgitation of Google Trends), but I don't think you're suggesting Clojure is actually a popular language are you? Which is the only point I'm trying to make (that it isn't popular).

Clojure is reasonably popular as far as programming languages go. It's not difficult to get a job as a Clojure developer, particularly in certain sectors (fintech and healthcare are the heaviest Clojure users). Of course C++, Java, C# and PHP dwarf both Clojure and Rust by several orders of magnitude.

> It's not difficult to get a job as a Clojure developer

Let's be honest and avoid painting a misleading picture. Getting a job as a software developer of any kind is genuinely difficult right now. Finding a position on a Clojure team has always been relatively harder for various reasons - and not simply because of its [in]popularity.

Clojure tends to attract older, more experienced developers. If you want a full-time Clojure role but have no prior experience with it, you'll often need to accept a junior-level salary - something many seasoned developers can't afford or simply won't do.

Junior developers have it even harder. Recruiting pipelines don't really distinguish between experience levels - everyone goes through roughly the same process, and juniors are expected to keep up with veterans, with almost no room for error.

Senior, battle-tested Clojure devs face a different kind of pressure. Interviews are frequently grueling, mentally exhausting sessions comparable to architect-level evaluations in other places. And because Clojure enables small, skilled teams to accomplish a lot, companies rarely need to hire in bulk - so competition for each opening is fierce.

This creates a frustrating situation for everyone, companies included. They want top-tier talent but offer junior salaries, while simultaneously rejecting juniors and anyone without direct Clojure experience. Supply and demand are badly out of balance.

That breeds resentment - "why bother learning it if I'll never get hired?" Honestly, there's no clean answer, and Rust seems to be in a similar spot right now. Even so, the language is worth learning. It has real practical value, even when you're not using it on a team. The future-proof choice I believe is to learn both - Rust and Clojure. Exploring both of these languages, I can honestly think things will change in their favor. Unless you want to stay sad at nearly-burnout levels for the next decade or more with TS/Python/Java/etc.


The JVM is one of the major selling points of Clojure. You can "write once, run anywhere" and benefit from Java's massive ecosystem, all without having to use a Blub language. Modern JVM implementations are also incredibly fast, often comparable in performance to C++ and Go.

i don't think you're wrong necessarily...but rust, golang, zig, mojo, etc are gaining popularity and imo they wouldn't be if they were JVM languages.

Scala and Clojure were smart to ride the JVM early on. Babashka and Jank are Clojure breaking out of the JVM.

It's almost as if different tools exist for solving different problems. Clojure is "Lisp on the JVM". That's the core premise behind the language. Rust is a "systems programming language with a focus on type and memory safety". This is an apples-to-oranges comparison. They offer different benefits while providing different drawbacks in return. Their ecosystems are likewise very different, in each case more closely tailored to their particular niche.

understood, i'm just pointing out that people seem to prefer the apple over the orange.

> i don't think you're wrong necessarily...but rust, golang, zig, mojo, etc are gaining popularity and imo they wouldn't be if they were JVM languages.

> understood, i'm just pointing out that people seem to prefer the apple over the orange.

This is kind of like saying that fewer people are drinking Coke every year and are choosing other beverages. It might be objectively true but it glosses over the fact that literally billions of people drink Coke daily and will continue to do so for decades to come.

The JVM is the same. Some people and organizations might be using zig or mojo (and I have absolutely nothing against zig or mojo, to be clear, I hope they succeed) but many multiple orders of magnitude more individuals and organizations run JVM stuff in a given year and will continue doing so.

At this point, the JVM is a civilizational technology. If it went away tomorrow, multiple banks would fail, entire countries would no longer be able to administer social services, millions of people would die. The JVM is in everything.

Developers on HN using zig, mojo, etc. aren't really a representative sample.


> Developers on HN using zig, mojo, etc. aren't really a representative sample.

Agree. A lot of manipulation and astroturfing goes on, from many different groups, that affects what appears to be popular on a particular site. The bubbles formed at a site can become self-reinforcing.

The more time one spends at a particular site, the more likely to fall for the illusion or become to believe that what is being presented, is representative of everyone or everywhere else. Kind of like if a person only watches Fox News or PBS News.


A programming language is not the compiler. A programming language is, in fact, not software.


Trying to define what a programming language is, is a lost cause anyway :)


> It was the last time that a Japanese company made a fundamentally Japanese move.

What do you mean by this?


It's certainly an extremely bizarre and false statement. Curious what he meant as well.


There is no "lack of understanding" here. The people responsible for these interfaces understand consent perfectly well, they just don't care for it.





Is there any way to see the whole conversion, and not one specific reply in the middle of it?



LLMs are next token predictors. Their core functionality boils down to simply adding more stuff.


Here's an SBCL coroutines talk at the European Lisp Symposium from 2024: https://www.youtube.com/watch?v=S2nVKfYJykw


Yeah, so I believe that this proposal kind of petered out at proof of concept phase but the author of the one being discussed references it.


it came up in the SBCL mailing list as well, and its author has been commenting there as well. seems like it has some legs! would be a very nice feature to have.


So like Harold T. Martin who took 50 terabytes of data from the NSA because he was a data hoarder and was sentenced to nine years in prison?

https://en.wikipedia.org/wiki/Harold_T._Martin


> "Martin reportedly stole the information simply by walking out of his various secure workplaces with it in his possession"

"secure" eh?


"Secure" workplaces means that you have to have the appropriate clearances and background checks to be allowed in and out. I'm sure there are more secure workplaces, but the security of your average SCIF largely depends on the people allowed inside of it not being bad actors.

Outside of strip searches upon arrival and leaving I'm not sure how you could eliminate that risk.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: