On Sat, Jan 23, 2016 at 12:48 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Okay. Start persuading "management" (presumably the PSU) that CPython
>> needs to be more modular, with different release cycles for different
>> components. Your first step is to figure out the boundaries between
>> t
On Sat, Jan 23, 2016 at 12:30 AM, Rustom Mody wrote:
> You just gave a graphic vivid description...
> of the same thing Marko is describing: ;-) viz.
> A full-size language parser is something that you - an experienced developer -
> make a point of avoiding.
It's worth noting that "experienced de
On Friday, January 22, 2016 at 7:13:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > IOW anyone who thinks that *arbitrary* complexity can *always* be
> > tamed either has a visa to utopia or needs to re-evaluate (or get) a
> > CS degree
>
> Not all complexity can be tamed, but what yo
Chris Angelico :
> Okay. Start persuading "management" (presumably the PSU) that CPython
> needs to be more modular, with different release cycles for different
> components. Your first step is to figure out the boundaries between
> those components. Get started.
Gladly, I don't need to do anythi
Rustom Mody :
> IOW anyone who thinks that *arbitrary* complexity can *always* be
> tamed either has a visa to utopia or needs to re-evaluate (or get) a
> CS degree
Not all complexity can be tamed, but what you can't tame you shouldn't
release, either.
Marko
--
https://mail.python.org/mailman/
On Friday, January 22, 2016 at 6:05:02 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody wrote:
> > 2. My students trying to work inside the lexer made a mess because the
> > extant lexer is a mess.
> > I.e. while python(3) *claims* to accept Unicode input, the ac
On Sat, Jan 23, 2016 at 12:00 AM, Marko Rauhamaa wrote:
> However, as a matter of rule, older code bases have been bloated till
> they can barely be maintained. That's when the management starts to
> listen to new ideas. Better late than never.
Okay. Start persuading "management" (presumably the
Chris Angelico :
> Alright. Can you rewrite all of those modules in three months?
The point is not to rewrite modules except as a fallback for a
hopelessly badly written module.
> And then there's the language itself. The cpython/Python directory has
> 58 .c files, many of which are closely tied
On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody wrote:
> On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
>> > The knowhow, vision and skill is apparently very rare. On the product
>> > management side, we have the f
On Fri, 22 Jan 2016 04:04:44 -0800, Rustom Mody wrote:
> These are just specific examples that I am familiar with Chris' general
> point still stands, viz take the large and complex program that is
> cpython and clean up these messinesses: You will still have a large and
> complex program
I'm not
On Fri, Jan 22, 2016 at 10:54 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
>> So what do you do with a huge program?
>
> Modularize. Treat each module as a separate product with its own release
> cycle, documentation, apis, ownership etc
Rustom Mody :
> These are just specific examples that I am familiar with Chris'
> general point still stands, viz take the large and complex program
> that is cpython and clean up these messinesses: You will still have a
> large and complex program
No, as long as the ugly parts are compartmentali
On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
> > The knowhow, vision and skill is apparently very rare. On the product
> > management side, we have the famous case of Steve Jobs, who simply told
> > the engineers
Chris Angelico :
> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
> So what do you do with a huge program?
Modularize. Treat each module as a separate product with its own release
cycle, documentation, apis, ownership etc.
What is a reasonable size of a module? It is something you would
On Fri, 22 Jan 2016 12:19:50 +0200, Marko Rauhamaa wrote:
> We need similar code sanity management. Developers are given much too
> much power to mess up the source code. That's why "legacy" is considered
> a four-letter word among developers.
When I started in this business, in the mid-70s, ther
On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
> The knowhow, vision and skill is apparently very rare. On the product
> management side, we have the famous case of Steve Jobs, who simply told
> the engineers to go back to the drawing boards when he didn't like the
> user experience. Most
Rustom Mody :
> On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
>> I've been there. I think the root problem is to have a code base
>> that's so large and complex.
>
> Bizarre comment... Are you saying large and complex code-bases should
> non-exist?
Why, yes, I am.
>>
On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
>
> > The author points out there are times when a code base is large and
> > complex enough that refactoring puts the programmer in a state of not
> > knowing whether they're making progress, because until th
Ben Finney :
> The author points out there are times when a code base is large and
> complex enough that refactoring puts the programmer in a state of not
> knowing whether they're making progress, because until the whole
> refactoring is complete the errors just cascade and it's hard to tell
> wh
Rustom Mody writes:
> You may find this strategy useful:
> https://pchiusano.github.io/2015-04-23/unison-update7.html
>
> particularly the section "Limitations of refactoring via modifying
> text files in place, and what to do instead"
A direct link to that section is
https://pchiusano.github.io
20 matches
Mail list logo
