21 ms·

The future is fewer people writing code?

• mattnewton 10y ago
  I don't know if I agree with the author since they didn't seem to provide any evidence / argument for why the future is codeless. They did warn me though that I wouldn't be able to understand from my vantage point in Silicon Valley though so maybe other people see the argument? But from my perspective code is only growing without showing signs of abating.
  • madelinecameron 10y ago
    First off, I agree. I agree that everyone who continually says "programming" is dying and in 5 - 10 years, "AI" will be writing code (or whatever else they can dream up) have no idea what they are taking about. Programming is definitely going to get easier and I don't doubt that it will become a common skill. I just doubt this idea that professional programming is a dying art or something. It is just silly to say that because tools that lower the barrier of entry are becoming more common, that the entire profession will soon be dead. (Also, I am like 75% sure that it was a sponsored article to advertise for the company named in the article)
    • FilterSweep 10y ago
      I believe that: > It is just silly to say that because tools that lower the barrier of entry are becoming more common, that the entire profession will soon be dead. Is actually due to Labor Supply vs. Labor Demand. I can envision a world where majority of jobs are all replaced by machines (from Baristas to Accountants), and web/software development (among other fields, such as specialized medicine) are some of the last places for people to remain self-sufficient off their own labor. With this over-abundance of supply, employers are capable of being extremely discretionary over their hires, and are able to pay just enough for their human capital to sustain themselves.
    • mattnewton 10y ago
      I think we are on the same page, but I was genuinely hoping someone could fill in the gaps the author seemed to be hand waving about. Is programming going to become an easier skill? Absolutely. What does that have to do with the means? What evidence do we have that drag and drop interfaces will replace the majority of coding? Why not something like swift playgrounds or some other IDE innovation that make the coding easier but get out of the way to expose the text if need be? Why is that harmful? Why is that not coding anymore?
    • rimantas 10y ago
      Programming won't be any easier. It's like claiming that in the future thinking will get easier. I'd claim otherwise: keeping in mind recent trends of "outsourcing" the knowledge many brains just don't have enough building block in working memory to do complicated thinking.
  • seangrogg 10y ago
    Another SV resident, I can understand given WYSIWYG tools and CMS like WordPress it would "only seem logical" that eventually nobody needs to code and we just magically make things work. I think the problem with that assumption is that there has been virtually no traction on "just telling the computer what to do" - whether text or voice. There is also the assumption that programming is not getting more difficult. While not everyone is working on "capital E" engineering efforts, it's a bit ridiculous to think that our jobs are getting easier to automate in the wake of Internet of Things, Virtual Reality, Augmented Reality, and projects like Web Assembly pushing browser-based development into interesting, new places. Just because we made it easy to set up a blog doesn't mean we made it easy to "program with words".
• madelinecameron 10y ago
  Nice sponsored article there.
  • jmagoon 10y ago
    I actually clicked the link for whatever visionary platform bubble is--it's a workflow engine! Real groundbreaking stuff there.
• lmm 10y ago
  Coding in a good language already consists of writing about the things you care about, not the things the computer cares about. Text (with a few symbols) turns out to be the best way to express computations, not to a computer but to a human reader/maintainer. The future is most professionals writing code as part of their job, just as the present is most professionals writing as part of their job.
• buckbova 10y ago
  > To get there, programming tools should first use our language. For instance, to turn a button red, we shouldn’t have to write code. We should just be able to point to the button and select a shade of red. We've had that for over twenty years.
  • throwaway2016a 10y ago
    Yeah but web developers still tend to do it the "hard way" but editing the CSS directly. Why do web developers still do it that way even though visual tools exist? My guess is because with working with text is more efficient. The cognitive load of finding a setting in the UI, moving your mouse to it, and selecting the value is far greater than just typing.
    • laggyluke 10y ago
      Text can be version controlled and diffed.
      • buckbova 10y ago
        And so can IDE generated code from drag and drop controls. Visual Studio and many others have this out of the box but there's plenty of companies that do well selling exactly this like telerik. I personally don't and been doing it the "hard way" since the beginning because it feels less confining. And I don't want to rely on an IDE to build something. Plus the code it generates was always kind of kludgy.
    • warfangle 10y ago
      Why do people still build business process tools when they could point and click in Salesforce?
    • Pfhreak 10y ago
      Why do people play D&D instead of WoW? Perhaps, in part, because one allows for a greater expressiveness -- albeit with a little more planning and cognitive load.
• pmlnr 10y ago
  “50 years from now, I can’t imagine people programming as we do today. It just can’t be." Dear writer, let me introduce you to FORTRAN, COBOL, LISP, or BASIC. These are alive languages, all 50+ years old. Coding didn't change much. The languages, the methodologies, the ideas change, but the approach is the same, and whoever thinks this will soon (50 years is not _that_ far) changes, have never had to debug something nasty. Doing that with voice commands in my opinion is significantly harder compared to what we have now. We will have tools, accessible, easy tools; Arduinos and Pis of the future; sure. But it will not replace, nor eliminate or reduce the amount of code written.
  • xxs 10y ago
    you missed assembler; it's still a thing
    • deleted 10y ago
      [deleted]
    • pmlnr 10y ago
      I did miss that, true; however, Assembly is heavily architecture-tied. Therefore x86 Assembly significantly differs from, for example, ARM assembly, but nonetheless I should have mentioned it.
      • slededit 10y ago
        Its annoyingly incompatible and RISC is more verbose but really the concepts are pretty much the same. Load something to a register, do some very basic operations on said registers and save it out. An X86 programmer should be able to pick up other CPUs fairly easily. Although delay slots will probably piss them off every time.
  • fossuser 10y ago
    I agree, though I think there are improvements that could make things better even for existing languages. It just doesn't seem to be a main focus of our industry. I found a lot of ideas in this article to be pretty interesting: http://worrydream.com/#!/LearnableProgramming http://worrydream.com/#!/LearnableProgramming
