[Libre-soc-dev] Task 939 and its subtasks

[lkcl]

On Wed, Nov 23, 2022 at 11:16 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Tue, Nov 22, 2022, 13:08 Dmitry Selyutin via Libre-soc-dev <libre-soc-dev at lists.libre-soc.org> wrote:
>>
>> On Tue, Nov 22, 2022 at 11:37 PM lkcl <luke.leighton at gmail.com> wrote:
>> >
>> > On Tue, Nov 22, 2022 at 7:01 PM Dmitry Selyutin <ghostmansd at gmail.com> wrote:
>> >>
>> > > I'd take this with a grain of salt. :-)
>> >
>> > no, really:
>>
>> Please don't speak for everybody around. If it takes 45 minutes for
>> you to change this code respectively -- this might be correct.
>> Otherwise this is quite an exaggeration, starting from the whole ply
>> concept.
>>
>>
>> > if that takes more than 45 minutes then something is very very wrong.
>>
>> No, it's not. People are different. Some outperform in one area,
>> others -- in different. This is perfectly normal.
>>
>>
>> > from there, the confidence builds massively because all you have
>> > to do is say, "NEXT".  pick any function (any one of the BNFs),
>> > create associated unit tests, and it's done.
>> >
>> > with there being so few BNF expressions, it quickly becomes
>> > "routine".
>>
>> Later -- yes. But not on the first iteration. Especially not for a newcomer.
>>
>>
>> > the "gotchas" in c are that you have to declare variables.
>
>
> waay more than that...you have to figure out what type those variables should be, we need type deduction/propagation for that to work. we're currently getting by by relying on python's total lack of static typing.
>
>>   well, just
>> > accumulate those, drop them into a separate data structure during
>> > the BNF walk, and now you have 2 data structures, one of which
>> > may be post-process-substituted into the other.
>> >
>> > > I'd argue with MAINTAINABLE and SIMPLE as one who debugged and
>> > > modified it, especially since you write it in CAPS.
>> >
>> > three other people have demonstrated self-learned capability to
>> > both comprehend, debug, and modify the python-ply-based parser.
>> > this is enough empirical evidence to support the hypothesis that the
>> > code is both simple and also maintainable.
>
>
> I would instead argue based on my personal experience and from what i've heard people say that those 3 other people you are referring to were forced into having to comprehend, debug, and modify the python parser because they found the language implemented by it to have terrible user experience,

tough.  get over it.

> failing with indecipherable error messages

tough. get over it.

> for confusing reasons or producing output that would fail when run,

tough.  fix it.

> both of which could only be fixed after extensive tinkering with the pseudo-code
> and then finally having to fall back on debugging and bodging the parser themselves.

good enough.

> Any language that we want to be taken seriously

it doesn't.  it was never intended for use as executable code.

> (and what language could be more qualified as needing to be taken seriously than the specification of our processors?!)

not this one.

> imho that is all symptoms of a parser with near zero error handling,

tough.

> no type checking

tough

> or inconsistency checking,

tough

> with a common method of dealing with syntax errors being to throw an AttributeError

good enough.

l.