robertkrahn01

Site is currently down; https://web.archive.org/web/20200122181519/https://blogs.qui...

The article mentions the ransom message with the date March 1 2018. This probably means this malware is two years old?

Nah, BER will actually be turned into the Tesla factory. This way they can at least stop spending millions just to keep the lights on.

A podcast version of it is here: https://softwareengineeringdaily.com/2019/03/17/crypto-bubbl...

Go in the C++ STL! Now that would be a headline!

"Reader, Come Home" by Maryanne Wolf is a good book on the topic of how new technology influences our reading habits.

https://www.goodreads.com/book/show/35887237-reader-come-hom...

Here are slides of an earlier version of the talk given at QConSF 2017: http://homepages.inf.ed.ac.uk/wadler/papers/categories/qcon-...

Great to see those ideas discussed! It is a little strange, however, that Ted Nelsons ideas around Xanadu and its link representations aren't even mentioned.

https://youtu.be/hMKy52Intac?t=1m44s

Plus org-clocking, easy time keeping and also offers easy aggregation for reviews. It is really interesting to see after a while how much time was spend at various activities...

https://orgmode.org/manual/Clocking-commands.html

Used it, works great. Also really good to understand what git really "is".

I can really recommend Waldrop's The Dream Machine [1]. It is a pretty detailed description of the different driving forces that let to the Internet, personal computers, AI research etc. Yes, a lot was influenced by the US military and DARPA, starting with RADAR systems and the need for computation in WW2 and continuing with the cold war, the Sputnik shock and increased research spending afterwards. On the other hand, a lot of the folks involved certainly had no militaristic attitude or intentions. A lot of government funding early on sparked an amazing development, the foundations of the things we work with today.

[1] https://www.amazon.com/Dream-Machine-Licklider-Revolution-Co...

If you don't want to run your own Lively installation locally then all it needs is a web browser.

If you want to run it locally via https://github.com/LivelyKernel/lively.installer then it should run well in MacOS and Linux. On Windows you might need to use a proper bash (e.g. git bash or the Ubuntu subsystem).

There is a desktop app for mac os that wraps the installer and gives you a menu bar entry for controlling the lively server but in the end it is just a frontend for what the installer does.

Personally, I think the interaction model is closer to Self than to Smalltalk. A walk-through of building a morphic app is here: https://lively-next.org/doc/todo-list-tutorial.html

Lively also got some influence from Emacs in terms of integrating tooling and support for remote development. One example, connecting to another webpage and modifying it via lively: https://www.youtube.com/watch?v=gbp30e_QYvY. Apart from JavaScript, it is easy to integrate other languages as well, e.g. you can connect to a running Python process via https://github.com/LivelyKernel/lively.py) and then use workspaces and file editors inside of Lively to modify and run Python code. This stuff is based on a generic RPC mechanism that connects Lively worlds and other runtimes: https://lively-web.org/users/robertkrahn/2015-06-12_l2l-map.....

cloxp is following more a traditional Smalltalk-model, the core component is a system browser for Clojure namespaces.

Lively!

LivelyKernel (2008): https://www.lively-kernel.org/

lively.next (2017): https://lively-next.org

cloxp (2015): http://cloxp.github.io/cloxp-intro.html

No, it's not about personal preference. It is about what is (im)possible when the only context to be considered is the status quo. The technologies you list are innovative but in the end just iterations of inventions of the 1970s. The 70s were so special because stuff happened there was the result of increased spending into science and research of the 60s after the Sputnik crisis [1]. Today's R&D is not focused on what could be possible in 10, 20, or 30 years but in 1, 2, or 3 quarters since companies funding the research need to be focused on their bottom line. The Eve project was special insofar in that it received funding not tied to short-term goals – but only to an amount that in the end wasn't enough. Similar things happened elsewhere and this bars the way to more meaningful inventions [2].

[1] The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal. Mitchell Waldrop.

[2] Founder School Session: The Future Doesn't Have to Be Incremental https://www.youtube.com/watch?v=gTAghAJcO1o

Where? The state of the art today of

- debugging

- code browsing, system exploration

- customizable, modular, non-textual user interfaces*

- immediate feedback after code changes

- non-textual programming

is < what Lisp and Smalltalk environments provided more than thirty years ago.

* not necessarily visual programming. Look at the Genera Lisp OS or Plan 9 for example.

They all moved over to find the next adventure.

