• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

Natural Language Programming

Natural Language Programming: Good Idea?

  • Yes

  • Maybe

  • No


Results are only viewable after voting.
Status
Not open for further replies.

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
Having programmed for many years in many languages, I often find myself thinking in a kind of natural language pseudo-code, then translating it into whatever I'm working with at that time. So one day I thought, Why not simply code at a natural language level and skip the translation step? I talked it over with my elder son, also a programmer, and we decided to test the theory. Specificially, we wanted to know:

1. Is it easier to program when you don’t have to translate your natural-language thoughts into an alternate syntax?

2. Can natural languages be parsed in a relatively “sloppy” manner (as humans apparently parse them) and still provide a stable enough environment for productive programming?

3. Can low-level programs (like compilers) be conveniently and efficiently written in high level languages (like English)?

And so we set about developing a "plain english" compiler in the interest of answering those questions. And we are happy to report that we can now answer each of those three questions, from direct experience, with a resounding “Yes!” Here are some details:

Our parser operates, we think, something like the parsing centers in the human brain. Consider, for example, a father saying to his baby son:

“Want to suck on this bottle, little guy?”

And the kid hears,

“blah, blah, SUCK, blah, blah, BOTTLE, blah, blah.”

But he properly responds because he’s got a “picture” of a bottle in the right side of his head connected to the word “bottle” on the left side, and a pre-existing “skill” near the back of his neck connected to the term “suck”. In other words, the kid matches what he can with the pictures (types) and skills (routines) he’s accumulated, and simply disregards the rest. Our compiler does very much the same thing, with new pictures (types) and skills (routines) being defined -- not by us, but -- by the programmer, as he writes new application code.

A typical type definition looks like this:

A polygon is a thing with some vertices.

Internally, the name “polygon” is now associated with a type of dynamically-allocated structure that contains a doubly-linked list of vertices. “Vertex” is defined elsewhere (before or after this definition) in a similar fashion; the plural is automatically understood.

A typical routine looks like this:

To append an x coord and a y coord to a polygon:
Create a vertex given the x and the y.
Append the vertex to the polygon’s vertices.


Note that formal names (proper nouns) are not required for parameters and variables. This, we believe, is a major insight. My real-world chair and table are never (in normal conversation) called “c” or “myTable” -- I refer to them simply as “the chair” and “the table”. Likewise here: “the vertex” and “the polygon” are the natural names for such things.

Note also that spaces are allowed in routine and variable “names” (like “x coord”). This is the 21st century, yes? And that “nicknames” are also allowed (such as “x” for “x coord”). And that possessives (“polygon’s vertices”) are used in a very natural way to reference “fields” within “records”.

Note, as well, that the word “given” could have been “using” or “with” or any other equivalent since our sloppy parsing focuses on the pictures (types) and skills (routines) needed for understanding, and ignores, as much as possible, the rest.

At the lowest level, things look like this:

To add a number to another number:
Intel $8B85080000008B008B9D0C0000000103.


Note that in this case we have both the highest and lowest of languages -- English and machine code (in hexadecimal) -- in a single routine. The insight here is that (like a typical math book) a program should be written primarily in a natural language, with appropriate snippets in more convenient syntaxes as (and only as) required.

We hope someday soon to extend the technology to include Plain Spanish, and Plain French, and Plain German, etc.

Anyway, if you're interested, you can download the whole thing here: url redacted. It’s a small Windows program, less than a megabyte in size. No installation necessary; just unzip and execute. But it's a complete development environment, including a unique interface, a simplified file manager, an elegant text editor, a handy hexadecimal dumper, a native-code-generating compiler/linker, and even a wysiwyg page layout facility (that we used to produce the documentation). If you start with the "instructions.pdf" in the “documentation” directory, before you go ten pages you won't just be writing "Hello, World!" to the screen: you’ll be re-compiling the whole shebang in itself (in less than three seconds on a bottom-of-the-line machine from Walmart).

Take a look. Then let us know what you think here on the forum.

Thanks,

Gerry Rzeppa
Grand Negus of the Osmosian Order of Plain English Programmers

Dan Rzeppa
Prime Assembler of the Osmosian Order of Plain English Programmers