• bbctol 10y ago
  It seems like this is focused a lot on what people want to do, as opposed to what provides value. Not that that's a bad focus! But if you want to predict the future, I think market forces would be a better indicator; as much as we might want to move to a future where programming involves more intuitive tools, I still think it will be more powerful, and thus valuable, to be able to muck around in the code.
• tribune 10y ago
  "...so why are we having a serious conversation about grooming children to become software developers before they’ve even gone to middle school?" We're not, really, but given the pervasiveness of computing technology we're recognizing that it's important for children to have some formal experience with software design concepts regardless of which career path they choose. I'm a firm believer that at least some coding ability is beneficial in any profession. It's like writing, or vocabulary; you don't "need" it for some professions, per se, but being a good writer enhances both your professional and personal life in many ways, so it's worthwhile to teach. It's much the same with coding.
  • circlefavshape 10y ago
    This. Whether or not we need more professional devs is beside the point. At coder dojos, for example, they're not teaching design patterns, they're teaching the basics - assignment, loops, conditionals - the kinds of things that allow you to automate computation in other fields of endeavour
    • rimantas 10y ago
      There is also one million other skills that would be beneficial.
  • leggomylibro 10y ago
    Exactly - teaching people how to use software to solve problems at an early age is not railroading them into a single career path, it's setting them up to be more effective in the career path that they eventually choose. An administrative assistant who can write scripts to collate and email weekly reports to their boss is far more valuable than one who spends four hours a week combing through excel spreadsheets. A visual artist who can write their own plugins for Blender/Maya/Photoshop/etc will be much more flexible and productive than one who performs the same 2-minute-long string of commands hundreds of times a day. A machinist who can quickly design a part in Solidworks and send it to a CNC mill or lathe will be able to serve a wider range of customer needs than one who outsources that design work or crafts the part by hand. And so on. Why is there so much hostility to the idea of teaching children some basic programming skills at an early age?
• deathcakes 10y ago
  "To add an example for clarity, think of the field of typography — until the Digital Age, typography was a specialized occupation. But with new programs like Microsoft Word coming into existence, typography (e.g. formatting a document, setting the margins, making sure the lettering is appealing, etc.) became something everyone could do easily without much thinking." Without much thinking pretty much encapsulates what Word did to presentation standards, at least in my experience. Let us never forget WordArt. Part of me always wants to make the argument that these things are difficult, not just because of an abstract syntax and arcane rules, but because these things are genuinely difficult to reason about - attempts to make difficult things easier by papering over the cracks results in a lot of pain for a lot of people. Bits ping off and people are left unable to even begin to solve the problem. However the very, very, obvious flipside of this is that lowering barriers to entry is pretty much always a good thing. It invites unconventional perspectives and novel approaches - how could that be a bad thing? Sure, some people will make crappy things that shouldn't have ever existed but by the same token some people will make great things that never would have been without the lowered barriers.
• Kinnard 10y ago
  > For instance, to turn a button red, we shouldn’t have to write code. We should just be able to point to the button and select a shade of red. Someone is going to have to right the code so that the end-user can just click buttons. So if this future of programmatic interfaces is coming, it's going to require more people writing code to build it— not fewer!
  • xigency 10y ago
    Just point to the button and select a shade of being able to point at the button and click a color. (Yes, that is confusing.) I don't think the author or the person interviewed has used Visual Basic, or understands why a developer might not want that.
    • Kinnard 10y ago
      Essentially what he's saying is that in the future people will just read and not write . . .
• dkopi 10y ago
  "The future I imagine is a world in which programming is self-explanatory, where people talk to computers to build software. To get there, programming tools should first use our language." But is: "For every button on the page that is a "warning" button, replace the background color to red." Necessarily better than? $("button.warning").css("background-color", "red")
  • malux85 10y ago
    Yes - it's miles better. If you're unconciously competant (i.e. good at your job) they might seem like they both take about the same cognitive effort to understand. But think for a beginner: What is $ ? Is it money? What are () for? What is CSS? I want to shade it, so lets do background-shade .. oh, color only works, so you have to know all the terms. Can I do "background-color" "red blue white striped" What is button.warning? Can I do button.border ? These are all questions a newbie could ask - because they have no experience in the "domain language"
    • bbctol 10y ago
      The questions raised was "better," not "easier to learn." In absence of everything else, being easy to learn is a point in favor of natural language--but the inefficiencies, ambiguities, and probable weakness of using natural language are big marks against it. Checkers is easier to learn than chess, but has fewer players.
  • mrob 10y ago
    Inform 7 is a programming language that looks similar to natural English. As far as I can tell the only benefit is tricking beginners into thinking it's easy. By the time they figure out it's a normal programming language only with extra verbose syntax, it's too late, they're already a programmer. If we had a real natural language based programming language it would have all the problems of law. Laws are written in a very formal style that takes a lot of training to understand, and despite this they contain enough ambiguity to support a whole industry of lawyers arguing about them. Making programming similar to law would not make anything easier.
