There are many things that we do or could do to make the ssential complexity more manageable.
Something that we do already is abstract away parts of the essential complexity (CRUD, entities, validations, etc) where you have DSLs to specify that essential complexity.
But there are many other things we could as well, like some sort of ontological autocomplete that would help you specify your business model (a User may have these fields, a “Sale” is better represented as a “Transaction” in order to handle returns)
Moreover, re the Facebook App example, the ease of creation vs control is a false dichotomy. A page builder of sorts could spit a predefined design (to have something working ASAP) but there is no reason you couldn’t customize completely to your liking, as if no page builder was used. In other words, having a working app ASAP by using defaults, in order to aid requirement discovery, should be a feature or programming environments/tools/libraries framewors and not an either-or.
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.
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.
> [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.
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.
>>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!
UML didn't pick up for whatever reason and visual programming fell into the valley of deception. I expect that with more UI/UX research we can get to the plateau of productivity in the next decade.
Visual programming could be very well an alternative. Or fucking oculus vr or god knows why. I 100% agree with rl3, it proposes a very interesting and challenging problems for the UI/UX folks.
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.