Coding is Over(medium.com)
medium.com
Coding is Over
https://medium.com/@loorinm/coding-is-over-6d653abe8da8#.ixfq42smv
17 comments
This was painful to read.
Yes, writing code is inefficient. It's unfortunate it's the best way yet to create computer systems.
Yes, a lot of work in programming is line of business applications with slight customization and implementing specific business rules.
Yes, it'd be amazing if we achieved something smart enough that a set of data, business rules and requirements in human language could be used to generate an application. That would be amazing. So would flying cars and living on the moon.
Feels like the author has no context on how difficult their suggestions are to implement, and the point about how we're already there because of GraphQL (?!) and Algolia support it.
Yes, writing code is inefficient. It's unfortunate it's the best way yet to create computer systems.
Yes, a lot of work in programming is line of business applications with slight customization and implementing specific business rules.
Yes, it'd be amazing if we achieved something smart enough that a set of data, business rules and requirements in human language could be used to generate an application. That would be amazing. So would flying cars and living on the moon.
Feels like the author has no context on how difficult their suggestions are to implement, and the point about how we're already there because of GraphQL (?!) and Algolia support it.
Coding is not over. I too once thought as you did.
In a previous job, I worked extensively with LabView[1]. Like Reason, you hook up wires to little boxes. This enables graphical dataflow programming.
LabView enables a person with no knowledge of syntax to write a program. It's great! Until your program grows in size. Then, you have a very large and very difficult to understand system of boxes and wires. Debugging becomes increasingly difficult. Users can abstract the wires and boxes away into more boxes, but after more than a few layers of turtles, you start wondering why you're even using a system like this.
Later on I discovered that LabView was an instance of a "4GL" and that such things had been around for decades. Although some have been successful in certain niches, to my knowledge no 4GL has ever succeeded as a general purpose programming language.
Why is this? It's because textual programming languages are far more general and expressive. Programs written in text are far easier to change, version control, and understand. There is no silver bullet[2].
[1] http://www.ni.com/labview/ [2] https://en.wikipedia.org/wiki/No_Silver_Bullet
In a previous job, I worked extensively with LabView[1]. Like Reason, you hook up wires to little boxes. This enables graphical dataflow programming.
LabView enables a person with no knowledge of syntax to write a program. It's great! Until your program grows in size. Then, you have a very large and very difficult to understand system of boxes and wires. Debugging becomes increasingly difficult. Users can abstract the wires and boxes away into more boxes, but after more than a few layers of turtles, you start wondering why you're even using a system like this.
Later on I discovered that LabView was an instance of a "4GL" and that such things had been around for decades. Although some have been successful in certain niches, to my knowledge no 4GL has ever succeeded as a general purpose programming language.
Why is this? It's because textual programming languages are far more general and expressive. Programs written in text are far easier to change, version control, and understand. There is no silver bullet[2].
[1] http://www.ni.com/labview/ [2] https://en.wikipedia.org/wiki/No_Silver_Bullet
The author's twitter says that they just graduated from a coding bootcamp. I am not trying to silence anyone- but maybe its too soon to be making such claims.
Unfortunately, I've had several idiot project managers like that, who just do not understand the "point" of coding, and don't understand why project development takes as much as it does, why there are bugs, etc.
These people are not fit to be project managers. You cannot manage what you don't have a basic understanding of and appreciate.
These people are not fit to be project managers. You cannot manage what you don't have a basic understanding of and appreciate.
I love this post. I think that when most apps look the same, you start to wonder why we can't just fill in some data and regenerate the UI again. A lot of UI builders work this way anyway: you drag and drop stuff, hook up events to functions, etc.
Why are we still building CRUD apps in 2016? Building that with any tech is just boring, whether it's COBOL, Java, Ruby, or node.
This is the way tool building works. You sharpen a rock so you can work with wood, you work with wood so you can build a trebuchet, you build a trebuchet so you can go to the moon.
I've said it before and I'll say it again. The next breakout programming platform probably won't be terminals and editors. It'll be something that sparks creativity, like the author's Reason example. Mobile apps allllllmost got there; can you imagine if even 1/1000th of Snapchat users had an easy way to program their phones?
Don't be so quick to dismiss someone based on their writing style or their "lack of" education. This is an optimistic, creative article, and it contains a lot of sophisticated insights like this:
> More than that, it allows for infinite “creativity”, also knows as code smells. Most code is pretty rank. Engineers spend countless hours dealing with syntax, typos, indentation, linting, errors, arguing over style and best practices, and making shortcuts to try to coax some of the code to type itself. It’s absurd. And it’s a waste of time.
That's all 100% true.
Why are we still building CRUD apps in 2016? Building that with any tech is just boring, whether it's COBOL, Java, Ruby, or node.
This is the way tool building works. You sharpen a rock so you can work with wood, you work with wood so you can build a trebuchet, you build a trebuchet so you can go to the moon.
I've said it before and I'll say it again. The next breakout programming platform probably won't be terminals and editors. It'll be something that sparks creativity, like the author's Reason example. Mobile apps allllllmost got there; can you imagine if even 1/1000th of Snapchat users had an easy way to program their phones?
Don't be so quick to dismiss someone based on their writing style or their "lack of" education. This is an optimistic, creative article, and it contains a lot of sophisticated insights like this:
> More than that, it allows for infinite “creativity”, also knows as code smells. Most code is pretty rank. Engineers spend countless hours dealing with syntax, typos, indentation, linting, errors, arguing over style and best practices, and making shortcuts to try to coax some of the code to type itself. It’s absurd. And it’s a waste of time.
That's all 100% true.
thanks camgunz. Like I said in my post, I knew this would be very unsettling for many people who have built their lives and identities on coding.
yeah okay... i feel like the author is way too simplistic in her thinking. "coding is over" is akin to house building is over. we know to build every part of a house so why re-invent the wheel? why not have some magical machine that just builds whatever we can dream of?? there are a lot of nuances and things to think about depending on what you're trying to accomplish.
i do think we need to be optimistic about a world where coding is something magical where you can build anything you imagine like some lego set, but there is a huge leap between making some example todo list or implementing a basic user auth system and a full fledged web app and i think she fails to understand that.
at it's core ever app is CRUD, just like a house is walls and a door or a car is wheels and whatever.
i do think we need to be optimistic about a world where coding is something magical where you can build anything you imagine like some lego set, but there is a huge leap between making some example todo list or implementing a basic user auth system and a full fledged web app and i think she fails to understand that.
at it's core ever app is CRUD, just like a house is walls and a door or a car is wheels and whatever.
Why can't we just throw data into a database and have it optimize it?
Well I suppose we could. We could probably build a set of tools that optimized a database of separate tables with connections between them. That's not a horrible idea, I'm reasonably sure we do some of that, though we can still reason about things better than algorithms can, much the same way that hand coded assembly can be more efficient for an embedded device then a JVM and byte code.
But the reason we can't just have such a server, graphql and the browser is because not everyone on the internet needs access to everything on a server. Users should have access to their data, not everyones. You need business logic.
I think they are right that rebuilding the same parts of crud apps is a waste of time, but often the parts we rebuild over and over are abstracted into libraries, modules, classes, packages, gems, etc. And you need to build a few crud apps before you see the commonalities that can be abstracted.
We aren't handcoding bytes on a wire with a telegraph key, we aren't writing a web app in assembly, and that's because we build tools and frameworks and languages. But those tools, etc. still need to get built, and are still being improved, and that means the crud app you built in 1990 with perl and CGI and apache running on slackware, while perfectly servicable, isn't as responsive or useful as the app you build today. And even that 1990 app had CPAN... and CPAN was an innovation. And even perl is still used today, in stuff I use everyday, like git on the command line.
I guess what I'm trying to say is that we stand on the rickety shoulders of giants, and being an engineer means both having the beautiful abstraction to build grander visions and see great vistas before us, as well as to cover over the framework with dry wall CRUD and make it look smooth, and also to climb down and into that framework, and write compilers, parsers, databases, machine learning code, virtualization software and software to manage concurrency between network nodes, to create all of the pieces that we create to make those heights scalable.
That said, I'm appreciative of them for sharing their vision, and think they deserve better than to be insulted ad hominem, instead of having what they wrote critiqued.
Well I suppose we could. We could probably build a set of tools that optimized a database of separate tables with connections between them. That's not a horrible idea, I'm reasonably sure we do some of that, though we can still reason about things better than algorithms can, much the same way that hand coded assembly can be more efficient for an embedded device then a JVM and byte code.
But the reason we can't just have such a server, graphql and the browser is because not everyone on the internet needs access to everything on a server. Users should have access to their data, not everyones. You need business logic.
I think they are right that rebuilding the same parts of crud apps is a waste of time, but often the parts we rebuild over and over are abstracted into libraries, modules, classes, packages, gems, etc. And you need to build a few crud apps before you see the commonalities that can be abstracted.
We aren't handcoding bytes on a wire with a telegraph key, we aren't writing a web app in assembly, and that's because we build tools and frameworks and languages. But those tools, etc. still need to get built, and are still being improved, and that means the crud app you built in 1990 with perl and CGI and apache running on slackware, while perfectly servicable, isn't as responsive or useful as the app you build today. And even that 1990 app had CPAN... and CPAN was an innovation. And even perl is still used today, in stuff I use everyday, like git on the command line.
I guess what I'm trying to say is that we stand on the rickety shoulders of giants, and being an engineer means both having the beautiful abstraction to build grander visions and see great vistas before us, as well as to cover over the framework with dry wall CRUD and make it look smooth, and also to climb down and into that framework, and write compilers, parsers, databases, machine learning code, virtualization software and software to manage concurrency between network nodes, to create all of the pieces that we create to make those heights scalable.
That said, I'm appreciative of them for sharing their vision, and think they deserve better than to be insulted ad hominem, instead of having what they wrote critiqued.
To provide some actual constructive criticism (seriously, everyone?), yes, there is overlap in apps made today. As a result, if tech companies want to stand out when everyone has access to the same tools, they have to code, and code the best.
Game theory is fun like that.
Game theory is fun like that.
I'm sorry but the quality of this article is just too low for my taste.
While the basic idea behind the article is very nice, its not really ready yet. People try all the time, and you end up with stuff like SAP (which still needs coding). I think the only way you can remove the coding (apart from basic: click button -> do: XY) is to advance AI to a point where you can just request an application with basic specs and its made. However, that looks like its still a few years away.
So the future of software is basically PLC programming[1], which has been dying out and slowly getting replaced with cheap ICs or arm chips.
[1] https://i.ytimg.com/vi/xfKXeLj84wY/maxresdefault.jpg
Also some dbs already have a REST interface out of the box like Riak, though I dont see the far more popular databases going anywhere in the near future.
[1] https://i.ytimg.com/vi/xfKXeLj84wY/maxresdefault.jpg
Also some dbs already have a REST interface out of the box like Riak, though I dont see the far more popular databases going anywhere in the near future.
Some good points buried in here (especially about the over-glorification of coding), but lots of wrong or irrelevant points:
> Have you ever wondered why we need a server acting as a middleman between the client and the database?
Well, not recently; without it you have a two-tier architecture instead of three-tier. Two-tier architectures have been used a lot, are well-understood, and are suitable for some applications. Using them doesn't eliminate coding, though.
> Algolia makes a pile of data searchable. I’m not sure how they do it. But what I do know is, a computer is cheaper and better at optimizing structured data than a human is.
I'm going to make a wild guess that there's some coding going on to achieve that.
> We should be throwing data into a pile and databases should organize and optimize themselves using machine learning and other buzzwords.
Building systems that use "machine learning and other buzzwords" to acheive, well, anything often requires a non-trivial amount of coding. So, really, this isn't just talking about a preference for a different locus of coding. Which isn't entirely invalid (though it seems to involve a lot of attribution of magic to tech that the author isn't familiar with the implementation of), but is a long shot from coding being dead.
> People should not be writing database schemas, because we inevitably get it wrong. Database design is an optimization algorithm, not an area of engineering.
To a certain extent, its an optimization problem. That doesn't take it out of the domain of engineering. And, yes, there may be tools that can be coded to take some of the gruntwork out of doing that. And, in fact, plenty that have: but mostly those end up being productivity multipliers for coders on specific applications, rather than eliminating coding for specific applications.
> Product Managers should be able to just make the app do what it’s supposed to do, without knowing how to code at all.
And everyone should have a pony.
> The only thing a company should be creating are the things that make their product unique.
Unfortunately, everyone that's been there first hasn't necessarily released all their work as open source, so if you want "like X but with unique Y", you often need to build X and Y. Once the company that built X first -- when it was unique -- spent the effort, they may not want to give it away.
> My current undertaking is to build an easy-to-use drag-and-drop interface, where anyone and everyone can construct fully-featured, full-stack apps, with no coding.
Coding using a visual rather than textual language is still coding. And tools that replace some coding with visual drag-and-drop diagram manipulation have been used in lots of places, for ages. They definitely have their place, but they generally fail to succeed at being anything more than adjuncts to textual programming for most serious work.
> Have you ever wondered why we need a server acting as a middleman between the client and the database?
Well, not recently; without it you have a two-tier architecture instead of three-tier. Two-tier architectures have been used a lot, are well-understood, and are suitable for some applications. Using them doesn't eliminate coding, though.
> Algolia makes a pile of data searchable. I’m not sure how they do it. But what I do know is, a computer is cheaper and better at optimizing structured data than a human is.
I'm going to make a wild guess that there's some coding going on to achieve that.
> We should be throwing data into a pile and databases should organize and optimize themselves using machine learning and other buzzwords.
Building systems that use "machine learning and other buzzwords" to acheive, well, anything often requires a non-trivial amount of coding. So, really, this isn't just talking about a preference for a different locus of coding. Which isn't entirely invalid (though it seems to involve a lot of attribution of magic to tech that the author isn't familiar with the implementation of), but is a long shot from coding being dead.
> People should not be writing database schemas, because we inevitably get it wrong. Database design is an optimization algorithm, not an area of engineering.
To a certain extent, its an optimization problem. That doesn't take it out of the domain of engineering. And, yes, there may be tools that can be coded to take some of the gruntwork out of doing that. And, in fact, plenty that have: but mostly those end up being productivity multipliers for coders on specific applications, rather than eliminating coding for specific applications.
> Product Managers should be able to just make the app do what it’s supposed to do, without knowing how to code at all.
And everyone should have a pony.
> The only thing a company should be creating are the things that make their product unique.
Unfortunately, everyone that's been there first hasn't necessarily released all their work as open source, so if you want "like X but with unique Y", you often need to build X and Y. Once the company that built X first -- when it was unique -- spent the effort, they may not want to give it away.
> My current undertaking is to build an easy-to-use drag-and-drop interface, where anyone and everyone can construct fully-featured, full-stack apps, with no coding.
Coding using a visual rather than textual language is still coding. And tools that replace some coding with visual drag-and-drop diagram manipulation have been used in lots of places, for ages. They definitely have their place, but they generally fail to succeed at being anything more than adjuncts to textual programming for most serious work.
[deleted]
To put it mildly, I don't get the feeling that the author is much of a coder, and is suffering from Dunning Kruger.
This author is crazy.
here we go again
Intuitive: no. Productive: Well, we haven't found anything better for building software. What would you like to compare it to?
> I used to make electronic music with a program called Reason. I loved it because it let you drag and drop wires between different machines, showing you exactly how everything was connected.
Ever seen a call graph of a non-trivial piece of software? It shows you how everything is connected, but it isn't usually useful on an intuitive level.
> But most of what we do is not engineering. Being an engineer is about solving new problems, and about deep thinking. It’s intellectual work.
Who's "we"? I write software when I can't find something suitable that's already been written. I design it, work out use-cases, come up with a set of requirements, and build it.
> Real engineers code, they say, and coding is what makes you a great engineer.
"Real engineers" do a lot of things. "Code" is somewhere in the middle of the list, after a whole lot of analysis and design, and before a support cycle. Not all people that are called engineers are engineers.
> These are just a few examples of how engineers waste time duplicating the same basic features over and over.
...but as meaningfully different implementations. Unless the author would like to adapt some C code. The stone wheel is heavy and hard to carve. The wood wheel is easier, but flimsier. The metal wheel is easier, stronger, and lighter, but it's still "reinventing the wheel". Doesn't mean that it isn't sometimes worthwhile.
> Software engineers are grossly overpaid
Define "overpaid". I'm paid roughly what the market will support in my area. If the market's broken, then it's ready for disruption, and you're in a position to become very rich when you figure out how to take advantage of it.
The author bounces around all over the place. I like the core idea of the article (which I take to be simplifying work where possible and avoiding duplicate effort), but there's so much slop and fluff around it that a basically good idea is just buried.