2 ms·
What you describe is legalese. The precision of programming with the syntax of natural language. Programmers of legalese are ... special. Even fewer people get
by Swizec 6y ago
What you describe is legalese. The precision of programming with the syntax of natural language.
Programmers of legalese are ... special. Even fewer people get into that field than get into programming. Because expressing your thoughts and modeling reality precisely is the hard part. Not the syntax.
- hardwaresofton 6y agoBut the domains are drastically different. I assume you mean legalese as is used in Law -- modeling reality of law is hard, but modeling reality for computers is not hard, we've worked hard to make things very deterministic and demonstrably so. All we do is send instructions to computers all day that are mostly executed perfectly, changing the language you use to speak to the computers is the point of higher level languages, and I strongly consider english to be just another frontend (in the LLVM sense), just one that is a lot harder to encode the semantics of fully. But the thing is, you don't need to encode the semantics fully -- just make paths one at a time for certain functionality (ex. `read_file(path: string): string` can have it's first "call sentence" be "read file from <path on disk: var> and store the contents in <new const var>")
- Swizec 6y agoYes modeling computers is easy. But that’s useless. Most of my job is translating the PMs fuzzy brain and the company’s fuzzy business processes into precisely defined things computers can follow. That’s the hard part and very similar to the challenges legalese faces. How do you ensure a fuzzy “I want X” happens correctly in every case? Even something as simple as “90%” can be hard to define in the right context. Does “Read 90% of article” mean you read 90% of all words? Saw 90% of all sentences? Saw 90% of paragraphs in full, or is every paragraph at 90% also good? Etc