And how exactly is that going to help improve the hiring situation? It's already very inhumane and getting worse.

Are applicants just supposed to sit and roll their thumbs waiting for the right AI to have the right hallucinations?

I don't get the excitement for applying this crap to each and every aspect of our lives. What about the human experience?

Try thinking about life experiences and thoughts as a series of lottery tickets or futures contracts

If LLMs are going to get used to filter candidates out of jobs (they will, lets be real) then it is going to happen regardless of if a candidate makes a tool that explicitly provides their data in an LLM friendly format or not.

Resumes are already being run through a machine. We know what the next generation of machine looks like, so now as candidates we can put our best foot forward.

> Are applicants just supposed to sit and roll their thumbs waiting for the right AI to have the right hallucinations?

The really bright people are doing hype and bleeding edge things like this. Getting lots of notice, trending on HN (and probably LinkedIn), etc.

Everyone else? Yeah.

I don't mean this as a diss. This is just the meta. I got a really good job doing exactly this sort of thing. And it worked marvels for fundraising too.

I absolutely know not everyone has time or patience for this bullshit meta game. But networking and distribution are kind of like that.

tl;dr - If you trend on HN, LinkedIn, etc., you're already winning the hiring game.

Good for you, and him, for a while at least.

What about the world?

Being good at this bullshit doesn't imply any kind of competence in anything that matters.

The tech industry is increasingly performative.

It's nothing new. All of human life throughout time has been.

Being surrounded by people who follow every nudge and agree with everything you say never leads anywhere worth going.

This is likely worse.

That being said, I already find the (stupid) singularity to be much more entertaining than I could have imagined (grabs pop corn).

> [...] she only found that the AI was “talking to him as if he is the next messiah. [...]

This made me laugh out loud remembering this thread: [Sycophancy in GPT-4o] https://news.ycombinator.com/item?id=43840842

In The Matrix, the machines were fooling the humans and making humans believe that they're inhabiting a certain role.

Today, it is the humans who take the cybernetic AGI and make it live out a fantasy of "You are a senior marketer, prepare a 20 slide presentation on the topic of..." And then, to boost performance, we act the bully boss with prompts like "This presentation is of utmost importance and you could lose your job if you fail".

The reality is more absurd than the fantasy.

Agreed, super weird.

Did it once for a back injury as an adult, also only remember the countdown.

But my system was flushed with opiates when I woke up, so I was in a pretty good mood at least.

Could never wrap my head around the idea.

They're often framed by employers as perks: Look, we're giving you the chance to come and work overtime for free, isn't that great?

I only think this is true if the hackathon is around projects that are part of or similar to the normal work. In those cases, they should be during work hours and treated as work.

My company 15 years ago or so did a hackathon with arduinos, where they provided a bunch of arduinos and hardware and food, but the projects we made were completely unrelated to work and served no practical purpose. My team made a Simon says game.

It was just for fun, there was no benefit for the company. I think those are fine.

Yeah that would be like a “golf outing” or something for the sales team.

It’s not free, you get pizzas!

A recent boss mandated that people come on weekends. Everyone’s contract said you have to, except mine. I pointed out to the boss that even though he can ask people to work on weekends, there are laws that prevent how much (you need more and longer breaks, and you can’t do it every weekend.)

He got cold feet and cancelled the event. But he forgot to tell people. The most junior developer had spent 2+ hours on the commute.

These are not real hackathons.

They’re corporate knockoffs.

I’ve never heard of a company encouraging their employees to participate in a hackathon that they sponsored. Are you thinking of internal “hack week” periods where employees get a chance to build something “for fun” at work?

Lucky you, I've experienced several variations on that theme in my own career.

Often sold as team building and way to level up in competence/skill, with an undertone of proving your loyalty to the company.

Some people seem to like it, and be very effective using it.

The problem is it's a walled garden, with its own quirky syntax; nothing that happens inside of loop is applicable outside, and the other way around.

The main issue I have with CLs type checking is the clunky syntax and the fact that it looks different in different contexts.

I made an attempt to fix that for eli: https://github.com/codr7/eli#type-checking

I don't particularly like the syntax for the types, but I can't also think of a better way to implement it without adding a special case in the parser/compiler for it, right now with your syntax I believe, correct me if I'm wrong, it can be implemented with a macro in any Lisp

Are those compile-time type checks or runtime assertions?

Mix, similar to CL but slightly more runtime atm.

Your eli looks clunky to me.

Well, use something else.

And maybe ask yourself why you felt saying so was important to you.

    (the number (+ 35 7))

is a lot less clunky than

    (+ 35 7)@Numeric

That's your opinion, I don't agree. And the other reason is I can use the same syntax wherever I want type checking.

Opinions aside, it is objectively an increase in syntactical complexity, and many people who love lisp enjoy its relative syntactical simplicity.

Whatever is gained in exchange for this additional syntactical complexity may not be valued in the same way by everyone.

So that almost certainly explains that reaction.

One problem with Lisp is everything, including variable bindings, increases the nesting level making the code illegible. Last thing you want is for the type declaration to have their own nesting.

You'd love threading macros in Racket: https://docs.racket-lang.org/threading/index.html

It's like Unix pipes for functions:

  (~> "hello"
    (string-ref 1)
    (char->integer))

Obviously, also available in CL, in Serapeum library[1]. Racket is credited in the docstring (since it's ~> instead of ->). Also, `nest` works very well for unnesting forms[2]

[1] https://github.com/ruricolist/serapeum/blob/master/control-f...

[2] https://github.com/ruricolist/serapeum/blob/master/REFERENCE...

The nesting level doesn’t necessarily impair legibility, it depends how it’s done. Nesting levels in homoiconic & referentially transparent languages have an impact more comparable to nesting levels in yaml or json than nesting levels in a language like python or javascript. The tradeoff weighs in a completely different way.

First you will usually want to write small chunks of code, instead of a large soup.

Second, you can make intentional decisions with your use of newlines in order to highlight specific aspects of the code.

I find clojure more readable than most other languages… However, bad code stands out horribly (which is actually great if you have at least one experienced engineer in the team- I’d argue there’s nothing worse than bad code that looks normal). Just like anything else, writing good lisp takes some skill.

Your specific editor and its configuration will also have a big impact on your experience.

Aside from the points that others have raised already, this sort of deep nesting can be seen as a feature instead of as a bug, since it can force you to think about refactoring the code into being less nested.

If you hate nesting, just do this

    (defun foo (&aux bar baz)
      (setq bar (quux)
            baz (xyzzy))
      ...)

This is not necessarily true, you can pretty easily implement just about any syntax you want

The understanding of the code certainly degrades, which means any updates cause the code to lose its integrity over time.

The older code is, the more people probably have at least a passing understanding of it - just by virtue of osmosis and accidental exposure. A thorough rewrite means only the person who wrote is is familiar with it.

Of course you can start a code review policy and make sure everyone at the dev team has gone through all of the code that gets written, but that becomes a ludicrous bottleneck when the team grows

Once the code is mature and only needs sporadic updates, that's not true anymore from my experience. The story around the code is lost, people leave and the developers who make changes weren't around when the code was first written.

They don't have to do anything.

When society crumbles because nothing works anymore its going to be our problem.

Personally, I prefer writing code to reviewing code written by someone without a plan.

That’s perfect, you should start with a slop plan before getting to the slop code.

I personally find react slop to be perfectly workable.