jscheme-user

[Jscheme-user] Thinking about computing

[Ken A. <kan...@bb...>]

This  is Bruce Eckel's weblog:
http://www.mindview.net/WebLog

He's written books on C++ and Java and now he's writing Python, hates Java's checked exceptions, and likes dynamic typing!

We should be able to make good use of his aguments.

k

[Jscheme-user] GrewpEdit in JScheme

[Timothy J. H. <tim...@ma...>]

We are about to make a release of a Collaborative Editor
(GrewpEdit) implemented in JScheme and would appreciate
any feedback from the groupscheme and JScheme community about this tool.

      http://tat.cs.brandeis.edu:8090/grewp

We are releasing it as a Java Web Start (JWS) application, a signed 
Java applet,
a double-clickable jar, and a source distribution.

I am especially interested in seeing

   1)  whether the JWS and applet versions run on various Microsoft 
operating
        systems (we've tried one version of NT and it worked OK under 
Netscape and IE)

   2) whether there is a noticeable (or annoying!) lag time for people
        using the editor far from Boston. (There is no noticeable lag 
when I
        use it from home. I'm about 10 routers and 10 miles away on a
        wireless link to a DSL connection).

The current version allows you to connect to a server in Boston just by
supplying a username (any will do!). You can also create your own
Grewp server and have people connect to it.

The client editors send scheme terms over a socket to a server which
resolves conflicts and sends back official transformed editing 
operations.
The clients then apply these operations to their textfield. Thus, this 
is a
full duplex model where a slow connection will cause a noticeable lag.
Each character you type goes to the server, gets transformed and sent
back to your machine before it appears on the screen.

We are working on building a Jupiter/NetEdit model that uses speculation
to remove the lag time, but its not up yet. We are also working on a 
mini-emacs
interface for the collaborative textarea (which would allow users to 
define their
own emacs bindings in Jscheme ...) The next version of GrewpEdit will 
allow
the user to select from a wide variety of widgets including whiteboards,
cobrowsers, and other groupware widgets...

Cheers,
---Tim---

Re: [Jscheme-user] GrewpEdit in JScheme

[Geoffrey K. <ge...@kn...>]

Windows XP Pro:
-Java Web Start:
-- Create Shortcut.  Unable to create a shortcut for GroupEdit: v1.1  
7/2/04.  Invalid filename.  Please make sure the application title is  
valid.
-- Seemed to work fine.
-Signed applet:
--WinXP Pro, IE6, via signed applet, double-clicked on visit-log, also  
single-clicked on visit-log & pressed JOIN, both times got this:

ERROR in Action in reponse to an AWT  
eventjava.awt.event.ActionEvent[ACTION_PERFORMED,cmd=Join] on  
javax.swing.JButton[,0,0,59x28,layout=javax.swing.OverlayLayout,alignmen 
tX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundB 
orderUIResource@6c15a4,flags=1200,maximumSize=,minimumSize=,preferredSiz 
e=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.p 
laf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,p 
aintFocus=true,pressedIcon=,rolloverEnabled=false,rolloverIcon=,rollover 
SelectedIcon=,selectedIcon=,text=Join,defaultCapable=true] is  
(undefined tag  ())

Mac OS X:
-Java Web Start: Clicking on this link in Safari triggered a download  
of grewp.servlet, after which nothing happened.  I seem to recall that  
JWS apps on my Mac had .jlnp extensions.  Am I remembering correctly?
-Signed Applet:
--Worked great EXCEPT (!!!) I was in a tab of Safari, and clicking Edit  
in the signed applet CLOSED MY SAFARI WINDOW (and thus, all the other  
web pages I happened to be visiting).  It EXITED SAFARI too.  I'll have  
to try again with the signed applet in its own window. [...]  I tried  
it again, it closes all of SAFARI.

GNU/Linux (Fedora Core 1, FireFox 0.8 browser):
- Java Web Start: Works great.
- Signed applet.  Everything I wrote about Mac OS X + signed applet  
applies, except the browser is FireFox instead of Safari.  The behavior  
of the whole browser closing when I select File/Exit from the applet is  
the same.

