Natural Language Programming

[Gerry Rzeppa]

That [most of what most programs do is simple stuff] is total BS. Programs are written to perform complex tasks, that's why they are needed in the first place, geeez. I've never once written a program to "draw a line on the screen" or "Move this over here".

Think of Amazon's website, for example. Most of the code there is simply finding the information of interest (probably using an English-like language like SQL) and slapping it on the screen. Manage the shopping cart. Calculate the total. Which part of that is difficult?

Or think of the computer systems in every fast-food restaurant in the world: display a menu on a big TV screen; let an employee select items on a keyboard and total up the amount.

Or think about Twitter, Facebook, the code in every microwave oven in the world: nothing hard about any of those.

Or consider our very own integrated development environment (interface, file manager, text editor, hex dumper, compiler, page-layout facility): most of that is just "move this" and "draw that" and "save something" -- I know, I wrote the thing. Most of what most programs do is trivial and is most often most easily expressed in natural-language terms.

You write some plain English compiler that works on only the very narrowest scope and call it a success.

It answered the questions we set out to ask, so yes, it's a success. And it has served us well since -- both as a teaching tool and in the development of new systems and products. So again, yes, it's a success.

Again let me repeat this. Your project is not needed. You created it to try and solve a problem that does not exist, and it will never be used by anyone outside your cult.

Too late. Already being used by others. Do I need to repeat all those glowing reviews from actual users of our system?

I wrote a Tetris clone in VB. Do the same in your natural language. This should be right up your alley, there is no complicated math involved. Or better yet, have someone who has never programmed before (but knows the game well) write one using your natural language. You will have me firmly in your court if you can. Standing by.

So writing an entire development system -- including interface, file manager, text editor, hex dumper, native-code-generating compiler/linker and wysiwyg page layout facility -- conveniently and efficiently, in Plain English, isn't enough to prove the concept viable to you? You'd be more impressed with a small game?

Okay, then, here's what that kind of thing looks like in Plain English. This is the essence of a pong-like game I wrote with a six-year-old where you try to stop a moving bird with a baseball bat:

To do it:
Draw the screen's box with the black color.
Move the bat. Draw the bat's picture.
Move the bird. Draw the bird's picture.
Check for collision.
Draw the score.
Refresh the screen.
If the escape key is not down, repeat.

To move the bat:
Put the mouse's spot into a spot.
Put the screen's right minus 1 inch into the spot's x.
Center the bat's picture on the spot.

To move a bird:
Move the bird's picture right the horizontal bump.
Move the bird's picture down the vertical bump.
If the bird's right is greater than the screen's right, play the pop sound; subtract 1 from the score; negate the horizontal bump.
If the bird's left is less than the screen's left, play the boink sound; negate the horizontal bump.
If the bird's bottom is greater than the screen's bottom, play the boink sound; negate the vertical bump.
If the bird's top is less than the screen's top, play the boink sound; negate the vertical bump.

To check for collision:
Put the bird's picture's center into a spot.
Put the bat's picture's box into a box.
If the spot is not in the box, exit.
Say "ow".
Add 1 to the score.
Add 1/64 inch to the horizontal bump.
Add 1/64 inch to the vertical bump.
Negate the horizontal bump.
Negate the vertical bump.
Move the bird's picture left 1/2 inch.

To draw the score:
Put the score into a string.
Put the green color into a color.
If the score is less than 0, put the red color into the color.
Draw the string in the center of the screen's box with the color and the font.

There's more stuff, of course, like type and variable definitions and some initialization code, but that's the gist of it.

 

[Markbnj]

Think of Amazon's website, for example. Most of the code there is simply finding the information of interest (probably using an English-like language like SQL) and slapping it on the screen. Manage the shopping cart. Calculate the total. Which part of that is difficult?

Gerry, really? They created the entire Amazon Web Services cloud infrastructure, probably one of the most sophisticated cloud computing platforms in existence, because they needed it to run their e-commerce and fulfillment systems. Netflix, which drives about 1/3 of all downstream Internet traffic, uses AWS because it was better than anything they could build for themselves.

When you make comments like that trivializing very difficult and significant technical achievements it just makes you sound like a loon and twerp. You should not wonder why you constantly run into the same reaction; why you got only one negative comment on HN; why your indiegogo is unfunded. Grow up.

 

[Gerry Rzeppa]

This would be a good idea as well. Simple games are often chosen for demo programs because they touch on every aspect of what a modern language has to enable: input, timing, events, looping, logic, drawing, etc.

Indeed. The sample program described in our instruction manual also touches on all those things (plus accessing and parsing a page off the internet). Events and loops, for example, are discussed on pages 20-21; flicker-free drawing on pages 24-25, etc. The manual is here: www.osmosian.com/instructions.pdf

If Tetris isn't up your alley, Gerry, feel free to port my C#/WPF rendition of Conway's Game of Life. Link to an archive with binaries and sources is at the bottom of the page.

And the point would be? I'm already certain "Conway's Game of Life" can be conveniently and efficiently programmed in Plain English, so there's no direct benefit to me. And I don't know what you would get out of it either: if you can't see from the work we've already done and the reference materials that come with our system that such a thing is possible, well, I'm not sure pasting the actual code in here would help.

 

[Gerry Rzeppa]

"We", "our", you use these terms almost exclusively and yet you're the only one here. I find that remarkable.

I often say "we" because my elder son and I worked closely together on the development of the system. We agree on the principles I espouse here.

 

[Merad]

Once again, the quality of a solution has to be judged relative to the goals set for that solution. And it must be kept in mind that great engineering almost always involves striking a balance between competing objectives. In this case, we wanted a compiler that was both (1) simple, and (2) efficient.

Gerry, you don't even know what your own goals are. In one post you talk about making plain english great for students and new programmers, then in the next post talk about how plain english is great for writing almost anything, even OS kernels. As a result you're making lots of contradictory decisions that only serve to make your product worse for everyone. One decision is good for beginners at the expense of experienced developers, another is good for experienced developers at the expense of beginners. It's almost like a comedy of errors.

 

[Gerry Rzeppa]

Gerry, really? They created the entire Amazon Web Services cloud infrastructure, probably one of the most sophisticated cloud computing platforms in existence, because they needed it to run their e-commerce and fulfillment systems. Netflix, which drives about 1/3 of all downstream Internet traffic, uses AWS because it was better than anything they could build for themselves.

Sure. But that doesn't change the fact that most of the code in most of their systems simply moves stuff around and draws it and saves it and other simple stuff like that.

COBOL vendor Micro Focus claims:

- COBOL supports 90 percent of Fortune 500 business systems every day
- 70 percent of all critical business logic and data is written in COBOL
- COBOL powers 85 percent of all daily business transactions processed
- $2 trillion worth of mainframe applications in corporations are written in COBOL
- 1.5 million new lines of COBOL code are written every day
- 5 billion lines of new COBOL code are developed every year
- The total investment in COBOL technologies, staff and hardware is estimated at $5 trillion
- An estimated 2 million people are currently working in COBOL

I believe those are recent statistics. But even if not, the point still remains: most of what most businesses do can be expressed in COBOL, so most of it must be easy stuff like move and draw and save.

When you make comments like that trivializing very difficult and significant technical achievements it just makes you sound like a loon and twerp.

Or someone with a bit of perspective: someone who is far enough away from the trees to see the forest. Take another look at that "Game of Life" program you wrote and mentioned earlier: see how much of it is actually "difficult and significant technical achievements" versus how much is stuff like "move this over there" and "draw that on the screen" and "save something someplace".

 

[Gerry Rzeppa]

Gerry, you don't even know what your own goals are. In one post you talk about making plain english great for students and new programmers, then in the next post talk about how plain english is great for writing almost anything, even OS kernels. As a result you're making lots of contradictory decisions that only serve to make your product worse for everyone. One decision is good for beginners at the expense of experienced developers, another is good for experienced developers at the expense of beginners. It's almost like a comedy of errors.

The overarching goal is to make everything simple for everyone. Our Osmosian Aunt Tilly often says, "If it's hard, it's wrong," and we've taken her advice seriously to heart.

Thus it is not contradictory that we want to write an OS kernel in a way that can be understood by a 12-year-old: that's the ultimate goal: to make the whole thing simple and understandable. So we nibble away at it from both ends: (a) making the high-level stuff more like everyday speech and writing, while (b) eliminating the non-essentials from the lower-level stuff. That's why we use only ten of the hundreds events available to us in Windows, and only a dozen of the hundreds of instructions available on a typical Intel CPU. Now I know that some people here call that extra stuff "sophisticated technical advances" -- but we call it decoration. As Aunt Tilly's would say, "Tell us what you need, and we'll tell you how to live without it."

 

[Markbnj]

Or someone with a bit of perspective: someone who is far enough away from the trees to see the forest.

No, just someone who lives in his own world and is disdainful of everyone who lives outside of it. So, two things:

1) Stop twisting words. This isn't a religious forum. We have P&N here if you relish that type of debate. I did not speak of my little experiment in WPF as any sort of significant technical achievement. I was responding to your characterization of Amazon's website.

2) Stop being deceptive. If your son wants to come here and speak for himself he's welcome. All you're doing is trying to make your personal "movement" sound larger than it is. Again, we have bullshit forums for bullshit. This isn't one of them.

 

[Merad]

The overarching goal is to make everything simple for everyone. Our Osmosian Aunt Tilly often says, "If it's hard, it's wrong," and we've taken her advice seriously to heart.

And there, truly, is your fundamental contradiction.

Managing memory and ownership is hard, so we've developed complex garbage collectors and reference counting schemes so that most programmers don't have to worry about it. But you don't want that, because you don't even acknowledge that it's a difficult problem.

Making effective and attractive GUIs is hard, so we develop GUI toolkits and widgets to make the job somewhat easier. But you want everyone to design their own GUI from scratch, because everything else is a "painted whore".

Developing real-world software is difficult, and your Aunt Tilly is a fool if she thinks otherwise. The best way we've found to make the process easier is to create layers of abstractions to insulate the end developer from the complexities of the underlying machine. But you don't want any of that because it's all just "kluge". Before you repeat your line about your compiler and IDE yet again, let me be blunt: Yes, it took a fair amount of work to create those, and you should be proud of them. But compared to software that exists today, they barely even qualify as toys. It's probably not an exaggeration to say that the web browser you're writing your response in is hundreds if not thousands of times more complex than both of your tools combined.. and a web browser is far from bring the most complex program out there.

Do you ever stop and ask yourself why, 8 years after its release, there are apparently less than 5 active users of plain english? We're trying to tell you, but your eyes and ears are sealed. You have some ideas that could produce very interesting results, but the way you're pursuing them only is only going to result in all of them dieing off whenever you get tired of posting about them on forums like this.

 

[Gerry Rzeppa]

If your son wants to come here and speak for himself he's welcome.

I don't think that's going to happen. My son feels quite strongly that nobody with a life ever participates on forums!

 

[crashtech]

Nice. *unsubscribes*

 

[Gerry Rzeppa]

Managing memory and ownership is hard, so we've developed complex garbage collectors and reference counting schemes so that most programmers don't have to worry about it. But you don't want that, because you don't even acknowledge that it's a difficult problem.

But managing memory isn't hard, whether it's done automatically (as we do with strings) or manually (as we do with other structures in our system).

Making effective and attractive GUIs is hard, so we develop GUI toolkits and widgets to make the job somewhat easier.

Again, that's not true and again, we know, because we've done it (and not just in our prototype). It may be tedious, but it's not hard.

But you want everyone to design their own GUI from scratch, because everything else is a "painted whore".

No, I want designers and developers to think about the interfaces they are planning for their users, and not just assume that the status quo is best. Does a cashier at retail store really need scroll bars on her screen? Should forum editors be edit-here-preview-there-go-back-to-make-corrections, or wysiwyg? In Windows there are at least 6 ways to close a window (close box, menu command, icon on toolbar, ALT-F4, CTRL-F4 CTRL-W, etc). Do we really need all of those in all applications?

Developing real-world software is difficult, and your Aunt Tilly is a fool if she thinks otherwise. The best way we've found to make the process easier is to create layers of abstractions to insulate the end developer from the complexities of the underlying machine.

Better still to simply eliminate those complexities wherever possible. But again, you have to keep our goals in mind when evaluating our work: the educational value of a system is of prime importance to us.

But you don't want any of that because it's all just "kluge".

We don't want any unnecessary complexity in our systems, yes. Nothing that even smacks of "kludginess".

Before you repeat your line about your compiler and IDE yet again, let me be blunt: Yes, it took a fair amount of work to create those, and you should be proud of them. But compared to software that exists today, they barely even qualify as toys.

Obviously, we disagree.

It's probably not an exaggeration to say that the web browser you're writing your response in is hundreds if not thousands of times more complex than both of your tools combined.. and a web browser is far from bring the most complex program out there.

Browsers are complicated because the languages they are required to support are so badly designed and are in a constant state of flux. Our system is small and reliable because the underlying design is both simple and stable. You're comparing apples and oranges. Oberon is much, much smaller and simpler than than Windows, but it's not a "toy".

Do you ever stop and ask yourself why, 8 years after its release, there are apparently less than 5 active users of plain english?

Don't have to. I know why. My son got married (to a woman with three kids) and had another kid after that and hasn't had time to work on the thing. Almost simultaneously, my wife (57 years old at the time) and I also had a another baby, who has taken up a great deal of our time and energy. So the project has been on the back burner for a while. But now things are settling down for my elder son, and our younger son is nine and almost ready to learn about compilers and such, so we're looking to revive it.

Meanwhile, people are at work converting our system to both Plain Portuguese and Plain Spanish; and we've got a potential candidate for the Plain Russian version as well. We've also posted ads for bilingual French, German, and Italian programmers who are interested in bringing natural-language programming to their societies. That's something truly unique in the world of programming languages.

We're trying to tell you, but your eyes and ears are sealed. You have some ideas that could produce very interesting results, but the way you're pursuing them only is only going to result in all of them dieing off whenever you get tired of posting about them on forums like this.

Don't think so. Soon we'll have some financing from one quarter or another, and we'll be back in development mode. We're leaning toward an implementation specifically designed for schools this time around. Probably something inexpensive like a Chromebook that can booted with either our operating system and compiler on one of those teensy thumb drives (for learning, growing, and accessing our "Alternet"); or with Chrome (for access to the rest of the world). Let the kiddos see and experience the differences first hand. And, of course, catch 'em before they pick up a lot of bad habits and crazy ideas about how things "have to be."

 

[BoberFett]

Exactly. My wife -- a typical mom -- doesn't need or want to see a URL on the screen when she's looking for kid's shoes. Putting one there shows an utter disregard for the point of view of that entire user community. In a word, it's bad design.

In your opinion. And I think you're wrong.

 

[BoberFett]

This guy is a tool.

 

[Gerry Rzeppa]

My wife -- a typical mom -- doesn't need or want to see a URL on the screen when she's looking for kid's shoes. Putting one there shows an utter disregard for the point of view of that entire user community. In a word, it's bad design.

In your opinion. And I think you're wrong.

It's not my opinion (or yours) that matters here; it's my wife's -- she's the user in this case. And I just asked her again: same answer. But admittedly, that's only a sample of one. So ask around. Print off two pictures of the Walmart web site with some shoes displayed -- one with the URL at the top, one without. Then ask the first ten moms you see if that URL thing at the top does anything for them. Most (if not all) will say no. Then start deleting other stuff. Pretty soon you'll have a simpler and more focused design that requires less coding, less testing, less documentation, etc.

 

[Markbnj]

I don't think that's going to happen. My son feels quite strongly that nobody with a life ever participates on forums!

Well seeing as how the vast majority of the useful programming knowledge is found on forums, user groups, and message boards, I am not surprised.

 

[BoberFett]

Your design sucks. A menu per letter? Terrible.

 

[Merad]

Soon we'll have some financing from one quarter or another, and we'll be back in development mode.

Indeed, I see that you're up to $100 on Indiegogo right now. Good luck with that.

 

[Spungo]

Think of Amazon's website, for example. Most of the code there is simply finding the information of interest (probably using an English-like language like SQL) and slapping it on the screen. Manage the shopping cart. Calculate the total. Which part of that is difficult?

It's the little things that will screw you up the most.
I was working on my little C#/WPF project last week, and I encountered an odd problem. The way it's supposed to work: a tree view is on the left side of the window and a listbox is on the right side of the window. When a directory is selected on the left side, the right side should show all of the .dwg files in that directory. Think of Windows Explorer. Directories on the left, files on the right. It worked great.... but only for the root directory of any given drive. It could see files in C:\ but not C:\files\. If C:\files\ was selected, it would still say the files found in C:\. It took a while before I realized what the problem was. The way the program works is like this, as best as I can remember:
-Clicking a drive or directory in the tree view (left side) triggers an Expanded and a Selected event.
-The Expanded event gets a list of directories in the selected directory and adds them to the treeview (left side) as subitems.
-The Selected event clears the listbox (right side), gets a list of files in the selected directory, and adds the files to the listbox if they contain the extensions .dwg or .DWG

That's it. That's the whole process. Why does it not work? Select the text below to see the answer:

The Selected event was bubbling up through the hierarchy. I'm not entirely certain, but I think this is because the tree view was a recursive thing. Each tree item was subscribed to the Expanded and Selected events. That means the most deeply nested tree item would see the Selected event, clear the listbox, add that directory's files to the listbox, then pass the event to the parent directory in the tree. Selecting C:\test\files\ would list the appropriate files in C:\test\files, pass the event up to C:\test, this would then clear the listbox again, list the files for C:\test, pass the event to C:\, clear the listbox again, and list the files for C:\. This means it will only ever show the files found in the highest directory for any given drive letter. The way to fix this is to write "e.Handled = true" at the bottom of the Selected event's code.


Amazon is 100x larger than my little project. Good luck trying to figure out why the test system wants to charge a credit card 3 times instead of 1 time.
There's probably an easy way to build Amazon, but it's only easy if you know how to do it.

Or think about Twitter, Facebook, the code in every microwave oven in the world: nothing hard about any of those.

There's also nothing hard about listing files in a directory until you try doing it, it doesn't work, and you have no idea what went wrong. Fixing the problem takes 10 seconds, but understanding the problem can take hours.

 

[Cogman]

Exactly. So the student can learn all about computers, from the top to tbe bottom; from his first and almost magical "Hello, World!" to the lowest level where the secrets of machine code, stacks, memory management, etc, reside.

But they aren't learning anything about "the top" they are learning only the bottom. By making a low level language you are guaranteed to be mired in the low levels.

I haven't had those problems with any of my students, many of whom have gone on to lucrative careers as professional programmers, independently employed. Perhaps you're teaching the subject in an ineffective way. The key, in three words, is this: TEACHING IS TELLING. The so-called Socratic method is bunk. You want to transfer the working neural patterns in your brain into your student's brain -- not ask the student to reinvent the wheel. So you show him a problem, then you hand him the solution on a silver platter and have him type it in. (Our standard dual-monitor set up, where the teacher controls the mouse and the student controls the keyboard, is ideal for this kind of training.) Then you do it again, with the next problem. And again, and again, and again. When you see that the student is typing the right stuff before you tell him what to type, you're done.

Good job, you've trained code monkey's that are incapable of original thought! Seriously, this method of teaching will only result in students that program in a style very similar to their teacher. Quite frankly, I've seen this method employed before and it rarely (if ever) turns out someone that actually understands the WHY behind what they are doing.

Actually, more like Pascal or Oberon. But clearly that's all that's needed, both for beginner and professional.

No, those language have WAY more features that your natural English garbage. The similarity is only that those languages focused less on symbols and more on using english words.

If it wasn't enough, how could we write an entire integrated development environment (including interface, file manager, text editor, hex dumper, native-code-generating compier/linker, and wysiwyg page layout facility for documentation) -- conveniently and efficiently -- with just that and no more?

Oh? So the proof that a language is great is that you can do complex things with it? All of these things you have done were done with assembly just as efficiently. Were those assembly languages enough? No way! Just because you've made a compiler and wysiwyg editor in your language says nothing about the goodness of the language. The only thing it proves is that the language is Turing complete and that it has someone dedicated enough to it to make these things.

Just about every popular language out there (and several pretty unpopular ones) have been used to make the things you have made here. So the next question is why should a professional programmer want to use your language. As I've written, your focuses are completely misplaced.

Making complex things says absolutely NOTHING about the quality of a language or programmer. You can get the same results using a power screwdriver vs a manual screwdriver. Yet the tools are fundamentally different.

The beginning student doesn't need to see any of the low-level stuff. That's why, for example, we manage memory for strings automatically. But we do want the more advanced student to understand memory management, so we expose that level of detail when the student is ready to study more advanced data structures.

Great, this shows that you have make a purposefully inconsistent language. Good job on that one. Now "the student" has to figure out when memory manage takes place and why strings are treated differently from other things. The answer? "Well, we wanted this part to be easier but we added booby traps because it makes people better programmers, right?"

Yet smart enough to develop the non-trivial program under discussion. Smart enough to teach others who are now gainfully self-employed in the field. Smart enough to be self-employed in the field myself for over four decades.

I know plenty of idiots that teach programming and have been employees for decades. They have even made non-trivial programs. Their programs are crap and they don't know why. The lessons they teach are useless, but they see them as successes. Given the rest of your post here, I'm guessing you are one of these dinosaurs who couldn't wrap their mind around programming concepts much more complex than methods and variables. You don't understand the higher order programming concepts and so you write it all off as being useless garbage not needed.

To be frank, 40 years ago anyone could have been a programmer. The field was so new that we really didn't know what made a programmer good or bad. Being employed for 40 years says very little about your abilities as a programmer. Your posts here tell me the whole story. Congratulations, you are a terrible programmer with delusions of grandeur because you've managed to stay in the field for a long time.

That's not true. Memory leaks (including the number "drips") are reported when a program terminates. The developer can then use our standard debugging facilities and techniques to find his error. Besides, in practice it's hardly ever a serious (or even frequent) problem -- at least not for a student trained as we train them.

It certainly is true.

All types and routines in Plain English are global in scope, and variables are either global or local in scope. Each project is also it's own scope. This is sufficient for our needs: for teaching beginners how to write simple programs, and for teaching advanced students how to write sophisticated interfaces, editors, compilers, etc. In fact, it encourages the student not to let a program get too big, and not to integrate too many things into a single executable.

Ahahahaahahahaahahaaha!

You are basically admitting here that your language ISN'T suited for large complex application development. Love it.

Yeah. This is why no namespacing with global variables are such a bad idea. Thanks for exemplifying it while sanctimoniously being completely oblivious to the problem.

Yes, the developer copies the libraries (or the parts of the libraries) he needs into his project directory. (There is no separate "project management" facility in Plain English.) This insures that the developer's project will remain stable and operational even if the source library is "improved" at a later time. It's similar to the way our DNA is carried along in every cell of our bodies.

Got it, abstraction bad and scary! Why would we ever want to reuse code without having to copy and paste it everywhere!

It isn't like code every has bugs in it... oh... wait.

So tell me. What happens when the library you are copying and pasting inevitably has a security vulnerability, memory leak, or just bad logic? You now have to go to every project you've ever copied and pasted that library into and hope to god that nobody has touched the library logic. Yeah... great... And the fact that you don't see this as a problem is hilarious. Talk about not seeing the forest through the trees. Happily, you have so very few converts to your programming cult, because I shutter for the poor developers that have to maintain the steaming pile of garbage that is the natural english programming language.

At the time we wrote our prototype, most computers were x86s running Windows, so we chose that as our target. And sure, we could have inserted an intermediate virtual machine into our architecture, but that would have unnecessarily complicated the system for the student, and slowed performance. As I've said before, the elegance of a solution has to be judged based on the goals set for that solution -- not the personal goals of an outside observer like yourself.

So x86 isn't confusing but a intermediary byte code would be? Umm, yeah.... I would just say look up the LLVM for a great example of a low level byte code just as simple as x86 which targets multiple platforms while producing high performance assembly. it is certainly doable and has been done.

It's a wonder, then, that our code is so simple and reliable. In over eight years of productive use, only a handful of inconsequential bugs have turned up, and a serious defect in the compiler is yet to be found.

The language itself is overly simplistic and offers very few useful features to a programmer. That a compiler for a simple language doesn't have serious defects isn't really that surprising and says nothing about the goodness of the language.

Not needed for our purposes. And our disdain for the object approach (verbs inside nouns indeed!) has been documented elsewhere in this thread.

What does immutability have to do with objects? (hint: nothing).

The imperatives that fall from the lips of everyone on the planet, all day, every day, are typically procedural, not functional, in nature. We thus adopt a strictly procedural paradigm for our natural-language programming system. If it's not for you, fine. The "rest of us" are going to stick with the paradigm that has served humanity well for all 6000 years of recorded history.

Yet mathematics is fundamentally founded on functional concepts (simple algebra is functional in nature) and it has been the gradual adaptation of those concepts which have enable our rapid post dark age technical advancement.

