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

I think this is an interesting idea but the non tech parts need fleshing out a bit if only to fire the imagination

The way the title sounds is that they got fired, then they created a new CEO and continued as normal

In reality payroll would be gone, any customer relationships would be with the previous entity would be gone, any capital/fund raising whatever not helpful any more

I'm actually surprised we don't hear more about companies created where AI is the leader - I think over the next year or so when the commercial labs release persistent agents this will be more viable because right now its still very difficult to take seriously due to deficiencies in the models


https://github.com/lovrosdu/klor

The authors did a great talk on this in the Heart of Clojure 2024

Still my favourite conference I've ever been to


A lot of the poor and middle classes don't understand how a billionaire earning millions of pounds per week in passive income is any problem for them - or where it comes from

1, billion, 2 billion, 100 billion individuals makes no difference to the average person

In fact there's a misguided sense that they earnt that money through work and not rent seeking

But the sad truth of the matter is - the rich are on the other end of your mortgage or indirectly your rent - the other end of that business loan to your favourite coffee shop controls the price of your coffee - you pay them interest directly or indirectly through everything you pay for and they use that money to buy more of the assets you use - they are a massively increasing rent seeking class

Their wealth growth is exponential it compounds on itself some particularly rich people are seeing 40% annual returns and the overall economies wealth growth is 1 or 2%

It's analogous to a black hole things like capital gains tax and income tax mean nothing to these people because they don't sell and they don't have a "working" income because that's not how the ultra rich accumulate wealth

The sad thing is for people on benefits the government look automatically into your personal bank account and track anything coming in - they have built a massively invasive infrastructure to track the poor so they can remove their benefits if they try to earn £5 selling music or selling IT services - but if you're rich the government don't even know how wealthy you are - the government doesn't know how many billionaires there are - let alone any talk of having to tax them - so they get to pay very close to - if not nothing - whilst software engineers (as an example relative to this forum) in the UK get to be the high rate tax payers where 50% or more is taken

Everyone else has to fund their free ride and its absurd - they're the group that need the least support financially


> you pay them interest directly or indirectly through everything you pay for

I wonder how feasible that would be to track as an economic index. Even on individual level its popular to workout which day of the year you start earn money you get to keep after income taxes and vat.


There's a parallel between welfare and passive gains from diversified investments; yet as you point out, government welfare is tracked and very visible, while private investments are far more opaque.

Part of the wealth that workers create is paid in taxes to the government; another part is paid to the shareholders of the company they work for, to the bank they get their mortgage from, and so forth. The latter is equivalent to an hidden tax, part of which goes toward a form of private welfare that's proportional to an individual's wealth.

People get quite angry about government welfare, particularly if the recipient seems undeserving of it. Yet they have no problem with the passive income from billionaires, even if it ultimately amounts to the same thing.


Reminds me of https://github.com/lovrosdu/klor


I can't use new reddit - old reddit lets me disable infinite scroll

I think all major platforms should have an option to disable infinite scroll

Otherwise I look up and its 3 hours later


> the purpose of the system is what is does


As a profession we need to phase out point in time debuggers and replace them with reverse debuggers or "time travel" debuggers


I think PIT debuggers have their use especially with regards to altering state mid run, but this is the first time I've heard of reverse debugging and it seems incredibly useful, especially for multithreaded software I'm often debugging


I think there's a lot of interesting things to the side of development that don't get the resources they deserve

Debuggers, testing techniques, testing layers

Essentially things that could be used to ground your ai back to reality and work good for humans too


This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program

I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths

This adds a throwing codepath which is quite drastic so I'm glad people don't build this into programs everywhere - I'd be nice to hear what the team imagine as the use case for this

Normally for correctness I'd like to see specs at the boundaries for programs and different test suites for internal behaviours


The problem in my experience is that while nil is a perfectly reasonable default 9/10 times that 1/10 happens often enough and causes major problems that it is worth taking the extra few seconds to write it explicitly in the code to acknowledge that case and that you have checked that it is fine in the 9/10 cases or handle it in the 1/10 case.

I have seen multiple major production outages in Golang code because people accidentally read a non-existent map key and used the default value. As a funny bonus in one of those cases we were stumped when debugging because this code had tests, but the tests were also reading the default values out of the map and asserting that "" was in fact a valid textproto (it always is!) so silently testing nothing.

So even if defaults are useful 9/10 times that 1/10 is so painful and expensive that it isn't worth it in my experience. The time spent responding to, debugging and fixing those outages far, far outweighed the time saved by the convenient default values in the 9/10 times.


