Cool experiment. Really shows how poorly conceived/verbose Auto Layout is. The first thing I do in any iOS project is add some sort of wrapper around all that constraint nonsense.
Of course: the app draws from a database of thousands of snippets that are cleaned up and generalized with some scripting. Natural language queries are handled like search, with semantic matching over both natural language and code structures. Content within the snippet like naming, "subject"/"target", and values are dynamic (use # to modify those values) – but it still needs work. As for auto layout, I actually have a feature for that on the roadmap but wasn't sure it was a common problem – bumping up its priority!
I'm very committed to the project and use it myself everyday, but I understand that point of view – it's a bit of a moonshot. Please let me know if you have any specific criticisms
And it seems like you created an account just to slag off somebody's work without providing any real constructive criticism; no, thanks.
Are you an iOS or macOS app developer? Then you'll see the benefit of being able to look things like this up, especially in view of how Apple has deprecated a lot of their developer documentation without providing adequate replacements.
Tools like this can seriously help ease the pain for a lot of developers who just want something that should be simple done but don't want to scour Stack Overflow looking at other peoples' terrible code examples from years back.
If you're not an iOS or macOS app developer, then perhaps you don't see the usefulness, but that would only lead to the conclusion that you're giving unhelpfully besmirching something that has little to nothing to do with you.
This will just converge to some kind of lisp and then pragmatically end up as XML and then be thrown away when it is realised it is a poor imitation html.
"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." - Greenspun's Tenth Rule
IMHO: There is a good chance that Lisp is pretty close to expressing "natural language" in code. I would argue that written text / prose is even a bad starting point. I'd rather think about having an UML Activity Diagram, add a way to add parameters / variables to it. Then visually imagine that you take away the full bubbles around the commands and just leave the sides. They look like brackets, right?
Now fiddle in a syntax for having parameters, maybe place them next to the text that describes what the program wants to achieve.
The next step is to define what the program or routine is actually doing, so think about step one again.
... Every time I think about a non-graphical way of writing a program as intuitive as possible I usually end up with some sort of Lisp.
I was thinking more along the lines of natural language snippet creation. I think one of the key problems here remains that you go from a ~30 word (+your own identifiers) vocabulary to a English language vocabulary where you're not sure how to express something.
The example says constrain x. I wouldn't have searched for constrain, but for saturation, min-max, limit, or something along those lines. I'm not sure this will work as well if you don't use the right vocab.
More evidence that iOS really just needs a declarative UI format. Storyboards/IB are trash and doing it programmatically is fine, but slow and error-prone.
I know how to use them just fine, thanks. Anything that cannot be viewed/compared in version control or tested easily is trash. You cannot easily collaborate on complex IB or storyboards.
In a tightly-scoped domain like "write code in Vue.js" it might be really cool. Looking forward to seeing how this evolves!
But just like self-driving cars, once you start expanding the scope, and only just a little bit, it doesn't look so cool anymore. I would love to see how far they can take this.
Programming in the purest sense is taking problems that real people have, expressed in their own words, and creating a logical symbolic construct that automates a sequence of interactions that pleases them. Human language is an extremely fuzzy and messy affair involving all sorts of things like body language that don't transfer to writing. Programming is not like that. These are not just different things. These are completely different domains of things.
I toyed with the idea that corporate business analysts (who write requirements for products then hand to developers) could just write in a different syntax and pass them to a compiler that makes:
1. database tables
1. API CRUD endpoints with validation / sanitation
1. screens with input fields
Most of the corporate work I did was very similar to this. It was either a batch job, a UI screen, or an API that talks to some other service.
But just like self-driving cars, once you start expanding the scope, and only just a little bit, it doesn't look so cool anymore. I would love to see how far they can take this.
It's beautiful the way you balance the pessimism of hard experience with an optimism borne of real natural language understanding being still an amazing possibility.
Human language is an extremely fuzzy and messy affair involving all sorts of things like body language that don't transfer to writing. Programming is not like that. These are not just different things. These are completely different domains of things.
That's rock such hopes founder on, sadly. Of course, there's always a chance someone will the passage between things that others have missed.
A more hopefully way to put is that natural language is a stream of symbols that where the unnecessary parts are removed, the other parts are actively interpreted by context and by the intent of the speaker, and where any ambiguity is sorted out by dialog. If you can create a system that can let you program similarly, you may have something.
Natural language is ambiguous. Grammars for computer languages are designed to remove ambiguity. A natural language that is used to program a computer, too, will have to remove ambiguity, thus only using a severely constricted subset of a natural language. Is it worth it beyond curiosity? If a person can't grok a computer language are they going to grok such a terse natural language?
Only a Subset of features of natural langage introduce ambiguities, equivocations, etc.
It is perfectly doable to force one and only one meaning per keyword (just like do programming keywords already (if, while, etc), removing the ability to use coreferences, etc
I would love to see a great constrained English, formal without the readability and expressivity loss of formal symbolic grammars / formal maths
People love to pick on the intensive meaning of "literally", perhaps because it is more recent, but it's really not much different from the range of uses of "really", which also can mean both 'in fact, truly' as well as an intensifier sense like 'very'. E.g. "I was really shocked", "I was literally shocked" have similar ambiguities. Competent human speaker generally provide enough context that potential ambiguities aren't too problematic -- for other human beings, if not for machines.
Human languages are more ambiguous than you might imagine, and lexical things like 'what meaning of "literally" is the speaker using' are pretty tip-of-the-iceberg stuff. (Think about what "Every man wants to read some book" or "the girl saw the man with the binoculars" (can) mean.)
That means that natural language is not intrinsically ambiguous and fuzzy, and removing the features that cause ambiguities would create a Constrained natural language, far more clearer.
Or is it the word Subset that you want me to explain?
Everyone once in a while a product manager will get familiar with the Django admin page of an app I'm working on and say something like "What? Why does it say Companys? Is there something wrong with the app?"
My response is always (some diplomatic, lay version of), "No, it's correctly refusing to involve us in the game of guessing how the framework developers modeled plurals."
It's not actually a "natural programming language", it's more of a snippet generator. The output is ordinary code and you still have to understand it.
I can see how this would be useful to quickly get the right incantation in certain verbose APIs, as opposed to copy-pasting code from API docs or Stackoverflow.
I don't believe there is a natural grammar that is unambiguous, instead I think in the realm of computer languages it's more a process of creating a jargon set that relates to terms but explicitly overrides them with unambiguous meanings within the domain.
For instance `new Object` - we're all going to read that as "create a new object that hasn't existed before" but within english a `new Object` could also be an antique you happen to have recently acquired, so `new` could be comprehended to be an acquisition action - like copying an Object - rather than creating a new one... But in our fancy computer language jargon we have forever banished the "new to me" meaning from `new`.
Nice landing page, it made it extremely clear what your product was and how I might use it.
I'm usually skeptical about programming language abstractions but from the demo it looks like this is more of a "helpful addition" then something you need to fully commit to which is interesting. I don't do a lot of Swift but will keep this in mind if I do. Best of luck!
If you want to understand why this is bad just look at AppleScript, probably the closest thing I've ever seen to natural language, the only problem is that it's impossible to just figure something out if there isn't a tutorial, because there's no real convention you can make guesses based on.
Ah, interesting! The difference between Metacode and something like AppleScript is that the artifact left over from using Metacode is still the rigorous programming language you're used to. If we retain a query log, you could even convert your natural language queries into code comments alongside your code to actually improve clarity.
You're going to get a lot of comments like these because when you say 'natural language' and 'programming' or 'code' in the same sentence people think coding directly in some 'natural'-like language. Also people often don't click on the actual links and many don't necessarily watch endlessly looping video clips when they do. A little bit of verbiage on the site might help that and head off the more obvious-but-inaccurate critiques. .
It's actually kind of cool to watch the animation, the tool maybe can help teach people how to code in a much faster time-lapse way. I personally don't know how to code in Swift but I think I learned a lot just watching the animation and the different snippets. Maybe you can livestream your Metacode app on Twitch for a learning channel.
And probably be easier to type than these snippet demos. Has there emerged a good declarative API for iOS? As a web developer, as much as I hate the insanity of the javascript tooling ecosystem it's hard to imagine going back to the spaghetti I see with swift/iOS apps.
It was a pretty complex language, and meant to use English syntax to mix both the fiction writing and the coding. So you can end up with code that looks like the following, for example
---
"Stage is a room.
The old lady is a woman in the Stage. Understand "mother" or "stepmother" as the old lady. The old lady is active. The description of the lady is "She looks plucked: thin neck with folds of skin exposed, nose beaky, lips white. Perhaps when her fortunes are mended her cosmetics too will improve.""
---
And it obviously gets more complex as you create things like objects with weights and inventory limits etc. My experience of it is that when it worked it was pretty magical, but when it didn't it was utterly maddening to figure out how to get it to parse.
Kinda felt like a voice help that barely works.
Best of luck with this, I like where it looks like it is going, but it simply has to be /really good/ to be value-added and not frustration-added
This tool is almost, but not quite, entirely unlike Inform, though. The 'programming' part is still done in a regular old language like Swift. The tool finds and/or generates snippets for you and plonks them into the Swift code you're actually writing.
yes, I see that, I should have been more clear that I knew it was a separate domain. This looks more like extended and interesting macros. My only point was that when you move towards being able to express things in natural language - whether as programming or even getting Siri to call your friend, the frustration level can be much higher if it doesn't work as expected.
There is something about getting to talk in "natural lanaguge" some of the time, and otherwise having to repeat yourself while trying variations in syntax that just feels bad.
Since I was talking about Inform, probably analogous is the text adventure issue where you know /how/ to solve the riddle, but you don't know how to tell the machine that you know.
"Give lantern to crocodile"
"Offer lantern to crocodile"
"Put lantern on crocodile"
etc
I think the difference remains that the things you are talking about have natural-language-ness as an inherent property with all its promise and baggage. Whereas the tool's mention of 'natural language' is almost incidental. You could rename it 'a command line for snippets' and still accurately describe it.
I’m someone who picks up new languages easy - regardless of their paradigm - and this is honestly the first time I’ve spent 10 minutes going through a languages documentation and still not been any wiser where to start. That is an extremely odd programming languages; fascinating too.
The docs are actually amazingly comprehensive, but it does have a pretty steep learning curve, especially as it is presented towards non-programmers, so you can't nec look up how to do a conditional very easily.
However, what really shines are the tremendously well documented full games. You can literally load them in Inform and play the game in one pane and walk through the code in the other.
I'm still not sure what to think of it as a language, I think now as a full-fledged programmer, I would pick an interactive fiction framework that looks a lot more like a programming language and less like fiction. However as a beautiful experiment in being able to use the English language to write a story and make it playable at the same time, it is still pretty amazing to me.
It /is/ a full-fledged language. You can implement weather or tides or magical systems or inventory systems or health points or anything else you can thing of, but it all reads pretty English-y...until it doesn't!
Using NL as a macro system for quickly inserting code, instead of as a way to hide actual code, seems like a good use-case. I wish the website was more informative about how much you can do with it, how far it goes to automatically generate snippets, and what kind of language support it's planned to have.
One way to look at Stackoverflow is that it's a gigantic index that maps "intuitive plain English" to "non-intuitive exact syntax".
A good exampe of bridging this mismatch is "git" commands. A lot of questions about Git are just translating natural English into the "secret decoder ring" lingo of Git.[0] E.g. "How do I undo a commit?" isn't something obvious like "git undo". Instead, it's the more cryptic "git reset HEAD~"[1]
A lot of the programming grind is like that. You know the English words for what you want to accomplish but don't know the exact programming syntax to make it happen. So this app is sort of like putting Stackoverflow lookups with copy&paste directly into the IDE.
In contrast, the existing "insert snippets" functionality in Visual Studio[1] or IntelliJ have abbreviations to help find templates of code but not quite the rich natural language of Stackoverflow. I wouldn't be surprised if future versions of those IDEs incorporate something like Metacode.
100% agree with this take. I mentioned it in another comment, but I've actually been working on a project which is essentially a better search engine for programming questions that's integrated in your IDE.
When possible, you try to pull out code snippets from SO/github/reference sites/etc that answer the query with high confidence. (Essentially like "instant answers" in google, but making it better by focusing on programming questions.)
The challenge is the level of noise and ambiguity that you get back in search results, and actually sorting through that to surface the right answers.
I agree that a lot of the unremovable difficulty in programming is translating natural English into something precise.
But I also think git often makes the problem worse by splitting similar operations unnaturally across different commands. I believe that was the motivation behind mercurial.
Ah okay. But still, hg vs git is a good example of doing the same things, but (the former) dividing the functionality along more natural boundaries. You still have the unavoidable complexity of defining precisely what you mean by "reverting" a change, but hg (from all I've heard) is more intuitive.
Except languages are ambiguous. When you say you want to undo a commit, do you mean undo like pretend nothing had happened or undo but please keep track of the change.
That's why the first thing I do when I'm learning something new is to read the documentation to find out what capabilities are available.
But those are two options of the same command. You can have a -keep-changes argument for undo and it wouldn't be weird or incompatible with the plain -language description.
> One way to look at Stackoverflow is that it's a gigantic index that maps "intuitive plain English" to "non-intuitive exact syntax".
It's not that syntax itself isn't intuitive; there's after all nothing more intuitive than, say, FORTH, LISP or Haskell syntax - surely it handily beats the weird idiosyncratics of "more English-like" FORTRAN or COBOL! It's actually the semantics of what you're interacting with, that, while simple, might be initially unintuitive to a naïve user. I don't think that I'm actually disagreeing with what you're saying; it's just that "not knowing the exact syntax for X" generally unpacks to something slightly different, namely "not knowing the relevant semantics to the extent that one can figure out how to do X". This, I think, is a better explanation of how StackOverflow might end up being quite helpful.
Of course, natural language itself does involve some semantics-related facets of its own, that might well end up being more intuitive than the programming-language semantics we normally use. But even then, we can (and should) use devices like Montague-semantics to give them an "intuitive", compositional syntax reminiscent of the lambda-calculus, Haskell or FORTH. I think this is the better way towards the goal of "using natural language to make programming more intuitive".
> "How do I undo a commit?" isn't something obvious like "git undo". Instead, it's the more cryptic "git reset HEAD~"[1]
The issue with this example is that `git reset HEAD~` doesn't undo anything, and it doesn't undo _any_ commit, just the last one. It will also cause push and merge conflicts if the commit you're "undoing" was public, which may end up with you not really having "undoing" anything at all.
It's also not anymore cryptic than any other industry's jargon. It's a sentence that means something specific. It's somewhat, but not entirely, what someone _could_ mean when they say "undo a commit".
>The issue with this example is that `git reset HEAD~` doesn't undo anything, and it doesn't undo _any_ commit, just the last one.
I shortened the question in my comment for brevity. The full question I cited on StackOverflow was worded as: "How do I undo the most recent local commits in Git?"
> It will also cause push and merge conflicts if the commit you're "undoing" was public,
Yes, and StackOverflow answers also warned of that scenario. Again, the full SO question did ask about "_local_ commits".
>It's also not anymore cryptic than any other industry's jargon.
In my comment, "cryptic" doesn't mean the syntax doesn't have its own internal logic that makes sense once one "groks it". It's just non-intuitive for someone who has a goal in their head but the only know plain English for describing that goal.
I know what the SO question said, but this hilights the problem with natural language: it isn't an unreasonable answer to "how do i undo a commit" and is infact a top result for that very search string in ddg and Google for me.
> Yes, and StackOverflow answers also warned of that scenario.
So the answer isn't git reset, but git reset + a whole lot more natural language, even for the more narrow question asked.
> In my comment, "cryptic" doesn't mean the syntax doesn't have its own internal logic that makes sense once one "groks it". It's just non-intuitive for someone who has a goal in their head but the only know plain English for describing that goal.
Isn't the true of anything? Everything has their own jargon to express precisely what they mean. Would you tell machinist they're being cryptic if they told you to make a bolt-hole pattern? Is an accountant cryptic if they talk about something being a liability and not an asset? A ham if they ask for fsk31 and to call them on 6m? Complex things require precise language to talk about precisely. That isn't being cryptic, it's a feature of natural language that it becomes more ridgid and precise with a specialized vocabulary when things require it.
>So the answer isn't git reset, but git reset + a whole lot more natural language, even for the more narrow question asked.
Yes, and like you confirmed, all of that was in the SO answers. I'm not exactly sure what you're debating here. I deliberately put an abbreviated SO question (some words elided) in my parent comment. I also put an abbreviated answer (some words elided). I cited the full SO answers that explained all the caveats, qualifications, in a footnote. Are you complaining that I didn't copy & paste the entire ~5000 words of StackOverflow answers into my comment instead of just typing "git reset"?
>Isn't the true of anything?
Yes! And that truism is why StackOverflow is so useful.
I think the root issue is that you think I'm making a claim I didn't actually make. I never claimed that natural language English is good enough for precise programming or that it didn't have ambiguities. I also think you misunderstood my blurb about git as if I was making an all-encompassing definitive answer for "git undo" instead of using it as a lead-in to a larger point about the tool discussed in this thread.
To hopefully convince you I know what you're talking about, we can also say that non-English programming languages themselves are also fuzzy and imprecise when trying to translate to another programming language. There's always a hidden underlying semantic layer that's not visible in the surface-level text of the code. E.g. converting Javascript to C++.
Javascript: var x = y + z;
But numbers in Javascript are always 64bit doubles. But we don't know if the programmer truly used them as doubles or whether all the runtime values were actually 32bit integers. That hidden semantic layer requires more analysis.
Therefore we don't know if the correct translation to C/C++ is:
int x = y + z;
... or ...
double x = y + z;
So even trying to perfectly translate non-English programminglanguage_A to non-English programminglanguage_B runs into The Halting Problem.
Here's the key, even though programming language conversion is imperfect, the programmers still have a real-world need to translate them and that's why Google and StackOverflow are useful for attempting to convert Javascript to C++.[1] Again to emphasize: Not perfect, but useful.
You seem to be working bottom-up from some Platonic ideal of perfect precision. My parent comment was working backward from the existence of thousands of real-world questions on StackOverflow that translates natural (sometimes fuzzy) English to non-obvious answers about syntax. It's about why do those Git questions exist and why were they useful. The tool that this thread is about takes advantage of that phenomenon.
Not yet, right now I just have a tutorial window that shows up the first time you use the code builder feature, and the videos on the home page. Open to suggestions!
I gave it a try; love how fast and simple it is! You probably already know this, but the set of snippets are somewhat limited at the moment (though pretty good for a first launch). Also, it would probably be helpful to have more descriptions/metadata around each snippet, so that you can use some NLP goodness to make search better.
I've been working on a related idea, which is sort of a search engine for programming questions integrated into your IDE (starting with JS in VSCode). The idea is to give you fast, relevant answers (code snippets when possible), and reduce context switching to the browser to keep you in flow.
Similar in spirit though; would love to chat more! (my contact info in profile; I didn't see a way to contact you)
nexto stringum reperimentum da. # $next = pos $
nextum stringo reperimento da. # pos $string = $next;
inserto stringum tum unum tum duo excerpementum da. # $insert = substr($string,1,2);
insertum stringo unum tum duo excerpemento da. # substr($string,1,2) = $insert;
keyis hashus nominamentum da # @keys = keys %hash;
keya hashibus nominamento da # keys %hash = @keys;
117 comments
[ 3.1 ms ] story [ 146 ms ] threadMakes life easy.
Are you an iOS or macOS app developer? Then you'll see the benefit of being able to look things like this up, especially in view of how Apple has deprecated a lot of their developer documentation without providing adequate replacements.
Tools like this can seriously help ease the pain for a lot of developers who just want something that should be simple done but don't want to scour Stack Overflow looking at other peoples' terrible code examples from years back.
If you're not an iOS or macOS app developer, then perhaps you don't see the usefulness, but that would only lead to the conclusion that you're giving unhelpfully besmirching something that has little to nothing to do with you.
Now fiddle in a syntax for having parameters, maybe place them next to the text that describes what the program wants to achieve.
The next step is to define what the program or routine is actually doing, so think about step one again.
... Every time I think about a non-graphical way of writing a program as intuitive as possible I usually end up with some sort of Lisp.
EDIT: several edits for wording
Spoken programming languages is a different can of worms.
My main problem when programming against mac/iOS APIs is constantly looking up how to do the little things shown in the demo video.
I don't look forward to writing macOS/iOS apps but this makes me think differently.
The example says constrain x. I wouldn't have searched for constrain, but for saturation, min-max, limit, or something along those lines. I'm not sure this will work as well if you don't use the right vocab.
But just like self-driving cars, once you start expanding the scope, and only just a little bit, it doesn't look so cool anymore. I would love to see how far they can take this.
Programming in the purest sense is taking problems that real people have, expressed in their own words, and creating a logical symbolic construct that automates a sequence of interactions that pleases them. Human language is an extremely fuzzy and messy affair involving all sorts of things like body language that don't transfer to writing. Programming is not like that. These are not just different things. These are completely different domains of things.
Neat. Best of luck, guys!
1. database tables
1. API CRUD endpoints with validation / sanitation
1. screens with input fields
Most of the corporate work I did was very similar to this. It was either a batch job, a UI screen, or an API that talks to some other service.
It's beautiful the way you balance the pessimism of hard experience with an optimism borne of real natural language understanding being still an amazing possibility.
Human language is an extremely fuzzy and messy affair involving all sorts of things like body language that don't transfer to writing. Programming is not like that. These are not just different things. These are completely different domains of things.
That's rock such hopes founder on, sadly. Of course, there's always a chance someone will the passage between things that others have missed.
A more hopefully way to put is that natural language is a stream of symbols that where the unnecessary parts are removed, the other parts are actively interpreted by context and by the intent of the speaker, and where any ambiguity is sorted out by dialog. If you can create a system that can let you program similarly, you may have something.
Good Luck again!
I wish! People won't even use "literally" consistently, despite it existing to prevent you having to guess which sense a speaker means.
Edit: Toned down.
Human languages are more ambiguous than you might imagine, and lexical things like 'what meaning of "literally" is the speaker using' are pretty tip-of-the-iceberg stuff. (Think about what "Every man wants to read some book" or "the girl saw the man with the binoculars" (can) mean.)
https://en.wikipedia.org/wiki/Lojban
"Cookies set? Oh, that must be the plural of Cooky" -> actually happened in live coding demonstration before.
My response is always (some diplomatic, lay version of), "No, it's correctly refusing to involve us in the game of guessing how the framework developers modeled plurals."
Alternatively, as you said, use a non-ambiguous subset. But then it's no longer a natural language, I wouldn't mind betting they're all ambiguous.
I can see how this would be useful to quickly get the right incantation in certain verbose APIs, as opposed to copy-pasting code from API docs or Stackoverflow.
For instance `new Object` - we're all going to read that as "create a new object that hasn't existed before" but within english a `new Object` could also be an antique you happen to have recently acquired, so `new` could be comprehended to be an acquisition action - like copying an Object - rather than creating a new one... But in our fancy computer language jargon we have forever banished the "new to me" meaning from `new`.
I'm usually skeptical about programming language abstractions but from the demo it looks like this is more of a "helpful addition" then something you need to fully commit to which is interesting. I don't do a lot of Swift but will keep this in mind if I do. Best of luck!
In the code builder demo, it strikes me that all that code in swift could be replaced with a declarative format:
And probably be easier to type than these snippet demos. Has there emerged a good declarative API for iOS? As a web developer, as much as I hate the insanity of the javascript tooling ecosystem it's hard to imagine going back to the spaghetti I see with swift/iOS apps.http://inform7.com/
It was a pretty complex language, and meant to use English syntax to mix both the fiction writing and the coding. So you can end up with code that looks like the following, for example
---
"Stage is a room.
The old lady is a woman in the Stage. Understand "mother" or "stepmother" as the old lady. The old lady is active. The description of the lady is "She looks plucked: thin neck with folds of skin exposed, nose beaky, lips white. Perhaps when her fortunes are mended her cosmetics too will improve.""
---
And it obviously gets more complex as you create things like objects with weights and inventory limits etc. My experience of it is that when it worked it was pretty magical, but when it didn't it was utterly maddening to figure out how to get it to parse.
Kinda felt like a voice help that barely works.
Best of luck with this, I like where it looks like it is going, but it simply has to be /really good/ to be value-added and not frustration-added
There is something about getting to talk in "natural lanaguge" some of the time, and otherwise having to repeat yourself while trying variations in syntax that just feels bad.
Since I was talking about Inform, probably analogous is the text adventure issue where you know /how/ to solve the riddle, but you don't know how to tell the machine that you know.
"Give lantern to crocodile" "Offer lantern to crocodile" "Put lantern on crocodile" etc
Kudos for actually being able to use it.
However, what really shines are the tremendously well documented full games. You can literally load them in Inform and play the game in one pane and walk through the code in the other.
I'm still not sure what to think of it as a language, I think now as a full-fledged programmer, I would pick an interactive fiction framework that looks a lot more like a programming language and less like fiction. However as a beautiful experiment in being able to use the English language to write a story and make it playable at the same time, it is still pretty amazing to me.
It /is/ a full-fledged language. You can implement weather or tides or magical systems or inventory systems or health points or anything else you can thing of, but it all reads pretty English-y...until it doesn't!
A good exampe of bridging this mismatch is "git" commands. A lot of questions about Git are just translating natural English into the "secret decoder ring" lingo of Git.[0] E.g. "How do I undo a commit?" isn't something obvious like "git undo". Instead, it's the more cryptic "git reset HEAD~"[1]
A lot of the programming grind is like that. You know the English words for what you want to accomplish but don't know the exact programming syntax to make it happen. So this app is sort of like putting Stackoverflow lookups with copy&paste directly into the IDE.
In contrast, the existing "insert snippets" functionality in Visual Studio[1] or IntelliJ have abbreviations to help find templates of code but not quite the rich natural language of Stackoverflow. I wouldn't be surprised if future versions of those IDEs incorporate something like Metacode.
[0] so many "How to...?" in the most-upvoted questions tagged [git] : https://stackoverflow.com/questions/tagged/git?sort=votes&pa...
[1] https://stackoverflow.com/questions/927358/how-do-i-undo-the...
[2] https://docs.microsoft.com/en-us/visualstudio/ide/code-snipp...
When possible, you try to pull out code snippets from SO/github/reference sites/etc that answer the query with high confidence. (Essentially like "instant answers" in google, but making it better by focusing on programming questions.)
The challenge is the level of noise and ambiguity that you get back in search results, and actually sorting through that to surface the right answers.
But I also think git often makes the problem worse by splitting similar operations unnaturally across different commands. I believe that was the motivation behind mercurial.
That's why the first thing I do when I'm learning something new is to read the documentation to find out what capabilities are available.
When I start using anything new I really only check that it can do what I need it to, not everything that’s possible.
It's not that syntax itself isn't intuitive; there's after all nothing more intuitive than, say, FORTH, LISP or Haskell syntax - surely it handily beats the weird idiosyncratics of "more English-like" FORTRAN or COBOL! It's actually the semantics of what you're interacting with, that, while simple, might be initially unintuitive to a naïve user. I don't think that I'm actually disagreeing with what you're saying; it's just that "not knowing the exact syntax for X" generally unpacks to something slightly different, namely "not knowing the relevant semantics to the extent that one can figure out how to do X". This, I think, is a better explanation of how StackOverflow might end up being quite helpful.
Of course, natural language itself does involve some semantics-related facets of its own, that might well end up being more intuitive than the programming-language semantics we normally use. But even then, we can (and should) use devices like Montague-semantics to give them an "intuitive", compositional syntax reminiscent of the lambda-calculus, Haskell or FORTH. I think this is the better way towards the goal of "using natural language to make programming more intuitive".
The issue with this example is that `git reset HEAD~` doesn't undo anything, and it doesn't undo _any_ commit, just the last one. It will also cause push and merge conflicts if the commit you're "undoing" was public, which may end up with you not really having "undoing" anything at all.
It's also not anymore cryptic than any other industry's jargon. It's a sentence that means something specific. It's somewhat, but not entirely, what someone _could_ mean when they say "undo a commit".
I shortened the question in my comment for brevity. The full question I cited on StackOverflow was worded as: "How do I undo the most recent local commits in Git?"
> It will also cause push and merge conflicts if the commit you're "undoing" was public,
Yes, and StackOverflow answers also warned of that scenario. Again, the full SO question did ask about "_local_ commits".
>It's also not anymore cryptic than any other industry's jargon.
In my comment, "cryptic" doesn't mean the syntax doesn't have its own internal logic that makes sense once one "groks it". It's just non-intuitive for someone who has a goal in their head but the only know plain English for describing that goal.
> Yes, and StackOverflow answers also warned of that scenario.
So the answer isn't git reset, but git reset + a whole lot more natural language, even for the more narrow question asked.
> In my comment, "cryptic" doesn't mean the syntax doesn't have its own internal logic that makes sense once one "groks it". It's just non-intuitive for someone who has a goal in their head but the only know plain English for describing that goal.
Isn't the true of anything? Everything has their own jargon to express precisely what they mean. Would you tell machinist they're being cryptic if they told you to make a bolt-hole pattern? Is an accountant cryptic if they talk about something being a liability and not an asset? A ham if they ask for fsk31 and to call them on 6m? Complex things require precise language to talk about precisely. That isn't being cryptic, it's a feature of natural language that it becomes more ridgid and precise with a specialized vocabulary when things require it.
Yes, and like you confirmed, all of that was in the SO answers. I'm not exactly sure what you're debating here. I deliberately put an abbreviated SO question (some words elided) in my parent comment. I also put an abbreviated answer (some words elided). I cited the full SO answers that explained all the caveats, qualifications, in a footnote. Are you complaining that I didn't copy & paste the entire ~5000 words of StackOverflow answers into my comment instead of just typing "git reset"?
>Isn't the true of anything?
Yes! And that truism is why StackOverflow is so useful.
I think the root issue is that you think I'm making a claim I didn't actually make. I never claimed that natural language English is good enough for precise programming or that it didn't have ambiguities. I also think you misunderstood my blurb about git as if I was making an all-encompassing definitive answer for "git undo" instead of using it as a lead-in to a larger point about the tool discussed in this thread.
To hopefully convince you I know what you're talking about, we can also say that non-English programming languages themselves are also fuzzy and imprecise when trying to translate to another programming language. There's always a hidden underlying semantic layer that's not visible in the surface-level text of the code. E.g. converting Javascript to C++.
But numbers in Javascript are always 64bit doubles. But we don't know if the programmer truly used them as doubles or whether all the runtime values were actually 32bit integers. That hidden semantic layer requires more analysis.Therefore we don't know if the correct translation to C/C++ is:
... or ... So even trying to perfectly translate non-English programminglanguage_A to non-English programminglanguage_B runs into The Halting Problem.Here's the key, even though programming language conversion is imperfect, the programmers still have a real-world need to translate them and that's why Google and StackOverflow are useful for attempting to convert Javascript to C++.[1] Again to emphasize: Not perfect, but useful.
You seem to be working bottom-up from some Platonic ideal of perfect precision. My parent comment was working backward from the existence of thousands of real-world questions on StackOverflow that translates natural (sometimes fuzzy) English to non-obvious answers about syntax. It's about why do those Git questions exist and why were they useful. The tool that this thread is about takes advantage of that phenomenon.
[1] https://www.google.com/search?q=C%2B%2B+for+javascript+progr...
Do you have any ideas for how to document the tool well?
Thank you for the smile this brought to my face :). Really imaginative and cool tool.
I've been working on a related idea, which is sort of a search engine for programming questions integrated into your IDE (starting with JS in VSCode). The idea is to give you fast, relevant answers (code snippets when possible), and reduce context switching to the browser to keep you in flow.
Similar in spirit though; would love to chat more! (my contact info in profile; I didn't see a way to contact you)
For an older implementation of programming using a natural language, there's Lingua::Romana::Perligata http://users.monash.edu/~damian/papers/HTML/Perligata.html
Unfortunately for probably most people here, the natural language in question is Latin.