Sorry, I can't allow a link to a .zip in this context. Interesting first post, but if you want to give people access to the project then either post a link to a page of your own where they can read about the contents of the file and download it, or upload the source to github or bitbucket and promote it from there.

Markbnj
Programming mod
 
Last edited by a moderator:

Apathetic

Platinum Member
Dec 23, 2002
2,587
6
81
One of the biggest problems you have with spoken language is ambiguity. Compilers tend to hate that. Everything needs to be defined and all ambiguous statements need to be resolved before a compiler can generate proper code. How many times have you ever talked with someone who went and did something other than what you asked for?

Dave
 

Crusty

Lifer
Sep 30, 2001
12,687
2
0
Right, like I'm going to download a random Windows binary from some dude with 1 post.
 

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,688
12
81
www.markbetz.net
OP, the problem with your approach to getting this discussion started is that you basically described a bunch of advanced capabilities and posted a link to a .zip file. If you really want discussion and feedback, then do two things: first, don't tell us your compiler will correctly infer types, recognize plurals and word variations in different contexts, and figure out intent from natural language; tell us how it does those things. Second, don't post binary files, post the source code to a site like github and let people examine it for themselves to assess how credible the claims are.

That's my two cents, anyway.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
One of the biggest problems you have with spoken language is ambiguity. Compilers tend to hate that. Everything needs to be defined and all ambiguous statements need to be resolved before a compiler can generate proper code.
At least that's the popular "urban myth" on the subject. And one of the reasons we attempted the thing: we wanted to know if that popular belief was really true. What we found, was that it wasn't. You really can program in English, with a relatively "sloppy" parser, and still get what you want -- simply, reliably, and predictably.

How many times have you ever talked with someone who went and did something other than what you asked for?
Often. But more often with people I don't know well. My wife, for example, rarely misunderstands me. And so it's the same with a natural-language compiler: the better you get to know one another, the less frequently you misunderstand one another. In any case, we don't see this as an altogether bad thing: if we want the computers of the future to relate to us as humans relate to one another now, we have to allow for unexpected interpretations -- because that's part of what makes human interactions interesting. Sometimes comic; sometimes instructive; sometimes leading to an entirely different (and better) line of thought.

In any case, the problem isn't as bad as most people believe. Our program is not a trivial thing: desktop, file manager, editor, dumper, compiler/linker, and page-layout facility. All coded in Plain English. If English is so ambiguous, how did we manage to make all that work?
 
Last edited:

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
OP, the problem with your approach to getting this discussion started is that you basically described a bunch of advanced capabilities and posted a link to a .zip file. If you really want discussion and feedback, then do two things: first, don't tell us your compiler will correctly infer types, recognize plurals and word variations in different contexts, and figure out intent from natural language; tell us how it does those things.
It's easier to discuss the thing with someone who's actually seen and used it. The answers to your questions (and many more) are in the documentation (a pdf) and the source code (plain text files) that come with the download. It seems like a lot of work to attempt to repeat all of that in this tiny little non-wysiwyg message editor window. (By the way, what's with the "edit here, preview there" paradigm on all these forums? Doesn't anyone know how to code a wysiwyg editor anymore?)

Second, don't post binary files, post the source code to a site like github and let people examine it for themselves to assess how credible the claims are.
Again, it's easier to understand the source code once you've (a) seen the thing actually run, and (b) followed the tutorial in the instruction manual. I suggest you download the zip file, check it with a reliable virus checker (like Microsoft Security Essentials or McAfee) if you're worried, then start with the instructions.pdf as originally described. It's really the quickest way for both of us.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
OP, the problem with your approach...
I see you've removed the link in my post. We do have a website (www.osmosian.com) but it invites people to write us directly to receive the link -- we've been doing it that way (since 2006) because we find it generates a lot less "noise" than a direct link or a forum. Nevertheless, we thought we'd offer a direct link here in the interest of engendering some lively discussion, here, on the subject.

Perhaps you could download the thing yourself, check it for viruses with a reliable checker (like Microsoft's or McAfee's), and then replace my link in the post with a note that it's safe? That, I think, would not only reassure the fearful, but would keep the discussion here where it belongs.
 
Last edited by a moderator:

DaveSimmons

Elite Member
Aug 12, 2001
40,736
669
126
An AV checker can't tell that an EXE is safe, only whether it has been altered by a virus/trojan.

Your EXE could be written to do keylogging, read and transmit data files, make or read registry entries, set processes or services to run at startup, etc. without it being infected.
 

Cogman

Lifer
Sep 19, 2000
10,267
103
106
It is an interesting thing to attempt, but I believe it is doomed to failure.

First, there is the fact that natural languages just don't lend themselves well to programming. Take this statement for example:

He gave her cat food.

Now, did he feed her cat food or did he give her some cat food?

It is ambiguous and really depends a lot on inflection or context.

Then there is the more practical problem. I've seen WAY too many bug reports from users of software that think they are giving plenty of information to solve the issue, they don't. It usually requires a large effort to ferret out all requirements to finally build a working program.

And then there is the problem with formatting. There is a reason why indentation has become king when programming, it makes reading, reasoning, and writing a program much easier to handle. A natural language programming language would either end up being undebuggable because everything becomes paragraphs or horribly cludgy because you would end up writing programs that look like a whole bunch of wordy statements in sentences.

And then there is the question of brevity. Which would you prefer

Code:
if (person.isAlive())
   person.die()
   world.reset()
   cleanup()
vs
Code:
if the person is alive, tell the person to die and reset the world and cleanup
The first has many small easily chunckable statements which can be broken up. The second is a hauppauge of actions.

Even if you try to format it
Code:
if the person is alive,
   tell the person to die 
   and reset the world 
   and cleanup.
You end up with something that looks like cat scratches. And lets not forget logical statements. You could do the above, but what if you wanted to check two things vs execute functions? It become a nightmare fast.
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
15,382
2,415
55
Interesting premise, worrying presentation. The premise reminds me of some things I worked with and on a couple of years back. The first thing that came to mind is Cucumber, a natural-language-based unit testing system for Ruby:
[Step] 1: Describe behaviour in plain text
But then see Step 2:
[Step] 2: Write a step definition in Ruby
I can't imagine developing something like this without some base keywords. In your example, "suck" and "bottle" are the baby's base keywords. I see a few of them in your compiler:
Code:
to add a number to another number:
  intel $8B8508000000. \ mov eax,[ebp+8] \ the number
  intel $8B00. \ mov eax,[eax]
  intel $8B9D0C000000. \ mov ebx,[ebp+12] \ the other number
  intel $0103. \ add [ebx],eax
x86 assembly?
Code:
to adjust spacing given a string:
  if the current canvas is not the printer canvas, exit.
  call "gdi32.dll" "SetTextCharacterExtra" with the printer canvas and 0.
Windows DLL calls? But surely the compiler couldn't compile itself initially. How did you initially compile the compiler?

It looks like the "noodle" defines most of the other keywords-phrases. Is that right? If so, that's a huge lexicon, but I imagine my natural language could easily stump it.

Anyway, Cucumber can only be used by a Ruby programmer, and my friend-and-colleague Eric and I were tasked with making something that business analysts could use. So we put together Cucumber and FitNesse with something called Cukable. (Shamelessly promoting my employer here.) It, too, has a fairly large embedded lexicon - documentation of which I can't find right now - but FitNesse also has facilities for importing macros. I was also able to incorporate variables and if statements (nested, thank you very much ():)), but the linear nature of FitNesse appeared to preclude loops. The whole thing's open-source if you want to take a look.

As far as the presentation of your system, I'm not even confident enough that your EXE is safe to run it in Wine yet. But I have perused some of the documentation.

instructions.pdf said:
When you start me up, I will quickly take over your screen so you no longer have to look at that painted whore of an interface that comes with the kluge.
I don't think I like the idea of your program taking over my screen. :colbert:

Edit: Oh, yeah, and this all hasn't changed since 2006?
 
Last edited:

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
It is an interesting thing to attempt, but I believe it is doomed to failure.
Not sure what you mean by "doomed to failure." The program works, re-compiles itself, and has been used to produce a variety of real-world applications over the past 7 years.

