3 ms·
While this project is very young and is narrow in scope, I'm really excited by the somewhat parallel idea of building a good enough rosetta stone for practical
by hardwaresofton 6y ago
While this project is very young and is narrow in scope, I'm really excited by the somewhat parallel idea of building a good enough rosetta stone for practical computing such that one could power a programming platform with human language syntax. Imperative programming and natural writing have an overlap I think is under-appreciated -- the amount of people that could grok computer programming if programs became essays, functions became paragraphs and such is large I reckon.
Has anyone seen anything like this before? This submission seems like it could be a first step, but it's not the authors' goal.
Somewhat more on-topic, learnxinyminutes[0] is fantastic for jogging my memory on languages I use rarely.
[EDIT] - Oh also, I think that this kind of project could have some enterprise viability -- having private instances sharable by tech teams could make it much easier to on-board and share code snippets/best practices with team-members and keep tech-debt knowledge fresh.
[0]: https://learnxinyminutes.com https://learnxinyminutes.com
- Swizec 6y agoWhat 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
- alex_portabella 6y agolearnxinyminutes looks cool! I didn't know about it before starting this. I agree with the enterprise knowledge sharing! Every company has many snippets and commands they always use
- friendlybus 6y agoWasn't it the idea behind visual basic? If I recall correctly the devs aimed at making a more natural programming language. I don't think it'll ever work, there's the obligatory xkcd comic about the limits of sophisticated programming languages. The code will never free you from the burden of having to specific exactly what you want. Maybe an ML/AI parser for natural language would be a possible improvement and then tweak the details after the parsing. Likely just make things more complicated though.
- hardwaresofton 6y ago> I don't think it'll ever work, there's the obligatory xkcd comic about the limits of sophisticated programming languages. The code will never free you from the burden of having to specific exactly what you want. In my mind it's less about freeing the user from specificity, but just changing the language under which that specificity happen. Honestly it's just syntax! Imagine something like: > open file on disk at "/some/path/to/a/file" into $my_file_handle. read contents of file handle $my_file_handle into new variable $contents. print $contents to standard output. Imagine every sentence just being a textual template for a function invocation, with context in-between functions (state) being preserved and managed implicitly with the use of variable names & prose. signatures for the functions required would be something like: - open_file (path: string): file_handle - read_bytes(fh: file_handle): string - print(s: string): void We already have functions like this and compose them in ways that the text suggests -- it's more about just adding a different way to group and recall up the composed functionality.