Benjamin Shoemaker Dr.

Tircuit Programming Languages 13 September 2011 Language Design and Analysis Project Draft 1 A key issue in the field of software development is the sheer amount of unique programming languages available. Each language was designed for a specific type of hardware, application, or niche domain, and, while this is helpful when developing one of these certain types of programs, it prevents a single developer from easily working in unfamiliar situations. An individual could not be expected to have fully mastered ten's of programming languages suited for every occasion. Obviously, this creates problems for small organizations that can only afford to employ a limited information technology staff. As business begins to rely more and more on technology, an individual developer in that situation could be expected to develop software, both desktop and mobile, for use internally, while also maintaining a 'web-2.0' company website, and perhaps administrating the hosting server. Operating in this scenario, a company is forced to accept the cost and time overruns associated with retraining an employee as each new task arises, or simply replace that employee. Neither is an adequate solution. It seems then, that a unified, cross-platform, cross-domain programming language would allow a single programmer to handle a large variety of tasks with minimal additional training. The proposed NAME language would address the code writability that these needs require, while still maintaining the reliability of a traditional programming language (Sebesta 14-17) The sheer size of NAME'S implementation may cause some concern about readability, however, not all of its constructs are required leaving NAME just as usable for small applications as large projects.

To address a variety of programming situations, NAME would have to be fundamentally general, but also have a variety of specific extensions that would allow a unified language to confront individual tasks. For instance, NAME would not require domain-specific features, such as the list-processing power of LISP or the logic expressions of PROLOG, but would required compiled, server-interpreted, and scripting extensions to allow for the language to be used in a variety of applications (Sebesta 49, 81). Although the these extensions would be modularized for complete portability, it would be expected that the extensions would be shipped and taught together, as the syntax would be essentially the same. Because the feature set of NAME is so large, the language could be seen as bloated, and hard to learn a significant drawback if the language is to be adopted universally. The counter-argument to this is that a programming student could spend a significantly larger amount of time learning NAME, as a variety of other languages would be rendered unnecessary. To this end, each developer, be they entry-level or experienced programmer, would need to have essentially the same skillset. The complexity of NAME would require a developer to be a NAME 'master' a casual knowledge would not be enough to preform adequately with NAME. Because NAME combines a variety of programming paradigms application, web design, and scripting it would almost certainly have to borrow features from previous languages. While NAME is not intended to be a derivative language as C++ and Objective-C derive from C , it will incorporate major design features of prominent languages. For instance, to be viable as a desktop and mobile application design language, it would need to implement classes, and possibly aliasing, in a C++ style. It would also borrow heavily from C/C++ syntax, as its structures seem to be representative of the majority of common programming languages. In order to accommodate interactive and datasource-driven web page design, NAME would

require interfaces both for interacting directly with DBMS's and echoing another language (usually HTML) directly to the server. NAME could implement these in much the same way that PHP and ColdFusion currently do. For NAME to handle scripting tasks, it would require an interface to interact with command lines, just as Unix Shell Scripting does, but also a method by which compiled NAME could interpret a stripped down 'scripting' version of itself, just as Lua can be interpreted by C++. It seems this is a feature that would be unique to NAME. By deriving NAME from other extremely common languages, it is ensured that not only will it will have the best possible feature set, but also that it will be easily adopted by seasoned programmers (Sebesta 37-108). Because NAME is such a large cross-platform, cross-domain, cross-paradigm language, it's implementation and distribution would need to be approached with careful consideration. The sheer size of the project mandates that the initial implementation would need to be handled or managed by a university or corporation. Organizing a large group of decentralized opensource developers with no beginning codebase would almost certainly end in, if anything, a poor realization of NAME's goals. However, after the initial implementation was completed, control should be handed over to the community at large. Creating compilers for different systems and architectures, along with adding features and maintaining code stability would be within the realm of feasibility for a dedicated volunteer team. This non-proprietary system has been well proven, as open-source languages such as Java, Perl, and PHP are quite stable, and almost universally adopted. This 'universal adoption' is another important consideration for the NAME language. In order to continue attracting the best developers to maintain the project, NAME must be deemed, by the community at large, useful and accepted. If the language is not readily accepted, the

project will fizzle out and become a failure. In order to garner this initial support, the language must be made as widely available and accessible as possible. Because the project is open-source, community-produced compilers would almost certainly be freely distributed, however, the initial university or company compiler implementations must also remain free, even if this requires a loss for the company. The institution would still benefit from the publicity generated by supporting a successful language as evidenced by the growing familiarity with Sun Microsystems and Oracle from their control of the Java language. The designers and maintainers of NAME must also avoid packaging the language with a mandated development environment, such as C# or Objective-C. By restricting developers to an unfamiliar or unwanted development environment, the chances of that developer adopting NAME are significantly reduced. The open-source community maintains several actively-developed integrated development environments; most notably Eclipse. By writing a plugin for something like Eclipse, the NAME designers give potential developers a choice between using an IDE or simply a text-editor and command-line functions. With careful guidance from a controlling body and eventual support from an open-source community, NAME could become one of the most widely-adopted programming languages yet. Its approach to application development, web development, and scripting allow it to be used by a large variety of programming domains, but also by a single developer to handle multiple tasks with relative ease. This would allow small businesses to increase their profits, and more readily adopt technology in general.

Works Cited Sebesta, Robert W. Concepts of Programming Languages. Boston: Addison-Wesley, 2010. Print.