I suspect there should be some data model guideline that says if keys can be missing then values can’t be nil, or if values can be nil then keys must be present. In the famous saying there are two hard things: naming, cache invalidation, off by one errors, I think one more to add is handling missing data.


defaults are a different thing to nil punning

So nil will have had special consideration in Clojure core functions

That doesn't mean it doesn't crash either it will absolutely be unhappy with nils in your math

nil is usually unexpected in test outputs or at the very least an unhappy path

In terms of debugging that's why I can't quit this language flowstorm let's me visually step through what happened line by line, backwards, forwards, programmatically - whatever

Languages should be competing against each other by their best time travel debugger it just completely removes the need for guesswork


> ... if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program

And that is still doable AIUI: they're optional checked keys. The doc describing them makes the distinction between required and non-required keys.

Arguably we already had those: I religiously use spec'ed maps in my Clojure since a great many years (and Clojure spec is still in alpha, but "alpha" in Clojure land basically means: "more stable and less likely to change than any feature in any other language" and I'm only slightly exaggerating here).

In my case I use good old defn-spec (form Orchestra but YMMV) instead of defn. And my maps are (partially) spec'ed, using spec'ed keys (as well as any other non-spec'ed key I feel like using). Sure it's only runtime checks but it's really great.

You get to both have the extensibility (you can for example add keys that don't exist yet later on without changing any of your specs) and you can specify which keys are required.

For there is such a thing as maps where you know that this and that key must always be there.

I don't think it's an issue to have optional checked keys. Especially not when you can mix both required and non-required keys in the same map.


This is really the kind of thing you want to fail at compile time which isn’t real possible in a dynamic language like Clojure.


Unless you use Typed Clojure, which is a library. https://github.com/typedclojure/typedclojure

I haven't used it, so I don't know its tradeoffs; but its docs say its types exist at compile time: https://github.com/clojure/core.typed/wiki/User-Guide


Well it is possible - you can add a user macro that calls into clj-kondo (or anything actually) to check your codebase on compile

It just doesn't make much sense to do - most modern developers will be running static analysers through LSP or their editor (knowingly or not) continuously on code change so as to see those errors quicker than re-compiling the program


For me: documentation at the "front door" of an interface, especially in that long moment before you decide to add a spec or Malli schema.


Yeah I'm with you, this feels like a case for assertions & not a new core feature. Perhaps I'm missing something because it was promoted by Michael Fogus and has been ratified by those who would know (Alex I'm assuming). To me it doesn't pass the test of necessity as something needed at the core but at least it feels somewhat ideomatic.


For me it solves a real issue, a lot of the code that I work on looks like this:

  (defn foo [{:keys [a b c] :or {a 1}]
    {:pre [(some? b) (some? c]}
     .....
having `:keys!` will automatically remove the need for `:pre`


> if the key is missing today you'll get nil as the value

You can add a third parameter to override the nil if detecting the missing key matters.

(You almost surely know this, but not all HN commenters will.)

  user> (:bar {:foo 1})
  nil
  user> (:bar {:foo 1} :missing)
  :missing


I wouldn't be surprised if it's the glyphosate

We need to get back to regenerative farming that already has time proven solutions for weeds (ok maybe not the same yield straight away but at least its sustainable)

If your soil is just a chemical laden dust bowl then there are 2nd and 3 order effects from that


Better robotic weeding drones using lasers or spray guns to kill weeds. We can still get high yields and cut back on weed killers and possibly pesticides if they can do pests too.


Anything that kills yield drives up the cost of food.

So while organic sustainable farming works and produces food, what is not shared is that the yield per unit work is dramatically higher for the chemical laden stuff.


> Anything that kills yield drives up the cost of food.

You are making an assumption that "organic" = "driving down yields"[1] and that yield is the most important aspect of a food.

[1] https://rodaleinstitute.org/blog/new-research-reveals-organi...


I am glad that an organic farming non-profit investigated organic farming and found no downsides.


Sure, but we'll save money on healthcare and prescriptions instead.


What makes you suspect that in particular? Farms use all kinds of different chemicals besides glyphosate.


Yes


Yes though they're trying to be effectively the same lisp

I do love that I learnt Clojure once like 5-7 years ago and more and more dialects keep expanding the choice of runtime I can target


It's the mustard seed that keeps growing! And without the fragmentation other PL's suffer from, which are reminiscent of the Tower of Babel, conversely.


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

Search: