C/C++ Warm Fuzzy Feelings.... Dylan-Interim 
Author Message
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim


   Newsgroups: comp.lang.dylan
   Date: 26 Jun 94 02:14:01 GMT


      ....

      With the infix syntax, will pt.x be preferable to x(pt)?

   Seems like a matter of taste.  I predict the former will give the
   C/C++ crowd warm fuzzy feelings and therefore will be used more.

Well, if someone really wants Dylan to be used more, then they had better
take a look at what people are e{*filter*}d about.  Perhaps then we will get
that Tcl feel-alike syntax and all those Tcl people will then switch to
Dylan....  :->

Anybody willing to refute a suspicion that the recent Dylan demonstration
(during MacExpo) was written in Dylan-Classic (but vu-graphed in
Dylan-Interim)?  Or is that common knowledge already?

What percentage of development time has been spent on issues that where
solved already (or nearly so) by Dylan-Classic but have been reopened by
Dylan-Iterim?  Any Dylan partner care to comment on the man-hours spent in
meetings debating syntax (would 'begin' or '{' make Dylan's 'target
audience' feel more warm and fuzzy), the lexical/syntactic analyzer
implementations (if the C community is any guide, we are just now getting
parsers that nearly identify the proper line and character position of a
syntactic error), and the still unknown macro system)  Apple?  CMU?

How many Dylan partners are there now?  What are their backgrounds?

-- Ed



Sat, 14 Dec 1996 08:12:29 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

   What percentage of development time has been spent on issues that where
   solved already (or nearly so) by Dylan-Classic but have been reopened by
   Dylan-Iterim?  Any Dylan partner care to comment on the man-hours spent in
   meetings debating syntax (would 'begin' or '{' make Dylan's 'target
   audience' feel more warm and fuzzy), the lexical/syntactic analyzer
   implementations (if the C community is any guide, we are just now getting
   parsers that nearly identify the proper line and character position of a
   syntactic error), and the still unknown macro system)  Apple?  CMU?

Indeed, this is a very pertinent question.  How much money has been
spent, and how many potential customers lost, by the extra work and
long delay caused by Dylan's technically and even politically
questionable change-of-syntax gamble?  Are there really a large
percentage of programmers who will gladly switch to an OODL
if-and-only-if it has irregular ("algebraic") syntax?

My own observations suggest that the acceptance or rejection of new,
more powerful technology has little to do with syntactic familiarity
and much to do with willingness or unwillingness to change total
behavior ("process", "culture", "established way of doing business").
In other words, if you think that what you're using is "good enough,"
you're not going to switch to anything genuinely new; but if you
realize that what you're using is simply not sufficient, superficial
considerations are not going to stand in the way of a genuine,
significant improvement.

I don't mean to be hypercritical or overskeptical.  The point is, we
just don't know the answers to these questions yet.  Time will tell.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories

Standard disclaimer.



Sat, 14 Dec 1996 21:24:52 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

   My own observations suggest that the acceptance or rejection of new,
   more powerful technology has little to do with syntactic familiarity
   and much to do with willingness or unwillingness to change total
   behavior ("process", "culture", "established way of doing business").

Whereas my experience has been that acceptance or rejection of new,
more powerful technology has a great deal to do with how unfamiliar
and disorienting it is.

Selling Dylan by saying "You have to change everything you know, all
your behavior, all your methods, etc" is fun.  Selling Dylan by saying
"It has important and significant advantages over what you use now,
but you can leverage lots of your hard-won experience, hard-learned
and expensive hardware and software base, etc" is effective.



Mon, 16 Dec 1996 08:32:36 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim


      My own observations suggest that the acceptance or rejection of new,
      more powerful technology has little to do with syntactic familiarity
      and much to do with willingness or unwillingness to change total
      behavior ("process", "culture", "established way of doing business").

   Whereas my experience has been that acceptance or rejection of new,
   more powerful technology has a great deal to do with how unfamiliar
   and disorienting it is.

This is rather paradoxical when applied to productivity.  By
definition, increasing human productivity requires =some= major change
in human behavior.  The best you can ever hope for is to "drop" some
old work-step that is now unnecessary without adding a new one; but
even such simple "work-step deletion" implies a change in process
("how we do business").  Far more commonly, productivity-increasing
technology does require significant modification of one's work
activities.

   Selling Dylan by saying "You have to change everything you know, all
   your behavior, all your methods, etc" is fun.  Selling Dylan by saying
   "It has important and significant advantages over what you use now,
   but you can leverage lots of your hard-won experience, hard-learned
   and expensive hardware and software base, etc" is effective.

There is some merit to your approach, but it could be applied
equally--indeed, perhaps even better--to, say, ANSI Common Lisp (or a
small-footprint subset thereof) than to Dylan.  Your hypothesis,
stated in my own rather blunt terms, seems to be that for large
numbers of otherwise highly-regarded programmers, a small amount of
transitory syntactic discomfort obscures numerous major technical
advantages, and that such programmers manage to effectively obstruct
their managers' introduction of productivity-increasing technology.
Dylan is the experiment that will determine if this hypothesis is
correct.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories

Standard disclaimer.



Mon, 16 Dec 1996 21:40:05 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim



          What percentage of development time has been spent on issues that where
          solved already (or nearly so) by Dylan-Classic but have been reopened by
          Dylan-Iterim?  ...

       Indeed, this is a very pertinent question.  How much money has been
       spent, and how many potential customers lost, by the extra work and
       long delay caused by Dylan's technically and even politically
       questionable change-of-syntax gamble?  Are there really a large
       percentage of programmers who will gladly switch to an OODL
       if-and-only-if it has irregular ("algebraic") syntax?

One really has to feel sorry for the Dylan-Classic designers.  Brilliant
people with a great, timely idea being saddled by a 'target audience' that
is still debating exceptions and garbage collection and that probably
can't appreciate Dylan even given a warm-and-fuzzy syntax.

[I really am interested in *exactly* who is in this 'target audience'... we've
heard and read C/C++ etc but, ignoring language, I can't imagine that the
audience was ever outside of Apple itself.  Or should be.]

Syntax notes...  This works (at least it's better than some languages):
  if (#t) #t end if  & "I'm ok"
This doesn't work (won't compile):
  if (#t) #t end if; & "I'm sick"
This works (in the event that some people don't know);
  (and (if t t) "I'm ok")

Dylan Syntax needs an 'end-all' core-word... then we get
    define method foo ()
      for (x)
        if (y)
          unless (z)
            block ()
              "..."
            end all;

Instead of:
    define method foo ()
      for (x)
        if (y)
          unless (z)
            block ()
              "..."
            end block;
          end unless;
        end if;
      end for;
    end method;

Given the example above, can I conclude that Apple (still) uses
lines-of-code per time-unit to measure productivity?  If so, Dylan will
prove to be highly productive.  Which points to a business opportunity for
some motivated individuals - You could produce massive gains in
productivity by designing a language in which each reserved word could span
multiple lines!  d
                  e
                   f
                    i
                     n
                      e
                       ...
Whoa, he's producing 10,000 lines per day!  Don't lose him!

And then you could build and sell an editor to highlight things readably!

Hell, just require every keystroke to be on a seperate line.  Let's think
of a name... "Lylan"  (Line Language).  Oh, better yet...  Unix - rm, ls,
mv, cp, ed, dc, dd, at, as, w ...

-- Ed "Off the deep end" Gamble

Clearly not working for a company that expects me to do anything.



Mon, 23 Dec 1996 08:56:37 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

...

Quote:

> Dylan Syntax needs an 'end-all' core-word... then we get
>     define method foo ()
>       for (x)
>    if (y)
>      unless (z)
>        block ()
>          "..."
>        end all;

> Instead of:
>     define method foo ()
>       for (x)
>    if (y)
>      unless (z)
>        block ()
>          "..."
>        end block;
>      end unless;
>    end if;
>       end for;
>     end method;

...

And I suppose that for C, this is too complicated:

        int foo()
        {
            for(x = 0; ...){
                if (y) {
                    if (! z) {
                      blah blah ...
                    }
                }
            }
        }

and we need a special ctrl-shift-meta-bucky-brace to end all those at the
same time too.

I don't buy it.

Quote:

> -- Ed "Off the deep end" Gamble

> Clearly not working for a company that expects me to do anything.

Joe Wilson



Wed, 25 Dec 1996 09:42:23 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

: And I suppose that for C, this is too complicated:

:  int foo()
:  {
:      for(x = 0; ...){
:          if (y) {
:              if (! z) {
:         blah blah ...
:              }
:          }
:      }
:  }

You wouldn't do this anyway. You'd use

int foo(void)
{
    for(x = 0; ...)
        if (y)
            if (! z) {
  blah blah ...
     }

Quote:
}

Perhaps something similar in Dylan would be preferable to forcing people to
close IFs, FORs etc with explicit terminators for single-line bodies.

Tony

---

Virtual Reality, Scheme, Smalltalk-80, Dylan, Operating Systems...



Thu, 26 Dec 1996 15:44:07 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

Quote:


> > Instead of:
> >     define method foo ()
> >       for (x)
> >       if (y)
> >         unless (z)
> >           block ()
> >             "..."
> >           end block;
> >         end unless;
> >       end if;
> >       end for;
> >     end method;

> ...

> And I suppose that for C, this is too complicated:

>    int foo()
>    {
>        for(x = 0; ...){
>            if (y) {
>                if (! z) {
>                  blah blah ...
>                }
>            }
>        }
>    }

> and we need a special ctrl-shift-meta-bucky-brace to end all those at the
> same time too.

> I don't buy it.

The problem is in C, you have to type only 4 braces (assuming that your editor
helps with indentation) but in Dylan you type 47 character so you might and
end all in dylan but not in C. And you have to know what type of block you
are ending at each step. Frankly I think it is insane.

Muzaffer

The opinions expressed above are those of the author and don't reflect the
views and policies of Microsoft Corporation.



Fri, 03 Jan 1997 07:15:57 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim


Quote:
> The problem is in C, you have to type only 4 braces (assuming that your editor
> helps with indentation) but in Dylan you type 47 character so you might and
> end all in dylan but not in C. And you have to know what type of block you
> are ending at each step. Frankly I think it is insane.

(1) If you know why you are closing a scope don't you also know what kind
of scope it is (or do you just type braces until the compiler stops
complaining)?

(2) I believe the designator for what type of block you are closing is
optional, anyway.

(3) A good set of macros for any decent text editor can readily insert both
the initial form and the closing form at the same time and leave you
inserting code in the middle.



Sat, 04 Jan 1997 09:16:53 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

   The problem is in C, you have to type only 4 braces (assuming that your editor
   helps with indentation) but in Dylan you type 47 character so you might and
   end all in dylan but not in C. And you have to know what type of block you
   are ending at each step. Frankly I think it is insane.

Since this only affects source code and not object code size, the issue is
pretty trivial.  Of course, when it comes to language religion, the heat
of the argument is always inversely proportional to its importance!

It's unfortunate that the Dylan crew seems to have decided against defining
an abstract syntax layer for the language, which would allow multiple parsers
and multiple syntaxes to coexist, and thereby render all the syntax arguments
moot.  There is sufficient practical experience with other Lisp dialects and
with Applescript to show that it would work just fine.  Sigh...

                                                        Stan Shebs



Sun, 05 Jan 1997 02:19:57 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

: (1) If you know why you are closing a scope don't you also know what kind
: of scope it is (or do you just type braces until the compiler stops
: complaining)?

I type braces.  Just call me a Lisp programmer, but that's how I program.  And
do a dang good job at it too.  The start/end stuff is a pain in the neck.

: (3) A good set of macros for any decent text editor can readily insert both
: the initial form and the closing form at the same time and leave you
: inserting code in the middle.

Languages are meant to help, not hinder.  If we have to use a tool in
order to use a tool, what's the point?    I want to see Dylan in every
pot.  To do that, we can't say "well, if you want to _really_ program in
the language, you have to use/have extensive knowledge of Super Editor X."
We need to make the language itself useable.

Thank goodness natural languages don't work this way!

+--------------------------------------------------------------+
| Sean Luke                             This signature no verb |


+------------------------oOO--(_)--OOo-------------------------+



Sun, 05 Jan 1997 10:10:47 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

Quote:
>(3) A good set of macros for any decent text editor can readily insert both
>the initial form and the closing form at the same time and leave you
>inserting code in the middle.

In fact, there is already a similar critter.  Dylan-mode.el for Emacs
has a function called dylan-insert-block-end.  You type
    if (foo)
and invoke that function, and it'll put in "end if;", indented and
everything.  Bind it to the key of your choice.

(Dylan-mode.el and the Mindy sources are available from
http://legend.gwydion.cs.cmu.edu:8001/gwydion/mindy/)

-Nick Kramer



Mon, 06 Jan 1997 04:46:26 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

   (1) If you know why you are closing a scope don't you also know what kind
   of scope it is (or do you just type braces until the compiler stops
   complaining)?

The subject may be a bit different in Scheme (Lisp) because there are
much (MUCH) more nested scopes, but yes, that's exactly what I'm
doing. I usually don't care about what I'm closing (that's done and
over), but where I'm going on. So I close brackets and watch Emacs
highlight the corresponding opening bracket until I've reached the
level where I wanted to go.

  As someone pointed out in a previous article, most programmers look
at the whitespace (level of indentation) anyway. In fact, I've thought
of writing an Emacs macro that closes brackets until the level of
indentation of the next line is reached. I use this quite often,
e.g. when modifying one branch of an if form. The level of indentation
of the else-branch and the following forms is supposed to stay the
same.

   (2) I believe the designator for what type of block you are closing is
   optional, anyway.

Ok, in Scheme it's `)' all the way down anyway.

   (3) A good set of macros for any decent text editor can readily insert both
   the initial form and the closing form at the same time and leave you
   inserting code in the middle.

From my experience, this kind of macro is not very useful. Quite
frequently, I want to wrap a form around an expression I've already
written. For this, structure-macros are not very convenient.

--
--axe

 =:-)                                                         * Axel Wienberg
 "#     "...or is it just like life: interesting in bits,
         but no substitute for the real thing..."
                                          Douglas Adams



Tue, 07 Jan 1997 21:43:17 GMT  
 C/C++ Warm Fuzzy Feelings.... Dylan-Interim

Quote:


>    (1) If you know why you are closing a scope don't you also know what kind
>    of scope it is (or do you just type braces until the compiler stops
>    complaining)?

> The subject may be a bit different in Scheme (Lisp) because there are
> much (MUCH) more nested scopes, but yes, that's exactly what I'm
> doing. I usually don't care about what I'm closing (that's done and
> over), but where I'm going on. So I close brackets and watch Emacs
> highlight the corresponding opening bracket until I've reached the
> level where I wanted to go.

So, you are relying on the editor.  The complaint most frequently raised
about using editor macros to insert structures is that it depends on
special features in the editor.  Blinking parentheses is also a special
editor feature.

Quote:

>   As someone pointed out in a previous article, most programmers look
> at the whitespace (level of indentation) anyway. In fact, I've thought
> of writing an Emacs macro that closes brackets until the level of
> indentation of the next line is reached. I use this quite often,
> e.g. when modifying one branch of an if form. The level of indentation
> of the else-branch and the following forms is supposed to stay the
> same.

>    (2) I believe the designator for what type of block you are closing is
>    optional, anyway.

> Ok, in Scheme it's `)' all the way down anyway.

>    (3) A good set of macros for any decent text editor can readily insert both
>    the initial form and the closing form at the same time and leave you
>    inserting code in the middle.

> From my experience, this kind of macro is not very useful. Quite
> frequently, I want to wrap a form around an expression I've already
> written. For this, structure-macros are not very convenient.

Automatic parenthesis matching is of somewhat less utility here since you
need to find the end of the expression.  Now, one nice thing some editors
do is automatically selecting an entire parenthesized (or brace delimited)
expression with appropriate attention paid to nesting.  Similar tools can
be written for Dylan-like syntax; in fact, I believe MPW has some though
not as part of the standard UI.

In my experience when writing Scheme or LISP code, parenthesis matching is
crucial but mostly because (a) you tend to nest much more deeply since
everything is parenthesized and (b) all parentheses look alike.  Dylan's
syntax doesn't suffer from this nearly as much since I'm not likely to nest
my control structures so deeply as to blow my mental stack and the
different terminators actually are (can be) different.

Consider:

(if (zero? n) (do-something (evaluate-a-parameter))
              (do-something-else (evaluate-something-else
(and-its-parameter))))

v.

if (zero? (n))
   do-something (evaluate-a-parameter ())
else
   do-something-else (evaluate-something-else (and-its-parameter))
end if

I've probably got the Dylan syntax slightly wrong and the need to put
parentheses around the conditional for the if is an annoying C-ism (why not
just go the full Pascal/Modula route and allow "if zero? (n) then"), but
nowhere do I need to use more than two identical scope closures in a row.

- Mark Hamburg

P.S. On the other hand, for code that works on code, Lisp has the beauty of
coming "pre-parsed".



Wed, 08 Jan 1997 01:22:37 GMT  
 
 [ 44 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Warm and fuzzy feeling

2. Warm, Fuzzy Feeling

3. to CS: or not to CS: in F-PC assembler

4. Intro CS book using Dylan?

5. Dylan Interim Reference Manual now available

6. Dylan Interim Manual available via WWW

7. Dylan Interim Reference Manual now available

8. C is dead, C++ is moribund, I'm not feeling too well myself

9. Fuzzy in FPL (fuzzy functions/objects)

10. SOURCES SOUGHT: Fuzzy Prolog and Fuzzy Prolog Applications

11. Camp Smalltalk (CS 6) registration

12. APL as First Language for CS

 

 
Powered by phpBB® Forum Software