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
