Re: Functions as first-class objects

["szbnwer@..." <szbnwer@...>]

Il giorno sab 8 set 2018 alle ore 15:54 Alejandro Reimondo
<aleReimondo@smalltalking.net> ha scritto:
>
>
>  >- the "source" you gave is not really like a source but its more
>  >likely something like a serialization, that is only "source" in quotes
>  >for me cuz its not really human readable,
>
> In in conventional computing paradigm, the source is the
>   most important product of programmer efforts.
> As the person is outside of the system (because the system will run
>   somewhere else, in another time, "in the future")
>   the system is not relevant and the only you have/need is "the
>   specification" of it.
> The specification is secure and has the beauty of a
>   non-living/abstract artifact.
> The source/specification defines a closed/ideal system.
>
> If you change a line, it will define ANOTHER system; with no
>   relation with the preceding system in terms of sustainability
>   of the real system (the system that will be instantiated in
>   the future when started).
>
> In an open object system, the system runs when you are using it.
> If the system "do nothing" it already exists (the porpouse it is sole
> sustainability through time).
> It is not something running to produce output for you (nor for any user)...
>   you can collect some fruits... but the system is not there
>   for an user, nor to "compute" something for a human been.
>
> Each object can change as concecuence the action/impact of another
>   person/object through sending/receiving/understanding messages
>   (the understanding directs the change).
> Each object has a language defined by what messages are
>   understood by the object.
> The language for each object can change... in an instant
> In this kind of (open) systems the language change.
> The main difference between an object and a component
>   (an artifact of object oriented architectures) is:
> -component: is something with an API that defines the way to communicate
> with it.
> -object: is something (when you send a message it will impact and the
> concecuences
>   can change from the time you send the message the first time and a
> second time).
>
> Object systems are not secure, but sustainable.
> Some systems has been changing/evolving for decades.
>
> The system can contain more than one compilers (or other tools to
>   instantiate behavior), and other tools to survive while
>   potentially "all" can change.
>
> The source is not relevant; and there are situations where you understand
>   what is happening seen it happen (by the observation of emergent
>   behavior).
> In the first stages of learning smalltalk systems containing specific
>   domain models, it is frequent/reccomended to use visual
>   representations (GUI) of the objects to understand the
>   system; and from the most interesting points of the system
>   you start reading source (when you have the intention to
>   change something).
>
> Object systems are "moving"/working while you learn; and you
>   learn from active media; not only from reading texts or drawings.
> Browsing, inspecting and evaluating expressions is the way to
>   understand how/what/why it is working... while it is working.
>
> It you break something it can happen that the system survive your
> actions or not.
> In case of still working, repairing the system is an effective way to learn.
>
>  > i need to run it first to get an idea what i actually have,
>
> Yes, you use computer to see while learning; not only texts
>   to imagine what will happen when it will run.
> When you read a text, you do not have more than
>   what is in your mind/imagination.
> The problem with imagination is it can't be shared in a concrete
>   support (must be abstracted, loosing information value)
>
>  > while my stuff is 100% handwritten code. except what i am working
>  > on ~currently, some serialized data that have no functions,
>  > userdata and threads, but everything else is
>  > in a kinda pretty form.
>
> Today, you can have more than words stored in a file (text in a page of
> a book).

sure! but u misunderstood my point :D (no problem :) )

so i already understood these, but what i wanted to say is that the
initial trust for a newcomer comes from readability before running
anything at all. this is a very much important point for most of the
linux users (not only), just like for me. if i wanna achieve the trust
of anyone, then id like to share pure source codes, not a system image
that could even cause any harm for the host. (RMS have the opinion
that even a minified js is a proprietary sw, and i mostly have to
agree with that.) so this is only the domain of cybersecurity and
trust. i could even trust in a disassembled binary, but that is a hard
work to study that... however if st *cant* run anything on startup but
only if i explicitly say so, and its only loading its object tree,
then that can be initially trustworthy just as well, right without any
knowledge about the system ive just got to play with. however this
would mean that st have a great disability by design, and i cant even
write an app with it, cuz it wont run initially. so i strongly believe
this is not the case, except if there is a command line option that
can achieve this for me. on the other hand, if there is an open source
introspector, then its already trustworthy, cuz i can know what i got
before i let anything play with my system. so this can even work
anyhow... :) and i strongly hope that you didnt take these words
against yourself! :)

so im just talking about trust, not even that much from my point of
view opposing with yours or with st, but from any1's pov who will ever
get my stuff. in the meantime u r talking about the greater experience
in so many senses opposing with reading source that is not "alive" and
running a finalized application with all its features standing and
being frozen in a single state, and if any1 would like to
modify/extend its features, then they must play with that dead text,
recompile and enjoy the new stuff.

