Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #384570 > unrolled thread

Which newsgroup for json parsing?

Back to article view | Back to comp.lang.c

Contents

  Which newsgroup for json parsing? Josef Möllers <josef@invalid.invalid> - 2024-05-08 15:04 +0200
    Re: Which newsgroup for json parsing? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-05-08 16:21 +0300
      Re: Which newsgroup for json parsing? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 03:03 +0000
    Re: Which newsgroup for json parsing? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-08 15:33 +0100
      Re: Which newsgroup for json parsing? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-05-08 19:53 +0300
    Re: Which newsgroup for json parsing? jak <nospam@please.ty> - 2024-05-09 15:18 +0200
    Re: Which newsgroup for json parsing? Josef Möllers <josef@invalid.invalid> - 2024-05-13 11:07 +0200
    Re: Which newsgroup for json parsing? Mikko <mikko.levanto@iki.fi> - 2024-05-16 19:27 +0300
      Re: Which newsgroup for json parsing? Josef Möllers <josef@invalid.invalid> - 2024-05-16 20:01 +0200
        Re: Which newsgroup for json parsing? scott@slp53.sl.home (Scott Lurndal) - 2024-05-16 18:53 +0000
          Re: Which newsgroup for json parsing? bart <bc@freeuk.com> - 2024-05-16 20:21 +0100
            Re: Which newsgroup for json parsing? scott@slp53.sl.home (Scott Lurndal) - 2024-05-16 20:54 +0000
            Re: Which newsgroup for json parsing? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-17 05:24 +0100
              Re: Which newsgroup for json parsing? bart <bc@freeuk.com> - 2024-05-17 15:13 +0100
                Re: XML (was Re: Which newsgroup for json parsing?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-25 02:53 +0000
              Re: Which newsgroup for json parsing? jak <nospam@please.ty> - 2024-05-17 18:39 +0200
                Re: Which newsgroup for json parsing? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-17 18:07 +0100
        Re: Which newsgroup for json parsing? Mikko <mikko.levanto@iki.fi> - 2024-05-18 16:21 +0300
          Re: Which newsgroup for json parsing? Josef Möllers <josef@invalid.invalid> - 2024-05-27 13:51 +0200
            Re: Which newsgroup for json parsing? Vir Campestris <vir.campestris@invalid.invalid> - 2024-05-27 21:18 +0100
              Re: Which newsgroup for json parsing? Josef Möllers <josef@invalid.invalid> - 2024-05-28 12:33 +0200
                Re: Which newsgroup for json parsing? Michael S <already5chosen@yahoo.com> - 2024-05-28 14:45 +0300
                  Re: Which newsgroup for json parsing? Josef Möllers <josef@invalid.invalid> - 2024-05-28 20:15 +0200
                  Re: Which newsgroup for json parsing? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 17:14 +0100
                    Re: Which newsgroup for json parsing? David Brown <david.brown@hesbynett.no> - 2024-05-29 19:23 +0200
                      Re: Which newsgroup for json parsing? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-29 23:32 +0100
                  Re: Which newsgroup for json parsing? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-30 19:23 -0700
                  Re: Which newsgroup for json parsing? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-08-05 02:55 +0000
                Re: Which newsgroup for json parsing? Vir Campestris <vir.campestris@invalid.invalid> - 2024-05-30 17:49 +0100
      Re: Which newsgroup for json parsing? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 03:40 +0000
        Re: Which newsgroup for json parsing? scott@slp53.sl.home (Scott Lurndal) - 2024-05-23 17:14 +0000
          Re: Which newsgroup for json parsing? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-05-23 20:57 +0100

Page 2 of 2 — ← Prev page 1 [2]

#385198

On 27.05.24 22:18, Vir Campestris wrote:
> On 27/05/2024 12:51, Josef Möllers wrote:
>>
>> In my 40+ years of experience in IT/programming (I graduated 1981 from 
>> a Dutch polytechnic "HIO" in Computer Science and have retired in 
>> 2022) I have learnt that "works fine" is only part of the work. 
>> Maintainability should be added as well. Even if it is code written 
>> for one's personal use only, it may need some work later and then it's 
>> crucial to have it maintainable.
>>
>> But maybe you think so too,
> 
> I agree completely.
> 
> I learned my lesson a a student with a personal project which I left for 
> 6 months. When I came back to it I had to comment it before I could 
> carry on.

You will never have enough comments, even when you consider this rule ;-)

