mattfenwick

15 ms·

91.
by mattfenwick 13y ago
I'm sorry, I don't think I understand the first 2 sentences of your response. They seem to say that a language and an implementation of that language are the same thing. Am I correct that this is what they mean? (Apologies if som
92.
by mattfenwick 13y ago
The question I always have when someone says "scripting language" is "to what aspect of the language are you referring?" Unfortunately, since AFAICT the term never seems to have been precisely defined (unlike "touc
93.
by mattfenwick 13y ago
This is specifically refuted in the article: > ‘interpreted’ and ‘compiled’ are properties of an implementation
94.
by mattfenwick 13y ago
s/strong/static/
95.
by mattfenwick 13y ago
I'm sorry, I don't follow your point. I was responding to "Evolution is actually quite horrible at engineering. Since it can only hill-climb, we end up with ridiculous designs stuck in local maxima". In my opinion, seve
96.
by mattfenwick 13y ago
What about robustness, adaptability, and learning? Those are qualities of natural life that I find to be extremely well-engineered, and sadly lacking from most (all?) man-made engineering solutions.
97.
by mattfenwick 13y ago
As a Clojure fan, while I appreciate the author's effort, and admit I would do a much worse job, I'm bothered by oversimplifications like these: - "Like all Lisps, it employs a uniform structure" - "All Clojure code
98.
by mattfenwick 13y ago
An interesting read on this topic at http://www.ncbi.nlm.nih.gov/books/NBK9579/ : "When personally identifiable health information, for example, is disclosed to an employer, insurer, or family member, it can r
99.
by mattfenwick 13y ago
But many DSLs can be implemented just as well without the use of macros. This does not refute your point at all -- that macros can be very helpful when implementing DSLs -- just wanted to point out that macros are not a requirement for doin
100.
by mattfenwick 13y ago
Plus, each of those concepts needs a motivation and a context in order for it to stick in their minds.
101.
by mattfenwick 13y ago
I agree with the point, but the argument -- that by arbitrarily ignoring features you come up with a simple core language -- can be applied to Haskell (and pretty much any other language) as well. If you exclude typeclasses, extensions, and
102.
by mattfenwick 13y ago
The article appears to be flamebait. The main point is trivial because it applies to nearly every single technique/tool/language/framework: "X is not perfect. X can/should not be applied in all situations. X must
103.
by mattfenwick 13y ago
Your post reminds me of "The Truth" ( http://en.wikipedia.org/wiki/The_Truth_(novel) ) by Terry Pratchett, in which the characters invent newspapers and deal with these issues. Hilarity ensues.
104.
by mattfenwick 13y ago
What an interesting read. I'm glad there are incredibly smart people like him challenging the programming status quo. My favorite quote: "I always do, not just dynamic stuff when I give a talk, but I do stuff that I'm interac
105.
How journals like Nature, Cell and Science are damaging science(theguardian.com)
5 points by mattfenwick 13y ago|0 comments
106.
Show HN: a JSON validator for tricky corner cases(mattfenwick.github.io)
3 points by mattfenwick 13y ago|0 comments
107.
by mattfenwick 13y ago
Very interesting! I'm curious about the parser's error reporting for malformed input -- does it use Irony's default error reporting, or a custom solution? Are error reports good, bad, or lacking in any way?