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 architect…
You agree with the author. >> No, the hard part of programming is understanding in very specific and rigid details how to accomplish a task. The real benefit of something like Project Bloks is that it actually removes the code; it allows children to begin thinking programmatically, without the obstacle of syntax. And this is a tough distinction to make, because people often use “programming” and “coding” synonymously…
The future is fewer people writing code?
211–220 of 256 posts
Re: The future is fewer people writing code?
#212Earlier quoted context omitted.
There's a serious gap in the writer's mind about computation and programming. It's like the author is suggesting that "eventually we won't need writing: it will be replace by writing-thinking or picture-writing". It's completely absurd. Specific, complex ideas can only be described and communicated in text. Not pictures. Blueprints, for example, have a pictorial element to them, but their fundamental value is our abi…
Blueprints/schematics are far, far superior at conveying the information they do compared to a written narrative. Given the ease of preparing written text compared to drawing schematics nobody would go to the trouble of doing so if that weren't the case.
Re: The future is fewer people writing code?
#213Earlier quoted context omitted.
Yes, and that's how I would use a language that would allow mixed picture and text logic flows. At a certain level of abstraction block diagrams greatly assist understanding program flow, and it is redundant that I have to write the code and then draw the block diagram later for documentation. Going back to electronics, I don't think anyone would argue that schematic block diagrams are inferior to reading the raw net…
"I don't think anyone would argue that schematic block diagrams are inferior to reading the raw netlist." Well, no, but some may well argue that reading the HDL is better then a diagram. I have experience working with both the HDL and schematic in the FPGA world, and in my estimation text-based HDL is way better than working with a diagram. Of course, YMMV, my brain may just be more optimized for processing text inst…
That should be a great fit for a textual HDL instead of labouring through a schematics mainly linking pins to pins again and again. It would even be much more expressive, now that we often have chips so big that they cannot be represented efficiently as a single symbol on a single sheet but are split in smaller blocks looking like HDL ports without the flexibility; now that µC, SoC and other kinds of chips have pins that are so much muxed out that they don't have a clear, expressible function, meaning that grouping them in blocks is more of random choice than a good solution. And this multiplexing means that you'll often have to change and change again the connections of your wires in the schematic, and that would be much easier to do with an HDL.
-----
That's why my mind was blown when a software job forced me to use a graphical tool like Scade. It felt like coming 20 years backwards, when in electronics HDL were not popular yet and we had to design FPGAs and such with schematics. And that was even worse, because the graphical representation looks parallel, concurrent, as a electronic schematic does, except that it doesn't match anything on the software side: first the specification/design document you have to implement is generally sequential, not concurrent, and then the generated code and the way the CPU/computer works are sequential as well, not concurrent. So you have this weird looking graphical part in the middle, which looks parallel but isn't really, and messes with your brain because you have to perpetually translate between the sequential specification to it, and from it to what it really does sequentially.
An appaling moment to do this job and discover that they considered it an improvement on C/Ada/whatever regular programming. And I didn't mention the tooling; like when what could have been a simple textual diff turns into an epic nightmare you are never sure you can trust the result, if you manage to get a result.
Re: The future is fewer people writing code?
#214Earlier quoted context omitted.
> I don't think an oil change is a tune up. Maybe it is. It's not. I have a couple of 60s Mustangs and several newer cars. My original '65 needs ignition service (what most people call a "tune up") every couple of years (of very modest usage). My '66, converted to electronic ignition, gets about twice as long (and 10x as many miles) before needing ignition service. They both end up fouling plugs because of the terrib…
> My diesel Mercedes and Nissan LEAF obviously never get tune ups. You don't do valve adjustments on the Mercedes?
About the only thing I've done abnormal on the car in 7 years is replace two glow plugs. (And when the second one went, I actually replaced the 5 that hadn't been changed yet, since they are cheap and I didn't want to take the manifold off again to change #3...)
Re: The future is fewer people writing code?
#215Think 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.
> 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.
Re: The future is fewer people writing code?
#216Earlier quoted context omitted.
I agree and I disagree at the same time. For professional programmers, many people on this forum, the format that we use (text) is almost certainly the most efficient (yet conceived). It's made better with better tooling, of course, like IDEs that help us refactor, show errors in code as we edit, etc. The author's point is that many more people will be programming in the future (hopefully) than are today. But not as…
From a first principles perspective, it's me and the computer, and I want the computer to do something. My laptop has the following input devices: keyboard, mouse, webcam, and microphone. I mostly use the keyboard and mouse. There are some places where the mouse is better than the keyboard. I was playing online chess today, and I like to drag and drop the pieces. It feels more natural and not that much slower than in…
Re: The future is fewer people writing code?
#217Earlier quoted context omitted.
Well, it's dramatic in the little things, but not so much in the big things. Cars now go 100,000 miles between tune-ups. They used to go, what? 10,000 miles? Cars are much safer in collisions than they used to be. Most cars now have air conditioners. I've driven in a car without AC in Arizona in July; believe me, AC can be a really big deal. Most cars now have automatic transmissions, power steering, and power brakes…
>Cars now go 100,000 miles between tune-ups. They used to go, what? 10,000 miles? I'm curious what your definition of tune-up is, because I don't believe there exists a car that can go that far unmaintained without doing lasting damage to various systems. After a quick Google, my impression is that most 2016 cars have a first maintenance schedule around 5k-6k miles. Some as low as 3,750.
Re: The future is fewer people writing code?
#218So 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.
Re: The future is fewer people writing code?
#219Earlier quoted context omitted.
You agree with the author. >> No, the hard part of programming is understanding in very specific and rigid details how to accomplish a task. The real benefit of something like Project Bloks is that it actually removes the code; it allows children to begin thinking programmatically, without the obstacle of syntax. And this is a tough distinction to make, because people often use “programming” and “coding” synonymously…
Sure, we agree the code is not the important thing, but that's a very oblique point. Where I disagree is that "removing the code" will help someone gain better understanding. It might help them dip their feet in and get at the core of what's important (hence MIT using scheme for its intro CS class for 30 years). However as soon as someone passes the beginner phase, the difficult thing is expressing the ideas succinct…
There are many people who think that a visual language or some other abstraction will simplify the problem of coding. I really don't think so. While things like diagrams are great for helping people comprehend something, they are absolutely terrible for expressing something. Just look at how difficult it is to draw really good diagrams. Consider the fact that we have had cook books for hundreds of years, but almost none of them are described solely with diagrams. Words are how humans prefer to communicate.
I think we often fall into the same trap with programming languages or frameworks. We say, "Look how easy it is to do this trivial thing. It's 100 times easier to do trivial things with this framework than without it". We are completely blind to the fact that the framework makes it 100 times harder to do ordinary things and 1000 times harder to do complex things.