> 1. Is it possible to write complex, modern applications (things like browsers, photo editors, etc. — things that would take millions of lines of Java or JS) using this style of programming?
If it were a complex application it wouldn't be very forthy would it? Factor the problem instead of trying to factor a preconceived solution.
> 2. What is “sourceless programming”? Where is a good place to learn more about it?
Sourceless programming was used in Okad a vlsi design tool written by Chuck Moore.
> Portability is not important. Portability is not possible. Real applications are closely coupled to hardware. Change the platform and all the code changes. If it didn't, you wouldn't have changed the platform.
In a forth-like language, you can think of all functions as implicitly being unary: They take a stack, and return a stack.
I've never used any other kind of concatenative language, so I'm less able to speak to them, but I'm guessing some similar situation applies for those as well.
> Anarchism is a political ideology that's never met the real world, like a lot of ideologies on HN and elsewhere. This might convince the random Internet reader, but it's not going to convince anyone who has studied the topic.
Although there have been some widespread and fairly comprehensive implementations of anarchism, namely the Makhnovists in the Ukraine and the Spanish Revolution in Catalonia, Aragon, Andalusia, and some parts of the Valencian Community, anarchism is more of a political tension "from where you are standing right now" than an attempt to conquer a territory to establish anarchism. That should follow from the name itself.
The Situationist movement had some enduring effect on French culture from the first-person perspective. (Situationism is not anarchist, but it is libertarian and communist). The Spanish revolution less so, because it was followed by General Franco's rule.
I'm aware of anarchism's role in the Spanish Revolution, but I'm not sure what we can really say about that experience. It lasted a very short time, mostly due to factors outside of its control, but also because it was part of an unstable political front with the communists and other liberals. How much of that instability was due to anarchism itself? It's difficult to say.
Don't mean to sound anti-anarchism, because I understand the sentiment. Thanks for more examples. Also:
With all due respect I would have liked if the hackernews moderators had kept my original headline "An Anarchist Critique of Democracy by Moxie Marlinspike (Signal SMS), Windy Hart"
I thought this article/transcript was of interest to hackernews in a large part due to one of the two authors being the author of the Open Whisper Systems Signal SMS app.
I understand the feeling, but we've learned from experience that HN works better when the focus is on content rather than personalities, especially in titles.
We've also learned that HN can't really have a substantive discussion about ideology. Something about open internet forums causes such discussions to revert to the mean, and from there to the bottom of the barrel, pretty quickly. But at least your submission was off the beaten track!
> Gopher and IRC make it possible to use any client of your choosing, thus keeping innovation and improvements accessible to anyone with an idea.
I agree to the former and disagree to the latter---they are not correlated. In fact, IRC has demonstrated that it might be hard to adapt to new requirements without breaking many things (no matter it's an existing client, a community or a requirement itself). Today the relevance of IRC is mostly due to the existing community and not due to the technical innovation, and casual users wouldn't benefit from that. I don't know much about Gopher but I haven't seen any counterevidence to this observation.
The new(ish) IRCv3 standard does not break compatibility with existing clients though. If they don't support all of its features, they just have less things displayed.
The web is like an operating system that you are locked into using. This prevents alternative operating systems such as Plan 9 from ever becoming useful, because building a web browser is such a monumental effort. Even if a decent web browser were built for Plan 9 it would defeat the purpose of using such an alternative OS because the web binds software to content.
The web has effectively killed innovation in operating systems. A clean and consistent system will be out of reach as long as this web app nonsense continues.
I think this is the wrong way around; Plan 9 prevented itself from becoming useful by changing everything so thoroughly that building an actual web browser was pretty much impossible. It was more or less guaranteed that APE (The "ANSI Posix Environment") would die from neglect. This neglect seemed intentional and people seemed happy to run plain white windows with black borders and congratulate themselves that their system neither had nor needed the massive shared libraries that Unixen of the time seemed to need.
The lesson seems to be, rather - don't build an operating system that can't build up enough infrastructure to run a browser. This is maybe less forbidding than, say, being forced to build an operating system that can support an entire Windows subsystem.
I have trouble understanding what it is that people want when they say they want "innovation" in operating systems. It seems like almost anything that was practical to do in the period when I worked with Plan 9 is now eminently practical and far more performant in user space; so why not go build it on top of a minimal Linux kernel and save yourself the trouble of building a gazillion drivers, boot loaders, etc.
Web desktops may be the next step. As much as people are joking about running Javascript on metal, the idea of running a universally accepted virtual machine (WebAssembly?) and building a high level language and operating system on top of it seems to have some merit. See also
the idea of a web desktop doesn't make sense when we have services like google docs and dropbox that perform the roles of the desktop without the overhead of installing software. The desktop was a forced requirement while content had to be centralised on your PC, why bother with it now that we're freed from that constraint?
> The desktop was a forced requirement while content had to be centralised on your PC, why bother with it now that we're freed from that constraint?
Because some of us want content to be centralized on our PCs. We want to own our data, instead of giving it away and then renting back access to it. Related, I consider the push towards abstracting away the file system to be a very bad thing.
I agree with you completely, especially given all the revelations that have come out about dragnet surveillance, but the OP was talking about web desktops specifically.
Have you ever thought about the fact that most people don't like innovation and don't need it? They want and need well tested incremental updates to proven technologies.
There is still innovation happening in operating systems, it just doesn't reach mass adoption because most of it doesn't provide real-life benefits to the mass market. Some of the more practical aspects trickle down to mainstream OSes.
We're past the Wild West stage of operating systems. You win some, you lose some.
In my view the web is a very successful demonstration of language-based security in the OS. It's quite natural that the web has essentially became a full-featured (and half-baked) operating system because it has to handle everything in order to keep the language-based security and relevance. Therefore I would argue that the innovation in operating systems has not been killed---it has been shifted to the different realm.
The web, at least the part most people interact with, is more like a throwback to leased terminals.
The real computation happen on a far away pile of hardware, with the local computer just being responsible for drawing the updates on screen based on the results coming over the wire.
I disagree, while writing a web browser would be significant work, it would likely be on the same order as writing an operating functional enough for people to actually want to use it. Porting a browser would likely take less work even (while still being a significant amount of work).
Forgive me, but you should more specifically define the terms you use. As it stands, it looks like by "functional enough for people to actually want to use it" you seem to introduce a circular dependency -- as though an OS is useless unless it's easy to port a browser to it.
The GP post mentiones Plan 9, which is a great example here. There are real people who use Plan 9 every day (I have met some of them!) but Webkit will never be portable to that OS because there is no C++ compiler. This doesn't make the OS non-functional, but it does mean step one to porting a modern browser is "port GCC or LLVM," which is a massive task by itself.
Both Firefox and Chrome source code repositories are in the hundreds of megabytes, even without the required host OS dependencies vendored in. The document you linked to recommends leveraging freetype, cairo, and all kinds of other things that would require serious graphics infrastructure of a sort that's just not feasible.
Modern web browsers are keystones that cap off arches built of hundreds of pieces of very specific software. As time goes by, they require more infrastructure, not less -- c.f. Firefox, where to build the latest version you must also have a Rust compiler that targets your operating system. As the checklist of requirements grows ever longer, the candidate operating systems capable of meeting those requirements grows ever shorter.
Five years from now, I predict the only three operating systems capable of interacting with the web in any meaningful sense will be linux, macos, and windows; bsd and haiku et al will have been left by the wayside.
Ten years from now I predict there will be four operating systems, and one of them will be Fuchsia, because only a megacorp like Google has the resources to accomplish that.
> Five years from now, I predict the only three operating systems capable of interacting with the web in any meaningful sense will be linux, macos, and windows; bsd and haiku et al will have been left by the wayside.
That is an interesting prediction. What do you think will cause the BSDs to be left by the wayside in such a short timeframe, when they are more than capable of running the latest browsers right now?
Is the browser becoming a systemd module?
I am a little concerned about the trend to push "hardware acceleration" into everything. Graphics cards and their drivers are the biggest source of grief in PCs for me.
One intriguing direction we could take is for someone to make a self-hosting browser. Doing that would mean taking all these technology dependencies and moving as many as possible into wasm, until you're just left with the kernel, a "barebones" wasm runtime, and a browser binary. I think that is within the reach of one of the big-leaguers, albeit ambitious and full of "interesting" problems and standards that will have to be broken.
I'm no expert, but I believe the difficulty in writing an OS lies with the myriad of different hardware configurations you have to support. Writing drivers for poorly documented hardware is difficult. You don't get around that complexity by writing a browser. That's just an additional effort you have to make.
The point seems to be you could now use any system you wanted (as long as there is a compliant browser) and not worry if your needed app is supported or has all the features of the Windows/OSX version.
This lets you take advantage of whatever benefits your desired system provides you without a change of user experience.
I think I understand your argument now. Why do you think browsers as de factor operating systems is wrong? Their programming interface is highly standardized across implementations.
> Their programming interface is highly standardized across implementations.
It may be easier to have everyone use the same software and hardware platform everywhere. After all we do want interoperability and we do want everyone to play well with others, but, standardization and portability is a push to stop people from trying new things. The push to standardize everything is an unfortunate consequence of not having a separation of concerns, separate concerns such as content and UI.
A smaller contact area between implementations means we need only be concerned about compatibility at that interface and the rest is up to you. This keeps the area of software that we can't change to a minimum.
> A clean and consistent system will be out of reach as long as this web app nonsense continues.
Isn't that exactly what iOS and Android are though? I mean most of the criticisms of iOS are against Apple's obsessive curation of it's simplicity and usability, and it 'came to power' smack in the middle of the internet age. People are always complaining that native apps for internet services are a threat to the web. It seems to be exactly the thing you're saying the web makes impossible.
Dunno. Initially iPhone was not supposed to have apps at all.
Apple even release a web framework for making sites that looked and behaved as if it was native to iPhone.
Only after the jailbreakers enabled third parties to fool around with the guts did we see apps happen. And initially Jobs wants to sue those app devs and distributors into oblivion.
Yes, Jobs did a song-and-dance about web apps but not because they didn't want 3rd party apps but because Apple wasn't ready to support developers on what was a new platform. Apple plays it safe.
For one, it's not consistent with the timeline and secondly as the jailbreakers discovered there was quite a bit of infrastructure to support apps even in iPhone OS 1.0.
* iPhone release date: June 29, 2007
* iOS SDK Announced: October 17, 2007
* iOS SDK Released: March 6, 2008
* iPhone OS 2.0 release date: July 11, 2008
Apple had such a tough time providing enough support to developers that they restricted access to the paid developer program to just 4000 (Apple said 25000 tried to join).
There wasn't enough time for everything to happen (including relatively sophisticated tools like the iPhone Simulator) if it was just a reaction to jailbreaking.
Furthermore, the OS itself was initially developed for tablet computers, so apps would have been crucial. Adapting it to a Phone platform with a more limited initial scope was a fairly late stage pivot.
You mean web apps?
Because the web itself was fine till everyone started thinking that anything on the web must be an application. And that web must "win" mobile for some reason.
You'll understand that "some reason" when you'll want some cool, fancy, useful app and the vendor will have not developed a version for your current mobile OS.
Web apps have been the default approach for over a decade now. The O.G. vision of the web / netscape was to have a virtual OS, platform independent. I think it's time to lay the idea of the webapp as somehow being this alien thing to rest...
compile a linux desktop to the web (webassembler/jslinux), style your gui to look like your brand, users are logged into x11/wayland as guest by default. logging in looks like you're on a website but in fact you're in a linux session. you code your apps in gtk/kde (whatever) and html/xml (or something more sane) is only used for the layout of those apps.
"Chuck Moore, the inventor of Forth and ColorForth programming languages, gives a presentation on writing "1x software," or how to avoid common sources of bloat in software. Topics covered include: what it means to be Forth (as distinct from other languages), how ColorForth is simpler still than Forth, how common system services such as files, windows, and even local variables, complexify (complect) the software, the impact of bloat, maintenance on that bloat, etc. And, as is usual for Chuck, deeply philosophical thoughts as well."
Basically, you can build a cathedral per project. It will be elegant, all parts will be purely sufficient and focused on getting the pieces of that particular project working.
But when the project changes in certain ways, that bespoke foundation no longer suffices. Time to take the wrecking ball to it and start building a new cathedral.
It is technically true that you can reduce the sheer amount of code involved with a running program, but I for one would not wish to. I would rather inherit the problem-solving, optimization insights, and compatibility tackling of others inherent in OS modules and libraries (along with their "bloat" and complexity), than carry all the weight of non-project-specific development from bare metal. This is a statement of scope and time as well of that of surface of opportunity for bugs and weaknesses.
I would still point out that that article focuses on bringing everything into the small. Redefine problems so you're not tackling large monstrosities, but simplified versions. Make it so that it neatly fits in little bits of code that directly computes simple things.
That's all well and good, but some people are building web browsers, or distributed AI databases, or even large chip development suites that do things that certainly wouldn't fit in 500 lines of Forth. Forth is a great expression evaluator, and has actual compile-time metaprogramming features, which is nice. But it doesn't solve actual large problems for you. It asks you if you can solve a non-large problem, and if you can, you're happy with Forth.
It's sort of like retro programming. You can work in a small (architecturally conceptual) scope that handles a few things elegantly, and implement some cool project within those constraints and building blocks. But it's still building a little cathedral per project.
For "large" projects you do as every other language does: you link/FFI to the C library that does the heavy lifting for you.
It's kind of unfair to say "forth can't do browsers" when all browsers are implemented in C/C++ at the core.
You link to C when you need speed, and that's not even usually necessary anymore in languages like JavaScript or Lisp. Linking to C doesn't let your code somehow abstract higher, to deal with larger projects and larger architectural scopes.
https://www.youtube.com/channel/UCVMrX6BlNjIeGfX0QcBobGg