First, there is the fact that natural languages just don't lend themselves well to programming.
We respectfully disagree -- it was both easy and fun to program our development system in Plain English. And our development system is not a trivial program.

Take this statement for example:

He gave her cat food.

Now, did he feed her cat food or did he give her some cat food? It is ambiguous and really depends a lot on inflection or context.
Indeed. The curious thing is that we were able to write such a substantial program without having trouble with things like that.

Then there is the more practical problem. I've seen WAY too many bug reports from users of software that think they are giving plenty of information to solve the issue, they don't. It usually requires a large effort to ferret out all requirements to finally build a working program.
That sounds more like a design and specification and testing problem, rather than a choice of language problem.

And then there is the problem with formatting. There is a reason why indentation has become king when programming, it makes reading, reasoning, and writing a program much easier to handle. A natural language programming language would either end up being undebuggable because everything becomes paragraphs or horribly cludgy because you would end up writing programs that look like a whole bunch of wordy statements in sentences.
See our code; we typically place each sentence on a line by itself.

And then there is the question of brevity. Which would you prefer

Code:
if (person.isAlive())
   person.die()
   world.reset()
   cleanup()
vs
Code:
if the person is alive, tell the person to die and reset the world and cleanup
The first has many small easily chunckable statements which can be broken up. The second is a hauppauge of actions.

Even if you try to format it
Code:
if the person is alive,
   tell the person to die 
   and reset the world 
   and cleanup.
