<razzy>
i said "feels half broken" i meant "i do not understood all the syntax and inner working"
<razzy>
why do picolisp has classes? should not it be achieavable by lists and "macros?"
<Regenaxer>
A very broad question
<Regenaxer>
Lists and macros don't support polymorphism and inheritance
<razzy>
i mean easier achievable by lists and some "macros"?
<Regenaxer>
Classes are symbols, with the methods in a list
<Regenaxer>
Macros are not in PicoLisp
<Regenaxer>
only read macros
<razzy>
i know, by "macros" i meant on the fly code generation in picolisp similiar to code generation by macros in common lisp
<Regenaxer>
on the fly are read macros
<beneroth>
Hi Regenaxer !
<Regenaxer>
and CL macros are replaced in a much better way with FEXPRs
<razzy>
Regenaxer: imho are macros in common lisp done in compile time
<razzy>
pre execution
<Regenaxer>
yes
<Regenaxer>
read macros too
<Regenaxer>
The reader is the "compiler" of pil code in some way
<razzy>
picolisp could generate code that feels like macro on the fly
<razzy>
not that efficient tho
<beneroth>
razzy, in my experience, after a certain complexity the custom-list-type (e.g. data format is a list with specific data at specific index) is becoming intransparent, using a symbol/object with named properties is nicer and flexibler, and simpler, at that point.
<beneroth>
razzy, in picolisp you can write custom interpreters with FEXPR, more powerful than macro in principle
<razzy>
beneroth: you could use list pairs with names (colour . black)
<razzy>
beneroth: in general i agree
<razzy>
but i cannot imagine picolisp classes in bigger complexity job
<beneroth>
because you cannot imagine classes in general in bigger complexity job? or because of some aspect of picolisp classes?
<razzy>
beneroth: i can imagine some big tables of classes with special user (excel-like) interface. i can think that there it could be beneficial
<Regenaxer>
pairs with names (colour . black) are indeed equivalent. Properties in pil are in fact implemented like this, but they are easier to use
<Regenaxer>
properties are (black . colour) though
<Regenaxer>
key/value reversed
<Regenaxer>
but that's transparent to put/get
<beneroth>
T
<beneroth>
razzy, excel-like spreadsheet application lend themselves very well to OOP. the only concern would be to chose which data are in which class/object properly (software design), e.g. not filling ram with hundred thousands mostly empty/similar objects for the table cells but using techniques like the flyweight pattern https://en.wikipedia.org/wiki/Flyweight_pattern
<beneroth>
actually I cannot imagine a non-OOP architecture for a complexer spreadsheet application to be simple and maintainable.
<razzy>
beneroth: all i am saying that with special graphical interface could special OOP classes reduce load for programmer in large complexity problems
<beneroth>
OOP was basically invented to make graphical interfaces
<beneroth>
but granted, there is a lot of OOP dumbness around and bad implementations of OOP.
<beneroth>
and the inherent risk is to spread out the code/logic too much, where in non-OOP it might be placed more in a central place. on the other hand, this central place tends to become so cluttered that it's not manageable anymore.
<beneroth>
there is no golden formula to protect yourself from stupid software design and/or bad programmers.
<razzy>
beneroth: i agree with you. picolisp classes seem half way from non-oop to graphical usefull oop. but i avoid oop where i can
<razzy>
and did not done any graphical interface :]
<beneroth>
picolisp OOP is rather special compared to most OOP implementations. For one it does not limit the programmers access to the inner workings of classes. And it has the most elegant solution to multiple inheritance.
<beneroth>
which is very simple and absolutely natural in hindsight, but in all OOP languages I know multi-inheritance is solved with weird crutches or partly to fully forbidden (while not really solving the risk/problems that can occur with it)
<beneroth>
but yeah, most likely picolisps approach to that comes from its interpreted nature, in this context it makes much sense while its not so obvious in compiled languages.
<razzy>
picolisp OOP might be best in the buisiness. but still seems half way to usefullness for me
<razzy>
human brains are not prepared for compiled languages :]
<razzy>
imho
<beneroth>
well to program with many human-drones as it is done in big enterprise, meaning dozens or even hundreds of programmers on the same project, the "limit control/access to the programmer"-aspect of the mainstream languages (Java, C#, Go?, ..) is absolutely essential.
<razzy>
beneroth: T. imho the many-human-drones aproach to programming is inefficient :]
<razzy>
really hard to manage right
<beneroth>
sorry, slight nitpick: it's surely ineffective (not good in producing results), but prolly efficient (economical, costs are in a balance for the gains) - 1. there are less good programmers than code-monkeys 2. many companies have a hard time to recruit and keep good programmers, because of their culture, because of the work, because having many bad managers. 3. so for them, working with code-monkeys and getting some minimal output is better than not gettin
<beneroth>
g any output
<beneroth>
so from a business perspective, I can understand that approach and find it legitimate. from a technical/hacker perspective its pure insanity :)
<beneroth>
and of course this is usually not a consciousness decision by those companies.
<beneroth>
good programmers are also pretty hard to manage right. well, you should give them the task and let them work and remove all obstacles which keep them from working... but that's pretty hard for managers who like to work on their career and be at least a bit active in the political game which rule their career xD
<beneroth>
and as with programmers, it's hard to find good managers.
<beneroth>
picolisp is tailored to good programmers.
<Regenaxer>
Good explanation
<beneroth>
thx
<beneroth>
mainstream languages are tailored/evolved towards bad programmers, they give some lower limit to productivity and risks, but do this with restrictions which also set an upper limit to power and productivity for a well-skilled programmer
<beneroth>
and while the bad programmers are mostly not aware of those limits, the well-skilled programmers recognizes them and is frustrated by them.
<beneroth>
a tiny sub-group of those go searching for alternatives and end up here :P
orivej has joined #picolisp
<razzy>
:D aaah, not at all self centered :]
<beneroth>
no, not at all. also, very humble and no inch of arrogance :)
<razzy>
#its-not-arrogance-if-it-is-true
<beneroth>
#its-still-arrogance
<beneroth>
for me this is the big difference between arrogance and delusion