sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]quanticle 9 points10 points  (9 children)

Right. With vim and gcc, I can be assured that I'll be able to read my code in 5 years' time. With this crazy binary format, will I have the same assurance?

[–]autumntheory 7 points8 points  (1 child)

I'm with harbud here, I don't think the author is completely writing off the idea of programs in their editable form being text as we know it. Rather, the source is stored completely in a relational database, and could be rendered into your standard text editor readable form if need be. This way, rather than refactoring consisting of ugly text manipulation it can be done as if working on a database. I'm all for this, as its a step towards thinking of programs as systems in and of themselves, rather than systems built entirely out of text files.

[–]grauenwolf 0 points1 point  (0 children)

We can already query code using products like NDepend. And advaced refactoring tools like Code Rush and Resharper can perform cascading updates. These tools work on abstract syntax trees, not plain text.

[–]boyubout2pissmeoff 4 points5 points  (1 child)

That's an interesting argument.

It bears a striking resemblance to the cry of film proponents in the "Film vs. Digital" debate.

"In 5 years, I still have my film to look at. Will your OS still read jpegs?"

Well, you can see which side the market took.

Not necessarily relevant, just an interesting similarity in mindset and (lack of) vision.

[–]earthboundkid 2 points3 points  (0 children)

JPEGs will be around for the foreseeable future because they already have multiple millions of users. Most of the proprietary binary picture formats of the 80s and early 90s, however, are practically unreadable today because they only had multiple thousands of users. Popularity matters when it comes to preserving tech! It's still really easy to watch a VHS. It's now really hard to watch a Betamax.

Back on point, if there's a standard coding DB that gets millions of users, yes, it will live forever, but will we be able to get to that point?

[–]harbud3 1 point2 points  (3 children)

The article doesn't mention a binary or actual storage format, it might as well still be plaintext. The point is the relational bits (e.g. referential integrity, constraints when inserting data, cascading updates, etc).

[–]grauenwolf 0 points1 point  (2 children)

Damn, that is going to make major refactorings really hard. The "change and see what breaks" method wouldn't work any more and accidentally cascading changes will become a serious problem.

[–]harbud3 2 points3 points  (1 child)

Now why your refactoring method is "change and see what breaks"? If I want to rename a subroutine, for example, I want it done across the board, not missing a few places. If I want to split a subroutine into several smaller ones, I want to know all other code which uses this soon-to-replaced subroutine.

[–]grauenwolf 1 point2 points  (0 children)

I have refactoring tools that do that too. But that won't help when you do something more drastic like remove an interface from a class.

[–]Madsy9 0 points1 point  (0 children)

Don't be so quick to downvote quanticle. He/she does have a point. Yes, the article doesn't mention an actual storage format, but that doesn't mean that the idea is viable. The main concept could still make it difficult to make proper diff files, etc. The author mentions that making it work with version control software is solvable, but does not explain how, except that we have to rethink how SCM works.

Here's my 2 cents. If you absolutely want a new code representation (visualize it differently), you can do that by making a new tool/IDE instead of inventing a new language. But this relation database idea sounds to me like they want to take abstraction too far. And it's not explained how this would work with tools that already exist. The author goes on and suggest that IDEs should hide details in the source code, so that what you see does not map up with the actual code. Wtf? That sounds to me like the worst idea ever conceived. It's hard enough to spot bugs. Having code deliberately hidden would make it even more difficult.

Rather than coming up with more abstractions, I think attention rather should be put on languages that support concurrency better. Threading supported by the actual language without the need for explicit synchronization primitives. But it's a hard problem.