|
in reply to Choosing a Platform
I have no doubt that Perl can do the job for you, but your list of requirements is... well, not a list of requirements. There is no way you can know that you need "run-time definition of new classes and methods, without performance penalties" before you've even chosen a platform! Different platforms handle situations in different ways, and you should really do as the Romans (or Java programmers) do when you're in Rome. Right now, you seem to have a pre-conceived design based on what you know about Perl, which is fine, but don't bother pretending you are considering other languages then.
I'm confident that you could build whatever this project is in Java or ASP.NET. You could avoid the cost and most of the problems with Java by using open source tools instead of the expensive commercial products. However, if you have a good development team that wants to use Perl, just do it. If you are looking for help with political arguments that your managers are making against Perl, then ask for that. |
Re^2: Choosing a Platform
by drago99 (Sexton) on Jul 23, 2004 at 00:51 UTC
|
- Runtime definition of classes and methods.
The main ideas here are:
- We want our installed codebase on the web servers to be as minimal as possible while still leveraging a large number of classes and methods.
- Less code is a good thing. If we can shave off several thousand lines of code to write, document and debug, then that's great.
- This thing has to scale out in a big way. The less we have to worry about quirky behavior of any kind, the better.
- If we can look at 8 lines of code on a web server and see that it's looping through the items in your cart, sorting them by name, calculating the subtotal, looking for cross-selling relationships, checking for discounts and making sure we still have all you items in stock, that's a good thing.
- Declaring everything we want to iterate through as Iteratable, as well as defining its One True Sort Method, is too much work. Let the machines get paid for that.
Defining all these methods on the core servers, and also defining "pass-through" methods on the web servers would defeat the point of having lots of functionality, but very little code.
If, on a web server, I say: User myUser = User.retrieve(12); I want it to go get user #12 from the core server. I don't want to have to specify that this method is somehow special because it, like every other method for every single object, is defined within the core.
The other part of the problem is if I want to override "User.retrieve()" locally. That local method should still be able to call it's superclass' method on the core server.
With Perl, this is easy: Just use AUTOLOAD. With C#, it is possible, but not easy. There is currently no C# equivalent. We would have to define the same methods locally (by hand), but have them call out to the core using webservices. If we have 100 servers running as clients to the core, we would have to go update 100 servers with new methods whenever we add new functionality. If our application has 1000 methods running on 100 servers, it can become unmanagable very quickly.
Consider this scenario. You have 30 websites running as clients on 1 server. Website#1 wants their Contacts to have unique email addresses, but Website#2 doesn't. Website#3 wants 1 Contact registration per household, Website#4 wants at least 3.
We can simply have domain-level Class method overrides take care of the Contact.Create() method, leaving the rest of Contact alone.
We could have implemented some front-end logic on their website's lead-capture form, but what about the administrative tool which everyone uses? We couldn't enforce the same validation/requirements on the backend this way.
We can offer sensible default behavior out of the box, but when (not if) our customers come to us with special requirements, we can now accomidate them with a reasonable amount of effort, while leaving our other customers' data, objects and experience out of it.
I would be very interested in finding out techniques for achieving the same kind of runtime flexibility and extensibility using other development platforms out there. In fact it could make writing the plugins for other platforms a bit easier later on.
Thanks!
| [reply]
[d/l]
[select] |
|
|
These still aren't really requirements. I was thinking of something like "handle customization of system functions for individual customers in a way that minimizes our work." Assumptions about using multipe servers, remote methods, etc. are all design, not requirements, and they are affected by your choice of platform.
You talk about code generation as a way to achieve ease of maintenance and avoid "quirky" behavior. In general, code generation is pretty confusing and error-prone, and often makes maintenance harder.
Then you're talking about remote method calls, without any context for why they have to happen. Your first goal should be to eliminate as many remote calls as you can, since they will slaughter the performance of your system. If you do have to do something remotely, that still doesn't mean you need AUTOLOAD (another rather quirky and error-prone feature). You can do this sort of thing with proxy objects, or various rmeote method call systems that different platforms supports.
I don't know enough about your system to give you concrete advice, so all I'm really saying is that deciding you need functionality along the lines of AUTOLOAD before you have chosen a platform seems backwards to me and implies that you really have chosen a platform already in your mind.
| [reply] |
|
|
| [reply] |
|
|
Woops, forgot to log in before I posted.
| [reply] |
|
|
While this is indeed the most measurable decision you can make, it is hardly the most important. I have seen teams argue for months on platform choice. At the same time, they spend zero seconds arguing on the importance of testing, hiring experts, agile process, or the other important issues.
Must be something about the visibility of the platform choice (look he is using Visual Studio!) vs. the non-visibility of the important stuff.
Cannot remember the name of the famous consultant, who has been on many a project, and was asked: what is the most productive platform? His answer: it makes no difference, as long as the team gells arount it, and has a passion for it.
| [reply] |
|
|
While this is indeed the most measurable decision you can make, it is hardly the most important.
I agree, to a point.
We took a task-by-task look at how much code (and therefore how much time) it takes to do 10 common tasks in Java, .NET and Perl.
- Regex search-n-replace.
- Read in a file, line by line, storing only the lines that match a regex.
- Open a recordset and iterate through it.
- Make an HTTP request.
- Perform XSLT transformations on XML.
- Iterate through a hash or other deeply-nested data structure.
- Sort an array or hash, by keys or values, with your own sorting algorithm.
- Append variables and static strings.
- Run another program and collect its STDOUT.
- Execute part of your program within another thread, or fork off a separate process.
When writing a web-based application, these are arguably some of the most common tasks. If each one only takes 1-2 lines of code, or if each one takes 5-10 or 15-20 lines of code, it can make a serious difference in the amount of time it takes to write, and the amount of code you have to maintain.
Bugs are more easily identified in less code. That's a pretty important factor to take into account, IMHO.
| [reply] |
|
|
