4 ms·

Even back in the 1980s everyone knew that "fifth-generation" programming languages will make programming obsolote. This article seems to take a bunch of press r

• waps 12y ago
  Teaching programming is like teaching constructivism in logic. It teaches rigour and produces working things, and a focus on algorithms, even if most people don't see what they're doing as having anything to do with algorithms. Very valuable that. There's the issue that some things are fundamentally out of reach of constructivist thought, but it certainly is an easy way to get pretty knowledgeable. In my opinion the easiest thing to automate are the higher up jobs in companies. A top executive essentially has to make 2 judgements. First, tell if someone's lying or wrong or otherwise doesn't know what (s)he's talking about without having any first-hand knowledge of the subject. Second, basic (and only very very basic) NPV calculations. The second problem is so extremely easy my 5 year old daughter is probably pretty close to being able to automate it. The first problem is the perfect computer science problem. The key is here : "without any first-hand knowledge of the subject". The decisions higher ups in companies make, they have to make without having real knowledge of what they're deciding. So there is no advantage is having knowledge about first-principles, simulation, ... they're generally not going to be beat by any engineer, because an engineer will want exact answers, and they don't exist. So their decision process HAS to be based on statistics, numerical analysis and nothing more. They will obviously disagree, but everyone does (I remember very strong discussions about robots not being able to make and/or combine "non-trivial" auto parts during my vacation jobs long ago). I did a startup, and we eventually hired an older CEO, mostly because he could get us more funding than we ever could. Now, the guy was everything I expected: zero knowledge about what the company was doing, and not interested in learning more about it (beyond polite interest I mean, he was very professional). Surprisingly, his sales knowledge also was tangential at best. Now I wanted to know what this guy knew that I didn't that made him successful ? But I just couldn't find anything where his knowledge didn't seem trivial at best (outside of physics, which he doctored in an eon ago, but I'm pretty sure he wasn't using 50-year-old high energy physics knowledge to lead the company). Eventually I found it. For a specific funding we had to get a "model" of the business going. And we worked on it together ... so I worked with the guy for a few weeks. What. The. Fuck. The guy built a model, in excel, that was just far beyond anything I even thought possible in excel. In fact, it was significantly beyond what I could get done in real programming languages, especially given the time available. He had all components of the business in there, and how they evolved. Employees, equipment, rent, lines of credit, ... and all sorts of things. Assuming we use the most efficient credit line to pay for things, employee onboarding means 2 months of half productivity, X new features per month, X sales calls per month, X% of them successfull, when we get a customer, X days to install, X days to first payment, X months the customer stays, then leaves, slowly ramping up to bigger and bigger customers, ... And what came out is what happened to the company's bank balance. My mind was blown in a pretty big way. Now it wasn't perfect. Far from it. He got the gist right though, and looking about a year later, he wasn't that horribly far off, close to 100k euro. And more importantly, it got investors on board. I didn't believe the model he made, to be honest, but I was wrong. But going to work on that data, using AI methods I could (after the fact) build a much better model predicting the business. Of course it isn't an excel file that could be passed to investors, but ... But here's what I eventually found out his job was : to go out, negotiate. Takes a bit of flair, but everyone can do it provided you do the next thing right : Take the terms on offer, translate them into this excel model of the business and see how they affect it. If they make the business succeed or just barely fail, accept them after a bit of haggling. If they don't, don't bother with the haggling, just politely and professionally tell the guys to get stuffed. Now of course, this can be automated. I believe this is much easier to automate than programming the company's products themselves, which requires domain knowledge no-one has when the company starts. It is generally a bloody hard problem for any new kind of product. And middle management, even of programmers, would be a lot easier to automate than even this. I think that's what's going to happen. Some people, probably financial companies first, since they're really only numbers, will put AI algorithms in charge of departments, which will include programmers. And then the owner will die, simply of natural causes, but the company just stays running. And 200 years later we will be wondering. Hell, I'm betting several such companies already exist, as it's certainly been possible for 10-20 years now to do this. Because one thing I'm very very sure of. No matter how good you think you can model stuff as a human, you will get your ass handed to you by relatively basic predictive algorithms. Of course, those algorithms, they don't know what they're talking about, beyond the numbers. But neither does management, so it can't be critical for the function.
  • carlosrt 12y ago
    RE: <The guy built a model, in excel> Do you have a template of that model?
• sriku 12y ago
  > They’ll just need good higher-level design thinking so they can clearly, logically explain the computer’s task. ... and how do you develop that skill? While the "search all existing code" approach may lead to improved security (for example) if such considerations are factored into the search, I'm unsure how this would permit us to do something a part of which has never been done before. The article probably does a disservice to the project by projecting it in the wrong direction which hides other very significant benefits it can bring to the table today. IMO, Wolfram Language deals with the human interface in a much better way than whatever (I think) searching through code can give you. WA generates multiple programs that are possible interpretations of a given query and runs them all, or a pruned set of them, depending on out-of-query context (at least as far as I understand it). This is possible only for those cases without side effects. If some imperative code for calculating prime numbers surreptitiously has an instruction to launch a rocket, how would a naive user know? In other words, such an intelligent system will need to distinguish between "doing something" and "an instruction to do something" - which is basically imperative languages versus monads. The vast majority of code is written imperatively and this kind of eager execution of multiple possible interpretations of an ambiguous instruction would be unsafe without that ... at least unsafe without the ability of the "programmer" to read the resultant code before accepting it.