12 ms·

The Web Is Becoming Smalltalk

111 points by zacharyvoase 14y ago

jc00ke 14y ago
Tim Felgentreff did some cool work on remote debugging with MagLev. The video is pretty sick: http://blog.bithug.org/2011/09/maglev-debug http://blog.bithug.org/2011/09/maglev-debug
russellallen 14y ago
Another approach to this type of thing worth checking out is Dan Ingall's Lively Kernel http://lively-kernel.org/ http://lively-kernel.org/
- Turing_Machine 14y ago
  Snap is also worth a look: http://snap.berkeley.edu/init http://snap.berkeley.edu/init (it's a semi-port of MIT's Scratch language).
- robertkrahn01 14y ago
  Great to see LK come up here. Yes, the approach of Lively goes towards what is mentioned in the article, right now however, the client session (what you run in the JS VM in your browser) is what the image is for Lively. We developed a persistence mechanism that will read/write a JS object graph so that your working state of your session can be saved and resumed, just like a Smalltalk image [1]. We are currently experimenting in distributing LK runtimes in nodejs instances so that basically a network of active runtimes can be created that communicate / exchange objects. Note that the core development moved to github [2]. [1] http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/LinckeKrahnIngallsRoederHirschfeld_2012_TheLivelyPartsBinACloudBasedRepositoryForCollaborativeDevelopmentOfActiveWebContent_IEEE.pdf http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/... [2] https://github.com/LivelyKernel/LivelyKernel https://github.com/LivelyKernel/LivelyKernel
gregmuellegger 14y ago
So you want your live editing beeing persistent? What about testing? I think you should first write a test that fails before attempting to fix it...
- vincie 14y ago
  Test your code in a Workspace before editing your classes. Depends on the complexity of the change you are making of course. If it is complex, clone the image and test on the clone.
- emp 14y ago
  Writing a test that fails is a subset of what you can do. Pharo (and other Smalltalks) support writing traditional test cases and running them in a test runner. However you can also: - write snippets in a workspace, as vincie mentioned. - write code against an API that doesn't exist, run it, have it fail, and then fill in the API and implementation. - write stubs that fail automatically, and then fill them out (similar to above). The difference is, when things fail: - you get to play with the live objects in a work space. - fill in missing implementation. - fix any errors. And then much of the time continue execution from the point of failure. No need to restart anything. I simply could not appreciate the variety of options available in a Smalltalk environment until I used it for some fun projects over a few months. Be warned, you might hate your so called modern environments once you get back to them. For Objective-C coders there is hope: http://injectionforxcode.com http://injectionforxcode.com
breckinloggins 14y ago
Chris Granger's Light Table is also trying to do it. Of course, Bret Victor's talk breathed new life into this whole thing. But everything old is new again. People want to build software from a small kernel that scaffolds itself. They want to immediately switch between "testing the app" mode and "building the app" mode. They want something more than a text file, a tool pipeline, and an executable at the other end. On the other hand, they don't want their code to turn into an opaque binary blob that can't be diffed, can't be read by text tools, and can't be shared with people who don't feel like using your sweet "Invented on Principle" tool. It feels like we're converging on the ideal solution, but it's happening more slowly than I think many of us predicted.
- DoubleCluster 14y ago
  Exactly, I'd love more interactivity but you can pry my plain text source files from my cold dead hands. The smalltalk environment was way too magical and too easy to mess up when I tried it.
- trafficlight 14y ago
  The Bret Victor presentation for those interested: http://vimeo.com/36579366 http://vimeo.com/36579366 I can't help but smile while I watch.
- seanmcdirmid 14y ago
  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 does. However, this was originally in Self and relatively independent from Self's hot swapping capabilities. It also didn't really map back to code very well (it was very dependent on direct manipulation via Morphic's edit menu).
  - asynchrony 14y ago
    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.
chewxy 14y ago
It only makes sense if you talk about utility webapps (like twitter). Not everything is a webapp though. Wikipedia for example, is just a display of documents. Should it become a fancy webapp? I don't see much benefit in it. The old page concept is plenty fine in many contexts IMO.
- malandrew 14y ago
  The Browser — A Lament *Binstock:* Still, you can't argue with the Web's success. *Kay:* I think you can. *Binstock:* Well, look at Wikipedia — it's a tremendous collaboration. *Kay:* It is, but go to the article on Logo, can you write and execute Logo programs? Are there examples? No. The Wikipedia people didn't even imagine that, in spite of the fact that they're on a computer. That's why I never use PowerPoint. PowerPoint is just simulated acetate overhead slides, and to me, that is a kind of a moral crime. That's why I always do, not just dynamic stuff when I give a talk, but I do stuff that I'm interacting with on-the-fly. Because that is what the computer is for. People who don't do that either don't understand that or don't respect it. The marketing people are not there to teach people, so probably one of the most disastrous interactions with computing was the fact that you could make money selling simulations of old, familiar media, and these apps just swamped most of the ideas of Doug Engelbart, for example. The Web browser, for many, many years, and still, even though it's running on a computer that can do X, Y, and Z, it's now up to about X and 1/2 of Y. ref: http://www.drdobbs.com/article/print?articleId=240003442&siteSectionName=architecture-and-design http://www.drdobbs.com/article/print?articleId=240003442&#38...
- zokier 14y ago
  Wikipedia is pretty bad example imo, as it is actually quite advanced webapp of sorts. More specifically, it's a webapp for authoring, collaborating, searching and viewing documents.
indubitably 14y ago
WebDAV? Heaven help us…
- DoubleCluster 14y ago
  Why the dislike? It's not a bad protocol.
  - chubot 14y ago
    From what I remember, it's pretty chatty. It appears to be on its way out. Is there any new software that's using it? WebDAV had some varying levels of support in Windows and Mac desktops. But AFAIK the Windows stuff got broken; not sure about Mac. I think that access from a GUI file browser was one of its main use cases in the 90's. If nobody does that anymore, and I don't think they do, then the protocol will need a new app or it will continue to die.
    - DoubleCluster 14y ago
      I've used it to bolt file storage on a REST API for enterprise stuff. It seems to be a good fit. I'm even using the Windows WebDAV implementation... working around its quirks is madness: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html http://www.greenbytes.de/tech/webdav/webdav-redirector-list.... Note that XP SP3 has the port-handling bug even though it's not on that list.
gamache 14y ago
This kind of hot-swapping can be achieved on quite a few languages; certainly Perl and Ruby in addition to JS, and I'm sure there's a dozen more languages that allow you to redefine at runtime. The difference is that Smalltalk made hot-editing the default. SmallTalk is an uncommon language these days, with the exception of its half-descendant, Objective-C. Ruby borrows Smalltalk's OO semantics pretty much completely. Just sayin'
- norswap 14y ago
  You can even do it in Java with Eclipse (Notch did it during his screencast), although I don't know the specifics.
  - seanmcdirmid 14y ago
    Notch used a special programming framework to get their. Many game engines support similar features; the ability to modify the game world while its running, and can even do that with C++. The problem is you don't get it for free (framework transparent hot swapping isn't good enough), and its only because of special compromises made in the framework that you can get liveness at all.
  - drakeandrews 14y ago
    Intellij keeps telling me it has the feature. Although I've never managed to use it on purpose.
- martinced 14y ago
  "...I'm sure there's a dozen more languages that allow you to redefine at runtime" Indeed. There are all the Lisp dialects to start with. And it's no surprise that hence SmallTalk had this feature too: Alan Kay (+), one of the key creator of SmallTalk, acknowledged the heavy influence of Lisp on SmallTalk: http://www.franz.com/services/conferences_seminars/lisp_50th-birthday.lhtml http://www.franz.com/services/conferences_seminars/lisp_50th... (+) Famous quote attributed to Alan Kay: "I coined the term "object oriented". I can tell you I didn't have C++ in mind."
