Agreed on the "let's make programming more accessible" point, but meh on the "good old days" view. I've been writing software since 1976 so I have some perspective on the good old days. Programming was always arcane, and it always required specialized knowledge and the patience to work at a level of detail few people find enjoyable. Yes, there were things like hypercard that opened up programming at a certain level to a certain semi-skilled person. Excel falls into the same category. But in the end it is not the symbology, or the tools, or the environment that makes programming difficult: it's the mental process of building up complex behavior from little pieces, analogous sometimes to being handed a bag of atoms and instructed to build a toaster. Some of us find building up these intricate abstract models fun and rewarding, but believe me we're a tiny masochistic fraction of humanity.
Developer inequality and the technical debt crisis
41–50 of 105 posts
Re: Developer inequality and the technical debt crisis
#42> Attempting to simplify and democratize programming will attract only scorn and derision (as did COBOL and Visual Basic).
The reason COBOL and Visual Basic attracted scorn and derision is that they were awful. The problem with them is quite simple: You can use them to create something improperly in 1000 hours that you could create properly using other tools in 2000 hours. That thing will then work until you have enough concurrent users to expose the race conditions, or the Access database backing it reaches the 2GB limit, or the wind blows too hard and the hamsters powering it become frightened. At which point you'll spend 10,000 hours of overtime trying to keep it from collapsing in production while the users all burn you in effigy.
And the likes of Javascript don't suck because they aren't like COBOL and Visual Basic, they suck because they are.
Re: Developer inequality and the technical debt crisis
#43Because it's there. The only reason people use all these web tools is because they are there, documented and ready. The classic example is the Apache web server - it was there and worked. It was written when the web was small and the number of users to a site was low. Competing web servers are here now with performance way higher, so people are switching. Nobody wanted to write a better web server so nobody did for a…
As a long-time Lisp/ML hacker, I find it absolutely hilarious that FP is a fad now. I'm not saying you're wrong; I just think it's incredibly funny.
Re: Developer inequality and the technical debt crisis
#44I think the reason there's so much technical debt is largely because the amount it would cost to actually build quality software... is too high. We could not afford it. Like, as a society. Our society is built on crappy software. I think it's just a utopian fantasy to think that if only the right hypercard-like tool could be created, then the cost of building quality software would go down. Or at any rate, actually:…
I think the reason there's so much technical debt is largely because the amount it would cost to actually build quality software... is too high. We could not afford it. Like, as a society. Our society is built on crappy software. I'm not sure that I agree. If by crappy you mean "not formally proven", then sure. Or if you consider floating point crappy, then we disagree on terms. I think our industry is in a state whe…
You say "So much of the code out there is "totaled": it would cost more to fix or maintain it than to rewrite it from scratch."
If that's the case, why does such code still exist? If it's still running, then in some sense someone is "maintaining" it, at least to the extent of keeping the server it resides in powered on. In other words, someone obviously finds it cheaper to keep such code running as-is than to rewrite it (or to do more ambitious maintenance on it).
Even crappy horrible buggy code can be useful (in a business sense, or a "makes its users happier than if it didn't exist" sense), as hard as it is for us as developers to admit it.
Re: Developer inequality and the technical debt crisis
#45I often watch other developers look to make their lives more complex by trying to solve problems which aren't there. Why? Because the obvious solution is simple and boring. In any other culture that would be crazy. In programming culture, it seems to be the norm.
Personally, I perceive the 'complexity as a status marker' less a technological or programmer culture problem and more as one of business and job culture.
You won't find someone building needless complexity into something if the fundamental goal pushes the limits of their abilities. Basically, starving men don't build Rube Goldberg Machines to crack their eggs.
In technology in general, the majority of jobs seem to be been-done implementation while the education and training continues to stress design and engineering.
Complexity is an outlet for every boilerplate operator who would rather be engineering and a differentiator to remind him/herself and signal to others a greater capability.
Re: Developer inequality and the technical debt crisis
#46I'll go ahead and say it: this is a strawman. A simple web page is as simple as it ever was: Hi Hello, world! The problem is that everybody wants something so flashy and pretty that they can't settle for the functional-but-ugly barebones interfaces app programmers used to make. The problem is that we've trained users that if a product isn't pretty it's useless, and in pursuit of that all these other things happen. Yo…
Yes. But isn't HTML itself the flashy & pretty (and often non-value-added) alternative to plaintext, the functional & ugly interface? Why not just use plaintext, wrap everything in , and call the Web a fad? I'm all for simplicity, I just wonder what's considered taking it too far.
> Yes. But isn't HTML itself the flashy & pretty (and often non-value-added) alternative to plaintext, the functional & ugly interface?
No, HTML's improvement over plaintext isn't cosmetic, its functional. (E.g., automatically traversable hyperlinks.)
Re: Developer inequality and the technical debt crisis
#47This feels astonishingly wrongheaded to me. "Imagine an Internet HyperCard that allowed regular people to easily build web apps, as easily as using a spreadsheet." and then JUST TWO SENTENCES LATER, "There are many app-in-a-can tools that generate highly stereotypical apps but to be truly disruptive we need to match the broad generality of frameworks like Rails." In other words, we need to make it possible for people…
"In other words, we need to make it possible for people to build simple things without much coding. Oh wait, people already can build simple things, but....that's not what you mean?" I think that the problem the OP has with most current app-in-a-can tools is that they don't allow users to create arbitrary simple things, but only fairly specific types of simple things.
The more generalized a tool is, the more special knowledge you need to use it for specific tasks. The advantage of stored-program computing is that we can take a general tool (a computer) and package it with a set of automated instructions (the stored program) to turn it into a specialized tool that you can use with general knowledge. That's pretty much the fundamental endeavor of the software profession.
Compilers, IDEs, etc. are themselves generalized tools to produce more specialized tools; as a result of being generalized, they require special knowledge to use. A programming environment that allowed you to create an arbitrary specialized application using only general knowledge of computing would certainly be a great thing to have -- in fact, I'd describe it as the holy grail of computing.
People have been pursuing that goal for decades. Partial solutions have been discovered in the past (the OP mentions Hypercard, Visual Basic, etc.) but have generally been insufficiently powerful. It is also frequently difficult to keep them up to date with changes in the underlying technology.
Re: Developer inequality and the technical debt crisis
#48I think a lot of people are misinterpreting what the article is saying (and maybe it wasn't expressed that well). The author is not saying that we need a tool that lets literally anyone be a developer ("So easy even a manager can use it!"), but rather that the current technology stack is so hacky that it gets in the way of progress, and demands levels of specialized knowledge that are tangential to the task of building web applications: that is, a higher-level set of development tools. Just as (to pick a high-level, desktop-oriented language at semi-random) C# is easier to work with than x86 assembly language, because it hides the messy details, I think the author would like a world where building a web application is as easy as building a desktop application: a world where issues like data serialization, browser-specific JavaScript hacks (and the hacky frameworks meant to solve them), incompatible databases, constant vigilance against easily preventable attacks (cross-site scripting, SQL injection, etc), and the necessity of juggling at least 3 different languages (JavaScript, HTML/CSS, and whatever you have on the backend) do not occupy valuable developer brainspace.
The issue is that the current web technology stack was never meant for building applications. HTML was designed for static documents. JavaScript's early development was mainly for making terrible mouseover-effects on links. XMLHttpRequest is a historical accident. So, yeah, it all works together, somehow, but it wasn't designed to be used as it is today, and it shows. And it's the developers who carry the burden of integrating these hacks. I, like the author of this article, wonder if it wouldn't be nice to design a system to provide the advantages of the web (distributed client-server applications with highly-customizable, visually attractive front-ends delivered on-demand) with a slightly more human development process. If we can't replace the web outright, maybe we can build better tools ontop of it.
I agree that current web technology is a horrible pile of kludges. Let's try to build something better. Some attempts are already being made. Please check out the amazing Ur/Web language [1] that lets you write front-end code, back-end code (compiled to native), and database code in a single, type-safe language that statically guards against errors that are rife in dynamically-typed web scripting languages. It abstracts the database, without wrapping your data in an annoying object layer; it lets you write front-end and back-end code in one language that communicate transparently. It is far from a finished product but it is an amazing glimpse and what could be with intelligent develop tools. There are some great examples on-line that show how easy it could be. Easy for a developer, of course, not for a layperson.
Re: Developer inequality and the technical debt crisis
#49The web won because it has the least barriers to entry for a new developer and solves a lot of difficult problems that the old-school application stack had. This is all from my history and point of view so I'm sure a lot of people will disagree. Cost: The days when big companies developed tooling and platforms cfor developers where great IF you worked at a company that could afford to pay for them. They were expensiv…
> The web won because it has the least barriers to entry for a new developer and solves a lot of difficult problems
> that the old-school application stack had. This is all from my history and point of view so I'm sure a lot of people will disagree.
In my hindsight, the web won in the enterprise because deployment was free. When the web was developed, in the early 1990s, vendors charged per seat for PC runtimes (Powerbuilder, Unify Vision, etc.). You got zero-cost runtimes, free client distribution (IE on windows) and application version control (server-sode managed code). The low barriers to entry probably exacerbated the hodge podge, but I'm happy to bill hours cleaning up after people.
Re: Developer inequality and the technical debt crisis
#50Earlier quoted context omitted.
"In other words, we need to make it possible for people to build simple things without much coding. Oh wait, people already can build simple things, but....that's not what you mean?" I think that the problem the OP has with most current app-in-a-can tools is that they don't allow users to create arbitrary simple things, but only fairly specific types of simple things.
I think you're right. My problem with that problem is that it's some combination of naive, impractical and pie-in-the-sky. It'd be great for humanity if you didn't need any skills or training to make any kind of computing application you wanted. While we're at it, let's also have a replicator to make any kind of food we want, instantly and deliciously, without any culinary training whatsoever, beyond being able to pr…
"My problem with that problem is that it's some combination of naive, impractical and pie-in-the-sky."
Is it? We had simple yet general-purpose tools for end-users at various points (eg. Hypercard). Why can't we have them again?