Live data from Hacker News

The Web Is Becoming Smalltalk

zacharyvoase.com

71–80 of 112 posts

Re: The Web Is Becoming Smalltalk

#71
post #33

While a lot of the comments here are focussing on other aspects of the article, I think the most basic actionable takeaway is we need a simple method of persisting changes made in Firebug/Developer Tools to the code. Once mentioned, it seems like a no brainer - why doesn't this already exist?

There is something called firefile that will save your css changes made in firebug but when I used a year or so ago it was a little buggy and stripped comments out of css (breaking WP Sites).

I'm working on a WordPress editor called WPide, live css/less editing is something I have planned. When your code editor is part of your website/app I think there is a lot more scope for improving the editing process.

With the current code on github I'm in the middle of implementing git functionality, just struggling with the push/pull side of things, ssh keys specifically.

I did have a concept in place for live editing of css without constant round trips to the server by passing data over cookies. This was some time back, I've since realised HTML 5 has much better ways to achieve that communication. That was when I planned to have the css editor in a different browser window but it might be easier to move the css editor panel onto the front end as a small panel like firebug/inspector. I've got code completion for PHP and WordPress so don't see why css can't be auto completed as well.

I kind of thought creating an editor built with PHP, HTML, javascript and css would make it easier for people to get involved and create a really good editor that was moldable by any develope but as yet no one really seems to get excited about a Web based editor and probably think I'm wasting my time but I'll plod on..

Re: The Web Is Becoming Smalltalk

#72

Earlier quoted context omitted.

Its not the same. Light Table and Bret's demos go way beyond what Smalltalk ever did. Its not just about hot swapping, but liveness, and the Smalltalk community never got that [1]. But it doesn't stop them from saying they've already done it because they don't understand what they are seeing, and thinking is hard. [1] John Maloney got it with Morphic, and even coins the term Liveness at about the same time Tanimoto d…

More than (almost) any other language/environment, Smalltalk is capable of this kind of 'liveness'. That it hasn't been implemented in the way you refer is due more to a lack of development effort than anything else. For the last four decades, Smalltalk has been providing a glimpse of the future. That future is still waiting to happen.

That's a vacuous statement if I've ever heard one. Nothing in Smalltalk makes achieving liveness easier than say Java or, more obviously, a language with very encapsulated state like Erlang, and definitely not various visual languages where you get liveness for free (Quartz Composer!). It's telling that Granger et al are basing Light Table on Clojure/Lisp rather than Smalltalk (it will be interesting to see what Bracha does with Newspeak, however). Also consider various game editing engines (Unreal, Unity) that offer live scene scripting capabilities in whatever scripting language and C++ they support.