You end up with something that looks like cat scratches. And lets not forget logical statements. You could do the above, but what if you wanted to check two things vs execute functions? It become a nightmare fast.
Again, wasn't a problem for us. The bottom line is that we did not find it as imprecise or inconvenient or otherwise unworkable as many thought it would be. Perhaps it's a "personality type" thing; perhaps some kinds of people will never like it. But we do.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
Interesting premise, worrying presentation...[I can't imagine developing something like this without some base keywords.
The "keywords" of the language are the same ones (we believe) people use to parse conversation in their heads: articles (a, an, the), prepositions (of, in, on, etc), and state-of-being verbs (is, has, does, etc). All of the other terms are defined by the programmer and are "hardcoded" nowhere.

In your example, "suck" and "bottle" are the baby's base keywords. I see a few of them in your compiler:
Code:
to add a number to another number:
  intel $8B8508000000. \ mov eax,[ebp+8] \ the number
  intel $8B00. \ mov eax,[eax]
  intel $8B9D0C000000. \ mov ebx,[ebp+12] \ the other number
  intel $0103. \ add [ebx],eax
x86 assembly?
Yes, x86 assembly at the very bottom -- the compiler generates native Intel machine code and we have to tell it somewhere what to generate.

Code:
to adjust spacing given a string:
  if the current canvas is not the printer canvas, exit.
  call "gdi32.dll" "SetTextCharacterExtra" with the printer canvas and 0.
Windows DLL calls?
Yes, Windows DLL calls. It runs on Windows. But note that the user of our Plain English system does not need to know anything about either x86 assembly or Windows DLLs.

But surely the compiler couldn't compile itself initially. How did you initially compile the compiler?
Decades ago we wrote a compiler for a Pascal-like language called AIQ in Delphi. We used our AIQ language to write the first scaled-down version of the Plain English compiler. Then we used successive versions of the Plain English compiler to grow it into what it is now.

It looks like the "noodle" defines most of the other keywords-phrases. Is that right? If so, that's a huge lexicon, but I imagine my natural language could easily stump it.
Not accurate. The "keywords" as I described above are defined in the Compiler file. The Noodle is mainly just a wrapper for ugly Window's and Intel stuff. And the "lexicon" of keywords, as I described above is not only small, but limited primarily to articles, prepositions, and short verbs. See page 11 of the manual for an overview.


Anyway, Cucumber can only be used by a Ruby programmer, and my friend-and-colleague Eric and I were tasked with making something that business analysts could use. So we put together Cucumber and FitNesse with something called Cukable. (Shamelessly promoting my employer here.) It, too, has a fairly large embedded lexicon - documentation of which I can't find right now - but FitNesse also has facilities for importing macros. I was also able to incorporate variables and if statements (nested, thank you very much ():)), but the linear nature of FitNesse appeared to preclude loops. The whole thing's open-source if you want to take a look.
Thanks, I'll do that when I have some time.

As far as the presentation of your system, I'm not even confident enough that your EXE is safe to run it in Wine yet. But I have perused some of the documentation.
For what it's worth, you have my personal guarantee that it's safe.

I don't think I like the idea of your program taking over my screen. :colbert:
We were trying to show what an alternative to Windows might look like. The advantage is that (1) we know exactly what the user's screen looks like so it's easier to document, and (2) it looks and behaves exactly the same on every version of Windows.

Edit: Oh, yeah, and this all hasn't changed since 2006?
Minor updates only. It's a remarkably stable and capable system.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
An AV checker can't tell that an EXE is safe, only whether it has been altered by a virus/trojan.

Your EXE could be written to do keylogging, read and transmit data files, make or read registry entries, set processes or services to run at startup, etc. without it being infected.
Could be, but it's not. What more can I say? How does anyone on this forum ever share an executable that they've written?
 
Last edited:

Markbnj

Elite Member <br>Moderator Emeritus
Moderator
Sep 16, 2005
15,688
12
81
www.markbetz.net
Could be, but it's not. What more can I say? How does anyone on this forum ever share an executable that they've written?
People don't share executables via this forum, even long time members in good standing.

In general people don't often share software projects as executables, or at least not solely as executables. If it is proprietary then hang it off your own site, and link to the page. I'll allow that, and you can take responsibility for the content.

If it is not proprietary then host the source and the binaries on one of the sites expressly made for the purpose: bitbucket, github, codeproject, etc.
 
Jun 19, 2004
24,142
1,588
126
It's an interesting idea but, there are currently no computers or software sophisticated enough to parse standard English (or, any other spoken language). The reason is humans infer from context while computers need rigid definitions.
 

brianmanahan

Lifer
Sep 2, 2006
20,957
2,860
126
i have seen and used attempts at natural language type programming languages

they never work well
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
...hang it off your own site, and link to the page. I'll allow that, and you can take responsibility for the content.
Forgive my ignorance, but I thought that was what I did. I provided a link to a zip file, on our site, that contains the instructions, the source code, and the executable.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
It's an interesting idea but, there are currently no computers or software sophisticated enough to parse standard English (or, any other spoken language).
If that's so, then how were we able write the program we wrote?

Granted, our compiler doesn't understand anything and everything that someone might say -- most humans can't do that! But we know that it does understand the 25,000 plain English sentences that we've asked it to parse, because it's able to display our desktop, and manage our files, and edit our text, and compile our programs, and layout our pages as we intended it to do.

The reason is humans infer from context...
It's true that humans infer much from context; so does our compiler. Consider, for example, this Plain English code fragment:

Put 7 inches into an x coordinate.
If the x is greater than the screen's right, exit.


The compiler assumes, based on the context, that the variable referenced in the second line as "x" is the local variable that was implicitly defined in the first line with the term "x coordinate"; it also assumes, based on a larger context, that "the screen's right" refers to a global variable that describes the dimensions of the user's monitor.

...computers need rigid definitions.
But not as rigid as we've been led to believe -- at least not at the level of source code. Consider, for example, these similar lines of Plain English code:

Draw the text with the Osmosian font.
Draw the text using the Osmosian font.
Given the Osmosian font, draw the text.

Our complier understands that all three of those statements are specifying a call to the same routine even though they are coded in different ways (because it knows that in this context, "with" and "using" and "given" are equivalent prepositions, and that the order of the clauses is inessential.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
i have seen and used attempts at natural language type programming languages... they never work well
I can't speak about your personal experiences, since I don't know what they are. But my own personal experience programming a native-code-generating compiler/linker with all the side dishes (desktop, file manager, editor, dumper and page layout facility) in Plain English was nothing but delightful (except, of course, for interfacing with Windows and those ugly Intel chips!). And since the completion of that project, I haven't even been tempted to program in any other language. One of the things I like best about programming in Plain English is that when I come back to it after being away for a while, I can get back up to speed in minutes since the syntax of the language is essentially the syntax I use, in oral and written conversation, every day.
 
Jun 19, 2004
24,142
1,588
126
If that's so, then how were we able write the program we wrote?

Granted, our compiler doesn't understand anything and everything that someone might say -- most humans can't do that! But we know that it does understand the 25,000 plain English sentences that we've asked it to parse, because it's able to display our desktop, and manage our files, and edit our text, and compile our programs, and layout our pages as we intended it to do.



It's true that humans infer much from context; so does our compiler. Consider, for example, this Plain English code fragment:

Put 7 inches into an x coordinate.
If the x is greater than the screen's right, exit.


The compiler assumes, based on the context, that the variable referenced in the second line as "x" is the local variable that was implicitly defined in the first line with the term "x coordinate"; it also assumes, based on a larger context, that "the screen's right" refers to a global variable that describes the dimensions of the user's monitor.



But not as rigid as we've been led to believe -- at least not at the level of source code. Consider, for example, these similar lines of Plain English code:

Draw the text with the Osmosian font.
Draw the text using the Osmosian font.
Given the Osmosian font, draw the text.

Our complier understands that all three of those statements are specifying a call to the same routine even though they are coded in different ways (because it knows that in this context, "with" and "using" and "given" are equivalent prepositions, and that the order of the clauses is inessential.
What happens when the user says, Write the words with Osmosian. Type the text with Osmosian. Print the page in Osmosian.
 

Gerry Rzeppa

Member
Dec 13, 2013
195
1
76
www.osmosian.com
What happens when the user says, Write the words with Osmosian. Type the text with Osmosian. Print the page in Osmosian.
It depends on what else you have told the compiler. As I mentioned in another reply, the "keywords" the compiler knows are primarily articles, prepositions, and a handful of very common state-of-being verbs (like is, has, and does). The rest of the vocabulary is defined by the programmer for his particular application. So if you tell it what a "text" is, and you tell it that "the words" are synonymous, it will behave accordingly. Likewise, if you tell it how "to print a page in a font" it will then invoke that routine when you say "Print the page in [or "given" or "using"] the Osmosian font." There's no magic here -- we never claimed there was. We simply said that our personal experience has been that:

1. We find it easier to program when we don’t have to translate our natural-language "pseudo-code" thoughts into an alternate syntax; and that

2. Natural languages can be parsed in a relatively “sloppy” manner (as humans apparently parse them) and still provide a stable enough environment for productive programming; and that

3. Low-level programs (like compilers) can indeed be conveniently and efficiently written in high level languages (like English).

And keep in mind that every type you define and every routine you code increases the compiler's vocabulary and skill set. So the compiler's ability to understand what you say increases more and more as you "get to know one another".

I recommend you take it for a test run. It's quick, it's easy, it's entertaining, and some have even found it edifying. Write me for a link if you can't find one in this thread.
 

Sheep221

Golden Member
Oct 28, 2012
1,844
26
81
I don't think it's a good idea just because of the word order. Commanding a child or animal or other person is not same as programming. If you want to program a door opening, for a compiler it is difference when you write open door, door open or open the door, same as, shut door, shut the door, or close door. It would be possible but then programmer would have to remember all sorts of exact commands which would be hard to sustain, given the way we use our natural language, so it's easier for both compiler and programmer to remember door_open=1 or door_open=0 and use the command accordingly. Anyway, with natural language anyone virtually could be a programmer without hard effort and I don't agree with this, if I have to work hard to become doctor, lawyer or firefighter and more, why not a programmer?
 

douglasb

Diamond Member
Apr 11, 2005
3,163
0
76
Forgive my ignorance, but I thought that was what I did. I provided a link to a zip file, on our site, that contains the instructions, the source code, and the executable.
He meant the source code INSTEAD of the executable. You did not post the source code of the executable. You posted a bunch of random text files that your executable presumably parses and then does something with.
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
15,382
2,415
55
It, too, has a fairly large embedded lexicon - documentation of which I can't find right now
I finally found the missing piece: Rsel. (And Selenium. I forgot how dependent this is on running in a web browser.)
 
Status
Not open for further replies.

ASK THE COMMUNITY

TRENDING THREADS