freemint has quit [Remote host closed the connection]
freemint has joined #picolisp
ubLIX has quit [Quit: ubLIX]
freemint has quit [Ping timeout: 250 seconds]
freemint has joined #picolisp
freemint has quit [Ping timeout: 250 seconds]
_whitelogger has joined #picolisp
Nistur has quit [Ping timeout: 248 seconds]
Nistur has joined #picolisp
_whitelogger has joined #picolisp
_whitelogger has joined #picolisp
orivej has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
<beneroth>
tankf33der, I don't the point of the comment, as it stresses your point (picolisp is faster) :D
<beneroth>
I don't *understand the point of the comment
<beneroth>
Good morning Regenaxer :)
<Regenaxer>
Good morning beneroth!
<Regenaxer>
The comment interpretation vs. compilation?
ubLIX has joined #picolisp
<beneroth>
T
<beneroth>
the example posted in the comment is an interpreter (as far as I understand), and its much slower than picolisps load :)
xkapastel has joined #picolisp
<Regenaxer>
Ah
<beneroth>
the idea of this benchmark of the V lang guy is of course not very meaningful
<beneroth>
in the end only practical performance makes a real difference for the user experience and the efficient use of the software (and that should be the goal of software, to be useful)
<beneroth>
as you always said
<beneroth>
I haven't yet seen a fast java or c# program. too many turtles involved.
<beneroth>
and I feel that in general the user-experienced-performance of applications went down in recent years
<Regenaxer>
Yeah
<beneroth>
"software is getting slower more rapidly than hardware is becoming faster." Wirth's law
<Regenaxer>
haha, yes
<tankf33der>
beneroth: vlang cant compile more than 50K statements.
<beneroth>
damn tankf33der, your vlang thread made me create a reddit account
<tankf33der>
LOL
<freemint>
beneroth It is the difference between cooking at home and going to a fast food chain restaurant. Both is food but how it is made, how fresh it is and how much it cost humanity to make it is different.
<beneroth>
freemint, that is the difference between compilation or direct interpreting? how so?
<beneroth>
your analogy sounds more like "writing your own software" vs. "pull docker image"
orivej has quit [Ping timeout: 272 seconds]
<freemint>
Yes that is the difference between direct interpreting and compiling.
<freemint>
It is the difference between interpreting and compiling. Both getting executable code in to memory but how it is made, how long since it was translated from the source and how efficient it is when executing the same code over and over is different.
<freemint>
Home cooking can't exist without fresh ingridients. => You can't execute interpreted code without the source.
<freemint>
Chain restaurants are more economical (unless the chain restaurant is run really badly) => If you execute your code often enough you can save computation time by compiling (unless your compiler is stupid).
<freemint>
I think the analogy works really well.
<beneroth>
hmm.. so "fresh code" in this context would mean "code as it was at the source, without modifications of pre-/post-compilers etc."
<beneroth>
agreed
<Regenaxer>
The question is whether pil's read mechanism is called compiling or not
<beneroth>
though I think we picolispers do also argue that direct interpretation is quicker than compiling, so I'm not sure if the analogy fully works
<Regenaxer>
T
<Regenaxer>
In the Forth world this read is called compiling, in the Lisp world it isn't (there it is called "reading")
<beneroth>
Regenaxer, I think that question gets a clear NO. but we take the point of the vlang benchmark (not really a good one?) as being "preparation time" from code to execution
<Regenaxer>
But 'read' factually does a kind of compilation
<Regenaxer>
yes, preparation time is another issue
<Regenaxer>
A pil web app uses this all the time
<Regenaxer>
reading text
<beneroth>
I think the Forth usage of the word in the general (CS) sense is wrong, though it might of course be used as a forth-specific terminus.
<beneroth>
T
<Regenaxer>
I think both what Forth and 'read' does is a compilation
<Regenaxer>
Like bytecode compilers do too
<Regenaxer>
Forth and Lisp have word-code compilers
<beneroth>
compile: From Middle English compilen, from Old French compiler, from Latin compīlō (“heap, plunder”, verb). 1. (transitive) To put together; to assemble; to make by gathering things from various sources. 2. (obsolete) To construct, build. 3. (transitive, programming) To use a compiler to process source code and produce executable code.
<beneroth>
I argue that this usage (anmd also Forths usage of "compiling") is wrong, as no "put together, assembling, to make by gathering things from various sources" is involved
<Regenaxer>
You *can* further compile bytes or pointers to machine code
<beneroth>
yes, but normally this is not done
<Regenaxer>
It is often done
<Regenaxer>
JIT
<Regenaxer>
in Java
<beneroth>
hm.. T
<Regenaxer>
In Forth interpretation is direct execution of the command line
<Regenaxer>
In Lisp it is always first compiled
<Regenaxer>
also in the REPL
<Regenaxer>
Fort executes each word from left to right
<Regenaxer>
it is true interpretation
<beneroth>
I think one has to differ between "compiling" to really mean "from source to execution" (as Forth does, and we do in this Vlang benchmark), or "producing machine code from some input"
<Regenaxer>
If you write : foo ... ; it compiles
<beneroth>
you just said it interprets?
<Regenaxer>
No, compilation does *not* mean machine code
<Regenaxer>
Fort interprets
<Regenaxer>
dup + .
<Regenaxer>
but
<Regenaxer>
: foo dup + . ;
<Regenaxer>
compiles foo
<Regenaxer>
Compilation in CS is not tied closely to the original English meaning
<Regenaxer>
It means transform a program from one representation to another
<Regenaxer>
The internal pointer structures are completely different from the original text form
<Regenaxer>
character array to a tree
<Regenaxer>
For example the original Basic was a true interpreter
xkapastel has joined #picolisp
<Regenaxer>
Probably Bash too
<Regenaxer>
But Lisp 'read' is a form of compilation
<Regenaxer>
Surely it is no interpretation
<Regenaxer>
Later, the result of 'read' is interpreted
<Regenaxer>
But interpretation is everything
<Regenaxer>
also the machine code, it is interpreted by microcode
<beneroth>
you are right
<Regenaxer>
A traditional C compiler compiles from one text form to another
<Regenaxer>
C code to Asm
<Regenaxer>
Then Asm is assembled
* beneroth
wanted to counter with "but the word transpile". fail. transpile: "Shortening of transcompile."
<Regenaxer>
then the modules are linked
<Regenaxer>
yes, good word!
<beneroth>
T
<beneroth>
so your point is: (load) is compilation, the vlang commentor is technically wrong? :)
<Regenaxer>
Not wrong, the terms are not used uniformly
<beneroth>
you should update the FAQ and the website. we have a compiler (the parser), and picolisp advertises as "fastest compiler" :D
<Regenaxer>
I said yesterday that I expected such comment
<beneroth>
yeah, of course. that comment was to be expected, no surprise.
<Regenaxer>
Well, I sticked to the Lisp usage
<Regenaxer>
There we have 'read'
<Regenaxer>
and compiled *Lisp* is something different
<Regenaxer>
But outside the Lisp world it is different :)
<beneroth>
funny is then, that the commentator who brought this up, boasted about the lisp they use which does both compiling and interpretation, someone asks for the benefits of interpretation :)
<Regenaxer>
Yeah, it is a confusing issue
<beneroth>
Regenaxer, is in your world view the common lisp community part of the lisp world? :P
<Regenaxer>
Yes, CL is Lisp
<beneroth>
yeah I took it then as a good point to advertise pil :P
<Regenaxer>
CL is very Lispy. Scheme and Clojure are questionable
<beneroth>
how are FEXPRs more problematic than macros beside when creating a compiler?
<Regenaxer>
NewLisp is not a lisp as I understand it
<beneroth>
NewLisp is like new social economy xD
<Regenaxer>
FEXPRs are problematic *only* when compiling
<beneroth>
(to normal social economy)
<beneroth>
yes, that is my understanding
<Regenaxer>
It is a broader issue
<Regenaxer>
ie dynamic vs static
<Regenaxer>
Same with the heavy use of 'load' in pil, eg in web app
<Regenaxer>
CL would not encourage this
<Regenaxer>
as each page would be compiled again and again
<Regenaxer>
(compiled in the Lisp sense ;)
<beneroth>
well in picolisp everything gets compiled again and again
<beneroth>
but the compiler is so fast that this is ok :)
<beneroth>
right?
<Regenaxer>
yes, exactly
<Regenaxer>
It is compiled, executed, and gc'd
<Regenaxer>
In Lisp terms: 'read' and 'eval'd
<freemint>
beneroth, it is ok only when your application does not suffer. Since compilation often comes with optimization there are some places where PicoLisp would not be an ok language.
<freemint>
For webserver it is good enough.
<beneroth>
for what do you find it unsuitable, beside big number crunching?
<beneroth>
I don't disagree with you.
<beneroth>
but that's the general point people love to overlook: use the right tool. what the right tool is, depends on the task and ones existing capabilities.
<Regenaxer>
There are surely "some places", but if speed is a matter you can get very far with 'native' call
<Regenaxer>
s
<Regenaxer>
beneroth, exactly
<beneroth>
in picolisps case, the critical part lies more in the capabilities and situation of the user than the task, I think.
<Regenaxer>
For complex applications it is never wise to write a monolithic system in a single language
<Regenaxer>
Not wise, and even impossible
<Regenaxer>
At least system calls go down to C
<Regenaxer>
or asm
<Regenaxer>
And on the top is some shell
<beneroth>
hm... it's not wise to write complex applications. I'm not so sure about the monolithic system, I believe a well-designed monolithic system can reap benefits a less coupled system cannot (because of the lack of global knowledge in the system).
<freemint>
- big number crunching
<freemint>
- real time applications
<freemint>
- low memory applications
<freemint>
- writing kernels for operating systems/talking to device driver
<Regenaxer>
real time is not an issue of the language, but of the whole system
<Regenaxer>
All other points have been done in Pil
<Regenaxer>
mini for embedded, or PilOS for the kernel
<freemint>
This statement is unfair towards languages which make sacrefices to run in real time. Like the languages used in PLCs.
<Regenaxer>
bignum might be not the fastest in pil though
<freemint>
- low latency
<Regenaxer>
First of all real time is a matter of interrupt latency
<freemint>
not only
<freemint>
There are languages where you can predict the execution time on some special piece of hardware exactly. This requires performance tradeoffs in hardware and really thight restrictions in the laguage.
<freemint>
Also you can not have any code that "allocates" (like picolisp does from it's pool of cells) in space or aero applications in the US by law.
<Regenaxer>
OK
<beneroth>
yeah, either pre-allocate and change picolisp insofar as no new allocations can be made
<beneroth>
or...
<beneroth>
probably Regenaxers answer would be... use Forth? :D
<Regenaxer>
hehe, no :)
<beneroth>
what would you use for embedded?
<freemint>
Also i would not want PicoLisp on a hard disk controller.
<Regenaxer>
Yes, Forth excells at embedded small systems
<beneroth>
because?
<Regenaxer>
I would use Pil for everything, but write proper primitives
<beneroth>
T
<Regenaxer>
(unless the system is very small, 2 or 8 KiB)
<Regenaxer>
For 8 KiB Forth is ideal
<Regenaxer>
Such a Forth packs interpreter, compiler, debugger, editor, multitasker and I/O into 8 KiB
<freemint>
because the system is really small. The if the control loop can run faster we can get better performance from the hardware. These things are deployed millions of times. There is no space and no time for following pointers. Also you really do not want hard disk controller to reboot. Also the operate on really, really wide words. If you do not have the time to follow pointers you are not running PicoLisp. Also lots of accesses in
<freemint>
caches and Array manipulation never was a strong point of picolisp.
<Regenaxer>
"Following pointers" can however result in a significantly smaller and thus more efficient system (i.e. in Forth)
<freemint>
Also PicoLisp would not run so well on GPU because lock step execution of following cell pointers is really hard when caching is involved
<Regenaxer>
Speed is not always the main issue
<freemint>
True
<Regenaxer>
And if truely dynamic behavior is needed, Lisp tay make a lot of sense
<freemint>
You can use PicoLisp if speed does not matter that much or if you got enough hardware resources or if the hardware you run is good for LISP
<freemint>
The problem is: We are horrible at understand truely dynamic behavior and want to get rid of in engineering if possible :)
<beneroth>
there is embedded C#. I doubt that it is much faster than picolisp.
<beneroth>
freemint, if your statement would be true, then "software engineering" fails heavily (well, it does!)
<freemint>
I think software engineering is mostly a misomer
<beneroth>
the point of picolisp is: programmer controlled dynamic behavior, instead of black box dynamic behavior of some third party library.
<beneroth>
freemint, agreed.
<beneroth>
well it is not a minsomer, it is a euphenism. always was.
<Regenaxer>
Think or a Mars explorer which must change behavior in many unforseeable ways
<beneroth>
*euphemism
<beneroth>
Regenaxer, yeah or when they fixed hubble by controlled shaking xD
<Regenaxer>
T
<beneroth>
its a scale
<Regenaxer>
Flexibility gets more and more important
<beneroth>
the power of software is, that it is dynamic electronics
<Regenaxer>
good point
<beneroth>
for pure reliability and performance, you do it in hardware.
<beneroth>
within software, picolisp is on the more dynamic side.
<freemint>
I do not know embedded C# so i can make no statement. "Embedded" ranges from ATMs to "Schaltnetzteilen". I am sure there is space for PicoLisp and C# there. But i do not want PicoLisp in my "Schaltnetzteilen", PLCs or hard disk contollers. These systems should be as predicatable as possible.
<freemint>
Anyway PicoLisp is really great and really self consistent language.
<Regenaxer>
These are primitive systems
<beneroth>
picolisp is fully predictable.
<Regenaxer>
better in hardware or asm
<beneroth>
and most of them are already running on a linux pretending to be hardware, probably :(
<freemint>
Regenaxer, that is what i am saying
<Regenaxer>
I said that too
<beneroth>
pil asm :)
<Regenaxer>
write primitives in pil
<Regenaxer>
yep
<Regenaxer>
For clear, simple things have a built-in pil function
<Regenaxer>
Then you can be powerful and flexible on the application logic level
<freemint>
But sometimes there is no point in "being called from pil" when your "main loop" has into be assembler.
<Regenaxer>
Then the whole system is primitive
<Regenaxer>
no reason to worry
<freemint>
If i have enough headway i think i use PicoLisp but i do not always have that.
<freemint>
(am not always going to have that)
<Regenaxer>
right
<Regenaxer>
The point is that pil is vertical
<beneroth>
picolisp is also not suitable for code monkey programming
<Regenaxer>
You control all levels
<Regenaxer>
yep
<beneroth>
picolisp is meant to automate code monkey programming away :)
<freemint>
Oh another reason not to use PicoLisp: - Your depend on a proprietary compiler to be able run you code on piece of hardware, which you can not replace because you violate some (power, platine space, money) target
<freemint>
This is basically FPGA development
<beneroth>
that is not a reason not to use picolisp
<beneroth>
that is just inability
<Regenaxer>
freemint: why "proprietary"?
<beneroth>
also: port the pil vm to that compiler, solved
<beneroth>
Regenaxer, because he uses a proprietary FPGA. it's about the FPGA, not pil.
<Regenaxer>
There is even no "compiler"
<beneroth>
I misread too, at first
<Regenaxer>
Didn't see anything with FPGA :)
<freemint>
Oh and rewriting the compiler is >1000 man years and detailed knowledge of intelectual property of the design of the FPGA.
<freemint>
Yeah PicoLisp is great
<beneroth>
really, a FPGA that requires so much detailed knowledge, really?
<freemint>
yes because there is no ISA for FPGAs
<beneroth>
I mean, I believe it for the intel x86, which is a big ball of legacy dragged along, but FPGAs are that shit?
<beneroth>
ISA?
<freemint>
Instruction set architecture
<freemint>
There is no X86
<beneroth>
yes, I mean, that is the whole point of a FPGA, no?
<freemint>
Each chip/chip-family has different binary format to specify how the cross switches connect stuff
<beneroth>
I wonder why it then should require 1000 manyears
<freemint>
Because place and route is a really hard problem
<beneroth>
and there is no meaningful FOSS ?
<beneroth>
FOSS chop
<beneroth>
chip
<freemint>
Not really, slowly growing. There is no FOSS chip but some free compilers
<freemint>
mostly free of charge and they will not compile for more expensive chips.
<freemint>
Because you have to consider magnetic/electric field effects
<beneroth>
ok, so FPGA chips are more closed than normal CPUs (e.g. Risc-V)
<beneroth>
didn't know that
<freemint>
Yes
<freemint>
I story i heard from someone yesterday:
<beneroth>
will you change that? :)
<freemint>
i also dont know if the 7k160t would have enough gate capacity, i might have to go to the 7k325t at which point someone needs to shell out ~3 kUSD for a full vivado license
<freemint>
because no longer compatible w/ the free compilers
<freemint>
that would bump the chip cost from $386 to $1450
<beneroth>
well that is the freemium model, like in mobile apps :)
<beneroth>
how ironic how the best hope for such hardware is probably the chinese gov.
<freemint>
??
<freemint>
FPGAs are really closed down. There are some attempts at open tool chains but they are not competitive (the same logic needs way more transistors, you can't clock it as fast) and only support a few targets (Mostly really low-end ones).
<beneroth>
and the groups able to change this, don't, because they're able to do their custom chip design anyway and don't have much use for a opened up FPGA tool chain?
<freemint>
Also there were attempts to design an open source/open hard ware FPGA, but they never got past the running on a proprietory FPGA stage. The hurdle to get silicon produced are also really high (it takes serious money even on the same really outdated transistor size the intel 8080 was produced).
<freemint>
Also industries keeps it down where it has the chance. Or atleast all that is my impression
<beneroth>
yeah, of course.
<beneroth>
thanks for the interesting insights.
<beneroth>
btw. unrelated, does anyone know any (still) good software by mozilla?
<Regenaxer>
no idea :)
<beneroth>
now they have auto-updates even with forced restart in firefox
<Regenaxer>
uh
<freemint>
Also fun note: The latest high end FPGA has 3x-5x more transistors than a GPU.
<beneroth>
thunderbird is not as much sucking as firefox (because they didn't do much on it the last 10 years), but it all the same is all in all pretty bad, and sucks.
<beneroth>
freemint, and the lowest end FPGA ?
<Regenaxer>
What FPGA does Geo use for PilMCU?
<beneroth>
we should ask you that, not the other way around, Regenaxer :)
<Regenaxer>
I don't know :) Geo selected it
<beneroth>
yeah, we should ask him on ML
<Regenaxer>
And I rarely use ff
<freemint>
I like the new firefox
<Regenaxer>
first w3m, then PilBox
<beneroth>
I really have to write my proxy solution for browsing
<beneroth>
freemint, I still hate them for destroying all plugins. including plugins which were native functionality ones. firefox became big just because of the plugins.
<freemint>
Actually yes and no.
<beneroth>
and as far as I understood the reasons for that: security improvements (good reason, though why was it insecure before...) and sucking up to google (as they do in like everything these days)
<freemint>
I hate that down them all is gone but now the same plugins work on desktop and mobile seemslessly.
<beneroth>
well, why are firefox and firefox mobile different?
<beneroth>
and firefox mobile always sucked
<beneroth>
still does
<freemint>
I do think so.
<beneroth>
regularly forgets open tabs with an update.
<freemint>
Really?
<beneroth>
yes, I have the issue often.
<freemint>
Also they will reimplement the necessary APIs slowly again. I think they should have had an API ready that offered all the features the previous API had.
<freemint>
But i think it is good XUL is gone.
<beneroth>
yes? how could one even think different
<beneroth>
about compatibility. I don't know what XUL is.
<beneroth>
and I still hate them for kicking out tab-groups (once a native functionality)
<freemint>
XUL is the firefox specific language that was used to design firefox guis
<beneroth>
no money to clean the codebase and properly maintain it, but enough money to do third party bullshit (pocket etc), maliciously install plugins on peoples computers (Mr. Robot easter egg) and do hipster media bs
<beneroth>
too much money
<freemint>
I think you are to opinionated about this
<beneroth>
well the totally broke my way of working, for no good reason as far as I can see, yes I am opinionated.
<beneroth>
the other important function they would have is to oppose monopoly in the web. they won against MS. now they don't fight against Google.
<freemint>
Mozilla tools i like: Rust, Bugzilla, Firefox send, Firefox Klar.
<freemint>
Mozilla tools i do not want to miss: Thunderbird, Firefox Android, Firefox
iuno has quit [Quit: Leaving]
<freemint>
beneroth i agree that the people in responsile seem to have to much free time (Mr. Robot). But if it keeps people happy doing the non fun part of bbuilding a decent browser i am happy with it.
<beneroth>
the problem was not the cool easter egg, the problem was that they installed it automatically on peoples computers, and even their kept it hidden in the list of installed plugins. that is violation of trust and an abuse of update channel.
<beneroth>
apart from that I agree with you, though I find they don't do enough in the (maybe non-fun) parts.
<beneroth>
the sync functionality was never finished to fully support self-hosted servers. and then they removed self-hosting capability. why?
<beneroth>
and remade the whole sync in another lame attempt to make money.
orivej has quit [Ping timeout: 272 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
<beneroth>
it pisses me off that they claim to work for user control, individualism and a free & open web - but they don't in my opinion.
<beneroth>
not anymore.
<beneroth>
not for a long time.
<beneroth>
wouldn't piss me off so much if they would stop doing these claims.
orivej has joined #picolisp
beneroth has quit [Quit: Leaving]
ubLIX has joined #picolisp
xkapastel has joined #picolisp
_whitelogger has joined #picolisp
_whitelogger_ has joined #picolisp
_whitelogger_ has joined #picolisp
_whitelogger__ has joined #picolisp
_whitelogger__ has joined #picolisp
_whitelogger__ has joined #picolisp
_whitelogger___ has joined #picolisp
_whitelogger___ has joined #picolisp
_whitelogger___ has joined #picolisp
_whitelogger___ has joined #picolisp
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has quit [Remote host closed the connection]