101–110 of 120 posts
Earlier quoted context omitted.
Please don't write "begs the question" when you mean "raises the question". http://begthequestion.info/
But if we know what he meant why does this matter? Language exists to convey meaning, and I think we all understood what he meant, so I don't see the problem here.
Earlier quoted context omitted.
Please don't write "begs the question" when you mean "raises the question". http://begthequestion.info/
But if we know what he meant why does this matter? Language exists to convey meaning, and I think we all understood what he meant, so I don't see the problem here.
Earlier quoted context omitted.
Please don't write "begs the question" when you mean "raises the question". http://begthequestion.info/
But if we know what he meant why does this matter? Language exists to convey meaning, and I think we all understood what he meant, so I don't see the problem here.
I often don't know what the user meant. It makes for extra work to stop and think what possible meaning was intended. Some thing when people use "less" for "fewer". I have to think, did they mean "lesser" or "fewer"?
Earlier quoted context omitted.
"Don't have the editor/IDE insert the parens/brackets. Have it check them for you. Emacs can do a momentary highlight of the opening paren/bracket whenever you type the close of the pair." NO. Sorry but you're doing it wrong. Relying on the editor to highlight parentheses is a highly inefficient and error-prone way to work. It's distracting, it wastes mental cycles and inhibits flow. The correct way is to configure e…
NO. Sorry but you're doing it wrong. Relying on the editor to highlight parentheses is a highly inefficient and error-prone way to work. It's distracting, it wastes mental cycles and inhibits flow. The correct way is to configure emacs so that when you press a certain key (in my case, right shift because I configured my keyboard so I can activate left shift with my thumb), emacs inserts "()" and puts the cursor in th…
Incidentally, I use emacs and Lisp every day.
The argument that XML can have various different structures for storing a person's name, while JSON provides one simple solution, doesn't fly. You could run into something like { "Person": { "property": { "type": "first-name", "value": "John" }, "property": { "type": "last-name", "value": "Smith" } } } This begs the question, "Why would you do something that convoluted?" Well, you can ask the same of the XML examples…
Please don't write "begs the question" when you mean "raises the question". http://begthequestion.info/
Conversions between XML and JSON can be a challenge (defining namespaces,etc.). The Google Data API handles this very well. Check out their nice side-by-side example: http://code.google.com/apis/gdata/docs/json.html
Earlier quoted context omitted.
Not enough data types in CL or Scheme's reader (Clojure wins here) and no standard between the lisps. But, there was something Lisp did right that no other mainstream scripting language has - it separated the reader and the evaluator. You can eval Perl or Ruby or Python, but not securely read it. This goes for Javascript too - you can eval a JSON, but you'd be an idiot.
> Not enough data types in CL [reader] Huh? CL's reader handles structs, hashes, and vectors in addition to strings, lists, atoms (with packages), lots of number formats (including Roman), and the ability to express AGs, not just trees (yes, cyclic too). Plus some other things that I forget. (Arrays?) What else do you want to read? No matter - CL's reader is programmable....
It's probably bad you can express cyclic graphs. That means you'll have to watch for denial-of-service attacks phrased as cyclic data.
Programmable reader isn't the point. That gets you back into defining your own syntax. The point is to have a standard.
Earlier quoted context omitted.
Sorry we were late to the party, guys, we just got so wrapped up in writing software that people actually use.
The Lisp programmers were writing airline reservation systems... the other programmers were writing board-game generators.
Earlier quoted context omitted.
Language designers take note: there is tremendous utility in making entities in your language isomorphic to entities expressed in previous languages. I am actually using such isomorphisms in my current porting project. I'm literally getting a couple of orders of magnitude more productivity out of this over porting by hand. Also note: less syntax makes this easier.
I recently wrote a program to do Threefish encryption which I deliberately wrote to look as much like the mathematical notation in the spec as possible. That made things so much easier that it was almost ridiculous, even if it made the resulting program very peculiar-looking.
You'll be especially enamored of their 200-line TCP/IP implementation, introduced on p17 and reproduced with documentation starting on p44. It's implemented as a grammar in their meta-language that parses the ASCII-art diagrams in the RFCs and executes them.
Earlier quoted context omitted.
It's true that s-expressions don't give you a literal syntax for hashmaps or arrays, but note that some lisps (e.g. Clojure) do support these natively … and in a syntax that's better than JSON since you don't have to type all those annoying commas ;-)
You know I never quite got that comma thing. For instance in python, the only reason it is necessary is because {"foo": "bar" "baz", 'k2':'v2'} is the same as {'foo':'barbaz', 'k2':'v2'}. Getting rid of auto-concatination allows for {'foo':'barbaz' 'k2':'v2'} which is pretty easy to parse base on tokens and ':'. It also eliminates a pretty common bug, in which there is kv pair per line, and the line ends with ',', ex…
{ 'foo':'barbaz'
, 'k2':'v2'
}