Asp Forum - Re: Ousterhout and Tcl lost the plot with latest paper

Wenwei Peng

4/22/2015 1:56:00 AM

? 1997?4?2???? UTC+8??4:00:00,Chris Bitmead??:
> chenadi.COM (Franklin Chen) writes:
>
> > I've looked at the paper, and found it extremely misleading for its
> > omissions and factual inaccuracies. In particular, I was baffled that
> > there was no mention _whatsoever_ of advanced languages such as
> > Scheme, ML, and Haskell--languages that to me seem most promising as
> > foundations for safe, efficient, and expressive prototyping/scripting
> > as well as general purpose programming.
> >
> > If anyone is interested, I can go into detail about everything I found
> > misleading about Ousterhout's paper. I encourage anyone else who
> > cares to do the same; perhaps an eventual unified response to
> > Ousterhout is called for.
>
>
> The essence of Ousterhout's argument seems to be this... What is the
> ultimate sports car (programming language)? A '59 Cadillac complete
> with fins and powerful engine (C++) or a VW beetle with it's elegant
> simplicity (Tcl). John puts forward a strong argument that the beetle
> is the ultimate sports car, while conveniently ignoring that it is
> possible to combine the powerful engine of the Caddy with the elegance
> of the VW and come up with a Porche 959 (Scheme or Lisp or ML or many
> others).
>
> These are my comments on his paper. Remember that Sun is pushing Tcl
> for some obscure reason, and Ousterhout is apparently working for Sun
> now, so I guess we'd expect something like this, but we can't let him
> get away with this. Imagine... C and TCL. The worst of all possible
> worlds.
>
> My comments are interspersed with his paper below...
>
> >Scripting: Higher Level Programming
> > for the 21st Century
> > John K. Ousterhout
> >
> > Abstract Scripting languages such as Visual Basic and Tcl
> >represent a very different style of programming than system
> >programming languages such as C or Java. Scripting languages are
> >designed for "gluing" applications; they use typeless approaches to
> >achieve a higher level of programming and more rapid application
> >development than system programming languages. Increases in computer
> >speed and changes in the application mix are making scripting
> >languages more and more important for applications of the
> >future. Whereas object-oriented approaches have largely failed to
> >increase software reuse or reduce development costs, scripting
> >languages have succeeded.
> >
> >1 Introduction
> >
> >As we near the end of the 20th century a fundamental change is
> >occurring in the way people write computer programs. The change is a
> >transition from system programming languages such as C or C++ to
> >scripting languages such as Visual Basic or Tcl. Although many people
> >are participating in the change, few people realize that it is
> >occurring and even fewer people know why it is happening. I am writing
> >this paper to call attention to the change and to explain why
> >scripting languages will handle many of the programming tasks of the
> >next century better than system programming languages.
> >
> >Scripting languages are designed for different tasks than system
> >programming languages, and this leads to fundamental differences in
> >the languages. System programming languages were designed for
> >building data structures and algorithms from scratch, starting from
> >the most primitive computer elements such as words of memory. In
> >contrast, scripting languages are designed for gluing: they assume the
> >existence of a set of powerful components and are intended primarily
> >for connecting components together. System programming languages are
> >strongly typed to help manage complexity, while scripting languages
> >are typeless to simplify connections between components and provide
> >rapid application development.
> >
> >Scripting languages and system programming languages are
> >complementary, and most major computing platforms since the 1960's
> >have provided both kinds of languages. However, several recent trends,
> >such as faster machines, the increasing importance of graphical user
> >interfaces and component architectures, and the growth of the
> >Internet, have greatly increased the applicability of scripting
> >languages. These trends will continue over the next decade, with
> >scripting languages used for more and more applications and system
> >programming languages used primarily for creating components.
> >
> >2 System programming languages
> >
> >In order to understand the differences between scripting languages and
> >system programming languages, it is important to understand how system
> >programming languages evolved. In the earliest days of computing,
> >computers were programmed by entering instructions and data directly
> >into the computer in binary form. This approach was quickly replaced
> >by symbolic assembly languages. Assembly languages represent a program
> >textually with one statement for each machine instruction. The fields
> >of the instruction are specified symbolically: for example, the symbol
> >ADD might be used to represent the opcode for an addition instruction
> >and SP might be used to specify the register that serves as stack
> >pointer. An assembler reads the statements, converts symbols to the
> >corresponding binary values, and generates a binary program suitable
> >for execution.
> >
> >The use of textual symbols in assembly language makes programs
> >substantially easier to write than binary approaches while still
> >providing complete control over the machine. However, assembly
> >language suffers from three defects. First, it requires the programmer
> >to write one line of code for each instruction or variable, which
> >becomes tedious as programs grow in size. Second, assembly language
> >forces programmers to deal with many low-level details such as
> >register allocation and procedure calling sequences. Third, assembly
> >language provides almost no structure; for example, all instructions
> >have roughly the same appearance and integer and floating-point
> >variables are declared in the same way. As a result, it is difficult
> >to write and maintain large programs in assembly language.
> >
> >By the late 1950's higher level languages such as Fortran and Algol
> >began to appear. In these languages statements no longer correspond
> >exactly to machine instructions; a compiler translates each statement
> >in the source program into a sequence of binary instructions. Over
> >time a series of system programming languages evolved from Algol,
> >including such languages as PL/1, Pascal, C[4], C++[7], and
> >Java[1]. System programming languages allow large applications to be
> >developed much more quickly than assembly languages while providing
> >nearly the same level of efficiency. As a result, they have almost
> >completely replaced assembly language for the development of large
> >applications.
>
> A brave beginning! Ousterhaut tries to characterise Tcl as some sort
> of next generation language that is some sort of higher level
> abstraction above non-scripting languages.
>
> Talk about turning a bug into a feature! Apparently because Tcl lacks
> fundamental language concepts such as data structures, and a type
> system, it is now superior because it is "simple". I guess that makes
> BASIC another superior language of the future. NOT!
>
> >System programming languages differ from assembly languages in two
> >ways: they are higher level and they are strongly typed. The term
> >"higher level" means that many details are handled automatically so
> >that programmers can write less code to get the same job done. For
> >example:
>
> Where did this very dubious definition of a "system programming
> language" come from?? I don't think there is any official definition,
> but these are the attributes I personally would use to describe a
> systems language. They certainly don't include Ousterhout's
> definition...
>
> A system programming language should be...
> * Capable of being compiled for efficiency
> * Suitable for building complex data structures and algorithms.
> * Suitable for accessing the full capabilities of the operating
> system in a convenient fashion.
>
> > Register allocation is handled by the compiler so that
> >programmers need not write code to move information between registers
> >and memory. Procedure calling sequences are generated automatically
> >so that programmers need not worry about moving arguments to and from
> >the call stack. Programmers can use simple keywords such as while and
> >if for control structures; the compiler generates all the detailed
> >instructions to implement the control structures.
> >
> >On average, each line of code in a system programming language causes
> >about five machine instructions to be executed, compared to one
> >instruction per line in assembly language.
>
> And then Ousterhout goes on to argue that because a one line Tcl
> command can create a GUI button, therefore it is a higher level
> language. What a lot of rot! One line of C code can cause 10 billion
> instructions to be executed if it is a function call. And the Tcl
> button creation command is basicly a function call. Absolutely no
> difference. Very misleading.
>
> >Various studies have shown
> >that programmers can write roughly the same number of lines of code
> >per year regardless of language[2], so system programming languages
> >allow applications to be written much more quickly than assembly
> >languages.
> >
> >The second difference between assembly languages and system
> >programming languages is typing. The term "typing" refers to the
> >degree to which the meaning of information is specified in advance of
> >its use.
>
> Ousterhout conveniently excludes the whole spectrum of dynamically
> typed languages, not to mention strongly typed languages with type
> inference like ML.
>
> >In a strongly typed language the programmer declares how each
> >piece of information will be used and the language prevents the
> >information from being used in any other way. In a weakly typed
> >language there are no a priori restrictions on how information can be
> >used: the meaning of information is determined solely by the way it is
> >used, not by any initial promises.
>
> A fairly vague assertion, which he continues to repeat over and over
> without examples.
>
> >Modern computers are fundamentally typeless at heart: any word in
> >memory can hold any kind of value, such as a character, an integer, a
> >pointer, or an instruction. The meaning of a value is determined by
> >how it is used: if the program counter points at a word of memory then
> >it is treated as an instruction; if a word is referenced by an integer
> >add instruction then it is treated as an integer; and so on. The same
> >word can be used in different ways at different times.
>
> Modern computers are not "typeless"! While I find this whole argument
> meaningless anyway, if you want to make the comparison, you would say
> that computers are dynamically typed, but nevertheless typed. In that
> respect they compare better to dynamically typed languages like
> Lisp. While a piece of computer memory can hold data of any type,
> (Like a lisp variable), computer instructions only operate on the
> correct type. You can't use an add instruction and pass it a string
> with some ascii numbers in it (Similar to Lisp).
>
> >Today's system programming languages are strongly typed. For example:
>
> Are they? First Ousterhout defines a strongly typed languages as
> system programing languages. Now he tells us that systems languages
> are strongly typed. Well I guess if you define it that way in advance
> it must be so.
>
> > Each variable in a system programming language must be declared
> >with a particular type such as integer or pointer to string, and it
> >must be used in ways that are appropriate for the type. In assembly
> >languageany variable can be used in any way. Data and code are
> >totally segregated in system programming languages, whereas they are
> >interchangeable in assembly languages; it is difficult or impossible
> >to create new code on the fly in a system programming language.
> >Variables can be collected into structures or objects with
> >well-defined substructure and procedures or methods to manipulate
> >them; an object of one type cannot be used where an object of a
> >different type is expected.
> >
> >Typing makes large programs more manageable by clarifying how things
> >are used and differentiating between things that must be treated
> >differently. Compilers can use type information to detect certain
> >kinds of errors, such as an attempt to use a floating-point value as a
> >pointer.
> >
> >To summarize, system programming languages are designed to handle the
> >same tasks as assembly languages, namely creating applications
> >starting from scratch. System programming languages are somewhat
> >higher level and much more strongly typed than assembly
> >languages. This allows applications to be created more rapidly and
> >managed more easily with only a slight loss in performance. See Figure
> >1 for a graphical comparison of binary code, assembly language, and
> >several system programming languages.
> >
> >
> >3 Scripting languages
> >
> >Scripting languages such as Perl[8], Tcl[6], Visual Basic, and the
> >Unix shells represent a very different style of programming than
> >system programming languages. Scripting languages assume that there
> >already exists a collection of useful components written in other
> >languages. Scripting languages aren't intended for writing
> >applications from scratch; they are intended primarily for plugging
> >together components. For example, Tcl and Visual Basic are used to
> >arrange collections of user interface controls on the screen while
> >Unix shell scripts are used to assemble filter programs into
> >pipelines. Scripting languages are often used to extend the features
> >of components but they are rarely used for complex algorithms and data
> >structures; features like these are usually provided by the
> >components. Scripting languages are sometimes referred to as glue
> >languages or system integration languages.
> >
> >In order to simplify the task of connecting components, scripting
> >languages tend to be typeless: all things look and behave the same so
> >that they are interchangeable. For example, in Tcl or Visual Basic a
> >variable can hold a string one minute and an integer the next. Code
> >and data are often interchangeable, so that a program can write
> >another program and execute it on the fly. Scripting languages are
> >often string-oriented, since this provides a flexible representation
> >for many different things.
>
> As we all know, "proper" programming languages like Lisp can also
> generate and execute code on the fly. What Lisp programmers also know
> is that in most situations, doing so is a sign of a bad design. In the
> case of Tcl, the ability to do so is just a band-aid for the
> limitations of the language, that Lisp style languages generally don't
> need, but nevertheless do have.
>
> >A typeless language makes it much easier to hook together
> >components. There are no a priori restrictions on how things can be
> >used, and components and values are represented in a uniform
> >fashion. Thus any component or value can be used in any situation;
> >components designed for one purpose can be used for totally different
> >purposes never foreseen by the designer. For example, in the Unix
> >shells, all filter programs read a stream of bytes from an input and
> >write a string of bytes to an output so any two programs can be
> >connected together simply by attaching the output of one program to
> >the input of the other.
> >
> >The strongly typed nature of system programming languages discourages
> >reuse. Programmers are encouraged to design a variety of incompatible
> >interfaces. Each interface requires objects of specific types and the
> >compiler prevents any other types of objects from being used with the
> >interface, even if that would be useful. In order to use a new object
> >with an existing interface, conversion code must be written to
> >translate between the type of the object and the type expected by the
> >interface. This in turn requires recompiling part or all of the
> >application, which isn't possible in the common case where the
> >application is distributed in binary form.
>
> A fairly poor attempt to gloss over the issues here. Converting
> everything to strings does not solve anything except in the most
> trivial cases. Just because you encode some complex concept into a
> single string doesn't mean that the type information isn't still
> there. The simplest case is of course passing a string to an add
> function. At run time you've still got to know that the string
> contains a number. Again Ousterhout conveniently ignores the
> dynamically typed languages and glosses over the real issues.
>
> >To see the advantages of a typeless language, consider the following
> >Tcl command:
> >
> >button .b -text Hello! -font {Times 16} -command {puts hello}
> >
> >This command creates a new button control that displays a text string
> >in a 16-point Times font and prints a short message when the user
> >clicks on the control. It mixes six different types of things in a
> >single statement: a command name (button), a button control (.b),
> >property names (-text, -foreground, and -command), simple strings
> >(Hello! and hello), a font name (Times 16) that includes a typeface
> >name (Times) and a size in points (16), and a Tcl script (puts
> >hello). Tcl represents all of these things uniformly with strings. In
> >the button example the properties may be specified in any order and
> >unspecified properties are given default values; more than 20
> >properties were left unspecified in the example.
> >
> >The button example requires about 25 lines of code in three procedures
> >when implemented in C++ with Microsoft Foundation Classes. Just
> >setting the font requires 7 lines of code:
> >
> >LOGFONT lf;
> >
> >memset(&lf, 0, sizeof(lf));
> >
> >lf.lfHeight = -16;
> >
> >strcpy(lf.lfFaceName, "Times New Roman");
> >
> >CFont *fontPtr = new CFont();
> >
> >fontPtr->CreateFontIndirect(&lf);
> >
> >buttonPtr->SetFont(fontPtr);
>
> Come on! All this shows is the inconveniece of using the MFC
> classes. An interface exactly the same as the Tcl one could easily be
> written in C++.
>
> >Almost all of this code is a consequence of the strong typing:
> >variables lf and fontPtr must be declared, fields in the font
> >descriptor structure lf must be filled in individually, then a new
> >object of type CFont must be created from lf in order to match the API
> >of the button's SetFont method. In Tcl, the essential characteristics
> >of the font (typeface Times, size 16 points) can be used immediately
> >with no declarations, intermediate structures, or
> >conversions. Similarly, in C++ the behavior for the button must placed
> >in a separately declared method, whereas in Tcl it can be included
> >directly in the command that creates the button.
> >
> >It might seem that the typeless nature of scripting languages could
> >allow errors to go undetected, but in fact scripting languages are
> >just as safe as system programming languages. For example, an error
> >will occur if the font size specified for the button example above is
> >a non-integer string such as xyz.
>
> Huh??? Presumably he is refering to the line...
> lf.lfHeight = -16;
>
> Surely this would give a type error if it were changed to...
> lf.lfHeight = "xyz";
>
> >The difference is that scripting
> >languages do their error checking at the last possible moment, when a
> >value is used. Strong typing allows errors to be detected at
> >compile-time, so the cost of run-time checks is avoided. However, the
> >price to be paid for this efficiency is more conservative restrictions
> >on how information can be used: this results in more complex and less
> >flexible programs.
> >
> >Another key difference between scripting languages and system
> >programming languages is that scripting languages are usually
> >interpreted whereas system programming languages are usually
> >compiled.
>
> "Usually" perhaps, but not always. Surely the best solution is a
> language which can easily accomodate both options? Tcl does not at all
> easily support compilation. C++ does not easily support
> interpretation. There are many languages which readily support both.
>
> >Interpreted languages provide rapid turnaround during
> >development by eliminating lengthy compile times. Interpreters also
> >allow powerful effects to be achieved by generating code on the
> >fly. For example, a Tcl-based Web browser can parse a Web page by
> >translating the HTML for the page into a Tcl script using a few
> >regular expression substitutions. It then executes the Tcl script to
> >render the page on the screen. Or, an application can be extended by
> >downloading code into it.
> >
> >Scripting languages tend to be less efficient than system programming
> >languages, in part because they use interpreters instead of compilers
> >but also because their basic components are chosen for power and ease
> >of use rather than an efficient mapping onto the underlying
> >hardware. For example, scripting languages tend to use variable-length
> >strings in situations where a system programming language would use a
> >binary value that fits in a single machine word, and scripting
> >languages often use hash tables where system programming languages use
> >indexed arrays.
>
> But why? If we accept that scsh is a scripting language (which clearly
> it is), it suffers from neither of these drawbacks.
>
> >Fortunately, the performance of a scripting language isn't usually a
> >major issue. Applications for scripting languages are generally
> >smaller than applications for system programming languages, and the
> >performance of a scripting application tends to be dominated by the
> >performance of the components, which are typically implemented in a
> >system programming language.
>
> This is an often put forward argument that falls over time and time
> again when reality hits. Applications might start off small, but then
> people want more features, more performance, more
> everything. Eventually using the poor scripting languages break down
> because they don't give you the performance or data structures or
> abstraction mechanisms to support what you're doing. Things become
> more and more messy. You keep having to go back and rewrite things in
> your "systems" languages.
>
> Sure Tcl and C can be a lot faster than C alone. But then C is an
> appalling benchmark against which to make judgements.
>
> >Scripting languages are higher level than system programming
> >languages, in the sense that a single statement does more work on
> >average. A typical statement in a scripting language executes hundreds
> >or thousands of machine instructions, whereas a typical statement in a
> >system programming language executes about five machine
> >instructions. Part of this difference is because scripting languages
> >use interpreters, which are less efficient than the compiled code for
> >system programming languages. But much of the difference is because
> >the primitive operations in scripting languages have greater
> >functionality. For example, in Perl it is about as easy to perform a
> >regular expression substitution as it is to perform an integer
> >addition. In Tcl, a variable can have traces associated with it so
> >that setting the variable causes side effects; for example, a trace
> >might be used to notify a control whenever the value of a variable
> >changes, so that the variable's value can be displayed continuously on
> >the screen.
>
> At this stage the argument gets to the utterly riduclous
> stage. According to Ousterhout, because Scheme has only 5 "primitive"
> operations which execute only a few instructions, therefore to do
> anything in Scheme must be orders of magnitude more verbose than in
> Tcl which has lots of primitive operations. NOT!
>
> The convenience of performing complicated tasks is partly because of
> the elegance of the language, but mostly has a lot to do with the
> design of the libraries it has associated with it. Naturally Tcl can
> do a lot of things with a few lines of code, because it is supported
> by truckloads of library code doing the real work. But that is a
> benefit of Tk. Not Tcl.
>
> >Because of the features described above, scripting languages allow
> >very rapid development for applications that are gluing in
> >nature. Table 1 provides anecdotal support for this claim. It
> >describes several applications that were implemented in a system
> >programming language and then reimplemented in a scripting language,
> >or vice versa.
>
> This supposed comparison has a lot of flaws.
>
> - It only makes comparison with C, C++ and Java. Hardly a wide enough
> selection to draw the sweeping conclusions he then goes on to draw.
>
> - comp.lang.tcl is hardly an unbiased source of information.
>
> - It's not clear how much advantage was drawn from having the code
> already implemented in the "systems" language
>
> - There is no mention about whether the "systems" language
> implementation used an extensive set of libraries such as that which
> comes with Tcl, or whether they decided to reinvent every wheel
> themselves, as so often happens on C and C++ projects.
>
> - While the Java comparison makes a better one than C and C++, Java is
> a far from mature technology with as yet poor library support.
>
> In summary, the table is completely meaningless without further
> information.
>
> >The scripting versions typically required 5-10x less code or
> >development time than the system programming versions. Applications
> >that involved more complex algorithms or data structures, such as the
> >last example in the table, benefit less from a scripting language than
> >applications that are mostly gluing.
> >
> >To summarize, scripting languages are designed for gluing
> >applications. They provide a higher level of programming than assembly
> >or system programming languages, much weaker typing than system
> >programming languages, and an interpreted development
> >environment. Scripting languages trade off execution efficiency for
> >speed of development. Figure 1 compares scripting languages with
> >system programming languages graphically.
> >
> >4 Different tools for different tasks
> >
> >A scripting language is not a replacement for a system programming
> >language or vice versa. Each is suited to a different set of
> >tasks. For gluing and system integration, applications can be
> >developed 5-10x faster with a scripting language; system programming
> >languages will require large amounts of boilerplate and conversion
> >code to connect the pieces, whereas this can be done directly with a
> >scripting language. For complex algorithms and data structures, the
> >strong typing of a system programming language makes programs easier
> >to manage. Where execution speed is key, a system programming language
> >can often run 10-20x faster than a scripting language: the flexibility
> >provided by the scripting language results in more run-time checks.
> >
> >In deciding whether to use a scripting language or a system programming language for a particular task, consider the following questions:
> >
> > Is the application's main task to connect together pre-existing components?
> > Will the application manipulate a variety of different kinds of things?
> > Will the application's functions evolve rapidly over time?
> > Does the application need to be extensible?
>
> Pretty much all programming tasks have the above attributes. Go and
> ask a programmer working on a project if...
>
> - They will save time by using pre-existing components.
> - The application has to do different things
> - The application will change over time
> - The application needs to be extensible.
>
> Of course these statements are the definition of a normal evolving
> software project.
>
> >"Yes" answers to these questions suggest that a scripting language will work well for the application. On the other hand, "yes" answers to the following
> >questions suggest that an application is better suited to a system programming language:
> >
> > Does the application implement complex algorithms or data structures?
> > Does the application manipulate large datasets (e.g. all the pixels in an image) so that execution speed is critical?
> > Are the application's functions well-defined and changing only slowly?
>
> Here is the problem with scripting languages. Most applications start
> off with a simple model and structure, a modest sized dataset, and a
> well-defined problem. But then guess what? People want more features
> leading to more complex algorithms and the need for data
> structures. People start to feed larger and larger datasets into the
> program. And the requirements of the program start to change and
> change. Then you have to start all over from scratch because you find
> that Tcl doesn't scale.
>
> >Most of the major computing platforms over the last 30 years have
> >provided both system programming and scripting languages. For example,
> >one of the first scripting languages was JCL (Job Control Language),
> >which was used to sequence job steps in OS/360. The individual job
> >steps were written in PL/1, Fortran, or assembler language, which were
> >the system programming languages of the day. In the Unix machines of
> >the 1980's, C was used for system programming and shell programs such
> >as sh and csh for scripting. In the PC world of the 1990's, C and C++
> >are used for system programming and Visual Basic for scripting. In the
> >Internet world that is taking shape now, Java is used for system
> >programming and languages like JavaScript, Perl, and Tcl are used for
> >scripting.
> >
> >Scripting and system programming are symbiotic. Used together, they
> >produce programming environments of exceptional power: system
> >programming languages are used to create exciting components which can
> >then be assembled using scripting languages. For example, much of the
> >attraction of Visual Basic is that system programmers can write VBX
> >components in C and less sophisticated programmers can then use the
> >components in Visual Basic applications. In Unix it is easy to write
> >shell scripts that invoke applications written in C.
>
> While Unix shell scripts are a big improvment on what existed
> pre-Unix, they still have a lot of problems which could be better
> solved using a different paradigm. For example, a lot of shell script
> work involves parsing and re-parsing the text streams. One can imagine
> a paradigm where objects instead of strings are passed around. Let's
> imagine an "ls" directory lister which generates a collection of
> directory entry objects. Each entry object has a print method which
> prints the same as the Unix style "ls". Thus typing "ls" at the
> keyboard does the same thing. And if there is some special reason why
> you want to use the pure text version in a script you can do so. But
> much more typically you want to use some of the fields in the "ls"
> output to do calculations. "Which directory entries are older than
> 12/Feb/1997?" VERY difficult to do with Unix shell. Trivial in a scsh
> or CLOS style language. One can imagine writing something like (map
> (lambda (d) (< (file-time d) "12/Feb/1997")) (ls))
>
> >One of the
> >reasons for the popularity of Tcl is the ability to extend the
> >language by writing C code that implements new commands.
> >
> >5 Scripting is on the rise
> >
> >Scripting languages have existed for a long time, but their importance
> >has increased in recent years because the application mix has shifted
> >more towards gluing applications. Three examples of this shift are
> >graphical user interfaces, the Internet, and component frameworks.
> >
> >User interfaces are fundamentally gluing applications: the goal is not
> >to create new functionality, but to make connections between a
> >collection of graphical controls and the internal functions of the
> >application. Scripting languages have always been the primary vehicle
> >for creating user interfaces, whether the user interface was a card
> >deck as in OS/360, a command line on a terminal as in Unix, or a
> >graphical user interface as with Tcl or Visual Basic. With the arrival
> >of graphical user interfaces (GUIs) in the 1980's the richness of user
> >interfaces increased dramatically, as did the development effort
> >required to create them. The GUI accounts for half or more of the
> >total effort in many programming projects.
> >
> >I am not aware of any rapid-development environments for GUIs based on
> >a system programming language.
>
> Since Ousterhouts world view only includes "system" languages and
> "scripting" languages, and his definitions of these excludes lots of
> better and much more viable alternatives, his whole argument amounts
> to a straw man.
>
> >Whether the environment is Windows,
> >Macintosh Toolbox, or Unix Motif, GUI toolkits based on languages like
> >C for C++ have proven to be hard to learn, clumsy to use, and
> >inflexible in the results they produce. Some of these tools have very
> >nice graphical tools for designing screen layouts, but things become
> >difficult as soon as the designer begins writing code to provide the
> >behaviors for the interface elements. All of the best
> >rapid-development GUI environments are based on scripting languages:
> >Visual Basic on the PC, HyperCard on the Macintosh, and Tcl on
> >Unix. Thus scripting languages have risen in popularity as the
> >importance of GUIs has increased.
> >
> >The growth of the Internet has also popularized scripting
> >languages. The Internet is a gluing environment. It doesn't create any
> >new computations or data; it simply makes a huge number of existing
> >things easily accessible. The ideal language for most Internet
> >programming tasks will be one that makes it possible for all the
> >connected components to work together, i.e. a scripting language. For
> >example, Perl has become popular for writing CGI scripts and
> >JavaScript is popular for scripting in Web pages.
> >
> >The third example of scripting-oriented applications is component
> >frameworks. Although system programming languages work well for
> >creating components, the task of assembling components into
> >applications is better suited to scripting. Without a good scripting
> >language to manipulate the components, much of the power of a
> >component framework is lost. This may explain in part why component
> >frameworks have been more successful on PCs (where Visual Basic
> >provides a convenient scripting tool) than on other platforms such as
> >Unix/CORBA where scripting is not included in the component framework.
> >
> >Another reason for the increasing popularity of scripting languages is
> >the ever-increasing speed of computer hardware. It used to be that the
> >only way to get acceptable performance in an application of any
> >complexity was to use a system programming language. In some cases
> >even system programming languages weren't efficient enough, so the
> >applications had to be written in assembler. However, machines today
> >are 100-500 times faster than the machines of 1980. Many applications
> >can be implemented in an interpreted language and still have excellent
> >performance (for example, a Tcl script can manipulate collections with
> >hundreds or thousands of objects and still provide good interactive
> >response). As computers get faster, fewer and fewer applications will
> >need to be implemented in a system programming language to get
> >adequate performance.
> >
> >One final reason for the increasing use of scripting languages is a
> >change in the programmer community. Twenty years ago most programmers
> >were sophisticated programmers working on substantial
> >projects. Programmers in that day expected to spend several months to
> >master a language and its programming environment, and system
> >programming languages were designed for such programmers. However,
> >since the arrival of the personal computer, more and more casual
> >programmers have joined the programmer community. For these people,
> >programming is not their main job function; it is a tool that they use
> >occasionally to help with their main job. Examples of casual
> >programming are writing macros for a spreadsheet or writing a simple
> >database query. Casual programmers are not willing to spend months
> >learning a system programming language, but they can often learn
> >enough about a scripting language in a few hours to write useful
> >programs. Scripting languages are easier to learn because they have
> >simpler syntax than system programming languages and because they omit
> >complex features like objects and threads.
>
> Oh really?? Scripting languages are simpler and easier to learn than
> systems languages? That is a very broad claim to make. It is also a
> lot of rot. Take perl for example. A difficult language to truely
> understand and master. Each language has it's own unique
> characteristics and difficulties. It has nothing to do with whether it
> is a supposedly "systems" or "scripting" language.
>
> >For example, compare Visual
> >Basic with Visual C++; few casual programmers would attempt to use
> >Visual C++, but many have been able to build useful applications with
> >Visual Basic.
>
> Yeah right. Use C++ as a comparison against BASIC. Why not compare
> Perl to Scheme? Who wins then?
>
> >Even today the number of applications written in scripting languages
> >is much greater than the number of applications written in system
> >programming languages. On Unix systems there are many more shell
> >scripts than C programs, and under Windows there are many more Visual
> >Basic programmers and applications than C or C++. Of course, most of
> >the largest and most widely used applications are written in system
> >programming languages, so a comparison based on total lines of code or
> >number of installed copies may still favor system programming
> >languages. Nonetheless, scripting languages are already a major force
> >in application development and their market share will increase in the
> >future.
> >
> >6 The failure of object-oriented programming
> >
> >Scripting languages have received little attention in the programming
> >language community or in the press; instead, most of the attention has
> >been focused on object-oriented programming languages such as C++ and
> >Java. Object-oriented programming is widely believed to represent the
> >next major step in the evolution of programming
> >languages. Object-oriented features such as strong typing and
> >inheritance are often claimed to reduce development time, increase
> >software reuse, and solve many other problems including those
> >addressed by scripting languages.
> >
> >Unfortunately, there is not much evidence that object-oriented
> >programming produces the benefits claimed for it. Some projects have
> >claimed success with object-oriented languages, but others have
> >reported that languages like C++ actually made software management
> >problems worse.
>
> So object oriented technology is condemned because of the failure of
> C++? Yeah right.
>
> >I do not know of any studies showing substantial
> >reductions in development costs due to object-oriented programming,
> >and some language experts are now beginning to speak out against
> >object-oriented programming [3].
> >
> >The reason why object-oriented programming has not lived up to
> >expectations is that it doesn't raise the level of programming or
> >encourage reuse. Programmers still work with small basic units that
> >must be described and manipulated in great detail. In principle,
> >powerful library packages could be developed, and if these libraries
> >were used extensively it could effectively raise the level of
> >programming. However, not many such libraries have come into
> >existence.
>
> Oh really?
>
> >The strong typing of object-oriented languages encourages
> >narrowly defined packages that are hard to reuse. Each package
> >requires objects of a specific type; if two packages are to work
> >together, conversion code must be written to translate between the
> >types required by the packages.
>
> Again this argument about "conversion code". Hard to argue with since
> he gives no examples. A vague argument is an unassailable argument.
>
> >Another problem with object-oriented languages is their emphasis on
> >inheritance. Implementation inheritance, where one class inherits part
> >of its implementation from another, is simply a bad idea. It binds the
> >implementations of classes together so that neither can be understood
> >without the other: the subclass cannot be understood without knowing
> >how the inherited methods are implemented in the superclass, and the
> >superclass cannot be understood without knowing how its methods are
> >inherited in subclasses. In a complex class hierarchy, no individual
> >class can be understood without understanding all the other classes in
> >the hierarchy. Even worse, a class cannot be separated from its
> >hierarchy for reuse. Multiple inher...

Title: The core of the core of the big data solutions -- Map
Author: pengwenwei
Email: wenwei19710430
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: Map algorithm with high performance
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)

Download demo project - 1070 Kb
Download source - 1070 Kb

Introduction:
For the c++ program, map is used everywhere.And bottleneck of program performance is often the performance of map.Especially in the case of large data,and the business association closely and unable to realize the data distribution and parallel processing condition.So the performance of map becomes the key technology.

In the work experience with telecommunications industry and the information security industry, I was dealing with the big bottom data,especially the most complex information security industry data,all can’t do without map.

For example, IP table, MAC table, telephone number list, domain name resolution table, ID number table query, the Trojan horse virus characteristic code of cloud killing etc..

The map of STL library using binary chop, its has the worst performance.Google Hash map has the optimal performance and memory at present, but it has repeated collision probability.Now the big data rarely use a collision probability map,especially relating to fees, can’t be wrong.

Now I put my algorithms out here,there are three kinds of map,after the build is Hash map.We can test the comparison,my algorithm has the zero probability of collision,but its performance is also better than the hash algorithm, even its ordinary performance has no much difference with Google.

My algorithm is perfect hash algorithm,its key index and the principle of compression algorithm is out of the ordinary,the most important is a completely different structure,so the key index compression is fundamentally different.The most direct benefit for program is that for the original map need ten servers for solutions but now I only need one server.
Declare: the code can not be used for commercial purposes, if for commercial applications,you can contact me with QQ 75293192.
Download:
https://sourceforge.net/projects/pwwhas...

