Mail Archives: geda-user/2015/09/05/23:06:02
On Sun, 6 Sep 2015, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Sat, Sep 05, 2015 at 05:07:54PM -0400, DJ Delorie wrote:
>>
>>> It's just an opinion. Tastes may vary.
>>
>> Sure, you can always find a few exceptions to any generalization. But
>> KiCAD's community is growing, they're attracting big projects, and
>> people tend to try them first because they're the better-known name.
>> gEDA used to be that, but now we're the has-beens. Our community is
>> shrinking, we're losing devs, etc.
>>
>> Can we change? Sure, if we really want to, and figure out how.
>>
>> Can we retake the #1 spot? I see no technical reason why not, if the
>> people can work together to address all the reasons why we're not #1.
>>
>> But at the moment, unless we drastically change how we do things,
>> KiCAD is #1.
>
> Over and over again...
>
> Does this mean we should replace Guile with Python?
I wouldn't say "this". Rahter, in general, for many reasons, Guile should
be replaced.
With Python? Well... With antyhing popular, or at least paradigm-popular
(as in non-exotic, non-lisp), basically.
I personally believe hardwiring a single language is a bad idea.
Scheme may have looked a great option 15 or 20 years ago. Looking
at the sitation now, python or lua have good chances to survive at least
that amount of time, but who knows? What if there will be new trends and
noone will want to touch python in 2030?
I really believe in having a solid C core and a separate, multi-language
script plugin system. Core functionality should go without scripts.
Configuration should be declarative and simple, even if it costs a custom
mini-language. Scripts should be reserved for user addons.
> (Emacs Lisp with Vim scripts?, LaTeX coding with LibreOffice widgets?
> systemv with systemd etc. etc.)
>
>
> Citate from http://twistedmatrix.com/users/glyph/rant/extendit.html:
>
> -------------------------------------------------------------------
> Access from multiple scripting languages is not a good idea.
>
> In an article I posted to advogato, I described my position on this in
> more detail, but the gist is that it is extremely difficult to design an
> interface which makes sense and helps people be productive in one
> language. Doing it several times over is a fantastic challenge with
> little benefit - in fact, the effort may backfire.
>
> Consider that, if you maintain multiple scripting interfaces, your
> application will develop a ragged community of customization fans, who
> will regularly argue about what language to use to extend your software.
> If you support Perl, Ruby, Python, and Scheme, you will certainly find
Like this does not happen at the moment... My impression about this part
of gscheme always has been that there's a small but strong scheme-fan
developer base occasionally joined by a very few users, while the rest of
the user base simply can not penetrate the surface because of scheme. Not
having multiple scripting languages doesn't mean everyone will be happy
with your favorite language. It only means people have no choice, and will
not argue about which language would be the best for a task, but about how
your choice of language fails on it.
> Python and Perl fans who are using your application constantly at each
> others' throats, re-implementing the same 'script' functionality 8 or 9
> times, and generally wasting time that could be better spent enhancing
> their plug-in packages.
Yup, whenever there are multiple alternatives, reimplementations happen. I
don't find that a waste or a bad thing. I am sure kicad reimplements a lot
of things we do. There are hundreds or thousands of free text editors out
there, reimplementing a lot of the same problems, like how to handle
gigabyte long text files and edit lines in the middle without having to
memcpy the whole thing for each character. Abandoning all these for One
Good Implementation would be as bad as finding the most efficient animal
on the planet and wipe out the rest of the species.
>
> If you support only one scripting language, but you support it well,
> then you will create a simple environment into which contributors may
> put enhancements, and you will facilitate sharing and understanding
> between those contributors. Focusing on a single language and supporting
This did not happen with scheme. In theory if you chose a more popular
language, it may happen, but does not necessarily happen. And you really
can't know what's a good language for this purpose now, yet alone in 10
or 20 years into the future...
> It's just what's happening now in the project. Exactly one developer
> (Roland) works on its python branch and has a support of some users in
> the list who always keep repeating 'guile is wrong'. How will this
> encourage any dev like me who've invested their time on learning current
> gschem internals and Scheme in order to try to make things better?
I am an user of gschem. I am not a fan of python at all. Really, I hate
the indentation, I hate OOP. I find things like separator.join(array)
unintuitive as if it was designed by to explicitly make life harder.
BUT. It is 100x better than scheme. Really, I've been working on pcb-rnd's
rosetta subproject. Had to write and test the same 10..20 lines sciprts in
9 different langauges, including scheme and stutter (a lisp
implementation). It usually took 1 unit of time to write the initial
script in awk or lua. It took about (num_of_languages)/3 unit of times to
convert them to all the non-scheme/non-lisp languages. And then it took
2..4 units of time to get the scheme and lisp version working. It is not
the first time such things happen, I still remember the weekend I spent on
writing text gnetlist backends.
So even if python is very far from a language I'd like, I regard Roland's
efforts as a chance for a change for the good.
>
> OK, I see the message. Get out, stupid ancient fools, your time is
> out ;) The new generation is coming...
For me, it's not about old or new, neither in people nor in tools. My
absolute all time favorite language is awk. First appeared in 1977. As I
said about python, it's not even about getting my favorite language in the
tools. It's really about scheme being so bad of a choice that almost
anything else would be better, for practical reasons. Yes, even tcl
would be better...
Regards,
Igor2
- Raw text -