> (and I'm even older than you, although not by much)

Let me challenge that: I'm 67 (born September 1956) ;-)

Josef

[toc] | [prev] | [next] | [standalone]

#385200

On Tue, 28 May 2024 12:33:02 +0200
Josef Möllers <josef@invalid.invalid> wrote:

> On 27.05.24 22:18, Vir Campestris wrote:
> > On 27/05/2024 12:51, Josef Möllers wrote:  
> >>
> >> In my 40+ years of experience in IT/programming (I graduated 1981
> >> from a Dutch polytechnic "HIO" in Computer Science and have
> >> retired in 2022) I have learnt that "works fine" is only part of
> >> the work. Maintainability should be added as well. Even if it is
> >> code written for one's personal use only, it may need some work
> >> later and then it's crucial to have it maintainable.
> >>
> >> But maybe you think so too,  
> > 
> > I agree completely.
> > 
> > I learned my lesson a a student with a personal project which I
> > left for 6 months. When I came back to it I had to comment it
> > before I could carry on.  
> 
> You will never have enough comments, even when you consider this rule
> ;-)
> 

Probably true. 
And despite that you can very easily have too much (or too many?)
comments.

[toc] | [prev] | [next] | [standalone]

#385217

On 28.05.24 13:45, Michael S wrote:
> On Tue, 28 May 2024 12:33:02 +0200
> Josef Möllers <josef@invalid.invalid> wrote:
> 
>> On 27.05.24 22:18, Vir Campestris wrote:
>>> On 27/05/2024 12:51, Josef Möllers wrote:
>>>>
>>>> In my 40+ years of experience in IT/programming (I graduated 1981
>>>> from a Dutch polytechnic "HIO" in Computer Science and have
>>>> retired in 2022) I have learnt that "works fine" is only part of
>>>> the work. Maintainability should be added as well. Even if it is
>>>> code written for one's personal use only, it may need some work
>>>> later and then it's crucial to have it maintainable.
>>>>
>>>> But maybe you think so too,
>>>
>>> I agree completely.
>>>
>>> I learned my lesson a a student with a personal project which I
>>> left for 6 months. When I came back to it I had to comment it
>>> before I could carry on.
>>
>> You will never have enough comments, even when you consider this rule
>> ;-)
>>
> 
> Probably true.
> And despite that you can very easily have too much (or too many?)
> comments.

True. My (the obvious?) rule of thumb is that whenever I have to think 
about wtf Iwas thinking, then I add a comment describing why I did what 
I did. This often happens when I re-read the code before saving it, but 
sometimes shortly after that. When I have to think about why I did what 
I did much later, then it's obviously too late.

A remedy against too much/many comment(s) is to write some thorough 
documentation.

And, also, don't forget boilerplates for functions!

Josef

[toc] | [prev] | [next] | [standalone]

#385268

On 28/05/2024 12:45, Michael S wrote:
> On Tue, 28 May 2024 12:33:02 +0200
> Josef Möllers <josef@invalid.invalid> wrote:
> 
>> On 27.05.24 22:18, Vir Campestris wrote:
>>> On 27/05/2024 12:51, Josef Möllers wrote:
>>>>
>>>> In my 40+ years of experience in IT/programming (I graduated 1981
>>>> from a Dutch polytechnic "HIO" in Computer Science and have
>>>> retired in 2022) I have learnt that "works fine" is only part of
>>>> the work. Maintainability should be added as well. Even if it is
>>>> code written for one's personal use only, it may need some work
>>>> later and then it's crucial to have it maintainable.
>>>>
>>>> But maybe you think so too,
>>>
>>> I agree completely.
>>>
>>> I learned my lesson a a student with a personal project which I
>>> left for 6 months. When I came back to it I had to comment it
>>> before I could carry on.
>>
>> You will never have enough comments, even when you consider this rule
>> ;-)
>>
> 
> Probably true.
> And despite that you can very easily have too much (or too many?)
> comments.
> 
People have done some research and found that comments tend to make code 
harder to understand and maintain. Unfortunately as always I can only 
vaguely remeember reading this somewhere and can't provide any sort of 
reference.
-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#385272

On 29/05/2024 18:14, Malcolm McLean wrote:
> On 28/05/2024 12:45, Michael S wrote:
>> On Tue, 28 May 2024 12:33:02 +0200
>> Josef Möllers <josef@invalid.invalid> wrote:
>>
>>> On 27.05.24 22:18, Vir Campestris wrote:
>>>> On 27/05/2024 12:51, Josef Möllers wrote:
>>>>>
>>>>> In my 40+ years of experience in IT/programming (I graduated 1981
>>>>> from a Dutch polytechnic "HIO" in Computer Science and have
>>>>> retired in 2022) I have learnt that "works fine" is only part of
>>>>> the work. Maintainability should be added as well. Even if it is
>>>>> code written for one's personal use only, it may need some work
>>>>> later and then it's crucial to have it maintainable.
>>>>>
>>>>> But maybe you think so too,
>>>>
>>>> I agree completely.
>>>>
>>>> I learned my lesson a a student with a personal project which I
>>>> left for 6 months. When I came back to it I had to comment it
>>>> before I could carry on.
>>>
>>> You will never have enough comments, even when you consider this rule
>>> ;-)
>>>
>>
>> Probably true.
>> And despite that you can very easily have too much (or too many?)
>> comments.
>>
> People have done some research and found that comments tend to make code 
> harder to understand and maintain. Unfortunately as always I can only 
> vaguely remeember reading this somewhere and can't provide any sort of 
> reference.

Too many comments make code hard to read - too much of a good thing is 
always bad.  (That's what "too much" means.)

The key, IMHO, is not to use comments when the same thing can be 
expressed in code.  And don't use comments to repeat things that are 
obvious in the code.  If a variable needs a comment to say what it is, 
it's a sign that the variable should have a better name.  It's better to 
use an assert (static if possible) than to write a comment about the 
state of variables.  It's better to write clearer code than write 
comments about what the code is doing.

Bad comments like those are a pain for maintenance - you often have to 
double up the effort when fixing things, because you need to change the 
code /and/ the comment.  In practice, comments often get out of sync and 
then they are worse than useless.

Of course you want comments to talk about /why/ code is doing what it is 
doing, since that is usually not possible to express in the code itself.

[toc] | [prev] | [next] | [standalone]

#385287

On 29/05/2024 18:23, David Brown wrote:
> On 29/05/2024 18:14, Malcolm McLean wrote:
>> On 28/05/2024 12:45, Michael S wrote:
>>> On Tue, 28 May 2024 12:33:02 +0200
>>> Josef Möllers <josef@invalid.invalid> wrote:
>>>
>>>> On 27.05.24 22:18, Vir Campestris wrote:
>>>>> On 27/05/2024 12:51, Josef Möllers wrote:
>>>>>>
>>>>>> In my 40+ years of experience in IT/programming (I graduated 1981
>>>>>> from a Dutch polytechnic "HIO" in Computer Science and have
>>>>>> retired in 2022) I have learnt that "works fine" is only part of
>>>>>> the work. Maintainability should be added as well. Even if it is
>>>>>> code written for one's personal use only, it may need some work
>>>>>> later and then it's crucial to have it maintainable.
>>>>>>
>>>>>> But maybe you think so too,
>>>>>
>>>>> I agree completely.
>>>>>
>>>>> I learned my lesson a a student with a personal project which I
>>>>> left for 6 months. When I came back to it I had to comment it
>>>>> before I could carry on.
>>>>
>>>> You will never have enough comments, even when you consider this rule
>>>> ;-)
>>>>
>>>
>>> Probably true.
>>> And despite that you can very easily have too much (or too many?)
>>> comments.
>>>
>> People have done some research and found that comments tend to make 
>> code harder to understand and maintain. Unfortunately as always I can 
>> only vaguely remeember reading this somewhere and can't provide any 
>> sort of reference.
> 
> Too many comments make code hard to read - too much of a good thing is 
> always bad.  (That's what "too much" means.)
> 
> The key, IMHO, is not to use comments when the same thing can be 
> expressed in code.  And don't use comments to repeat things that are 
> obvious in the code.  If a variable needs a comment to say what it is, 
> it's a sign that the variable should have a better name.  It's better to 
> use an assert (static if possible) than to write a comment about the 
> state of variables.  It's better to write clearer code than write 
> comments about what the code is doing.
> 
> Bad comments like those are a pain for maintenance - you often have to 
> double up the effort when fixing things, because you need to change the 
> code /and/ the comment.  In practice, comments often get out of sync and 
> then they are worse than useless.
> 
> Of course you want comments to talk about /why/ code is doing what it is 
> doing, since that is usually not possible to express in the code itself.
> 
Currently I'm writing a lot of little test programs to show off my XML 
parser. They are of course also intended to be used as templates for 
anybody who wants to use it. But I haven't decided on a commenting 
policy. The comments are inconsistent and a bit of a mess.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#385337

Michael S <already5chosen@yahoo.com> writes:

> On Tue, 28 May 2024 12:33:02 +0200
> Josef Moellers <josef@invalid.invalid> wrote:
>
>> On 27.05.24 22:18, Vir Campestris wrote:
>>
>>> On 27/05/2024 12:51, Josef Moellers wrote:
>>>
>>>> In my 40+ years of experience in IT/programming (I graduated 1981
>>>> from a Dutch polytechnic "HIO" in Computer Science and have
>>>> retired in 2022) I have learnt that "works fine" is only part of
>>>> the work.  Maintainability should be added as well.  Even if it is
>>>> code written for one's personal use only, it may need some work
>>>> later and then it's crucial to have it maintainable.
>>>>
>>>> But maybe you think so too,
>>>
>>> I agree completely.
>>>
>>> I learned my lesson a a student with a personal project which I
>>> left for 6 months.  When I came back to it I had to comment it
>>> before I could carry on.
>>
>> You will never have enough comments, even when you consider this rule
>> ;-)
>
> Probably true.
> And despite that you can very easily have too much (or too many?)
> comments.

