Datasheet

4
Part I: Design Strategies
Defining the Design Strategy Elements
It’s natural to say at the outset of a project that you want to accomplish a particular task. You don’t know
how you’ll accomplish it at this point, but simply that you plan to accomplish it. Before you can defi ne a
language environment, you have to have some idea of what you want to accomplish. In many cases, you
need to consider some rudimentary steps to accomplish your goal as well. For example, you may want
to write an application that retrieves data from a Web service, performs some analysis on that data, and
presents it to the user. Each of these tasks forms a design strategy element for your application.
Developers can become stuck in a rut when it comes to programming languages. When you talk to some-
one who’s used Visual Basic exclusively, that person can normally tell you about all the inadequacies of
C# in detail without too much thought. Likewise, developers who use C# exclusively often see the warts
found in Visual Basic quite easily. A developer who takes time to learn both C# and Visual Basic will
tell you that each has some distinct advantages and disadvantages, but that you can develop most appli-
cations using either language.
However, some languages do provide a specifi c set of features that differ from common programming
languages. For example, you can use F# (I’ll describe this new Microsoft language later in the chapter)
to perform list processing, pattern matching, and other forms of analysis. Microsoft even makes it easy
to combine C# or Visual Basic with F# so that you can obtain the best of both languages in a single
application. When you consider the sample application described earlier in this section, you could use:
C# to obtain the data from the Web service ❑
F# to process that data ❑
C# to display the data to the user ❑
This second case points out a scenario where using multiple languages is more than a political state-
ment; it’s a necessity to make application development as easy as possible. The advanced features of a
language can easily offset the added complexity of using multiple languages in many cases.
Don’t assume that a developer on your team has experience in only one or two languages. The use of
a particular language by the developer may simply indicate that the company hired the developer to
use the language. Many developers have experience in multiple languages. For example, even though I
mainly work with Visual Basic and C#, I have also worked with everything from Assembler and ROM
BASIC to LISP and Prolog. I’ve worked relatively often with PHP, Java, and C++ as well. However,
unless someone asks me about my skill set, they may simply assume my language knowledge includes
mainly Visual Basic and C#.
Of course, you need someone on your development team with F# experience to write an application that
uses F# for analysis purposes. Depending on the inventory you conduct, you may fi nd that all your devel-
opers know C# or Visual Basic. In this case, the optimal language environment doesn’t use F#, but you
should still consider using the best language for the job at the outset of the planning process.
Your strategy has to consider the developers in your team, even if you have a team of one. You don’t
want to create an application where half the team twiddles its collective thumbs waiting for the other
half of the team to complete a process. An application development effort may require that you write
the low-level code using C# and the user display elements in Visual Basic. With proper planning, you
can move the development process along rapidly by letting each team complete the part of the applica-
tion most suited to its particular language.
15962c01.indd 415962c01.indd 4 1/23/09 5:44:59 AM1/23/09 5:44:59 AM