• mlashcorp 10y ago
  It saddens me that laypeople equate software development to writing code, that's like saying an architect just knows how to draw.
  • jasonthevillain 10y ago
    Which is an excellent example. Architects still do architecture, the tools just evolve.
• throwaway2016a 10y ago
  I remember going to a mobile conference in the early 2000s and every single vendor there was saying that developing mobile apps using UML was the future. No code, just map out everything in a diagram. Granted a smart phone was unheard of at this point so most mobile apps wouldn't even be called apps by today's standards. A decade and a half later and mobile developer is a highly skilled _coding_ position.
  • AnimalMuppet 10y ago
    And UML is... well, maybe not dead, but nobody thinks it's going to replace coding.
  • ktRolster 10y ago
    in the early 2000s and every single vendor there was saying that developing mobile apps using UML was the future. No code, just map out everything in a diagram. UML in later versions got so bad that even the original creators disowned it. Turned out that putting everything into a diagram was just as hard (and less convenient) than writing it as code.
• mafuyu 10y ago
  I think the author is missing the forest for the trees, here. Schools often don't have much of a computing curriculum, and these classes are great for improving general programming literacy. And if one kid finds out he really enjoys it when he wouldn't normally have through school, that's a win. It's true that most of them won't become programmers, but we don't teach biology in high school assuming you won't become a biologist, either.
