Here's the thing: everything sucks. Every industry, profession, even hobby is full of seemingly arbitrary limitations, poor tooling, quirky hacks you have to work around, little bits of required know-how that seem ancillary to the central goals. Ask your friends in other engineering disciplines, politics and public policy of all kinds, finance, medicine, and energy. Everything sucks because the world is complicated and path dependency calls the shots. The question to ask is whether things are getting better or worse.
And things in programming are getting emphatically better! For all the incidental complexity and pointless thrashing about [1], almost everything about writing software is better than it was just 10 years ago, which is not a very long time. The people who say things like "nothing ever changes" or "we're just reinventing old technology" have some seriously rose-tinted glasses. It's so much easier to do just about everything. The tools are better, the hardware is better, the quantity and quality of information is better. And we have better, bigger software doing more important things, which is why the industry is doing so well. The sky is doing the opposite of falling.
That isn't to say there isn't room for improvement, or that complaining about broken things is wrong. That lets us keeping fixing things. It's more that "everything is broken and stupid" isn't a very useful lens, and leads to fool's errands like this:
> It’s time to kill the aimless, bottom-up, ad-hoc incrementalism in programming in favor of purposeful, top-bottom and planned innovation.
I'll stick to my massive pile of working software that solves real problems, warts and all. And I'll continue to help improve it wherever I can so that it works better.
[1] I joked recently that Javascript library developers would be more efficient if they had their CI servers deprecate their APIs automatically before releasing them
>> It’s time to kill the aimless, bottom-up, ad-hoc incrementalism in programming in favor of purposeful, top-bottom and planned innovation.
Agree. Let the author put his money where his mouth is first, then we can discuss where he's right.
He wants programming to be "easier." Well everybody wants everything easier. It's easy to have just one thing easy scarifying other dependencies. But the limitations exist everywhere. And it was damn hard to even come this far and maintain the state we are here now:
as a tinkerer, I love programming. I enjoy optimizing routines, fighting complexity, exploring the solution space for hard problems.
the problem is, that doesn't pay for a roof and a meal.
so I spend my day fighting users that requires twenty seven pop-ups not to delete their own data accidentally, browsers that have each their own idea of css3, enterprise services that are a landmine of old documentation, bugs, workarounds, workarounds for bugged workarounds and bugs on top of these.
as my mentor once said, if work were fun they wouldn't have to pay you to do it.
One of the premises of this article - that "competing standards" exist primarily because of political reasons or shallow decision making - demonstrates a fundamental misunderstanding of software engineering.
Sure, some engineers (especially junior ones) enjoy reinventing the wheel more than using something that already exists to solve users' problems. We all like to trick ourselves into thinking we're unique snowflakes (this problem extends into our personal lives as well). But more often than not, when multiple popular standards emerge, it's because there are legitimate engineering tradeoffs that are being made.
JSON vs. XML? XML is far more capable but complex. JSON is far simpler but less capable. Sometimes when you're delivering value to customers, you need that extra complexity, so you use XML. Other times you don't need it so you use JSON. It has nothing to do with ego or politics. Multiple different JSON libraries? One may prioritize ease of use to get up and running, the other may prioritize strong typing for serialization speed. One may prioritize strict compliance with the spec, the other might prioritize speed above all else. JSON vs. a binary format? JSON is more readily compatible and easier to debug. Binary is faster but more complex to setup. It goes on and on.
Again, sometimes competing standards or libraries or languages emerge because of political or capitalistic concerns. But usually when you're talking about competing open standards, there are multiple because there are legitimate engineering tradeoffs being made because engineering is not a one-size-fits-all science. (Few sciences are, otherwise they wouldn't still have people working on them.)
When an open source project rejects a contribution, or five projects exist to solve the same problem, they're often making legitimate engineering tradeoffs that are in no way arbitrary, and any one project would suffer to try to be every thing to every person. The article in question doesn't even point out a single example of a set of standards or libraries that are entirely arbitrary in their differences or could be collapsed into one solution, which further highlights how this is a theoretical argument, not a practical one.
I clarified that "Sometimes" the causes are political, it used to say "Usually".
But if after a 30 minute read you picked up on a stupid example and you started a discussion on XML vs JSON you are just proving my point. The expectation in the 60s was that machines will figure out protocol, even make protocol, on the fly, by asking about each other. Yet, you want to have another discussion about XML and JSON.
It's worth mentioning that Chris Granger wrote an excellent blog post[0] that's similar to this one, but far more succinct. While I don't use Light Table, I'm still a huge fan regardless.
>What would programming be to you in an ideal world?
More visual, especially when observing execution.
When you're debugging anything non-synchronous—be it events, messaging, distributed systems—it usually sucks, even in the rare case that you do have good tooling.
I'd like to create, view and debug my code in an almost entirely visual fashion. I want to see events and messages perfuse through the structure of what I'm building, with complete temporal control of the view.
In the ideal world, i would program purely at the level of a sugared lambda calculus, free of trivial things like runtime,memory use,network latencies,serialization,platform incompatibilities,dependency management,string encoding/decoding issues <so many others>. Basically everything that makes programming different from math.
However, programming may be lambda calculus at a theoretical level, but execution is a turing machine. All these little real world things that can be abstracted away in abstractions(!!), have to be unabstracted to meet a bunch of very real NAND gates somewhere, limited memory, resources etc.
Thats one reason it "sucks", but thats why its engineering and not math. Maybe one day computers will just be so powerful that we can afford to treat memory as infinite, runtime as infinitesimal, and build all the abstractions we want for free - then programming will be done :)
In this fun world, when i want to build something ill just draw a bunch of squiggly boxes and describe an alarmingly underspecified thingy i want done. Then the program will automatically figure out all possible inputs, quickly perform a "32 questions" kind of thing and resolve any ambiguity, then produce code. Managers will once again be confused why "adding this textbox is so hard", but this time they will be right - i will just tell lambda to go make a textbox.
I would say that everything the author describes as facts that have led us to this "mess" are actual testments to how fucking amazing human ingenuity is.
Look at everything we built out of arbitrary conventions of boolean logic that has real impact and is shapping the modern world!
>>The computer shifted the complexity of our solutions from the world of atoms to the world of ideas.
And that's fucking awesome! Thanks everyone that was part in making that a reality!
Complexity can pile up in this new world, sure, but we are only starting to get our feet wet. Outside the boundaries of processing and storage, we are our only limitation. We can create things as complex as we can logically describe them.
It's also incredibly difficult to create something that will acomodate everyone else's solutions.
Software development is in its infancy. The fact that we can create absurd structures that still work is great because we can use them even if our skills are not mature enough to make truly elegant structures.
Saying programming sucks and wishfull thinking does not help anyone. Not happy? Start hacking on the next thing!
>>The computer shifted the complexity of our solutions from the world of atoms to the world of ideas.
>And that's fucking awesome! Thanks everyone that was part in making that a reality!
I glad you are entertained with programming. I am too! but we should judge a tool like programming by its productivity, not by it's entertaining powers.
> We can create things as complex as we can logically describe them.
One of my points is that we can't. To make a single app facebook needs hundreds of engineers and it is still buggy. Humans are, yet again, the weaker link in software engineering. I believe we need fundamentally better tools.
> It's also incredibly difficult to create something that will acomodate everyone else's solutions.
Agreed. I'd very happy with a tool that is not general purpose that could churn though CRUD systems (vast majority of systems our there) in a matter of hours without errors. If you want to something else like AI, or games or whathaveyou, use other tools built specifically for that or a programming language if none are available.
That CRUD tool (gross oversimplification) could be expanded with new capabilities as long as we understand those new capabilities properly.
> Saying programming sucks and wishfull thinking does not help anyone. Not happy? Start hacking on the next thing!
Taking the creativity out of an inherently creative process.
Imagine you're a painter and then comes some moron (who is probably not a painter) yelling at you:
- Why are you holding the brush that way? Also, I don't know that brand.
- You should make thinner strokes, and always start coloring the surroundings so you don't go over by mistake.
- Do not bother with the first brushes until you have a clear pencil sketch. Actually, here, use this one that I paid someone else to make. Limit yourself to add these colors.
- The painters at X draw ultra realistic portraits, that doesn't even look like a cow!
In pure software engineering there is much less creativity needed than most people want to admit.
While the UI/UX people gather requirements and work with the client to work out how the app should look and behave, sure, they can use their imagination. But once the requirements are set then in many cases a software engineer can sit down and build the software. There is no creativity needed to decide whether to use a vector or a double linked list if you need to prioritise fast append and prepend. After all, if you break down software to its basic building blocks, it's all mathematics and logic. And there is no creativity in Mathematics.
The article is a long rant, but wrong on more premises and conclusions. And yet, by quoting the people who were actually right in the cases they wrote about, it appears more correct than it is.
There are too many wrong "conclusions" and premises in the text, just an example, here's the author writing about Babbage's and his Analytical Machine:
"he was focused on doing math fast and without errors. He didn’t care how complex the machine was as long as it accomplished that."
Of course, not true, Babbage had to care. He was designing a purely mechanical machine for years at the time when nobody had electrical logical circuits. He designed the simplest "universal enough" machine in the limits of the technology of his time. And the design was never built. But to claim that his design was "too complex" the author would have to design a significantly simpler one under the same limitations and goals.
The whole article is, unfortunately, like this. Uses something that actually happened or somebody did say, "concludes" something else. And the claims that aren't that kind of "conclusions" also sound like from somebody who only very partially understands what he writes about.
This doesn't mean that the author shouldn't attempt to write more articles, he can learn something from it (although I'd suggest him to base his writing on his own, specific, experiences) just that this article as it is is a quite bad potential basis for a serious discussion, IMHO.
He asks "Is there another hardware, general-purpose or not, that would fit our needs more precisely while being cheaper to program?"
The answer is a simple "no." The author just doesn't understand how much of everything was invested up to now for him to pay so little for the CPU's he uses:
Note just the "plant stat-up costs in billions" column. And that's just a piece in the whole puzzle. There are big gains for those who'd improve a current state, so the humanity as the whole is much more motivated for the real improvements, where they are possible, than the author assumes.
When we remove wrong conclusions after quoting others, the rant can be summed up to just a few claims, one of major being "I'm confronted with different frameworks and libraries, "everybody" solves similar problems, it "sucks" to work this way, maybe the hardware is the main problem." No.
reference? In any case, the main point is that he was making tradeoffs for his math machine, not for modern software development. Not blaming him, just pointing out it was suboptimal for us.
> The whole article is, unfortunately, like this
I'd love more examples. I have definitely a lot to learn about writing.
> The author just doesn't understand how much of everything was invested up to now for him to pay so little for the CPU's he uses
I don't see how "a lot of money was invested" proves how there is no alternate hardware that would make programming more productive.
It's depressing to see how much effort was put into the presentation of this blog post compared to the effort in clarifying its ideas. The author's ideas aren't novel.
Programming isn't something that can be "solved" any more than math or writing is. There is inherent complexity in building apps and there are an infinite number that could be built. The fact that it hasn't been "solved" is no indication that we've "never asked ourself this question!"
I agree. I haven't read the article, but the first thing that came to my mind was: "it doesn't suck". Rather, I find it a fun activity.
There's so much creativity one can put into programming. Especially when programming for oneself and not for Super Evil MegaCorp (not the actual game dev company [0]!). Sometimes it feels to me like art, for example when creating games.
My older brother, at some point in his live, he thought programming sucked as well. But then he stopped doing programming professionally and now just as a hobby and it became fun for him once again.
According to the author programming sucks for the following reasons:
* costs and time, difficult to maintain
* difficult to hire developers, difficult to learn
* no diversity in industry
* users have no influence on product
Well, yes. Software is a labour intensive task. But given the number of jobs digitization has destroyed and the immense gains it provides, I don't think it so bad. Despite the authors criticism it's still an improvement.
I find his argument hard to follow, the author wants to solve 'the problem', but I don't quite get it. The all purpose machine was a good idea, having an evolving eco system, competition, forks, etc. is a good thing.
Read the article first. (The author is in fact himself a programmer who loves what he does.) The reason he says it sucks is not because it isn't interesting, but because modern programming is using a machine (the computer) to solve problems that that machine was never meant to solve and is actually rather ill-fitted to solve. He says that all the pay-offs and work-arounds we have had to use to get computers (originally a purely mathematical machine) to do what we want is the cause of many, if not most, problems in programming.
[meta] The title of this article sucks, really, it's a bait, which is sad because the article is actually interesting. Why do blog post titles about programming have to suck in order to attract readers ?
> Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem (there’s not much we can do about this)
Agreed. That's where "lean programming" comes into play. If you have the capacity to make the code change as requirements change then I think the issue is pretty much solved. However, not all languages/solutions are equal in that matter. Obviously TDD, Agile techniques help.
> If we assume that typing code is the way to program, we will never look for better alternatives.
Typing code is a medium. The fact is, for an engineers it usually the most convenient way to create a program.
> But without an end goal, of course you have millions of developers releasing Javascript frameworks every day
How many of these are still maintained 1,2,5 years after?
So I don't think that is really a problem, there is an handfull of well maintained frameworks and libraries in the JS world. Most are not. Most are flashy with a nice "flat" page then you never hear about them again.
It's easy to produce shitloads of code, it's harder to maintain it and build a real community around it.
> Building software is 90% a human problem
Agreed, but like everything humans do.
> What would programming be to you in an ideal world?
There is no general answer to that question. That's why we have all these languages, frameworks and libraries yet we keep on creating languages,frameworks and libraries.
What drives me as a "programmer" isn't the medium, but the goal, the product.
Creating something useful. Languages, frameworks and development methods are the necessary constraints.
> [meta] The title of this article sucks, really, it's a bait,
It was not intended. The title just tries to summarize the post. Still, so much to learn about writing!
>> Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem (there’s not much we can do about this)
> Agreed. That's where "lean programming" comes into play. If you have the capacity to make the code change as requirements change then I think the issue is pretty much solved. However, not all languages/solutions are equal in that matter. Obviously TDD, Agile techniques help.
I have a note on Agile. As I mentioned, I believe Agile or lean programming to be solutions. They don't question anything about the status quo, they just try to cope with it. It's good, it's an improvement. But an incremental one from the perspective of the stack of poker chips.
>> If we assume that typing code is the way to program, we will never look for better alternatives.
> Typing code is a medium. The fact is, for an engineers it usually the most convenient way to create a program.
>> Building software is 90% a human problem
>Agreed, but like everything humans do.
The first rule of the tautology club is the first rule of the tautology club. Of course! the idea is to make programming something that humans don't do, or at least, reduce how much human involvement you need. Humans are the weaker link in software development, we should do like with other things that humans don't do anymore, figure out a solution and put our time to do something else.
> Of course we have never questioned any of this. We don’t have a direction, a path or an overall goal for programming!
> Let me ask you this: What would programming be to you in an ideal world?
> We don’t know! We’ve never asked ourselves this question!
When at the start of the "essay":
> Turns out, we are horrible at predicting the future and we end up discarding that extra complexity.
Too bad outsiders think (and will for a long time) it's a done thing. Society thinks software is the best thing since sliced bread so it's all around us. It's both a curse and a blessing.
Compared to other fields, CS or engineering is relatively new. It's exciting, it will keep breaking and evolving. And that should be it. It should keep going places without restrictions, precisely because we don't know.
Similarly to scientists ripping open humans on anathomical theatres in the 17th, we are having fun.
You hit the spot. Yes, who is it to say that we reinvent programming tomorrow and it useless by next week. Great point.
My answer is, don't look at it from a black and white perspective. I'm not aiming for a 100% future proof solution, that is impossible as you pointed out. But we can make something much more future proof that what we have right now.
We don’t have a direction, a path or an overall goal for programming!
We (who do we mean when we say "we", anyway?) don't have a direction, path or overall goal for life, society, the human race and so on. I don't even have a plan for what I'm going to have for lunch next Tuesday.
Programming is contingent and incremental because rationality is bounded and the future is uncertain. We don't know what will be successful in the next few years or how the world will want to use it or what it will be prepared to pay for.
We can build jewel-like systems that are perfectly adapted to their use case using technology to the utmost. This nearly always results in a stranded evolutionary dead-end. The BBC Domesday Project (live video database on an 8-bit micro using PAL laserdisc!) is my favourite example, but there are many.
Personally, I don't think we could reinvent programming and make it 100% future proof. But if we reinvented programming it will be much more future proof that what we have now. The reason is that our current stack was not invented in the first place, kind of evolved upwards organically. If we did something it will at least be purposeful.
I think we just push our requirements until they hit boundaries where programming/tooling/whatever sucks.
These days it's trivial to create a CRUD web app that is even save against CSRF when you use a framework like Django.
But of course, nobody wants a simple CRUD web app anymore. It has to do business logic, it must have responsive design, usable on mobile, incrementally load pages, and be an enterprise integration framwork that checks with the credit card processor, the warehouse software etc.
It's just that we don't talk anymore about the things that have become trivial, because we don't spend much time on them.
So of course, in our perception, programming and tooling suck. And they always will. And that's OK, because if everything was breeze, we'd be bored.
I really don't think that programming sucks. I think some software sucks, and this is usually because of a number of reasons.
* There is always a deadline and pressure to deliver that exceeds quality controls.
* Software development shifted from engineering to crafting a long time ago, mostly because of the prior pressure to deliver.
* Poorer quality code that works and building new features on top are easier to sell, than rewrites and paying off technical dept.
I think it comes down to building in pieces that you don't mind throwing away when a better piece comes along.
This article more than anything underscores my feeling that there are too many people in programming who should not be doing it in the first place. It's a skilled profession, but it's increasingly dominated by people who despise the craft aspect of it. This results in both, suckage and bloat on the one end, and unrealistic expectations on the other.
> Hiring developers is an extremely difficult task. Learning to program is ridiculously difficult as well.
If programming was a solved thing, that would mean problem solving itself was a solved thing. It has by nature to be difficult. The question is more whether we manage to avoid additional difficulty on top of that. He's talking about the cost of bugs, but I posit the cost of burdensome frameworks and artificial bureaucracies in software development processes is by far bigger and harder to come to terms with, both of which exist in part to manage this inherent difficulty (often achieving the opposite).
> Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem
This is not unique to software development by any means. Every organization that deals with end users has to negotiate this interface.
> anywhere from 50 to 90% of the cost of building software goes towards maintaining it after the first release
Whether that figure is real depends largely on the type of software you're writing. If this fits what you're doing, the assumption that at some point the program is supposed to be "done" and every bit of time spent evolving it further must be a sign of inefficiency is simply unproductive. That kind of program is more usefully viewed as an evolving organism, and the sooner management recognizes the nature of this the better it will be handled by the organization.
> Our tools don’t make a good separation of essential and accidental complexity[2]––we are forced to crystalize the essential parts of our programs in a programming language and make them coexist with irrelevant, usually platform-specific code (accidental complexity).
This too depends on the nature of your chosen ecosystem. On the whole, interop has steadily improved throughout the history of computing. We have meaningful universal data formats now, and many options for moving code between platforms. Where interop troubles exist, they mostly exist on purpose (like the iOS example you made). You can absolutely solve most of this problem by throwing computing power at it and choosing an interpreted or cross-compiled environment if you want to avoid writing glue code.
We may be programming in our different teams, companies, organisations and countries, but the stuff we make makes an impact and affects the world around us.
This impact is an input into future similar projects and, given time, the technologies that results from wherever will be better for it. Please note that this idea does not mean that any group now is going to make these technologies, but what we do now will influence the future.
The same pattern has been observed in the industrial revolution - many tinkerers, manufacturers and inventors were all sort of learning from each other, all improving. This happened over decades. The main difference with programming is the time dimension. We've only really been doing it at a cultural level for the last twenty years - we're only just getting started in discussing and sharing what we are doing.
"Back in the day math was slow and error-prone and we created the computer. Now, it’s software development that is slow and error-prone."
I'd argue Math is still slow and error-prone. Ask any math PHD candidate. Computation is fast, but Math itself has more layers, and more branches than ever. Sound familiar?
That said, some smarties are trying to remove unnecessary layers in programming.
I feel like rump/Uni-kernels are looking to simplify the stack. [1] The clear linux project is removing some pieces from the stack. [2]
TL;DR Math is about as noisy as programming :/
I don't buy the premise. But, I enjoyed the read!
[+] [-] icambron|10 years ago|reply
And things in programming are getting emphatically better! For all the incidental complexity and pointless thrashing about [1], almost everything about writing software is better than it was just 10 years ago, which is not a very long time. The people who say things like "nothing ever changes" or "we're just reinventing old technology" have some seriously rose-tinted glasses. It's so much easier to do just about everything. The tools are better, the hardware is better, the quantity and quality of information is better. And we have better, bigger software doing more important things, which is why the industry is doing so well. The sky is doing the opposite of falling.
That isn't to say there isn't room for improvement, or that complaining about broken things is wrong. That lets us keeping fixing things. It's more that "everything is broken and stupid" isn't a very useful lens, and leads to fool's errands like this:
> It’s time to kill the aimless, bottom-up, ad-hoc incrementalism in programming in favor of purposeful, top-bottom and planned innovation.
I'll stick to my massive pile of working software that solves real problems, warts and all. And I'll continue to help improve it wherever I can so that it works better.
[1] I joked recently that Javascript library developers would be more efficient if they had their CI servers deprecate their APIs automatically before releasing them
[+] [-] acqq|10 years ago|reply
>> It’s time to kill the aimless, bottom-up, ad-hoc incrementalism in programming in favor of purposeful, top-bottom and planned innovation.
Agree. Let the author put his money where his mouth is first, then we can discuss where he's right.
He wants programming to be "easier." Well everybody wants everything easier. It's easy to have just one thing easy scarifying other dependencies. But the limitations exist everywhere. And it was damn hard to even come this far and maintain the state we are here now:
Louis C.K's take:
https://www.youtube.com/watch?v=uEY58fiSK8E
[+] [-] avereveard|10 years ago|reply
the problem is, that doesn't pay for a roof and a meal.
so I spend my day fighting users that requires twenty seven pop-ups not to delete their own data accidentally, browsers that have each their own idea of css3, enterprise services that are a landmine of old documentation, bugs, workarounds, workarounds for bugged workarounds and bugs on top of these.
as my mentor once said, if work were fun they wouldn't have to pay you to do it.
[+] [-] ghodss|10 years ago|reply
Sure, some engineers (especially junior ones) enjoy reinventing the wheel more than using something that already exists to solve users' problems. We all like to trick ourselves into thinking we're unique snowflakes (this problem extends into our personal lives as well). But more often than not, when multiple popular standards emerge, it's because there are legitimate engineering tradeoffs that are being made.
JSON vs. XML? XML is far more capable but complex. JSON is far simpler but less capable. Sometimes when you're delivering value to customers, you need that extra complexity, so you use XML. Other times you don't need it so you use JSON. It has nothing to do with ego or politics. Multiple different JSON libraries? One may prioritize ease of use to get up and running, the other may prioritize strong typing for serialization speed. One may prioritize strict compliance with the spec, the other might prioritize speed above all else. JSON vs. a binary format? JSON is more readily compatible and easier to debug. Binary is faster but more complex to setup. It goes on and on.
Again, sometimes competing standards or libraries or languages emerge because of political or capitalistic concerns. But usually when you're talking about competing open standards, there are multiple because there are legitimate engineering tradeoffs being made because engineering is not a one-size-fits-all science. (Few sciences are, otherwise they wouldn't still have people working on them.)
When an open source project rejects a contribution, or five projects exist to solve the same problem, they're often making legitimate engineering tradeoffs that are in no way arbitrary, and any one project would suffer to try to be every thing to every person. The article in question doesn't even point out a single example of a set of standards or libraries that are entirely arbitrary in their differences or could be collapsed into one solution, which further highlights how this is a theoretical argument, not a practical one.
[+] [-] lucozade|10 years ago|reply
But sometimes things are complicated/messy because we're trying to solve complex problems.
That's not to say that there isn't a simple solution to a particular problem nor that we should strive to find it.
But to assume that there are always simple solutions to complex problems is itself a form of ignorance.
[+] [-] lausobo|10 years ago|reply
I clarified that "Sometimes" the causes are political, it used to say "Usually".
But if after a 30 minute read you picked up on a stupid example and you started a discussion on XML vs JSON you are just proving my point. The expectation in the 60s was that machines will figure out protocol, even make protocol, on the fly, by asking about each other. Yet, you want to have another discussion about XML and JSON.
[+] [-] tarkeshwarsingh|10 years ago|reply
[+] [-] spacecowboy_lon|10 years ago|reply
[+] [-] rl3|10 years ago|reply
>What would programming be to you in an ideal world?
More visual, especially when observing execution.
When you're debugging anything non-synchronous—be it events, messaging, distributed systems—it usually sucks, even in the rare case that you do have good tooling.
I'd like to create, view and debug my code in an almost entirely visual fashion. I want to see events and messages perfuse through the structure of what I'm building, with complete temporal control of the view.
[0] http://www.chris-granger.com/2014/03/27/toward-a-better-prog...
[+] [-] giblet|10 years ago|reply
<https://www.youtube.com/watch?v=VZQoAKJPbh8>
A recent iteration <https://youtu.be/VZQoAKJPbh8?t=46m56s> looks wiki-like.
[+] [-] arethuza|10 years ago|reply
[+] [-] bonobo3000|10 years ago|reply
However, programming may be lambda calculus at a theoretical level, but execution is a turing machine. All these little real world things that can be abstracted away in abstractions(!!), have to be unabstracted to meet a bunch of very real NAND gates somewhere, limited memory, resources etc.
Thats one reason it "sucks", but thats why its engineering and not math. Maybe one day computers will just be so powerful that we can afford to treat memory as infinite, runtime as infinitesimal, and build all the abstractions we want for free - then programming will be done :)
In this fun world, when i want to build something ill just draw a bunch of squiggly boxes and describe an alarmingly underspecified thingy i want done. Then the program will automatically figure out all possible inputs, quickly perform a "32 questions" kind of thing and resolve any ambiguity, then produce code. Managers will once again be confused why "adding this textbox is so hard", but this time they will be right - i will just tell lambda to go make a textbox.
[+] [-] lausobo|10 years ago|reply
[+] [-] gldalmaso|10 years ago|reply
Look at everything we built out of arbitrary conventions of boolean logic that has real impact and is shapping the modern world!
>>The computer shifted the complexity of our solutions from the world of atoms to the world of ideas.
And that's fucking awesome! Thanks everyone that was part in making that a reality!
Complexity can pile up in this new world, sure, but we are only starting to get our feet wet. Outside the boundaries of processing and storage, we are our only limitation. We can create things as complex as we can logically describe them.
It's also incredibly difficult to create something that will acomodate everyone else's solutions.
Software development is in its infancy. The fact that we can create absurd structures that still work is great because we can use them even if our skills are not mature enough to make truly elegant structures.
Saying programming sucks and wishfull thinking does not help anyone. Not happy? Start hacking on the next thing!
[+] [-] lausobo|10 years ago|reply
>>The computer shifted the complexity of our solutions from the world of atoms to the world of ideas. >And that's fucking awesome! Thanks everyone that was part in making that a reality!
I glad you are entertained with programming. I am too! but we should judge a tool like programming by its productivity, not by it's entertaining powers.
> We can create things as complex as we can logically describe them.
One of my points is that we can't. To make a single app facebook needs hundreds of engineers and it is still buggy. Humans are, yet again, the weaker link in software engineering. I believe we need fundamentally better tools.
> It's also incredibly difficult to create something that will acomodate everyone else's solutions.
Agreed. I'd very happy with a tool that is not general purpose that could churn though CRUD systems (vast majority of systems our there) in a matter of hours without errors. If you want to something else like AI, or games or whathaveyou, use other tools built specifically for that or a programming language if none are available.
That CRUD tool (gross oversimplification) could be expanded with new capabilities as long as we understand those new capabilities properly.
> Saying programming sucks and wishfull thinking does not help anyone. Not happy? Start hacking on the next thing!
I am, thanks for the encouragement.
[+] [-] catnaroek|10 years ago|reply
[+] [-] TurboHaskal|10 years ago|reply
Imagine you're a painter and then comes some moron (who is probably not a painter) yelling at you:
- Why are you holding the brush that way? Also, I don't know that brand. - You should make thinner strokes, and always start coloring the surroundings so you don't go over by mistake. - Do not bother with the first brushes until you have a clear pencil sketch. Actually, here, use this one that I paid someone else to make. Limit yourself to add these colors. - The painters at X draw ultra realistic portraits, that doesn't even look like a cow!
Programming sucks because we need to eat.
[+] [-] wereHamster|10 years ago|reply
While the UI/UX people gather requirements and work with the client to work out how the app should look and behave, sure, they can use their imagination. But once the requirements are set then in many cases a software engineer can sit down and build the software. There is no creativity needed to decide whether to use a vector or a double linked list if you need to prioritise fast append and prepend. After all, if you break down software to its basic building blocks, it's all mathematics and logic. And there is no creativity in Mathematics.
[+] [-] acqq|10 years ago|reply
There are too many wrong "conclusions" and premises in the text, just an example, here's the author writing about Babbage's and his Analytical Machine:
"he was focused on doing math fast and without errors. He didn’t care how complex the machine was as long as it accomplished that."
Of course, not true, Babbage had to care. He was designing a purely mechanical machine for years at the time when nobody had electrical logical circuits. He designed the simplest "universal enough" machine in the limits of the technology of his time. And the design was never built. But to claim that his design was "too complex" the author would have to design a significantly simpler one under the same limitations and goals.
The whole article is, unfortunately, like this. Uses something that actually happened or somebody did say, "concludes" something else. And the claims that aren't that kind of "conclusions" also sound like from somebody who only very partially understands what he writes about.
This doesn't mean that the author shouldn't attempt to write more articles, he can learn something from it (although I'd suggest him to base his writing on his own, specific, experiences) just that this article as it is is a quite bad potential basis for a serious discussion, IMHO.
He asks "Is there another hardware, general-purpose or not, that would fit our needs more precisely while being cheaper to program?"
The answer is a simple "no." The author just doesn't understand how much of everything was invested up to now for him to pay so little for the CPU's he uses:
https://en.wikipedia.org/wiki/List_of_semiconductor_fabricat...
Note just the "plant stat-up costs in billions" column. And that's just a piece in the whole puzzle. There are big gains for those who'd improve a current state, so the humanity as the whole is much more motivated for the real improvements, where they are possible, than the author assumes.
When we remove wrong conclusions after quoting others, the rant can be summed up to just a few claims, one of major being "I'm confronted with different frameworks and libraries, "everybody" solves similar problems, it "sucks" to work this way, maybe the hardware is the main problem." No.
[+] [-] lausobo|10 years ago|reply
> Of course, not true, Babbage had to care
reference? In any case, the main point is that he was making tradeoffs for his math machine, not for modern software development. Not blaming him, just pointing out it was suboptimal for us.
> The whole article is, unfortunately, like this
I'd love more examples. I have definitely a lot to learn about writing.
> The author just doesn't understand how much of everything was invested up to now for him to pay so little for the CPU's he uses
I don't see how "a lot of money was invested" proves how there is no alternate hardware that would make programming more productive.
[+] [-] xiaoma|10 years ago|reply
Programming isn't something that can be "solved" any more than math or writing is. There is inherent complexity in building apps and there are an infinite number that could be built. The fact that it hasn't been "solved" is no indication that we've "never asked ourself this question!"
[+] [-] mobiuscog|10 years ago|reply
[+] [-] wsc981|10 years ago|reply
There's so much creativity one can put into programming. Especially when programming for oneself and not for Super Evil MegaCorp (not the actual game dev company [0]!). Sometimes it feels to me like art, for example when creating games.
My older brother, at some point in his live, he thought programming sucked as well. But then he stopped doing programming professionally and now just as a hobby and it became fun for him once again.
I will read the article later today :)
---
[0]: http://www.superevilmegacorp.com
[+] [-] cuillevel3|10 years ago|reply
* costs and time, difficult to maintain
* difficult to hire developers, difficult to learn
* no diversity in industry
* users have no influence on product
Well, yes. Software is a labour intensive task. But given the number of jobs digitization has destroyed and the immense gains it provides, I don't think it so bad. Despite the authors criticism it's still an improvement.
I find his argument hard to follow, the author wants to solve 'the problem', but I don't quite get it. The all purpose machine was a good idea, having an evolving eco system, competition, forks, etc. is a good thing.
[+] [-] veddox|10 years ago|reply
[+] [-] aikah|10 years ago|reply
> Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem (there’s not much we can do about this)
Agreed. That's where "lean programming" comes into play. If you have the capacity to make the code change as requirements change then I think the issue is pretty much solved. However, not all languages/solutions are equal in that matter. Obviously TDD, Agile techniques help.
> If we assume that typing code is the way to program, we will never look for better alternatives.
Typing code is a medium. The fact is, for an engineers it usually the most convenient way to create a program.
> But without an end goal, of course you have millions of developers releasing Javascript frameworks every day
How many of these are still maintained 1,2,5 years after?
https://www.nczonline.net/blog/2015/12/why-im-not-using-your...
So I don't think that is really a problem, there is an handfull of well maintained frameworks and libraries in the JS world. Most are not. Most are flashy with a nice "flat" page then you never hear about them again.
It's easy to produce shitloads of code, it's harder to maintain it and build a real community around it.
> Building software is 90% a human problem
Agreed, but like everything humans do.
> What would programming be to you in an ideal world?
There is no general answer to that question. That's why we have all these languages, frameworks and libraries yet we keep on creating languages,frameworks and libraries.
What drives me as a "programmer" isn't the medium, but the goal, the product.
Creating something useful. Languages, frameworks and development methods are the necessary constraints.
[+] [-] lausobo|10 years ago|reply
> [meta] The title of this article sucks, really, it's a bait,
It was not intended. The title just tries to summarize the post. Still, so much to learn about writing!
>> Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem (there’s not much we can do about this)
> Agreed. That's where "lean programming" comes into play. If you have the capacity to make the code change as requirements change then I think the issue is pretty much solved. However, not all languages/solutions are equal in that matter. Obviously TDD, Agile techniques help.
I have a note on Agile. As I mentioned, I believe Agile or lean programming to be solutions. They don't question anything about the status quo, they just try to cope with it. It's good, it's an improvement. But an incremental one from the perspective of the stack of poker chips.
>> If we assume that typing code is the way to program, we will never look for better alternatives. > Typing code is a medium. The fact is, for an engineers it usually the most convenient way to create a program.
Turns out that the medium has an huge effect on our understanding. https://signalvnoise.com/posts/2976-bret-victor-thinks-math-...
>> Building software is 90% a human problem >Agreed, but like everything humans do.
The first rule of the tautology club is the first rule of the tautology club. Of course! the idea is to make programming something that humans don't do, or at least, reduce how much human involvement you need. Humans are the weaker link in software development, we should do like with other things that humans don't do anymore, figure out a solution and put our time to do something else.
[+] [-] edem|10 years ago|reply
http://www.infoq.com/presentations/Simple-Made-Easy
[+] [-] kh_hk|10 years ago|reply
> Of course we have never questioned any of this. We don’t have a direction, a path or an overall goal for programming!
> Let me ask you this: What would programming be to you in an ideal world?
> We don’t know! We’ve never asked ourselves this question!
When at the start of the "essay":
> Turns out, we are horrible at predicting the future and we end up discarding that extra complexity.
Too bad outsiders think (and will for a long time) it's a done thing. Society thinks software is the best thing since sliced bread so it's all around us. It's both a curse and a blessing.
Compared to other fields, CS or engineering is relatively new. It's exciting, it will keep breaking and evolving. And that should be it. It should keep going places without restrictions, precisely because we don't know.
Similarly to scientists ripping open humans on anathomical theatres in the 17th, we are having fun.
[+] [-] lausobo|10 years ago|reply
You hit the spot. Yes, who is it to say that we reinvent programming tomorrow and it useless by next week. Great point.
My answer is, don't look at it from a black and white perspective. I'm not aiming for a 100% future proof solution, that is impossible as you pointed out. But we can make something much more future proof that what we have right now.
[+] [-] arethuza|10 years ago|reply
[No ability to execute, no debugging, no compilation step, no unit tests....]
[+] [-] estefan|10 years ago|reply
Whoever does this - how about sending a percent or 2 my way when you exit for billions :-D
[+] [-] pjc50|10 years ago|reply
We (who do we mean when we say "we", anyway?) don't have a direction, path or overall goal for life, society, the human race and so on. I don't even have a plan for what I'm going to have for lunch next Tuesday.
Programming is contingent and incremental because rationality is bounded and the future is uncertain. We don't know what will be successful in the next few years or how the world will want to use it or what it will be prepared to pay for.
We can build jewel-like systems that are perfectly adapted to their use case using technology to the utmost. This nearly always results in a stranded evolutionary dead-end. The BBC Domesday Project (live video database on an 8-bit micro using PAL laserdisc!) is my favourite example, but there are many.
[+] [-] lausobo|10 years ago|reply
Personally, I don't think we could reinvent programming and make it 100% future proof. But if we reinvented programming it will be much more future proof that what we have now. The reason is that our current stack was not invented in the first place, kind of evolved upwards organically. If we did something it will at least be purposeful.
[+] [-] perlgeek|10 years ago|reply
These days it's trivial to create a CRUD web app that is even save against CSRF when you use a framework like Django.
But of course, nobody wants a simple CRUD web app anymore. It has to do business logic, it must have responsive design, usable on mobile, incrementally load pages, and be an enterprise integration framwork that checks with the credit card processor, the warehouse software etc.
It's just that we don't talk anymore about the things that have become trivial, because we don't spend much time on them.
So of course, in our perception, programming and tooling suck. And they always will. And that's OK, because if everything was breeze, we'd be bored.
[+] [-] espinchi|10 years ago|reply
Very interesting thoughts about this. I wouldn't think programming sucks, until you think about how it could be in an ideal world.
I'd love to see a follow-up article about what the OP thinks about that question.
[+] [-] tracker1|10 years ago|reply
* There is always a deadline and pressure to deliver that exceeds quality controls. * Software development shifted from engineering to crafting a long time ago, mostly because of the prior pressure to deliver. * Poorer quality code that works and building new features on top are easier to sell, than rewrites and paying off technical dept.
I think it comes down to building in pieces that you don't mind throwing away when a better piece comes along.
[+] [-] Udo|10 years ago|reply
> Hiring developers is an extremely difficult task. Learning to program is ridiculously difficult as well.
If programming was a solved thing, that would mean problem solving itself was a solved thing. It has by nature to be difficult. The question is more whether we manage to avoid additional difficulty on top of that. He's talking about the cost of bugs, but I posit the cost of burdensome frameworks and artificial bureaucracies in software development processes is by far bigger and harder to come to terms with, both of which exist in part to manage this inherent difficulty (often achieving the opposite).
> Lots of rework happens because of miscommunications with the user. Other times, the user doesn’t fully understand their problem
This is not unique to software development by any means. Every organization that deals with end users has to negotiate this interface.
> anywhere from 50 to 90% of the cost of building software goes towards maintaining it after the first release
Whether that figure is real depends largely on the type of software you're writing. If this fits what you're doing, the assumption that at some point the program is supposed to be "done" and every bit of time spent evolving it further must be a sign of inefficiency is simply unproductive. That kind of program is more usefully viewed as an evolving organism, and the sooner management recognizes the nature of this the better it will be handled by the organization.
> Our tools don’t make a good separation of essential and accidental complexity[2]––we are forced to crystalize the essential parts of our programs in a programming language and make them coexist with irrelevant, usually platform-specific code (accidental complexity).
This too depends on the nature of your chosen ecosystem. On the whole, interop has steadily improved throughout the history of computing. We have meaningful universal data formats now, and many options for moving code between platforms. Where interop troubles exist, they mostly exist on purpose (like the iOS example you made). You can absolutely solve most of this problem by throwing computing power at it and choosing an interpreted or cross-compiled environment if you want to avoid writing glue code.
[+] [-] spacecowboy_lon|10 years ago|reply
And this was in the CSE stream which was for the less able children.
[+] [-] chippy|10 years ago|reply
We may be programming in our different teams, companies, organisations and countries, but the stuff we make makes an impact and affects the world around us.
This impact is an input into future similar projects and, given time, the technologies that results from wherever will be better for it. Please note that this idea does not mean that any group now is going to make these technologies, but what we do now will influence the future.
The same pattern has been observed in the industrial revolution - many tinkerers, manufacturers and inventors were all sort of learning from each other, all improving. This happened over decades. The main difference with programming is the time dimension. We've only really been doing it at a cultural level for the last twenty years - we're only just getting started in discussing and sharing what we are doing.
[+] [-] ThatMightBePaul|10 years ago|reply
I'd argue Math is still slow and error-prone. Ask any math PHD candidate. Computation is fast, but Math itself has more layers, and more branches than ever. Sound familiar?
That said, some smarties are trying to remove unnecessary layers in programming. I feel like rump/Uni-kernels are looking to simplify the stack. [1] The clear linux project is removing some pieces from the stack. [2]
TL;DR Math is about as noisy as programming :/ I don't buy the premise. But, I enjoyed the read!
[1] http://rumpkernel.org/ [2] http://clearlinux.org/