I realize the original remark was tongue in cheek..  still, I have
some serious responses to offer.

A more important question then whether there are enough comments is
what kind of comments are given.  It's easy to have too many of the
wrong kinds of comments.  Most of the code I have looked at that is
is commented tends to have more of the unhelpful kinds of comments
than it has more helpful kinds of comments.

Whether there are enough comments (yes I think there can be enough
comments) also depends on how the code is written.  Some code can
get by with very few comments.  At the other end of the spectrum,
some code is so awful that adding comments will probably make things
worse rather than better.  In cases like that, re-writing the code
has a higher ROI than it does to write more comments.

[toc] | [prev] | [next] | [standalone]

#387341

On Tue, 28 May 2024 14:45:09 +0300, Michael S wrote:

> And despite that you can very easily have too much (or too many?)
> comments.

My rule with comments is that they should explain *why* the code is doing 
what it’s doing, not simply repeat *what* the code is doing (which would 
be obvious to anyone who knows the language, APIs etc).

E.g.

    const ssize_t allocation_step = 10;
      /* something convenient to reduce nr of tuple resize operations */
    ...
    PyTuple_SET_ITEM(factorelt, 0, factorobj);
    PyTuple_SET_ITEM(factorelt, 1, powerobj);
    factorobj = powerobj = NULL; /* ownership has passed to factorelt */
    if (nr_used == nr_allocated)
      {
      /* need more room in result tuple */
        nr_allocated += allocation_step;
        if (_PyTuple_Resize(&tempresult, nr_allocated) != 0)
            break;
      } /*if*/

[toc] | [prev] | [next] | [standalone]

#385326

On 28/05/2024 11:33, Josef Möllers wrote:
> Let me challenge that: I'm 67 (born September 1956) 😉

I think we've given enough personal information in a public group (am I 
paranoid enough_?) but we're not far apart.

Andy

[toc] | [prev] | [next] | [standalone]

#384856

On Thu, 16 May 2024 19:27:00 +0300, Mikko wrote:

> Sometimes it is easier to make a parser than to use an existing one.
> In this case I might try LEX.

Fun fact: hand-coded lexical analyzers tend to be faster than table-driven 
ones like lex.

[toc] | [prev] | [next] | [standalone]

#384894

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 16 May 2024 19:27:00 +0300, Mikko wrote:
>
>> Sometimes it is easier to make a parser than to use an existing one.
>> In this case I might try LEX.
>
>Fun fact: hand-coded lexical analyzers tend to be faster than table-driven 
>ones like lex.

You have a warped sense of fun.

Tend to be?  Any cites?

And how often does the (I suspect very marginal) performance benefits
of a hand-coded lexical analyzer surpass the development/testing cost of using
a well-tested lexical analyzer generated by lex or flex, both of which
are rather efficient?

[toc] | [prev] | [next] | [standalone]

#384911

On 23/05/2024 18:14, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Thu, 16 May 2024 19:27:00 +0300, Mikko wrote:
>>
>>> Sometimes it is easier to make a parser than to use an existing one.
>>> In this case I might try LEX.
>>
>> Fun fact: hand-coded lexical analyzers tend to be faster than table-driven
>> ones like lex.
> 
> You have a warped sense of fun.
> 
> Tend to be?  Any cites?
> 
> And how often does the (I suspect very marginal) performance benefits
> of a hand-coded lexical analyzer surpass the development/testing cost of using
> a well-tested lexical analyzer generated by lex or flex, both of which
> are rather efficient?
 >
I"m currently adding xpath suppport to my XML document model.
The code is here

https://github.com/MalcolmMcLean/babyxrc/blob/topic/dataimport/src/xpath.c

(Baby X resource compilier, branch topic/dataimport, file xpath.c.)

It has a hand-coded lexical analyser. Now could the code be made better 
by moving to lex / flex?

I'm working on the code so it is currently in flux. But github stores a 
list of changes.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web