Syntax at the "what character do we use to mean X, what characters do we use to delimit blocks" level is such a trivial thing that choosing your language based on it is pretty ridiculous. Or, to quote a PL researcher of my acquaintance, "Syntax arguments are lame."
The notion that there is such a thing as a "functional programming syntax" doesn't make sense to me. The syntax Church and the original researchers gave the lambda calculus didn't have parentheses except for the same purposes C uses them. Same goes for ML and Haskell, two of the three most well-known functional programming languages around. The third, Scheme, is the most debatable of the three as to whether it's functional or not, and the parentheses are there for reasons that have nothing to do with being a functional language -- they were orgininally there because MacCarthy was going to add them later and they were kept because people by and large liked the advantages of macros and were willing to represent parse trees explicitly so they could have them without contortions.
Operator overloading is a far cry from what's possible when it comes to building new language semantics. Syntactic abstraction is where it's at, as the C++ people have learned with template metaprogramming. Unfortunately metaprogramming in C++ is the result of an accident, and for that reason it's really really unpleasant in C++; if they'd been paying attention they either would have made templates like ML's functors (and made the types work out with separate compilation) or made them like Scheme or Common Lisp's macros (and made it a million times easier to make metaprograms that do useful things).
More a CiteSeer replacement, I think. The idea behind CiteSeer is that in academic computer science, most researchers (and most conferences and journals) make their papers available for free on the web, but there are so many of them and so many places to look that actually finding a paper that's relevant to your research is really hard. The CiteSeer folks realized that web spiders could do a very good job of indexing all those papers and putting them in a searchable form and that it was much cheaper (computationally, financially, effort-wise) than traditional approaches like Lexis/Nexis. CiteSeer has been available for free for years, and Google Scholar seems like it's just a much better interface to the same idea, so I don't see any reason why they'd turn it into a pay service.
I'd leave scheme and lisp and other languages out of the picture for a while. They have nice features, but it takes a lot more than just casual reading to understand a code snippet
So
class Hello {
public static void main(String [] args) {
System.out.println("Hello world!");
} }
is lucid, but
"Hello world!"
isn't? Seriously, the whole point of teaching Scheme in intro classes is that Scheme (and particularly DrScheme) is very good at not making people type in mystical invocations they don't understand just to do basic things, and Java is notoriously horrible about that.
Not true, It has been proven, at least if by "sorting" we mean "comparison sorting" where we only know how to compare two objects (the statement is provably false by the existence of faster algorithms for versions of the problem where we get more information). This is a fundamental result of computer science and is a typical (and important!) topic of study in algorithms classes. See PlanetMath's article on the subject for a proof.
(Incidentally, I tried to track down a citation for the origin of the proof but failed. Anybody know to whom this result is due?)
I remember Andy McKay working with Keith on this at Rice in the summer of '98. Do you happen to know why the research has been going as slowly as it has? Are they just not very interested in pushing it, or are people just busy with cooler things, or what?
By the way, nice to see you around. What are you up to these days? Send me an email sometime. My alumni address will still work.
I'm not sure what implementing a brand-new language would help with points one and four. As for points two and three, if you think Haskell's syntax is unclear or Common Lisp's underlying model isn't flexible, you're clearly insane.:P
Don't be silly, the statement you quote is obviously true. Turing machines rely on the fact that they have infinite tape. If you only have 17 zillion slots on your tape, you're just a DFA in a fancy dress because there are finitely many states you can possibly be in.
Actually, compilation is often lossy. For instance, it's not uncommon for a compiler to translate for loops to while loops or boolean relational operators into if statements (not in C or C++, maybe, but in other langauges). Once the compiler does that, there's no way of determining which fragment was in the original code.
... yeah... compilers do little rewriting tricks that preserve semantics while improving runtime characteristics all the time, and converting recursion to iteration is definitely a good trick in that category. That's the essence of code optimization.
Python's lambda (actually Lisp's lambda incorporated into python 40 years later) is exactly the same mechanism, yes. A big difference is that F# is statically typed whereas Python is not.
"The whitespace issue isn't a big deal (I use a good text editor), but I've spent too long debugging make files to be comfortable with invisible-yet-syntactically-significant characters. Python does have the advantage that it doesn't dictate how much whitespace to use, but I'm still leery of issues with copying and pasting code from a web browser or a newsreader."
Actually that doesn't work in ML. It works in Haskell, though.
ML only allows a variable to have a concrete type -- int, string, bool, something like that -- or an abstract type like alpha or beta that's a variable that can be supplied any type. So ML would actually see fn (x,y) => x+y and type it unambiguously as an int * int -> int.
About strings: Graham is probably referring to Haskell's way of doing strings: "Hello" is just another notation for ['H','e','l','l','o'] and can be used as such (you can take the head and the tail of a string, or pass it to map or fold or whatever). However, there's no reason you can't still write a regular-expression library or a string-formatting library, or any other library you want that works on strings.
I think you faild to recognize the parent post as one from a Programming Languages Weenie. As I, too, am a Programming Languages Weenie, I'll attempt to try to bridge the language gap here.
That's one definition of generics, but hardly the only one in use in the programming world. "Polymorphism" is one of those fantastic words that has had so many meanings attached to it that it no longer means anything useful without further qualification.
"Generics" in this case means "type abstraction," which has been well-known to type theorists (the people who invent advanced type systems for programming languages and prove things about them) for some time. Type abstraction refers to the ability for a function to be "abstracted over types" by making the type depend on some input type in the same way normal functions are abstracted over values by making the function's return value depend on input values. There's a huge body of literature on this topic.
Templates in C++ can do a little more than boring old macros these days, too.
Maybe more than boring old macros, but not more than exciting new macros! Seriously, if by "macros" you mean "C preprocessor macros" then you're right, but to a real Programming Languages Weenie the term "macro" means something much cooler. Some languages, most notably Common Lisp and Scheme, allow source rewriting in a much more powerful and less gawdawful way. The standard example of how powerful true macros can be is that in Lisp, you can implement an entire object-oriented programming system that appears every bit as built-in as Java's object-oriented programming system using just a user-written library of functions and macros. New class syntax, appropriate error messages, everything.
It turns out that templates are kind of a 'Vogon liver' phenomenon: in the same way Vogons had a mutated liver that evolved to serve brain-like capacities, C++ templates are a bad solution to the problem of type abstraction that mutated and became a bad macro system. Seriously, download a copy of DrScheme, read up in the help files about 'syntax-case', and watch yourself be amazed as you realize the power of macros done right.
Maybe... by getting out of the business of giving copies of their data to strangers with no strings attached and then getting upset when those strangers do what they please with it?
If you don't like strangers using your data, don't give it away. And certainly don't give it away to them, demand they use it in one particular way, and then get mad when they also use it in another way you don't like. It's as simple as that.
The article is actually pretty muddled about why the companies are suing Gator: is it because Gator infringes on their copyrights by altering web pages? Because it pops up advertisements? Because it misleads people into thinking the advertisements come from the web page they're visiting rather than a third-party application?
The argument about Gator being misleading I buy. I don't use gator, nor have I ever, but if it's true that they're using deceptive practices to get themselves installed on people's computers and then silently altering other web pages, that's bad. But if that's not the case, well, the law should uphold my right to use the data web servers provide me in whatever way I see fit. I have no contract with anyone that says that if I download a file from their site I will render it in any particular way. As long as I'm aware that Gator is running, arguments that it's violating somebody's copyright are silly. I know it's there, and I can use my data how I want, thank you very much.
1. Test every branch. (This goes hand in hand with making sure you have small enough functions that they only have one or two branches apiece.) Sounds like overkill, but when you're writing a function it's easy, if a little dull, to write test cases for each branch. It's much harder to fix a bug in a given section of code if all you know is that one of the sixteen functions it calls has a bug, and that bug is in one of seven functions that code calls, etc.
2. Maintain your test suite. Every test we've ever written is still in our test suite, and every time a bug comes in, that bug gets its own set of tests and goes into the suite.
3. Run your test suite regularly.
This works well for a lot of things; the big area in which it doesn't work is very complicated 'mathy' algorithms for which you don't really know what the correct answer ought to be other than by just running your program and seeing what pops out and stochastic algorithms. Stochastic algorithms in particular are a total bitch to test. But, for the other stuff, there's really no better solution.
Slashdot Mirror
More a CiteSeer replacement, I think. The idea behind CiteSeer is that in academic computer science, most researchers (and most conferences and journals) make their papers available for free on the web, but there are so many of them and so many places to look that actually finding a paper that's relevant to your research is really hard. The CiteSeer folks realized that web spiders could do a very good job of indexing all those papers and putting them in a searchable form and that it was much cheaper (computationally, financially, effort-wise) than traditional approaches like Lexis/Nexis. CiteSeer has been available for free for years, and Google Scholar seems like it's just a much better interface to the same idea, so I don't see any reason why they'd turn it into a pay service.
Sois lucid, butisn't? Seriously, the whole point of teaching Scheme in intro classes is that Scheme (and particularly DrScheme) is very good at not making people type in mystical invocations they don't understand just to do basic things, and Java is notoriously horrible about that.
Is there any way end users can fight back against people like this?
...
You could've started by not advertising their product for free on the front page of Slashdot
Not true, It has been proven, at least if by "sorting" we mean "comparison sorting" where we only know how to compare two objects (the statement is provably false by the existence of faster algorithms for versions of the problem where we get more information). This is a fundamental result of computer science and is a typical (and important!) topic of study in algorithms classes. See PlanetMath's article on the subject for a proof.
(Incidentally, I tried to track down a citation for the origin of the proof but failed. Anybody know to whom this result is due?)
I remember Andy McKay working with Keith on this at Rice in the summer of '98. Do you happen to know why the research has been going as slowly as it has? Are they just not very interested in pushing it, or are people just busy with cooler things, or what?
By the way, nice to see you around. What are you up to these days? Send me an email sometime. My alumni address will still work.
I'm not sure what implementing a brand-new language would help with points one and four. As for points two and three, if you think Haskell's syntax is unclear or Common Lisp's underlying model isn't flexible, you're clearly insane. :P
Don't be silly, the statement you quote is obviously true. Turing machines rely on the fact that they have infinite tape. If you only have 17 zillion slots on your tape, you're just a DFA in a fancy dress because there are finitely many states you can possibly be in.
Actually, compilation is often lossy. For instance, it's not uncommon for a compiler to translate for loops to while loops or boolean relational operators into if statements (not in C or C++, maybe, but in other langauges). Once the compiler does that, there's no way of determining which fragment was in the original code.
... yeah ... compilers do little rewriting tricks that preserve semantics while improving runtime characteristics all the time, and converting recursion to iteration is definitely a good trick in that category. That's the essence of code optimization.
You could probably guess. Worst case, the decompiled version is refactored to be cleaner than the original, which doesn't sound all that bad to me. :)
Python's lambda (actually Lisp's lambda incorporated into python 40 years later) is exactly the same mechanism, yes. A big difference is that F# is statically typed whereas Python is not.
in a Java-like language ...
Get over it. He's just trying to convey the idea, not show you a working example of a piece of code in a particular language.
Yes. Read it that way, and then realize it's a totally legitimate request.
From the article:
"The whitespace issue isn't a big deal (I use a good text editor), but I've spent too long debugging make files to be comfortable with invisible-yet-syntactically-significant characters. Python does have the advantage that it doesn't dictate how much whitespace to use, but I'm still leery of issues with copying and pasting code from a web browser or a newsreader."
Actually, the revolution already happened, and nobody noticed.
Actually that doesn't work in ML. It works in Haskell, though.
ML only allows a variable to have a concrete type -- int, string, bool, something like that -- or an abstract type like alpha or beta that's a variable that can be supplied any type. So ML would actually see fn (x,y) => x+y and type it unambiguously as an int * int -> int.
About strings: Graham is probably referring to Haskell's way of doing strings: "Hello" is just another notation for ['H','e','l','l','o'] and can be used as such (you can take the head and the tail of a string, or pass it to map or fold or whatever). However, there's no reason you can't still write a regular-expression library or a string-formatting library, or any other library you want that works on strings.
This is essentially a repost of an exceptionally old story (April 1998).
"Generics" in this case means "type abstraction," which has been well-known to type theorists (the people who invent advanced type systems for programming languages and prove things about them) for some time. Type abstraction refers to the ability for a function to be "abstracted over types" by making the type depend on some input type in the same way normal functions are abstracted over values by making the function's return value depend on input values. There's a huge body of literature on this topic.
Maybe more than boring old macros, but not more than exciting new macros! Seriously, if by "macros" you mean "C preprocessor macros" then you're right, but to a real Programming Languages Weenie the term "macro" means something much cooler. Some languages, most notably Common Lisp and Scheme, allow source rewriting in a much more powerful and less gawdawful way. The standard example of how powerful true macros can be is that in Lisp, you can implement an entire object-oriented programming system that appears every bit as built-in as Java's object-oriented programming system using just a user-written library of functions and macros. New class syntax, appropriate error messages, everything.
It turns out that templates are kind of a 'Vogon liver' phenomenon: in the same way Vogons had a mutated liver that evolved to serve brain-like capacities, C++ templates are a bad solution to the problem of type abstraction that mutated and became a bad macro system. Seriously, download a copy of DrScheme, read up in the help files about 'syntax-case', and watch yourself be amazed as you realize the power of macros done right.
You are incorrect. No one had to say that. HTH.
How can the average webmaster compete with this?
... by getting out of the business of giving copies of their data to strangers with no strings attached and then getting upset when those strangers do what they please with it?
Maybe
If you don't like strangers using your data, don't give it away. And certainly don't give it away to them, demand they use it in one particular way, and then get mad when they also use it in another way you don't like. It's as simple as that.
The article is actually pretty muddled about why the companies are suing Gator: is it because Gator infringes on their copyrights by altering web pages? Because it pops up advertisements? Because it misleads people into thinking the advertisements come from the web page they're visiting rather than a third-party application?
The argument about Gator being misleading I buy. I don't use gator, nor have I ever, but if it's true that they're using deceptive practices to get themselves installed on people's computers and then silently altering other web pages, that's bad. But if that's not the case, well, the law should uphold my right to use the data web servers provide me in whatever way I see fit. I have no contract with anyone that says that if I download a file from their site I will render it in any particular way. As long as I'm aware that Gator is running, arguments that it's violating somebody's copyright are silly. I know it's there, and I can use my data how I want, thank you very much.
Our testing philosophy:
1. Test every branch. (This goes hand in hand with making sure you have small enough functions that they only have one or two branches apiece.) Sounds like overkill, but when you're writing a function it's easy, if a little dull, to write test cases for each branch. It's much harder to fix a bug in a given section of code if all you know is that one of the sixteen functions it calls has a bug, and that bug is in one of seven functions that code calls, etc.
2. Maintain your test suite. Every test we've ever written is still in our test suite, and every time a bug comes in, that bug gets its own set of tests and goes into the suite.
3. Run your test suite regularly.
This works well for a lot of things; the big area in which it doesn't work is very complicated 'mathy' algorithms for which you don't really know what the correct answer ought to be other than by just running your program and seeing what pops out and stochastic algorithms. Stochastic algorithms in particular are a total bitch to test. But, for the other stuff, there's really no better solution.
Neither side was happy about the proposed fees. This announcement just means the stakes have been raised.