[Info-vax] source control and semantics (Re: Why so much Unix envy?)

[Shark8]

On 9/13/2014 6:13 AM, Stephen Hoffman wrote:
> On 2014-09-13 01:49:23 +0000, Craig A. Berry said:
>
>> Actually most modern version control tools do not treat the source as
>> plain text because at the most fundamental level they don't treat it
>> as text at all: it's just arbitrary content....
>> <http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html>
>>
>>
>> And also note that you can typically ignore whitespace-only changes
>> when looking through history with such options as "git diff
>> --ignore-space-change".
>
> Yep.  Piping the incoming source code through a pretty-printer during
> the version-control check-in process is common practice.

You completely miss my underlying point... the point is that text is a 
terrible "base format" for program source in most languages. (Forth is 
probably one of the few exceptions given its view/philosophy... but even 
then it'd probably have a better time w/ non-textual storage,)

Just like "files" are a terrible base component for storing program 
source. (In an AST-like representation, you could refactor names w/o any 
concern about search/replace interactions.) Another poor point about 
files is that they can be separated from dependent and depending files 
-- storing the whole application/module in, say, a database (with, say, 
the restriction that all commits are consistent) alleviates that problem.

Why are we assuming a "lowest common denominator" for our tools and 
basic building-blocks for code? I will grant that there are times where 
such tooling would not be available [bootstrapping], but why must these 
rare cases drag down the rest of our tools? -- I maintain that this is 
due to the "quick and easy" mentality of C/Unix, in the `80s there was a 
clear desire and progress on tools of the nature I've described... but 
that all vanished just as C became the lingua franca for low-level systems.

> It'd also be handy to have the project's preferred source code format
> available via your preferred IDE or editor, too.  Yes, as well as
> whatever format the particular programmer prefers to use.

Exactly where my thrust is!
This shouldn't be in the "it'd be handy" category of thought, but the 
"WTF!?" category when you /don't/ have it.

> Xcode doesn't
> have innate features that provide this, but there are Xcode extensions
> that allow you to selectively reformat the source code, and that really
> helps even when you're just initially entering the source code.  Eclipse
> or NetBeans also undoubtedly have source code formatters available.
> You can go nuts here with emacs and vim, too.
> <http://stackoverflow.com/questions/149558/recommended-vim-plugins-for-c-coding>
>
>
> Combine this with continuous integration and build bots and related, and
> things can get much more interesting than is common in classic VMS
> environments.

Continuous integration is, once again, the wrong solution; if your 
"program database" is such that you cannot have an update which leaves 
the system in an inconsistent state [that is, non-compilable] then you 
have *ALL* the benefits of continuous integration... and at an earlier 
point in the development-cycle. (Essentially immediately, rather than 
the delay/turn-around of a compilation plus any comm handling [email 
alerts] all handled by separate facilities.)