bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: what can we expect from developers


From: Darshit Shah
Subject: Re: what can we expect from developers
Date: Fri, 29 Mar 2024 12:54:12 +0100
User-agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542

Hi Bruno,

I think you make some fair points on the contributions made by people with a 
passable  knowledge of the language.
However, when I said "maintained", I kind of assumed that there will be someone 
with a good enough command over the language who will be the arbiter of what 
patches get applied. Kind of like how you are currently the arbiter of how 
gnulib-tool is maintained because of your extensive knowledge of Bash and 
various portability concerns.

Such a maintainer could help clean up the patches when needed. My argument on 
wanting to stick with a more "pythonic" way of doing things comes from 
experience of having made the exact same choice long back and seeing with the 
power of hindsight how it affected things. The only reason the test suite in 
Wget is in a decent state right now, is we eventually got a contributor who 
modified quite a bit of it to be more Pythonic.

The other reason is that, the way something is stable and maintainable in the 
long term is if you leverage the strengths of that language. Just as you 
wouldn't attempt to write bash in a lisp-like fashion because a lot of GNU 
contributors are well versed with Lisp, you shouldn't attempt to write Python 
in a C-like fashion. 

You mention, wanting a programmer to be able to make changes like the commit 
you linked. I will say, I have a lot of faith in the developers who'd like to 
make commits like that and that they would be able to infer how to do it based 
on the examples around it pretty fast :-) 

I will however concede that modern Python has a lot of syntactic sugar which in 
a way detracts from Python's original charm of being extremely easy to read and 
parse. So if we for example end up using complex generators and comprehensions, 
it will make it hard for a lot of people to follow. Maybe there's a balance we 
can tread there?

P.S.: For those who'd like, there's a great Easter Egg in Python: `import 
this`, which prints the "Zen of Python". Rules I think are great for 
programming in general.

On Wed, Mar 27, 2024, at 23:50, Bruno Haible wrote:
> Hi Darshit,
>
>> >   - Can someone with little exposure to Python understand and modify the
>> >     code? When you write 'list' and the developer knows that 'list' means
>> >     what is known as "array" in other programming languages, they can work
>> >     with the code. Using the abstract interfaces that Python has does not
>> >     help in this aspect.
>> 
>> I would argue against this line of thinking. Sure, keep it simple, but don't 
>> reduce the subset of Python available only to something that is easily known 
>> to, for e.g. a C developer. I made the same decision when writing the 
>> testsuite for Wget almost 10 years ago, and in hindsight I regret it. 
>> 
>> The thing is, when you restrict it something that can be understood by 
>> someone with little exposure to Python, you end up with a codebase that is 
>> alien to both groups, the ones that know Python and the ones that don't. You 
>> get a codebase that neither enjoy working with and want to maintain. 
>
> An interesting thought.
>
> But the problem is that in GNU, with its traditional focus on C and bash
> scripting, "the ones that know Python" are a minority and "the ones that 
> don't"
> are the majority.
>
> I want that someone with little knowledge of Python is able to make a 
> commit
> like this one:
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=29441fd7bc60ec6010e64f5e8b702c4b6290cec4
> without needing to learn the ins and outs of regular expressions in 
> Python.
>
>> Instead, I would argue that following the standard Python best practices
>> is a better choice. The person maintaining the script needs to be a Python
>> developer anyways.
>
> No, that does not match reality. A significant portion of development gets
> done by people who have not much experience with the specific language or
> technology.
>
> When I look at my own skills [1] and what I have been doing with them:
> - I'm writing TeXinfo manuals, although I have only base knowledge of 
> TeXinfo.
> - I'm co-authoring gnulib-tool.py with only base knowledge of Python.
> - When I wrote CLN, I had only little prior experience with C++.
> - I wrote a bunch of TypeScript code with just 2 weeks of exposure to 
> TypeScript.
> - Two weeks ago, I wrote a Bison parser for something; that was 
> probably only
>   my 3rd use of Bison ever, and I had beginner's problems.
> - Today, I'm considering writing code for a disk-files-based hash table
>   and realize that I have zero knowledge or experience about it.
>
> In summary: People write a *lot* of useful code and contributions at a moment
> when they still only have base knowledge.
>
> Please fill in your own skills set on Savannah [2]; I bet you will find that
> the same observation will hold true for yourself.
>
> Bruno
>
> [1] https://savannah.gnu.org/people/resume.php?user_id=1871
> [2] https://savannah.gnu.org/users/darnir



reply via email to

[Prev in Thread] Current Thread [Next in Thread]