Counterpoint: Use any language you want, as long as you keep in mind that you might have to re-write libraries that are available to you in more mainstream languages or use inferior or incomplete alternatives.
On many projects this isn't as much of a problem, but I think it's dangerous to assume that one can easily use 'any language' when developing web-based software.
This is not a counterpoint. Actually, I think it's a point of the article: use any language that better suits your needs. If your web app needs a library that's not available in language A, use language B. Or mix languages -- write feature X in language A, and feature Y in language B. The point is -- you can do whatever you want, as you control the environment, unlike with desktop apps.
Note the 2001. I think his point had more to do with a lack of library's making any powerful language useful. Ruby on rails vs Lisp is not really in favor of lisp, but there is a reason nobody has good C web frameworks.
PS: Which is something to think about, if you are spending as much money on HW as Google it might be a good idea to use C or other fast but hard to write language for some of your core functions.
Well, in 2001 the hot web languages were Perl and PHP and CPAN was already riding high.
I think this argument in some ways hinges on how far from the tree you're falling. If you're doing essentially a variation on a common theme, you'll be the fastest by picking a language where the bulk of the work is already done for you in a variety of reusable modules. It'd have to be a really poor language for its badness to outweigh having most of the work done for you up front.
If, however, you're starting from scratch on something relatively novel, e.g. where Viaweb was in 1996 (and not so much in 2001), then it's true, you should write in the language that fits the bill rather than following the course of momentum.
One proviso I would add there though is that Lisp is in the position of being fairly mature and non-traditional, unlike many flavor-of-the-weeks. There are many pains to be found in using tools which haven't stabilized yet, even if they do have a gee-whiz-bang factor.
As to your postscript, Google does also extensively use C++; I think that's still fairly common in high-performance stuff at the lower levels.
The point of the article is that you can use more powerful, but less used languages when developing web based apps. That hasn't always been feasible when writing software targeting the desktop. Which of course is true, but could have implications of it's own.
"you might have to re-write libraries that are available to you in more mainstream languages or use inferior or incomplete alternatives."
Use (something like) Clojure (or a dot net equivalent)and you can have the best of both - a lisp and lots of libraries. The (minor) price is some grunginess at the interface of the lisp and the libraries, but this is paid only once.
Rewriting libraries can work out really well. As well as a great way to learn, you may often end up with something better than the existing libraries - giving you another edge.
I'm not saying you should write everything yourself, just the bits that matter :)
Startups often don't have the time or resources available to them to re-write everything.
Many open source libraries have been developed by dozens of very smart people over many years, do you really think your solution will be better?
I like the Franz story about NFS. The found it was easier to reimplement NFS from scratch rather than to figure out how to configure the commercial product. Bleeping NFS!
Sometimes it is quicker to write the exact thing you need rather than struggling with something that wants you to think it is the solution to your problem.
Another case in point was the Aha! moment someone described when realized that the Lisp Postgress interface was not going against the library but against the wire protocol itself. Just as easy.
What axod is suggesting is programmers can always write something of their own if there isn't anything they want. They don't have to write everything in the first go. But incrementally. This is how Django and Rails were born. Smart people will join later if they find the base interesting.
That's sort of the point, though, isn't it? You should be concentrating on that stuff, not replicating (or writing from scratch!) N other libraries that you do need, but that aren't the core of your business.
The question to ask isn't whether the solution will be better, but rather whether the differentiation that gives your product value is derived from rewriting libraries.
Libraries tend to be generic, so you can often do better for your specific problem if you are willing to pay the opportunity cost.
Remember that libraries licensed under the GPL don't count, as far as startups go. You'd be surprised at how many of the libraries you use in hacked up code on a daily basis are ones you can't release with a closed source product.
The GPL will also kill your entire family when you're not looking. You should use the much better "jrockway is awesome license", which gives you the freedom to give me all your money. I like that one a lot more.
(Also, what is with all the anti-GPL FUD on this site? Have any of you guys read the license, or do you just like to bash it because you don't like Free Software?)
I'm actually very much for the GPL. Before you criticize people for not reading, you might want to do a bit of reading yourself? My comment history clearly places me in the pro-GPL camp, and there's nothing about my parent comment that suggests that I don't like the GPL.
I like the GPL, and I like SAAS. It's not an "end-run around the GPL" unless you believe that the object of the GPL is to stop people from making money from programming. If, instead, you believe the rightful purpose of the GPL is encouraging people to control the software on their own hardware, then SAAS fits in with that goal quite well. Letting people use my computer with my software on it for some task does not make my computer (or my software) theirs, and it shouldn't.
Does it often happen that higher-level languages have "inferior or incomplete" versions of libraries? My experience has been the exact opposite: in Common Lisp, for example, when there's a native library, it's invariably more flexible and powerful than in any other language I've used.
Does someone know offhand why these HTML generators are macros and not just functions? If I need to RTFSC that's fine, but thought I'd ask in case it's a quick answer.
Just try to imitate the behaviour of this library in your favorite language. I tried in Tcl, simulating macros with upvar, uplevel and even with sugar and is not easy to get the same result.
Judging by the HTML macros he talks about in ANSI Common Lisp, they had to be macros since they output HTML to file using a bunch of FORMAT calls. Since side-effects were involved and the calls had to be evaluated at specific points before and after other such calls, they had to be macros.
Ah ha! Thanks, gms. But this brings us to the question... are we getting anything by using side-effecty print statements to make web pages? I don't see it. I think I vastly prefer building up my markup functionally, and then handing it off to the web server when done. Plus, with the PLT way, you avoid writing macros. And a wise man once wrote, "It's considered to be bad style to use [macros] when they're not necessary." ;)
Okay...I'll leave my "Are we getting anything" question there, but it probably shouldn't be answered. Or at least not here. It's essentially the pure-functional versus side-effect debate. To be fair, you get benefits from both, and both have downsides that the others are better at.
Yes I prefer your approach too (I use a similar approach with the Elisp I use to publish posts on my blog). You are also right that one shouldn't use a macro where a function would do.
When looking at PG's approach in ACL, it's worth remembering that he came up with it more than 10 years ago, and consider it in that context. The surrounding ecosystem for web development was a lot more primitive back then (which serves to highlight how impressive his idea is/was).
But your result is not html. In the Arc library the arguments of the tags, like whitepage are any expression and only tag the stdout (you can redirect the output to another port). For example:
nope, I said that I tried to write the html library in the Tcl programming language using the Tcl comands upvar and uplevel trying to simulate the lisp's macros.
If you are using functions you have to first construct the whole page and only then render it's html.
If you are using macros you may start sending the html parts before the whole page is constructed.
The latter approach is advantageous if a page needs some heavy computations to generate it: with macros the user will start seeing at least something right away; plus, the browser will load CSS faster if you send that part before the computations.
On the other hand if there was an error in the middle of page generation you will not be able to handle it gracefully since you've already send half of the page to the user.
> If you are using functions you have to first construct the whole page and only then render it's html.
Not necessarily... even using functions, you can create a 'lazy node' in the page graph to delay completion of calculation until the final renderer actually starts rendering the node.
I guess the only advantage of using macros is that you can make page generation code without consing relatively easily. I'm not sure how necessary it is for web servers, but it may matter for extremely high-traffic sites.
I find the argument rather faulty. If you found your own company where does this "strong bias" to write software in the same language as the OS come from(just about every language out there has FFI to C so system libraries should be accessible)? If I am now writing Web software, I am now writing an application that runs on an OS that is primarily written in C so why does this "strong bias" magically disappear?
"(just about every language out there has FFI to C so system libraries should be accessible)"
Just about every language NOW has a good FFI to C. Subtract several years for when that essay was written, then subtract ten years for when the statement is set in, and you'll encounter a different world.
Today there's no great reason not to write your desktop app in PyQT or Clojure or on top of XULRunner. (Although I'd point out that surprisingly few people have noticed this!) ViaWeb was born into a different world. I didn't do much desktop programming in the 1996 timeframe, but you did not have many choices, especially if you were a student that couldn't drop ~$1000 2009-dollars into a programming language environment. (Now my new supercomputer-laptop costs less than that and superior environments are free. Vive la progress!) A couple that weren't C and, as it turns out, all doomed to be unsupported within a few years anyhow, like Delphi. I talk about 1996 because it's when I got into the game; the essay is a talk given in 2001 which means "ten years ago" is 1991.
System libraries are accessible, but bindings are still hard to write and maintain. Even when it comes to open-source communities that offer help for writing such bindings, the effort is still big ... try writing a GTK+ application in Haskell or CLisp ... yes, bindings for those two exist, but you're in for some pain.
Another reason is documentation. You'll have an easier time finding documentation/examples for the main language of the OS.
Another reason: having dependencies that aren't available on the target OS does impose additional development costs (if you don't want to give the user the burden of installing those dependencies). And if the distribution is over the Internet, it also means a bigger download size and extra harddisk space. These things may or may not matter, but imagine a simple feedreader that requires a 30MB download and 200MB of free disk space.
The main language of the OS doesn't necessarily have to be C/C++. It's the language that's best supported and encouraged by the company/community that maintains the OS (although it's currently not possible to write system drivers in C# on Windows, work is being done to lift some device drivers in user mode, which would make a good fit for .NET)
By looking at the way these users modified our built-in templates, we
knew what we needed to add to them.
Big companies outsource their R&D like this too, letting startups detect problems and solve them. Then the big corp. buys that startup (or copies it), and absorbs the solution into the platform, so the platform is constantly improving. It's a great thing for users.
On many projects this isn't as much of a problem, but I think it's dangerous to assume that one can easily use 'any language' when developing web-based software.