vincie 14y ago
Check out Seaside, the Smalltalk web framework. It has a edit-in-the-browser mode, where you can pretty much edit anything to make your web app work. Seaside itself is a component-centric framework, not page-centric as most web frameworks are. You build independent components, which you place here and there to make your app.
- doublec 14y ago
  Clamato, also from Avi Bryant, is an interesting approach to in browser development: https://bitbucket.org/avibryant/clamato/wiki/Home https://bitbucket.org/avibryant/clamato/wiki/Home
  - fractallyte 14y ago
    Clamato has been superseded by Amber: http://amber-lang.net/ http://amber-lang.net/ In particular, check out the tutorial page (Smalltalk in a browser!): http://amber-lang.net/learn.html http://amber-lang.net/learn.html
    - doublec 14y ago
      Oh, very nice, thanks!
lispm 14y ago
The language is written as 'Smalltalk', not 'SmallTalk'.
wbl 14y ago
And this makes Cross-Site Scripting even more fun then it already is! We can't even make the browser limit sharing across websites securely: what makes you think that this edit mode will not be a target?
_pmf_ 14y ago
> Well, the way I (and Roy Fielding) see it, the browser is a stateful agent that just renders HTML to a viewport, and executes JavaScript. I cringed.
jhonicker 14y ago
You might try looking at http://amber-lang.net/ http://amber-lang.net/ as a test for your ideas. It's a Smalltalk implementation running in JavaScript.
CoryG89 14y ago
I can't believe that the fact that Chrome can hot-swap code is surprising to anyone... Have you never been working on an app, opened up the console, changed a variable or function definition and seen the effect in real time?
- error54 14y ago
  I'm with you on that. It's the surprising the number of web developers who are just now finding out about this which leads me to another questions, what tools do they use if not Chrome Developer tools?
  - shurcooL 14y ago
    I imagine a text editor, terminal, browser, and a lot of Alt/Cmd+Tab, F5/Cmd+R, Ctrl+C+up+enter. But I can't say for sure.
    - error54 14y ago
      Those are general tools. I want to know what tools people use for debugging Javascript that are similar to Chrome Developer tools or Firefox's Firebug.
      - cdcarter 14y ago
        I believe the implication there was that the debugging process is "try, try again".
        error54 14y ago
        Haha ah thanks for the clarification cdcarter. That is a process I know all too well when debugging code in Internet Explorer 8.
calinet6 14y ago
I read the title and had some first thoughts spring to mind, and didn't reach the same conclusion as the author. While cool it was, it was limited in reach, and I think you could go further with this analogy. Treat every web site or address or endpoint as an object. Allow message passing as though the web were simply a single object-oriented system resident on the same computer. The definitions of the APIs are kept as standard, so the system "just works" with any site. This is, of course, the vision of APIs. But could we do better? Could we make it closer to a true object-oriented system, even simpler to use? Not sure if it would make a big difference, but as we know, sometimes a simple thing that makes connections easier can make a huge difference (eg: XmlHttpRequest). Make the web as easy as smalltalk. For every API, and eventually, every site. Not just the ones we decide to make language-specific libraries for. One library per language just interfaces with "the web" as a fully-generic API you can access as easily as any object. Just thought I'd share this thought. Any thoughts or ideas?
- njharman 14y ago
  You just described http. Every URL is am object and the post,put, et al are the messages.
phillmv 14y ago
I felt this way when I first saw better_errors: https://github.com/charliesome/better_errors https://github.com/charliesome/better_errors It's a little surprising how much we keep reinventing.
- codewright 14y ago
  Stuff like that has been in Python for a long time. (Werkzeug)
  - phillmv 14y ago
    That sounds like a clone of Rack, that doesn't support the latest version of Python.
    - codewright 14y ago
      Few that aren't running a charity use Python 3 in production web apps. Rack <-> WSGI Werkzeug is just an app server on top of WSGI that happens to be very nice, with features like the above described.
