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

Epicureanism is sustainable hedonism.

Sustainable and importantly ethical.

I believe the point is that price is not value.


Perhaps, but the price is the value.


As an outsider, I understand what wpietri argues, but I fail to understand yours --- even though I've read other branches of the discussion. Do you argue that wpietri's method still estimates tasks but the estimation is always around two weeks?


I keep fighting this stupid platitude [0]. By that logic, I fail to find anything malicious. Everything could be explained by incompetence, stupidity etc.

[0] https://news.ycombinator.com/item?id=46147328


> "Don't attribute to malice what can be explained by incompetence"

I don't think there's anything that cannot be explained by incompetence, so this statement is moot. If it walks like malice, quacks like malice, it's malice.


There are more than two explanations.


By all means, give us a few examples.


What does OpenDarwin or PureDarwin, independent projects, have to do with the fact that Darwin, Apple’s OS kernel, is open source?


Because they show that Darwin may be technically open source, but Apple are horrible stewards of it. It's impossible to actually build a usable operating system from it, which is probably their intent.


> the problem with waterfall wasn't the detailed spec

The detailed spec is exactly the problem with the waterfall development. The spec presumes that it is the solution, whereas Agile says “Heck, we don't even understand our problem well, let alone understanding a solution to it.”

Beginning with a detailed spec fast with an LLM already puts you into a complex solution space, which is difficult to navigate compared to a simpler solution space. Regardless of the iteration speed, waterfall is the method that puts you into a complex space. Agile is the one you begin with smaller spaces to arrive at a solution.


> whereas Agile says “Heck, we don't even understand our problem well, let alone understanding a solution to it.”

How can you even develop something if you don’t have a clear idea what you’re building?


> How can you even develop something if you don’t have a clear idea what you’re building?

But, the statement "we don't even understand our problem well" is typically correct. In most cases where new software is started, the problem isn't well-defined, amenable to off-the-shelf solutions. And you will never know as little about the problem as you do on day one. Your knowledge will only grow.

It is more useful to acknowledge this reality and develop coping strategies than to persist in denial of it. At the time that the agile manifesto was written, the failure of "big up-front design" was becoming plainly evident. You think that you know the whole spec, and then it meets reality much as the Titanic met an iceberg.

Agile does not say "no design, no idea", it points out things that are more valuable than doomed attempts at "100% complete design and all the ideas before implementation". e.g. "while there is value in (comprehensive documentation, following a plan), we value (Working software, Responding to change) more. (see https://agilemanifesto.org/ )

In other words, start by doing enough design, and then some working software to flush out the flawed thinking in the design. And then iterate with feedback.


You have am idea but typically you neither have a complete understanding nor a detailed view of the solution, and of course things tend to chanhe over time.

That's the key benefit of starting small and of iterating: it allows you to learn and to improve. You don't learn anything about your problem amd solution by writing a comprehensive design spec upfront.


I have an idea to build payments processor, how does that get me any closer to actual payments processing?


It wasn't the spec - it was the inability to change the spec.

It's the ability to _change_ quickly (or be agile) in response to feedback that marks the difference.


> There is a spec, but there is no waterfall required to work and maintain it.

The problem with waterfall is not that you have to maintain the spec, but that a spec is the wrong way to build a solution. So, it doesn't matter if the spec is written by humans or by LLMs.

I don't see the point of maintaining a spec for LLMs to use as context. They should be able to grep and understand the code itself. A simple readme or a design document, which already should exist for humans, should be enough.


> I don't see the point of maintaining a spec for LLMs to use as context. They should be able to grep and understand the code itself.

“I don’t see the point of maintaining a documentation for developers. They should be able to grep and understand the code itself”

“I don’t see the point of maintaining tests for developers. They should be able to grep and understand the code itself”

“I don’t see the point of compilers/linters for developers. They should be able to grep and find issues themselves”


The thing is that the parallels you are drawing is for things that is very explicitly not the source of the code, but exists alongside it. Code is the ultimate truth. Documentation is a more humane way to describe it. Tests are there to ensure that what is there is what we want. And linters are there to warn us of specific errors. None of these create code.

To go from spec to code requires a lot of decisions (each introducing technical debt). Automating the process remove control over those decisions and over the ultimate truth that is the code. But why can't the LLM retains the trace of the decisions so that it presents control point to alter the results. Instead, it's always a rewrite from scratch.


> “I don’t see the point of maintaining a documentation for developers. They should be able to grep and understand the code itself”

I cannot think that this comment is done in good faith, when I clearly wrote above that documentation should already exist for humans:

> A simple readme or a design document, which already should exist for humans, should be enough.


> giving away

Giving away to their own LLC, not to a non-profit [0].

[0] https://en.wikipedia.org/wiki/Chan_Zuckerberg_Initiative


That's so interesting- I'd assumed from the name that it was a charity for allocating donations, but legally it's a regular company?

Seems like its activities are mostly charity based at least.

It's a confusing thing, and I still don't really understand what 99% of wealth over the course of a lifetime actually means in real terms. Is that of lifetime wealth? 99% of Zuck's wealth from 2015 over the course of his life?


Yep. All are valid questions. I would rather have Zuckerberg donate to charitable causes than not. But this kind of bullshit indicates me that it's mainly for show.


It's ironic that you described how the 2008 financial crisis came to be to illustrate how “normal” this circularity is.


Loans have happened long before 2008 and have continued ever since.

This process is described in the Bible for example!


What does the Bible say about collecting interest on loans (the necessary part for making mortgage backed securities)


"Do not charge your brother interest on money, food, or any other type of loan. You may charge a foreigner interest, but not your brother." - Deuteronomy 23:19-20


I also like Ezekiel 18:13


I sort of would read bible passages describing modern financial instruments.

Perhaps it has some psalms discussing merits of MMT, or parables on Quantitative Easing.


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

Search: