Mail Archives: geda-user/2015/09/03/20:40:05
On Sep 3, 2015, at 5:30 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
>>> Do we want to retain backwards compatibility? Yes. Do we want to do
>>> so at the expense of new development? No. How do we reconcile these
>>> two goals? I don't know, and nobody has offered a workable solution.
>>
>> Actually, for netlisting, I think we do. Keep gnetlist and bring in xorn.
>
> Except that leads to the "memorable" name "gnetlist" referring to a
> then-obsolete command, and "xorn", which doesn't seem to have a
> project-related name, being the new way.
>
> IMHO It's ok for a generic name like "gnetlist" to be reused for
> something new that still does basically the same function from the
> user's point of view, as long as there's *some* way for people who
> need the old way to still get it. For example, renaming the existing
> gnetlist to gnetlist-scheme if/when we move our recommended gnetlist
> to be a link to gnetlist-xorn.
I expect that as Roland notes, the ones who would be confused won’t know what’s under the hood, while the ones who actually use the tool unwrapped will know what they’re doing.
> It's a minor one-time inconvenience
> for people who need the old way, in exchange for a much more
> consistent experience for the common user.
I don’t think it’s a one-time inconvenience for groups sharing designs. gEDA’s not just for hermits, you know.
>
> (this is my usual stance of "the common case should be easy, other
> cases should be possible.")
>
>>> We certainly can't just leave things the way they are. That's the
>>> road to stagnation and doom as other projects innovate right past us.
>>
>> I don't see that happening. Where is an EDA toolkit with anything
>> approaching our flexibility?
>
> Innovate != flexibility. If they come up with a better way to serve
> their users, they'll get more users and we'll get less.
Popularity is not a measure of excellence.
> Flexibility
> is *one* advantage, there are a lot of other things which add to the
> user experience.
Flexibility is our strength.
> A text editor is highly flexible but nobody uses it
> to do layout (tweak, maybe, do, no).
>
> (as an aside, I've watched mechanical cad users on youtube that are
> VERY productive on software that took the opposite approach as we did
> - just because a solution is good for a few people doesn't mean it's
> the best overall solution)
Of course. There should be integrated tools and toolkits. But we have a toolkit. That’s our part of the space.
>
>>> We want to encourage, not discourage, development of our tools.
>>
>> New tools, better tools, yes. Unnecessary changes to working tools
>> out of a misplaced fear of stagnation, no.
>
> The words "Unnecessary" and "misplaced" overstate your bias (you could
> have just said 'Changes to ... a fear of' and avoided the emotionally
> charged words completely). It seems that others disagree about
> whether change is needed, and if the fear of stagnation is real or
> not.
I approve of Roland’s approach: make a tool that’s likely better in parallel with the old tool.
> Your "fear of needed change" is not the best solution for the
> project. We aren't intentionally trying to break your scripts,
But you don’t even understand the problem. The gschem change that caused the biggest harm to a project of mine didn’t break any script. It was a change a few years ago in attribute promotion that produced schematics with a lot of promoted footprint attributes when I had intended only to promote those that should override my medium-heavy symbols. That was a mess. I suppose that whoever made that change thought it a harmless, minor improvement.
Nobody uses the full breadth of the toolkit, so it’s difficult for anybody to anticipate what a change might break. It’s not just scripts, although those are very important.
> but we
> also can't let one user's unusual setup prevent us from improving
> everyone else's experience.
>
> If you were the *only* person needing the old way (and I'm not saying
> you are), would it be fair to the project to force us to support you
> forever?
But it’s changes that produce the greatest need for support. If you don’t change things, not much breaks. Good tools need very little change. How much have TeX or AWK changed in the last decade? Their stability is an important part of their continuing relevance, I think.
> Of course not. So, where do we draw the line? In the open
> source world, the line is drawn wherever the developers choose to draw
> it. We are not contractually obliged to support old versions or users
> at all, although of course we prefer to do so whenever possible.
>
> So, sometimes developers may decide that change is neccessary, and
> that the fear is real. Sometimes, that means some users will not be
> happy. Telling the developers not to do that is neither constructive
> nor helpful.
But insisting on change for the sake of change is not constructive either. The person who is being really constructive here is Roland. Tool hard to change? Not flexible enough? Make a new one! I predict I will use both gnetlist and Xorn for a long time.
>
>>> We certainly can't just ignore our existing user base either, though.
>>> gEDA is known for its hackability and that unfortunately locks us into
>>> APIs that were never intended, but those hacks do some pretty awesome
>>> things.
>>
>> Unfortunately? Absolutely not! Is AWK a failure because it's widely
>> used, but hardly ever used for scanning telephone switch logs? That
>> a tool takes off and does things that its designers never intended
>> is testimony to excellent design.
>
> That was not at all what I meant. I meant, there may be internal
> functions that were never intended to be official (or even public),
> that someone discovered and (ab)used in a workflow.
Name one. Actually, in gnetlist, it's the other way around: a gnetlist scripter has to discover unofficial functions as there are *no* official ones!
> There must be a
> way to let that API change, despite its use, else we'd be unexpectedly
> locked into something we don't want.
>
Or you could take that as an indication that somebody had a need that you didn’t anticipate, and cleverly found a way to fulfill it. You seem to have antipathy toward users’ innovation: wise developers will guide the way in your thinking. But gEDA is very friendly to users’ innovation. That’s a strength. Let’s keep it that way. Your notions of what users want are wildly wrong in my case, and likely not as good as you think it is in most cases.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -