Morpheus пишет:
Ну а какой язык в комбинации с Eclipse позволит написать прогу в 1000 строк с кучей Linked Lists и чтоб она работала с превого-же запуска?

Коммерческое ПО = у производителей будет неудачный год и проект заглохнет с концами, т.к. исходников нет

гугл хром опенорцовый. и что-то я не вижу в его взлетающих рейтингах каких либо намеков на сомнительное будущее

Life As a C/Win32 API Programmer
Traditionally speaking, developing software for the Windows family of operating systems involved
using the C programming language in conjunction with the Windows application programming
interface (API). While it is true that numerous applications have been successfully created using this
time-honored approach, few of us would disagree that building applications using the raw API is a
complex undertaking.

The first obvious problem is that C is a very terse language. C developers are forced to contend
with manual memory management, ugly pointer arithmetic, and ugly syntactical constructs. Furthermore,
given that C is a structured language, it lacks the benefits provided by the object-oriented
approach (can anyone say spaghetti code?). When you combine the thousands of global functions
and data types defined by the Win32 API to an already formidable language, it is little wonder that
there are so many buggy applications floating around today.

Life As a C++/MFC Programmer
One vast improvement over raw C/API development is the use of the C++ programming language.
In many ways, C++ can be thought of as an object-oriented layer on top of C. Thus, even though
C++ programmers benefit from the famed “pillars of OOP” (encapsulation, inheritance, and polymorphism),
they are still at the mercy of the painful aspects of the C language (e.g., manual memory
management, ugly pointer arithmetic, and ugly syntactical constructs).

Despite its complexity, many C++ frameworks exist today. For example, the Microsoft Foundation
Classes (MFC) provide the developer with a set of C++ classes that facilitate the construction of
Win32 applications. The main role of MFC is to wrap a “sane subset” of the raw Win32 API behind a
number of classes, magic macros, and numerous code-generation tools (a.k.a. wizards). Regardless
of the helpful assistance offered by the MFC framework (as well as many other C++-based windowing
toolkits), the fact of the matter is that C++ programming remains a difficult and error-prone
experience, given its historical roots in C.

Life As a Visual Basic 6.0 Programmer
Due to a heartfelt desire to enjoy a simpler lifestyle, many programmers have shifted away from the
world of C(++)-based frameworks to kinder, gentler languages such as Visual Basic 6.0 (VB6). VB6 is
popular due to its ability to build complex user interfaces, code libraries (e.g., COM servers), and
data access logic with minimal fuss and bother. Even more than MFC, VB6 hides the complexities
of the raw Win32 API from view using a number of integrated code wizards, intrinsic data types,
classes, and VB-specific functions.

The major downfall of VB6 (which has been rectified given the advent of the .NET platform) is
that it is not a fully object-oriented language; rather, it is “object aware.” For example, VB6 does not
allow the programmer to establish “is-a” relationships between types (i.e., no classical inheritance)
and has no intrinsic support for parameterized class construction. Moreover, VB6 doesn’t provide
the ability to build multithreaded applications unless you are willing to drop down to low-level
Win32 API calls (which is complex at best and dangerous at worst).

Life As a Java/J2EE Programmer
Enter Java. Java is an object-oriented programming language that has its syntactic roots in C++. As
many of you are aware, Java’s strengths are far greater than its support for platform independence.
Java (as a language) cleans up many unsavory syntactical aspects of C++. Java (as a platform)
provides programmers with a large number of predefined “packages” that contain various type
definitions. Using these types, Java programmers are able to build “100% Pure Java” applications
complete with database connectivity, messaging support, web-enabled front ends, and a rich
desktop user interface.

Although Java is a very elegant language, one potential problem is that using Java typically
means that you must use Java front-to-back during the development cycle. In effect, Java offers little
hope of language integration, as this goes against the grain of Java’s primary goal (a single programming
language for every need). In reality, however, there are millions of lines of existing code out
there in the world that would ideally like to commingle with newer Java code. Sadly, Java makes this
task problematic. While Java does provide a limited ability to access non-Java APIs, there is little
support for true cross-language integration.

Life As a COM Developer
The Component Object Model (COM) was Microsoft’s previous application development framework.
COM is an architecture that says in effect, “If you build your classes in accordance with the
rules of COM, you end up with a block of reusable binary code.”

The beauty of a binary COM server is that it can be accessed in a language-independent manner.
Thus, C++ programmers can build COM classes that can be used by VB6. Delphi programmers
can use COM classes built using C, and so forth. However, as you may be aware, COM’s language
independence is somewhat limited. For example, there is no way to derive a new COM class using
an existing COM class (as COM has no support for classical inheritance). Rather, you must make use
of the more cumbersome “has-a” relationship to reuse COM class types.

Another benefit of COM is its location-transparent nature. Using constructs such as application
identifiers (AppIDs), stubs, proxies, and the COM runtime environment, programmers can
avoid the need to work with raw sockets, RPC calls, and other low-level details. For example, consider
the following VB6 COM client code:

' The MyCOMClass type could be written in
' any COM-aware language, and may be located anywhere
' on the network (including your local machine).
Dim obj as MyCOMClass
Set obj = New MyCOMClass ' Location resolved using AppID.
obj.DoSomeWork

Although COM can be considered a very successful object model, it is extremely complex
under the hood (at least until you have spent many months exploring its plumbing—especially if
you happen to be a C++ programmer). To help simplify the development of COM binaries, numerous
COM-aware frameworks have come into existence. For example, the Active Template Library
(ATL) provides another set of C++ classes, templates, and macros to ease the creation of COM types.
Many other languages also hide a good part of the COM infrastructure from view. However,
language support alone is not enough to hide the complexity of COM. Even when you choose a
relatively simply COM-aware language such as VB6, you are still forced to contend with fragile registration
entries and numerous deployment-related issues (collectively, and somewhat comically,
termed DLL hell).

Life As a Windows DNA Programmer
To further complicate matters, there is a little thing called the Internet. Over the last several years,
Microsoft has been adding more Internet-aware features into its family of operating systems and
products. Sadly, building a web application using COM-based Windows Distributed interNet Applications
Architecture (DNA) is also quite complex.

Some of this complexity is due to the simple fact that Windows DNA requires the use of numerous
technologies and languages (ASP, HTML, XML, JScript, VBScript, and COM[+], as well as a data
access API such as ADO). One problem is that many of these technologies are completely unrelated
from a syntactic point of view. For example, JScript has a syntax much like C, while VBScript is a
subset of VB6. The COM servers that are created to run under the COM+ runtime have an entirely
different look and feel from the ASP pages that invoke them. The result is a highly confused mishmash
of technologies.

Furthermore, and perhaps more important, each language and/or technology has its own type
system (that may look nothing like another’s type system). Beyond the fact that each API ships with
its own collection of prefabricated code, even basic data types cannot always be treated identically.
A CComBSTR in ATL is not quite the same as a String in VB6, both of which have nothing to do with a
char* in C.

The .NET Solution
So much for the brief history lesson. The bottom line is that life as a Windows programmer has been
tough. The .NET Framework is a rather radical and brute-force approach to making our lives easier.
The solution proposed by .NET is “Change everything” (sorry, you can’t blame the messenger for the
message). As you will see during the remainder of this book, the .NET Framework is a completely
new model for building systems on the Windows family of operating systems, as well as on numerous
non-Microsoft operating systems such as Mac OS X and various Unix/Linux distributions. To
set the stage, here is a quick rundown of some core features provided courtesy of .NET:

• Comprehensive interoperability with existing code: This is (of course) a good thing. Existing
COM binaries can commingle (i.e., interop) with newer .NET binaries and vice versa. Also,
PlatformInvocation Services (PInvoke) allows you to call C-based libraries (including the
underlying API of the operating system) from .NET code.

• Complete and total language integration: .NET supports cross-language inheritance, crosslanguage
exception handling, and cross-language debugging of code.

• A common runtime engine shared by all .NET-aware languages: One aspect of this engine is a
well-defined set of types that each .NET-aware language “understands.”

• A comprehensive base class library: This library provides shelter from the complexities of raw
API calls and offers a consistent object model used by all .NET-aware languages.

• No more COM plumbing: IClassFactory, IUnknown, IDispatch, IDL code, and the evil variantcompliant
data types (BSTR, SAFEARRAY, and so forth) have no place in a .NET binary.

• A truly simplified deployment model: Under .NET, there is no need to register a binary unit
into the system registry. Furthermore, .NET allows multiple versions of the same *.dll to
exist in harmony on a single machine.

As you can most likely gather from the previous bullet points, the .NET platform has nothing to
do with COM (beyond the fact that both frameworks originated from Microsoft). In fact, the only
way .NET and COM types can interact with each other is using the interoperability layer.