Re: Baby X is bor nagain

On 18/06/2024 18:38, bart wrote:

On 18/06/2024 17:11, David Brown wrote:

On 18/06/2024 15:48, bart wrote:

 

I haven't tried it directly in C (I don't have a C 'readfile's to hand); I tried it in my language on a 100MB test input of 15M random numbers ranging up to one million.

>
No one is interested in that - that was not part of the task.

 You're arguing in favour of a high level scripting language for task rather than a lower level one which you claim involves a lot of 'faffing' around.
 

Yes - for cases like the ones we've been looking at recently where Python code is vastly simpler and faster to write, and easier to get correct, and where the speed is fine for realistic use-cases.
No one has suggested that Python is faster to /run/ than reasonable C code - the point is that where Python runs more than as fast as you need, going faster is of no benefit.  But being faster to develop /is/ a benefit.

I tried it using mine (C would have taken 10 minutes longer), and found it wasn't actually that hard, especially if you have some ready-made routines lying around.

You are already far beyond the time it takes to write such code in Python.  And anything in your language is irrelevant to everyone except you.

 Plus it was a magnitude faster. Plus I showed how it could be run without a discrete build step just like Python (Tcc has that feature for C).
 So for this example, there wasn't a lot in it, while the low-level could was shown to be faster without trying too hard.
 For a throwaway program that is only run once you probably would use the nearest scripting language; its extra runtime (5 seconds for my example) is shorter than the next extra coding time.
 But that's not why you might use C.
 

I agree.  That's the point - use C when C is the best choice, use a higher level language when /that/ is the best choice.

 

>
With a more arbitrary input format, this would be the kind of job that a compiler's lexer does. But nobody seriously writes lexers in Python.

>
Yes, people do.  (Look up the PLY project, for example.)  Nobody seriously writes lexers in C these days.  They use Python or another high level language during development, prototyping and experimentation, and if the language takes off as a realistic general-purpose language, they either write the lexer and the rest of the tools in the new language itself, or they use C++.

 I'm not talking about experimentation.
 Actually I'm starting to wonder whether you use C much at all, and why.

I use C for embedded systems where C is the right (or only!) choice.  I also use C++ on such systems when that is the right choice.

 You come across as a Python and C++ 'fan-boy'.

I'm a fan of picking the best available tool for the job.  For something involving manipulating text, strings, and file data on a PC, that is rarely C.
Unless, of course, you are doing stuff in C for the fun of it, in which case C is clearly the right choice!