emp 14y ago
I hate to be picky, but it's Smalltalk, not SmallTalk.
hcarvalhoalves 14y ago
> 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 be used to run a general application instead of simply navigating hypertext, it's original purpose. All that because there's incentive in keeping users inside walled gardens and holding a ransom on their data. It's unbelievable we take as granted reinventing the wheel over and over again, dealing with weak standards and APIs designed by committee, fighting browsers into rendering interfaces and invoking the right callbacks. I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. The trend around mobile apps and some very successful native apps on the Mac App Store that consume web services seems to me as a best-of-two-worlds approach. > I have a hunch that WebDAV combined with standard HTTP authentication could be the answer. I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server. > I dream of the days when the Web truly does resemble SmallTalk. This would be more like a world with 5 different SmallTalk implementations, each slightly different, and all with a crappy/non-existant standard library and security model.
- IEatShortPeople 14y ago
  I disagree with your idea of running native code on the client as a replacement for the web in the context of laptops and desktops. The app store works because apple curates it. In the Android marketplace, many applications are viruses (http://www.androidguys.com/2012/12/14/lookout-18-million-infected-android-devices-by-end-of-2013/ http://www.androidguys.com/2012/12/14/lookout-18-million-inf...). If more than 9-10% of laptops and desktops had access to the app store, I would imagine that malware would be a more significant problem. Therefore, while I agree with the rest of your complaints, I disagree with the idea of making the web run using native code. I think that an interpreted environment will become good enough to do everything a user wants as computers get faster. In fact, if we can assume the standard user watches Youtube videos and sends and receives images and text through Facebook/Instagram/..., then interpreted code is fast enough today. On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer. Side Note: I also just really, really hate app stores. I find them to be much more restrictive than just throwing a website up and allowing anyone to access it. The idea of having to pay someone to allow users to be able to use my stuff is way too restrictive to me.
neil_s 14y ago
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?
- simon_thepiman 14y ago
  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..
mistercow 14y ago
>I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server. Where does version control fit in this vision?
- shurcooL 14y ago
  Assuming you have access to the repo, it can be pushed either to master or another branch of your choice. If you don't, a fork is automatically created.
shurcooL 14y ago
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 what the article described. There are definitely some very good ideas there. Unfortunately, it wasn't easy for me to figure out how to write some simple programs that print stuff to standard output, and I couldn't really find any samples online. It really makes me appreciate golang.org's Hello World sample right on the front page.
- jcromartie 14y ago
  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.
mshron 14y ago
I'm surprised nobody has mentioned Meteor yet. As far as I understand, developing for Meteor means having a single codebase that erases the distinction between server and client. Your web pages become live views of the underlying controllers. Modifying state in one client automatically modifies it in another. And I'm pretty sure it supports hot-swapping. http://meteor.com/ http://meteor.com/
prodigal_erik 14y ago
It's not the web. The web is presentation-independent semantic information rooted at stable URLs. Single-page javascript is a poorly-planned delivery platform for applications with essentially siloed state that is steadily displacing the web, and no amount of grafted-on functionality can enable the kinds of repurposing and unanticipated reuse we started building before writing off the web as insufficiently shiny.
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
p4bl0 14y ago
I was expecting to see a comparison between stateful object and server and method calling as message passing and api call. So I was surprised but also disappointed: to anyone who has worked with a REPL for instance it's not a big deal to hot swap piece of code. Many programmers use Emacs and do that almost daily in their text editor… And that's how the web was first designed (the first web browser, Mosaic, allowed to edit the page you were visiting, much like giant and distributed wikis or, with nowadays dynamism in web pages and services, much like giant and distributed Lisp machines or Smalltalk images).
dominic_cocch 14y ago
An editor that might no be too well known in the web world, Unity3D's editor, has an awesome way to edit code on the fly. Public variables are represented as generalized form controls like sliders and dropdowns. Very nice for the later phases of development. Tweaking the timing and speed of an animation or the effects of some physics float can be a pain without being able to change on the fly. I wish the web tools had a similar setup. http://docs.unity3d.com/Documentation/ScriptReference/Editor.html http://docs.unity3d.com/Documentation/ScriptReference/Editor...
sutongorin 14y ago
Are you looking for http://amber-lang.net/ http://amber-lang.net/ by chance?
dusty_dex 14y ago
Web development is nuts! We need new web tools and stop trying to fit round pegs into square holes. Too much effort is wasted working around old obstacles. Javascript was meant as a bridge to a Java based browser. That never happened and we're just left with the afterbirth.

111 points by zacharyvoase 14y ago

Tim Felgentreff did some cool work on remote debugging with MagLev. The video is pretty sick: http://blog.bithug.org/2011/09/maglev-debug http://blog.bithug.org/2011/09/maglev-debug

russellallen 14y ago

Another approach to this type of thing worth checking out is Dan Ingall's Lively Kernel http://lively-kernel.org/ http://lively-kernel.org/

Turing_Machine 14y ago
Snap is also worth a look: http://snap.berkeley.edu/init http://snap.berkeley.edu/init (it's a semi-port of MIT's Scratch language).
robertkrahn01 14y ago
Great to see LK come up here. Yes, the approach of Lively goes towards what is mentioned in the article, right now however, the client session (what you run in the JS VM in your browser) is what the image is for Lively. We developed a persistence mechanism that will read/write a JS object graph so that your working state of your session can be saved and resumed, just like a Smalltalk image [1]. We are currently experimenting in distributing LK runtimes in nodejs instances so that basically a network of active runtimes can be created that communicate / exchange objects. Note that the core development moved to github [2]. [1] http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/LinckeKrahnIngallsRoederHirschfeld_2012_TheLivelyPartsBinACloudBasedRepositoryForCollaborativeDevelopmentOfActiveWebContent_IEEE.pdf http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/... [2] https://github.com/LivelyKernel/LivelyKernel https://github.com/LivelyKernel/LivelyKernel

gregmuellegger 14y ago

So you want your live editing beeing persistent? What about testing? I think you should first write a test that fails before attempting to fix it...

vincie 14y ago
Test your code in a Workspace before editing your classes. Depends on the complexity of the change you are making of course. If it is complex, clone the image and test on the clone.
emp 14y ago
Writing a test that fails is a subset of what you can do. Pharo (and other Smalltalks) support writing traditional test cases and running them in a test runner. However you can also: - write snippets in a workspace, as vincie mentioned. - write code against an API that doesn't exist, run it, have it fail, and then fill in the API and implementation. - write stubs that fail automatically, and then fill them out (similar to above). The difference is, when things fail: - you get to play with the live objects in a work space. - fill in missing implementation. - fix any errors. And then much of the time continue execution from the point of failure. No need to restart anything. I simply could not appreciate the variety of options available in a Smalltalk environment until I used it for some fun projects over a few months. Be warned, you might hate your so called modern environments once you get back to them. For Objective-C coders there is hope: http://injectionforxcode.com http://injectionforxcode.com

breckinloggins 14y ago

Chris Granger's Light Table is also trying to do it. Of course, Bret Victor's talk breathed new life into this whole thing. But everything old is new again. People want to build software from a small kernel that scaffolds itself. They want to immediately switch between "testing the app" mode and "building the app" mode. They want something more than a text file, a tool pipeline, and an executable at the other end. On the other hand, they don't want their code to turn into an opaque binary blob that can't be diffed, can't be read by text tools, and can't be shared with people who don't feel like using your sweet "Invented on Principle" tool. It feels like we're converging on the ideal solution, but it's happening more slowly than I think many of us predicted.

DoubleCluster 14y ago
Exactly, I'd love more interactivity but you can pry my plain text source files from my cold dead hands. The smalltalk environment was way too magical and too easy to mess up when I tried it.
trafficlight 14y ago
The Bret Victor presentation for those interested: http://vimeo.com/36579366 http://vimeo.com/36579366 I can't help but smile while I watch.
seanmcdirmid 14y ago
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 does. However, this was originally in Self and relatively independent from Self's hot swapping capabilities. It also didn't really map back to code very well (it was very dependent on direct manipulation via Morphic's edit menu).
- asynchrony 14y ago
  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.

chewxy 14y ago

It only makes sense if you talk about utility webapps (like twitter). Not everything is a webapp though. Wikipedia for example, is just a display of documents. Should it become a fancy webapp? I don't see much benefit in it. The old page concept is plenty fine in many contexts IMO.

malandrew 14y ago
The Browser — A Lament *Binstock:* Still, you can't argue with the Web's success. *Kay:* I think you can. *Binstock:* Well, look at Wikipedia — it's a tremendous collaboration. *Kay:* It is, but go to the article on Logo, can you write and execute Logo programs? Are there examples? No. The Wikipedia people didn't even imagine that, in spite of the fact that they're on a computer. That's why I never use PowerPoint. PowerPoint is just simulated acetate overhead slides, and to me, that is a kind of a moral crime. That's why I always do, not just dynamic stuff when I give a talk, but I do stuff that I'm interacting with on-the-fly. Because that is what the computer is for. People who don't do that either don't understand that or don't respect it. The marketing people are not there to teach people, so probably one of the most disastrous interactions with computing was the fact that you could make money selling simulations of old, familiar media, and these apps just swamped most of the ideas of Doug Engelbart, for example. The Web browser, for many, many years, and still, even though it's running on a computer that can do X, Y, and Z, it's now up to about X and 1/2 of Y. ref: http://www.drdobbs.com/article/print?articleId=240003442&siteSectionName=architecture-and-design http://www.drdobbs.com/article/print?articleId=240003442&#38...
zokier 14y ago
Wikipedia is pretty bad example imo, as it is actually quite advanced webapp of sorts. More specifically, it's a webapp for authoring, collaborating, searching and viewing documents.

indubitably 14y ago

WebDAV? Heaven help us…

DoubleCluster 14y ago
Why the dislike? It's not a bad protocol.
- chubot 14y ago
  From what I remember, it's pretty chatty. It appears to be on its way out. Is there any new software that's using it? WebDAV had some varying levels of support in Windows and Mac desktops. But AFAIK the Windows stuff got broken; not sure about Mac. I think that access from a GUI file browser was one of its main use cases in the 90's. If nobody does that anymore, and I don't think they do, then the protocol will need a new app or it will continue to die.
  - DoubleCluster 14y ago
    I've used it to bolt file storage on a REST API for enterprise stuff. It seems to be a good fit. I'm even using the Windows WebDAV implementation... working around its quirks is madness: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html http://www.greenbytes.de/tech/webdav/webdav-redirector-list.... Note that XP SP3 has the port-handling bug even though it's not on that list.

gamache 14y ago

This kind of hot-swapping can be achieved on quite a few languages; certainly Perl and Ruby in addition to JS, and I'm sure there's a dozen more languages that allow you to redefine at runtime. The difference is that Smalltalk made hot-editing the default. SmallTalk is an uncommon language these days, with the exception of its half-descendant, Objective-C. Ruby borrows Smalltalk's OO semantics pretty much completely. Just sayin'

norswap 14y ago
You can even do it in Java with Eclipse (Notch did it during his screencast), although I don't know the specifics.
- seanmcdirmid 14y ago
  Notch used a special programming framework to get their. Many game engines support similar features; the ability to modify the game world while its running, and can even do that with C++. The problem is you don't get it for free (framework transparent hot swapping isn't good enough), and its only because of special compromises made in the framework that you can get liveness at all.
- drakeandrews 14y ago
  Intellij keeps telling me it has the feature. Although I've never managed to use it on purpose.
martinced 14y ago
"...I'm sure there's a dozen more languages that allow you to redefine at runtime" Indeed. There are all the Lisp dialects to start with. And it's no surprise that hence SmallTalk had this feature too: Alan Kay (+), one of the key creator of SmallTalk, acknowledged the heavy influence of Lisp on SmallTalk: http://www.franz.com/services/conferences_seminars/lisp_50th-birthday.lhtml http://www.franz.com/services/conferences_seminars/lisp_50th... (+) Famous quote attributed to Alan Kay: "I coined the term "object oriented". I can tell you I didn't have C++ in mind."

vincie 14y ago

Check out Seaside, the Smalltalk web framework. It has a edit-in-the-browser mode, where you can pretty much edit anything to make your web app work. Seaside itself is a component-centric framework, not page-centric as most web frameworks are. You build independent components, which you place here and there to make your app.

doublec 14y ago
Clamato, also from Avi Bryant, is an interesting approach to in browser development: https://bitbucket.org/avibryant/clamato/wiki/Home https://bitbucket.org/avibryant/clamato/wiki/Home
- fractallyte 14y ago
  Clamato has been superseded by Amber: http://amber-lang.net/ http://amber-lang.net/ In particular, check out the tutorial page (Smalltalk in a browser!): http://amber-lang.net/learn.html http://amber-lang.net/learn.html
  - doublec 14y ago
    Oh, very nice, thanks!

lispm 14y ago

The language is written as 'Smalltalk', not 'SmallTalk'.

wbl 14y ago

And this makes Cross-Site Scripting even more fun then it already is! We can't even make the browser limit sharing across websites securely: what makes you think that this edit mode will not be a target?

_pmf_ 14y ago

> Well, the way I (and Roy Fielding) see it, the browser is a stateful agent that just renders HTML to a viewport, and executes JavaScript. I cringed.

jhonicker 14y ago

You might try looking at http://amber-lang.net/ http://amber-lang.net/ as a test for your ideas. It's a Smalltalk implementation running in JavaScript.

CoryG89 14y ago

I can't believe that the fact that Chrome can hot-swap code is surprising to anyone... Have you never been working on an app, opened up the console, changed a variable or function definition and seen the effect in real time?

error54 14y ago
I'm with you on that. It's the surprising the number of web developers who are just now finding out about this which leads me to another questions, what tools do they use if not Chrome Developer tools?
- shurcooL 14y ago
  I imagine a text editor, terminal, browser, and a lot of Alt/Cmd+Tab, F5/Cmd+R, Ctrl+C+up+enter. But I can't say for sure.
  - error54 14y ago
    Those are general tools. I want to know what tools people use for debugging Javascript that are similar to Chrome Developer tools or Firefox's Firebug.
    - cdcarter 14y ago
      I believe the implication there was that the debugging process is "try, try again".
      - error54 14y ago
        Haha ah thanks for the clarification cdcarter. That is a process I know all too well when debugging code in Internet Explorer 8.

calinet6 14y ago

I read the title and had some first thoughts spring to mind, and didn't reach the same conclusion as the author. While cool it was, it was limited in reach, and I think you could go further with this analogy. Treat every web site or address or endpoint as an object. Allow message passing as though the web were simply a single object-oriented system resident on the same computer. The definitions of the APIs are kept as standard, so the system "just works" with any site. This is, of course, the vision of APIs. But could we do better? Could we make it closer to a true object-oriented system, even simpler to use? Not sure if it would make a big difference, but as we know, sometimes a simple thing that makes connections easier can make a huge difference (eg: XmlHttpRequest). Make the web as easy as smalltalk. For every API, and eventually, every site. Not just the ones we decide to make language-specific libraries for. One library per language just interfaces with "the web" as a fully-generic API you can access as easily as any object. Just thought I'd share this thought. Any thoughts or ideas?

njharman 14y ago
You just described http. Every URL is am object and the post,put, et al are the messages.

phillmv 14y ago

I felt this way when I first saw better_errors: https://github.com/charliesome/better_errors https://github.com/charliesome/better_errors It's a little surprising how much we keep reinventing.

codewright 14y ago
Stuff like that has been in Python for a long time. (Werkzeug)
- phillmv 14y ago
  That sounds like a clone of Rack, that doesn't support the latest version of Python.
  - codewright 14y ago
    Few that aren't running a charity use Python 3 in production web apps. Rack <-> WSGI Werkzeug is just an app server on top of WSGI that happens to be very nice, with features like the above described.

emp 14y ago

I hate to be picky, but it's Smalltalk, not SmallTalk.

hcarvalhoalves 14y ago

> 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 be used to run a general application instead of simply navigating hypertext, it's original purpose. All that because there's incentive in keeping users inside walled gardens and holding a ransom on their data. It's unbelievable we take as granted reinventing the wheel over and over again, dealing with weak standards and APIs designed by committee, fighting browsers into rendering interfaces and invoking the right callbacks. I would rather take a web based on open APIs and rich clients (running native code) than the kludges we have today. The trend around mobile apps and some very successful native apps on the Mac App Store that consume web services seems to me as a best-of-two-worlds approach. > I have a hunch that WebDAV combined with standard HTTP authentication could be the answer. I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server. > I dream of the days when the Web truly does resemble SmallTalk. This would be more like a world with 5 different SmallTalk implementations, each slightly different, and all with a crappy/non-existant standard library and security model.

IEatShortPeople 14y ago
I disagree with your idea of running native code on the client as a replacement for the web in the context of laptops and desktops. The app store works because apple curates it. In the Android marketplace, many applications are viruses (http://www.androidguys.com/2012/12/14/lookout-18-million-infected-android-devices-by-end-of-2013/ http://www.androidguys.com/2012/12/14/lookout-18-million-inf...). If more than 9-10% of laptops and desktops had access to the app store, I would imagine that malware would be a more significant problem. Therefore, while I agree with the rest of your complaints, I disagree with the idea of making the web run using native code. I think that an interpreted environment will become good enough to do everything a user wants as computers get faster. In fact, if we can assume the standard user watches Youtube videos and sends and receives images and text through Facebook/Instagram/..., then interpreted code is fast enough today. On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer. Side Note: I also just really, really hate app stores. I find them to be much more restrictive than just throwing a website up and allowing anyone to access it. The idea of having to pay someone to allow users to be able to use my stuff is way too restrictive to me.

neil_s 14y ago

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?

simon_thepiman 14y ago
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..

mistercow 14y ago

>I’m not 100% sure on it, but I can easily envision a world where you fix bugs in your website by opening it up in a browser, reading a stack trace, fixing the JS in that same browser and persisting your changes back to the server. Where does version control fit in this vision?

shurcooL 14y ago
Assuming you have access to the repo, it can be pushed either to master or another branch of your choice. If you don't, a fork is automatically created.

shurcooL 14y ago

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 what the article described. There are definitely some very good ideas there. Unfortunately, it wasn't easy for me to figure out how to write some simple programs that print stuff to standard output, and I couldn't really find any samples online. It really makes me appreciate golang.org's Hello World sample right on the front page.

jcromartie 14y ago
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.

mshron 14y ago

I'm surprised nobody has mentioned Meteor yet. As far as I understand, developing for Meteor means having a single codebase that erases the distinction between server and client. Your web pages become live views of the underlying controllers. Modifying state in one client automatically modifies it in another. And I'm pretty sure it supports hot-swapping. http://meteor.com/ http://meteor.com/

prodigal_erik 14y ago

It's not the web. The web is presentation-independent semantic information rooted at stable URLs. Single-page javascript is a poorly-planned delivery platform for applications with essentially siloed state that is steadily displacing the web, and no amount of grafted-on functionality can enable the kinds of repurposing and unanticipated reuse we started building before writing off the web as insufficiently shiny.

deleted 14y ago

[deleted]

deleted 14y ago

[deleted]

p4bl0 14y ago

I was expecting to see a comparison between stateful object and server and method calling as message passing and api call. So I was surprised but also disappointed: to anyone who has worked with a REPL for instance it's not a big deal to hot swap piece of code. Many programmers use Emacs and do that almost daily in their text editor… And that's how the web was first designed (the first web browser, Mosaic, allowed to edit the page you were visiting, much like giant and distributed wikis or, with nowadays dynamism in web pages and services, much like giant and distributed Lisp machines or Smalltalk images).

dominic_cocch 14y ago

An editor that might no be too well known in the web world, Unity3D's editor, has an awesome way to edit code on the fly. Public variables are represented as generalized form controls like sliders and dropdowns. Very nice for the later phases of development. Tweaking the timing and speed of an animation or the effects of some physics float can be a pain without being able to change on the fly. I wish the web tools had a similar setup. http://docs.unity3d.com/Documentation/ScriptReference/Editor.html http://docs.unity3d.com/Documentation/ScriptReference/Editor...

sutongorin 14y ago

Are you looking for http://amber-lang.net/ http://amber-lang.net/ by chance?

dusty_dex 14y ago

Web development is nuts! We need new web tools and stop trying to fit round pegs into square holes. Too much effort is wasted working around old obstacles. Javascript was meant as a bridge to a Java based browser. That never happened and we're just left with the afterbirth.