5 ms·
We already have this--contracts are "programs" that specify how other people should perform some action. Nevertheless, entire industries revolve around correct
by mattkrause 10y ago
We already have this--contracts are "programs" that specify how other people should perform some action.
Nevertheless, entire industries revolve around correctly writing contracts, making sure they are executed in the intended way, and resolving ambiguities and disputes about the original specification.
If it's ever possible to go directly from English to running code, programmers will still be around; they'll just sound more like lawyers.
- booleandilemma 10y agoAgreed. You're always going to have people that manage the details and edge cases of complex software systems. Those people will be programmers. And if there is ever an AI invented that can replace those people then many white collar workers are at risk of losing their jobs, not just programmers.
- petra 10y agoAnd yet there's a lot of effort in automating lawyers, so maybe the future will be setting more higher level .
- visarga 10y agoHigher order lawyers - where you can do with one HOL in a day what took a month with regular lawyers (just like Python vs Assembler).
- TheOtherHobbes 10y agoContracts are not "programs", any more than programs are binding legal agreements between users. Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation. In non-trivial corporate contract law they're paid to find favourable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements. They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view. Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.
- mattkrause 10y agoYou're making my point for me. Natural language is rife with ambiguities, contextual information, and implicit assumptions. It is a terrible method for precisely conveying instructions or expectations, even to equally intelligent peers. Making this work at all requires a whole specialised profession with its own elaborate procedures and complicated argot. If you wandered into an IBM office and said, "I need a document storage system. Here's a blank check; make it happen!", do you think you would be happy with the outcome? Probably not. What changes when you tell this to a chatbot instead of a guy in a suit? Instead, you'd work with someone lawyer/programmer who knows how to spec out the solution in enough detail that the vendor/optimizer can't go "well, you said STORE the documents, but you never said anything about RETRIEVING them later!"
- gridspy 10y ago> Contracts are not "programs", any more than programs are binding legal agreements between users. The conversation at hand is not about "programs" in the traditional sense, but more a conversation between a human and an AI which is providing what is asked for. This is very similar to asking a Genie to satisfy your wishes. You need to be clear and precise or it is likely you'll get exactly what you asked for, but not what you intended. We're NOT talking about traditional programming here. > Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation. Sure, but it appears that a Lawyer's domain involves the interaction between intent, specifications and reality. In all the points you raise, this is what the lawyer is doing. > In non-trivial corporate contract law they're paid to find favorable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements. This is exactly what a programmer is doing almost all the time (when not talking to clients). Finding the edge cases, creating rules. Avoiding or documenting them. Closing the loopholes, turning them into features or guiding the user away from them. > They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view. Okay, so lawyers are sales-people too. Do you really think that programmers are not already salespeople, or have people on their team that are? > Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains. Bear in mind that a programmer RIGHT NOW is managing the issues that you are discussing, as the computer is only half their domain. The other half is interactions with teammates, clients, etc. They already have to manage "human relationships, transactions and goals."
- return0 10y agoBut everyone can use language to clarify things, not just lawyers. A proper AI system would fill in the missing info with the optimal defaults, and ask for clarification for the rest. Every new edge case added makes the system smarter
- marvin 10y agoThis is exactly what a skilled developer does. In principle you could probably design a system that does it automatically. Sounds like strong AI territory though.
- mattkrause 10y agoOf course! I'm not saying that only people with 180s on the LSAT will be able to program. Instead, I'm arguing that writing an air-tight specification of your goals can be tricky, time-consuming and requires a certain mind-set, even if we assume perfect natural language understanding and ignore all the implementation details by saying that wizards...err...deep neural networks solve those issues. As support for this argument, writing contracts is still tricky, despite everyone involved having perfect language understanding and the sort of generalized intelligence that computers lack. Therefore, if there ever is an English-to-bytecode compiler, I expect that the "programs" written for it will look much more like a contract with lots of awkward but precise language and much less like "Yo Siri, build me a chatbot." You can call the person who spends all day drafting these things and interacting with the code-generating software something other than a programmer if you want, but if the shoe fits.... I'm also not convinced that optimal defaults exist for many things. You could certainly recommend a data structure based on the way it is accessed (if it's always being queried for the min, throw it in a heap, but use an array or hash table for random access), but how do you gradient-descent your way to a fun original video game without also assuming a decent model of human psychology? At some point, you have to specify that "when the player does X, Y happens", which is programming.