>  >comments can be strings, everything can be
>  >restored via functions for app state, so theres no need to serialize
>  >functions, but even those can be made from strings in case of need and
>  >they can be put in a table as the function is a weak key and the
>  >string is the value...
>
> In object systems we do not use to comment behavior (we do not
>   comment what is done to implement a contract).
> We comment messages.
>
> The comment states the meaning of the message.
> What happen when a message impacts an object depend of the object.
> Each object that understand a message should have the same comment for
> that message.
> The set of messages an object can understand define the "language" of
> the object.

this part was just the explanatory how i can solve storing app state
with only primitive data. however its not about the coding part, thats
saved before evaluating it in the form ive written them.

anyway it was not enough clear, i believe, as ive re-read my words :D
so ive said that my codes are handwritten, except this serialized data
set. that could look ugly, like a minified code or a huge json obj in
one line. so its indented, and therefor it looks nice, but still not
giving much self-explanatory, therefor ive said that comments can be
strings in it, but that can be even be a plain text with the key chain
for an element, i mean something like "x.y.z: stuff for ... purpose
used by ..." or can be an identical tree with explanatory in it
instead of the actual data, and then there is no way to mess with any
data that could require pairs() for example. so it can be really human
readable without running anything, even if not handwritten :D ahh just
now came the idea that an identical tree can be used to generate the
comments from strings, so the serialized data can have comment lines
that wont get lost on the way of parsing and reserializing, and there
wont be any need to swap between the data and the explanatory :D btw
this serialized data can be read and edited from within the app by
hand or by automatics. however even this way i wont be able to edit
the comments in place... kinda hackish anyhow...

by saying that functions are not required to be serialized and still
being able to restore appstate, (while there can be stuffs like a
callback that can change on the fly, or generated functions) ive meant
that i can have a factory function that gets something from the
serialized primitive data, and gives back the actual function that i
didnt serialize. an another stuff is that if id really need to
seralize functions, then i could serialize them as strings, and eval
them, and i can use a hash table with weak keys to map the functions
to these strings in case of need, but maybe this can be achieved via
the debug lib, dunno, i had no need for that til now, and i think this
is asking for more pain :D

>  >- the speed and heavy lifting. luajit is faster than a cheetah, but
>  >ive read that st is a bit slow, and as its currently on js, its still
>  >not faster... with js the main problem is that it is too much involved
>  >with the browser tech and must serve all the bull* of every webdev
>  >even with much backward compatibility so its kinda being a bloatware
>  >(what else could be if lua can do anything and its smaller :D ) so i
>
> You are talking about computation speed...
> I use to talk about speed of understanding, learning and
>   maintaining/growing systems... during decades.
> I am not in a hurry.

fine, but i wanna make an universal app, so there can be need for it,
like a web server really requires speed, and in general, too much
slowness all-around just kills any good vibes :D

>  >think using st would be a loss of speed anyhow, but ive read recently
>  >around that it can make use of binaries, so bottlenecks can be made
>  >wider but the less low level is the better for bigger popularity...
>
> Yes, we use all forms of execution in all execution environments.
> That is the most boring/lowlevel part of smalltalk :-P
>
> Execution machinery let us run our systems; we run binary, JIT VMs, etc...
>   from the '80s, we run our systems in different environments.
>
> Execution machinery is interesting, but the major product is global warming.
> What happens in the mind of the people using smalltalk systems
>   produces satisfaction.
> Under this(my) point of view it is not need to increase the speed
>   of production :-P

speed of execution is the main point for me, but production speed is
important just as well, therefor ive left behind the idea of using
assembly for my goals :D btw global warming is the production of
business in this case, but a good tool is a good tool, so why not make
one?

>  >the rest of my interest is ease of learn and use, some general
>  >interest in the language, basic libs available for general stuffs in
>  >case of need, compatibility with lower level stuffs in case of need
>  >and if i wanna move nearer to hw for whatever, flexibility, active but
>  >not running development, small base to be able to really own the whole
>  >source for whatever need ... these domains mostly seems to be fine
>  >with st as well.
>
> The difficulty learning is most of the times related to using
>   only texts (and drawings) to imagine a reality that the reader
>   has not experienced.
> The use of computers to present virtual realities in an active way
>   is a new medium to get experiences from unknown domains.
> Most people still uses reading and imagination in the mind...
>   it is ok, but from the creation of smalltalk environments (mid '80s)
>   we have new support for learning.
>
>  >but st requires a very different mindset
>  >than other general languages i believe, but mayb im wrong...
>
> Most of the smalltalkers do not have my point of view.
> There is a diverse spectra that covers from people understanding
>   smalltalk as a (dynamic) programming language
>   to a robust set of frameworks, to a robust toolset for
>   writing programs, etc...
>
> If you ask "what is smalltalk?" to a "self-called" smalltalker it will
>   be a diverse kind of responses to the question
>   (some will point you to a book and someoneElse/author's experiences).
>
> The responses will be like:
> -smalltalk is a dynamic Object Oriented Language (OOL)
> -smalltalk is a robust set of frameworks designed from the '80s
> -smalltalk is a class based system still evolving (extended to
> prototypes and other mechanisms of delegation in the '90s)
> -smalltalk is a robust toolset for browsing, designing and debugging
> robust applications
> -smalltalk is a image that contains a full set of virtual objects, that
> runs when started in a computer
> -smalltalk is the content of a snapshot, result of running a smalltalk
> in the past
> -smalltalk is an activity, it is what some smalltalkers is doing in
>   a domain of application (of the object environment); it produces
>   experience and runs in the mind of people
>
> So, it depends of the person you ask, if it is required a
>   different mindset to be understood.
> But more important than the response is what YOU can do with
>   the response; and how you can use the response to your own pourposes.
>
>
>  >a live sys is not the domain of st,
>
> Yes, it is. It happens in the mind.

yes it is, but ive meant not only... so its not a privilege.

st is just a way to achieve the very same stuff as everyone does when
coding! (except from the end-user's perspective.) someone gets/writes
a codebase, writes some new code, compile, and that new code will
interact with the previous codes, or can modify them. softwares have
versions, ppl can print values during development or do anything weird
to understand whats really happening. the only real difference is the
length of the path from writing the code and seeing the effect. a
classic c application can achieve live coding by interacting with a
compiler, making a shared library, load it, and see the effect without
any need to leave the app for a moment! this is the real joy for me
and i believe for you just as well in the whole game, that we dont
need to wait for the compiler, we dont have to reopen everything, go
to the state of the app where we can see the results of the current
modification, or switch continuously between the editor and the app.
this is what i wanted to mean. on the contrary, even st can have tools
included that can be called finalized or feature-complete for a single
purpose, and even then the time can come when anyone will modify it
for whatever purpose... the other good stuff is the homogeneous
ecosystem, so you can reuse everything uve ever made there, but these
are not privileges for st, just most app are developed on the old way,
but the tools behind them can achieve the same.

>  > you can achieve it with anything if youve got the source,
>  > the key is to put the app under its own control...
>
> Sorry but an app has nothing to do with life.
> An app running in a computer can't be alive
> (all live systems are produced by live systems, by definition)

but if it is edited from itself and can run new codes on the fly that
will interact with its currently running internals, then i think yes.

btw st is most likely made with c, running on the same machine, and
its just as well a "bytecode-based-lifeform", so any other app can
born from nothing just as well :)

> The code of a system has no compromise with the system
>   (has not relation with its sustainability).
>
>  >the greatest selling point of st in my eyes is that its even more
>  >flexible than anything else as you can redefine really anything,
>  >however i think that have its grammar as a fix point (even if you
>  >could you most likely dont have reason to do that)
>
> I am not trying to sell smalltalk, only talking about open systems
>   (what I have done during +three decades with smalltalk).

selling point is just an expression that i could define like a feature
that will grab interest in general. on the other hand, as i think you
can see im working on a kinda similar stuff, im very deeply interested
in other goodies out there, like what if ive missed a better tool for
my goals and id do it better to switch immediately for my own good
before my codebase gonna grow that huge as it will become too much
pain to ever switch... this is how you should interpret me to
understand my words :D basically i think about my app while im
writing, just as well as you think about your smalltalk, and my app is
more likely to st than other apps, however even those have the potency
kinda much all around... all that is required in an app is the ability
to save data, compile, load, and must be able to overload whatever is
currently running. and for sure to have any possibility of interaction
in a way as someone can modify its actual codebase right from itself.
even c with an external gcc or with a tiny c compiler integrated in it
is able to do the same.

> The powerfull/flexible part is the person using the system.
> If who is using the system is a person that is fixed in any way,
>   you see formal, beautifull, reduced and secure systems.
> In case of been used in different application contexts you see
>   well designed/evolving frameworks, etc...
> In case of been used for exploration of informatics, in an open world
>   you see smalltalks that uses other VMs, and with wide interfaces
>   to alien execution environments.
>
>  > and i feel the same that lua dont have anything that is too
>  > deep to modify and there could
>  >be a real need for it...
>
> The fexibility and experience of people using Lua in
>   the next decades will show us how it helps to evolve
>   from computing to informatics.
> IMHO, as Lua is defined today as a language,
>   it is not offered as a support for informatics.
> It is fixed in the languages picture.

i think it is only more specialized, but its tools are very flexible
and it have everything for all the needs i can imagine, it just
requires more groundwork to make it similar to the standard abilities
of st, and this is what im working on ..... i mean "with" :D just i
can still see room for shifting the experience to higher states while
this self modifying stuff is just an aspect, and any standalone tool
can be used in the classical meaning of an application just as well,
and just like st. :)

>  >ive got a few new questions...
>  >- if i wanna experiencing with st (im in lack of time, but sooner or
>  >later id like to see a bit more  ) which implementation have the
>  >strongest funds for linux? or wich is the easiest to set up and play
>  >with it with nice experiences? ive considered mainly pharo, cuz thats
>  >used for raptorjit (~rj), a nice luajit fork (
>  >https://github.com/raptorjit/raptorjit ) its domain is an analysis
>  >tool for the internals of rj, its called studio, i think ull find
>  >it... as im inerested in that project i wanna mess around studio just
>  >as well as its kinda more or less an organic part of rj. otoh it have
>  >a nice interface... and for sure im interested in ur stuffs just as
>  >well, but i couldnt do anything on ur playground...
>
> I would suggest to invest your time for learning st using Squeak or Pharo.
> With time you will see that there are more choices; and which
>   make you feel more confortable to learn and find your way.

thx! :)

>  >- can you give me example code that i can run there for introspecting
>  >its ecosystem? like an access to a root element, a dump and whatever
>  >is needed to look around a bit in its toolset... theres no need for
>  >much effort, i just wanna get a taste and be a tourist there :D and
>  >anything you think that could be interesting to see or useful during
>  >my journey... i know its syntax mostly, but that is the level of
>  >wikipedia...
>
> Download Squeak (or Pharo) and read the contents inside the system
>   (start the system and find documentation inside the system)
> I said "find documentation"... learn how to find something you want
>   in an object system (not in a set of files).

may i ask you to give me some small stuffs for the u8 playground on your site:
- instructions to dump/walk the obj tree, so whatever is required for
introspection
- a simple example of running something that includes messaging and
interaction between objects
- a simple example of modifying something
- and good entrance points to docs for these?

im really interested in what goodies your empire have! :)

> I've seen that at start of your response of this email has words in Italian.
> I live in Buenos Aires, Argentina. Have some good friends in Italy;
>   so if you are near Milan I would suggest to met someone working
>   with Smalltalk.
> Looking someone else working with smalltalk is a boost in learning;
>   and will let you discuss on the directions you need help.

nope, im hungarian (near to the capital), just learning italian
multiple ways :D but thx! :)

