|
|
Subject: Re: What are your views on generics in java? - msg#00117
List: programming.language-of-the-year
William Tanksley, Jr (21.01. 11:15):
> Stefan Schmiedl <s@xxxxxx> wrote:
> > Thibaut BarrÃre (21.01. 00:18):
> > > > Out of curiosity: Forth is a language with a very simple syntax.
> > > > Are there any known refactoring *tools* out there?
>
> > > None that I know about - is there a market for forth refactoring tools ?
>
> > If there is, it's not very large ...
> > But I guess you hit the nail on the head. It's not complexity per se, be
> > it syntactic or semantic, which brings tools into existence, it's the
> > demand for them.
>
> > Now where does this demand have it's origin?
>
> Need. Your language has to be complex enough to NEED the refactoring
> tools (Forth doesn't because its syntax is so ... different), and yet
> simple enough that the tools are easier to write than just manually
> refactoring.
Is it the language or the programmer? I dimly remember reading about the
"Chuck Moore Way of Solving Problems" ... which is basically avoiding
them. The difficulty is still getting things done ... though it's not
always feasible for mortals.
I had an eye-opener lately, when I actually looked up the two methods I
needed to write a really simple shopping cart with Ajax and a ruby
backend. The web-shop is now a bunch of static HTML pages in a directory
requiring HTTP-authentication, a little bit of Prototype-based
AJAX-magic (without any XML, I might add) and another bunch of files
where the carts' contents are dumped. No database, no hassle with
sessions or cookies, nothing. There is almost no code left, either.
I do realise that I don't need a lot of code, because of some heavy
components working in the background, but still ...
Does one need refactoring tools because one didn't avoid problems when
he had a chance?
>
> Of course, there also has to be education. Many languages that could
> have used refactoring tools lived and died without them because nobody
> knew.
ho hum ... what about the other "old" languages, FORTRAN and LISP?
I remember reading about unit-testing for Common Lisp, but know nothing
about refactoring tools for the Great Old Ones ;->
s.
--
Stefan Schmiedl
+-------------------------------+----------------------------------------+
|Approximity GmbH | EDV-Beratung Schmiedl |
| http://www.approximity.com | Am BrÃuweiher 4, 93499 Zandt, Germany |
| mailto:stefan-BgpFEFc6EmWfJOJzLBvvIA@xxxxxxxxxxxxxxxx | Tel. (09944) 3068-98,
Fax -97 |
+-------------------------------+----------------------------------------+
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/pragprog/
<*> To unsubscribe from this group, send an email to:
pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: Code generation: examples
> I would like to ask the readers of this list about their experiences &
> opinions about code-generation and related meta-approaches (MDA/MDD/DSL etc).
> How hard it was to implement such approach? Did it give advantages in
> productivity/maintanance?
> ...
> Any other examples?
Code generation is not hard, but does require a mental shift. It's really just
another tool in the reuse toolkit, and one that is perhaps more useful in some
contexts than in others.
It has greatly reduced maintenance costs because there's fewer places where I
(an error-prone human) can inject errors into the system. Better, any error I
inject will show up in several 10's -- or 1000's -- of places at once.
> other examples?
I have three:
(1) using the C preprocessor
------------------------------
My most often used technique for code generation is to use the standard C
preprocessor (cpp). It turns normal usage on it's head, but it works really
well...
It's reversed from normal usage because instead of a #define that is used in
several places, you create a data table of macro calls in a header file:
A(a, T1, "a" ...)
A(b, T2, "b" ...)
...
#undef A
Then, where you want to generate code, you #define the macro (A, in this
example), the #include the file...
#define A(v_, t_, s_) void v_ ## __function ( t_ newval );
#include "db_A.h"
It was, for me, quite useful to generate boilerplate functions in C that avoid
the curse of "void *" - while at the same time ensuring that there can be only
one implementation -- in the #define that generates the code.
(2) shell scripts to generate boilerplate
------------------------------
Similar to the macros is boilerplate generation. If I'm building a class
hierarchy, I use a script to generate the boilerplate code.
while read a b c d; do
cat <<!EOF!
class $a : public $b {
private:
$c ${d}_;
public:
$a() : ${d}_() { }
virtual ~$a()
void $d($c newval) { ${d}_ = newval; } // yeah, getter/setter
$c $d() const { return ${d}_; } // - it's an example
};
!EOF!
done <<!EOF!
... long list of stuff ...
!EOF!
After running this script, you can tweak as necessary, which leads to...
(3) using global operations in an editor
------------------------------
Another, different, dimension of code generation is intelligent use of an
editor. I use vi, so the following description is vi-centric. I'm sure the
concepts transfer to any editor that allows global find/replace...
Given a transformation that you want to make in a file, place a unique sequence
of characters at each place where you need to make the change - then think of
each line as a turing machine - the character sequence you added is your
pointer, so you think in terms of transforms near the pointer, and the "code"
you write is in the edit command, rather than directly into the file buffer.
For example, I use "@@" as my marker, so I will place @@ at the end of every
line where I want to add a new method. Then, it is off to global commands:
:%s/ : .*{/&@@/
:%s/@@/@@public: void newmethod(int p) const { ... }/g
...
...
- First operation adds "@@" after every "class foo : public bar {"
- <scan file, remove @@ where not needed>
- Second operation adds a new method after each "@@"
When I'm done, replace the "@@" with a single unique char ("@" or "^" is good),
then run it thru tr(1) to move the new method to a different line:
tr '@' '\012' < oldfile.c > newfile.c; mv newfile.c oldfile.c
This also works for "grep -nw" to generate "ed" scripts, which sometimes do
just what you need
By the way, I write compilers and interpreters for a living, so I guess I'm a
code generator as well :)
Hope these examples help to explain one person's use of code generation
techniques.
- Bryan Ewbank
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/pragprog/
<*> To unsubscribe from this group, send an email to:
pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Next Message by Date:
click to view message preview
REBOL and Tcl (Code generation: examples)
Hi Mathieu,
(I got a little carried away here. :\ Just read the === lines for
top-level answers.)
MB> what would be, in your opinion, the top 3 (or top N) advantages of
MB> REBOL over Tcl ?
=== Size
REBOL Core is a ~220K download. View, the one with the built-in GUI
system, is a ~635K download. The ActiveState distro for Tcl/Tk (which
includes a lot of extra stuff I imagine) is 20M for Windows; 15M for
Linux.
=== Easy setup
Just a single EXE. For Core, just run it; REBOL/View has a built-in
installer, like you'd expect for most Windows apps. I haven't tried
the ActiveState stuff to say how it compares.
If you encap a script (bind the script to the runtime), it, too, can
be a single EXE; no external dependencies what-so-ever.
=== Datatypes
REBOL has strong typing, but is a dynamic language; values have type,
variables do not. There are a *lot* of datatypes in REBOL, many of
which you don't use directly, and some "pseduo-types" that are very
handy--e.g. number! is a pseudo-type that covers both integer! and
decimal! types.
It has the common types you'd expect; integer, decimal, string, char,
etc., but it also has a lot more (something like 50 total). e.g.
foreach val [
$100 name-qDqigq+Nkyk@xxxxxxxxxxxxxxxx http://www.rebol.com #123-45
%readme.txt 5x20 <h1> 1.0.0
] [print [type? val tab mold val]]
money $100.00
email name-qDqigq+Nkyk@xxxxxxxxxxxxxxxx
url http://www.rebol.com
issue #123-45
file %readme.txt
pair 5x20
tag <h1>
tuple 1.0.0
=== The PARSE function
I would never have imagined writing little languages the way I do. No
Lex or YACC; just a pseudo-BNF dialect that makes it possible for
non-rocket-scientists, like me, to perform this task without pain.
Heck, it's actually *fun*. :)
One of the great things about datatypes in REBOL, is that you can use
them when parsing, so you can parse by datatype matches. e.g. to parse
these inputs:
a: [deposit $100.00 in account #12345 at 10:00]
b: [withdraw $100.00 from #12345]
I could write the parse rule this way:
action=: [set action ['deposit | 'withdraw]]
account=: [['in | 'from] opt 'account set account issue!]
time=: ['at set time time!]
rules=: [
(time: 12:00) ; set default time
action= set amount money! account= opt time=
(
; do something with the data we parsed
print remold [action amount account time]
)
]
parse a rules=
parse b rules=
would produce:
[deposit $100.00 #12345 10:00]
[withdraw $100.00 #12345 12:00]
How much you break out sub-rules is totally up to you, and the
trailing = sign on the rule names is just a convention, not a syntax
rule.
=== The View and the VID (Visual Interface Dialect) systems
Now that the AGG engine is used, there is even more to like, but with
a 32-bit compositing engine and all the pipeline effects that are
built-in, you can make things look any way you want and do really cool
graphic stuff.
VID (the rough equivalent of Tk), makes simple GUIs easy, though
advanced work can take some digging in. The new RebGUI system that
some people have built has some great stuff, and there are a lot of
custom styles (widgets) that experts have built. The biggest problem
with VID is that people expect it to be the only GUI system out there,
when it's really more of a great "starter kit". It's good enough that
it's kind of discouraged people from building other systems (IMO).
VID may not be a general advantage over Tk, not for everyone, but it's
one of the things that grabbed me; it's just a REBOL dialect, so
there's a nicer integration compared to using Tk with some other
languages IMLE.
=== Use as a data exchange language
This is really what REBOL is all about. The fact that we use it mostly
as a programming language today obscures that. At one time they called
it a "messaging language", the goal being the exchange and
interpretation of semantic information.
It's as much personal preference as anything of course. I've tinkered
with a lot of languages--and continue to do so when I have time--but
REBOL clicked with me. I can use it to do *almost* everything I need;
I like having a single language I can use for both code and data; it's
default GUI system works well for me (most of the time :); PARSE is a
wonderful thing (I'm not much of a RegEx guy, beyond simple pattern
mathching--and, yes, I have Friedl's book); it's fun to tinker with,
and I get a *lot* out of thinking about things in a REBOL context.
A lot of other things I like about REBOL are also available in Tcl,
IIRC.
Now, I'm not a Tcl guy, but I would say that Tcl has a lot of
advantages over REBOL as well, many based on its maturity and
community (the REBOL community is awesome, but it's small). Things
like a standard package system and Unicode support are major
advantages, for example.
HTH!
--Gregg
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/pragprog/
<*> To unsubscribe from this group, send an email to:
pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Previous Message by Thread:
click to view message preview
Re: What are your views on generics in java?
Stefan Schmiedl <s@xxxxxx> wrote:
> Thibaut Barrère (21.01. 00:18):
> > > Out of curiosity: Forth is a language with a very simple syntax.
> > > Are there any known refactoring *tools* out there?
> > None that I know about - is there a market for forth refactoring tools ?
> If there is, it's not very large ...
> But I guess you hit the nail on the head. It's not complexity per se, be
> it syntactic or semantic, which brings tools into existence, it's the
> demand for them.
> Now where does this demand have it's origin?
Need. Your language has to be complex enough to NEED the refactoring
tools (Forth doesn't because its syntax is so ... different), and yet
simple enough that the tools are easier to write than just manually
refactoring.
Of course, there also has to be education. Many languages that could
have used refactoring tools lived and died without them because nobody
knew.
> Stefan Schmiedl
-Billy
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/pragprog/
<*> To unsubscribe from this group, send an email to:
pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Next Message by Thread:
click to view message preview
Re: What are your views on generics in java?
Tanton Gibbs wrote:
> There are so many tools beyond lex and yacc now (though you could use
> them as well) and parsing has progressed to the point where
> this should not be considered when designing or improving a language.
I'm not sure exactly what "this" is in the quote above (even when in the
context of the original post). And I agree that ease of parsing is not as
important as many other factors (eg end-programmer friendliness).
However, I do think we're going to rely more and more on automated tools
to do source transformations within the IDE, and that is going to put some
pressure on language design. For example, hat might mean doing syntactic
analysis every keystroke. So having a syntax that allows unambiguous
parsing of isolated fragments of code is probably a nice property to have
when you want responsive, interactive, code-manipulating IDEs.
Andrew
--
` __ _ __ ___ ___| |_____ personal site: http://www.acooke.org/andrew
/ _` / _/ _ \/ _ \ / / -_) blog: http://www.acooke.org/cute
\__,_\__\___/\___/_\_\___| aim: acookeorg; skype: andrew-cooke
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/pragprog/
<*> To unsubscribe from this group, send an email to:
pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|
|