jamii

40 ms·

361.
by jamii 12y ago
Version numbers attempt to compress an awful lot of information into one totally ordered number. I'm really looking forward to seeing the approach in https://thestrangeloop.com/sessions/towards-annex-a-fact-bas...
362.
by jamii 12y ago
We were also taught prolog, asm and (weirdly) pascal. We didn't manage to actually produce anything interesting in any of those. The Access CRUD apps and the little VB6 games were the only working software that came out of that two yea
363.
by jamii 12y ago
UK schools teach 15-16 year old kids to build simple CRUD apps in MS Access. So the basics are definitely somewhat approachable.
364.
by jamii 12y ago
> I'm interested to see your methodology and how you handled researcher bias :) Oh we totally didn't :) Our user testing is very much at the anecdotal phase so far. Fwiw though, the researcher bias was in the other direction -
365.
by jamii 12y ago
I think you misunderstood my point somewhat. I'm not saying that Excel solved the version control problem - far from it. Manual version control by emailing copies of spreadsheets was identified as a major cause of errors in various stu
366.
by jamii 12y ago
> ...precisely the kind of languages that many programmers will claim are "too hard" Your argument seems to be that Prolog and Haskell are high-level and Prolog and Haskell are complicated and hard to learn. I agree up to that
367.
by jamii 12y ago
I think he is arguing that higher-order functions are more difficult to learn/use than first-order functions because they require higher-order reasoning. That's not to say that they aren't useful or that beginners can't
368.
by jamii 12y ago
I made a long list of some of the difficulties one encounters in trying to use industrial-grade tools to solve home-repair-grade problems: http://www.lighttable.com/2014/05/16/pain-we-forgot/ It's n
369.
by jamii 12y ago
Well said. That's the distinction that causes so much tension between programmers and users - it's why we have this rift between unixy software which is wonderfully composable but infuriating to use and windows/mac software w
370.
by jamii 12y ago
The key quote from the OP is "Complexity is cumulative cognitive load". From the point of view of an end-user, using Outlook is vastly simpler than learning to program in order to cobble together their own solution out of command-
371.
by jamii 12y ago
> However, it's not clear they are arguing for the same kind of "simplicity" than Jonathan Edwards. Jonathan Edwards: "Complexity is cumulative cognitive load. We should measure complexity as the cumulative effort to
372.
by jamii 12y ago
What most people seem to be arguing is either that the people currently using Excel and VB6 should suck it up and learn a real language or that they shouldn't be programming at all (I'm not saying you are, but this is the general
373.
by jamii 12y ago
Oh, I read it in context with: > We should concentrate on their modest but ubiquitous needs rather than the high-end specialized problems addressed by most R&D A lot of the things we do in programming give us power and flexibility at
374.
by jamii 12y ago
> But every attempt to create a completely general purpose language that anyone can use to do anything has failed Excel is used by millions of people and powers large swathes of the worlds economy. VB6 is still in use today and powers mu
375.
by jamii 12y ago
The lesson from both of these is that performance doesn't magically come from simplicity but it is enabled by simplicity. A complex system is always hard to optimise. A simple system may be easy to optimise. Building simple systems
376.
by jamii 12y ago
> That's /why/ we have our programs and processes divided into boxes http://db.cs.berkeley.edu/papers/cidr11-bloom.pdf - by unboxing distributed systems we can statically predict whether a given progr
377.
by jamii 12y ago
> ...they focus on ease of learning as the be-all and end-all of usability. I see people jump to this conclusion on pretty much every post of this type. In this case it is clear from the authors work ( http://www.subtext-lang.o
378.
by jamii 12y ago
Thats true, but there is still plenty of incidental complexity. Poor layout languages with no composition, stateful manipulation of the ui, no way to express components. Tools like React.js and Apple's Auto Layout show that much of thi
379.
by jamii 12y ago
Programming Languages
380.
by jamii 12y ago
Some demonstrations of how simplicity can be pursued: The Viewpoint Research Institute is trying to build an entire computing stack in 20kloc - http://www.vpri.org/pdf/tr2010004_steps10.pdf The Berkeley Order-Of-Magnit
381.
by jamii 12y ago
I believe Strilanc is talking about dimensions in phase space rather than in physical space. If you plot all the possible configurations of those points on a graph, that graph would have 30 dimensions. Whether or not that is a valid point i
382.
by jamii 12y ago
I am a big fan of http://www.amazon.com/Probability-Computing-Randomized-Algor... . Every time it teaches a new chunk of theory it motivates and grounds it in some algorithmic application.
383.
by jamii 12y ago
It is effectively just a form of magic bracket that never needs to be escaped.
384.
by jamii 12y ago
The same thing is true for lisp. Writing a tree-based interaction mode like paredit that doesn't die horribly on malformed text is a non-trivial problem ( http://mumble.net/~campbell/emacs/paredit.el - 2625 li
385.
by jamii 12y ago
So if I understand correctly, you would arrive at a symbolic expression like (->> (map f) (map g) x) and directly rewrite it to (->> (map (f . g)) x), rather than having to manipulate the resulting data-structures?
386.
by jamii 12y ago
They are more comparable to Oleg's Enumerators ( http://okmij.org/ftp/Haskell/Iteratee/describe.pdf ), in that you compose a series of computations and then push data through them. The type signature is si
387.
Imperative thinking and the making of sandwiches(scattered-thoughts.net)
2 points by jamii 12y ago|0 comments
388.
by jamii 12y ago
http://www.web2py.com/ https://www.youtube.com/watch?v=k7lE-R16H4c
389.
by jamii 12y ago
Currying with map/reduce/filter can be hard to read, but list comprehensions are pretty nice: (defn get-imcomplete-task-summaries [membername] (.then (fetch-data) (fn [data] (sort-by :time
390.
by jamii 12y ago
To phrase it better - I don't have any idea whether the UX skills of the team match up with the technical skills. I wasn't criticising anything in particular, just noting a lack of knowledge on my part.

More ›