>  >- when you wanna share your sys then you can simply cut a branch from
>  >the tree of its ecosystem that is serving for a specific domain or you
>  >copy the whole and modify it in any way you would like to?
>
> When you download a smalltalk it is a file of someone else.
> When you start it and modify something it becomes YOUR smalltalk :-)
> When you "save the image", you make a snapshot; and can continue
>   with your smalltalk next time you start "your smalltalk image".

just the same as forking any app :D

> When working in groups, the convergence of multiple systems
>   is done with integration cycles; investing energy in the
>   convergence of different experiences.
>
>  >- different st implementations meaning a different domain like you
>  >cant bring ur codebase to an another field or you can, or you can only
>  >by converting?
>
> You branch(copy your system) to another domain of application...
>   going to that destiny with your objects... and start working, changing
>   and sharing it with people in the site of exploration.
>
> Or you enter a domain/workgroup and start learning the system
>   that is already there... with time you inject some objects/frameworks
>   in the workgroup adapting to match the domain.
> The energy needed to enter a domain depends more on the communication
>   capabilities of the workgroup and the skills/experts in the group
>   than in the toolset.
>
>  >anyhow i can see that we are doing our business cuz the very same
>  >experience, and this is really the best way of coding that i can
>  >imagine
>
> Yes, an open system acts as a gravitator where people experiences
>   converges and modify the media to cristalize domain frameworks
>   with time.
>
>  >and thx for all ur time and efforts, i really appreciate them! just as
>  >well for the interesting conversation!
>
> cheers,
> Ale

thx again, sorry if my stuff became a bit messy, and i hope that the
lua folks dont hate us cuz our long off-topic, personally i think its
fine here as they can possibly find some goodies around for
themselves, and its even related to lua just as well :D (btw anyone
feel free to redirect us if we are too far from the coast! :) )