Hi (I'm not sure if my initial attempt to comment submitted - so I'll post again. Sorry if this ends up being a duplicate). I'm a fiber optic technician who is also a hobbyist programmer. I have written some small applications to help myself and my colleagues do our jobs, although I have never been paid to develop software. I actually studied programming at a small technical college after I finished my masters degree in an unrelated field (Music, MANY years ago). I used to use Java, but have migrated to Clojure for my projects these days. I enjoy lurking here and on Lobste.rs, although sometimes the articles are over my head. Not being a professional programmer, I'm not immersed in the technologies many of the submissions refer to, and a lot of the mathematical or physics related submissions are difficult for me to grok. I enjoy the attempt though, and hope that I learn something.
Feel free to debate my point of view, but I'd argue that staying would be essentially "re-founding" the company. Because senior engineering experience is gone and in it's place, a team composed of only people with <6 month experience with the codebase.
If I found a company, I'd like to be able to choose the product concept, choose who I work with, and start with a fresh cap table / debt load, etc.
Is this a product you believe in enough to (re)-"start" a company for? Are these the people you'd pick for starting a company? What's the financial situation?
What do folks think of my current strategy: never ever use the horrible euphemistic IP term, and instead use the terms "Intellectual Monopoly Laws" or "Intellectual Slavery Laws"?
I think Free Software needs to stand up for the truth. I think Intellectual Monopoly is a fine and accurate term, but I think anytime someone uses the IP term you need to counter with the Intellectual Slavery term, because IP laws don't have any logical connection to property but instead are a restriction on someone's freedoms--which is by definition slavery.
I think it's time to go on offense against the IS industry.
I know I'll be an outlier here, but I'm going to say it anyway: Total BS!
Browser technology in general* is horrible and its design is atrocious. It's lack of capability and the bureaucracy the standards committee impose only serve to limit real creativity and drown anyone who tries a novel approach to anything.
It's absurd to make the statement "browsers provide what users need". That's entirely subjective and users can't know what's even possible when developers are prevented from providing better options.
Scrolljacking is the perfect example of this. People don't implement scrolljacking because the scrollbars do everything that's required of them they do it because browser tech sucks and the developer is then forced to make trade-offs.
We shouldn't be telling developers not to scrolljack (which only serves to stifle creativity) we should be telling browsers to smarten up and lessen the trade-offs developers are required to make.
“WEIZSÄCKER: History will record that the Americans and the English made a bomb, and that at the same time the Germans, under the HITLER regime, produced a workable engine. In other words, the peaceful development of the uranium engine was made in GERMANY under the HITLER regime, whereas the Americans and the English developed this ghastly weapon of war.”
Will we every truly know why people do what they do? :-)
I suspect programmers/designers with no visual impairment do not consider accessibility at all times. Or, it's just a matter of preference, such as wanting a color scheme with little contrast which is subjectively easier on the eyes. I guess this is where the Stylus browser extension comes in handy.
Nope, sorry; struggling with the right height myself at times I placed some (half read ;) books under the table legs. Being able to easily adjust the heights of both chair and table would be a good ergonomical feature. I guess it can be hard to find the right setup, just like finding the right bicycle geometry …
As strange as it looks, it's a fairly conventional forthlike language. The biggest direct impact of sticking the system on top of ZigZag is that tokenization is no longer necessary; the second biggest one is that alternative paths are visually parallel in the code the way they are in flowcharts (instead of one being in front of the other in a linear stream).
If anything is unclear, don't be afraid to ask. Relatively few people clearly understand ZigZag, which makes understanding how this fits in a lot harder, & I don't always explain this stuff well.
> at no point has Kay attributed malice or otherwise nefarious ends to the reasons for which his ideas went unrealized.
Neither do I. It's unfortunate that relatively few people have continued Kay's work, but it's largely because they don't understand it, not because they're deliberately misrepresenting it. Likewise with Nelson & Engelbart.
(With regard to Engelbart, he wrote less in public about misrepresentation of his work, & I mostly know how he felt about it via Nelson. I don't think Ted's lying to me, & the two of them were close.)
> I'm unclear as to why a weak influence disqualifies something from being an influence.
A weak influence does not disqualify something from being an influence. However, a weak influence isn't meaningful -- I am weakly influenced by TV shows I've never watched, for instance.
> It's unclear to me whether the ideas of Nelson, Kay, et al. were failed to be realized because of some nefarious reason, because of ambivalence, because there simply wasn't a demand for their ideas, or because of a complex interplay of economic and social issues that thwarted adoption.
Nelson, Kay, & Engelbart actually did realize their ideals -- at least, at a small scale in prototype projects. We know what their ideals were because they wrote about them, & we know that they were realized because we've seen those projects.
Later projects that claim to be inspired by them do not have these qualities, because they do not have the same goals. (I'm not, in this essay, judging them for not having the same goals. I do that in other essays. I'm judging bad journalists for claiming a stronger link than is justified.)
Again, I'm not complaining about the history. I'm complaining about the historiography.
Highlighting a lineage between these projects & modern systems is misleading, particularly when people make the strong form of the argument (that modern systems represent what these projects envisioned). Such a misapprehension is valuable for marketing purposes, since it allows modern systems to borrow clout: we ought to be very careful about feeding that kind of mythology, since it's both dubious and backed by powerful figures.
It's accurate to say that the mouse came from nLS, that overlapping windows, icons, and drop-down menus came from PARC & the Alto project, and that jump links came from Xanadu. But, it's inaccurate to characterize nLS primarily as the origin of the mouse (seeing as how it had defined itself as a groupware system for creating human-machine symbiosis), or to characterize the Alto primarily as the inspiration for the Macintosh (since Mesa also inspired plan9 & Oberon and since Smalltalk80 was such a rich & interesting system in of itself), or to characterize Xanadu primarily as the inspiration for the web (since jump links were one of many features, all balanced together carefully in a nuanced overarching design, which the web did not duplicate because TBL did not understand it).
When we remember seminal system primarily for the elements shared with economically-successful modern systems inspired by them, we create a narrative that discounts the value of the parts not adapted -- a clean linear narrative where the winners were fated. But the winners got lucky, & we have a lot to learn from the losers & from the seminal systems that inspired the whole lot (by dint of being allowed, due to lack of market pressures, to be more creative).
My main complaint in this essay is that such a claim is a misrepresentation of history: we don't use tech that is deeply influenced by these seminal projects, but instead use tech based on extremely different goals & constraints.
This is a common problem with popular history-of-science (and especially popular history-of-tech) & comes in both a strong and weak form.
The strong form is "we live in the future that <figure> imagined/wanted" -- something that's almost never true. Engelbart was not as outspoken in his criticism of the direction of development as Nelson & Kay, but he wasn't quiet about it either. Strictly speaking, these seminal projects had specific goals that they achieved far better than the later work inspired by them did.
The weak form is along the lines of "<project> influenced later work", which is weak enough to be almost meaningless. The most important elements of these projects are typically lost in the churn, meaning that while the influence is obvious it is also shallow.
Ultimately, this is a complaint about the historiography, not the development techniques. (I have problems with both, but the latter is covered in other essays.)
When we tell ourselves a neat story about the lineage of some piece of modern tech -- say, that the modern desktop comes from nLS or the Alto -- we erase the elements that differ, either forgetting them entirely or suggesting that they were mistakes. By telling this story, we lend to modern interfaces some of the idealism that animated the earlier projects.
However, the elements that are missing from modern systems are often precisely those most required for squaring the system with the ideals -- Smalltalk's live-editing and composition, for instance, or Xanadu's permanent addressing. So, to tell the history honestly, we should not allow ourselves to misattribute the ideals of nLS, Smalltalk80, & Xanadu to the Macintosh or the Web respectively.
Allowing ourselves to become confused by this kind of narrative supports some dubious marketing, which makes it more dangerous.
For instance, the Macintosh cribbed a lot of philosophical ideas from ARC (augmentation / man-machine symbiosis vs 'bicycle for the mind') & popularized them, to the point that these ideas are more readily associated with Macintosh marketing than with ARC, and yet the Macintosh was a substantially worse fit for this than its competitors in the market at launch! It weakens the original idea (by implying that the Mac was on the right track, or that the Mac was the best people could do in the early 80s, when really the Mac wasn't seriously trying to do any of these things).
Re: iterative innovation --
Iterative innovation doesn't really come into it. These projects were the result of rapid iteration in the first place. Our modern tech is not based on iteration on the seminal projects, but on taking a handful of ideas from those projects and implementing them in a different context. (Squeak is derived from actual Alto & Smalltalk80 tech, but the Macintosh is not. There's an actual Xanadu lineage, and the World Wide Web isn't part of it because TBL wasn't privy to the state of the art in Xanadu tech as of the late 80s.) Often, the ideas aren't fully understood, or they aren't adapted to the new context, or it's not considered whether or not necessary adaptations make the idea itself pointless -- we're talking about outsiders implementing new projects largely based on marketing materials. There's nothing wrong with doing that -- in fact, it's a great way to come up with potentially-interesting ideas of your own -- but it's not an effective way to add meaningfully to a lineage, particularly when you're trying to do it with a fraction of the original resources.
 The Lisa & Macintosh projects had a lot of ex-PARC folks involved, and so presumably many of the developers were fully aware of the differences. But, the driving design force was Jobs, whose understanding of PARC's design philosophy was very shallow, and they were working with technology substantially less beefy than the Alto, particularly in the Macintosh (which was specifically designed to be cheaper than the Lisa, leading to a lot of cut corners). In other words, in this case it's not completely accurate to say that it's a group of outsiders, but the decision-maker had an incomplete understanding of the original project the constraints on time & hardware had a greater influence on design decisions than any inherited idealism. Cost-cutting measures inherited from that project continued to be copied in other projects it influenced long after they ceased to be necessary.