• PaulHoule 10y ago
  Progress happens slow in the short term and fast in the long term. In the 1980s, there was a consensus that "software components" enabled by object orientation were a pipe dream. They were so long as you were using C++ which was barely binary compatible and where you couldn't reuse objects in a .so file without also having an .h file. It was awful, not at all a minimal viable product. Then Java came along and a number of other languages that adopted essentially the same model for OO programming such as Python, PHP, Ruby, C#, etc. Now you can cut and paste a few lines of XML into Maven and woohoo... You've incorporated a software component into your system. People bitch that it has to be XML, but the sheer ease of doing so means it is not hard at all to get 100+ dependencies in a project and now the problem is dealing with the problems that come when you have 100+ dependencies. (And of course the same is true with npm and every other language that has similar tools.) Two big themes are: (i) tools that reduce the essential difficulty of software development and (ii) antiprofessionalism in software engineering. Compilers like FORTRAN mean you don't need to have the intimacy with the machine you need to write, say, Macro Assembler. That is mainstream, but other technologies, such as logic programming and rules engine are still stillborn. In theory tools like that mean the order of execution does not matter so much so you don't need the skill to figure out what order to put the instructions in. Practically they are yet to become vernacular tools that are palatable to programmers and non-programmers. (Anything programmers can't stand will be 10x more painful to non-programmers, I can tell you that!) Anti-professionalism is another big theme. Had computers come around 20 years earlier we would probably have a programmer's union, licensing and other things that would make a big difference in our lives. As it is, the beef that programmers have is not that we don't get paid enough, it is that we are often forced into malpractice by management.
• spotman 10y ago
  Maybe an unpopular opinion here, but I agree with the article overall. My view is less that programming is going away, and more that all jobs are. Not immediately or anything, but I don't think we are going to magically produce programming jobs for all the masses who are going to need a job. Having been at this over 15 years I have single handedly automated thousands of jobs, and of those a healthy handful are making things more efficient that a project needs less programmers, etc.. So while we will still need programmers probably forever , I'm not sure why people think that the number of programming jobs will do anything but stay the same or decrease, while the number of candidates increases. Tooling has come so far, and it's going to go farther. You don't need to know a lot to make something meaningful anymore. How we expect to train all children to be programmers and think that by the time they are our age it will still be a field that is lucrative is silly I think. My prediction is with all the new programmers coming into the field intersecting with the tooling getting better, intersecting with that a lot of other markets need less people I think we are left with a crowded field of players where the average skill level is lower because the tasks do not require it to be all that high any more. Programming is the new carpentry. Probably jobs for a long time , but training the children now like it's going to be the most amazing career path is short sighted I think. Considering this, I hope my kids don't pick programming as a career. I would love to be wrong.
  • ktRolster 10y ago
    Programming is the new carpentry. Probably jobs for a long time , but training the children now like it's going to be the most amazing career path is short sighted I think. Train your children to think. Give them the freedom to change career paths if necessary.
  • freerobots 10y ago
    Supporting your opinion the BLS puts the job outlook of a programmer at -8% between 2014 and 2024. I hold the same opinion as you. I think that new languages and tooling will empower people to do more with less while being easier to learn. Combine this with globalization plus stagnating economies and the outlook of programming as a career seems less lucrative.
  • marcosdumay 10y ago
• random3 10y ago
  That's a bit Cocky, considering the amount of knowledge and effort google has behind AI, quantum computing and others. But I guess the main point of the article was not that, but the Bubble plug.
• emblem21 10y ago
  Dear writer, the future is fewer people writing sponsored content.
• lnanek2 10y ago
  If it was another company doing this, there might be a chance it is meaningful. Google is not that company, however. They started and killed visual programming projects before, dumping everyone's data. The last one was called App Inventor. At least they made the code open source so MIT could write App Inventor 2 based on it. The best thing they could do to make me think Project Bloks will be meaningful is to give it to another company in a similar fashion. Otherwise I expect they would just kill it next year anyway like other projects of theirs.
  • lern_too_spel 10y ago
    The difference is that Bloks isn't a service that can be shut down. It's essentially a set of open source schematics.
• ISL 10y ago
  Are there graphical languages that advocates like? The only graphical language that I've encountered professionally is LabVIEW, and I've yet to see an instance/programming style where it has been superior for anything but quick prototyping. A language that's editable in both flowchart and traditional formats could be very useful, if executed in a way that doesn't cripple the traditional side of things.
  • robotmlg 10y ago
    People seemed to like Scratch [1] a lot a few years ago. Haven't heard much about it since, but IIRC it can switch between flowchart and text mode. [1] https://en.wikipedia.org/wiki/Scratch_%28programming_language%29 https://en.wikipedia.org/wiki/Scratch_%28programming_languag...
  • pp19dd 10y ago
    LabVIEW was eerily satisfying to write code in. Or at least some type of code in. Loops and logic blocks got a tiny bit weird, but overall you could do a lot with sub-vis. I find myself craving it even 15 years later.
    • maxxxxx 10y ago
      LabVIEW gets really weird once you get to things like loops or, even worse, threading. You will start craving some good old fashioned code very quickly. I haven't seen any kind of visual coding environment that didn't fall apart quickly once you got to more complex scenarios.
  • corysama 10y ago
    I've heard tons of praise for https://docs.unrealengine.com/latest/INT/Engine/Blueprints/ https://docs.unrealengine.com/latest/INT/Engine/Blueprints/ and I've job-interviewed several people who have built simple games without bothering to type code.
  • optforfon 10y ago
    I have an artist friend who does everything in Max/MSP. At first I was rather dismissive and thought he should just learn to code properly - but the patching environment makes him able to get results incredibly fast - much much faster than I can do with C++ (even using something like Openframeworks)
• winstonewert 10y ago
  Dear article writer, Natural language sucks, it is amibigious, difficult to manipulate, verbose, and have too many non-functional degrees of freedom. After all, that's why mathematics left natural language and adopted the mathematical syntax we have today. Diagrams suck, they are ambigious, difficult to manipulate, verbose, and has too many non-functional degrees of freedom. That's why cook books don't have diagrams to describe recipies. The syntax will never die, it is the only sensible we have to define programs.
  • n00b101 10y ago
    > Diagrams suck And yet anytime two or more programmers get together to talk about what they are creating, they start drawing diagrams on whiteboards.
    • winstonewert 10y ago
      And it is on a whiteboard because it is not useful enough to record in a longer term medium. I'm not saying diagrams are useless, they just make a poor substitute for syntax.
      • krapht 10y ago
        I'm going to disagree on that. Every day I wish I could intermix textual and pictorial representations of logic in the programming I do. In particular, any series of computations that can be represented as a directed graph, e.g. a streaming data workflow, or state machine, is much more easily understood pictorially than textually. The flowchart and decision tree exist for a reason to describe algorithms.
        • pessimizer 10y ago
          > In particular, any series of computations that can be represented as a directed graph, e.g. a streaming data workflow, or state machine, is much more easily understood pictorially than textually. As long as it is very simple. Electronics already have a highly developed visual language for describing their functions - but if what was going on inside every chip was illustrated just as what was going on between chips, it would be entirely unintelligible. Instead, any visual representation is at a particular scale, and well known portions are represented as blocks with cryptic textual notes next to each interface (ACK, EN, V0+, CLK, PT2, HVSD, WTFBBQ, etc.), labels to identify company or type, and an expectation that you know what they do or can find out on your own (and not an expectation that you understand how they do it.) Anything simple enough to be completely expressed in human-comprehensible pictures should be exposed to the user and modifiable (even if not by using pictures, but forms.) I totally agree, if that's what you and this article are trying to say. My experiences in trying to encode actual human workflows in BPMN have taught me that when using pictures it's harder to express things of any sophistication than in words - because of words like "with" and "each" and "all", "if" and "when," and because of ways things change over time, and because of separate but overlapping/interacting flows that languages can express easily but pictures not so much. In pictures, that involves looking all over your picture for different things, trying to figure out how to draw lines to them; if the condition is once or twice removed from the object of the search, it involves trying to untangle massive knots with your eyes and memory. Theoretically, that is. What it involves in practice is scrawling words all over your picture (just like in a circuit diagram.) Words that express the same types of relationships over time and type as the picture is trying to express projected onto a plane, words that could be easily expanded to include those relationships and eliminate the 18 types of lines, the 25 types of shapes, the 12 types of shape borders, the 16 color schemes and the long list of rules for connecting them that had to be invented to avoid coming up with a textual syntax.
• Forge36 10y ago
  -on mobile so I apologize in advance for bad grammar and typos I don't think the author understands the purpose of the project. Google wants more coders. As a company Coders are likely one of Google's largest expense (At my Job staffing is 25% developers, and staffing is ~80% of our current budget). Does Google necessarily need more developers writing code? No, however they could use more people who can code to solve the small problems they face daily. I think it's more likely we'll have people writing code informally, and as a small part of their overall job. >Writing code will become less and less necessary, making software development more accessible to everyone. I agree with that sentiment, however I fail to see the link between more accessible development and fewer people writing code. This process has been happening for years. >The real benefit of something like Project Bloks is that it actually removes the code. But is that new? What if something more advanced is needed? Excel is a good example of writing code for a job. Access is an example of programming without writing code (it's sql with a GUI). Both tools are popular however people have a hard time doing advanced things. This is also perhaps due to the high price of creating the building block interface/software cost. By thinking logically, people may not write code formally, they may not write any code: however it will encourage people to create solutions to the problems most applicable to them. Maybe their solution is 90% the blocks provided by their program. 10% code they wrote so handle their edge case. Perhaps it's something they only engage in one day a month. In the end I think we'll see more code, more people writing code, and programs with more handling of the common tasks as building blocks but the ability to write code for the complex parts and plug it in where needed.
• WorldMaker 10y ago
  As someone that has had several times now to "productionize" or "modernize" an Excel spreadsheet or Access database many times, this is one of those prognostications this is one of those things people think from time to time and thus far in my experience tend to be incorrect about. The issue with "computational thinking" in so far as how this article seems to want to teach it and how most schools often do teach it already in the real world is the tendency to stop at the basics and Office applications and just enough VBA/macros to give people a feeling of competency without giving them a glimpse into the real depths of programming and what software developers really do. I keep wanting to make a XKCD-style sketch graph of the idea. But there's a lot of Dunning-Kruger over-competent business people that thinks all the software they need to run their business is spreadsheets and spreadsheets pretending to be databases like Access. To them real software developers seem over-paid based on their experience of Lovecraftian "systems" they can hack together given what they think they know. That's a very real and dangerous place for business people to be, but it is unsurprisingly common. Those people don't respect programming as a discipline and a craft, and sometimes those are the people out in the corporate world controlling software developer salaries or morale... It's also the same lack of knowledge about software as a craft (as engineering, in a very classical sense) that leads people time and time again to the well of "well in the future people won't be coding because [ Excel will do it all | There will be a visual tool everyone will easily understand | AI will do all the programming based on natural language queries | Insert some other magic idea here ]". There's as much art to software development as there is science, and forgetting that art will still need artists and will not make itself is a strange thing that is surprising common. To be fair, there are a lot of software developers themselves that have played into this delusion, and it's something of a trap that a software developer can easily fall into. We're trained to break down systems and try to automate them to their fullest potential and it's hard sometimes to avoid that meta-leap to wanting to do it to our own systems. We fall into building "Business Rules Engines" that we think some business users might be able to understand and comprehend and might obfuscate away the need for programming. We experiment with boondoggles like visual programming languages and "auto-coding" experiences. We get grandiose visions of the machine or software product or great AI that will make it all more accessible... The future will probably look like the present in that regard. We'll still have the Dunning-Kruger folks building mission critical applications out of complex webs of Excel and Access and other past and future productivity tools we build in the goal of making programming more accessible. We'll still have software developers eventually hired to clean up the messes and craft versions that can sustainably last or reliably operate outside the hacked together environment from which they were originally built. There will continue to be software developers continuing to think they can build the environment that will done rule them all and save everyone time (and meanwhile eat up so much of software development budgets and time to built it)... And all of these groups will still have a hard time communicating between each other the real risks and efforts involved in any of it.
• meira 10y ago
  Well, I disagree. When I started to program, in 2000, it was só easy that a child 12 years old could do (HTML,php,ftp). Although anyone can deploy something online today, I doubt it's só easy for a 12 years old kid to learn something similar to what I used, like React, node and git. Editado: conclusion, programming is becoming harder, not easier.
  • ktRolster 10y ago
    programming is becoming harder, not easier. So true. I'm not sure why, it shouldn't be that way.
• 50CNT 10y ago
  This article strokes me the wrong way. If any of the things described in there were possible, why the hell would I be writing any code? I'm a lazy programmer for gods sake, and code I don't have to write is a win in my book. Matter of fact, once I got past the point where the novelty of writing lots of code wore off, I'm spending most of my time trying to write less code. That side step all these miracle solutions for bringing coding to the masses in one fell swoop and eliminating its tedium do is that "Hey, technically, if you draw pictures instead, it doesn't count as writing". Yes, technically true, totally useless. I personally believe that whoever comes up with this again and again deserves to be bludgeoned by a copy of "K&R The C Programming language", turned into a picture book. All 70,000 pages of of it, with the big glossy full-page, double-page foldout prints. /rant
• deleted 10y ago
  [deleted]
• gerbilly 10y ago
  Think of the the other time when people want to be precise: contracts. Contracts are written down in text, so they can be edited, carefully read and referred to later. He might as well also say, that in the future there will be no written contracts, we'll go back to debating and settling our issues verbally in public.
  • audleman 10y ago
    > that in the future there will be no written contracts, we'll go back to debating and settling our issues verbally in public. This is a great metaphor. Only I would change that he thinks we should "go back" with he thinks we are going to invent a magical technology that lets lawyers from two companies drag and drop a few images together and BOOM there's a legally binding contract.
    • fourthark 10y ago
      The lawyers will explain what they want to the computer. They will have no idea what the computer made of it, but the result will look close enough that they won't be able to argue they didn't get what they asked for.
• whack 10y ago
  The writer presents an ideal vision for the future - one where people can "build software" purely through abstract thought, without needing to know the semantics of specific tools and programming languages. If such a future is possible, that would be great. I would be all for it. But the people who are already in the field, working in the trenches, don't think it's a realistic vision for the near future. All attempts thus far to produce "layman friendly programming" have been either failures, or relegated to non-functional toys. Hence why we don't want to waste our scarce time and resources on such moonshots. If the author and his peers disagree, they are free to found/invest in such ventures. And if they're right, they can make a fortune for themselves in the process. But just sitting in the sidelines and armchair quarterbacking is a pointless waste of time for everyone involved.
• pklausler 10y ago
  So long as it's the right people no longer writing code, that future sounds pretty nice to me.
• Animats 10y ago
  Visual Basic was a success until Microsoft killed it. Remember when you could write HTML with a WYSIWYG editor? Most sites can be built with Wordpress. The hosting side of things is mostly automated and becoming more standardized.
• hyperbovine 10y ago
  Anyone else stop reading at "intersectionality"?
• seangrogg 10y ago
  "[...] so why are we having a serious conversation about grooming children to become software developers before they’ve even gone to middle school?" For the same reason we groom children to become mathematicians, scientists, readers, writers, historians, musicians, actors, etc. before middle school. Project Bloks grooms your child to be a Software Developer about as much as their first grade teacher grooms them to be a Quantitative Analyst.
• dasil003 10y ago
  Non-programmers make this mistake all the time: thinking that the syntax is the hard part of programming. No, the hard part of programming is understanding in very specific and rigid details how to accomplish a task. What the author doesn't realize is the enormous amount of processing power, shared culture and empathy that goes into human interaction. Even mighty Google doesn't have the compute power or the architecture to replicate this. Until computers can understand humans at a human-level this will not be possible. Several breakthroughs will be necessary, and even still I expect decades/centuries before it happens if it even happens. Essentially we're talking about the Singularity.
  • bdrool 10y ago
    > Non-programmers make this mistake all the time: thinking that the syntax is the hard part of programming. Programmers make it all the time too, or at least something very similar. See all those people who are on the endless quest for the "perfect" language, which usually means one which allows for writing the shortest code, sometimes at a very high cognitive cost for very little payoff. No, I really don't want to do a massive amount of mental backflips just to save a few characters, thanks.
    • pm90 10y ago
      There isn't anything wrong with this kind of obsession tbh. We do need SOMEONE inventing, experimenting with new languages and if someone else is excited about doing so I'm quite ok with that :)
    • Jtsummers 10y ago
      Many people looking for the "perfect language" want one that minimizes cognitive costs. An initial increase (comprehensive type systems like in MLs; rust's notion of ownership and lifetimes; Spark Ada's comingling of specification, code, and types) in cognitive cost which, once internalized, results in reduced cognitive costs for certain tasks. Less time spent developing tests. Less time debugging. Less time spent in maintenance (not because it's not needed, but because it goes faster when it's done).
    • 10y ago
• hackguru 10y ago
  There is an upper bound limit for how abstract a general purpose programming language can become. Programming languages mainly exist because of their ability to remove ambiguity. Our natural language on the other hand is very vague. Many people might read the same exact article and interpret it differently. This is natural language's great feature. This feature is why a kid, without fully formed thoughts, can learn and use a natural language. Hence I don't see a day programming languages will completely fade away. Programs are result of a careful thought process that cristalizes a concept into a process and that process is only complete when you can describe it in an unambiguous language. One may argue that natural languages are capable of being not ambiguous. A subset of a natural language can be used without ambiguity but that is just definition of a programming language. Arguing programming languages will fade away is the same as saying math one day will not be necessary because we can explain all concepts in physics or other sciences in natural language.
• zwieback 10y ago
  The linked article by Jeannette Wing is more interesting than the techcrunch article. She wrote really interesting stuff on subtyping in the 90s so her name jumped out right away.
• justinlardinois 10y ago
  Is "computational thinking" really something that isn't already being taught in schools? There's a link to an article that spends three pages defining it: https://www.cs.cmu.edu/~15110-s13/Wing06-ct.pdf https://www.cs.cmu.edu/~15110-s13/Wing06-ct.pdf It alludes to computer science, but really it just boils down to solving problems by breaking them into parts. In other words, problem solving skills. It doesn't sound like anything special to me.
  • grossvogel 10y ago
    I don't think it's being taught adequately to lots of people who aren't destined for careers in tech or academia. Look at the nearly universal disdain for math and especially "story problems," as well as the mystical aura of "coding" outside of those tech / academic circles. In that context, I do think early encounters with programming might be a great entry point to "computational thinking" for some who aren't well served by existing curricula. It certainly makes more sense to me than trying to train every child to write code for its own sake.
• LoSboccacc 10y ago
  same as always right?
• linguistbreaker 10y ago
  Did the author not notice the text on the Project Bloks homepage he linked to that says "creating new ways to teach computational thinking to kids." Pretty disingenuous or arrogant to act like you're setting Google straight xD. Also, "intersectionality."
• dkarapetyan 10y ago
  Programming is really formalization. That is the hard part. The kind of thinking required to take something and express it as a set of logical and computable constraints. It doesn't matter how much money you throw at the problem we are never going to have the entire population being able to "program". It is the same reason despite all the training in mathematics only a few people go on to get a PhD and come up with something novel in mathematics. The rest of the population gets by with basic algebra, not even calculus is required.
• ktRolster 10y ago
  Once upon a time, Excel didn't exist, and if you wanted to do that kind of thing, you needed to program it. So Excel replaced a segment of programmers. At the same time, many other programming opportunities opened up. We have code in every single doorknob (at least, a lot of them). Some coding usages will be replaced, but others will always open up, at least for the forseeable future.
• cnfjdnx 10y ago
  And in this thread you can see programmers getting defensive and flustered over the notion that they too might be vulnerable to automation.
  • walshemj 10y ago
    Or recall all the other times a silver bullet has been hyped - first I recall was "the Last One" in the late 70's early 80's
• pessimizer 10y ago
  Thinking that turning buttons red is the major problem of programming is mistaking the interface for the substance. It's as if you wanted to teach people how to develop new automobile technology by selecting the shape of the steering wheel, the fabric in the interior, and the color of the paint job. The problem with programming is that computers can't understand your intention. What amateur programmers need is side-effect free functions, efficient abstracting away of cores and memory-management, and static analysis that makes functional bugs as obvious as a leak in a plastic bag. Computers will never understand your intention; programmers barely understand your intention and they have a lot more in common with you.
• maker1138 10y ago
  Programming is done in code for the same reason mathematics is done in notation, for specificity. Doing programming in plain English would be just as cumbersome as doing math in plain English. I don't think anyone can quite fully imagine the nightmare of trying to program in a recursively enumerable language[1]. [1] https://en.wikipedia.org/wiki/Chomsky_hierarchy https://en.wikipedia.org/wiki/Chomsky_hierarchy
  • sdegutis 10y ago
    Hell, even trying to explain how a relatively simple shopping cart web app works, unambiguously, in plain English, to an executive, is extremely tedious and verbose, requires defining a lot of specific terms, and at the end of the day it still confuses the hell out of him.
    • beachstartup 10y ago
      you should work for better executives.
  • adrianratnapala 10y ago
    I think this is correct -- but. In Utupia (aka Nowhere) we will have programs that a human being can know is correct. This might involve mathematical proofs, tests and whatever. But how do we know that those things are correct? In some cases, it would help if we had an English text explaining what the program should doo + computer verification that the program really does that. The English text is only one part of the picture -- but an important part. This is what acceptance testing tools like Cucumber and Robot try to do; but they avoid actually parsing English. Computers are getting better at parsing human languages, so I expect improvement in this field.
  • sapphireblue 10y ago
    Isn't doing programming projects much less cumbersome when you hire a professional programmer and express a high-level project spec to him/her? Why cannot a sufficiently advanced machine-learning model behave just like such a professional? Modern models learn to achieve goals in increasingly sophisticated 3d environments and even learn execute commands in some very limited form of natural language. You could say that the question of achieving more humanlike performance may be "just" a question of engineering and scale.
• fapjacks 10y ago
  Well, that's what they said forty years ago, so...
• jfe 10y ago
  Any time a new idea comes along, there's always someone who claims everyone needs to learn it, and that it needs to become a part of school curriculum. In my opinion, the ability to think laterally is far more valuable than the ability to think 'computationally'. The latter is comprised of essentially one pattern of thinking -- procedural -- while the former opens one to an infinite set of patterns with which to think. The computer is a decent vehicle for exploring patterns or modes of thinking once you've discovered them, but the goal should be to explore the pattern, not the vehicle.
• dudul 10y ago
  Is the future of math to get rid of notation, greek letters, etc?
• maus42 10y ago
  >But with new programs like Microsoft Word coming into existence, typography (e.g. formatting a document, setting the margins, making sure the lettering is appealing, etc.) became something everyone could do easily without much thinking. Correction: Most people do it without thinking. This does not mean the majority of the typography on the internet (and eventually printed) is good or well done. My LaTeX setup produces fairly good typography for math work, without too much thinking on my part, after setting up the packages, fonts, etc and learning LaTeX, which did took some time. (And ironically enough, writing LaTeX feels quite a bit like coding...) But first of all, deciding to use and learn LaTeX (or some other workable solution to produce good typography, it probably isn't the only one but the one I'm familiar with) requires you think about typography and realize that good typography is needed in the first place.
• mempko 10y ago
  I'm sorry the future is clear. Perl 6 will be the last programming language. The only way coding will become visual is when we use unicode symbols to do diagrams in perl 6.
• modeless 10y ago
  He's right but he doesn't understand why. We'll write less code in the future but it won't have anything to do with visual programming languages or other fancy tools for "programming without code". Code will always be the best way to write programs. The reason we'll write less code in the future is we won't need as many programs. The future is in machine learning and machine teaching, which enable a single program to perform a huge variety of different tasks. We'll train the computers of the future by showing examples and correcting mistakes, as we do with our fellow humans. Machine teaching is a different thing entirely from programming.
• nijiko 10y ago
  There will exist both. You need one to create the other. Eventually graphical will become the textual representation to create the higher power. There is always a lower and higher power, even if they are equal in design.
• jwatte 10y ago
  "Writing code will become less and less necessary, making software development more accessible to everyone." I heard that same argument 30 years ago. "4G" and "expert systems" and "application generators" and "visual programming" were going to do away with the "engineering" aspect of software engineering. However, in reality, we write more complex code for a simple business app now than ever before. Once hard AI can extract requirements and transform them to systems, we can retire from coding, but probably not before then.
• codingdave 10y ago
  Some of my coworkers have been using similar concepts to teach K-5 coding in a few school districts for a few years now. And the big, surprising impact has not been about the code, but about the problem solving... I'm getting the stories second-hand, but apparently the concept of debugging problems becomes so ingrained that they "debug" all their efforts. When they make a mistake in math, they debug their process to fix it. They debug what is wrong with their handwriting to improve it. They think of everything as a problem to be solved, work towards solving it, and are doing wonderfully across all subjects. So the question of whether these kids will be coders as they grow up really doesn't seem to be that important of a question -- they are being taught how to succeed at whatever they try. I'm excited to see these types of programs move forward and become prevalent throughout our educational system.
  • marklubi 10y ago
    > the concept of debugging problems I've been seeing this same thing happen with my 7 year old son (I'm a programmer), and I always encourage him to find out why something didn't work out the way he expected it to. Whether they grow up to become a coder or not, I'll be happy when more people look for the cause of the problem, rather than just simply treating the symptoms.
