osdir.com
mailing list archive

Subject: Re: What are your views on generics in java? - msg#00117

List: programming.language-of-the-year

Date: Prev Next Index Thread: Prev Next Index
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?
Yes No
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/
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by