Weblogs Forum - Version Control is Undo

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Version Control is Undo

83 replies on 6 pages. Most recent reply: Jan 27, 2009 4:17 AM by Dhruva Krishnamurthy

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 83 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 7:03 AM

> I must admit I do have an appreciation for good old text;
> it's simple and accessible. But as I've pointed in the
> best of worlds the actual benefit of text in our day to
> day work is quite limited.

My real problem is losing control over the code. Code is valuable and I need to be able access it in a static form that I can understand. It's mine (or my employer's) and will not depend on a third-party to be able to read and edit it.

One of the big problems I have with non accessible code and the tools around them is that the act of interpreting the code results in changes to it. For example, looking at the code while connected to a database schema causes the tool to modify the code silently. Another issue is that if the tool has a bug, the developer is shit-out-of-luck. I used a tool once that had a problem when I would change a query underlying a report that it would move all the screen elements off of the viewable area of the screen. In the tool my only option was to recreate the report from scratch (I had to update hundreds of these screens). Luckily the tool allowed me to export to a text format that could be understood and modified (with some effort.)

So if you were to derive a new way to persist code, and I were giving requirements they would include: accessible, (hand) editable, and archivable source. Given those requirements, files on a file system (universally supported on all modern platforms) fit the bill perfectly. I can imagine a completely different approach to structuring code but I still don't see what is gained by moving from text files which are inherently readable, editable, archivable, emailable, and universal.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 7:13 AM

> Take IntelliJ IDEA. Think of all the antics it goes
> through to essentially synchronize the textual
> representation with the parsed model it maintains. Two
> SORs usually indicates a bad design, and since the text is
> obviously not nearly as efficient or as dense as the
> model, the logical choice is to scrap the text. Sadly, we
> can't do that until we have a truly integrated source
> control system.

On a side-note, I'm not sure I understand your point here. I don't use IDEA (I've heard it's great) but are you suggesting that it has two persisted forms of the code? I would imagine it has the source and an in-memory representation of that source. There's only one system of record: the source. If there are things that it's persisting that cannot be maintained in the source, then that's really a problem with the source format. It wouldn't be surprising if that were the case given that Java was designed without these kinds of tools in mind.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 7:32 AM

> On a side-note, I'm not sure I understand your point here.
> I don't use IDEA (I've heard it's great) but are you
> u suggesting that it has two persisted forms of the code?

Yes, worse it appears to cache the display representation. If the cache goes wrong you can get major discrepancies between what IDEA shows as the content of a file and what is actually on the disk in the 'original' source file. This is incredibly confusing. I have had this happen on a number of occasions.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 7:46 AM

> > On a side-note, I'm not sure I understand your point
> here.
> > I don't use IDEA (I've heard it's great) but are you
> > u suggesting that it has two persisted forms of the
> code?
>
> Yes, worse it appears to cache the display representation.
> If the cache goes wrong you can get major discrepancies
> between what IDEA shows as the content of a file and what
> is actually on the disk in the 'original' source file.
> This is incredibly confusing. I have had this happen on a
> number of occasions.

I see. So given that, I say this means the source is inadequate or the IDEA team believes it to be so. I'm not convinced that this means we must abandon text altogether.

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 11:03 AM

>My real problem is losing control over the code. Code is
>valuable and I need to be able access it in a static form
>that I can understand. It's mine (or my employer's) and
>will not depend on a third-party to be able to read and
>edit it.

I suppose that's a common fear. I'm sure many people felt the same way during the transition from file cabinets to databases. Ultimately, we either trust/depend on advances in technology to improve our lives or we don't.

Personally, I think someday in the not so distant future source files will seem quaint. I'm hoping anyway.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 11:34 AM

> >My real problem is losing control over the code. Code is
>
> >valuable and I need to be able access it in a static form
>
> >that I can understand. It's mine (or my employer's) and
> >will not depend on a third-party to be able to read and
> >edit it.
>
> I suppose that's a common fear. I'm sure many people felt
> the same way during the transition from file cabinets to
> databases. Ultimately, we either trust/depend on advances
> in technology to improve our lives or we don't.

It's rational to fear something that you've experienced multiple times. You didn't address any of my concerns or give any reason why I shouldn't have them. You've simply made a comparison that I don't even think is valid.

