John Passaniti
|
| Posted: 06/24/2001, 8:20 PM |
|
I was poking around on the www.gotocode.com web site, and found something
strange. Under the "Community" tab, there is a poll for what is your
favorite programming language. In much the same way that idiot head hunters
think HTML is a programming language, this poll lists ASP as a programming
language.
It's not.
ASP is an object-oriented application framework that is *completely*
language independent. There is *nothing* in ASP that demands VBScript. You
can program ASP-based applications in JavaScript, Perl, Python, Ruby, Lua,
and even reportedly a crippled Forth and a dusty Rexx. As long as the
language has a binding to Microsoft's ActiveScripting framework, it will
work with ASP.
Why is this a big deal? Two reasons.
First, CodeCharge should offer additional targets for ASP. Since the object
model is the same, generating templates to handle ASP with PerlScript (for
example) shouldn't be that difficult. The ASP object model remains the
same, the only difference is the surrounding language that manipulates the
object model. There are lots of ASP developers (like myself) who never
touch VBScript. We use ASP with Perl or Python or other languages because
we don't want to be saddled with VBScript. CodeCharge's template-based
approach to code generation screams out for additional targets for ASP. And
this could serve to differentiate CodeCharge from other web application
tools.
Second, I have seen in this newsgroup and many others constant claims that
follow the form "PHP is better than ASP because VBScript sucks." Such
comments show the lack of understanding of what ASP is, or an assumption
that VBScript is somehow intimately tied to ASP. Likewise, www.gotocode.com
asking if ASP was a favorite programming language shows a similar lack of
understanding-- surprising for a company that should know better.
|
|
|
 |
