873 karma · joined November 23, 2009
email - srikumarks @t gmail d.t com blog - http://sriku.org
Work area (former) - Automatic video editing tools (algorithms, fx, rendering)
Ph.D. - Understanding Indian classical music through computer synthesis.
Banner - helping create, communicate, learn and understand Indian classical music through technology.
another possible answer - Erlang.
While the look of the condition/restart scheme may be very different, such a condition/restart protocol can be implemented as message passing with a known global "condition handler" process I think.
A "raise" function can be implemented as a message-send to the condition handler process followed by an immediate wait-for-response. The handler process may terminate the raising process, replace its value with something, etc. depending on the installed handlers.
While it isn't a mainstream language by any means, a scheme dialect called muSE [1] that I developed for writing logic for automatic music video construction supports such resumes and retries. [2]
[1] https://code.google.com/p/muvee-symbolic-expressions/
[2] https://code.google.com/p/muvee-symbolic-expressions/wiki/Ex...
(Apologies for shameless plug)
-- edit: I just saw that the clojure library "ribol" has an api design similar to muSE's in principle. A couple of design comments though -
1. The "on blah blah" is too much syntax for this. It prevents direct sharing of handlers between similar situations. Function argument pattern matching ought to be enough.
2. The retry options mechanism is somewhat limited - the options seem to apply only at the raise point itself (disclaimer: I've only had a quick glance at ribol). It is more useful to have multiple retry options at different scopes so you can partially unwind, try something, if that doesn't work unwind some more (perhaps involving cleanup), try something else, etc.
I think muSE's design is better on both these fronts.
I also recommend a Mozart/Oz style interactive search tree explorer made by a student [2] .. built on fd.js.
[1] https://github.com/srikumarks/fd.js [2] http://minhtule.github.io/Search-Tree-Visualization/
Then again, we can make the same argument about utility providers. If a private electricity provider asks for a share of the payment of the video being served using the electricity that they supply, where should this stop?
I'm beginning to think that we'll eventually end ip with a middle ground where some usages of communication infrastructure are regulated (such as emergency response) and some others are in the market.
While folks are arguing about whether such a breakage of net neutrality will be bad for consumers, are there at least any reasonable market simulations that point out good/bad out omes for each party involved, includin consumers?
At least, I'm not rational enough to reason identically whether I've been primed with death or just the risk of death. So I think this would be a useful exercise for me (and those like me).
Today's "normal pc" compute power is inadequate for 4k video ... Unless you plug in a decent gpu and your machine includes a decent bandwidth to that gpu.
Given that parents have always wanted to film thir kids at the highest quality they can afford, where do you thnk this trend might take us industry wise?
Edit: if i cannot type out this post error free, mobiles phons suck as PC replacements ;)
I find the "right tool for the job" to be a total conversation stopper. It stops the bikeshedding type arguments, true, but it also stops potentially illuminating comparisons. Can we, as a community, agree to stop bringing it up in comparison arguments?
Imagine a new programming language and system being presented in an article. It is healthy and useful for the article to say "We designed system X so it is easier to express Y kind of programs. A, B, C are the complications encountered when doing the same with systems I, J, K." rather than "We designed system X to express Y kind of programs. We like it, but if you don't, use the right tool for your job."
While many of us are polyglots, we do seek to minimize the number of parts when building a system, so such comparisons are often meaningful at some level.
I was given the standard cautionary rules by many, but I have to say that in all that commuting, I never felt threatened even once. Normal folks commuted by bus too. However, there were also quite a few who we were "challenged" in various ways, but still had regular jobs at cafes and such. Since my commute schedule was fixed, I became familiar with them and realized that though there wasn't much conversation going on, the regulars were all familiar with each other.
On one occasion, one guy sat next to me and poured his heart out about how his girl friend ditched him years ago and how upset he's been over it for many years. Then, when a stop came, he wordlessly walked out the door and held it open for one of the regulars. This lady had her eyes to the floor the whole time and after she'd got down, said "bye" to him. He returned a "take care", came back to his seat and resumed his story with me.
I admit I was somewhat uneasy on the bus commutes initially, but this incident totally changed me. Actually, I'd never seen this quality of spontaneous kindness among "normal" folks during my stay there .. and was humbled greatly myself.
I always recall this incident (and all those commutes) fondly. I now think most "normal" city folks who curse each other on every misstep, cant tolerate a couple of seconds delay on the road, who never seem to get a thought to extend themselves out of their pitifully small and limited bodies to someone else; as the folks who are "challenged".
So, coming back on topic, at least start a conversation with the regulars on your commutes.
Dealing with process coordination using the resolution of logical variables gave me a refreshing new perspective. The finite domain constraint system design in Oz is an awesome example of this in action.
An interesting tidbit - the Mozart/Oz team invented "pickling" before it caught on with Python.
Though the beginnig was with a blow to the head, I did enjoy the immediacy of BASIC.
(Edit: I had to change the variable to caps)
My mind keeps coming up with generalizations all the time. For example, "the more space you have for your family, the less valuable time together you spend". Needless, useless generalizations like this about just about everything. So I've formed a mental habit of just pausing and asking "really?" .. and soon these just go poof.
In other words, I automatically question the validity of any concept I construct. This way, I'm free to stick to one temporarily and have no qualms about abandoning concepts that aren't valid for me.
The nice thing about Derek's post is that he's just posing the question and leaving it to the reader to ruminate on what answer would mean to them. The skill to pick up here is to ask these kinds of questions ... like all the time.
On a similar note, it would really help if the website for the Wolfram Programming Cloud had just one bloody-awesome/blow-me-away example or tutorial that would make it accessible to a lot of capable programmers who may not have used a Mathematica Notebook.
Folks who haven't used Mathematica ever - I recommend the Home Edition. Yes, it is worth paying for it!
With that perspective, we can ask what representations of a formal system do we find easy to manipulate in ways that produce results that are significant for us (in a specific problem context).
A visual representation would certainly be a better match for a spatial problem domain (Sutherland's work, for example). Similarly, an audio representation can work well for an audio domain (ex: beardyman's realtime performance system he presents in his ted talk). Likewise, I'm quite sure a system for exploring cuisine art would match a "smell representation".
The notion of a "universal turing machine" guarantees that all of these representations can be mapped to that of a symbol stream. That is a mathematical result, but which representations appeal to humans involved in various kinds of work is not a mathematical question - it is a HCI question.
If you have an idea along the way that sounds interesting, just ask yourself "what problem would be solved if I work on this?" ... and pretty soon you'll gain tremendous clarity, often discarding many useless ideas very early on.
This shift has perhaps been the biggest learning of my phd years. Compared to the effect this has on me, I find the "agile methodologies" etc tips relatively useless.
Though the naming seems to give documentation benefits, naming variables and functions is one of the hardest things we do as coders. The practice of properly factoring your system comes more out thinking in terms of values rather than steps. When you think "what value am I computing?", you not only write short sweet functions naturally, but also build more robust code in the process.
And yes functions are values as well.
I don't code much lisp these days (though getting into clojurescript a bit now), but when I used to, the cycle went pretty much like this -
1. Express what you want to express as an s-expression, capturing known structures in the simplest way I can think of.
2. Figure out which aspects can be "functions" straight forwardly and which are macros and implement them.
3. Test and iterate a bit till I like the way domain elements are composing and the way the composition looks in code. Try to reduce the required concepts in each iteration.
4. Document the relationships that have emerged from this process so others can understand it.
5. Usually I'm done, but sometimes (the few) users of my "api" come back with questions, based on which I iterate a bit more.
I've mostly followed this in building the "editing style specification language"[1] part of the product "muvee Reveal" (an automatic video editor)[2], built in a custom scheme dialect called "muSE"[3]. (Full disclosure: I've happily worked for muvee Technologies from 2002 to 2011.)
Btw - most discussion on macros and lisp seem to first assume that there two things - a) functions and b) macros. There are more, depending on the kind of lisp system you're working with.
You could form a taxonomy of sorts based on whether argument forms are evaluated and whether the result form is evaluated -
1. Argument forms are evaluated before "apply", result is a value (i.e. not evaluated). => Function
2. Argument forms are unevaluated before "apply", result is code (i.e. is evaluated). => Traditional macro
3. Argument forms are evaluated before "apply", result is code (i.e. is evaluated).
4. Argument forms are unevaluated before "apply", result is a value. => Traditional macro (depending on system)
In the course of using the domain modeling approach above, I've written stuff like functions that create one or more macros, macros that evaluate to function values (not s-expressions) and such stuff that might be considered an "abomination" by the OP ... but in the context of the domain, the concepts are usually clear enough to be used without major issues.
[1]: https://code.google.com/p/muvee-style-authoring/ [2]: http://www.muvee.com/en/products/reveal [3]: https://code.google.com/p/muvee-symbolic-expressions/
Intuitive = FamiliarIt does looks like the incentives are aligned in the direction laid out in the article. Companies can better control their user experience on mobile through uncrawlable apps. You hear "mobile first" a lot these days. These things are with users for longer than desktops/laptops. Anyone can carve out a section of the web where content gets created, but cannot be linked to.
The two gaps I see are -
a) mobile devices are good for _consumption_, but are not yet on par with *tops for _creation_, and
b) reputation systems on the internet (currently) require linking, and there's nothing to replace that in the mobile world.
Nothing wrong with a "never ending story" and there's a considerable clientele for that in older media too. The LoTR trilogies also have that similar feeling for me - I'm left with a bit of a craving after watching just one.
What is, perhaps, new is the immediacy of the never-endingness. One phone-screenful is all you get at a time.
The closest I've come is to use org-mode in emacs with the foldout package enabled [1]. This works well actually and I even wrote my thesis this way (which I can't do using Workflowy btw ;) .. but you got to manage the syncing etc yourself.
It is valid to argue that a tree structure is not the ideal mind-map, but the speed advantage of editing a tree structure way more than compensates for a more complex graph structure ... and you can always hyperlink.
[1]: http://lists.gnu.org/archive/html/emacs-orgmode/2007-10/msg0...
The real downside for me is that my notes are on their server. I really hate that. So .. I keep getting back to org mode .. which isn't available everywhere.
The kind of response you're talking about is not enough. This kind of speed of response in addressing the issue must have been given when the OP filed the report, not only when he decided to go public with it.
Given that the technology required for evernote isn't advanced or cutting edge or experimental researchy stuff, I find the bug rate appalling.