Google for "weston bye magnetic gear clock". Note its not as convenient as you might think... no ferrous material in the construction or it'll build up on the magnets until it hits something, and no pendulum designs, or none with conductive material due to magnetic braking.
It turns out the inherent mechanical limitations override the low friction advantages pretty much everywhere.
For practical engineering work most frictionless applications either need to handle 100+ HP to make economic sense, which isn't happening, or what they really need is sensing with no stick/slip friction and we have rather advanced and cheap optical position sensors and other non-contact sensors now a days.
It's a set of tools and frameworks that make it convenient to use the Gambit Scheme compiler to develop apps for several platforms.
There are a variety of reasons that someone might choose it over Clojure or ClojureScript:
- they like Scheme better than Clojure
- they like the frameworks in LambdaNative better than the libraries available for Clojure
- they like the toolchain used with LambdaNative better than the toolchain around Clojure (both toolchains are kind of baroque compared to, say, Lispworks or ClozureCL)
- they want to build for a platform (such as iOS) where Gambit provides a convenient solution and Clojure doesn't
- they want to deliver apps to more platforms than Clojure currently supports
- they want to deliver compiled binaries that don't need a JVM or javascript VM to run
After reading Bezos' biography a few weeks ago, this sounds like something that he would never, ever do. Amazon is the everything store. What's going on?
Without getting too specific it helped me do a few things (I know your question is about learning) however. First, it let me mend fences with people who I hadn't talked to in a while and I learned that it was easy to reconnect by doing something like this because it makes it very easy and lowers the social friction.
I also saw a few broad themes like being disorganized, thinking big but failing to execute, lack of ambition, etc. Some overlap, and some were smaller issues. I reckon I will actually write it up, depending how significant the other half of the results are.
On balance, it is a good way to reconnect with people and also see if there are broad negative attributes you were missing. I also wrote a few responses to people who asked for me to do it in return, so it gives you a chance to help others and yourself if your close friend has a really annoying quality you wish he would work through.
Just from the perspective of mapping sentence meanings to bash commands, that's a difficult thing to do. But going beyond that, I think there are issues having to do with the ambiguity of language that just aren't solvable, period.
Take your example: "Show me all my files, including my hidden ones". That, to me, should show all the files on the entire system where I am the owner. Even as someone who ostensibly knows some bash, you missed that you dropped some pieces of data which are relevant in bash terms. "my" indicates ownership, and nowhere in your sentence did you say to limit the function to the current directory. If you're making that mistake as an experienced user, what hope does a beginner have?
`ls -a` actually encodes a fairly complex query, which only becomes apparent when you attempt to really nail down what it does in a natural language. To produce `ls -a`, you would really have to type something like "List the names of all the files, folders, and symbolic links in the current directory that are visible to the current user." You could, of course, start making assumptions about certain parts of this, similar to how `ls` does, but then you get into users guessing which part of the sentences they can elide (why wouldn't we assume that "List the names of the files, folders, and symbolic links in the current directory" wouldn't show us all the files, folders, and symbolic links?). At that point, the user must learn the idiosyncrasies of which exact sentence they have to type in to get what they want: i.e. when they have to say "all", when saying "my" matters instead of saying "the", etc. At that point the natural language stuff is no longer a learning tool, it's a separate, very complicated thing for the student to learn in addition to what they are trying to learn.
As another example of this: if you're willing to accept some ambiguity, why did you choose `ls -a` instead of `find .`? Recognizing that `ls -a` and `find .` do very different things.
To summarize: I don't think it's a bad idea, just an impossible one. :)
I think there are issues having to do with the ambiguity of language that just aren't solvable, period.
This, absolutely. Once you've used a programming language enough, you'll find that natural languages are disturbingly ambiguous; it only works (most of the time, at least) for communicating with other humans because of implied context.
To me and a lot of people, the commandline is already natural language.
`ls -a` is just a contraction for "list all"
Your nine words aren't any more expressive than my two, and that's the problem. There's not much value in being able to express simple commands with long sentences (with often many interpretable meanings)
There _could be_ value in natural language processing for some very complicated commands, but it would have to be fairly intelligent before it would be useful.
A good NLP interface for files would look as different from a command-line as it would from a graphical file manager. You'd want something context-sensitive, with the ability to use pronouns and iterative refinement, some of which would take the place of simple scripting. You'd need to replace many commands with phrases, and many variations on phrases.
Whether you'd get any users is another question.
You might also consider what a command-line interface based on Dasher would look like. Probably not just a simple typing interface. You could extract a great deal of useful information from completion mechanisms, for instance.
> What do people think about wrapping a Natural Language Processing interface around the command line (for educational purposes)?
Fragile, verbose, and actively hostile to learning why anyone would actually use a command line shell to begin with. For example, how would your syntax support redirection?
Bourne shell syntax is hairy enough as it is. The quoting rules are rebarbative and dealing with whitespace can drive you to madness in some circumstances. Adding another thick layer of syntactic sugar onto that is only going to end in tears.
