Lepiter is the latest significant step in our journey to making systems explainable. Here is a behind the scene peak of how we got here.
1/
Our guiding north star @feenkcom is making the inside of systems explainable. We spent a great deal of energy rethinking how we can figure systems out, and this led to #MoldableDevelopment and #GToolkit.
#GToolkit proposes a new development experience. We see the environment as a language made out of visual and interactive operators that can be combined in many ways while working with the environment.
3/
Early on, we embraced the idea that narratives are central to software development:
At the same time, Documenter was another component that complemented the Playground with live textual narratives and that transformed the #GToolkit image into a wiki made out of class comments and markup files:
Documenter was particularly interesting in combination with examples (tests that return objects). When embedding custom inspector views of examples in documents, we essentially use the testing effort to produce live and testable documentation.
#Lepiter unifies what Playground and Documenter had to offer and adds more abilities and it enriches the environment's language in significant and unexpected ways.
If until now #GToolkit might have been considered as an environment for #Pharo, we can now show how the same principles and design apply well beyond Pharo and even beyond programming.
12/
Consider this example: we write a custom visualization that highlights a query over the current knowledge base, and when clicking on the result we get to continue editing.
Interestingly, the size of Lepiter's implementation is comparable to that of Playground and Documenter, but it's so much more powerful. That's what we mean by a language. Lepiter is not a feature. It's a new operator that is combinable with the rest of the environment.
14/
With the addition of Lepiter we get an environment in which we can treat programming, data science and note taking in the same way. The possibilties that are opened from this unification are simply exciting.
After a year of working with Lepiter we can now safely say that it has transformed how we program, how we learn, how we document, how we communicate both on the technical level and on the business level.
16/
Newcomers to #GToolkit often tell us that it's unclear what the environment is. Some see a notebook. Some see a programming environment. Some see code analyses. Some see a graphical engine. And now, some people see a note taking tool.
So, which one is it? Neither and all.
17/
#GToolkit is first and foremost our exploration of how to make systems explainable by doing away with artificial boundaries in the environment.
While #GToolkit can appear advanced by today's standards, it's merely the beginning of the conversation. If you like what we build, connect with us. Let's enrich the conversation.
It went like this. Imagine you have a system written in Python and you want to split it for various reasons.
You'd first look for components that already exist. In this case, the system already seems to have top components available (as documented by top folders).
Personal computing was conceived to be personal. Personal, as in experiencing computation the way it fits you. Your context should come first and dictate what is interesting. The experience should follow.
1/
For example, consider where you are reading this tweet. Or where you are writing a reply to it. It's not unlikely that you are doing it exactly in the same way many other millions of people are doing it: using the generic interface that Twitter offers.
2/
Of course, this is convenient. At the same time, it might not match your actual needs. For example, say you like writing longer threads. Longer threads imply more consideration and possibly longer time to write. And, you may want to handle multiple drafts in parallel.
3/
#MoldableDevelopment is a way of programming through which you construct custom tools for each problem.
What does that mean exactly?
Where does it come from?
Why is it relevant?
Read on.
1/
The original idea of #MoldableDevelopment came from the work on Humane Assessment through which I argued that we need custom tools to reason about software systems effectively.
Interviewing new employees is a two-way street. On the one hand, you want to know them. On the other hand, you want them to know you, too.
It's also useful to remember that the interaction is also an investment on both sides.
1/
While both parties are invested in similar ways, the conversation is not symmetric. For example, the interviewee is likely significantly more emotionally invested.
That's why as an interviewer, I prefer to compensate.
2/
Typically, interviews are optimized for the act of filtering interviewees. In these situations the organization gains the most. The interviewee can at most get in. However, in the worst case scenario is that nobody learns anything.
3/
A while back, I asked “what is architecture?” and I got many responses within just one day. Some serious, some more (bitter-sweet) joking. We can identify some cluster of responses, but even so, there are certainly a dozen distinct perspectives.
That there are many perspectives is not a surprise given that the literature is full with competing definitions. For example, it's not atypical for architecture books to say something like: “there exists many definitions, so here is ours”.
The search for the perfect definition of architecture captured the imagination of several generations by now, yet it still seems to remain elusive. But, what if it’s Ok to have many of them?