I'm very sorry to see this. We need investment in programming language and environments – and right now there is pretty much zero of it. No, new programming concepts and tools will not pay of immediately but in the long term they can be incredible efficiency multipliers, empowering pros to do more work in less time and non-pros to be programming in the first place. As long as no one is interested in funding this kind of research & development we stay where we are today.

+10

I think any material that establishes more history and viewpoints in our field is and will be very valuable. Please consider releasing more of it.

Yes, the reified execution stuff is so powerful and fun. You can take a "process", turn it into an object, inspect it, copy it, save it, resume it later, ship it to other VMs and run it there and so on and forth.

Yay :)

You are right, my usage of the term static does not go back to a well defined notion, I used it for brevity. What I meant is to make a distinction between entities describing the (runtime) system's state (classes, methods) vs. the entities used in the system's execution (stack frames, message sends).

A non-exhaustive list:

- Amber Smalltalk provides a Smalltalk layer on top of JavaScript: http://www.amber-lang.net/

- Indium adds JavaScript tooling support and runtime interaction to Emacs and brings a few Smalltalk features such as object inspection (the project creator and maintainer is a Smalltalker and author of Amber): https://github.com/NicolasPetton/indium

- Lively provides a Smalltalk-like environment (code browsing, editing) as well as object(-graph) persistence, similar to the Smalltalk image idea, and mixes in some ideas from Self: http://lively-next.org/

Lively's meta interface is separately usable via lively.vm and lively.modules: https://github.com/LivelyKernel/lively.vm https://github.com/LivelyKernel/lively.modules

Smalltalk has a meta API that is designed to allow introspection and modification of both static and dynamic code entities [1,2].

Static entities such as classes and methods (and depending on your Smalltalk implementation namespaces and object versions) can be modified at runtime, i.e. while your program is running you can make a change and get an immediate effect. This is now known as "live" programming, however, it is notably different from your typical "hot reload" implementation in that it knows how to apply changes for individual code entities. E.g. if you modify a method you don't need to reload the entire class or module or entire runtime. For me, this feature alone makes for a big productivity increase.

Dynamic entities such as stack frames can also be reified by the meta interface. This allows to inspect and modify runtime processes, e.g. inside a "debugger" [3]. Note that the debugger allows to modify and create new code while your are debugging. This is a powerful feature because it means that you get access to runtime objects inside of it. Ever wondered what object gets passed into your method at a certain point, what methods it knows, what properties it has? Just try it out and see for yourself!

An interesting analogy to describe this experience: [4].

For a deeper description about the ideas behind that see Design Principles Behind Smalltalk [5].

Also, most Lisp implementations provide the same kind of meta interface, and CLOS arguably provides a more flexible and higher level abstraction of these ideas [6].

As for similar environments I have worked on, there is Lively for JavaScript [7] and cloxp for Clojure [8]

[1] http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/31%20-%20C...

[2] Chapters 16 http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

[3] https://www.youtube.com/watch?v=1kuoS796vNw

[4] http://simberon.blogspot.nl/2013/01/swimming-with-fish.html

[5] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

[6] https://mitpress.mit.edu/books/art-metaobject-protocol

[7] http://lively-next.org/

[8] http://cloxp.github.io/

The notion of the function point metric is explained in [1]: "the amount of business functionality an information system (as a product) provides to a user". The IFPUG report in the article explains it further and also mentions the inaccuracies across different variations of that metric [2].

As a Smalltalk programmer I certainly agree with having an increased productivity when programming in Smalltalk. But in my opinion this does depend less on the language and much more on the development environment. Having worked with multiple Smalltalk-like environments for JavaScript I can (anecdotally) report the same kind of productivity for programming in JS.

I think the right tooling around a PL influence productivity a lot, maybe even more than the language itself. Of course, certain tooling features depend on meta interfaces of the programming language and its runtime.

[1] https://en.wikipedia.org/wiki/Function_point

[2] page 9, http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...

There were some good links in the article but my no. 1 resource for CSS grid is https://css-tricks.com/snippets/css/complete-guide-grid/

Interesting in this regard might also be the talk that Robert Smith of Rigetti Computing recently gave: https://www.youtube.com/watch?v=f9vRcSAneiw

Apart from praising Common Lisp he describes how they are building an assembler-like language for quantum computing.

The HN thread: https://news.ycombinator.com/item?id=15880172

bright-shadows.net [1] was a Project-Eulerish site around security related challenges. I think it's pretty dead now but I remember lots of interesting problems that motivated to learn new stuff.

http://bright-shadows.net

Live Debugging in Smalltalk https://www.youtube.com/watch?v=1kuoS796vNw

Well, maybe afterwards is safer.