• wentoodeep 10y ago
  Future isn't about writing less code or using a building blocks, but by using AI and NPL to produce results from user intents. Perfect example would be Wolfram|Alpha and Wolfram Language. It's no longer about developing a software, mini app or microservice but more about getting answers. Either textual or graphically.
• sp527 10y ago
  This is a very amusing article because I went in expecting fairly sophisticated arguments about Cloud, PaaS, DevOps, layers of abstraction, higher-level languages/paradigms, etc. Perhaps this was naive, given the domain of origin. The irony is that the future probably will enable individual programmers to have an even more outsized ability to create value, and fewer programmers will be necessary to accomplish the same set of tasks. Sadly, cogent arguments about meaningful issues aren't exactly TechCrunch's forte.
• Falkon1313 10y ago
  It's not about code. When you, as a programmer, consider the purpose of programming, and how computer-illiterate people view it, things are different. A programmer's job is not to type code. It's to find out what is holding other people back from achieving what they want and find a way to remove that barrier. It's to solve problems and help people make more valuable use of their time. It could be the analyst that spends hours of drudgery printing out things from one system and retyping them into another (then going back to fix the typos) when what they want to be doing, what would enable them to provide value, is analyzing the output from the second system. It could be the junior exec that spends countless hours manually collating data to build spreadsheets and presentations about their projects, when they want to be doing is trying out new ideas and refining their projects. Many people were raised to "write each vocabulary word 30 times" and see drudgery as a necessary, albeit frustrating, part of their jobs. Programmers automate that away so those people can do more important and useful things and produce more value. It's not just drudgery though. People have hard problems, often vaguely defined, and programmers help them understand, specify, clarify, and solve those problems. Younger generations are more computer literate, but still often just use computers and don't realize how much control they could have over them. They may use programs that don't do quite what they need, not realizing how easy that would be to fix. Even if they're not the ones doing the programming, just recognizing that a programmer could help solve their problems is valuable. At the same time, many non-programmers don't realize how hard some things are to program, or how clear, precise, and unambiguous things need to be defined in order for computers to produce the desired result. They assume something must be simple when they can't even define what the something is. Or they assume that because a program exists, any programmer could make an equivalent but slightly different program quickly and easily. We don't need to teach everyone to code, we certainly don't need to teach everyone the syntax of some specific language. But we really do need to teach them to think in these terms. What problems do you face? Which of those could be automated or streamlined? How would you specify it clearly and unambiguously? What edge cases and special conditions do you need to deal with? etc. Given that line of thinking, those who are interested will learn to program and those who aren't will at least understand it. Some hypothetical pictocode/vocalcode/AIcode doesn't really matter. People need to understand the basic concepts of problem-solving and automation, how they can be useful, and what makes them relatively easy or difficult.
• ankurdhama 10y ago
  Programming is the act of "describing" a computation to a computing machine. In the past people used gears and levers to do that for mechanical computers. The way of describing computation can exist in many forms, like, formulas in excel sheet or using timeline to describe an animation or using C to build a device driver. All these ways have their own particular context to be useful. So, it doesn't make sense that in future we will have "one particular way" of describing computations.
• nercht12 10y ago
  To each their own. Yes, I'm sure one day more people will use software that allows them to put together amazing programs using complex GUIs that do wonderful magic. These may be business programs that do statistics, or games, and we've already seen both (hello Excel, hello game studios). The problem, as it always has been, is that point when you want to do more and suddenly find yourself in asm land or looking to talk to mysterious "drivers". After all, what's a port anyways? Does that mean my computer has Docker built-in? As I hint, people will hit that wall of mystery, and lower-level programming become inevitable. After that happens, they eventually become accustomed to this idea of telling a computer what to do by strict commands according to a specific protocol. For the average guy who never gets into it, you could tell him it's kind of like talking to a dog. "Sit." It sits. "Love." It wags its tail. "You're so smart, pooch." It gives you a blank stare... and keeps wagging it's tail. These days, when I look for a programming language, it's not about the syntax sugar, it's more about the feature set that comes with the language: things like the module and build system (e.g. Java is pretty easy), the ease at which both complex and trivial tasks can be accomplished, and the availability of support community and libraries.