We have advanced as far as we have not because a team of workers learned how to read instruction books, but because specialists have proven first theoretically how to do something and later transformed those concepts into actions that they themselves or others could perform.

The future of computers isn't making them dumb procedural executors, but rather expanding their capabilities to understand and handle higher order concepts.

Actually, we are forced to deal with concurrency in some spots -- the same file opened on more than one tab, for example. And we do. But it's not a major area of concern for us or our intended audience.

Who is your intended audience? Beginners? So why the hell are you including such low level concepts. Why is concurrency taboo yet assembly is OK? Is it, perhaps, that concurrency is a hard problem not easily represented by strictly procedural languages? Sorry but any language hoping to be mainstream needs to handle concurrency elegantly, the fact that you ignore it and say "Well, our intended audience doesn't care about this!" shows some big deficiencies in your language. Oh, btw, concurrency is something that is pretty well represented in the english langauge.

"Bill, open the door. Ted you get behind the goat, and jim you make sure the goat doesn't get away from us. Now go!"

That statement assumes that the parties involved will be concurrently doing things.

.

I'm not going to address the rest of the stuff about the english language, My wife is kicking me and telling me to go to sleep.

 

[Markbnj]

Don't think so. Soon we'll have some financing from one quarter or another, and we'll be back in development mode.

I see you don't understand business any better than you understand software. As the co-founder of a software company that went through two angel rounds and two institutional rounds before being acquired, allow me to explain why you will not be getting financing.

You have three potential sources of financing open to you: knowledgeable investors, amateur investors, and crowd funding. Knowledgeable investors (venture capitalists, experienced angels, money managers) will not invest in your project because they seek a return. Since almost nobody pays for programming languages there is no money in them. Across the entire spectrum of software development, outside of some specialty tools for PLCs and the like, nobody pays for development tools except corporations who buy MSDN subs for their devs. The devs themselves can download express versions of the tools for free, but the sub gets them access to tons of other stuff, at a cost of up to $10k or more per year. So, no money in programming languages means no professional investment for Osmosian.

Amateur investors are your friends and family. They have no idea whether you're full of crap or not, but you're family so they might take a shot out of love. It's probably safe to say that if you could have tapped them you already would have.

Crowdfunding. Sorry to say this isn't happening either. People who "donate" to crowdfunded projects aren't investors, and don't get a return. The only thing they get is access to the thing they are funding, if all goes well. Nobody is going to give you money in return for possible access to a programming language, when they can get dozens of working languages right now, for free.

Smart people develop programming languages because they are moved by an idea, not because it is a route to riches, or even a steady job. It might be the latter. It will almost never by itself be the former.

 

[Gerry Rzeppa]

Your design sucks. A menu per letter? Terrible.

It's like the index in the back of a book. And it works. For beginners and experienced users.

 

[Gerry Rzeppa]

Indeed, I see that you're up to $100 on Indiegogo right now. Good luck with that.

As I've mentioned elsewhere, we don't expect the kind of projects we specialize in to succeed with "crowd funding". Kickstarter and IndieGoGo are not so much sources of venture capital as they are "The Home Shopping Club for Generation X, Y, and Z". But real venture capitalists do look in on such sites, now and then, and when a project doesn't get funded, they sometimes offer a traditional investment (ie, where the investor acquires stock in the new venture) behind the scenes. (Anyone who has been in business for any significant period knows the real deals are not typically made in public.) So we think of Kickstarter and IndieGoGo as free advertising directed toward that kind of investor. And if, by some unexpected confluence of events, we happen to get crowd-funded, great.

 

[Gerry Rzeppa]

I'm not going to address the rest of the stuff about the english language, My wife is kicking me and telling me to go to sleep.

Your wife appears to be a wise woman.

 

[Gerry Rzeppa]

I see you don't understand business any better than you understand software... allow me to explain why you will not be getting financing... You have three potential sources of financing open to you...

You're forgetting miracles, Horatio. I believe in miracles. I believe that a kid who knows very little about business can start a company with just $50 in the bank and end up making millions. Something like this, for example: www.era-sql.com. I believe that a woman 10 years past menopause can have a child of her own womb at the tender age of 57. Somebody like this, for example:

I'm pretty sure there are more things in heaven and earth than are dreamt of in your philosophy.