The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Weblogs Forum
The Real Lesson of Flex

25 replies on 2 pages. Most recent reply: Oct 24, 2008 6:03 AM by Rob Reynolds

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 25 replies on 2 pages [ « | 1 2 ]
Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 20, 2007 9:37 AM
Reply to this message Reply
Advertisement
Most code generation works like this: you write a script that reads some input, and outputs code (in text format). The resulting code is then compiled. But there are other forms of code generation. Lisp code generation is much easier and more structured because you don't generate stings: you generate parse trees. If you encounter duplicate code. You'll first try to remove the duplication with functions/classes/...if that doesn't work you write a little code generator. Code generators work exactly like functions, but they run at compile time instead of run time. If code generators operate on syntax trees and if they are part of your program (not an external tool) then you can extend the language instead of creating an entirely new language.

Magic is just code you don't understand. In some cases that's the code's fault, but in some cases it's your fault. OOP is magic for some people and code generation is magic for others. Code generation can be very easy to understand if you have a lot of small code generators working together (like methods and classes) instead of one big code generator (all code in the main() method).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Real Lesson of Flex Posted: Mar 20, 2007 9:59 AM
Reply to this message Reply
"Magic is just code you don't understand."

Magic is code that I cannot expose and trace via a debugger - either the source is missing, or freaky runtime tricks are getting played. A little magic can be powerful. A lot of magic invariably leads to big problems.



Posts: 55
Nickname: lazydaze
Registered: Feb, 2006

Re: The Real Lesson of Flex Posted: Mar 20, 2007 10:46 AM
Reply to this message Reply
> "Magic is just code you don't understand."
>
> Magic is code that I cannot expose and trace via a
> debugger - either the source is missing, or freaky runtime
> tricks are getting played. A little magic can be
> powerful. A lot of magic invariably leads to big problems.

All we're talking about here is laying out a Java component in XML, aren't we? Browsers do a lot of magic under the surface when rendering HTML, but that never troubles anyone. Maybe using the terms DSL and 'code generation' is making this sound more complicated than it really is? When I was playing with XAMJ (XML layout/Java scripting) a year or so back, I never encountered any of these problems. Everything just kinda worked, just like HTML works.

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 20, 2007 12:08 PM
Reply to this message Reply
> "Magic is just code you don't understand."
>
> Magic is code that I cannot expose and trace via a
> debugger - either the source is missing, or freaky runtime
> tricks are getting played. A little magic can be
> powerful. A lot of magic invariably leads to big problems.

Then code generation certainly is not magic. (1) you can trace it because it generates normal (traceable) code (2) you can view the source (how do you write a program without viewing it??) (3) it's executed at compile time, not at run time, so no "freaky runtime tricks".

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Real Lesson of Flex Posted: Mar 20, 2007 2:38 PM
Reply to this message Reply
> Then code generation certainly is not magic. (1) you can
> trace it because it generates normal (traceable) code (2)
> you can view the source (how do you write a program
> without viewing it??)

This is only true if I can trace the generated code back to the written code in a transparent way. If the relationship is not obvious - then it is still magic.

I once worked on a system written in a language called flecs. Flecs is a sort of pseudo OO language but it does not have a compiler. Instead it emits very ugly FORTRAN. It was virtually impossible to trace problems back to the responsible source code.

Write in one language, generate another, then compile/run it - this is dangerous if there is not adequate mapping information kept to allow mapping from generated code back to original source.

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 20, 2007 2:48 PM
Reply to this message Reply
> Write in one language, generate another

That's why the same language should be used as both the generator and the target...

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Real Lesson of Flex Posted: Mar 20, 2007 8:22 PM
Reply to this message Reply
> > Write in one language, generate another
>
> That's why the same language should be used as both the
> generator and the target...

Same problem exists - you must be able to map from any statement in the generated code back to the source code - or how will you understand how to fix things?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Real Lesson of Flex Posted: Mar 21, 2007 9:01 AM
Reply to this message Reply
But it would be so advantageous for Java to adopt S-expression capabilities through tuples...I do not understand why everyone overlooks this possibility.

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: The Real Lesson of Flex Posted: Mar 21, 2007 9:32 AM
Reply to this message Reply
> But it would be so advantageous for Java to adopt
> S-expression capabilities through tuples...I do not
> understand why everyone overlooks this possibility.

Tuples or records? The example you posted seems to be a mix of the two. Text is named (like in a record), but the button is unnamed (like in a tuple).

I think syntactic support for records/tuples is a good solution for Java because it's a relatively small addition that will allow much better APIs.

Rob Reynolds

Posts: 2
Nickname: rreynolds
Registered: Oct, 2008

Re: The Real Lesson of Flex Posted: Oct 24, 2008 5:56 AM
Reply to this message Reply
I believe the failure of Applets was simply they intruded into terratory (client) dominated by markup language developers. Moving from HTML/Script to JAVA/Swing/2D, etc. is a huge challenge.

Rob Reynolds

Posts: 2
Nickname: rreynolds
Registered: Oct, 2008

Re: The Real Lesson of Flex Posted: Oct 24, 2008 6:03 AM
Reply to this message Reply
Flex has allowed developers a way to ease into Applet-type solutions from a familiar markup perspective.

Flat View: This topic has 25 replies on 2 pages [ « | 1  2 ]
Topic: Goodbye Artima Previous Topic   Next Topic Topic: My experience with the EeePC 901 so far
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use