5 ms·
Vocabulary based programming
- scotty79 12y agocompare the card with the ordered card in sequence find the position to be inserted shift the card to make space put in the card This is horribly imprecise and vague. If you understand it, it's only because you can guess a lot from your experience. If it was talking about versoring introns and translucing gerns to make invo you wouldn't know what's that all about. Recently I was trying to understand how CRISPR/CAS works and I can't guess much about it. Btw. there is a vocabulary based programming language, it's called Forth. Not much grammar though.
- hzhou321 12y agoNatural language is imprecise and vague. And it is relying on a lot of your experience. However, this is why natural language is so much more effective than the programming language counterpart -- it leverages on people's experience, or I would refer as context. The idea is to differentiate the two layers of programming. The top layer is the syntax layer, and it should follow the path of natural language which takes in human context (the human interface). The lower layer is the rigorous part (but still human readable), mostly context free and emphasizes the machine (optimization) interface. Just like we get the daily work done, we use the top layer to express and think, then verify at the lower layer. Forth is a great language, totally fits the concept. But the article is trying to show that we can program in any language with vocabulary leading style (with the help of meta-layer perhaps) in which you do not lose any benefits of language (if you consider them benefits).
- 4ydx 12y agoHow precisely do you expect to be able to map from something imprecise to something precise? The idea of giving the author complete control over the higher level terms they use sounds like a nightmare in the making honestly :) Being able to understand somebody elses code requires that it be written in a way that is at least familiar in terms of syntax. To say that natural language is "effective" does not, honestly, ring a bell with me. I guess we think about effective on totally different terms. Math is effective. Spoken language is not in my opinion. On a general level this sounds more like somebody feeling frustrated that the computer didn't "understand them".
- hzhou321 12y agoHow do you map from something imprecise to something precise in daily life? For example, you tell the kids "go to school", very vague (walk or bus or wait for you to drive), and each detailed steps require even detailed actions (composability). So how did you reach the efficiency with only "go to school"? First of all, we have mechanisms to establish conventions -- which is the user maintainable dictionary I was referring to. Second, we have direct feed back -- if the kids didn't move or the school called, we know something went wrong, (then we strengthen or correct the conventions). In the two layer programming structure, both layers are within programmer's access. Programmer try to work at the top layer as we do in our daily life, but we will get signals from lower level compiler, and we can verify the lower level code directly (which is as readable as what you do today -- you are only working at the lower level language today). It is not one or the other, that is how we manage the daily efficiency. Are you a mathematician? How much math do you speak anyway? Even my fellow mathematician convey most of the mathematical meaning in English. Can you imagine mathematicians only write in math (as today's programmer do)? Theorem, at least from the math books on my shelf, are mostly composed in English (more words than math). And even in pure math equations, we make up new symbols (with special meanings under special context, not just operators, what do you think the concept of algebra is) all the time, which is along the same line of vocabulary based programming. If you think I am saying that math can work with English only, then you misunderstood me.
- 4ydx 12y agoOf course math works across all languages and I didn't think you were implying that, but using a word in a mathematical context carries a lot of precision with it. It isn't simply a layman's usage. The words don't make the description work, but the math behind it does. This applies to programming languages as well.
- scotty79 12y ago> Natural language is imprecise and vague. And it is relying on a lot of your experience. Yes. That's because if you need to be precise you remove yourself farther and farther from natural language towards professional jargon where words have more specified meanings and towards math and computer languages that you can call precise. > The top layer is the syntax layer, and it should follow the path of natural language which takes in human context (the human interface). It would be nice to keep at least some part familiar but more often than not you can't because some 'top layer' constructs you need to express have very cumbersome expression, if any, in natural language. For example natural languages lacks constructs for deep composability or indirection. Natural language is perfectly fine in daily work, like deciding what's for dinner, but trying to explain any non-trivial concept with natural language quickly becomes too cumbersome and person trying to convey the message moves onto more expressive and precise tools like math or drawings or pseudocode. Please look at how theorems and proofs looked before invention of math symbolism. That's natural language stretched to extremes. Also please read any modern code of law. That's what we get when people go out of their way to express concepts in natural language instead of creating some explicit domain symbolism. I'll take math or even cobol any day instead of that.
- techbio 12y agoPara 33 should read "functions" in the plural?
- hzhou321 12y ago"For function(s), we need worry about ..." ? Corrected.
- brudgers 12y agoAs a card carrying condescending know it all, I am obligated to point out that Lisp allows extending the programming language with new vocabulary easily and with new syntax relatively easily. Whew...now that that's out of the way, I can get on with what I really wanted to say. From a natural language standpoint, I have found J [1] particularly interesting. Kenneth "not Alan" Iverson [2] extended and refined the the ideas he developed for APL [3] and mapped it onto the ASCII character set. Like APL, J is built on a grammar of nouns, verbs, adverbs, etc. with the idea that the labels for the language's parts map reasonably to their counterparts in natural language (for some definition of "reasonably"). One of the great things about J is it's documentation. Originally a commercial product, J's documentation includes great tutorials and primers that someone was paid to write (as opposed to produced instead of doing the coding they love). [1]: http://www.jsoftware.com/ http://www.jsoftware.com/ [2]: https://en.wikipedia.org/wiki/Kenneth_E._Iverson https://en.wikipedia.org/wiki/Kenneth_E._Iverson [3]: https://en.wikipedia.org/wiki/APL_%28programming_language%29 https://en.wikipedia.org/wiki/APL_%28programming_language%29
- vorg 12y agoWhen I tried out both J and APL a while back, I found the J symbols to be unintuitive compared to APL's, mainly because APL had balanced parens, brackets, and curlies, whereas J didn't but instead used them unpaired as part of multi-symbol operators. APL operators were always single-symbol which also helped readability compared to J, but of course entering APL symbols was far more difficult than J's ASCII ones. One of my favorite possibilities for a syntax that's terse but still readable as well as easily enterable is one using Chinese/Japanese Kanji. IME's like Cangjie or Wubizixing mean they can be entered easily without using unintuitive operators like (= or /] or {%
- brudgers 12y agoI think learning J is a project that will take more than 24 hours, not something that where naive intuition is going to produce significant progress...the documentation implies as much. It's Emacs not gedit. Then again, I don't think any powerful programming language is going to be easy to learn. Turing machines or lambda calculus, take your pick, are hard concepts when it comes to navigating all their implications. That's what allows them to capture all of computation. Python or Ruby or whatever may push the point where the power to complexity curve goes asymptoticly vertical a bit to the right, but it's still there and steep as a wall. J doesn't pretend to be English. It tries however to have a logical grammar that reflects the grammar of natural language rather than a vocabulary that does.
- belovedeagle 12y agoThis is complete nonsense. After finally making it to the end of the article, it became clear that the author is simply advocating for a top-down programming style. However, this fact is completely hidden by some very fundamental misunderstandings about how any of the referenced languages work. "Fold" is not a "keyword" in Haskell, not by a long shot. The author doesn't seem to understand how the programmer can himself implement functions such as fold.
- hzhou321 12y agoThanks for reading to the end; I appreciate it. I quoted "fold" because it is essentially a vocabulary word (which is the whole reason I quote it), it only feels like a language keyword because it is designed and programmer typically learned it.
- belovedeagle 12y agoSorry, still nonsense. All functions are "designed" and "learned"—that's the whole point of a function, a unit of code reuse. You're positing magic, uh, how did you call them... "elite programmers" in the sky who bestow upon us all the magic functions. Now, I understand that when you first see packages such as Kmett's lens package, it can certainly feel that way, but there's no real truth to the idea. There's no difference between what you call "vocabulary" and library-supplied functions like fold. > A vocabulary based programming need give ordinary user the ability to create new words and the ability to expand its usage That's just called implementing a new function, or maybe writing a new API.
- bendersalt 12y agoAnecdotal Comment: No matter how magical someone has made a library, I have never worked on a project that did not find an oversight, or some weird edge case where the abstraction dies in a horrible fire and you end up having to understand all the of the libraries internals anyway. Its just kind of the nature of programming in the end. I'd much rather understand how to write a fold than to "know what it is." There is always something that just has to be done "the hard way."
- TuringTest 12y agoI'm a few days late to the party but still wanted to add my comment. Contrarily to others in this thread, I get what the author is trying to do with the MyDef library and I share that goal myself. As I see it, such lightweight scripting (meta-)layer is not intended to replace a programming language in full. Instead, it acts as a general-purpose template language - a wrapper were you put in the ''easy'' parts of the program, which can then be written without the attention to detail that a true programming language forces upon you. As others have said, the hard parts of a program still benefit from a non-ambiguous, utterly detailed syntax of a full PL. A templating meta-layer is not a good fit for those, that's why you should use them in combination - use something like MyData to write the "general picture" flow, dive in into the hard language to build the details. Then you get the best of both worlds. It's no different to what it's commonly done with template languages for the web or user interfaces, expect that this library seems to be extendable to other business domains.
- hzhou321 12y agoThanks a lot for understanding. I am puzzled why most readers see MyDef as another language or library. Let's use Javascript for example, Coffee script or other language force you to re-learn and write in the new language, but with MyDef, we still write JavaScript and use the same pattern we acquired. It is not about re-learn, rather it is about growing. For example, `document.getElementById('name')`, which you learned the first time starting Javascript, you don't have to relearn; but in the meantime you don't want to write/think in so much detail, so with MyDef, you start write `$(id:name)` (one of the many ways you can come up). Here, you did not learn the new word, you grew it. Then, you start write `$(type:name)`, `$(value:name)`, `$(show:name)`, `$(hide:name)`, or `$(select:#name)`. Just like the word we use in daily life, when we say "go to school", we understand what we mean and (more importantly) we immediately get feedback on whether the reality (the kids walks to school bus) meets our expectation. In MyDef, we understand where these idioms are defined and the translated output is right there for us to verify (which is not much different from markdown). In comparison, when we use `$("#name)`, we only can learn the meaning; if we guess, there is nowhere to directly get feedback -- which forms a disconnect from your old acquired knowledge. Similar with most library and framework, you are disconnected from you old experience (I don't mean abandon, but a discontinuity) and re-learn a new set. MyDef is about grow, not re-learn, there isn't any barrier.