Live data from Hacker News

All my new code will be closed-source from now on

twitter.com

91–100 of 118 posts

Re: All my new code will be closed-source from now on

#91
post #35

Earlier quoted context omitted.

Whether you think it possible or not, this take misunderstands Marxism at a fundamental level. For Marxists, automation is a good thing - in fact it is a core precondition of socialism. Marx spent half the first chapter of the Communist Manifesto fanboying over capitalism for the productivity increases brought by capitalism. So why do you think it was to the chagrin of Marxists? Marx spent decades cheering on the adv…

Fair enough: the Chinese Marxists seem to love their robots, a lot. But, also, they handle all that automation to the capitalists. Because capitalists are simply much better at doing it. So it seems that, even when it succeeds, socialism can't really get rid of "the system", after all.

The CCP isn't Marxist and doesn't claim to be.

Deng basically copied parts of Lenins "New Economic Policy" of "limited capitalism" because he like Lenin realised they'd made a mistake in preempting dismantling of the market, in direct contradiction of the Marxist view that a socialist revolution requires a well developed capitalist economy, and Marx explicit warning against attempting socialism too soon. That's what I pointed to with the reference to the German Ideology. Because of course taking out profit enough to do meaningful redistribution will harm growth. That's not a "gotcha" - it's an inherent, core assumption of Marxist thinking that socialism only becomes possible because of capitalism.

Re: All my new code will be closed-source from now on

#92

Earlier quoted context omitted.

Curious your thoughts on how we got here, with git being the dominant VCS. You do know how git rose to fame? Who wrote it? Why it was adopted? It came from a need. So what needs do we have that you solve? I agree GitHub is evil. There’s GitLab, gitea, codeberg… self hosting, ssh like its old school git, you have other options.

Line and column. There's 50 years of tech debt in lines and columns which can be traced back through git to patch and then to TTY and to actual typewriters on which you had to feed the paper a line and return the carriage. Line and column are how you break down (and address into) code when code is written on a simulation of a stack of punchcards

Interesting, because one of git's philosophies is to not try to be clever about that (in reaction to a general trend in version control at the time of trying to make diffing and merging more clever: Linus felt this just tended to make the breakage less obvious).

Re: All my new code will be closed-source from now on

#93
post #92

Earlier quoted context omitted.

Line and column. There's 50 years of tech debt in lines and columns which can be traced back through git to patch and then to TTY and to actual typewriters on which you had to feed the paper a line and return the carriage. Line and column are how you break down (and address into) code when code is written on a simulation of a stack of punchcards

Interesting, because one of git's philosophies is to not try to be clever about that (in reaction to a general trend in version control at the time of trying to make diffing and merging more clever: Linus felt this just tended to make the breakage less obvious).

I respect the hell of those philosophies because of how far Linux and git have made it, which they've done by winning people over with good, solid choices. I would hope I'd be a good enough engineer to make the same choices if I saw the same things Linus saw 20 years ago. But it's 20 years later and I'm looking at the next 20 years and I see a different landscape and it causes me to have a different outlook. I think code literacy is a hugely important right now as a battle is fought over whether people will own their technology.

If many people are literate in code, the likelihood is far greater that they will own the tech and it will be open source and built according to principles that make software accountable to them. If most people are illiterate in code, they will become subjects to proprietary technology forced to use products which they have no control over.

