All these tools exist for a reason, it's not "madness", it's individuals who wrote some code and open sourced it for the benefit of those who might find some use in it. Just because a tool hits the front page of HN doesn't mean you need to use it. I find it ridiculous when people complain about the js tooling ecosystem (especially beginners), "too many tools" is only a problem for someone who doesn't have a real problem to solve. If you were tasked with the job of hanging a window curtain, would you walk into Home Depot and exclaim "omg, hardware is a mess, why are there like 40 different types of drills, why can't they just make this simple??". It is simple, you are the one making it complicated by obsessing over the options instead of focusing on getting the job done. "but I want to pick the best tool for the job", well if you don't know what that is, hire an actual professional, it's their job to know.
I'm not sure this analogy works. My brother-in-law is a builder and I would certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd have an answer. (If I didn't have him to ask, I'd probably be able to differentiate by "brands I've heard of" and price, with a sprinkling of research on Amazon.) But if those 40 different drills all had slightly-to-greatly different characteristics and then had a fundamental paradigm shift every six to twelve months, rendering previous drills potentially obsolete, would the professional builder really be able to answer definitively? Can anyone in web development really answer definitively as to whether you should use npm by itself, grunt, gulp, or even make?
(Possibly someone who knows a lot about drills is going to tell me I'm an idiot in a second...)
This is the flaw in your reasoning. A better drill does not make the older one incapable of doing the same thing it has always done to meet your needs. For something to be made obsolete, the alternative must be definitively superior by definition, so the reason for picking the superior option is clear in such cases, but even then, you don't have to use the superior tool. If a traditional drill can meet your needs, you are the one creating a problem by using a tool that doesn't provide you with clear benefits.
> My brother-in-law is a builder and I would certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd have an answer.
If you told your brother-in-law you needed a new drill, he'd likely ask "what are you going to be using it for", and then you'd explain your requirements and he'd give you an answer based on that. If you said "I really want to get into building stuff, but I'm not sure which magnetic drill press is the best option for a beginner", he'd probably say "whoa whoa whoa, that's a specialized tool for a specific kind of job, just stick with a regular drill and if that doesn't do what you need come back and ask me again".
> Can anyone in web development really answer definitively as to whether you should use npm by itself, grunt, gulp, or even make?
The crux of my point is that this isn't a useful question to ask. The question should be more along the lines of
Q. "I need a way to run some custodial tasks related to the operation of my application, what should I use to accomplish this?"
A. "Well, you could write some shell scripts and run those directly or with npm's script running capabilities, or if you prefer to use JavaScript to define these tasks since you're already using that for your application you can try gulp or grunt; grunt takes a more declarative 'config file' approach while gulp takes a more imperative 'streams' approach but they basically do the same thing, though, you've been a C programmer for 10 years so you might already feel comfortable with make, so you could use that I suppose, but you won't be able to easily import js code from your application into make so if that's something you want to do then you probably want gulp or grunt...." etc.
These tools didn't just emerge from the ether, they were created in response to specific issues. The existence of some arbitrary library or framework has absolutely zero impact on whether or not your existing solutions are adequate for the problem at hand.
Thank you for your thoughtful and considered response. I'll just leave out the bit about drills, because debating analogies is always unwise, especially if the analogous subject is outside of one's area of expertise!
> The crux of my point is that this isn't a useful question to ask. The question should be more along the lines of
Q. "I need a way to run some custodial tasks related to the operation of my application, what should I use to accomplish this?"
I think you've just rephrased the question, no? We all know that "run[ning] some custodial tasks" is what a task runner does; but many wise people have expended many words telling you which of these increasingly fancy task runners you absolutely must use, ecosystems have built up around them, and the waxing of one and the waning of another does have a significant impact on the decision-making process.
> These tools didn't just emerge from the ether, they were created in response to specific issues.
I'm not sure people were really desperate to move from "configuration to code" or thought they really needed streams in their task runner before they were told they did, so for me I struggle a little to see what the "specific issue" was that gulp solved over grunt. The movement away from grunt and gulp to npm scripts and even crusty old make(1) is, of course, at least partly in reaction to the added complexity of these task runners - so in a way that's almost like unsolving a "specific issue".
I think we see the early growing pains of a new ecosystem.
React is great and a fantastic tool but by making it "just the 'V'" it opened up a lot of options and complexity in the ecosystem and Redux/Reflux/Flux/Relay each are trying to fill in the missing pieces. And yes it's hard to figure out and painful even for seasoned vets. But its getting better, the community seems to be settling on Redux for the most part over Flux/Reflux (Relay tries to solve a different problem).
NodeJS web development is kind of in the same boat. There's still no clear "winner" in the framework wars there like Django/Rails. I don't know why these trends seem to be magnified in the JavaScript ecosystem but it's similar to the early days of Java web development in the late 90s early 00s (Struts anyone?).
How hard is it to program these types of systems ? Its sounds quite technically challenging to build an automated system that can easily steal information from Target etc.
I'm going to take the other side of this argument and suggest that we didn't create the dog and the limitations in the dogs abilities.
I suspect that this will be difficult for the HN community to hear, but we must face the upcoming realities.
Though I think the article may be assigning more abilities to AI than is actually feasible in our lifetimes, let us not forget that most back-end developers are doing basic I/O and data manipulation tasks. Put something into a database, get something out of a database. Front-enders are doing layout, animation, sizing and colouring.
The average modern programmer doesn't spend their time writing if/else/then statements, I believe the average programmer spends their time writing GET/SET/EDIT/DELETE flows.
I believe in the next 10 years, artificial intelligence will be able to model and create these basic systems based on human input. UX and possibly even UI can also be trained. A/B testing can certainly be trained.
Those who think programmers can't be replaced begin to sound like the Luddites who felt the loom could not match the quality of their craft.
Note: I am a full-stack developer, I believe 90% of my day job will be replaced by AI in the coming years. That final 10% often deciding what to do or the best how, will likely be the main task.
I did a bit of research in program synthesis, which is probably the closest academic field to this sort of thing (albeit in the realm of programming languages rather than AI/ML). I have two main conclusions:
• Current methods to generate programs fundamentally do not scale. Most practical research is about how to extend small-scale synthesis systems to large-scale problems, rather than synthesizing large programs outright.
• The best way to scale these systems is to make them more interactive. Let the programmer do what's easy for humans and use synthesis for the parts easy to automate. This is another way of saying that program synthesis is less about fully automatic programming and more about (radically) better development tools.
I am confident that we will not have automatic programming systems that can handle non-trivial programs by themselves in the next 10/20 years, barring the sort of paradigm-shifting breakthroughs we can't really predict. Instead, we will have systems that can generate some amount of code and work in tandem with programmers—perhaps through sketching[1], programming by demonstration or just much-improved Intellisense.
The current trajectory is that programming is to become easier, not obsolete. The result will not be fewer programmers but more programmers, largely because people with less expertise will be able to become programmers: think Jevons Paradox[2] for programming.
Programming as a job will change and people will certainly have to adapt, but the job as a whole is not going anywhere.
Current program synthesis isn't that advanced. At least not compared to state of the art AI.
Recently AI has proved it can beat expert humans at all perfect information games. Go has a ridiculously huge search space, but by using neural networks AIs can learn to narrow it down to a manageable size.
Program synthesis is just like a perfect information game. You have a search space, a state, a set of goals, etc. You could theoretically make it into a board game, and have human experts challenge computers at it.
> You could theoretically make it into a board game
But not actually. Program synthesis is hard even if you have perfect formal requirements. In practice, gathering formal requirements is by far the most difficult task. You're probably better off building a system using modern development practices than trying to collect formal requirements Let alone translating those requirements into code, which is easier than coming up with the requirements but still difficult.
> Recently AI has proved...
FYI, it's not as if the program synthesis folks haven't heard of neural nets... you're giving researchers who actually do this stuff all day surprisingly little credit.
I think that getting the formal requirements is in some ways easier than programming. People can describe the things they want the computer to do, like sorting a list so it's all in order. Actually coming up with an algorithm that does that efficiently is much harder, and is where bugs come from.
I mean yes good program synthesis wouldn't replace programmers on it's own. But it would radically change how programming is done and make our lives much easier.
I'm just saying that AI is a quickly advancing field and predictions like "not in 20 years" have been defied months later. Applying deep reinforcement learning to tasks like game playing is relatively novel, and has only really started to succeed in the last 2 years.
I think that measuring state spaces is really misleading. (Although we totally did that to aggrandize how good our synthesis system was, at least to ourselves :P. The space of possible programs, even short ones in a small language, quickly gets hilariously large.)
Past a certain point the structure of a space is what matters which dictates how well any given search strategy will perform, and that doesn't readily generalize across domains.
I have not seen anything that would lead me to believe that results like AlphaGo will meaningfully generalize to such an extent. I still think that it would take more than just incremental work to get from where we are now to scalable program synthesis.
You are right, but I'm just trying to say that AI is now believed to be able to beat all perfect information games. If you could model program synthesis as a game (regardless how boring/unfun it might be) computers could beat expert humans at it. OR, we have game that humans are still better at, and AI researchers at big companies will spend years attacking it for fame and glory. Either way it's interesting.
The proportion of systems programmers that can writte assembly code consistently on par with the quality of that from a decent compiler (such as Gnu's GCC) is probably less than 1%, and they take orders of magnitude more time to do so. Yet, you do not observe system programmers dying out. They use C (and increasingly, C++, Dart, etc) to build bigger and more complex systems, with more demanding requirements.
Ditto for application developers. We now have this amazing enginees called DBMS, which handle out of the box a bunch of common requirements, and whose reign and management has spawned a new class of job that did not exist 30 years ago: DBAs. Some of those are glorified IT grunts, but many are not! They build (information) systems that are bigger and more complex than ever by translating business use cases into a description that is understandable by the DBMS engine.
I could keep going on and on: web frameworks, game engines, simulation models, etc, etc. The point is that the hard part about this craft is not to know how to make the machine compute some XYZ calculation, it is to understand that computing XYZ is an acceptable way to fullfil a business need within the limits of available resources (in the dimensions of development cost, runtime cost, infrastructure maintenance, etc).
Note, I was talking about the 'average modern programmer'. I believe your argument points to a smaller more specialized sub-sections of the field.
At the same time, you say "We have been there before", but we haven't had the quality of AI that we are reaching today, so in many ways we have not 'been here before'. Let's not forget, there was a time when elevator operators thought they were irreplaceable by a machine. Today, you can't imagine having somebody operate an elevator.
A few years ago you had to be a 'web developer' to build a web-page. It was unimaginable that somebody who is barely computer literate would be able to put a website online. Today, you can run an online store without knowing anything about programming.
I suspect DBAs won't have an illustrious future as machines learn how to model data. Yes, they will need a person to train them, and tell them what to do, but I suspect an AI system can look at all the potential modeling options and give a layperson the option to pick one which best suits their needs, or recommend one.
As far as 'magnitude more time' for computers to do the work, I often find this argument interesting with respect to processing power in IoT. In life-threatening situations, performance is very important, but often as long as a persons time isn't being wasted, it doesn't matter if a machine takes twice as long.
Already today standard CRUD web development is largely automateable. I already have my own specialized scripts from years of experience, targeting backend, front end, design components, that generate most of what I want with some basic inputs. I imagine most experienced web developers have some internal tooling like this too.
This kind of approach already does replace programmers, and could do so a lot more. But what do you mean by replaceable by AI? How would that work?
>I imagine most experienced web developers have some internal tooling like this too.
I don't think that's true at all unless you're talking about 3rd party tools like rails scaffolding. What languages / frameworks are you using by the way?
The boilerplate stuff that can be replaced by scripts is maybe 10-15% of my time anyway. The rest of my time is spent at a much higher level either trying to interpret client requests, trying to help the client decide what they want, making high level design decisions, or adding features that require way to much customization to use automated code generators.
This is much different if we're talking about a language like C where a much higher percentage of my time is spent on boilerplate code. However with newer languages and frameworks I think we're reaching diminishing returns for what can be automated by either the language itself or generator scripts/frameworks.
There is a huge productivity difference between using C and raw PHP when writing a CRUD app. There's less of a productivity boost (still huge though) when moving from raw PHP to something like Rails. And there's even less of a jump between Rails and something newer like Phoenix. I expect that the next 10 years will give us even smaller incremental improvements.
I hadn't strictly thought this out, but I guess what I'm thinking is that your basic CRUD scripts on steroids. What if it didn't need your domain knowledge to run the scripts? What if the styled output of the scripts was high-quality UI? - Not to shame your scripts, but I'm thinking back to my Rails days and though I could 'generate' everything, I then would have to manually go in and edit the code so that it did what we really wanted.
What if the person requesting whatever function (report, process, notification, etc) could have this system built without a developer?
That make developers replaceable. I'm not suggesting this is happening in the short-term, but as you say yourself, you use scripts for your basic CRUD development. What is stopping those scripts from moving up market to the point where you are not needed.
Front-end devs who used to write HTML and CSS would have said they where always needed because a computer can't make a webpage. But look at SquareSpace, Wix and the like. Again, this isn't every job, but this is a portion of the market which is no longer served by a person, and that will continue.
The new jobs will be in training and building these systems, which I think is historically how industrialization has progressed.
I don't think the replacement of programmers is going to come in the form of AI actually writing code in any normal context we consider writing code.
It's more going to be that a lot of the superficial patterns if/then (and quite a lot of scripting) that are being done today will be easily replaced. Not that writing a new kernel or some other advanced job is going to be handled by machines.
In that context I think it's going to go fast and be in our lifetime.
Agreed, I don't think the 'average programmer' is writing new kernels or ... advanced job'. The average programmer is working at an SME or Agency, getting systems to run, sales to happen and be tracked.
I'm basing this on the amount of jobs and interviews I've been to where the tasks are normally completely uninteresting from a technical stand-point. I now work at a government science and technology research agency and much of the work here is still quite rote.
I used to think this way, but this assumes there's an upper limit to demand. I think as the capability of tools increase, so will user expectations in capabilities and coverage.
Sure, programming will be more about asking the right questions than implementing solutions. We'd think that'll be easy, but most people have no idea what they want in life, and philosophy is still hard.
The way I see it, "programming" will become an archaic term. It might become a branch of ethics, but for machines rather than people. It'll involve setting intelligent boundaries.
I mean if you are talking about something like weebly then sure. If you are talking about something like Tony Stark's assistant then you are really talking about replacing almost every occupation. If AI becomes that smart then it will probably take over the world anyway before we even realize it has happened.
The main problem with replacing programming is that programming is constantly evolving. Weebly can do most if not all of web 1.0 and some of web 2.0, but there is still a lot that it can't do. The rapid pace of technology doesn't slow down enough for our automated tooling to catch up. Unless we are talking about basically a sentient AI then I just don't see this really happening unless we are talking about replacing programmers that are barely programmers at all.
How long is that though? Decades? More? How do you train a neural net to take a vague description of a desired outcome and produce results that fit the requirements? We are no where close to the general AI that would be required.
I certainly believe that classes of automation problems will be done by machine learning but I have a very hard time believing all programming tasks are going to be replaced any time soon.
Interesting point about how long it will take to train. It makes me think that the way we look at sprints and fast-iterations today may work in AIs favor.
Build this -> builds -> fix this -> fixes -> change this -> changes.
Automating 90% of the work will only make software cheaper, and more in demand, as we are very far from creating every possibly useful software. Developers pay might even increase because of it.
Automating 100% of it is a completely different thing. But well, that's hard AI definition. Software development is among the last kinds of work that will get automated.
As someone else already pointed out we actually do have robots doing surgery. AIs are not dogs - that's a bad analogy.
Right now development costs per head are sky high. If there's any way to cut that spend, you better believe executives will be all over it. A lot of businesses don't care so much about quality and craftsmanship - as long as their customers are stuck with them they're perfectly willing to ship the most minimal product they can get away with.
> Right now development costs per head are sky high. If there's any way to cut that spend, you better believe executives will be all over it.
There is already a big trend of automation albeit on the IT side and not on development. Where it used to take a separate IT team and developers and DB admins etc there is growing field of devOps with automation. Companies, especially startups are biting into this trend and vendors, especially Cloud vendors are spearheading this movement.
If there is glare of possibility of automating the development, these vendors and companies would have been all over it. This behaviour is not seen, means that this a possibility that exists in distant future.
"Bankers" is obviously a broad term, but I'd point out that just about everyone employed in the financial industry in a role where they are giving advice or soliciting/executing transactions have very strict licensing and continuing education requirements. Just look at the list of FINRA licensing exams: http://www.finra.org/industry/qualification-exams
(Of course, even licensed persons may choose to make poor choices. That said, I've taken a few of those exams, and they are no joke.)
And the FINRA licensing exams focus almost entirely on the laws that are intended to protect consumers from bad actors. To study for those exams is to have it drilled into your head what you can and can't do. Unfortunately, much of what collapsed the US economy wasn't actually illegal, and in the case where laws were broken, the bankers were comfortable with knowingly bending the rules.
User themselves are, too: look at all these BSD-style "provided as-is, explicitly no guarantees" licenses that people take enthusiastically.
And for something aircraft-grade or medical-grade, you definitely meet with rather strict controls on a case-by-case basis (unlike the wholesale licensing).
As an extremely vocal individual, being vocal actually is a loss in productivity. When I am trying to communicate what I am doing to my co-workers - it leads the project from slowing down - and me unable to meet my deadlines.
This is why I do not like to waste my time explaining others what I am doing. Its more productive for them to specify the Inputs and Outputs and me doing my thing.
You're talking about someone who is too noisy. This kind of person probably benefits from an open environment with instant feedback. Even though the group may suffer a bit short term, in the long term, that person will be a better team member when they learn when and how to speak.
People who are too quiet can also benefit from being among a respectful group. Safety in numbers, and you can learn from your peers.
These are not hard and fast rules. I'm just discussing times when open environments can help teams. The parent of this thread did not mention any of the benefits of open offices.
You made a pretty sweeping assertion about software developers. Is this an anecdotal observation or do you have any empirical data to back it up? Genuinely curious...
You mean this? -- "Software developers grow up with more screen time than others. They need forced interaction in order to communicate enough in person. Otherwise it's all by text and can easily degrade to passive aggression."
Yup it is a sweeping generalization. I'm comfortable making it. I am/was one. It's totally anecdotal, based on my 15 years experience in work and school environments around both engineers and sales-y type people. The engineers are, on the whole, way more comfortable with screens than people. There's absolutely nothing wrong with that.
I'm not aware of any published research but if I were going to design an office I'd try to research people's experiences by asking friends or Google [1]
All engineers are different and there are many who prefer people to screens. I think the rest of my first comment explained that people are not all the same and can change over time.
I would never create an office seating plan without getting to know each individual. I would also change it up over time. Sitting in the same place all the time for years is too boring.
I see where you are coming from, it's just I doubt your premise. I don't think your average software developer grows up with more screen time than the average teenager playing XBox360 or PlayStation III. Heck, I know accountancy and law students who were socially well adjusted that played more Counter Strike than I did messing about with my Linux system when I was a student!
> I know accountancy and law students who were socially well adjusted that played more Counter Strike than I did messing about with my Linux system when I was a student!
Sure, there are individuals at any point on the scale. We're talking about averages though.
I have no qualms about disagreeing over where the averages lie. In fact I would widen my generalization and say that younger people are, on average, more comfortable talking through screens than directly person to person. Young engineers are just a subset of that who I think are more likely to be screen focused.
I'm okay with embracing some elements of stereotypes. Denying them entirely seems like an equally useless generalization.
This sub-thread was started by someone who felt open office environments aren't effective. Yet, open offices can be a tool for getting people used to person to person interaction. Every person, group, and organization will decide whether they think that's important or not.
Just a small difference of opinion, I honestly asked to understand where you were coming from :-) I've also got only anecdotal information, in all likelihood you could be correct!
Open communication within any organisation is very important so a developer who sits in his own office all day is a concern I'm in agreement with you. I guess I'm just not convinced of the reasons for the behaviour. But I think your observations are interesting and valid, so I appreciate you taking the time to give me a solid answer!
Sure thing! Thanks to you also for making me think =)
> I guess I'm just not convinced of the reasons for the behaviour
Reasons for behavior, even for a single individual, are super tough if not impossible to nail down. But we can make some educated guesses based on correlations. If we prevent ourselves from forming such hypotheses, life might get pretty boring. In hindsight, my original statement could be more accurately prefaced by "in my experience, ..."
Its going to put downward pressure in the price of education. We really need an international market for education.