stefanu

Advantages so far: high quality per that works with fountain pen. No fear of ruining whole notebook with an ugly note or a drawing. I can carry only sheets that are relevant to the problem I am solving right now. I can lay out the sheets in front of me to get a bigger picture. I can throw away the bad ones. It is easier to scan (using iPhone scan to PDF function).

https://md.midori-japan.co.jp/en/products/mdpaper-pad/

In addition to that, I gradually switched to their 0.38 pens of different colors. With fountain pen it was more stylish but impractical for multiple semantic(*) colours. With cheap, light, yet nice quality pens of different colours I can not only carry multiple ones, but have the same set at multiple places.

(Dark blue is body text/drawing, light blue is comment/secondary annotation, orange is action/process/message passing, green is data/metadata flow, …)

The coloured trails you can see at more detailed zoom levels, are part of the hiking trail system. The outdoor signage even has a national technical norm [^2] (in Slovak, but has some terminology translated int to English and German).

[1] https://en.mapy.cz/turisticka?x=19.8702765&y=48.7675046&z=14 [2] http://www.jazdecka-turistika.sk/images/stories/dokumenty/KT...

http://www.jazdecka-turistika.sk/images/stories/dokumenty/KT...

EDIT: Typo

I really enjoyed working on Data Brewery and I eventually will resume my work as there is a lot to do. It is just put aside on the back burner. In the meantime I might only hope that someone would volunteer to at least handle bug fixes. I'm open to grant access to the repositories.

Any suggestion how to prevent open-source project from dying is welcome.

Bubbles was meant to be data integration library (also known as ETL) – get data from multiple sources, transform them and produce tables that are more suitable for further analysis or reporting.

Moreover thunderstorm network (if we consider the interactions of particles in the thunderstorm) is very transient. No feedback loops emerge in the system (to my understanding of thunderstorm). Also the system does not adapt to the surrounding environment through it's reconfiguration of internal connections. Thunderstorm lacks many properties of the complex systems discussed in the article.

What might make it less attractive is the verbosity of Cocoa (formerly known as OpenStep), too many class name prefixes, missing native literal objects and use of pointers. This is problem of the framework, not the language itself though.

Smalltalk on a RISC (SOAR) is a simple, Von Neumann computer that is designed to execute the Smalltalk-80 system much faster than existing VLSI microcomputers. The Smalltalk-80 system is a highly productive programming environment but poses tough challenges for implementors: dynamic data typing, a high level instruction set, frequent and expensive procedure calls, and object-oriented storage management. SOAR compiles programs to a low level, efficient instruction set. Parallel tag checks permit high performance for the simple common cases and cause traps to software routines for the complex cases. Parallel register initialization and multiple on-chip register windows speed procedure calls. Sophisticated software techniques relieve the hardware of the burden of managing objects. We have initial evaluations of the effectiveness of the SOAR architecture by compiling and simulating benchmarks, and will prove SOAR's feasibility by fabricating a 35,000-transistor SOAR chip. These early results suggest that a Reduced Instruction Set Computer can provide high performance in an exploratory programming environment.

[1] http://dl.acm.org/citation.cfm?id=808182

I would not mind buying a floppy drive and all necessary adapters, install Atari ST emulator and write Kamenicky encoding converter in Python to convert 1st World Plus documents from '89 if I had to convert documents of my parents. I would not be complaining about obsolescence of the format at all.

My problem is not technical, it is about user experience and productivity.

I have written quite a few bash scripts, python scripts and long ago ruby and smalltalk scripts to do things for me, that bothered me. My point is, this is a software I am paying for (and I've already mentioned that 2008 should not be considered as old) and I would rather spend my time writing the "super 1337 h4x0r" bash and python scripts for something that I can't do otherwise.

I'm not saying that it is permanent problem, there is solution for it for sure. It is just unnecessarily cumbersome and mostly unexpected: I can imagine dropping support for files from 1995 not for files from 2008.

I miss the talks of pre-Etoile days on #gnustep.

Irony is that at that time the Smalltalk people didn't see the advantages of frameworks like StepTalk. I got a few "Why don't you just use Smalltalk?" questions on ESUG conference in 2003 – on one hand they were not happy that Smalltalk use was a bit declining (or at least not thriving, compared to other languages/environments), but didn't wanted to see a compromise solution. Only the pure Smalltalk way was the proper way.

> Maybe it's an idea whose time has finally come :-)

... where web == one large distributed Smalltalk image? I'm all for that! ;-)

It is light-weight SmallTalk interpreter on top of ObjectiveC objects. See the examples for better idea of what it does: https://github.com/Stiivi/StepTalk/tree/master/Examples

I guess we just need to reach some adoption tipping point or end of support of Python 2. Whichever comes first.