[devdoomari]

> ". Over email, he said, “We might be up the creek ;).” Later, when Gün pointed to the error in line 666, Daian replied, “Don’t think so.”

well, isn't the financial law against this kind of incompetence in the first place?

I don't think the thieves would be guiltier than the team behind DAO.

ps: and line 666??? who the hell keeps a single source-code file that big? no wonder bugs are around...

[__s]

> who the hell keeps a single source-code file that big

Me. SQLlite. .NET's garbage collector. CPython's eval. Lua's lexer. xinit. dwm. These are off the top of my head that I've seen

https://raw.githubusercontent.com/dotnet/coreclr/master/src/...

https://github.com/catseye/Befunge-93/blob/master/src/bef.c

https://github.com/rust-lang/rust/blob/master/src/liballoc/v...

https://github.com/oxyc/luaparse/blob/master/luaparse.js

Yep. Pretty troll comment. Felt like taking the bite today. I'm going to get back to getting my lexer past 1000 lines today: https://github.com/serprex/luwa/blob/master/rt/lex.wawa

[minxomat]

I think big source files have their place. Single procedure view is about the only thing I miss in today's Visual Studio (was a thing in VS6).

[tzs]

> ps: and line 666??? who the hell keeps a single source-code file that big? no wonder bugs are around...

Why would you expect there to be a relationship between source file size and bugs?

Suppose a program has 100 functions, and each function is 10 lines plus on average 4 lines of comments.

If I organize it as a single file, it will be about 1500 lines.

If I organize it as 10 files, they will each be about about 150 lines.

But when I'm actually working on the program I'll be seeing it through a window that shows the same amount regardless of whether the program is one big file or 10 smaller files.

Since I see essentially the same thing in both cases, I don't see how the bug rate will be different.

Don't get me wrong...I'm not saying it is OK to always put everything in one file. There are times when good design requires multiple files. For example if a program must use global variables and the language supports globals that can only be references within the file containing them, then organizing files around which globals functions need access to might be a good idea and help avoid bugs.

But in that case it is not the size of the files that matters. It is their data access needs.

[MereInterest]

I've seen single-file Fortran code that exceeds 15k lines of code, and I have no doubt that there exist source files orders of magnitude larger than that. Below 1000 lines, it depends on the style. If those are all a single function, then you're up a creek. If those are neatly split into many independent functions, then it can be pretty manageable.

[pjc50]

Blockchain currency advocates like to claim that the law doesn't apply to them.

Line 666 is an entertaining coincidence but that is really not that large a file for most languages.

[dmix]

> Blockchain currency advocates like to claim that the law doesn't apply to them.

Example? Or do you just mean like every financial organization ever (even beyond Wall St) that pushes back on regulatory oversight?

Attempting to regulate Ethereum with human gatekeepers sounds ridiculous to me, especially at this point, and entirely defeats the purpose of the whole system.

These people who put money into that DAO fully knew the risks of what they were doing. And none of them are calling for centralized oversight from the US gov as a result. So I'm not sure who this would be protecting or helping.

[mannykannot]

> Attempting to regulate Ethereum with human gatekeepers sounds ridiculous to me, especially at this point, and entirely defeats the purpose of the whole system.

The problem is that Ethereum cannot live up to its intended purpose, at least not the hyped, pie-in-the-sky purpose that it is being promoted with.

>These people who put money into that DAO fully knew the risks of what they were doing.

Pretty clearly, they did not - and when it went pear-shaped, they abandoned all their principles to rescue themselves from the situation they had created. They appointed themselves as agents with more powers than any statutory regulator has.

[dmix]

> and when it went pear-shaped, they abandoned all their principles to rescue themselves

How exactly?

By rolling back the primitive marketplace that had almost zero repercussion because the marketplace was barely beyond the first users?

I didn't see anyone calling for solutions that went outside of the control of Ethereum. To fit into your snide analysis they would have turned to state authorities for help or called for other real centralized systems of control. But that didn't happen. As far as I can tell there was zero control relinquished to central bodies as a result and it would be almost impossible for them to take the same approach now that the market is maturing. So the original decentralized concept still underpins the technology as it ever did.

Comparing the early alpha days of the system to the stated ideals of what they want the system to be in the future in not fair.

If every experimental project followed your advice by being totally risk adverse as well as was carefully controlled with red tape from the early days then we wouldnt have any innovation or the great products we have today. Just look at Japan's market, feeding off industry from the last time they allowed markets to operate freely in the 1980s, if you need proof of this.

This idea that you see nothing wrong with believing you know better than people who volunteered their time and money with this project and they need to be protected by government systems is what concerns me. Why not let them run this project and see if it fails or not? Is it really worth killing this experiment to mitigate risk so a few people don't get burned?

I personally think this project is full of snake oily hand wavy ideas that will mostly fail. But I'll endless defend their right to try it. And provide feedback and thoughtful analysis to poke holes in the bad stuff as I come across it.

[mannykannot]

>> and when it went pear-shaped, they abandoned all their principles to rescue themselves.

>How exactly?

If I am not mistaken, the central principle of Ethereum, from which almost all of its alleged benefits arise, is that the blockchain is the sole authority and so the currency, contracts and transactions are consequently immune to meddling. Of course, one might argue that it was never true, and that all the hard fork did was to demonstrate that fact, but truth is not a necessary feature of a principle - though false principles usually turn out to be unworkable in the long run; see, for example, communism.

Your argument seems to be that the hard fork was feasible, expedient and harmless, but that is not an argument against it being a breach of their own principles. Furthermore, if you followed all the arguing at the time over whether there should be a hard fork, you would know that there are plenty of people who thought it was a terrible idea - so much so that some of them have gone to the considerable trouble of keeping Ethereum Classic running.

>Comparing the early alpha days of the system to the stated ideals of what they want the system to be in the future in not fair.

It is certainly fair to point out that they are unjustifiably claiming that it is, now, what they want it to be in the future. Furthermore, I don't recall it being described as alpha software when people were putting hundreds of millions of dollars worth of assets into the DAO.

> If every experimental project followed your advice by being totally risk adverse as well as was carefully controlled with red tape from the early days then we wouldnt have any innovation or the great products we have today.

Even if these general points were not exaggerated and simplistic, they would not refute the specific claims about the current state of Ethereum. Furthermore, you seem to think I am advocating the regulation of Ethereum, but I don't think that would save it from its fundamental contradictions.

> This idea that you see nothing wrong with believing you know better than people who volunteered their time and money with this project and they need to be protected by government systems is what concerns me. Why not let them run this project and see if it fails or not?

See my immediately previous response - though I would prefer it if Ethereum was promoted without claims that cannot currently be justified.

> Is it really worth killing this experiment to mitigate risk so a few people don't get burned?

That's what the opponents of the hard fork said - but the people who would have been burned without the hard fork would have included some of the most influential people in Ethereum. It would be interesting to know how much the pro-fork miners had at risk in the DAO.

> I personally think this project is full of snake oily hand wavy ideas that will mostly fail. But I'll endless defend their right to try it. And provide feedback and thoughtful analysis to poke holes in the bad stuff as I come across it.

You seem to be trying pretty hard to not notice some significant holes.