It's interesting how often we see these articles (and associated discussions) saying that programming is harder than it should be, and that if only we had a better language, it would be much easier.
In my experience, choice of language makes only a superficial difference to the difficulty of a project. The real challenge is always figuring out exactly what you're trying to do, and exactly how you're going to achieve it. And these questions aren't solved by a language because they're questions about your project itself, not about the implementation.
Sure, some toolchains are better suited to some types of project - I would really not want to do serious number crunching in JavaScript, or an interactive GUI in COBOL. But there's generally at least one (and usually bogglingly many more) solid, freely available toolchains to suit any given application.
It's the same logic used when people decide to build their own framework, or advocate against not using a framework - by writing everything yourself, you'll understand everything. It boils down to "other people's code is hard to read", which can probably be extended to entire languages and other concepts as well.
It's in part laziness - reading and understanding someone else's code takes a lot of focused effort. But it's also a matter of gratification - writing code is far more satisfying (IMO) than reading and comprehending others'. Most developers I know - and probably myself included - are of the "I get paid to write code" mentality, and often not really being mindful of whether what they write now will still be understandable in 5 - 10 years time. Sure, they will follow best practices, clean coding and all that stuff, but what about (high-level) documentation? Revisiting the user stories from which the code was born? Writing good commit messages and pull request descriptions? These all seem secondary to the code itself, which I guess is true to a degree, but all that other stuff is important too.
Getting into a new project is hard. Starting from scratch and writing your own is easy. Writing code and other stuff so that others getting into your project is easier is hard (as is allowing others into your domain and code for that matter)
> It's in part laziness - reading and understanding someone else's code takes a lot of focused effort. But it's also a matter of gratification - writing code is far more satisfying (IMO) than reading and comprehending others'.
No, it is rather the problem that other people's source code changes all the time. If the other programmer can assure me that his source code is good enough that it can be used for 10-20 years without any problems (and will be maintained this long time) and the only changes that will happen are small bugfixes, I can easily be convinced to read into all the gory details of it (of course only if the source code is useful), since I know that the knowledge that I gain by diving into these details will help me for many years after.
The situation that we have is that every few months a new framework comes out and such a deep reading into is not worth it since in a few month something new will come and in few years the original framework will be forgotten, making all the investment into understanding it deeply worthless.
Something I never see mentioned, and something that's honestly the biggest barrier to me adopting an appropriately licensed third party library or framework, is code style. If you use several libraries with significantly different coding style, your own code becomes a horrible mishmash of random capitalisation, calling conventions, allocation/deallocation/ownership conventions, etc. and your ability to easily interpret your own code goes out the window.
What I usually end up doing is wrapping each third party library with a thin wrapper which uses my own conventions, to isolate the differences, but still, this is a pain. When you add this pain to the pain of finding a library that does what I want, and the pain of figuring out how to use it despite often poor documentation, and the pain of having to debug weird edge cases that the developer never encountered, you get a pretty sizable disincentive compared with just implementing your own.
Agree that maintainability is important, disagree that frameworks = maintainability. I'd rather maintain an application written 10 years ago from scratch, than an application written 10 years ago using a framework that was popular then.
When it's all said and done with, software needs to be consistent and meet the expectations of its users.
If it does that, the question of a framework or high level documentation or user stories don't matter. Those are tools used to help achieve the above govals, but if you can do so without the use of the tools then the tools aren't all that useful for that particular project.
I sometimes think people miss the forest for the trees. I make the same argument about tests and TDD, the goal isn't tests, the goal is stable, maintainable software. If you can do that without tests, then you don't need tests, and that's ok.
In general I'd argue that that's a tooling issue rather than a language issue - it should be possible in theory to provide tooling for any language that will give you a sufficiently detailed crash dump to diagnose the problem.
In practice, very few languages do so, and the ones that do so require a fair bit of work to set up, which is really annoying. The only thing worse than being told "but it worked on my computer" is being the one actually saying the phrase!
> In my experience, choice of language makes only a
> superficial difference to the difficulty of a project.
That largely is my personal experience as well, and your point that the "real challenge is always figuring out exactly what you're trying to do" echoes Brooks's point from No Silver Bullet regarding accidental vs. essential complexity.
However, these are actually two different things, and I am not convinced they are as connected or as universally true as presented.
First of all, language choice these days is largely superficial, languages have much more in common than they differ, even when you include the more "esoteric" choices such as Smalltalk and LISP. So maybe the reason that choice of language doesn't make much of a difference in projects is that they all suck pretty much the same.
Second, there is a lot of at least circumstantial evidence that "accidental" complexity is actually much larger than we think, and at least partly dependent on architectural choices, and on what you consider "accidental". There's the
20KLOC Xerox PARC vs. 400MLOC MS-Office example, or Knuth vs. McIllroy ( 12 pages vs. 1-6 lines), or my current project, Wunderlist, which is 100KLOC just for a single iOS/Mac client. Or TBL's WWW at 5KLOC vs. Firefox at >13MLOC, or Nile/Gezira at 500LOC vs. Cairo at >100KLOC.
Something is going on here, and I certainly welcome all efforts to figure out what it is and hopefully do something about it.
I think "accidental" complexity is hugely situational and depends on the interaction between original architecture choices and subsequent maintainers of a piece of code. Good maintainers will decrease accidental complexity by eliminating it as they find it, via refactoring or other code tidyup. Bad maintainers will increase it via cut-and-paste coding, bandaid fixes, and poorly structured code.
In a long-enough-lived project, there will always be bad maintainers, so I agree that a language that eliminates accidental complexity would be great, if it were possible.
A lot of those examples seem to be related more to the amount of functionality given. For example, Xerox PARC (I'm assuming you're talking about their early desktop publishing software?) does a vanishingly small amount compared with MS Office.
Related, yes. Reasonably related? Is MS-Office really 20,000 times better at doing personal computing than what they had at PARC? Is Firefox really a 2600 times better web-browser than WWW.app?
I would say it is a stretch to say that MS-Office is 100 times better, but let's assume it is. What's the other 99.5% of the code doing? Let's say Firefox is a 10 times better browser than WWW.app. Again, what's the other 99.5% of the code doing?
There's some sort of polynomial (or exponential?) involved as we try to grow software systems, and I don't think it has to do with "bad maintainers", or at least not primarily.
I don't know, I used to feel that way but over the last few years I've changed my mind. The reason is because I got a hosting company as a client and I've seen some shit.
I've written the tools they use for automated VPS creation/deployment. The wrench in the works is that this company offers the ability to install/configure a lot of different pieces of software and software combinations, not just the usual to get enough going for the customer to log into the VPS. Slowly over the last few years I've started to realize my trust and hope in software that isn't written by me has plummeted as a direct result of this experience. I'm talking about software with a configuration web API where only half the confurable options will actually configure via the given web API and instead you find yourself tracking down and diving into the individual files and updating those instead (and figuring out how to restart their services such that they don't overwrite your changes and accept them). It's just not acceptable, and they charge money for that implementation. I've been told that one of the major features in their new version is that their own web app will start calling the web API so their implementations will actually work in this version. Am I the only one who finds that a ridiculous feature?
long story short, I think there's an assumption in your post that the people writing the software give a shit about correctness and ease of use, when in reality a lot of software only cares about getting money in their pocket. If that means shipping with a web API that's broken and announcing the proper functioning of said API as a feature for the next version, then so be it.
What ends up happening is that you, as a developer, have to deal with the bad decisions made by other people and at some point you start preferring to just write it yourself. To give you an example, PoSH SSH (Powershell SSH). Version 1.6 had no timeout functionality, so it was possible for an SSH session to never end. 1.7 added a timeout functionality, only the default timeout was set to 60 seconds, you can only change the timeout on a session basis, and it's not possible to get back the old 1.6 behavior of having no timeout (sending a timeout of 0 just immediately returns with a timeout error). The best you can do is set the timeout to Int.Max.
The thing is, most of the differences are a bit of a pain, but nothing more, except for the decision to change the default behavior in 1.7 to be different than 1.6. This guarantees that anyone who upgrades gets rocked by this change. And for no good reason. If someone wants a shorter timeout in 1.7, they can make that adjustment while they're writing new code. It's just a bad decision made out of convenience and probably some emotional feeling of "goodness" that results from the default behavior being "right" or "correct" with the new timeout behavior.
Another issue in 1.7 is that if the connection goes away, it will hang until the timout gets hit. I went diving into the code to see what was going on, and in their busy wait loop they never actually check if the session breaks unexpectedly, so if it does break it sits in that loop until the timeout is hit. I discovered this because my automated tools were SSHing into some linux VPS's and issueing a restart command. But because the timeout is on a session basis rather than command basis, it isn't as simple as just adjusting the timeout. I had to actually start maintaining my own version (I did report the issue to PoSSH SSH, but I don't think it's been fixed).
In general, the quality of the PoSH SSH library is such that I'm actually in the middle of changing from PoSSH SSH to the putty tools for my SSH/SCP needs. It's actually more consistent for me to escape and parse the cmd input/output than it is for me to use PoSH SSH, and that's damning.
I'm not asking for 9 9's of availability from these libraries, but my personal goal when I write code is for it to work consistently, and to be loud in its failures so we know that more work is needed to work consistently. But PoSH SSH's design is such that it's easier to meet those goals using external CLI tools than to use the Powershell library.
This turned into a bit of a rant, but this is something that's been on my mind more and more over the past few years as I find myself dealing with such a myriad of different pieces of software with this client.
> Roberts explains: “We’re in the mess that we are in now because of software engineering preferences from 30 years ago, made by people that just didn’t write enough code to have those preferences be worth anything.”
This is a typical attitude of younger programmers towards the previous generation.
> he decided to create his own programming language
And this is the typical solution.
It's happened so many times before it's either really funny or no longer funny. I'm not sure which.
The reason why "everything is broken" is because writing correct software, that does all the things, in any language, is difficult. That's not to say that new solutions cannot make improvements but it is naive to think that new solutions will solve all the problems. A good rule of thumb is to make sure you really understand a system before you replace it.
This sounds like something that should have a simple description, but I'm not sure the article tells enough to work out what it is.
(Unless the simple description is Not Invented Here syndrome, which I imagine it's not).
I had a quick look at the website linked at the end but it's just a site with a list of projects like a text editor and some game debugging components.
I'm not really sure, it rambles a bit. It seems basically to be advertising a coding community or something, with a fair amount of indie superiority complex on the side?
In my experience, choice of language makes only a superficial difference to the difficulty of a project. The real challenge is always figuring out exactly what you're trying to do, and exactly how you're going to achieve it. And these questions aren't solved by a language because they're questions about your project itself, not about the implementation.
Sure, some toolchains are better suited to some types of project - I would really not want to do serious number crunching in JavaScript, or an interactive GUI in COBOL. But there's generally at least one (and usually bogglingly many more) solid, freely available toolchains to suit any given application.