Off-Topic > Off-Topic - Tiny Tux's Corner
(m|s|p) locate / sql ("db") vs grep / awk ("db.txt")
mocore:
--- Quote from: mocore on November 30, 2024, 03:01:50 AM ---
--- Quote from: nick65go on November 17, 2024, 08:30:59 AM --- My understanding is that curaga had prefered not-compiled solutions (if I remember correctly).
--- End quote ---
i wander for what reasons this might be?! ???
--- End quote ---
idk perhaps some part of the answer might be
to do with decide-ability
https://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html
yvs:
>> prefered not-compiled solutions
> wander for what reasons this might be?!
>
if script execution time for some particular daily task is negligible, what could be a practical reason to use compiled solutions ...
mocore:
--- Quote from: yvs on December 26, 2024, 04:34:12 AM --->> prefered not-compiled solutions
> wander for what reasons this might be?!
>
if script execution time for some particular daily task is negligible, what could be a practical reason to use compiled solutions ...
--- End quote ---
certainly an interesting question
attempting to articulate a coherent reply i happened to read
"Julia is not an interpreted Language" @ https://github.com/ninjaaron/administrative-scripting-with-julia/issues/7
--- Quote ---Compilation matters, but not nearly as much as language semantics.
--- End quote ---
the discussion of definitions and related terms
and distinction between interpreted / complied
suggest each case to have its much of its own nuance
+ related
"A read–eval–print loop (REPL)" https://forum.tinycorelinux.net/index.php/topic,26193.0.html
see also : “Software is getting slower more rapidly than hardware becomes faster” https://forum.tinycorelinux.net/index.php/topic,26683.msg171907.html#msg171907
Rich:
Hi yvs
--- Quote from: nick65go on November 17, 2024, 08:30:59 AM --- ... My understanding is that curaga had prefered not-compiled solutions (if I remember correctly). ...
--- End quote ---
I won't speak for curaga, but I can give a few reasons for this.
Transparency: The source code is the executable so it is present in
the environment it runs in. It can be examined if someone wants
to see what it's doing or how it's doing it.
I have personally learned a lot by examining the scripts roberts
created and observing how he accomplished various tasks.
Participation: A result of "Transparency" is accessibility. Anyone with
an editor can offer bug fixes or enhancements. No toolchain required.
It's as easy as:
1. Edit.
2. Save.
3. Run.
4. Repeat steps 1-3 until satisfied with the results.
Size: "Small" compiled programs (C) tend to have a minimum achievable
size when compiled. In TC10-x86 the size of waitforX is 1932 bytes. It's
about a dozen lines of code and mostly sleeps waiting for a display to be
created. With each new compiler version, the "minimum achievable size"
seems to increase. The linker scripts seem to add more padding too.
More info on gcc and program size:
https://forum.tinycorelinux.net/index.php/topic,23134.msg144804.html#msg144804
A shell script is the size of the text it is written in, always.
I'm sure there are other reasons, these are just the ones that came to mind.
yvs:
Hi Rich,
> I'm sure there are other reasons, these are just the ones that came to mind.
> list of reasonable reasons
There's another one possible reason that sometimes forgotten: practical.
For example in scopes of this topic:
Let's say my goal is to find a package that provides a _file_. Note: not fullname, nor directoryname, just a basename. (I suppose it's the most common case).
Because I'm not interested in names that a part of directory trees, then format could be very simple "packagename flat-list-of-basenames" per line.
sed'ing time for /basename/ through text with so simple format is negligible, in my case it was much faster than I type 'sed' word.
In this case I'd not bother to think of databases at all. I.e. there was no need in a real db, and sed was more than fast for this particular practical task.
Navigation
[0] Message Index
[*] Previous page
Go to full version