29.4.05
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
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.
19.4.05
asxcaml
Another project related to Links. Thanks to Alan Schmitt for reminding me of this!
13.4.05
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.
11.4.05
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.
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.
====
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
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.
7.4.05
Links meeting at ETAPS
Forty-plus folk showed up!
Our afternoon treat was a cake modeled after the Bruntsfield Links.
There were lively discussions. Copies of slides to appear on the web page shortly.
Our afternoon treat was a cake modeled after the Bruntsfield Links.
There were lively discussions. Copies of slides to appear on the web page shortly.
6.4.05
Links meeting at ETAPS - enter comments here
Those attending the Links meeting at ETAPS should enter a comment here. (Click where it says "n comments".) Please include
* Your name
* Your institution
* Your web page
* Why are you interested in Links?
* Killer app: what facility could Links provide that would entice users?
You may also wish to answer the following challenge, posed by Simon Peyton Jones.
Describe a language feature or features that is/are qualitiatively better than what we have in either Haskell or ML. The feature does not need to be fully designed yet; but it should be more than content-free e.g. "better reasoning about concurrency". What are the challenges we need to overcome to make it real?
* Your name
* Your institution
* Your web page
* Why are you interested in Links?
* Killer app: what facility could Links provide that would entice users?
You may also wish to answer the following challenge, posed by Simon Peyton Jones.
Describe a language feature or features that is/are qualitiatively better than what we have in either Haskell or ML. The feature does not need to be fully designed yet; but it should be more than content-free e.g. "better reasoning about concurrency". What are the challenges we need to overcome to make it real?
5.4.05
Josef Svenningsson on Links
I'm sorry I haven't responded to your invitation to the Links workshop
earlier. Although it sounds like great fun I have my hands full with
writing up my thesis. Whether or not I'll be participating in the
future depends on who my future employer might be...
I'd still like to make some comments on the project though. First of
all I think the Links project has a lot of potential. I'm absolutely
confident that Links is going to be a really sweet language. There is
also a lot of opportunities for exciting research in the design and
programming experience with this language.
Now to my remarks. Here's a short summary:
One of your primary goals with Links seems to be to make a widely used
language. The mechanisms of language stardom is very complex and
completely different from designing a good language. Below I share
some thoughts on what I think it takes for a language to become
popular these days. The last paragraph talks about types and effects.
I'd like to start by quoting you:
"If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications."
These are two sentences which have very little in common. The first talks
about a language which is going to be famous and widely used. The second
talks about a technically superior language. I think it is time we learn
from history. Whether a technology becomes standard or widely used has
very little to do with the quality of that technology. As I said above I
am convinced that you're going to cook up a very nice language. But making
it widely used is a whole different mission.
But maybe it won't be that difficult to get Links widely used? After all it
has a "killer app"; web applications. But in my experience this is not
enough to draw attention. What you have to do nowadays to draw attention to
a language is to write a really unique program or system which people will
want to use. Recent examples of this is darcs, the revision control program
written in Haskell. It is a nice piece of software which could have
been written in any language really. To draw attention to Links I think you
should involve some hard core web developers (it is a good idea anyway
to hear what they have to say about the design of the language.) You will
be needing to write eye popping applications. Example of such applications
abound at Google; Google suggest, Google maps, GMail for example.
After getting peoples attention to a language there really needs to be
a lot of example code, libraries and tutorials for people to use and
look at. Haskell still lacks in this respect. And this is because it
is tedious work to write these things, work that one doesn't get score
any academic point with. Companies like Sun and Microsoft can handle
these things by setting their armies of programmers and technical
writers to work.
I find it interesting that you suggest that Links type system should
be equipped with effects. In fact I'm really thrilled by this language
design experiment. As far as I know there is really no knowledge at
all about the practical use of effects in programming so its going to
be interesting to see what comes out of this. Immediate obstacles that
come to mind is for instance debugging. I believe that using print
statements inside a algorithms is still a very common thing to do. But
with monads or effects this suddenly changes the type of my algorithm
making it incompatible with the rest of my program. In Haskell this
has led to some gruesome hacks such as the trace function. Another
thing is common exceptions like arithmetic exceptions and stack
overflow. In Java they solve this by having a special class of
exceptions. This may or may not be the best way to solve the
problem. Finally, since effects are rather fresh ground they might not
be the best choice for a language which is supposed to be widely used.
I hope my tone hasn't been overly patronising. As I said above I think
Links is going to be just great I'm looking forward to seeing it
develop. I wish you good luck with the workshop next week.
/Josef Svenningsson
earlier. Although it sounds like great fun I have my hands full with
writing up my thesis. Whether or not I'll be participating in the
future depends on who my future employer might be...
I'd still like to make some comments on the project though. First of
all I think the Links project has a lot of potential. I'm absolutely
confident that Links is going to be a really sweet language. There is
also a lot of opportunities for exciting research in the design and
programming experience with this language.
Now to my remarks. Here's a short summary:
One of your primary goals with Links seems to be to make a widely used
language. The mechanisms of language stardom is very complex and
completely different from designing a good language. Below I share
some thoughts on what I think it takes for a language to become
popular these days. The last paragraph talks about types and effects.
I'd like to start by quoting you:
"If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications."
These are two sentences which have very little in common. The first talks
about a language which is going to be famous and widely used. The second
talks about a technically superior language. I think it is time we learn
from history. Whether a technology becomes standard or widely used has
very little to do with the quality of that technology. As I said above I
am convinced that you're going to cook up a very nice language. But making
it widely used is a whole different mission.
But maybe it won't be that difficult to get Links widely used? After all it
has a "killer app"; web applications. But in my experience this is not
enough to draw attention. What you have to do nowadays to draw attention to
a language is to write a really unique program or system which people will
want to use. Recent examples of this is darcs, the revision control program
written in Haskell. It is a nice piece of software which could have
been written in any language really. To draw attention to Links I think you
should involve some hard core web developers (it is a good idea anyway
to hear what they have to say about the design of the language.) You will
be needing to write eye popping applications. Example of such applications
abound at Google; Google suggest, Google maps, GMail for example.
After getting peoples attention to a language there really needs to be
a lot of example code, libraries and tutorials for people to use and
look at. Haskell still lacks in this respect. And this is because it
is tedious work to write these things, work that one doesn't get score
any academic point with. Companies like Sun and Microsoft can handle
these things by setting their armies of programmers and technical
writers to work.
I find it interesting that you suggest that Links type system should
be equipped with effects. In fact I'm really thrilled by this language
design experiment. As far as I know there is really no knowledge at
all about the practical use of effects in programming so its going to
be interesting to see what comes out of this. Immediate obstacles that
come to mind is for instance debugging. I believe that using print
statements inside a algorithms is still a very common thing to do. But
with monads or effects this suddenly changes the type of my algorithm
making it incompatible with the rest of my program. In Haskell this
has led to some gruesome hacks such as the trace function. Another
thing is common exceptions like arithmetic exceptions and stack
overflow. In Java they solve this by having a special class of
exceptions. This may or may not be the best way to solve the
problem. Finally, since effects are rather fresh ground they might not
be the best choice for a language which is supposed to be widely used.
I hope my tone hasn't been overly patronising. As I said above I think
Links is going to be just great I'm looking forward to seeing it
develop. I wish you good luck with the workshop next week.
/Josef Svenningsson