And I still haven't seen a convincing reason why we should move away from source files. What's the advantage of this yet to be named format? Given that the trends in application architectures are mostly going towards text, what makes you think that code should go away from it?

> Personally, I think someday in the not so distant future
> source files will seem quaint. I'm hoping anyway.

Sandals, they are so BC.

What's quaint about them? Calling something 'quaint' is a pretty weak replacement for an actual argument. What would be a superior format and why? As far as I'm concerned bytes is bytes. It's all about how you interpret them. Should I just accept as god's truth that there's a format that's significantly better? You must have specific reasons for believing in whatever it is that you think will improve our lives, right?

Without any other explanation I can only imagine that you are conflating the logical meaning of data and it's persisted structure. So if you know of some inherent advantage of a specific approach to storing code, I'd like to hear what it is.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 12:02 PM

>
> I suppose that's a common fear. I'm sure many people felt
> the same way during the transition from file cabinets to
> databases. Ultimately, we either trust/depend on advances
> in technology to improve our lives or we don't.
>
> Personally, I think someday in the not so distant future
> source files will seem quaint. I'm hoping anyway.

I think what James is saying, or at least what I feel, is that I expect my code to be in a format where I can edit and manipulate it with a wide variety of tools. There is a huge ecosystem of tools for manipulating text. You give up a lot when you move away from it. If your code is locked up in a proprietary binary format that can only be read by tools from one vendor, you are completely locked to that vendor. You are at the mercy of any corruption the tool introduces into the file, because your only other option is a hex editor. That's not fun.

As for filing cabinets, well, I know a lot of people who still print everything out and keep it in filing cabinets. They haven't went away.

Fred Garvin

Posts: 52
Nickname: fredgarvin
Registered: Jan, 2008

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 4:18 PM

>Calling something 'quaint' is a pretty weak replacement
>for an actual argument. What would be a superior format
>and why?

I thought I presented the argument in my original post. Essentially, modern development tools have moved way beyond text editors and compilers. A top notch IDE (IDEA) is measured by its ability to improve our development experience via static analysis, code completion, refactoring, navigation, etc. The IDE must produce a persistent parse model of the source to enable these features; the source files just get in the way. Constantly keeping the two models in sync decreases both performance and the practicality of otherwise useful tools. So, I say, why bother with the source? If the IDE could instead work directly on the model and forgo source files altogether, it will be a boon to tool development and, thus, a boon to developers.

I also mentioned that an integrated source control system would benefit from working on the parse model. For instance, changing a member or type name would have real meaning and would affect just one element in the model, not all usages of it. Change tracking would have new meaning. Standards regarding code formatting become meaningless; you can view and edit code your way. Essentially, a parse model based source control system is much more capable than a conventional text based one.

Regarding source files, they can still exist; they're just not the system of record. If you want source files, the IDE will happily generate them for you. If you have existing source files, the IDE will happily compile them. Think import-export.

What's needed in this grand scheme is a standard parse element definition and format so that tools are compatible. For instance, Java could specify a parse element definition and could directly compile this format... and pigs will fly.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 5, 2008 5:04 PM

> >Calling something 'quaint' is a pretty weak replacement
> >for an actual argument. What would be a superior format
> >and why?
>
> I thought I presented the argument in my original post.

I see no argument. I see an assertion. One that I dispute.

> Essentially, modern development tools have moved way
> beyond text editors and compilers.

I'm asking you to give some evidence of this. You are just reasserting the proposition I am questioning. I gave very specific reasons that text is advantageous. I would expect you to give some specific reasons why the format that you still haven't identified is better.

> A top notch IDE (IDEA)
> is measured by its ability to improve our development
> experience via static analysis, code completion,
> refactoring, navigation, etc. The IDE must produce a
> persistent parse model of the source to enable these
> features; the source files just get in the way. Constantly
> keeping the two models in sync decreases both performance
> and the practicality of otherwise useful tools. So, I say,
> why bother with the source? If the IDE could instead work
> directly on the model and forgo source files altogether,
> it will be a boon to tool development and, thus, a boon to
> developers.

So, as I suggested above, you're conflating the logical model of what the code represents with it's persisted representation. There are innumerable ways to persist a given model that are all exactly equivalent. In order to demonstrate that a given format is 'better' than text, you would have to show that there is something you can represent with the unknown format that cannot be represented in a textual format or at least something that is unacceptably difficult to represent in text.

