https://futureofcoding.org/ logo
Join SlackCommunities
Powered by
Ouch , true? What do you think: 1. Is it harder? 2...
# thinking-together
c
Ouch , true? What do you think: 1. Is it harder? 2. About that relationship.. https://twitter.com/KevinHoffman/status/1448272900759379972
d
Not a web historian but if I had to guess … in 2001 the web was still reasonably close to the idea of readability (and simplicity) of html - that was mostly what you had to know and understand to make a site. (This doesn’t mean it was a good framework … ). JS changed that drastically.
c
I think it's way easier isn't it? Most people use things like Squarespace, Shopify, WordPress etc. Expanding the definition of "website" somewhat, lots of independent small businesses (restaurants etc) use their Facebook page as their primary online presence. I think what people are nostalgic about is the ability for a lone hacker to max out the possible quality of a website. That is, in 1996 your personal static HTML site had a similar perceived quality to CNN's. People say similar things about game development. How come it used to be that a single 15yo could write a world class game, now it needs a team of 100 professionals? Well, the definition of "world class game" moved a long way. Certainly between 1996 and 2021 "make a website" has become something that my parents can do.
a
I don't know about 1996 exactly, but you can still make websites with very simple tech if you feel like it. I don't know if you can still find reputable shared hosting with SSH, so you might have to admin your own server, but plain HTML still works. Inline JavaScript still works. I guess I agree with Chris Knott, but would phrase it differently: A lot of the change is that people's expectations have gone up as we've seen what's possible. Which is not to necessarily say that software doesn't also have some kind of unhealthy relationship with complexity.
g
“Because our industry has a codependent relationship with complexity.” [my reaction to the above statement] # Definition of Simplicity “Lack of Nuance” # Source of Complexity Problems have a number of degrees of freedom - dimensions. Our reality appears to have 4 dimensions (4D) - x,y,z,t. Trying to squeeze more than one dimension into a single notation results in what we perceive as complexity. Flattening 4D (reality) down to 2D (pen and paper) results in “complexity” - some things become merely harder to express. We need more than one 2D notation to express 4D concepts, each in a seemingly “simple” way. # Complexity Is In The Eye Of The Beholder Nothing is “complex”. The use of a mis-fitting notation might make a problem appear more complex, but does not change the underlying nature of the problem. more at https://guitarvydas.github.io/2021/10/14/Complexity-vs-Simplicity-II.html
👍 1
k
No question that some of the complexity is well-justified. It's also equally clear that times of increasing complexity provide lots of cover for capture and rentierism. Such times are when priest classes gain power. If the "complexity inequality" grows too large in society it can become irreversible. The time for an intervention is when the priest class is still small and relatively ineffective. It's questionable if the programmer priest class is small these days, but it seems clear that it's ineffective. Society is constantly reminded these days of its failures. So these debates seem very valuable. @Chris Knott You're right that the space of possible quality has expanded a lot. An additional part of the problem is that the supported part of the space is a tiny fraction of the total space. Someone learning how to build websites today is unlikely to encounter pure-html tutorials anymore (that are not references). There's a pervasive implicit assumption in tutorials that the end point is CNN's website, which requires lots of ongoing maintenance in exchange for its perceived quality. I think it's valuable to expose people early to the idea of wabi-sabi in software.
c
In 1996, I found it stomach-churningly complex and frustrating to figure out how to even run more than a basic web page from my university network's servers, not to mention running a server myself, especially getting configurations right and the early versions of CGI working – I had years of web ptsd – no warm and fuzzy feelings here Yes, html was easy, at least that
d
the dream of the 90's is alive at https://neocities.org/
❤️ 1
https://glitch.com/ is also pretty fun. My 90's self would approve.
k
The question posed initially requires some context: Is making a Web site harder today than in 1996 - FOR WHO? For someone familiar with Web technology, the answer is no, as others have pointed out: if you want a plain HTML site, you can still make one with exactly the same effort as in 1996. For someone familiar with just browsing the Web, who then wants to move on to creating a Web site, the answer is yes: it's much harder to get started because of the enormous labyrinth of paths you need to evaluate to make a good choice. Most of them end in some non-obvious trap such as a walled garden. In 1996, you could walk into a book store, buy "Web sites for Dummies", and get going. Maybe some other book would give slightly better advice, but you couldn't make a serious mistake following any book's advice. Today, there is no obvious place to look for guidance, and most advertised solutions can be a serious mistake, depending on your requirements.
👍 1
c
So Konrad you would see it as a "Paradox of choice" issue?
k
Yes, that's the main issue. With evaluating the options being the most difficult task, in a context where advertising abounds, educational resources are rare, and the market changes so fast that evaluations become rapidly obsolete.
d
Is it possible for a one or two person dev team to build an open source photo management app? Ars Technica thinks not, it's just too complicated:
Our perhaps unsatisfying conclusion to this seven-app showdown exposes an important truth: the photo management software world is too complex for a one- or two-person dev team to properly handle.
https://arstechnica.com/gadgets/2021/06/the-big-alternatives-to-google-photos-showdown/
k
Certainly if you want to have lots of users, grow like a weed. But I'd argue most teams with more than one or two people fail at that as well. So, just don't try that maybe? https://www.robinsloan.com/notes/home-cooked-app 100 people building for 100M people: very hard. Doesn't matter what you build. 2 people building for 10: very doable. Doesn't matter what you build.
➕ 3
❤️ 1
o
Thanks for sharing this great article , Kartik! Some quotes:
In a better world, I would have built this in a day using some kind of modern, flexible HyperCard for iOS, exporting a sturdy, standalone app that did exactly what I wanted and nothing else.
In our actual world, I built it in about a week [...]. I waved some incense and threw some stones and the gods of Xcode allowed me to pass.
And:
This messaging app I built for, and with, my family, it won’t change unless we want it to change. There will be no sudden redesign, no flood of ads, no pivot to chase a userbase inscrutable to us. It might go away at some point, but that will be our decision, too. What is this feeling? Independence? Security? Sovereignty?
Is it simply… the feeling of being home?
I really like this idea of home-cooking app (or computing to be more general). I also find the parallel with cooking very nice and expressive.
k
I remember the article that @Kartik Agaram shared from a while ago. Back then, it got me thinking. I have a few ideas for similar few-people situated apps that I could use. But there's still a huge learning curve for mobile platform development, plus the eternal risk that whatever development tool you choose will not be supported under future versions of Android and/or iOS. In other words, in my mind mobile platforms are inherently unstable, much like Web platforms that go beyond plain HTML. Am I wrong there? What's the track record for the longevity of mobile apps?
💯 1
k
I think you're exactly right. What my efforts to be more radical have taught me is that it's really difficult right now to avoid these issues. So I have even more appreciation now for people making these difficult trade-offs as best they can with the knowledge and skills they have at hand. I've been spending some time in the Collapse and Permacomputing communities lately. And noticing that even if they turn out to be too pessimistic about our future, the approach they take helps us today. We don't have the capacity to perfectly reshape our computers, so we're forced to accept them as they are and adapt them to our needs as best we can.
👆 1
💡 1
💯 3
k
Extremist approaches often end up useful in more moderate settings. I had seen permacomputing before, but not CollapseOS. Reminds me of the computer I used in the 1980s (a Colour Genie to which I had ported Forth myself). I knew every byte in the ROM of that machine.
c
I still believe that there is room for a kind of "makerspace - hacker" culture where hardware is simple enough so it can be easily repaired or replaced by self taught individuals. This combined with something like collapse could evolve into interesting , "robust" resilient computing cultures.
a
@Konrad Hinsen Flutter seems pretty stable and well-supported and even kinda future-proof (for the next 5 years at least) to me. That would be my default choice for smallish-scale cross-platform development (I can compare with Xamarin and Cordova). But you might disagree. 🙂
Regarding original questions... 1. As already was pointed out the notion of "Web site" changed dramatically from 1996 to 2021. So if we're talking about "Web site" as a collection of HTML pages, then nope, it's easier to do now. Not even mentioning again Foursquare, Facebook and such, now we have very nice professional good-looking and easy to use CSS frameworks (many more than just Bootstrap) and templates. Filling them with your actual content is a breathe and you instantly get great-looking "Web site". Even vanilla CSS3 and JS7 are so much nicer than what we had in 1996. Regarding "Web sites" in the sense of "Web applications"... What we can and do now wasn't even possible in 1996 so I don't even know how to compare... I suspect the original tweet was (secretly) referring to Webpack, Babel and other pretty crazy tools to process JS and stuff which you didn't have and didn't need in 1996. But the funny thing is... you still don't need them to build Web apps in 2021 that weren't even possible in 1996. Yep, even using modern frameworks, JS and CDN. Babel/Webpack/whatever are just not required. 🙂
2. I think our industry is indeed very much codependent with complexity for a very simple reason we (the industry) value backwards compatibility so much. Or even depend on backwards compatibility so much. As long as you support everything that came before you're sole choice is to only ever add stuff. And more stuff inevitably leads to (quadratic) increase in complexity because of interactions. The only way to significantly cut complexity for real is to get rid of some old stuff and redesign on different metaphors and abstractions. But that breaks backwards compatibility.
💯 1
k
I think it's mostly customers (aka users) who value backwards compatibility.
Moreover, I suspect what customers mostly care about is backwards compatibility for their data. I'd be happy to try your shiny new contact management app, if I can be sure that all my contacts survive, with all relevant detail that I have carefully added over the years.
So... maybe lock-in is a big part of the problem?
@Alex Chichigin I have no reason for disagreeing with your assessment of Flutter, Xamarin, and Cordova, for the simple reason that I don't know any of them. Flutter is OK with me - except that my time horizon is closer to 20 years than to 5 years.
a
@Konrad Hinsen pretty much everybody is someone's customer. 🙂 Backwards compatibility starts with hardware, and I was pretty happy I could take HDD and RAM from my old laptop and plug in the current (less old) one. And occasionally I'm happy I still can open a someone's MS Word'97 file in my LibreOffice Writer. Operating systems have very good backward and forward compatibility with both hardware and software and that's tremendously useful. And so on.
@Konrad Hinsen regarding Flutter. Yeah the time horizon is the biggest concern. I think about 5 years ago many were saying Google will drop both Dart and Flutter, but so far they only improved both projects great deal. So I'm pretty sure Flutter will be still maintained and updated 5 years from now. But 10 years? Who knows? Nowadays we have no guarantees any piece of technology proprietary or open-source will be still maintained in 10 years or even less. Sure Flutter as well as all other OSS projects won't disappear but will it still support modern (to that time) versions of Android and iOS? I'm not 100% sure Android and iOS will still be around and as relevant in 10 years from now. But that covers hardware as well. Will x86_64 be still as relevant for desktops and laptops in 20 years as it's now? Or will it become kinda niche HPC thing? While both desktops and laptops will become dominated by ARM processors. And maybe even RISC-V (derivatives)? I won't be overly surprised. I can't even imaging what will grow out of current fashion for "Neural" coprocessors and ongoing research into memristors. Maybe it all will just die out during the next 10-20 years or maybe they indeed change the face of computing as we know it. 🤷‍♀️
k
If I had to bet on any computing technology to be around in usable form 20 years from now, I'd pick Fortran, Cobol, C, Common Lisp, Java, JavaScript, Linux, x86 binaries, and not-too-recent Web technologies. "Usable form" may well be via emulation, but that's fine. Long history plus wide use is what makes for a long future. Unfortunately, my list includes nothing that permits building good user interfaces.
a
I don't think Cobol is really usable today, not on the same level as even Fortran or C. 🙂
k
@Alex Chichigin Is your opinion of Cobol from experience? https://medium.com/swlh/why-you-should-learn-cobol-in-2020-9b263bee775d
a
@Kartik Agaram I personally have nothing against Cobol (though one my ex-coworker that actually did work with production Cobol codebase has a ton against Cobol) but even installing a Cobol compiler and libraries is not as straightforward as even Fortran. Thus to me it's definitely less usable, I have to put more effort to start using it.
k
Cobol has always been the domain of large software for large institutions, so optimizing a personal development setup is probably nobody's priority in this space. But the real message behind the survival of Cobol is that technical merits and personal preferences are much less important factors for the longevity of technology than sheer inertia.
k
Also, I suspect @Konrad Hinsen's "usable" above wasn't really about the modern connotation of usability..
k
Indeed. What I expect is having a straightforward and well-documented way to use old software. No tinkering required, but it doesn't have to be single-click.
2 Views
Open in Slack
PreviousNext
Powered by