Re: GNAT GPL is not shareware

["Björn Lundin" <b.f.lundin@gmail.com>]

On 2015-01-06 21:52, Shark8 wrote:

>> So? Welcome to the real world.
>> PATH is an environment _variable_
>> that is ok to add stuff to.
> 
> I'm not saying it's not ok to add stuff to it; I'm saying making your
> system dependent upon it is, in a word, stupid.

becasue ?


> 
> Really?
> What has file-centric and "distributed among tools" setups brought about
> (a) in terms of configuration complexity? 
I do not know
And I do not see the relevance

>(b) In terms of organization complexity/dependence? 
I do not know
And I do not see the relevance

And (c) in terms of consistency complexity?
I do not know
And I do not see the relevance

> (A) How many different "small tools" have their own configuration which
> directly impacts another tool and that other tool doesn't know about the
> first?

I do not know
And I do not see the relevance here either.

> (B) Consider how many libraries need to be installed in a certain place
> to get them to work right/easily.
> (C) Have you /EVER/ linked to the wrong object because it became out of
> date?

No. Unheard of. Did not think it was possible.


> 
> At what cost?
> If things are in a database you can get consistency-checking essentially
> for free! You can design the system so that you *NEVER* compiler
> "against the wrong object". 

How do you do for accomplish linking out-of-date objects ?
You seem really hung up on this, so I interpret it as it happens often.
Does it?

>You can make it so that you *NEVER* pull an
> 'oopsie' with a simple textual search-and-replace rename.

So why would a db-based ide be better on this thatn a file based?

> Moreover, if stored in a database things like version-control can be
> made more useful by storing only the semantically meaningful changes.
> Things like "formatting style" become absolutely meaningless because,
> guess what, the textual-representation gets reconstructed and
> redisplayed as-needed... and that can be fully customizable to the
> particular user w/o impacting anyone else.

And that would make you be the most impopular man,
if our company set the standard for that.
People get _really_ upset if you tamper with a 15-year old comment.
Or changeing case on variables.
Automatic re-writes is a nono. (a bit conservative. I know)


> Seriously, that "the industry" remains fixated on _text_ as the de facto
> medium for storing/maintaining/manipulating programs is disgusting! --

Very much seems disgusting to you...

> It's like a firearm manufacturer that refuses to use firearms in favor
> of bows because "it's simpler".

It would be simpler to deny weapons at all ...

> 
> Hell, if *"because it's simpler"* is a valid reason to embrace
> something, might I suggest you look into PHP, after all its
> implementation (and usage) is "much simpler" than Ada or most any
> compiled language.

No. I like thing s to be simple AND safe. PHP does not match safe.
I also like the KISS principle. Less errors because of
overly complex configuration. I like it simple so I do not need to
explain stuff for my colleagues. I compile stuff with -O0 and -g
to get good stack-traces when needed. To catch errors, and understand
them as soon as possible, so a fix can be provided.

Yes, i like simple stuff, because they break more seldom.
But don't confuse simple with bad.


And I also like to auto-generate objects from xml-files that wraps
access to database-tables. Output is Ada-files.
Print to standard_output and redirect to file.
Simple. Works. Not needed to fiddle with API to access your IDE-DB
or whatever you can provide. If you provide other input means than your IDE.


>> Lets us kill all text-editors and
>> only use _your_ soon-to-come-any-decade fantastic
>> super duper editor
> 
> Who said anything about killing text editors?
> Of course it'd need a way to display/manipulate the program, and of
> course it'd need to be able to import/export plain-text.

ok - rephrase to 'lets kill all editors that saves to file'

> 
> But the fact still remains: the text-based/file-based model is
> inherently worse because it pushes automatable and verifiable checking
> directly into the user's lap.
> 

Things your coming IDE can catch by saving to DB, it could also catch
when save to file.
Consider the file system your db.


--
Björn