And no, this would not be a boon to developers using the language. It is at best a non-issue and at worst it's a nightmare. It's really a boon for the creator of the tool because it simplifies their job mainly because they don't have to figure out how to produce a good textual representation of their logical model just like it's easier for car makers if they don't have to install safety features.

You need to understand I have intimate experience with tools that do just what you are suggesting. I got no benefit from the lack of textual source and in all cases it's been a huge downside of the tool. Reality trumps starry-eyed assertions.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Version Control is Undo . . . or more

Posted: Dec 8, 2008 5:22 AM

Just like cabinets; Give me CDs over downloaded MP3s any day. No domestic usage restrictions, higher quality, longer lifetime (and the ability to generate aforesaid MP3s, WMAs, AACs, etc. to any abitrary level of quality). I suspect, though, that making such an argument says more about my age than the reality of the points made.

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Version Control is Undo

Posted: Dec 8, 2008 3:14 PM

while i appreciate people trying to improve the status quo, it bugs the crap out of me that people don't know that the status quo didn't have to be the way it was; that there were (and sometimes are) 'fringe' alternatives that suck less, except for all the issues that obviously come along with the fact that they are 'fringe' :-)

http://en.wikipedia.org/wiki/Versioning_file_system

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 9, 2008 5:13 AM

> What's needed in this grand scheme is a standard parse
> element definition and format so that tools are
> compatible. For instance, Java could specify a parse
> element definition and could directly compile this
> format... and pigs will fly.

Actually, what is required is a universal data format. Not for source code only, but for anything. A universal data format could solve many issues in today's computing.

One step in the right direction is XML.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 9, 2008 5:15 AM

> And no, this would not be a boon to developers using the
> language. It is at best a non-issue and at worst it's a
> nightmare. It's really a boon for the creator of the tool
> because it simplifies their job mainly because they don't
> have to figure out how to produce a good textual
> representation of their logical model just like it's
> easier for car makers if they don't have to install safety
> features.
>
> You need to understand I have intimate experience with
> tools that do just what you are suggesting. I got no
> benefit from the lack of textual source and in all cases
> it's been a huge downside of the tool. Reality trumps
> starry-eyed assertions.

What problems did you have? please describe some...

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 9, 2008 12:21 PM

> What problems did you have? please describe some...

I gave some examples earlier. Here's a high-level list off the top of my head:

* difficult to impossible to incorporate into source control with other resources
* no useful diff / merge (XML-based source is big offender)
* source that is difficult or impossible to read. If the source becomes corrupted, it costs a lot of time/money to repair the source if it's not human readable.
* ultimate vendor lock-in (cannot see our own process logic or extract it from text)
* silent corruption of code by tool
* lack of persisted format between tool versions (see previous)
* infeasible to write custom analysis, code generation, and refactoring tools
* inability to conform to change management (manual production deployments)
* integrated source control broken / unusable
* gui-based development much slower than text based (modal dialog hell)

I'm not saying that a non-text based format cannot be written without these issues but unless all the benefits I get from text-based source are available in a new approach, I don't believe it is wise to use that approach. The downside risks are too high.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more

Posted: Dec 9, 2008 1:18 PM

> > What's needed in this grand scheme is a standard parse
> > element definition and format so that tools are
> > compatible. For instance, Java could specify a parse
> > element definition and could directly compile this
> > format... and pigs will fly.
>
> Actually, what is required is a universal data format. Not
> for source code only, but for anything. A universal data
> format could solve many issues in today's computing.

Universal formats already exist. Text is one of them. The problem is that a universal format must be constrained in order to be useful for defining program logic.

> One step in the right direction is XML.

I disagree completely. XML is one of the worst formats for storing code. The only benefit it provides is that there are lots of libraries around for parsing it. The readability of XML-based code is very low, especially when XML gets embedded in the XML. And because equivalent XML can be formatted in many different ways, special diff tools to work with it.

What we need is better parsing libraries so that people don't feel the need to use XML for code. Parsing is really a pretty small part of the problem. The structure of the documents and the interpretation of them is a bigger problem.

Flat View: This topic has 83 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]

Previous Topic

Next Topic