Jeff Stuart
|
| Posted: 06/24/2001, 10:53 PM |
|
The problem John is that ASP is MAINLY used with VBScript (or Jscript if
you're so inclined). So while yes, you are correct that ASP is an
application framework, 99 times out of 100, if you ask someone about ASP,
they will be thinking of VBScript and IIS.
--
Jeff Stuart
jstuart@neo.rr.com
"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:9h6alq$1kg$1@news.codecharge.com...
> I was poking around on the www.gotocode.com web site, and found something
> strange. Under the "Community" tab, there is a poll for what is your
> favorite programming language. In much the same way that idiot head
hunters
> think HTML is a programming language, this poll lists ASP as a programming
> language.
>
> It's not.
>
> ASP is an object-oriented application framework that is *completely*
> language independent. There is *nothing* in ASP that demands VBScript.
You
> can program ASP-based applications in JavaScript, Perl, Python, Ruby, Lua,
> and even reportedly a crippled Forth and a dusty Rexx. As long as the
> language has a binding to Microsoft's ActiveScripting framework, it will
> work with ASP.
>
> Why is this a big deal? Two reasons.
>
> First, CodeCharge should offer additional targets for ASP. Since the
object
> model is the same, generating templates to handle ASP with PerlScript (for
> example) shouldn't be that difficult. The ASP object model remains the
> same, the only difference is the surrounding language that manipulates the
> object model. There are lots of ASP developers (like myself) who never
> touch VBScript. We use ASP with Perl or Python or other languages because
> we don't want to be saddled with VBScript. CodeCharge's template-based
> approach to code generation screams out for additional targets for ASP.
And
> this could serve to differentiate CodeCharge from other web application
> tools.
>
> Second, I have seen in this newsgroup and many others constant claims that
> follow the form "PHP is better than ASP because VBScript sucks." Such
> comments show the lack of understanding of what ASP is, or an assumption
> that VBScript is somehow intimately tied to ASP. Likewise,
www.gotocode.com
> asking if ASP was a favorite programming language shows a similar lack of
> understanding-- surprising for a company that should know better.
>
>
|
|
|
|
CodeCharge
|
| Posted: 06/24/2001, 11:36 PM |
|
Thanks John for your comments.
You're absolutely right and we'll correct the mistake, even though most
people wouldn't notice it 
Regarding CodeCharge, it is not simple to create new language patterns. Each
language pattern is handled separately and if any changes are made in the
application, currently 13 language patterns need to be updated. We can't
justifty supporting more technologies unless there is a serious demand for
them.
You may consider adding your wish to our GotoCode.com system and see for
yourself how it is rated by others. You may also open a discussion about the
subject. And possibly other people reading this message will voice their
opinion as well.
Future versions of CodeCharge may allow for more flexibility where it may be
possible to customize or create your own language pattern. This however
depends on several factors and wasn't decided at this point.
Regards,
Adam S.
YesSoftware
"John Passaniti" <nntp@JapanIsShinto.com> wrote in message
news:9h6alq$1kg$1@news.codecharge.com...
> I was poking around on the www.gotocode.com web site, and found something
> strange. Under the "Community" tab, there is a poll for what is your
> favorite programming language. In much the same way that idiot head
hunters
> think HTML is a programming language, this poll lists ASP as a programming
> language.
>
> It's not.
>
> ASP is an object-oriented application framework that is *completely*
> language independent. There is *nothing* in ASP that demands VBScript.
You
> can program ASP-based applications in JavaScript, Perl, Python, Ruby, Lua,
> and even reportedly a crippled Forth and a dusty Rexx. As long as the
> language has a binding to Microsoft's ActiveScripting framework, it will
> work with ASP.
>
> Why is this a big deal? Two reasons.
>
> First, CodeCharge should offer additional targets for ASP. Since the
object
> model is the same, generating templates to handle ASP with PerlScript (for
> example) shouldn't be that difficult. The ASP object model remains the
> same, the only difference is the surrounding language that manipulates the
> object model. There are lots of ASP developers (like myself) who never
> touch VBScript. We use ASP with Perl or Python or other languages because
> we don't want to be saddled with VBScript. CodeCharge's template-based
> approach to code generation screams out for additional targets for ASP.
And
> this could serve to differentiate CodeCharge from other web application
> tools.
>
> Second, I have seen in this newsgroup and many others constant claims that
> follow the form "PHP is better than ASP because VBScript sucks." Such
> comments show the lack of understanding of what ASP is, or an assumption
> that VBScript is somehow intimately tied to ASP. Likewise,
www.gotocode.com
> asking if ASP was a favorite programming language shows a similar lack of
> understanding-- surprising for a company that should know better.
>
>
|
|
|
|
John Passaniti
|
| Posted: 06/25/2001, 12:12 AM |
|
"Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
news:9h6jkg$8ff$1@news.codecharge.com...
> The problem John is that ASP is MAINLY used with
> VBScript (or Jscript if you're so inclined). So while
> yes, you are correct that ASP is an application framework,
> 99 times out of 100, if you ask someone about ASP,
> they will be thinking of VBScript and IIS.
I realize this. Most books and other references on ASP ignore the
possibility of using other languages, and so the "great unwashed" out there
believe that ASP is intimately tied with VBScript.
This misconception does not however prevent the CodeCharge folk from being
more correct and more specific in their language. References to ASP should
be qualified with what language is used to implement the ASP code. Thus
instead of simply saying "ASP" they should say "ASP/VBScript" or something
like that.
I realize some people will see this as a useless semantic argument. I see
it as more a matter of correctness and truth in advertising.
|
|
|
|
John Passaniti
|
| Posted: 06/25/2001, 1:22 AM |
|
"CodeCharge" <support@codecharge.com> wrote in message
news:9h6m4m$afk$1@news.codecharge.com...
> Thanks John for your comments.
> You're absolutely right and we'll correct the mistake,
> even though most people wouldn't notice it
I'm sure that is the case.
> Regarding CodeCharge, it is not simple to create new
> language patterns. Each language pattern is handled
> separately and if any changes are made in the application,
> currently 13 language patterns need to be updated. We
> can't justifty supporting more technologies unless there
> is a serious demand for them.
The real issue here is the level of abstraction your patterns operate at.
Right now, I imagine CodeCharge works by building up a large data structure
describing the whole project. That is, the CodeCharge user interface is
really an intelligent editor for this data structure. When it comes time to
generate code, a walk over the project data structure results in various
"patterns" to fire. For example, you might have a high-level pattern that
describes a grid form. This pattern then generates code for the language
and platform the user selects. (I'm sure there is more detail here. I'm
only describing the general approach you likely take.)
If you look at how traditional compilers work (such as GNU C), you see that
there is an intermediate language produced. That is, C code is converted to
an intermediate language (called RTL) and then intermediate language is then
compiled down to whatever target processor you are generating code for.
The same idea can apply to CodeCharge. When the project data structure is
walked to generate code, CodeCharge can generate an intermediate language
that describes the operation, instead of generating code for the actual
target.
The advantage would be that language patterns would be much simpler, easier
to create, and easier to support. High-level objects (like grids and input
forms) would be described not by the language templates, but at the level of
the intermediate language. That would allow CodeCharge to describe such
high-level objects once and only once. The grid would then decompose into a
simpler set of primitives that the langauge pattern would then handle.
I'm willing to bet that right now, when CodeCharge makes a change to a
high-level object like a grid, that change has to occur in every pattern for
every language and platform. It can't have escaped someone's notice that
the same technique of template-based code generation could be applied to
CodeCharge itself.
Or am I getting to "meta" for you? 
> Future versions of CodeCharge may allow for more flexibility
> where it may be possible to customize or create your own
> language pattern. This however depends on several factors
> and wasn't decided at this point.
I think the CodeCharge designers should realize that the idea of
template-driven code generation is not new, and there has been a lot of
published work by computer scientists on the subject. What CodeCharge is
doing can be done one better by competitors who seize on the idea of raising
high-level objects to an intermediate level above the target language. When
that happens, watch out.
|
|
|
|
|