Smalltalk was crazy innovative, while Self (Smalltalk's only real successor) gave us the first live graphics toolkit (Morphic). But the future is still being invented, and it will be a much better experience than Smalltalk ever was.

Re: The Web Is Becoming Smalltalk

#73

> Now that conventions are moving towards ‘single-page’ web apps, the concept of a ‘page’ is losing its special meaning. The web is so broken. The whole "web app" concept is just a giant hack. The job of us web developers today consists in employing a never ending pile of hacks (e.g. AJAX, long-pooling, semi-broken languages and implementations, non-standard vendor APIs) to fight a browser into submission so it can b…

> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. I won't. Installing native apps for everything I do? When I can just go to a app website and use it? I have no intention to go back into the 80s.

There is no dichotomy between "the web" and "native applications", like the rhetoric here seems to imply. The line is much more blurred. You can buy "apps" on the Chrome Web Store that are launched from outside of the browser, render their own windows without Chrome's... chrome, etc. You can write native code that runs in a sandbox (NaCl) that gets updated whenever you hit Ctrl+R.

And combining the two, you can "install" webapps, which happen to be launched like native apps, which happen to be written and updated like webapps, which happen to have all the performance and access-to-resources of native apps. Photoshop--the real one, not a janky Javascript clone--running "in" your web browser. Though it's not really a web browser any more, at that point: it's just a platform, like Silverlight, Adobe Air, etc. It just happens to be one for which there is this default "hypermedia viewer" app that comes with it.

Re: The Web Is Becoming Smalltalk

#74

Earlier quoted context omitted.

> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. But that exists. It's called native programs, which are free to access web API's and whatnot just as much as any browser is. The whole point of the web is you don't have to download software, you don't have to store your data locally. Sure, it's a pain to support the quirks of different browsers and s…

> I fail to see how web apps are a hack at all. (...) Sure, they're not the "original purpose" of the web, but they work awfully well for things like GMail, GDocs, GMaps, etc. Well, you realize all the products you mention were only possible because someone figured out a hack (XMLHttpRequest), and now everybody relies on something that wasn't thought out in any shape or form? Can you see how fragile is the software s…

>Well, you realize all the products you mention were only possible because someone figured out a hack (XMLHttpRequest), and now everybody relies on something that wasn't thought out in any shape or form? Can you see how fragile is the software stack an entire web industry is basing itself on?

How is that different from, anything else, really? The first wheel was also a hack. Fire was also a hack (hey, let's bang this two stones together).

XMLHttpRequest was not a hack. It was a feature engineered my Microsoft that people found another use for. After that the hack status was gone: it was standardised, documented, best practices were written, an interchange format was invented for it (JSON), etc.

Don't conflate the origin with the result.

Re: The Web Is Becoming Smalltalk

#75

Earlier quoted context omitted.

> I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. But that exists. It's called native programs, which are free to access web API's and whatnot just as much as any browser is. The whole point of the web is you don't have to download software, you don't have to store your data locally. Sure, it's a pain to support the quirks of different browsers and s…

> I fail to see how web apps are a hack at all. (...) Sure, they're not the "original purpose" of the web, but they work awfully well for things like GMail, GDocs, GMaps, etc. Well, you realize all the products you mention were only possible because someone figured out a hack (XMLHttpRequest), and now everybody relies on something that wasn't thought out in any shape or form? Can you see how fragile is the software s…

>When a better alternative shows up (Sparrow), people flock to it even if it's a paid app. Of course, Google killed it, they are web app zealots after all and need the revenue from the ads.

Sparrow? It existed for a couple of years before being bought by Google and people hardly "flocked" to it. It was mostly a marginal app. The overwhelming majority of OS X users either used Mail.app or Gmail on the web.

Google just brought it for the talent and to get some better native app tech. Not because people were ...flocking to Sparrow and lessening Google's revenue. I doubt there was even a dent to their revenue.

Re: The Web Is Becoming Smalltalk

#76

> Now that conventions are moving towards ‘single-page’ web apps, the concept of a ‘page’ is losing its special meaning. The web is so broken. The whole "web app" concept is just a giant hack. The job of us web developers today consists in employing a never ending pile of hacks (e.g. AJAX, long-pooling, semi-broken languages and implementations, non-standard vendor APIs) to fight a browser into submission so it can b…

Applets were always the answer. Amazing how badly a technology can fail because of start-up time.

Re: The Web Is Becoming Smalltalk

#77

Earlier quoted context omitted.

More than (almost) any other language/environment, Smalltalk is capable of this kind of 'liveness'. That it hasn't been implemented in the way you refer is due more to a lack of development effort than anything else. For the last four decades, Smalltalk has been providing a glimpse of the future. That future is still waiting to happen.

That's a vacuous statement if I've ever heard one. Nothing in Smalltalk makes achieving liveness easier than say Java or, more obviously, a language with very encapsulated state like Erlang, and definitely not various visual languages where you get liveness for free (Quartz Composer!). It's telling that Granger et al are basing Light Table on Clojure/Lisp rather than Smalltalk (it will be interesting to see what Brac…

Smalltalk is capable of evaluating statements as they're entered, and it's a relatively small step to reflect those changes immediately on compilation - thus, 'liveness', as in Light Table. I can't imagine being able to do that in Java.

If I'm missing something, can you please provide some more detail?

Re: The Web Is Becoming Smalltalk

#78

Earlier quoted context omitted.

I don't quite understand this distinction between liveness and hotswapping, as all the examples of liveness that I've seen involve hotswapping code that causes graphic or audio side effects, and clearly that sort of thing has very real practical limitations.

There is one demo in Bret Victors' IoP talk where he is live programming a sorting algorithm and something non-graphical is visualized (in this case, control flow and local variable states). The hotswapping really isn't the focus at all; its the live feedback that is important.

You might be fighting a battle that's already lost. For most people, live programming is having a running system with a REPL or equivalent attached so that you can run & update code inside that system. For example a running web server with some mechanism to add a new request handler while the server is running. Or a program that's playing programmatic music or some kind of graphical demonstration where you can add and redefine functions to change the music/graphics. This kind of "live programming" is basically the same as hot swapping, but some people also associate it explicitly with a live stage performance (e.g. music or visual).

With the kind of live programming that you mean there is some meta system that is monitoring your code and continuously giving you feedback on it. Perhaps it does this by just running the code and showing the output, perhaps it displays the execution trace in some way, perhaps it displays a visualization of a data structure over time. In a way, live feedback on static type errors could also be considered a limited form of live programming. Maybe it's a good idea to adopt a new term for this kind of live programming? It would also help from a marketing perspective I think, to have a new thing that people can be excited about rather than a term that they associate with a boring, limited and old fashioned feature (i.e. hotswapping).

Even with this second notion of live programming the question of updating running code does not go away. If you are developing a game, you may want to do live programming by running the game next to the code and have that be updated whenever the code changes. But a game has state, and how do you transport that state to the next version of the code? Hot swapping code by blindly mutating a function pointer in the running game is obviously not the answer. That's just a hack that works some of the time: it doesn't work when updating code while the running game is still in the middle of something, and it corrupts the state when there is a bug in the code, and it doesn't work at all when data structure structure changes. The perspective "how to transport the state to the next version of the code" is much better than "how to I shove new code into the running system with the old state". The same issue comes up with most programs, not just games. This is still an open problem as far as I know. For live programming we also need tools to manage and reset the state. When you have corrupted your state with a bug in your code, you want to be able to quickly go back to a previous non-corrupt state. Even if you change the entire programming model, you'll still have to address this state update problem in some way.

Re: The Web Is Becoming Smalltalk

#79

Earlier quoted context omitted.

More than (almost) any other language/environment, Smalltalk is capable of this kind of 'liveness'. That it hasn't been implemented in the way you refer is due more to a lack of development effort than anything else. For the last four decades, Smalltalk has been providing a glimpse of the future. That future is still waiting to happen.

That's a vacuous statement if I've ever heard one. Nothing in Smalltalk makes achieving liveness easier than say Java or, more obviously, a language with very encapsulated state like Erlang, and definitely not various visual languages where you get liveness for free (Quartz Composer!). It's telling that Granger et al are basing Light Table on Clojure/Lisp rather than Smalltalk (it will be interesting to see what Brac…

Similar to self, iolanguage would be a strong place to start for getting cheap liveness.

Re: The Web Is Becoming Smalltalk

#80

I recently tried out the binary at squeak.org. It was recommended to me when I described to some people what I'm trying to create (a system for building software using which you can improve itself). It was very neat, and so easy to try out. You essentially download it, run it, and it's like a mini-operating system running. You can inspect the system itself and make changes, and then save/load these images. Basically…

Yeah, Smalltalk and stdin/stdout don't usually go together, unfortunately. Smalltalk is just not designed to be a part of the UNIX ecosystem, since it's a big environment and not a small purpose-built program.

And I'd also recommend Pharo over Squeak at this point, since they have been aggressively improving the Squeak project and creating their own clean modern Smalltalk.

If you want to use Smalltalk for UNIX-style scripting, I'd suggest GNU Smalltalk.

Post reply on HN