Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It really is amazing.

I feel like there is a similar mismatch and almost backwards progress when you look at the concepts and tools behind smalltalk and the concepts most working programmers today reason with and are familiar with.



I think the huge focus on web development set CS back at least two decades in certain areas. The industry has been so intent on reinventing applications through the browser, it's lost ground in what can happen in areas like Engelbert's or Smalltalk or real hypertext.


I love Smalltalk, but it has some problems with it that are solved by the web browser.

Firstly, Smalltalk is a computing environment built around the concept of Personal Computing. You can open up and redefine the functionality of anything running on the system. This obviously makes it very prone to abuse. It was a system that was not built on the principles of running any random source code coming from a foreign party. The focus of the system was to elevate the concept of computing for the individual.

The web browser, on the other hand, has been built from the ground up on the principle that it would be running foreign and inherently untrustworthy code.

The web browser is approaching what Smalltalk was aiming for, however, with a focus on running code in a secure, sand-boxed environment. I don't feel like this is an inherently conscious trajectory but the fact that JavaScript has significant influences from Smalltalk-80 has probably helped to guide this path.

The advancements in networking and multimedia present in HTML5 are allowing for this sandboxed and restricted environment to more fully express it's influences from the Smalltalk systems.

Secondly, the open nature of the web browser and it's standards have encouraged adoption whereas the closed and proprietary nature of Smalltalk systems played a large role in it's "failure".

Designing by committee and standardization has it's pros and cons, but ultimately it promotes adoption and helps a system to survive in the overall ecosystem of computing systems.

I don't blame the web for the death of such amazing computing platforms as Smalltalk and Lisp machines, I blame market mechanics.

Microsoft succeeded with it's approach to Personal Computing because it focused on what the customers demanded for their short-term business goals, rather than some enlightened ethos of enabling humanity through better tooling. These corporate customers actually benefited from the opposite. Lack of control over a computing environment was seen as beneficial to the overall goals of the organization and is the antithesis of the goals of Smalltalk.


If you think of technology progress as a global simulated annealing problem, it is ok to step back a bit to get out of the local maxima. Web Dev may have taken us back 20-30 years in certain areas but once caught up, it can take us much further than the previous methods could have ever expected us to. The previous methods in this case being, compiled software that require specific devices/OSes and require a very high level of competency in all aspects of development.


Web solutions also require specific devices and web browsers, really; I can't think of a single jaw-dropping JS demo around here that didn't meet with several complaints related to it simply not working under certain browsers (and a lot more complaints about performance). Aye, if you put enough time and hacks into it, you get it to run on pretty much any browser. Until the next update, that is.

> require a very high level of competency in all aspects of development

Crude tools, development methods and principles are a surrogate for simplicity, not an actual manifestation of it. Barring the fact that you sacrifice performance, code maintainability and, to a high extent, security, I also think the question of productivity remains open. I find it stunning that young web developers are ecstatic about how their tools allow you to get from idea to result so quickly, when they are pretty much on-par with where Motif was in the mid-'90s. Not to mention the truckload of CSS hacks you need to make something that looks like a button (but without native looks) out of an anchor-that-really-shouldn't-be-a-button-but-it's-the-closest-thing-html-has-got. I don't think that can take us much further than compiled software could have taken us -- and slowly, but surely (with stuff like asm.js), it looks like a lot of people are rediscovering that.



I think we both know that's not what I was referring to. It's stuff like this one (PhoneGap, but really, it's like this almost everywhere): <a href='#' class="button header-button header-button-left">Back</a>. Unless I am mistaken and you can build the whole UI out of form elements (perhaps you can, but I'm not sure I've actually seen that done anywhere), that's simply not sufficient.


I took your comment to mean that no button element exists, but I suppose that was not your intention. But I did realize you were referring to links being abused as buttons.

I think the issue is simply that buttons tend to have more default styling you need to override, which is more likely to vary across platforms since the default style is generally chosen to mimic the system's native buttons. Whereas default styling for links is quite simple across all platforms. Besides that, there is no particular problem with using real button elements instead of link elements as far as I'm aware, just a matter of habit and convenience.


We had to focus on the Web as a platform because all other platforms failed to evolve, they reached their "nirvana point" where most things just worked, but they just stopped there. The twisted and contorted fucked up mess that we call the Web, that shares more with the Unix philosophy of "worse is better", has somehow managed to keep growing and evolving and will soon leave everything else in the dust, even if it will never get close to any "it mostly just works" point and it will never be better at any particular thing than anything else... it will just be "better overall" and it will keep growing, and businesses love growth so they will keep betting on it.

I think we need to concentrate on steering the Web's growth in the right direction, instead of bitching about how much it set us back (and I agree, it did, but it's a "platform cost" that was/is worth paying if you want to "ride the wave" instead of sinking with your favorite ship and then swimming back to the surface every time a new Smalltalk ship show up floating, then sinks and then a new one comes and so on... as an example, even choosing to develop a desktop app or a native iOS app instead of an HTML5/Javascript one with minimal backend is basically "riding a sinking ship", even if you'll make profit out of it and even if you'll deliver a better product to the customer).


I don't see that web platform's developers chose to reinvent anything. I would put the blame to Microsoft and other closed system makers of 80's and 90's which prevented development of cross platform applications for open content production and consuming. Thus everything OS's can do (and did even in 60's and 70's), needs to be re-implemented in the browsers, in aggreement. This too has taken a long time for precisely same reasons: companies waging war over platforms to lock users in, embracing and extending fledgling standards.

Web development tools are the best we can use these days if we want to reach the broadest audience, benefit from each others experience and further enchance the platform. Other tools make us choose one walled garden where development is rosy and ideas old, all the while hoping it stays alive long enough. I hope web can do what Engelbart's system did in 1968, but this time as open source, documented, findable and usable by every user with every device connected to the same truly global network.


Yes, exactly. It is the reinventing of his goals that is painful.


I never had more than a passing interaction with a full blown Smalltalk-80 environment, but that was enough to make me look at e.g. any Java system and just feel sick to the stomach.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: