Dave Turner on Links

Sorry I probably won't be able to make the Links meeting (shame, since it
would have been a great chance to meet up with old friends). I am going on
holiday tomorrow, so I have a load of stuff to clear off my desk before I
go.

I did get a chance to look at your project proposal though. Generally, I
thought it looks great, though I came up with a few questions/comments which
it may be worth addressing (or expanding on).

1) What are the most costly/difficult aspects of programming a web site.
This is not my area of expertise, but I can take a guess that the following
issues are important:

a) Multi-language development (you already have this covered)

b) Fault tolerance (to network outages etc).

c) Performance constraints (interactive response times etc)

d) Inability to debug in realistic environments (can't have real web
server and database for each developer)

e) Difficult to isolate and test components (eg. I don't want to have to
fire up a real database and web server just to write an automated test for
my gui logic)

f) Performance does not scale well (this includes CPU, memory and
bandwidth scaling problems)

Do you think Links will address all these areas? If not, are you sure that
this will not be a significant weakness of the approach?

2) The Links project proposes to knit together a number of separate
technologies. What reason do you have to believe that they can combined
into a single coherent language?

3) Access to existing library code seems essential if you want to get
realistic web sites to use Links. How do you propose to interface to
existing libraries? Although foreign function calls and the like are well
understood now, I can imagine that the addition of such functionality may
well break your code generation model (for example, calling out to a Java or
C# library means the calling code cannot be moved onto the Javascript client
machine).

4) I would say more about tool support. Emacs modes and the like are well
out of date. Current developers (especially Java and C# ones) are used to
very sophisticated development environments which support integrated
debugging, browsing, refactoring etc. These IDEs can have a significant
effect on productivity, so I would consider integration your tools into a
modern, open, IDE such as Eclipse (which is specifically designed to work
with different languages etc).

Dave

CRA Computing Leadership Summit report Feb 2005

List of problems with how computing is perceived, and strategies for the solution, from a US perspective.

asxcaml

Another project related to Links. Thanks to Alan Schmitt for reminding me of this!

Tim Bray on Web Services

A useful roundup. Thanks to Will Partain for the pointer.

Rodrigo Barnes's web scripting survey

Useful background for Links. Follow the link above.

Norman Ramsey's comments on Links

Norman Ramsey attended the Links meeting and wrote down his thoughts afterwards; follow the link above.

Clone of Google maps using Flash

Another useful pointer from Jeremy Yallop

Somebody's written a
clone of Google maps using Flash.

It's apparently written using a tool that allows you to write in a
".NET language" (C#, VB.NET) and compile to Flash.

I found it via
Chris Double's weblog.

Ajax: A New Approach to Web Applications

One target audience for Links is those writing rich web clients in the style of Gmail, Google Maps, Amaztype, Mozilla Amazon Browser, and the like (see links below). The article linked to above explains key components of this brave new world. Thanks to Jeremy Yallop for the pointer.

Perl 6 in Haskell (PUGS)

While I'm on the subject of Perl and functional languages, here's another message from Will Partain. Of course, his implication in the first paragraph that I would already know of such a thing is completely wrong -- Will is my lifeline for learning this stuff.

Phil, you _probably_ know but just in case: this Autrijus Tang has
been making waves in Perl land, by *actually doing something* about
Perl 6 -- in Haskell! Relevant message below.

As you also probably know, Perl 6 is undergoing the most drawn out
design process in history :-) and the implementation people seem to do
nothing but tweak their VM (Parrot), usually to support Intercal or
something. Autrijus has broken the cycle. (Whether it will be
sustained is another matter.)

Will

PS: Damian is, of course, the "how to write Perl in Latin" guy.

====

From: Damian Conway
Newsgroups: gmane.comp.lang.perl.perl6.language
Subject: Kudos to Autrijus
Date: Thu, 17 Feb 2005 11:02:27 +1100

It's been mentioned to me that some folks were surprised that the design team
hasn't been more effusive in it's support for the incredible job that Autrijus
is doing prototyping the Perl 6 interpreter over the top of Haskell.

We had thought that answering his questions about 1000 times faster and much
more extensively that we ever answer anyone else's (;-) might have indicated
how much respect and admiration we have for the work he's doing. But
apparently not.

So let me publicly state that Larry, Allison, Patrick, Luke, Hugo, chromatic,
and myself find Autrijus's work both amazing and amazingly useful: as a way of
exploring the deeper design and implementation issues, and also as a way for
people to start playing with (and experiencing the real power of) Perl 6.

Well done, Autrijus!

Damian

Higher-Order Perl

By Mark Jason Dominus. Noted by Will Partain. (Thanks, Will!) Takes techniques familiar to functional programmers and transposes them to Perl. I liked the story about the cover.