I'll have to try Solaris later.  The kids want to go canoeing!

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

On Jul 3, 2004, at 08:24, Timothy John Hickey wrote:

> We are about to make a release of a Collaborative Editor
> (GrewpEdit) implemented in JScheme and would appreciate
> any feedback from the groupscheme and JScheme community about this  
> tool.
>
>      http://tat.cs.brandeis.edu:8090/grewp
>
> We are releasing it as a Java Web Start (JWS) application, a signed  
> Java applet,
> a double-clickable jar, and a source distribution.
>
> I am especially interested in seeing
>
>   1)  whether the JWS and applet versions run on various Microsoft  
> operating
>        systems (we've tried one version of NT and it worked OK under  
> Netscape and IE)
>
>   2) whether there is a noticeable (or annoying!) lag time for people
>        using the editor far from Boston. (There is no noticeable lag  
> when I
>        use it from home. I'm about 10 routers and 10 miles away on a
>        wireless link to a DSL connection).
>
> The current version allows you to connect to a server in Boston just by
> supplying a username (any will do!). You can also create your own
> Grewp server and have people connect to it.
>
> The client editors send scheme terms over a socket to a server which
> resolves conflicts and sends back official transformed editing  
> operations.
> The clients then apply these operations to their textfield. Thus, this  
> is a
> full duplex model where a slow connection will cause a noticeable lag.
> Each character you type goes to the server, gets transformed and sent
> back to your machine before it appears on the screen.
>
> We are working on building a Jupiter/NetEdit model that uses  
> speculation
> to remove the lag time, but its not up yet. We are also working on a  
> mini-emacs
> interface for the collaborative textarea (which would allow users to  
> define their
> own emacs bindings in Jscheme ...) The next version of GrewpEdit will  
> allow
> the user to select from a wide variety of widgets including  
> whiteboards,
> cobrowsers, and other groupware widgets...
>
> Cheers,
> ---Tim---
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital  
> self defense, top technical experts, no vendor pitches, unmatched  
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

RE: [Jscheme-user] Thinking about computing

[Borislav I. <bor...@ko...>]

The core argument for dynamic typing is actually one that I used to
convince myself to rely on dynamically typed languages more and more: we
need to test anyway so sacrificing expressiveness, readability and
development speed for the illusionary safety of static type checking is
simply not worth it. But he misses two important (related) points in
favor of static typing:

1) When a mistake is detected "statically", at compile time, not only is
a programmer informed about it, but the information is much more useful
- you know where it is in the code, you can more easily associate it
with a mistaken/misunderstood intent, program design/structure etc. In a
sense, a semantic constraint is really reduced to syntactic one which is
one level down in terms tractability by both humans and machines.

2) The rigor and expliciteness required by statically typed languages
become increasingly important with program size. This is a consequence
of the previous point: it is easy to track down a run-time exception
when the program is small and the behavior can be easily localized
within the code. For large systems, maintained and evolving over years
by many programmers, the extra fingering and design contraints enforced
by static typing can be life savers - ok, a test may detect that
something is wrong, but how long before the programmer goes from the
error produced by the test to the real problem? And what (how many?)
changes to the code would that prompt?

A problem I often have when programming with Jscheme is the error:
"Expected pair or '(), but found blabla....". I know in what function
this happens, I know where is the code expected the list, but god know
where I put the blabla instead of it. The positive aspect is that this
forces me to be much more attentive to the type of data I'm passing
around, a habit I'd lost (or probably never really aquired) with
languages like Java and C++.

Cheers,
Boris

| -----Original Message-----
| From: jsc...@li... 
| [mailto:jsc...@li...] On Behalf 
| Of Ken Anderson
| Sent: Friday, July 02, 2004 4:43 PM
| To: Jscheme Users
| Subject: [Jscheme-user] Thinking about computing
| 
| 
| This  is Bruce Eckel's weblog:
| http://www.mindview.net/WebLog
| 
| He's written books on C++ and Java and now he's writing 
| Python, hates Java's checked exceptions, and likes dynamic typing!
| 
| We should be able to make good use of his aguments.
| 
| k
| 
| 
| 
| -------------------------------------------------------
| This SF.Net email sponsored by Black Hat Briefings & 
| Training. Attend Black Hat Briefings & Training, Las Vegas 
| July 24-29 - 
| digital self defense, top technical experts, no vendor pitches, 
| unmatched networking opportunities. Visit www.blackhat.com 
| _______________________________________________
| Jscheme-user mailing list
| Jsc...@li...
| https://lists.sourceforge.net/lists/listinfo/jscheme-user
| 

RE: [Jscheme-user] Thinking about computing

[Ken A. <kan...@bb...>]

Nice reply.
Now, that i'm reading Bruce's mind view, i think he muddies things up a lot more than i would have liked.  Maybe this is the right approach, especially for people like him who have survived C++.

At 02:23 PM 7/5/2004 -0400, Borislav Iordanov wrote:
>The core argument for dynamic typing is actually one that I used to
>convince myself to rely on dynamically typed languages more and more: we
>need to test anyway so sacrificing expressiveness, readability and
>development speed for the illusionary safety of static type checking is
>simply not worth it. 

Types are good, but i think the real problem is "static".  Imagine having to halt the internet everytime an interface changed.  CORBA and RMI require both sides of a conversation agree on the types.  Common Lisp lets you change the definition of a class dynamically, though i don't think this has been done across machines.  I saw a nice NASA presentation once that used "frames" (nested alists) or almost XML to communicate across machines.  That let them add a field to the output of one machine and other machines could ignore it until they were updated. Optimize for flexibility as Howie Shrobe would say.

>But he misses two important (related) points in
>favor of static typing:
>
>1) When a mistake is detected "statically", at compile time, not only is
>a programmer informed about it, but the information is much more useful
>- you know where it is in the code, you can more easily associate it
>with a mistaken/misunderstood intent, program design/structure etc. In a
>sense, a semantic constraint is really reduced to syntactic one which is
>one level down in terms tractability by both humans and machines.

I take this to mean that typing something like this in Java:
Foo x = (Foo) foos.get(name);
seems more like writing assembly language than saying
Foo x = foos.get(name);
There is no reason Java could not do this type inference.
IN a dynamic language you could say
x = foos.get(name);
which does seem "higher level than assembly".

>2) The rigor and expliciteness required by statically typed languages
>become increasingly important with program size. This is a consequence
>of the previous point: it is easy to track down a run-time exception
>when the program is small and the behavior can be easily localized
>within the code. For large systems, maintained and evolving over years
>by many programmers, the extra fingering and design contraints enforced
>by static typing can be life savers - ok, a test may detect that
>something is wrong, but how long before the programmer goes from the
>error produced by the test to the real problem? And what (how many?)
>changes to the code would that prompt?

So here i think you're arguing in favor of static typing.  It keeps you honest longer.  However, when i've changed large code bases i didn't understand, i make the smallest change i can and test it.  Which suggests that it is really testing that leads to code longevity. 

>A problem I often have when programming with Jscheme is the error:
>"Expected pair or '(), but found blabla....". I know in what function
>this happens, I know where is the code expected the list, but god know
>where I put the blabla instead of it. The positive aspect is that this
>forces me to be much more attentive to the type of data I'm passing
>around, a habit I'd lost (or probably never really aquired) with
>languages like Java and C++.

If you are criticizing JScheme, let me know, lets make it better.  I have a way of finding where functions are defined, and i agree that backtraces can be hard to follow.

I have begun to follow the PLT Scheme practice of writing a type signature before a procedure definition:
;;; sq: number -> number
(define (sq x)
   "return x squared."
   (* x x))

you can use 
(describe sq)
to see the definition and the documentation of sq.

k