Applications:
First,modern warfare can’t be without the mass of information query, if the query of enemy target information slows down a second, it could lead to the delaying fighter, leading to failure of the entire war. Information retrieval is inseparable from the map, if military products use pwwhashMap instead of the traditional map,you must be the winner.

Scond,the performance of the router determines the surfing speed, just replace open source router code map for pwwHashMap, its speed can increase ten times.
There are many tables to query and set in the router DHCP ptotocol,such as IP,Mac ,and all these are completed by map.But until now,all map are using STL liabrary,its performance is very low,and using the Hash map has error probability,so it can only use multi router packet dispersion treatment.If using pwwHashMap, you can save at least ten sets of equipment.

Third,Hadoop is recognized as the big data solutions at present,and its most fundamental thing is super heavy use of the map,instead of SQL and table.Hadoop assumes the huge amounts of data so that the data is completely unable to move, people must carry on the data analysis in the local.But as long as the open source Hadoop code of the map changes into pwwHashMap, the performance will increase hundredfold without any problems.

Background to this article that may be useful such as an introduction to the basic ideas presented:
http://blog.csdn.net/chixinmuzi/article/detai...

comp.lang.lisp

Re: Ousterhout and Tcl lost the plot with latest paper

Wenwei Peng

x Login to ForumsZone