The problem is that code literacy hasn't moved beyond the era where developers are people who own a physical keyboard and a full-size computer monitor, use a filesystem regularly, and are able to install and run native applications on their laptop or desktop. But here you've got the next generation of programmers who need to become literate in code (so that they won't become subservient to it) and for many all they have are touchscreens: phones and tablets. Maybe they're on a shared device where they can't or don't want to install software. They might not know what a filesystem or x86 machine code is. That's why I'm on mission to make code literacy and the ability to contribute to open source a matter as simple as having a screen and a browser.

Re: All my new code will be closed-source from now on

#94
post #92

Earlier quoted context omitted.

Line and column. There's 50 years of tech debt in lines and columns which can be traced back through git to patch and then to TTY and to actual typewriters on which you had to feed the paper a line and return the carriage. Line and column are how you break down (and address into) code when code is written on a simulation of a stack of punchcards

Interesting, because one of git's philosophies is to not try to be clever about that (in reaction to a general trend in version control at the time of trying to make diffing and merging more clever: Linus felt this just tended to make the breakage less obvious).

To reply more directly to the difference in philosophy around merging diffs, I think the git philosophy on preferring to expose potential conflicts rather than glossing over them is basically exactly right, because it creates a system to resolve ambiguity by capturing user intent. If I have any complaint it's that some types of ambiguities are not captured because they are not the result of textually overlapping changes. The canonical example would be a scenario where one developer renames a function and another adds a new usage of it. Git can see no text conflict and so it glosses over the semantic problem. A semantic system would be able to expose not only all the potential conflicts/ambiguities that git can see, but also some that it cannot. And in the case of an add/rename conflict the system should just handle it because the semantic intent of each change was recorded in the system: not "change these 8 call sites" but "change every site that calls this function."

Re: All my new code will be closed-source from now on

#95

I've never thought of open source as something you can make money on directly. It's hard to see how it benefits an IC economically, besides getting some recognition and a sense of pride. Open source has always felt explicitly like a benefit for companies. - They get free code, buy vs build is irrelevant when you can just pip install. - Systems become largely homogenized, thus contributors are replaceable. - They get…

> when you can just pip install.

To add: This is okay in early organizations. In larger organizations, the risk of malicious code entering your systems is much greater. So I think FOSS benefits small companies more than large companies, which seems good.

Re: All my new code will be closed-source from now on

#96
post #92

Earlier quoted context omitted.

Interesting, because one of git's philosophies is to not try to be clever about that (in reaction to a general trend in version control at the time of trying to make diffing and merging more clever: Linus felt this just tended to make the breakage less obvious).

To reply more directly to the difference in philosophy around merging diffs, I think the git philosophy on preferring to expose potential conflicts rather than glossing over them is basically exactly right, because it creates a system to resolve ambiguity by capturing user intent. If I have any complaint it's that some types of ambiguities are not captured because they are not the result of textually overlapping chan…

I suppose this canonical example would be papered over easily with minimal test coverage.

Re: All my new code will be closed-source from now on

#97

I don't mean to trivialize the OP's experience. This is definitely a very important matter and serious issue in the industry. So forgive me for raising a much smaller, side point. > I've contributed millions of lines of carefully written OSS code over the past decade I have never tracked my own output, but I would be surprised if I have written even a single million lines of code, let alone several. Out of curiosity,…

Might be true, might not be true. Don't make the mistake of comparing lines of code with quality and usefulness of programs. I'm not saying you do, but don't even entertain that thought. ;)

Re: All my new code will be closed-source from now on

#98

Earlier quoted context omitted.

To reply more directly to the difference in philosophy around merging diffs, I think the git philosophy on preferring to expose potential conflicts rather than glossing over them is basically exactly right, because it creates a system to resolve ambiguity by capturing user intent. If I have any complaint it's that some types of ambiguities are not captured because they are not the result of textually overlapping chan…

I suppose this canonical example would be papered over easily with minimal test coverage.

Yeah it can be, but you'd really prefer to know without having to go do an exhaustive search I think. The closer to the root cause you catch the problem the easier it will be to tell what happened. Plus, it's not always easy to run exactly the right tests and to run them at exactly the moment they're needed. I usually won't run the whole test suite on each commit if I'm just doing a rebase, say, but it would still be nice if I didn't sail past a problem that I would later have to retrace my steps to fix.

Re: All my new code will be closed-source from now on

#99

Earlier quoted context omitted.

I suppose this canonical example would be papered over easily with minimal test coverage.

Yeah it can be, but you'd really prefer to know without having to go do an exhaustive search I think. The closer to the root cause you catch the problem the easier it will be to tell what happened. Plus, it's not always easy to run exactly the right tests and to run them at exactly the moment they're needed. I usually won't run the whole test suite on each commit if I'm just doing a rebase, say, but it would still be…

The amount of code changes as seen in a git diff is roughly close to the amount of text changes. So reviewing is scaled linear with the change. In the way your are diffing are there any confounding changes? i.e. I make what seems like a small textual diff but it realigns the whole model of the code base that causes your diff to look like a big chunk of your code base is changed? Maybe that's a good thing? Just thinking out loud, I can't say I have an understanding about what your methodology is.

Re: All my new code will be closed-source from now on

#100

Earlier quoted context omitted.

The problem is that’s ai is monetizing your code And not giving you anything

So? If some other riser used my code to make money sould I be upset? Isn't it the whole point to me useful to others?

Some AI companies have jobs where human coders solve algo problems for model training.

Why not apply directly to those jobs and doing it for free? That would maximize your usefulness to others, would it not?

I'm actually asking, that's not a rhetoric question.

Post reply on HN