I've been thinking some lately about systems that express the idea of programming as an ordinary computer use...systems that don't draw a distinction between users and programmers...systems that don't distinguish between programming them and using them. Earlier today, I was writing a demi-argument in response to a complaint about Windows 10S not having the Linux subsystem based on that idea and how it related to the replacement of "programming" with "development" and part of that reply was enumerating systems that treated "programming" like using.
That's when I remembered Amaya which I first stumbled across back in 2007 or so when I was trying to figure out how to build a website for my practice (pretend work that was easier than trying to dig up clients on the cusp of the recession). What is interesting to me is how diverse browsers were in the days before Chrome. The old Opera is another example of what a web browser could be...or could have been.
This post reminded me that Richard Stallman related something like this (an aside in [1], which is mostly about Lisp history from his point of view).
> Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
There's a similar phenomenon with Excel. People will put together amazing things with Excel formulas. Sometimes these things are effectively line-of-business applications. But it wouldn't even occur to them to call themselves programmers. They're just "good with Excel".
Many others have also commented on the significance of the 8-bit TV computers booting to a BASIC interpreter rather than something to launch "apps" made by "developers", which I suspect was already part of your exploration.
Speaking about booting to basic, i seem to recall that the idea was for the RPi to boot to python or some such.
These days it seems to have morphed into a basic ARM Linux computer (not that i am complaining, especially with the likes of Pi-top making laptop and desktop "cases" for them).
The net today has become what the cable box with a modem tried to be, a way to make TV shop a one button interaction.
While the net was all about files/documents the idea may still have had a chance. But with the dot-coms came the money, and with the money came the crooks.
These days even FOSS projects operate with a sharp delineation between user and programmer. And don't use the term power-user within earshot of them...
"But with the dot-coms came the money, and with the money came the crooks."
Correct, it's why nowadays I go out of my way to avoid much of it thus have time for more productive things (it's reason for my cynicism in the reply comment re JS further on hereunder). :-)
It could have all been so nice, if X(HT)ML would have found more support on the client side, as well as on the httpd server side. I am thinking about XIncludes, URL-endocded XPath and places like Wikipedia defining their own namespaces.
You don't need XML/XHTML for structured markup and document-oriented web pages. SGML, on which HTML is based (or was based on originally), and which still can formalize HTML in all its glory [1] (my project), is much more capable and user-oriented than XML anyway.
XML was devised as an "easy" subset of SGML to eventually form the basis of HTML, SVG, and other web vocabularies; it just didn't make it into the mainstream web. But that's no reason to give up on formal methods for content engineering alltogether. I can assure you SGML works just fine for the modern web.
Now if you mean that web standardization as a community-driven process has come to an end years ago, and has been taken over by Google et. al. in the form of WHATWG, with folks cheering at taking HTML out of the hands of W3C, I agree this is an unsustainable situation given the importance of HTML (though, personally, I also like HTML5 and what WHATWG has been doing).
Exactly. It's an artifact from a time when the grand vision of the Web was to be much more participatory and collaborative, much like how we think of wiki sites today. In those days the goal was emphatically not to create yet another channel for the unidirectional flow of content from producers to consumers.
Great tool. I used it intensively from 97 to 2006. It was the only tool roughly equivalent to dreamweaver available for linux. Made me learn a lot about w3c standards
I remember Amaya very well and I was annoyed when the W3C ceased to develop it further.
The big question is why the W3C failed to continue to develop it, as there was (and still is) a big need for a good 'reference' HTML editor.
Another big question that has never been satisfactorily answered for me is why most WYSIWYG HTML editors are so terribly—really horribly—bad[1]. One only has to look at the code they generate even on the simplest of text to realize this.
I think I've probably answered my own question here, in that the W3C couldn't actually make a decent HTML editor—certainly not one that could produce good reference code—so it just gave up!
Isn't it rather ironic that the very 'keepers' of HTML were unable to do this. It seems to me this tells us a great deal about the intrinsic inadequacies of HTML itself and I'm forever surprised there's very little ongoing debate or complaint about it. Thus—in the absence of any such criticism—the W3C has 'forgotten' fundamental matters such as mark-up formatting (limitations thereof, etc.) and is now more worried or concerned about keeping the Big End of town happy with ancillary junk such as DRM.
____
[1] For example, take the terrible HTML editor in Thunderbird email, it's been around for many years now and has had much time to evolve into a proper editor but it's still essentially a joke when it comes to editing/producing good HTML. It's open so anyone could have a go at fixing it (if it was easy to do then by now presumably someone would have done so).
If you want proof of how bad it is then just install the ThunderHTMLedit add-on which lets you view (then if you want edit) the editor's code. [For instance, it cannot automatically concatenate multiple/repeated <xyz> </xyz> - type operations, which (along with similar elementary coding stuff-ups) I often find myself manually having to clean up].
You're absolutely right of course. Even without JS, it's hard to think of a system that could be messier and more convoluted than the way we now mark up web pages. Not that this problem is unique to web pages, desktop publishing and wordprocessors still have and have always had similar issues (similarly the lack of coherent rules for cutting-&-pasting between pages generated by different means—i.e.: the ongoing matter of formatting distortions, etc. after pasting).
This has always seemed strange to me as you'd think that replacing handwriting onto paper with a systematic standardised format/methodology for displaying writing etc. onto computer screens/printers would have been considered one of the most basic and fundamental tasks for computer solution but unfortunately it's never been so.
Consider the following still-unsolved problem of writing (or annotating) between the lines or in the margins of computer-generated text. Right, it's dead easy to do if one wants to scribble by hand in the margins of a book or on a sheet of paper, etc. but it's nigh on impossible to do it electronically. (Given that we've now had electronic computers for some 70 or so years since WWII, this, I reckon, is very strange indeed.)
___
Incidentally, I consider JavaScript an abomination (at least in web pages). By default, JS is turned off on my browser and I only turn it on when strictly necessary, which in practice is about 3% of web sites I visit. Moreover, sites that require its use up front or refuse to display the primary/home page without it are clicked-off as fast as my mouse-clicking reaction time is (there's always a plethora of similar sites without such issues). This way, I avoid the most egregious of the junk that often appears on web pages and my browsing is very significantly faster (not to mention much more satisfying).
Amaya was written in like 1997. Definitely didn't make sense then; doubtful that running as a JS app (as opposed to just augmenting the browser runtime with editing bits) is a big advantage now.
It depends on what "inside" means. Amaya was designed to author web pages in the days when user created mashups was a mainstream idea about what it meant for ordinary people to browse the web. It was a world view where creating something like a Geocities page was normal use of the web and not something that only professionals did while lay users just consumed content. Or to put it another way, Amaya is of a time when instead of complaining about the layout/font/noise on a web page, the user might just mashup their own version and look at that instead.
If inside the browser means as part of the browser application, then Amaya already has it inside the browser. On the other hand if it means in a browser tab, then there's all sorts of issues with cross site security and such that make mashing up several pages difficult...and in modern browser designs increasingly impossible.
My professor suggested to use either Amaya or Adobe Fireworks in a web programming class. I tried to use Amaya at first because it's free and open source but I ended up using Fireworks...It's a bit shame that this kind of project is abandoned.
