Questions while reading stuff

noob-questions.md

Python

__debug__ vs. -O

Python has a built-in variable __debug__ which is set to True when python is called without -O (optimize). The -O flag disables all assertion code.

This seems at first glance like a very easy and clean construct to rely on when coding in development versus production: in development, don't use -O, defensively litter your code with type- and sanity-checking asserts. Perform development-only debugging by testing __debug__ beforehand.

When in production, run all code is run with -O which disables asserts (speeding execution) and sets __debug__ to False.

Why is this construct not more popular? Why does nearly large-ish collection of python code re-invent a DEBUG global variable or the like and ignore __debug__?

Scheme

Reading http://en.wikipedia.org/wiki/Scheme_(programming_language)

• Why the necessity for let, let*, and letrec? It seems like let* would do everything that let can do; and letrec can do everything let* can do. If it is a matter of performance (is let simpler and faster than letrec?) then could a clever interpreter determine which of the three was appropriate for any given set of definitions?

Smalltalk

Reading http://blog.moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html

• Can the "big wins" from smalltalk exist separately from some of its unusual features like
  • image-based persistence
  • a built-in graphics environment with (non-tiling) window manager, (crappy) code editor, and (interesting) code browser?
  • (yes, because some lisps have this image-based computing idea, and some do not?)
• How does one test, package & distribute small units of smalltalk code?
• Specifically about image-based persistence:
  • Doesn't a crash run the risk of massive loss of state? (read up about image-based persistence)
  • Doesn't the assumption of modifying the code on a long-running vm risk corrupting the state? How does one rollback/recover?
  • Examine http://stackoverflow.com/questions/722204/which-programming-languages-besides-smalltalk-are-image-based
  • Long-running stateful seems more vulnerable to memory leak issues and less compatible with "ephemeral" virtual hosting. False?
• Specifically about SmallTalk's (Squeak's?) built-in graphical development environment:
  • Graphical development environment as desktop environment? As operating system?
  • The whizzy features of being able to interact with rotated UI elements in real-time feels slow. Can the VM take advantage of accelerated graphics libraries like OpenGL?

First, the stuff I kind of know something about.

• You are right that the existence of let, let*, and letrec are largely due to implementation concerns.
  • The language standards meant to explicitly permit let forms to be evaluated in parallel, as opposed to let* which has an explicit data-dependent ordering. I am unaware of compilers that take advantage of this but there may be some.
  • letrec allows for definition of recursive and mutually-recursive functions. This is quite different at the assembly/IR level than let and let*, of course. While a sufficiently smart compiler could disambiguate a more general let construct (and that compiler is probably GHC) there was sufficient precedent in both the Lisp and ML communities for this to never be a big pain point for most people. The specs have much bigger problems, Common Lisp especially. ;)

Now for some of my armchair-speculation/bullshit:

• It depends on what "big wins" from Smalltalk you're talking about.
  • I certainly think that "the focus of OOP should be on messaging" has been captured in other object systems and languages, perhaps especially Erlang.
  • Oh, boy. I also think that having a language described in it's own metalanguage has been done to varying degrees in Lisp, Smalltalk, Factor, CLOS' Metaobject Protocol, and elsewhere. It is an open question to me whether Kay is referring to Homoiconicity or some even more nebulous concept. I'm not sure about the veracity of his claim that having a metasystem is so important, actually. I think there's a real question of what level of granularity we're talking about as, well. I really like reflection because I like to be able to play with programs live and look inside (introspection) and peek and poke. Computing to me is fundamentally about interactivity, ever since I learned what a computer is. It's alive. That said, his biology-inspired arguments (which are, I must admit, more intuitive than scientific) that we should have hot code reloading deeply supported for long-living systems don't hold up when the level of granularity internet startups care about is servers or clusters and not classes or modules.
  • As for what level of live-editing, gleeful hacking, deep-diving, chest-thumping whatever-you-have can be attained without "an image", I'm not sure. Hot code module-level reloading can be done in static languages. There are many papers to prove it but it is often less "convenient" though guaranteed "safe". This seems to fall back to the old "if your tools/language don't provide it, you learn not to want it" adage. I've yet to meet a Haskeller that cares about not having image-like tools, or a Smalltalker that bemoans the lack of a better type system. C'est la vie.

Re: how does one test/package/distribute code?

• See the SCM category of the above link. tl;dr: It is rather foreign to what you're used to. Modern lisps are much less whole-hog on the persistent-image-as-code-store thing than modern smalltalks. We realized we'd lost that battle. There are differences between how you would distribute proprietary apps to end users and how you package/lock down a shippable image/VM for a proprietary app, of course.

Re: image-based-persistence questions...

• These are good questions and, due to lack of experience, I don't have answers. I can say most image-based systems I'm aware of had an analog to "image patches" that were regularly serialized to disk. Think append-only/log filesystems. Most languages deeply committed to this model, especially Interlisp and Smalltalk had tools to support it. Most trouble I've heard about relates to fixing a bug in the image, forgetting to in some way keep the change, and losing it on the next "full load". You can make that same mistake with git, of course. "Where did I put this? .... oh, I didn't. :-("

I'm not sure I have a good answer for your remaining questions but yes, Smalltalk in many ways wants to be an OS. There is a good article/paper along these lines titled something like "There Shouldn't Be An Operating System" or "An OS Is A Group Of Things You Couldn't Figure Out Where To Put In Your Language" or something. Finally, you may be interested in pharo which I think has OpenGL/hardware compositing for graphics.

Before I forget, Daniel Lyons has written a huge number of thought provoking posts about these and other languages issues that I think you would find worthwhile. Here are three favorites:

• Hiding Complexity
• Good for Whom
• Free Your Technical Aesthetic

I'd strongly encourage you to read them. In fact, I'd be happy to have a beer/skype session to discuss any individual one. In fact, why the hell don't I start an Atlanta CodeTalkers meetup to discuss papers, actual pieces of code everyone agrees to read, and other weird non-language specific, non-tech specific issues?!? O____O