A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I've seen people mention a development methodology of developing robust frameworks in a compilable laguage and gluing the pieces together using a script language.
Any texts describing that way of making software? It sounds like it has its merits, more rapid resonse to changes required by the users being the most obvious. But there are issues of security and user-tampering that should be considered.
If these problems have a solution, it could be a powerful technique.
Doesn't Windows Script Host work like this? The compiled framework is the objects that are surfaced through the various automation DLLs and then those objects are scripted. Or are you thinking of something at a higher level?
Tuesday, November 09, 2004
"Doesn't Windows Script Host work like this?"
Classic ASP is another example. Microsoft expected everyone to build web applications in VB and C++ and then use ASP to glue that to HTML presentation.
Sadly, web hosts don't like you installing your own binary components so pretty much all web applications were written entirely in ASP (with all it's insane limitations).
I think that .NET (and Java) provide much of the same benefits of scripting languages while still providing the traditional compilation step.
For many web applications, ASP classic, or plain JSP, or PHP, or whatnot, without any extra framework, are an ideal solution. The edit-build-test cycle is pretty much instantaneous. Scripting languages are fantastic for little problems, like simple content management for a small firm's website.
IMO, frameworks and the use of a compiled language only make sense if your site simply needs to be running all the time, integrate with other software, and perform complex functionality. An online bank comes to mind, or a payroll system for a large enterprise with a web front-end.
I have worked on large projects as an architect and lead developer using the classic ASP approach (2 years, swarms of people) and the framework plus compiled Java approach (large banks and so forth), and for all their faults, the projects with the classic ASP approach, while being shoddily programmed, were developed far quicker.
I don't know of any reference books discussing the technique in general, but it is true that almost all commercial video games are built on this model.
Much of the commercial software that I've written was built using a combination of interpreted and scripted components. I've used VB and C/C++ for one project, written my own simple scripting language for others.
To address your specific issue of:
"But there are issues of security and user-tampering that should be considered."
Most end-users are never going to even attempt to modify your application. If you package your application as a "normal" executable (most scripting languages support a "wrapper" for this), it probably won't even occur to them that it's possible.
For the few that might - you could place a digital signature, or even simple checksum on essential files and refuse to run if they're modified (or at least refuse to support any changes they make).
If you're writing for the mass-market, you'll probably need to keep all your security-related code in native code, obviously.
ColdFusion is probably the most common use of this. Its less of a scripting language even, and more of a markup language, but you can create custom tags and modules in java.
Tuesday, November 09, 2004
Yeah, just plain vanilla ASP is fine for a lot of applications (like FogBugz). I've written some non-trivial web-applications using ASP, with SQL Server back-end. It isn't pretty, but it works well enough.
I have to admit that I love the new ASP.NET environment, as it has allowed me to build a framework for the Vertical I'm working in and then "glue the bits together", in a Logo-style.
This is the classic OO idea, but the bits are at a much higher level of abstraction, so they are "bits" that a Business User would recognise and work with, like Broker, Client, Policy, etc.
Wednesday, November 10, 2004
One example of this was Groove versions 1.0-2.5. The core code was C++ with COM wrappers, while the tools were script.
As a developer you could see all the code for the standard Groove tools which was handy if you were developing custom tools. There were several hoops to jump through especially regarding threading and script.
With Groove 3, they have rewritten several of the script tools in C++ for performance reasons. It shows.
Thursday, November 11, 2004
John Ousterhout's (Tcl/Tk creator) paper "Scripting: Higher Level Programming for the 21st Century" might be the kind of reference you're looking for:
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz