So apparently the way to develop applications for the iPhone is by
creating a web service that takes advantage of Web 2.0 (whatever that
means) and AJAX, all based on the Safari browser.
Since there are quite a few web application frameworks available for
Common Lisp (and also at least one pretty impressive one for Scheme)
this should be relatively straightforward. But does anyone see an
obvious winner, or obvious losers because of some possible restrictions?
I am just curious because I haven't done any web applications myself yet...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> So apparently the way to develop applications for the iPhone is by
> creating a web service that takes advantage of Web 2.0 (whatever that
> means) and AJAX, all based on the Safari browser.
>
> Since there are quite a few web application frameworks available for
> Common Lisp (and also at least one pretty impressive one for Scheme)
> this should be relatively straightforward. But does anyone see an
> obvious winner, or obvious losers because of some possible restrictions?
>
> I am just curious because I haven't done any web applications myself yet...
>
>
> Pascal
There is nothing special about it. It is just another
web client with Javascript and Ajax. The user has
to be online. The browser just happens to run
on an iPhone with a touch screen. But you don't get
more than running another browser on another
mobile thing. The whole 'best browser in the world'
and 'the real Internet on the iPhone' is just complete
bullshit. Nokia also uses Webkit
(http://opensource.nokia.com/projects/S60browser/).
Maybe Lisp people get some advantage writing JavaScript,
since JavaScript is mostly a Lisp dialect with
a different syntax. But developing and debugging
Javascript apps on a Web browser is only fun
in some perverse way.
I'm not impressed. If we had OpenMCL in a ARM version
running on the thing and driving a Core Animation based
touch screen UI, then we would be talking...
But Apple seems to see it as a piece of consumer
electronics and not a computer platform. So they won't let
you touch the OS.
Even more the argument that there would be a security
problem if one could develop apps for it is stupid.
On other phones there is a way to do that and now
you see Laptops with 3G built in. Plus Web browsers
with Javascript have been a single giant security problem
in the past years. Is there a week without new security
problems? Apple just had Safari 3 beta published. Within
hours security problems have been found...
Say, if Salesforce has a client for mobile devices via
Web 2 and Ajax, then the iPhone will be just another
client system. But it will not be a particular
iPhone special app. You might want to know things
like screen size, colors, DPI, transfer speed, and so on -
but that's mostly it...
--
http://lispm.dyndns.org
On 2007-06-12, Rainer Joswig <······@lisp.de> wrote:
> Maybe Lisp people get some advantage writing JavaScript,
> since JavaScript is mostly a Lisp dialect with
> a different syntax.
Is there any language you do not consider to be a Lisp dialect?
In article <··························@babayaga.math.fu-berlin.de>,
David Lichteblau <···········@lichteblau.com> wrote:
> On 2007-06-12, Rainer Joswig <······@lisp.de> wrote:
> > Maybe Lisp people get some advantage writing JavaScript,
> > since JavaScript is mostly a Lisp dialect with
> > a different syntax.
>
> Is there any language you do not consider to be a Lisp dialect?
OCAML. F#. Prolog. Ada. Cobol. Snobol. Algol. Fortran. Java. C.
C++. C#.
Javascript is/has
* dynamically typed
* higher-order first-class functions
* full lexical closures
* interactive
* simple object-system without information hiding
* EVAL
* Garbage Collection
--
http://lispm.dyndns.org
On Jun 13, 10:49 am, Rainer Joswig <······@lisp.de> wrote:
> In article <··························@babayaga.math.fu-berlin.de>,
> David Lichteblau <···········@lichteblau.com> wrote:
>
> > On 2007-06-12, Rainer Joswig <······@lisp.de> wrote:
> > > Maybe Lisp people get some advantage writing JavaScript,
> > > since JavaScript is mostly a Lisp dialect with
> > > a different syntax.
>
> > Is there any language you do not consider to be a Lisp dialect?
>
> OCAML. F#. Prolog. Ada. Cobol. Snobol. Algol. Fortran. Java. C.
> C++. C#.
What about Erlang?
In article <························@c77g2000hse.googlegroups.com>,
fireblade <·················@gmail.com> wrote:
> On Jun 13, 10:49 am, Rainer Joswig <······@lisp.de> wrote:
> > In article <··························@babayaga.math.fu-berlin.de>,
> > David Lichteblau <···········@lichteblau.com> wrote:
> >
> > > On 2007-06-12, Rainer Joswig <······@lisp.de> wrote:
> > > > Maybe Lisp people get some advantage writing JavaScript,
> > > > since JavaScript is mostly a Lisp dialect with
> > > > a different syntax.
> >
> > > Is there any language you do not consider to be a Lisp dialect?
> >
> > OCAML. F#. Prolog. Ada. Cobol. Snobol. Algol. Fortran. Java. C.
> > C++. C#.
>
> What about Erlang?
I don't know much about it. Though it looks very interesting, based on
the little I have read about it. I'm planning to read
the book 'Programming Erlang: Software for a Concurrent World'
written by Joe Armstrong.
--
http://lispm.dyndns.org
On Jun 15, 10:57 am, Rainer Joswig <······@lisp.de> wrote:
> In article <························@c77g2000hse.googlegroups.com>,
>
>
>
>
>
> fireblade <·················@gmail.com> wrote:
> > On Jun 13, 10:49 am, Rainer Joswig <······@lisp.de> wrote:
> > > In article <··························@babayaga.math.fu-berlin.de>,
> > > David Lichteblau <···········@lichteblau.com> wrote:
>
> > > > On 2007-06-12, Rainer Joswig <······@lisp.de> wrote:
> > > > > Maybe Lisp people get some advantage writing JavaScript,
> > > > > since JavaScript is mostly a Lisp dialect with
> > > > > a different syntax.
>
> > > > Is there any language you do not consider to be a Lisp dialect?
>
> > > OCAML. F#. Prolog. Ada. Cobol. Snobol. Algol. Fortran. Java. C.
> > > C++. C#.
>
> > What about Erlang?
>
> I don't know much about it. Though it looks very interesting, based on
> the little I have read about it. I'm planning to read
> the book 'Programming Erlang: Software for a Concurrent World'
> written by Joe Armstrong.
>
> --http://lispm.dyndns.org- Hide quoted text -
>
> - Show quoted text -
It's pretty ugly but it has other strength, concurrency, SMP , free
enviroment, mnesia, yaws and finally Ercison & co to persuade your
boss that big companies depend on it for production not another
hackish/academia/whatever-beside-mainstream language that *nobody* use
it.
(message (Hello 'David)
(you :wrote :on '(13 Jun 2007 07:36:25 GMT))
(
??>> Maybe Lisp people get some advantage writing JavaScript,
??>> since JavaScript is mostly a Lisp dialect with
??>> a different syntax.
DL> Is there any language you do not consider to be a Lisp dialect?
Guy L. Steele Jr. participated in the creation of JavaScript (ECMAScript)
standard. does it say something? :)
well, i'm not sure that Steele have contributed any major features, but
JavaScript is surprisingly well done for a language like this, especially
comparing to uglies like PHP.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")
On Jun 13, 12:30 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> Guy L. Steele Jr. participated in the creation of JavaScript (ECMAScript)
> standard. does it say something? :)
Makes me think of Guy's well known quote about Java brining people
from C++ closer to Lisp.
Maybe Javascript is a further pull in that direction? Clever.
-jimbo
On Wed, 13 Jun 2007 19:30:16 +0300, "Alex Mizrahi" <········@users.sourceforge.net> said:
| ...
| ??>> Maybe Lisp people get some advantage writing JavaScript,
| ??>> since JavaScript is mostly a Lisp dialect with
| ??>> a different syntax.
| DL> Is there any language you do not consider to be a Lisp dialect?
| Guy L. Steele Jr. participated in the creation of JavaScript (ECMAScript)
| standard. does it say something? :)
He is also one of the authors of Java, which isn't a Lisp dialect
nevertheless.
---Vassil,
who thought it was a well-known fact that JavaScript is a cousin, if
not a member of the Lisp family, perhaps in some disguise.
--
The truly good code is the obviously correct code.
Rainer Joswig <······@lisp.de> writes:
> Nokia also uses Webkit
> (http://opensource.nokia.com/projects/S60browser/).
Yes, but so far I haven't seen a single ajax page that works in Safari
on the mac that will work in the browser on my Nokia E61.
> Even more the argument that there would be a security
> problem if one could develop apps for it is stupid.
I think that's just a lame excuse. The /real/ reason is probably (this
is not my idea, I got it from some blog, but I can't remember which
right now) that they want full control of the GUI experience until it
has "settled" somewhat, so that the users learn what a real iPhone app
should look & feel like. This will make the users demand the same GUI
qualities from third party apps (otherwise, who knows, they might have
been happy with applications with an S60-like or Win CE-like
application interface).
So my guess is: They /will/ open it up, but after some
time. Hopefully, it will eventually be as programmable as any other
*nix machine. And then I want a port of LispWorks :-)
--
(espen)
Rainer Joswig wrote:
>
> I'm not impressed. If we had OpenMCL in a ARM version
> running on the thing and driving a Core Animation based
> touch screen UI, then we would be talking...
> But Apple seems to see it as a piece of consumer
> electronics and not a computer platform. So they won't let
> you touch the OS.
>
If you want a phone that does let you touch the OS, see
http://wiki.openmoko.org
The Neo1973 is not really mass-market available yet,
so you might have to wait a bit, but it's a pretty
open device, and not complete vapourware insofar as
physical phones do already actually exist.
Simulating it is straightforward enough -
http://wiki.openmoko.org/wiki/OpenMoko_under_QEMU
A compile of one of the smaller lisp implementations
for it would likely also be straightforward, and if
the lisp has GTK and/or X11 bindings, well, you're
sorted.
(I expect Rainer in particular already knows about it,
this is just a general information post.)
On Tue, 12 Jun 2007 22:27:51 +0200, Pascal Costanza wrote:
> So apparently the way to develop applications for the iPhone is by
> creating a web service that takes advantage of Web 2.0 (whatever that
> means) and AJAX, all based on the Safari browser.
>
> Since there are quite a few web application frameworks available for
> Common Lisp (and also at least one pretty impressive one for Scheme)
> this should be relatively straightforward. But does anyone see an
> obvious winner, or obvious losers because of some possible restrictions?
If you're doing just basic REST-y stuff, Hunchentoot is a good base, and
i'm sure we'll see a lot of mini-frameworks built on top of in the the
coming months. If your needs are more to the ajax-y, or the call/cc-y, or
the ViaWeb-y (that is to say interactive web applications) , UCW can't be
beat. The new ucw_ajax branch is beginning to stabilize quite nicely, and
i'm already using it in development, with production coming when the app
is delivered.
I'm of the opinion that the people behind UCW must be really special and
dynamic individuals, as it's one of the few libraries i know that comes
with support for ContextL out-of-the-box. Surely this is a sign of a many
layered development and user community. :P
>
> I am just curious because I haven't done any web applications myself
> yet...
UCW places a lot of distance between the programmer and HTTP. Thus, it is
probably a much better fit for a lisper-turned-web-developer than
vice-versa. I personally belong to the latter camp though, so what do i
know ;).
drewc
>
>
> Pascal
>
--
Posted via a free Usenet account from http://www.teranews.com
On Jun 13, 11:50 pm, Drew Crampsie <·············@gmail.com> wrote:
> UCW places a lot of distance between the programmer and HTTP. Thus, it is
> probably a much better fit for a lisper-turned-web-developer than
> vice-versa. I personally belong to the latter camp though, so what do i
> know ;).
I've heard (not yet seriously verified) that Hunchentoot currently has
performance bottleneck due to its flexible Flexi-streams library. (At
least on SBCL.) And UCW is good for what it's intended to do, but it's
rather difficult to deviate from its assumptions to do something more
conventional.
I'm currently developing app which uses both libraries, but those
libraries are abstracted away enough that I rarely deal with either of
them.
Tayssir
On Wed, 13 Jun 2007 23:55:22 -0000, Tayssir John Gabbour <············@googlemail.com> wrote:
> I've heard (not yet seriously verified) that Hunchentoot currently
> has performance bottleneck due to its flexible Flexi-streams
> library.
Did that come from the same source as "Lisp is slow"?
:)
Seriously, writing through two layers of Gray streams can't possibly
be as fast as writing directly to the socket stream, but for real
world applications I've never ever had any performance problems with
it.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Jun 14, 2:12 am, Edi Weitz <········@agharta.de> wrote:
> On Wed, 13 Jun 2007 23:55:22 -0000, Tayssir John Gabbour <············@googlemail.com> wrote:
> > I've heard (not yet seriously verified) that Hunchentoot currently
> > has performance bottleneck due to its flexible Flexi-streams
> > library. (At least on SBCL.)
>
> Did that come from the same source as "Lisp is slow"?
>
> :)
Anything's possible. ;) Well, I heard that from someone who showed me
the profiling data, and another person who also looked into it (on a
similar basic Debian Linux + SBCL platform).
Unfortunately, it does seem unfair to mention this without offering
evidence, so take it with a grain of salt until I take more concrete
steps to figure out what's going on... Particularly since it does seem
like an odd claim, so it requires a higher standard of evidence. Could
be they're measuring some other, undiscovered factor.
Tayssir
On Thu, 14 Jun 2007 01:47:28 -0000, Tayssir John Gabbour <············@googlemail.com> wrote:
> Anything's possible. ;) Well, I heard that from someone who showed
> me the profiling data, and another person who also looked into it
> (on a similar basic Debian Linux + SBCL platform).
FWIW, here's something I wrote about this topic a while ago:
http://weitz.de/hunchentoot/#performance
If the guy you're talking about sees performance problems that prevent
him from using Hunchentoot for his project, I'd be happy to help him,
preferably via the mailing list.
However, very often (witness c.l.l) I see hackers who start to
benchmark and worry about performance before they've written any code
at all. That's clearly a waste of time.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Wed, 13 Jun 2007 23:55:22 +0000, Tayssir John Gabbour wrote:
> On Jun 13, 11:50 pm, Drew Crampsie <·············@gmail.com> wrote:
>> UCW places a lot of distance between the programmer and HTTP. Thus, it is
>> probably a much better fit for a lisper-turned-web-developer than
>> vice-versa. I personally belong to the latter camp though, so what do i
>> know ;).
>
> I've heard (not yet seriously verified) that Hunchentoot currently has
> performance bottleneck due to its flexible Flexi-streams library. (At
> least on SBCL.)
Hearsay is not admissible in court.lang.lisp :)
> And UCW is good for what it's intended to do, but it's
> rather difficult to deviate from its assumptions to do something more
> conventional.
This may have been true quite a while ago, but for at least 15 months
we've had a 'dispatch' mechanism similar to that of TBNL. One matches a
url (via string=, regexp, etc) and a handler is called. A simplified
version would look like this:
;; assume *request* contains the current HTTP request
(dolist (dispatcher (find-dispatchers *request*))
(when (dispatch dispatcher *request*)
(handle dispatcher *request*)
(return)))
HANDLE could be nothing more than:
(serve-file (request-path *request*))
or maybe:
(run-cgi-script *request* #P"/var/www/cgi-bin/some-script.cgi")
... or all the way to UCW's component rendering and call/cc magic. Even
when using all of the bells and whistles, every step is
customizable (and this is much more true of the ucw_ajax
branch) to allow for things like bookmarkable URLs, database connection
management and all the other things you may want to define per application.
Of course, the documentation for these interfaces is the (well commented)
source code, and the _ajax branch moves quite quickly so features come and
are refined at a fast pace.. but modern UCW is a lot more than just a
call/cc framework. Support for on-the-fly parenscript compiling, serving
static files or tal templates and a host of other features
are supported out-of-the-box, and almost anything else you could possibly
want to do is a few DEF*'s away,
> I'm currently developing app which uses both libraries, but those
> libraries are abstracted away enough that I rarely deal with either of
> them.
I wouldn't mind hearing about what difficulties you had with ucw and the
assumptions it makes, and how that affected the design of your
application.
Cheers,
drewc>
> Tayssir
--
Posted via a free Usenet account from http://www.teranews.com
On Jun 14, 1:55 am, Tayssir John Gabbour <············@googlemail.com>
wrote:
> On Jun 13, 11:50 pm, Drew Crampsie <·············@gmail.com> wrote:
>
> > UCW places a lot of distance between the programmer and HTTP. Thus, it is
> > probably a much better fit for a lisper-turned-web-developer than
> > vice-versa. I personally belong to the latter camp though, so what do i
> > know ;).
>
> I've heard (not yet seriously verified) that Hunchentoot currently has
> performance bottleneck due to its flexible Flexi-streams library. (At
> least on SBCL.) And UCW is good for what it's intended to do, but it's
> rather difficult to deviate from its assumptions to do something more
> conventional.
>
Heard where ? Or this is some FUD tactic.
> I'm currently developing app which uses both libraries, but those
> libraries are abstracted away enough that I rarely deal with either of
> them.
>
> Tayssir
So tells us your experience, that would come streight from the you,
and could be verified or discredited.
On Jun 15, 10:04 am, fireblade <·················@gmail.com> wrote:
> Heard where ? Or this is some FUD tactic.
>
> > I'm currently developing app which uses both libraries, but those
> > libraries are abstracted away enough that I rarely deal with either of
> > them.
>
> So tells us your experience, that would come streight from the you,
> and could be verified or discredited.
I just did. I'm adding features to the app on behalf of the same team
which did the profiling for two different projects. My intention, if I
think it's interesting enough, is to blog about the issues which come
up on a real-world commercial project (actually two or three), which
already have users this very instant.
Too often, Lisp "advocacy" is completely unaccountable to the poor
fellas who realize from painful experience that it's not as smooth as
advocates glibly maintain. Like most software advocacy; I've often
used a Linux distro and asked, "Is THIS what people say is ready for
their Grandmas? What kind of hacker grandmas do these people have?"
I'm relatively new to working with them, so it will take some time for
me to verify or reject their claims, since I focus on other areas.
However, these are people who seem careful and thoughtful, who spend
time on these issues, so I do pay some attention to their claims.
Since you do not know these people, you can feel free to take it with
a grain of salt -- as I've already suggested.
Already, I am inviting Lisp users to that very office -- people who
come don't have to take my word for it, they can see it themselves!
http://wiki.alu.org/BeNeLux
Incidentally, note that misleading "pro"-Lisp sentiments often go
unchallenged on this forum. While those who differ are immediately
challenged, often with angry denunciations. We can predict the effects
of this.
Tayssir
On Jun 15, 1:28 pm, Tayssir John Gabbour <············@googlemail.com>
wrote:
> On Jun 15, 10:04 am, fireblade <·················@gmail.com> wrote:
>
> > Heard where ? Or this is some FUD tactic.
>
> > > I'm currently developing app which uses both libraries, but those
> > > libraries are abstracted away enough that I rarely deal with either of
> > > them.
>
> > So tells us your experience, that would come streight from the you,
> > and could be verified or discredited.
>
> I just did. I'm adding features to the app on behalf of the same team
> which did the profiling for two different projects. My intention, if I
> think it's interesting enough, is to blog about the issues which come
> up on a real-world commercial project (actually two or three), which
> already have users this very instant.
>
> Too often, Lisp "advocacy" is completely unaccountable to the poor
> fellas who realize from painful experience that it's not as smooth as
> advocates glibly maintain. Like most software advocacy; I've often
> used a Linux distro and asked, "Is THIS what people say is ready for
> their Grandmas? What kind of hacker grandmas do these people have?"
>
> I'm relatively new to working with them, so it will take some time for
> me to verify or reject their claims, since I focus on other areas.
> However, these are people who seem careful and thoughtful, who spend
> time on these issues, so I do pay some attention to their claims.
> Since you do not know these people, you can feel free to take it with
> a grain of salt -- as I've already suggested.
>
> Already, I am inviting Lisp users to that very office -- people who
> come don't have to take my word for it, they can see it themselves!http://wiki.alu.org/BeNeLux
>
> Incidentally, note that misleading "pro"-Lisp sentiments often go
> unchallenged on this forum. While those who differ are immediately
> challenged, often with angry denunciations. We can predict the effects
> of this.
>
> Tayssir
And discouragement is the beginning of failure.
- Richard p. Gabriel
Patterns of Software - Tales from the Software Community
I understand.
You were seduced by the sheer buty of s-expressions, the rapid
development of REPL, power of macros, CLOS generic functions and vast
knowledge of community calling themselves lispers. Where strange
people live who could do things that feels no lesser than wizardry
and coding is like magic using the most powerfull language on earth.
So you wanted piece of action. For free. Well it ain't gonna work
that way. There's price to pay and it comes with blood toil tears and
sweat. Move on if you aren't ready. Poor fellas & whiner shouldn't
expect any sympathy here. Cry yourself out and start working to solve
your problem. If your web server is slow fix the bottleneck or at
least find where it is so other could fix it (if it really exist). If
your favourite library is missing write it. Or walk away and code you
applications with some other language. Whichever of them suits your
need . But stop whining. Your mamma is not here to suit you.
Slobodan Blazeski
My apologies to those who like Java, C#, PHP, Delphi, Visual Basic,
Perl, Python, Ruby, COBOL, or any other language. I know you think you
know a better language than lisp. All I can say is I do, too!
Drew Crampsie wrote:
> I'm of the opinion that the people behind UCW must be really special and
> dynamic individuals, as it's one of the few libraries i know that comes
> with support for ContextL out-of-the-box. Surely this is a sign of a many
> layered development and user community. :P
:)
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/