Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
ACCU Spring Conference 2003 Roundup

By codemonkey_uk in Technology
Fri Apr 11, 2003 at 05:32:22 PM EST
Tags: Focus On... (all tags)
Focus On...

The ACCU Spring Conference 2003, incorporating the Python UK Conference, was held between the 2nd and 5th of April. This report covers only some of the 57+ sessions at the conference, which had 5 "tracks", plus evening "birds of a feather" meetings, and covered such diverse topics as C, C++, Java, Python, Haskell, language neutral design, patterns and more.

This article should give you a taste of what I saw of the conference. Unfortunately, I can't be in more than one place at a time!


Quick Index:
  1. Linguistic Variables: Clear Thinking with Fuzzy Logic
  2. Coding Standards: Given the ANSI C Standard why do I still need a Coding Standard
  3. C++ & Multimethods
  4. In the Spirit Of C
  5. Design & Implementation of the Boost Graph Library
  6. Secrets and Pitfalls of Templates
  7. The Timing and Cost of Choices
  8. The Cost of C & C++ Compatibility
  9. Advanced Template Techniques (double session)
  10. The Internet, Software and Computers - A Report Card
  11. Multi-Platform Software Development; Lessons from the Boost libraries
  12. Pattern Writing: Live and Direct (double session)
  13. End note, extras, etc.


Wednesday 2nd April

Linguistic Variables: Clear Thinking with Fuzzy Logic - Walter Banks, Byte Craft Limited

Walter Banks introduced the concept of a "linguistic variable" by way of example. A simple soup recipe was shown, and expressions such as "pinch" of salt highlighted. Walter pointed out that the real world is full of such imprecise terms, and that modelling them with a Degree Of Membership (DOM) value - which is normalised to a 0..1 range - can make working with them computationally & algorithmically simple and efficient. It is worth noting at this point that boolean values (true or false, 1 or 0) are a true subset of "fuzzy" DOM values.

Mapping a real world range of values, for instance temperature, to a linguistic variable is best achieved using a 4 point range graph, where the first value represents the point in the range below which the DOM is zero, the second value represents the point in the range up to which the DOM is between 0 and 1, and after which it is 1 (full membership). The third point on the graph is the point at which full membership ends, and the last point on the graph is the point after which the DOM once again becomes zero.

But a picture is worth a thousand words, so:

      1 |   B__C
DOM     |   /  \
      0 |__/____\__
          A      D
In which A, B, C, & D represent the first, second, third and fourth points described above, and the horizontal and vertical axis would represent a crisp real world value (such as temperature), and the Degree Of Membership respectively.

Audience members asked Walter if linear interpolation was enough, and he assured us that it was, and that despite there being corner anomalies with this approach, it has been shown in practice that the corner values are always non-critical.

Walter then went on to show how "fuzzy" logic operations can be implemented on DOM values very efficiently. A fuzzy OR (a,b) is equivalent to a MAX (a,b), and a fuzzy AND (a,b) is equivalent to a MIN (a,b). Fuzzy NOT (a) is just (1-a). Conditionals using linguistic variables were shown to work in a slightly surprising way. Any IF condition will boil down to a DOM value, which is then used as the degree to which the THEN expression is evaluated. This only really works well, as far as I can see, when the expression is a fuzzy assignment.

Commercial applications for these techniques include: Electric motor starters, furnace control, aviation, loan application evaluation, fraud detection, stock price control, and of course, washing machines. Finally, it was interesting to learn that the 40,000 computer animated characters in the Lord Of The Rings movie, in the attack on Helms Deep scene, were controlled by a simulation system using approximately 135 fuzzy rules for each character type.



Coding Standards: Given the ANSI C Standard why do I still need a Coding Standard - Randy Marques, Atos Origin

"There are 100 ways to do something, all equally good. Choose one, and stick to it"

Randy Marques gave a surprisingly entertaining talk on a difficult subject. He started the talk by pointing out that while the current ANSI C Standard is C99, when we talk about ANSI C almost everyone, including the majority of compilers think C89, causing many people to fall at the first hurdle - which ANSI C Standard? Will there be support for Variable Length Arrays? Incomplete Arrays? What about C++ style comments (//)?

The talk itself focused on the C89 standard. Appendix F of the C89 standard contains 267 items. Appendix F of the ANSI C Standard lists & describes all the unspecified, undefined, and implementation defined behaviour in the language (and a bit more). An example of unspecified behaviour would be the order of evaluation between sequence points. Many people know that: "array[i] = i++;" is asking for trouble, but how many also realise that the order in which the functions are called in this example: "i = f1() + f2() * f3();" is also unspecified?

Undefined behaviour ("dragons be here") includes the exact behaviour in the case of integer overflow (wrap around, or saturate), and the behaviour of non-void functions with empty return statements. Implementation defined behaviour (consult your compiler documentation) includes the exact behaviour of casting a pointer type to an int, and the result of a right shift on a signed integer.

Randy also described several situations that can result in unexpected or unpredictable behaviour that are well defined in the standard, such as comparing floats for equality, and returning the address of a local variable.

Given all this, and many more reasons I do not have space here to go into, he argued, there is not only a strong motivation for development teams to adopt an internal coding standard, but for it to be enforced, where possible, with static (automated) testing - claiming that 40% of all runtime errors in C applications could have been found by using a static analysis tool.

When creating a coding standard, Randy told us, you will have to make some decisions on matters of style, in such cases his advice was: "There are 100 ways to do something, all equally good. Choose one, and stick to it. Do not try to make it a democratic process."

Other interesting facts in this talk were that any given bug fix has a 15% probability of introducing a new bug, and that the best fault rate in the world is that of the NASA engineers, who in production code, a fault rate of "only" 6-8 faults per 1000 lines of code.

Randy Marques has kindly made the slides of this talk available from his homepage, at the following URL: www.xs4all.nl/~rmarques/Werk/Pres/CodingStandards.ppt



C++ & Multimethods - Julian Smith

"C++ is deliberately designed to offer sharp tools when needed."

Julian introduced the audience to multimethods. Those of you who use the Dylan programming language , or CLOS may already be familiar with, or just take for granted the existence of multimethods. Those of you that have had to implement the Visitor Pattern will be familiar with the problem that multimethods solve, if not the name.

Multimethods, it was explained, are methods that dispatch at runtime like virtual methods, but to more than one object. The virtual function call dispatch mechanism is a special case of the general multimethod mechanism, an example of "single dispatch", were the dispatch is determined by one object type. "Double dispatch" is the special case of method selection based on two objects. Multimethods generalise this to method selection on any number of object types.

An example application of multimethods is the double dispatch problem of deciding if two shapes overlap. An OO system might typically have a class hierarchy rooted with a Shape class, which might want to provide a public method for testing overlap, like so: "bool Overlap( Shape & a, Shape & b ) { /* ... */ }", the problem comes when implementing this method, as it needs to know the derived type of both objects.

Multimethods, we were told, provide the solution. The multimethod mechanism presented was in the form of a language extension for C++, using a syntax previously suggested by Bjarne Stroustrup, which uses the virtual keyword as a type qualifier in the argument list of a non-member function like so: "bool Overlap( virtual Shape & a, virtual Shape & b );"

This function is declared by the programmer, and implemented at the compiler level, based on what type specific versions of the method have been provided. Julian also discussed techniques using multimethods to simplify GUI event handling and perform internationalisation of error messages.

Julian Smith has kindly made the slides of this talk available from his homepage, at the following URL: www.op59.net/accu-2003-multimethods.html

An implementation of the language extension is available from the following URL: www.op59.net/cmm/readme.html

During the conference there was an interest expressed by compiler vendors in implementing this extension to the language. If this happens, and it gains more widespread usage, I would like to see it become part of the C++ Standard.



Thursday 3rd April

Keynote: In the Spirit Of C - Greg Colvin, Oracle Corporation

"Real programmers can write FORTRAN in any language."

Greg Colvin gave a genuinely engaging and provocative keynote to get the second day of the conference off to a good start. He focused on what he felt was the "spirit of c" linking C with C++ and Java, starting with a brief history of C, it's origin, and the motivations that drove it's designers.

Greg told us what he felt the spirit of C boiled down to the following key points:

  1. Trust the programmer.
  2. Don't prevent the programmer from doing what needs to be done.
  3. Keep the language small and simple.
  4. Provide only one way to do an operation.
  5. Make it fast, even if it is not guaranteed to be portable.

He went on to explore how this "spirit" of C maps to C, C++, and Java as they currently stand. His angle on how C++ and Java map to the 5 "spirit of C" key points was that each language has adopted a focus on a subset of the 5 points, at the expense of the rest. For instance, C++ still holds the first rule in high regard, at the expense of the third rule, where as Java places more emphasis on the third rule, at the expense of the 5th rule.

On C++ he said "There is no limit to the level of complexity that can be packed behind a beautifully elegant interface". He observed that templates were added in order to support typesafe lists, and that the current trends in meta programming were entirely unexpected, accidental and impossible to prevent.

On Java he commented that the fact that there was no undefined behaviour in the Java language specification was "remarkable", but that didn't mean that you no longer had to trust the programmer, as threading was still hard, and deadlock common. He also noted that depending on automatic memory management can actually make it harder to manage memory.

Looking to the future, Greg urged that the C standards body "keep it real", and leave C99 as the final revision of the C standard. Of Java he said that true standardisation is needed, before the needs of the Java developer community are ignored by Sun in favour of corporate interests. C++, he said, should keep evolving, whilst being kept as close to being a proper superset of C as is possible.



Design & Implementation of the Boost Graph Library - Jeremy Siek, Indiana University Bloomington

Jeremy Siek started the talk off with a brief introduction to graph theory, explaining four commonly used graph-search algorithms: Breadth First Search (BFS), Depth First Search (DFS), Dijkstra's, and Prim's minimum spanning tree.

He went on to explore the commonality that these algorithms shared, observing that they all follow out edges, spread through the graph, and select from the visited unexpanded nodes to expand next. It was observed that the odd one out of the four, from an implementation point of view, was the DFS, and that by using generative configuration techniques the other three can all be implemented with a single function template interface; in the Boost Graph Library (BGL) that function is the graph_search function. Jeremy explained in detail the configurable elements of this interface, how they are used to implement the different search algorithms, and how the design decisions were arrived at.

The library makes heavy use of algorithm visitors in it's design. For instance, the graph_search function template expects to be passed a Queue object, supporting push, top & pop methods, with the exact behaviour of the queue determining the behaviour of the search. Passing in a First In First Out (FIFO) queue results in BFS behaviour, a priority queue sorted on vertex distance results in an implementation of Dijkstra's algorithm, and a priority queue sorted on edge length implements Prim's.

One element of the talk that was of particular interest to me was the section on "breadcrumbs", which allows the user of the graph_search function template to provide their own system for recording node "colour" (visited and expanded, visited, or unvisited) by providing an object supporting the array syntax, indexed on node, which has the potential to be very efficient on trees that support marking at the node level, for example: Colour& operator[](Node& n){return n.colour;}, and at the same time allows searches to be performed on trees that don't support node marking by using an external "colour map".

The second half of the talk described the adjacency_list class template, which is highly configurable at compile time via the use of "generative" options, allowing the user to make their own decisions about functionality and implementation trade offs. An example of a functionality trade off would be selecting a directed graph or an undirected graph. An example of an implementation trade off would be selecting to use arrays, or linked lists for the node "backbone".

Asked by a member of the audience about the abstraction penalty, Jeremy claimed that it would only be apparent when using poor quality compilers, and that in theory using the BGL should be as efficient as custom code would be. I asked if BGL had an implementation of the A* algorithm, and was told that it did not. My impression was that the BGL is a very well designed, and carefully implemented library.



Secrets and Pitfalls of Templates - David Vandevoorde, Edison Design Group & Nico Josuttis

"Just get on with programming." - David
"Don't use templates." - Nico

David (pronounced "Daveed") and Nico are the collaborating authors on the "hot" new book: "C++ Templates: The Complete Guide". That the book weighs in at 300 pages on a single language feature is a testament to exactly how difficult and complex C++ has become.

The talk went down well with the audience, and the joint presentation format worked well, with a witty interplay between David, a compiler implementer playing the expert, and Nico "playing" the role of the c++ template user. The first topic addressed dealt with the same terminology issues that were covered in Nico's 2001 talk on template techniques . In addition it was explained that many people confuse "specialisation" (which is the result of instantiation) with "explicit specialisation" (which is where the programmer provides an different definition of a template for a specific type).

The talk then quickly moved on to some of the many "pitfalls" that can trip the unwary programmer, such as how scope affects name lookup. For instance, many people do not know that base class members are not automatically considered during name lookup when the base class depends on a class template parameter, leading to the recommendation that where this is desired the programmer use either: "Base<T>::Foo();", or "this->Foo();", depending on the exact semantics desired. Another problem is that Nondependent base members hide template parameters, that is, if you have a class template and it has a parameter that has the same name as typedef in a base class, then the template parameter is hidden by the name in the base class.

They looked quickly at template template parameters, noting that it was a core language feature added in order to support a library feature that no longer exists! Moving on to the Substitution Failure Is Not An Error (SFINAE) principal, which is essential for overloading function templates and currently a meta programming hot topic, they explained how SFINAE principal can be used to implement class templates for the automatic deduction of traits such as "is this type a class", or "does type Y have member X".

There where several other small tidbits that where interesting to learn during the course of the talk, such as the fact that Koenig look up is now properly called Argument Dependent Lookup (ADL) - perhaps because the standardisation committee wouldn't want Andy Koenig to take all the blame! Another interesting thing I learned was just how expensive meta programming techniques can be at compile time, with one example given generating a whopping 3.5kb of symbol data per instantiation within the compiler (not however, causing bloat in the executable, as is commonly believed).

On export we learned that there is still only one implementation of it (the EDG front end), and that it may become an "optional" feature, or it may be dropped from the standard all together. It was noted that the "EDG" team's implementation took 3 people 1 year part time to complete, compared to 1 person taking 2 weeks to implement template template parameters.

The quotes I gave under the heading for this talk refer to the replies given to an audience member who asked after the talk "So, given all these complications, what is your advise to programmers?", Nico clarified his quick reply by saying that people shouldn't "do stuff just because you can", and David pointed out that a lot of the difficulties described during the talk really only affected people working in the corners of the language, and that most people will only ever need to know this stuff so that in the unusual case where things don't work as expected, they know why they didn't work as expected.



The Timing and Cost of Choices - Hubert Matthews, Oxyware Ltd

"Removal is a mugs game."

Hurbert Matthews' opened his talk by asking the audience what they thought the talk would be about, based on it's title. A mixture of answers where put forward, from compile-time vs run-time binding, to business level management decisions. Herbert told the audience that they were all right.

Most of the remainder of the talk focused on what Herbert described as the Choose-Check-Use pattern. This behavioural pattern describes the process and time line that occur when a decision is made. His claim was that decision making falls into the pattern of making a Choice, Checking it, and Using it, and that by recognising this pattern we are able to examine how the timing of these focal points allows us to further consider the cost implications. For instance, the longer the time between making the Choice and Checking it, the more time is wasted if the check fails. Likewise, the longer the Time Of Choice to Time Of Use (TOCTOU) the more risk that the conditions will have changed, and the check will have been redundant, forcing you to go back to the start and make another Choice.

Clearly this view supports the argument that you should not attempt to make a choice until the last minute, but with that view you have to be aware that work takes time, and that there may be dependencies on your decision. In such cases making an early decision can reduce "analysis paralysis" and let you "chip away" at the larger problem. Hurbert also noted that when it came to changing the time of a Choice it is harder to move it from late to early than from early to late.

He also described what he called the Prevention-Removal-Tolerance pattern in managing potential faults, both in programming and business decisions. The idea is that you prevent faults from getting into the system. The faults you cannot prevent, you remove, and the faults you cannot remove you tolerate. Hurbert recommended focusing on Prevention and Tolerance.

Hubert Matthews has kindly made the slides of this talk available from his homepage, at the following URL: www.oxyware.com/Choices.pdf



Friday 4th April

Keynote: The Cost of C & C++ Compatibility - Andrew Koenig*, AT&T Shannon Laboratory

"C++ has become uncomfortably complicated"

Note: Andrew Koenig was unable to fly to the UK to attend the conference, and his slides were instead presented by conference organiser Francis Glassborow.

One of the first slides of the keynote read "The opinions expressed in this presentation are not necessarily those of the author", which, under the circumstances, got a good laugh.

The focus of the talk was to be the balance of stability vs stagnation. The slides told how he feels that if C++ sticks too close to the past (i.e. source code compatibility with C) it risks becoming marginalized in the future.

The presentation described the changing face of computing: How CPU performance increased, even outpacing memory and I/O, resulting in low level performance becoming less important than it used to be. Programs can now do more in less time, usually the bottle neck is bandwidth, be it the bus, harddrive, or network. This is allowing interpreted, and bytecode interpreted languages to flourish. With, for example, Java on the client-side, Perl on the server, and C# for windows applications, what place for C++?

The talk also explored the implications and consequences of the C compilation, linking, and execution models, and runtime library that C++ are tied to, comparing them to what is now being done by languages choosing not to tie themselves to a legacy language.

Andrew Koenig feels that it is time that the C & C++ communities acknowledge that C and C++ are two different syntactic bindings to a common semantic core, and define the nature of that core, allowing new bindings to it that are recognisably members of the C & C++ family, incorporate all the good stuff from C++, and from other languages as well, and omit as many of C++ pressent problems as possible.



Double session: Advanced Template (and namespace) Techniques - Herb Sutter

Herb Sutter gave an in-depth, talk on the real-world, practical issues in using C++ templates, and namespaces. He rooted the theory firmly in the real world by way of live compiler comparisons, showing what a selection of compiler & library combinations do and don't do in practice. The talk focused primarily on the following questions: What are dependant names? What is two phase name look-up? How does unwanted ADL affect your existing templates, and how can you avoid these problems? How should you enable users to customize your template(s)?

When you write a template, we were told, any name that depends on a template parameter is a dependant name. That is, any qualified or unqualified name that explicitly mentions a template parameter, any name qualified by a member access operator with a dependant type on the left hand side, and any function or functor call which has any arguments that are of a dependant type, that is not qualified with a non-dependent type.

Two phase name lookup splits the time during compilation where names are looked up into two phases. The first phase is at the point of definition, the point where the templates actual definition is parsed. This is when all the non-dependant names are looked up. The second phase is at the point of instantiation, this is the point at which the template is instantiated, creating a specialisation for actual types. This is when the remaining (dependant) names are looked up.

It should be noted at this point that most compilers currently do not implement two phase name lookup, and those that do may hide it behind obscure non-default command-line switches. When, in 1997 HP implemented it they discovered that could not find a single piece of non-trivial template code that was not affected by it, either at compile time or runtime, so they removed support for it from the compiler. This raises the question: Why have two phase name lookup if it will have such a huge impact on existing code? The main reason for it is "template hygiene". Two phase name lookup allows the template writer to better isolate their code from contamination by client code.

So what can the template author do to stop client code hijacking his names? One workable solution is to make use of namespaces for your code, and explicitly qualify any potentially dependant names that you don't want to be used as a point of customisation as coming from that namespace. This will work now with nonconforming compilers, and will also continue to work in the future when compilers implementing two phase name lookup become common (i.e. GCC 3.4 will have it).

ADL kicks in when the compiler encounters an unqualified name that is followed by a list of arguments in parenthesises, or an overloaded operator is called using operator notation. When this occurs the compiler also looks in the associated namespaces and classes of each of argument's types. ADL is suppressed when the name is qualified, or ordinary lookup finds the name of a member function (with the exception of operator overloading member functions). Note also, that ADL will no find "friends" of the argument types, and friend functions are not injected into the enclosing scope. All this raises the question: Why have ADL if it is so complicated? The main reason for it is to simplify the use of operators when used in conjunction with namespaces. An example of this is the use of C++ IO streaming operators in the std namespace. In adition, ADL implements the interface principal described by Herb Sutter in his ACCU 2001 talk.

A significant chunk of the second half of the double session explored an apparently simple, well formed code sample that caused problems on many compiler & library implementations due to combinations of unplanned for ADL, and missing two-phase name lookup hijacking names hidden in apparently reasonable library implementation code. Two ways of "turning off" ADL were then shown. The first is to explicitly qualify the namespace of the function call, which is a good solution for most, but not all, situations. The second is to use the function pointer syntax trick, sometimes used to avoid macros in the C library.

The talk then went on to go into detailed advice for library implementers, with regards the use of namespaces and templates, but I think that this article is becoming to long already, so I'll not go into the details of it here, but it boiled down to basically the same advice given above for dealing with two phase name lookup.

Herb then went on to give his advice on providing points of customisation in template code. What the template implementer should do at points of customisation is make unqualified calls to the customisable name, whist explicitly suppressing ADL on all other names, and the library user can customise by writing their own version (that uses the type used to instantiate the template) in their own namespace (the one containing the type used to instantiate the template). Another option is to use explicit specialisations. The template implementer provides a default class template in the library namespace and makes qualified calls to it. The library user writes their own explicit specialisation of this class template and places it into the library namespace. Whichever option is chosen, the library implementer should always document it.



Saturday 5th April

Keynote: The Internet, Software and Computers - A Report Card - Alan Lenton, Interactive Broadcasting Ltd

A bleary eyed Alan Lenton opened the last day of the conference with an interesting, if slightly politicised talk on the state of the IT industry as a whole. He started the talk by pointing out two trends in programming language development:

  1. The rise of high-level interpreted languages.
    i.e. Python, Ruby
  2. The rise of "commercial" languages.
    i.e. Java, C#

Arguing that that, where as non-commercial languages were designed to fill a hole, or scratch an itch, the "commercial" languages were designed to fulfil some commercial interest. In the case of Java, that interest was an attempt by Sun to marginalize Microsoft. In the case of C#, that interest was for Microsoft (to fix holes in the OS API, but also) to counter Sun.

Alan then asked if C++, being both a high level, and low level language, and non-commercial was in danger of becoming thought of as the "sofa-bed" of programming languages, observing that sofa-beds don't make good sofas, and that they don't make good beds either!

Alan then went on to consider the issue of "who owns your computer?" - with software patents (SCO suing IBM over Linux), End User Licence Agreements (EULA), software rental models, and Palladium, should we take it that big business regrets the general purpose personal computer? There is a battle for control going on that extends beyond even this, with people asking: in the future will the US own the Internet? and Who will own the DNS servers? There is a demonization of the internet (child porn, etc), and yet at the same time a real need to deal with genuine social problems arising from widespread internet use, such as spam, and viruses. He also observed that people want to use the internet as a panacea for education, and the rising trend of people assuming they have a right to have access to "free" stuff online - observing that it is always paid for by someone, and that during the dot com boom that just happened to be venture capitalist money.

Another trend highlighted by Alan's keynote was the politicisation of technology, citing the Regulation of Investigatory Powers (RIP) Act 2000 in the UK, and "eGovernment". With internet usage currently static at around ~60%, Alan asked, is "eGovernment" doomed to create an underclass of "unwired"?

Unifying these disparate points was the idea that: "The innovation that that accompanied the rise of first the personal computer, then later the internet, and which hasn't yet finished, destroyed the marketing model of a number of powerful interests. Since they are entrenched and powerful, they are trying, at a number of levels, to fight back through the legislative and judicial systems."



Multi-Platform Software Development; Lessons from the Boost libraries - Beman Dawes, StreetQuick Software

"Test early, test often."

Beman Dawes presented a talk aimed at a introductory & intermediate level audience (both coders, and managers), drawing on his experience in the development of Boost, a multi platform library that aims to work on all systems that support C++ - from the largest Cray mainframe, to the smallest embedded system.

The talk first explored the issue of what counts as a platform, listing not just operating systems as platforms, but also OS versions, compilers, tool-sets, internationalisation, hardware configurations - including "compatible" hardware with different performance characteristics, and office environments (culture clash) as containing potential "platform" issues. Beman suggests that the traditional "port", were you develop on X now, and port to Y later is asking for disaster - showing a photograph of a warning sign that reads "Beware of the Wildlife" as a visual device.

The main thrust of Beman's multi-platform strategy was test-focused, advocating a policy of "Test early, test often.", stressing automated testing, at least once a day. He also advocated such test-focused policies such as adding test cases before fixing bugs - and making sure the un-fixed code fails the test case before attempting to fix the problem. Not that this isn't quite the same as the unit-test-first policy advocated by the XP community, which advocates creating the test cases before implementing the code. Beman also suggested a policy of test result publication within the whole project team, as an aid to "team psychology" (a term he used no less than three times during the talk).

Beman acknowledged the harsh reality of software development by suggesting that project teams use "surrogates" for platforms that they "might" have to target, but do not ("currently") have access to, for instance using compilers that are available on the missing platform, or using a free UNIX such as Linux or BSD as a surrogate for a commercial unix such as Solaris or SCO.

He introduced the audience to what he called the Unified-Platform Development Process (UPDP), which places focus on having a single codebase and repository regardless of platform, with "single codebase" including source code, build scripts, test scripts and data, documentation, etc. The audience were also encouraged to use Platform Neutral Development Tools (PNDT), which should "work on one, work on all" - stressing that these tools should not only be portable in of themselves, but should also have portable inputs, be sufficiently powerful to do the job, and culturally acceptable to the project team. PNDTs might include: Repository / SCM clients, compilers, libraries, build systems, test systems, scripting languages, documentation tools, and defect tracking / task allocation software.

Beman said that by investing the time up front to find PNDTs and set up a UPDP the benefits of such a system are: multiplatform failures detected early, developers don't need to be experts on every platform, the cost of adding additional platforms is lowered, and improved project psychology.

The tools described in the talk are available from the following URLs:

Note however that these represent one of many options. Other free and commercial tools exist, and each team should decide which platform neutral tools are best for their project.



Pattern Writing: Live and Direct (double session) - Kevlin Henney, Curbralan Limited & Frank Buschmann

"The class is not a useful element of design ... :)" - Kevlin

Kevlin Henney and Frank Buschmann's joint presentation on pattern writing was interesting and thought provoking, though it did lack the natural 'chemistry' in the back-and-forth between the two speakers as was evident in David Vandevoorde and Nico Josuttis' Secrets and Pitfalls of Templates talk.

The talk started by introducing Patterns, citing several different views on the subject, the best of which being, in my opinion, a quote from Jim Coplien which states that "a pattern is a piece of literature that describes a design problem and a general solution for the problem in a particular context".

The talk explored how patterns document recurring design, and apply to domains outside of programming, for instance, architectural, or organisational patterns. Thus design patterns are sensitive to context. Patterns are not something that you "add" to a project, in the same way as "quality" isn't something that can be "added" to a project. Patterns document an design story, from problem to solution, with consequences and rational. It must document what, how and why.

Many people seem to think that the "Gang of Four" (GoF) book is the only, or definitive, book on software patterns. It is a good book, we were told, but it is 10 years old now, and the industry, and it's understanding of design patterns has moved on.

Kevlin and Frank went on to talk about the essential elements of pattern documentation, making repeated comparisons with GoF. They listed, and explained, the following sections as vital to pattern writing: Identification (name), Context (where the problem occurs), Problem, Solution (not necessarily a class diagram), & Consequences (design is always a trade off). They also recommended providing motivating examples but not a reference implementation.

They also talked about grouping patterns into pattern communities and pattern catalogues, and how some patterns will be complementary, meaning in this context, opposites, completing a natural symmetry of alternative solutions to a single problem, with balanced trade offs. Pattern decomposition was also examined, with the GoF Singleton decomposed into 5 separate patterns by way of example.

The first half of the double session closed with a examination of pattern languages, which forms a vocabulary that connects pattern communities, allowing pattern solutions to be described in terms of other patterns, with context equally, if not more important than it is with individual patterns.

The second half of the talk was in the form of an interactive / audience participation pattern-writing exercise in which an Object Manager pattern, dealing with object creation (Factory Pattern) and life time management, and destruction (Disposal Methods) where discussed and documented, putting the theory of the first half of the talk into a more practical context.

Kevlin has kindly made the slides of this talk available from his homepage, at the following URL: www.two-sdg.demon.co.uk/curbralan/papers/accu/PatternWriting.pdf



End note, extras, etc.

Standardisation, Organisers & Sponsors

The ACCU Spring Conference is organised by Desktop Associates Ltd, in conjunction with the ACCU. One of the activities the ACCU is involved in is the support of standardisation work. The ACCU 2003 Spring Conference was organised as to be at the same venue, at the same time as the WG14, WG21 & J16 standardisation meetings, a practice that ensured the highest quality of speakers and delegates (Bjarne Stroustrup, for example, attended). I think it is worth recognising the sponsors who provide financial support for the standardisation meetings. This year those sponsors were: Microsoft, LDRA, Intel and Hitex. In addition, the conference itself was also sponsored by Perforce Software, and Blackwells. For the sake of completeness, also in attendance as exhibitors were: Rogue Wave Software, QBS Software, and PCG.

Slides & Papers online

Some of the speakers have made the slides and/or papers from their talks available online. Here is a selection of the ones from talks I was unable to attend:

If you enjoyed this article, you may also enjoy the write up of the ACCU Spring Conference 2001, by the same author.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Conferences are where you go to...
o Learn 16%
o Network 36%
o Prop up the bar 12%
o Get away from the office 16%
o Get away from the kids 0%
o Watch porn on pay-per-view 20%

Votes: 25
Results | Other Polls

Related Links
o ACCU
o Python UK Conference
o Linguistic Variables
o Coding Standards
o C++ &amp; Multimethods
o In the Spirit Of C
o Design &amp; Implementation of the Boost Graph Library
o Secrets and Pitfalls of Templates
o The Timing and Cost of Choices
o The Cost of C &amp; C++ Compatibility
o Advanced Template Techniques
o The Internet, Software and Computers
o Multi-Plat form Software Development
o Pattern Writing
o End note
o Byte Craft Limited
o Randy Marques
o Atos Origin
o www.xs4all.nl/~rmarques/Werk/Pres/CodingStandards.ppt
o Julian Smith
o Dylan programming language
o CLOS
o Bjarne Stroustrup
o www.op59.net/accu-2003-multimethods.html
o www.op59.n et/cmm/readme.html
o Greg Colvin
o Oracle Corporation
o Jeremy Siek
o Indiana University Bloomington
o Breadth First Search
o Depth First Search
o Dijkstra's
o Prim's
o Boost Graph Library
o an implementation of the A* algorithm
o David Vandevoorde
o Edison Design Group
o Nico Josuttis
o C++ Templates: The Complete Guide
o 2001 talk on template techniques
o Oxyware Ltd
o www.oxyware.com/Choices.pdf
o Andrew Koenig
o *
o AT&amp;T Shannon Laboratory
o Herb Sutter
o ADL
o the interface principal
o Alan Lenton
o Interactiv e Broadcasting Ltd
o Python
o Ruby
o Java
o C#
o Sun
o Microsoft
o SCO suing IBM over Linux
o Palladium
o RIP
o Beman Dawes
o Boost
o Cray
o Linux
o BSD
o Solaris
o SCO
o www.boost. org/tools
o www.boost. org/libs/config
o www.boost. org/libs/compatibility
o Curbralan Limited
o Frank Buschmann
o Gang of Four
o www.two-sdg.demon.co.uk/curbralan/papers/accu/PatternWriting.pdf
o Desktop Associates Ltd
o Microsoft [2]
o LDRA
o Intel
o Hitex
o Perforce Software
o Blackwells
o Rogue Wave Software
o QBS Software
o PCG
o www.two-sdg.demon.co.uk/curbralan/papers/accu/C++Threading.pdf
o www.jagger soft.com/sauce/
o www.twonine.demon.co.uk/articles/Pattern-Experiences-in-C++.zip
o ACCU Spring Conference 2001
o Also by codemonkey_uk


Display: Sort:
ACCU Spring Conference 2003 Roundup | 162 comments (145 topical, 17 editorial, 0 hidden)
Godless Liberals! (2.18 / 16) (#16)
by egg troll on Fri Apr 11, 2003 at 01:48:48 PM EST

Its bad enough that the ACCU defends communists who want to burn our glorious flag, and supports murderous pedophiles. Now this liberal ACCU wants to teach us how to code? When will good and righteous American's stand up to this group? Act now, before its too late!

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

Provide only one way to do an operation?! (3.00 / 1) (#17)
by x3nophil3 on Fri Apr 11, 2003 at 02:24:02 PM EST

Insightful analysis that...

i++
i += 1
i = i + 1
(*(&i))++ (permute w/ above)


Depends how you look at it. (none / 0) (#28)
by codemonkey_uk on Fri Apr 11, 2003 at 06:42:50 PM EST

Okay, there are a couple of ways of looking at this. First of all, I could be pedantic, and say your first 3 lines of code, conceptually do the following:
  • Increment a variable
  • Add the result of an expression to a variable
  • Assign the result of an expression to a variable
So they are doing three different things, that in this case happen to have the same end result. C being a low level language, being able to be pedantic about semantics gives the programmer more control. The third being a compound statement that goes around the houses to do the same thing, just for the sake of it.

The other way to look at it is to realise that you are being pedantic because you have nothing of value to add to the discussion.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Aiight (none / 0) (#30)
by x3nophil3 on Fri Apr 11, 2003 at 08:47:05 PM EST

Yes, I'm being pedantic, but it still sounds like a bizarre statement to me.

As far as i = i + 1 and i += 1, they are not completely distinct, they have a superset - subset relationship, which has always troubled me.

If we use your strict definition of 'operation', then why does the speaker consider it a notable trait of C? I'm not aware of any language which allows you to increment a variable in multiple ways using the same operators in the same order.

If we use my loose definition of 'operation', then why does the speaker consider it a trait of C at all?

I've had an ongoing internal debate for a long time about whether it's really useful to have a += in addition to =. Thank you for not being insightful enough to realise that it's a worthy topic for discussion.

[ Parent ]

C is a low level language (none / 0) (#53)
by codemonkey_uk on Sun Apr 13, 2003 at 04:48:46 PM EST

Sorry for misreading the point of your comment. The reason for ++ and += predates optimising compilers. An increment is/can be faster and/or use less registers than an addition, and an addition is/can be faster and/or use less registers than an addition followed by an an assignment. So they are really legacy operators. That said, they still provide useful abstractions, helpful in eliminating temporary objects in, for example, heavyweight maths libraries (ie operator+ produces a tempory unnamed result variable that is passed to the assignment). So yes, IMHO it is useful to have a += in addition to =.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
I dunno about useful (none / 0) (#71)
by x3nophil3 on Mon Apr 14, 2003 at 01:42:03 PM EST

Yes, this is one of those linguistic anachronisms like the register keyword.

As far as avoiding temporaries goes, that is one of the things that disturbs me about C++ constantly. Your correct, but that is an optimisation that could feasibly be accomplished by the compiler, if the language had a constraint on overloading that prevented you from throwing sane operator semantics out the window.

That is, if the compiler prevented you from overloading += to do something completely distinct from +, the case where the left-hand expression in addition is also assigned the result of the expression could be optimised to not create a temporary.

Just another case of C++ giving people way more rope (in the twine, not the STL, sense) than they need to hang themselves. Unfortunately it's exactly this sort of thing that leads people to condemn C++ as slow and unnecessarily complicated, imho. But then that's a whole other argument (and one that's based on ignorance, even if it is justified).

[ Parent ]

Re: Provide only one way to do an operation?! (none / 0) (#49)
by Xirtam on Sun Apr 13, 2003 at 02:58:38 AM EST

In addition to the other commentary on this, the expressions you gave aren't all the same for more reasons.

int i = 3;

i++; /* The value of this expression is 3. */
i += 1; /* This one is 4. */

Also, if you assume i is not a simple object, but, say, a macro as in the following:

int array[5], count;
#define i array[count++]
...
i++; /* This is: array[count++]++; */
i = i + 1; /* This is: array[count++] = array[count++] + 1; */

Clearly these are different; the second, in fact, is undefined behavior. This is a contrived example, of course, but that doesn't mean it can never happen.

It's true that in a lot of cases, different expressions will yield precisely the same behavior. But as I hope I've shown, there may be some subtleties you're unaware of, which could bite you if you're not careful.

[ Parent ]

Yes (none / 0) (#73)
by x3nophil3 on Mon Apr 14, 2003 at 02:07:08 PM EST

You're right regarding your first example, but I don't know if that really justifies the existence of the post-(inc|dec)rement operators.

I tend to agree with codemonkey_uk's description of them as anachronistic. If they had atomicity guarantees for simple comparisons, they would continue to be very useful, but unfortunately concurrency wasn't on Kerningham or Ritchie's minds at that time.

if ( 0 == i++ ) {
}

If that comparison was executed atomicly with the post-increment, we would have a BTS equivalent in C, and could implement things like mutexes without going to assembly, which would be very nice, imho. Nonetheless, I use post-increment all the time, it is idiomatic and useful.

Your second example is less interesting. Since macros are a pre-processor function with almost no syntactic constraints, it's not very hard to figure out how they can break things in new and unusual ways. Having a pre-processor that's independant of the syntax of the language is amazing, but makes it pretty vacuously true that macros can break semantics.

See, while I am a C programmer, I came to C after learning Pascal, which lacks all the syntactic sugar operators. I never missed them in Pascal, and have now come full circle and try to avoid them in C.

C requires a lot of self-restraint, imho. Lots of C programmers are addicted to playing with the syntax of the language i.e.:

for ( i = 0; str[i]; str2[i] = str[i++] );

Which is cool, and faster than a stupid strncpy implementation. Unfortunately it also creates a potential buffer overflow, and is really slow if the compiler doesn't optimise it to copy through a 32bit register.

C is just a little too loose sometimes; even programmers who claim to know it really well often produce turgid, baroque, crap. I have never thought of it as rigidly 'providing one way to do an operation'. The aesthetic of C, seems to me, to be quite contrary to this principal.

C confuses economy-of-expression with brevity.


[ Parent ]

Cool... (5.00 / 1) (#108)
by Xirtam on Mon Apr 14, 2003 at 07:16:11 PM EST

for ( i = 0; str[i]; str2[i] = str[i++] );

You call this cool, but it's just flat out wrong (in addition to what you mentioned).  In C, str2[i] = str[i++] is undefined.  So, really, you're proving your point that C can cause you to write bad code while trying to be clever.  But it's a double-edged sword: You can write great, clever code as well.  I'll take the tradeoff.

If you care, you can see the effects of the undefined behavior by using the above construct with Intel's C Compiler (at least with version 7).  It doesn't do what you expect.

[ Parent ]

Interesting (3.00 / 1) (#113)
by x3nophil3 on Tue Apr 15, 2003 at 11:31:30 AM EST

Interesting,

I admit I just whacked that together off the top of my head. Why is it undefined?

str2[i] = str[i] is certainly defined, as is j = i++. So what's different about str2[i] = str[i++]?

[ Parent ]

Because i appears twice. (5.00 / 1) (#114)
by ucblockhead on Tue Apr 15, 2003 at 11:50:46 AM EST

When you use the increment operator on a variable, any other use of that variable in a line is undefined. That is to say, the compiler vendor can do whatever the fuck they want.

A compiler could, in theory, evaluate the right, then increment i, then evaluate the left.

(Insert rant about stupid standard committees making things undefined to make life easier on lame compiler vendors on obscure hardware.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Learn something new... (none / 0) (#118)
by x3nophil3 on Tue Apr 15, 2003 at 12:42:37 PM EST

every day.

That is dreadful. Double checking I came across this also:

i=2;
foo = i++ * i++;

Apparently this can assign 4 to foo, and do both postincrements subsequent to the multiplication.

Holy shit is that awful.

On the subject, did you know about this:

char foo[128];
foo[1] = 1; // syntactically valid
2[foo] = 2; // also syntactically valid

[ Parent ]

LOL (none / 0) (#135)
by codemonkey_uk on Wed Apr 16, 2003 at 04:49:21 AM EST

Welcome to the wonderful world of Obfuscated C!
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Go ahead (1.11 / 9) (#18)
by medham on Fri Apr 11, 2003 at 03:15:54 PM EST

Join the ACLU; we'll protect your freedom anyway.

The real 'medham' has userid 6831.

I've got a great topic for a long, detailed story (1.25 / 4) (#20)
by IHCOYC on Fri Apr 11, 2003 at 03:22:39 PM EST

How 'bout a long analysis of the regulations of the Indiana Plumbing Commission? (PDF) With helpful hints on how to pass the plumber's exam, maybe?

Perhaps explaining what the "ACCU" is might have been a more promising start. At least I know what plumbing is. . . .
 --
The color is black, the material is leather, the seduction is beauty, the justification is honesty, the aim is ecstasy, the fantasy is death.

Hmm (3.63 / 11) (#22)
by trhurler on Fri Apr 11, 2003 at 04:28:41 PM EST

So basically, you had a few people talking about odds and ends, and a lot of people trying hard to find nice things to say about C++. I tried to find something I could get worked up about, but other than the fact that patterns are basically a way to formalize the educations of people who are in no way yet qualified to actually be paid money to program, I can't really find anything. I could rant about C++, but that's getting tired.

Really though, patterns belong in schools. Maybe in continuing education and seminars and so on. Maybe near the core of some "can think clearly" certification for programmers. The idea that industry people are actively developing this stuff suggests that they're having to train morons on the fundamentals of programming, which means either they aren't paying enough or else they're deliberately hiring unqualified individuals. Fuckers.

Then again, I tend to consider people who aren't as good as I am to be incompetent, and I suppose most people probably don't. Fuck that though; I don't want to work with useless fuckers who can barely write bad perl scripts.

Here's my advice for those of you considering implementing something with templates: throw yourself off a tall building instead. Here's my advice for those considering maintaining such code: throw yourself off a tall building instead, after consuming a few grams of cyanide just in case.

It never ceases to amaze me the apology that gets written for C++. "Oh, it isn't that bad. You learn to manage. Blah blah." Hey, I don't have to learn to cope with the tools I use. I don't have to sit around daydreaming about corner cases until the end of time. It just isn't necessary. Why? Because I don't use things that suck. That's what "suck" means. It doesn't mean "won't work." It means "is a pain in the ass." WHY DO PEOPLE USE C++? It doesn't make any fucking sense. The language makes EVERYTHING harder, and the only thing it does for you relative to C, in theory, is save some typing. Truth be known, it doesn't even do that, because it adds so much fucking verbiage over nothing.

Of course, purists will start telling me about how C++ "enables" "modern" design and so on. This is because they don't know how to write C properly, and were never taught. Smug, self righteous fucktards, all of them, and they probably couldn't even READ good C.

I despise everything about C++, except the idea of a C-like OO-ish language. That idea will live on someday, in some language that doesn't suck ass.

--
'God dammit, your posts make me hard.' --LilDebbie

Disapointing (4.50 / 4) (#26)
by codemonkey_uk on Fri Apr 11, 2003 at 06:27:46 PM EST

I'm disappointed in you trhurler. This is a particularly sub-par rant. In the past you've put forward some interesting arguments with regards your views on programming language design. I'll have to put this slip down to you being overwhelmed by the sheer quantity of good material too work with.

Oh, and just out of curiosity, do you think I "don't know how to write C properly"? Because C++ does enable modern design. It's a very powerful tool. Now, I'm not saying it's perfect, not at all, no one who commands any respect at all in the C++ community thinks that, not even the bloody standards team thinks it's perfect. No one at that conference would seriously suggest it is a good first language, or that inexperienced staff should be let loose on a C++ project without some close mentoring. We all accept that there are lots of problems, and that the standardisation team made some mistakes. Some real clangers as it happens. Yet, despite this, it is still one of the most powerful and enabling languages I've ever worked with. It is also the most difficult language I've ever worked with. There is no denying that.

So isn't is about time the rest of the programming world stopped getting is such an embarrassing tizzy about how "hard" and "ugly" C++ is, and just use the tools that they are comfortable with?

I'm not even going to get into your bizarre anti-patterns bit. Why you object to the study of design, and the continuation of education of working staff is utterly beyond me.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Bah (4.33 / 6) (#29)
by trhurler on Fri Apr 11, 2003 at 06:57:11 PM EST

C++ gets everything wrong.

First of all, object orientation without a singly rooted object tree is just wrong. If you want to know why, I can write quite an essay on that topic. This flaw makes writing good code that truly takes advantage of object orientation in the presence of third party code very nearly impossible; everything ends up being a hack to get around a hack to get around another hack. No, the STL does not fix this. It makes it worse, because it came along so late that there are untold millions of lines of code that predate it which found their OWN solutions to problems, but even if it weren't for that(obvious) blunder, it also manages to avoid providing all the advantages of a singly rooted object tree.

Second, the insistence upon source compatibility with C is the stupidest idea ever advanced in programming languages. I am serious. This one lunatic requirement on the part of Bjarne "I'm being taken seriously as a language guy even though I know jack shit about the topic and am actually a simulations guy" Stroustrup has created or provided impetus for at least 90% of the inane backwards arcanity of C++. It is totally unnecessary; all that was needed was to provide a way to link object files created by the C compiler with C++. Therefore, every disadvantage it has is TOTALLY without justification. All talk about evolution is some monkey flinging feces, because nobody ever really NEEDED to do this.

Third, the language was designed by committee. Compare with PL/I, COBOL, and Ada if you want to know why this is a bad idea. A proud tradition of the worst programming languages EVER - all designed by committee. Can you say "kitchen sink?" I thought you could.

Fourth, name one important concept that C++ actually provides a sane implementation of. Not objects. Not exceptions. Not functions(!) Not strings. Not containers(STL is about the most featureless generic container library I've ever been exposed to.) Shall I go on?

Fifth, static typechecking in combination with dynamic loading(which C++ has to acquire from C in a very poorly fitting form, since it is a pansy ass language with no balls,) is like shit mixed with beef stew. Add in the mess that is C++'s templates and exceptions, and the result is complete uselessness. But hey, nobody wants dynamic linking anyway, I'm sure. Certainly not in a systems language(har.)

Sixth, C++ lacks constructs it ought to have, like a generally applicable foreach, a means of calling a method on all objects of a given type with a single call, a means of calling a method on all objects with a single call, a means of calling a method on all objects of a given type and all its subtypes with a given call, a robust runtime typechecker(who needs one when you have static checking that... can't actually do the job... in the face of modern programming methods... like... say... dynamic linkage of generics... not that C++ can do that anyway...

Seventh, an answer to your "but it is powerful" objection: power without clarity or ease of use completely misses the point of having high level languages. The chosen few who can actually really understand C++ don't need it, and those who could theoretically benefit from its expressive power can't understand it. What's the goddamned point in having underlings if you can't trust them to do anything without being watched constantly?!

Eighth, about using the tools I'm comfortable with: I do, but I also rant about C++, because I like to rant, and because C++ sucks.

Finally, about patterns: I'm not against patterns. However, they're a learning tool. Why are they so popular as self help seminars for so-called "professionals," and why are they so nearly absent from academia outside of a few institutions here and there? If your staff doesn't already understand the patterns common enough to be worth knowing, then why are they on your staff?! This is what I don't get. It is like these fucking Cisco monkeys we now have who don't even know that the hardware they're working on autosenses cable type - why on earth are these fuckers employed here instead of at a goddamned motherfucking Taco Bell where they belong, while guys like me are being told that due to corporate growth needs, there's no money to give us the raises we(they admit) DESERVE?! Also, the pattern concept has been stretched and distorted to nearly useless extents by way too many people, but apparently the speaker avoided that, which is nice.

In summary, your favorite programming language sucks, and so do stupid ignorant dumbfucks. Thank you very much.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Please. (3.00 / 1) (#31)
by i on Fri Apr 11, 2003 at 09:20:19 PM EST

Write that essay. I genuinely want to know. What are the advantages of a singly rooted object tree? I guarantee you my +1FP, anytime.

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
... that Darwinian theory can be applied? (none / 0) (#35)
by it certainly is on Fri Apr 11, 2003 at 11:06:06 PM EST



kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

Briefly ... (3.50 / 2) (#36)
by Simon Kinahan on Sat Apr 12, 2003 at 08:16:47 AM EST

Because the point of object orientation is interface polymorphism, and the normal mechanism for interface polymorphism is what C++ people goofily call "virtual functions" and everyone else calls methods. There are operations that can reasonable be applied to any object (discovering its type, discovering its identity, deleting it, and so on ...) and in languages with a rooted object hierarchy these are methods on the root (class Object, normally).

The fact that C++ does not provide a rooted class hierarchy, let alone the usual library of abstract classes for common contracts, seriously limits the usefulness of virtual functions. Thus, when C++ people want to write generally useful code that exploits interface polymorphism, they fall back on the template mechanism, which does no proper type checks, and therefore can exploit common operations on unrelated types. This leads the the amazing backwards mirror world of C++ design where people come up with fabulously complex ways of reproducing effects that can be obtained trivially in other other languages using the template mechanism.

Simon

If you disagree, post, don't moderate
[ Parent ]

The market reacted against it (none / 0) (#39)
by ucblockhead on Sat Apr 12, 2003 at 10:46:01 AM EST

Both Borland and Microsoft have hierarchies based on some sort of Object class and container classes that work with them before templates were even part of the language.

In terms of getting things done, I'll take the STL approach, thank you very much. It has nothing to do with "falling back" to template code. The "derives from CObject" approach lost in the C++ marketplace of ideas because people found it less useful.

It would be pretty easy for some vendor or group (like boost) to come up with a rooted object tree. The reason that no one does is that no one in the C++ community wants it. It isn't a real deficiency.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Not what I meant (none / 0) (#40)
by Simon Kinahan on Sat Apr 12, 2003 at 10:52:38 AM EST

Using the rooted object hierarchy to write collection classes that operate on Objects in a statically typed languages is an inferior solution to using generic types, which is why its the one use of templates in C++ that I didn't mention. This is why C# and Java are both adding generic types in the near future.

It would be extremely hard to add a standard class library in the style of other OO languages to C++ at this time, since there are already almost-sufficient template based ways of doing the same things, and it would probably significantly break the semantics of many programs. That isn't a good reason not to lament its absence, though.

Simon

If you disagree, post, don't moderate
[ Parent ]

As I said (none / 0) (#41)
by ucblockhead on Sat Apr 12, 2003 at 11:43:59 AM EST

Both Borland and Microsoft had an object based hierarchy in their compilers before templates were part of the language.

No one used them other than to interact with the classes that required them.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

That proves nothing (5.00 / 1) (#42)
by Simon Kinahan on Sat Apr 12, 2003 at 12:04:24 PM EST

Relying on vendor specific extensions and libraries is a bad idea, and for many people that's an overriding consideration. I wrote some C++ at the time to which you are referring, and avoided them like the plague for portability reasons.

Simon

If you disagree, post, don't moderate
[ Parent ]
Well, maybe... (none / 0) (#43)
by ucblockhead on Sat Apr 12, 2003 at 04:38:12 PM EST

I do know that the only people complaining about the lack of a single inheritance hierarchy are those who don't use C++. In C++ circles, you are far more likely to hear complaints of object hierarchies that are too deep.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
No (none / 0) (#44)
by Simon Kinahan on Sat Apr 12, 2003 at 06:46:21 PM EST

I use C++. It is the best choice for a certain combination of performance and project complexity. I'm just aware of its deficiencies. I'd prefer there to be a less baroque language in that space, but there isn't one.

I'm not sure what you think the relationship between rootedness and deep inheritance hierarchies is, so I can't really comment on that. Inheritance hierarchies should be the right depth. Usually that's not very deep, but this seems to be a totally different question from whether they have a single root.

Just to clear one thing up: I don't think the addition of a class hierarchy root would help C++. Other features of the language, such as the way multiple inheritance is handled, would make it hard, even if there weren't loads of legacy code that would break.

Simon

If you disagree, post, don't moderate
[ Parent ]

Performance (none / 0) (#45)
by ucblockhead on Sat Apr 12, 2003 at 07:38:03 PM EST

Perhaps a simple example might clarify things. Here is code that allocates memory for each object. Here is similar code that does not. The second bit of code runs nearly six times faster.

That's the performance penalty you pay for allocating every object separately, something you have to do for polymorphism. Requiring that every object be derived from "Object" forces you to pay that price even if you don't need polymorphism.

If you can tell me how to derive everything from object, then yeah, great...but until then, I'd prefer not to have the tools I need taken away.

Now I agree that C++ isn't for every project. However, what I get irritated at is the criticisms of C++ that seem to want to remove those language features that make C++ useful for the projects it is useful for.

I mean, you take C++ and change it to derive everything from Object, use garbage collection and bounds checked arrays and you've got "Managed C++", which is basically just Java with crappy syntax. No thanks.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

I don't see why (none / 0) (#46)
by greenrd on Sat Apr 12, 2003 at 08:05:44 PM EST

That's the performance penalty you pay for allocating every object separately, something you have to do for polymorphism. Requiring that every object be derived from "Object" forces you to pay that price even if you don't need polymorphism.

I'm not sure that I understand your point, but it seems that you're saying that since subclasses can have different memory requirements per instance than their superclasses, you'd have to allocate every object separately.

This is not always true. For instance (I don't know C++ I'm afraid, so I'll use a Java example), with:

public class A { String name; }
public final class B extends A { int age; }
public class C { B b; public C () { b = new B (); } public static void main () { c = new C(); } }
Space for b can be allocated along with c, because class B is declared final (can't have any subclasses), so you know at compile-time that b will at any time be either null, or an object consisting of precisely two fields.

You can take that a step further and make the JIT compiler detect when a class is effectively final (i.e. has no subclasses) and optimise accordingly. (Disentangling the situation when a subclass of that class is dynamically loaded is left as an exercise to the reader ;-)

It's a bit flippant to reply to many performance objections by saying "oh it can be optimised away" - but in some cases it happens to be true.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

No, no... (none / 0) (#47)
by ucblockhead on Sat Apr 12, 2003 at 09:24:34 PM EST

That's not the big performance win. The big performance win is that the vector does not allocate memory for each object but instead allocates blocks of memory containing multiple objects.

In fact, I could have gone further in the second example and told the vector to start out with space for the full million objects at start up, in which case the program would have effectively done only a single memory allocation, period.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Umm, no (none / 0) (#48)
by Vulcannis on Sun Apr 13, 2003 at 12:34:57 AM EST

What your two code examples show is that stack based allocation is six times faster than the default heap based allocation, for your compiler and library.  However, you are free to use different methods for memory allocation than those two.  C++ will even let you do so without requiring any syntax changes in your application, simply provide an alternate operator new.  If you're going to throw numbers around, at least attribute them correctly.

Your second paragraph is a little unclear, but your claim is false.  A singly-rooted hierarchy makes no performance demands simply by it's existence.  As a counterexample I'll again point to Eiffel, where every class is ultimately derived from ANY.  Despite this Eiffel still has the concept of expanded objects and types, which accomplishes exactly what you did in your second example.  I'm not quite sure how your examples prove your point anyway, given that they make no use of a common base class.

---
If it's not black and white, you're not looking close enough.
[ Parent ]

Stack based allocation (none / 0) (#51)
by ucblockhead on Sun Apr 13, 2003 at 08:19:08 AM EST

Neither example uses the stack for anything other than temporaries. The second example puts everything on the heap. What's important is that everything is on the heap in one single piece of allocated memory. (I.e. the entire vector is in one block of memory.)

The very point of the examples is that they don't use common base classes. I'll have to look into Eiffel.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Sorry (none / 0) (#52)
by Vulcannis on Sun Apr 13, 2003 at 12:26:36 PM EST

You're right about the stack/heap.  I criticized you for mis-attributing then do it myself.  At least it's all sorted out now... :P

Aye, and I'm saying the presence of common base classes shouldn't have had any performance affect upon either example, which is what you argued.  Unfortunately I don't have a C++ compiler handy at the moment so I can't just drop some changes in and say "see!" or "oops."

---
If it's not black and white, you're not looking close enough.
[ Parent ]

Well... (none / 0) (#54)
by ucblockhead on Sun Apr 13, 2003 at 06:34:52 PM EST

Well, it looks like I'm wrong, anyway...I need to learn Eiffel to be sure, but... I really wish that C# and Java had the same ability to create inplace objects like C++ and (apparently) Eiffel do.

It's just a bug of mine because I've seen things that purport to "compare" Java and C++, performance wise, and then use new for everything just like you do in Java. Not only does it miss an important optimization, but it makes the memory management substantually harder.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Um... (none / 0) (#67)
by trhurler on Mon Apr 14, 2003 at 01:07:57 PM EST

If you aren't going to use new, then why are you bothering with C++? Do away with the syntactic sugar, and there's this really nice language called "C" you could use instead:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
"new" (none / 0) (#75)
by ucblockhead on Mon Apr 14, 2003 at 02:16:57 PM EST

"minimize the use of" is not the same as "don't use".

But it's not a language issue...it's like saying "minimize the use of malloc" in C.

But I suspect that you didn't really understand the code...because new does get called...just not by mode code.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Actually, (none / 0) (#78)
by trhurler on Mon Apr 14, 2003 at 03:55:10 PM EST

While I can easily understand just about any code written in a language whose syntax is similar to C, Pascal, etc, I didn't bother to read your example, because what matters is the claims you're making about the code, not the code itself. (Also because you're probably mistaken about how things are happening in the Microsoft runtime, which does all sorts of really gross things, so reading your code will just muddy the real issue, which is the factual claims you're making about the results.)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Heh (none / 0) (#82)
by ucblockhead on Mon Apr 14, 2003 at 04:13:35 PM EST

Oh, yeah, you don't need to understand the code...

Bleah...too arrogant to think, more like it.

I'm interested in hearing how I'm "probably mistaken". Do tell...
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Hmm (none / 0) (#85)
by trhurler on Mon Apr 14, 2003 at 04:22:35 PM EST

No, certainly it is not that I don't need to understand the code - it is that you are making a very specific claim that either is true or is not true ABOUT some piece of code. Either it is true that memory allocation is "six times slower" one way than the other or it is not, and regardless of whether it is true, the magnitude of the actual difference is of FAR more significance than this multiple you've provided. Looking at the code won't provide ANY of the interesting answers here. What I want to know is, how fast was the faster one, and how fast was the slower one? It is notable that you don't ever mention actual magnitudes; I suspect this is because they're both so small as to be meaningless. (Generally speaking, a linear multiplier is irrelevant unless it is huge. Real speedups come when you go beyond linear time savings. You should, of course, know this, but your whole thread here is one big attempt to deny everything useful that's been learned about algorithmic complexity in the last 100 years or so.)

As for being probably mistaken, I don't know Microsoft's runtimes much better than anyone else, but I do know that, for instance, code that according to Microsoft documentation ought to compile to essentially the same thing can produce WILDLY different results depending on minor stupidities. They claim C# and "Managed C++" are very similar in performance, but in practice, one is better at some things than the other and vice versa in big ways - for no discernable reason. The point is, you cannot count on changing "just one thing" with Microsoft runtimes. There IS no well controlled experiment using their software.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Heh (none / 0) (#89)
by ucblockhead on Mon Apr 14, 2003 at 04:56:18 PM EST

The example that allocated everything in a block took a total of 0.29 seconds to allocated, use and deallocate the array. (0.24 seconds to allocate, .5 to use and less than a clock tick to deallocate). The example that allocated individual obkects took 0.179 seconds, about 2/3rds of which was in allocation.

I did compile both examples with /CLR...both examples took about twice the time. That's very much in line with every other test I've run that looks at the overhead involved in IL.

Anyway, I don't think you really understand what the example is showing...the slowdown is not linear. I never claimed it was. I was only making a claim about this particular example. The actual slowdown is going to depend entirely on the sorts of objects you are allocating. For example, you obviously can't do what I was doing if you are going to use polymorphism.

My claim has only been that C++ allowed you to combine multiple objects into single memory allocation units (like Eiffel, but unlike C# or Java), and that this feature could allow great speed benefits in certain applications. Do you understand this? It's hardly an outlandish claim. Did you bother to read before launching into your patented anti-C++ diatribe?

Also, none of this has to do with "Microsoft runtimes". That's one of those statements that makes me truly wonder if you are understanding what's going on here. Heap management is pretty standardized these days. Anyway, the results are even more dramatic with G++. The version that avoids small heap allocates runs almost nine times faster (in 0.36 seconds instead of 3.1). This is likely because Microsoft is using a special heap optimized for small blocks, and because my example usings small objects.

(Another advantage that I have not mentioned here is that the version that allocates fewer blocks (perhaps even only a single one, depending on various factors) is going to use substantially less memory as each block has overhead.)

To put it in a language that you might understand, the slow version does this:

Foo** Array=(Foo**)malloc(sizeof(Foo*)*1000000);
for(i=0;i<10000000;i++)
  Array[i] = (Foo*)malloc(sizeof(Foo));

while the other does this1:

Foo* Array=(Foo*)malloc(sizeof(Foo)*1000000);

Does that help you understand the difference?

1There are actually some reallocs, but they can avoided if you tell vector to reserve the right amount of memory.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

I give up (none / 0) (#94)
by trhurler on Mon Apr 14, 2003 at 05:40:11 PM EST

For some reason that is beyond my comprehension, your memory allocations are measured in tenths of seconds. I have never in my life used a machine so slow that this is the case - not even a Commodore 64. I can only conclude that you live in an alternate reality and that we are arguing past each other as a result of this fact.

What in the name of all that is good and right in this world is wrong with your environment that slows down memory allocations by several orders of magnitude?!

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Ummm.... (none / 0) (#141)
by ucblockhead on Wed Apr 16, 2003 at 12:57:17 PM EST

I could explain why it takes time to allocate a million blocks of memory, or why calling realloc a couple times on something that's a couple megabytes longmight take time on the order of a tenth of a second, but why bother? You're either not reading carefully enough, or just clueless.

I could give you the number of clock ticks, if you want. The numbers are in tenths of a second because I saw little sense in providing meaningless digits of precision. Regardless of that fact, I provided the fucking source code...you could find the timings yourself, you know.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Fight! Fight! Fight! Fight! nt (3.00 / 1) (#134)
by MrSnrub on Wed Apr 16, 2003 at 04:44:34 AM EST



[ Parent ]
In my ideal world ... (none / 0) (#50)
by Simon Kinahan on Sun Apr 13, 2003 at 07:28:56 AM EST

Languages that work at a more abstract level than C++ tend to look for the kinds of performance gains you talk about through dynamic, run-time optimisation. Obviously the cost of doing that analysis at run-time means they can never achieve the performance of C++.

The language I would really like to see isn't "Managed C++". God forbid. Rather, it is a language with simpler syntax than C++, working at a more abstract level, that did the analysis Java or Smalltalk does at run-time but moved it to compile time, and then allowed the programmer the control C++ allows if they needed it. Some trends in C++ design, using templates, seem to be headed in this direction ("Modern C++ Design" is the first programming book to surprise me in a long time) but unfortunately the language's behaviour doesn't degrade smoothly: You can't not think about low-level issues in C++, because you'll meet with disaster. Whereas Java or C# prevent you thinking about them, my ideal language would let you think about them where you really need to.

Simon

If you disagree, post, don't moderate
[ Parent ]

You know (none / 0) (#66)
by trhurler on Mon Apr 14, 2003 at 01:06:56 PM EST

First of all, the number of cases in which that factor of six matters is exceedingly small. Computers have gotten much more than six times faster even just since I've graduated from college. I realize you'll deny this(people using the performance argument ALWAYS do,) but if you aren't writing realtime code or some sort of numerical analysis or rendering or similar research application that runs for hours at a time, then performance gains of this sort are irrelevant. Almost all C++ projects could be just as well written in a C++ like language that had a single rooted object tree without the users being able to tell any difference at all on reasonably current hardware.

Second, I'm not in favor of garbage collection. It makes the easy case easier, and the hard case harder. I'd rather keep the easy case at "only kind of easy," and use static analysis tools to fix problems there while keeping the hard case managable instead of completely impossible, which is what it is in most GC systems. GC advocates are typically eggheads with no sense of reality and no perspective on what programming outside of their little research lab is like.

Third, things like bounds checked arrays don't even need to be a language feature. They can be a compiler switch for debugging purposes:)

Finally, with a true single rooted object heirarchy, you will save execution time in many places, do less cache thrashing(more commonality of code, fewer needless branches,) and generally that factor of six might disappear in a big hurry in a real application, although really it isn't a factor of six anyway for any real measurement since any sane program does NOT spend a significant fraction of its time allocating memory(ie, you are optimizing something that isn't a bottleneck anyway.) In addition, an optimizing compiler could eliminate most of the factor of six directly by restructuring memory allocations and playing other dirty tricks.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
"Oh, performance doesn't matter" (none / 0) (#74)
by ucblockhead on Mon Apr 14, 2003 at 02:13:42 PM EST

BULLSHIT!

Spoken like someone who doesn't do UIs. Users notice when it takes 750 milliseconds to resize a window instead of 250 milliseconds.

Yeah, writing some glorified batch processing server app, you can throw knew hardware at it. But in the real world, writing user apps, you have to deal with users getting pissed off because it takes too long for the window to open on their 250 Mhz boz with its 64 Mb of RAM.

Which is exactly why Java is so rare on the client side.

Yeah, my sample was a little test app...but I am working on a real app in a real language that performs significantly worse (factor of four) than a similar C++ app written the year before. And frankly, I am fucking sick and tired of hearing about mythical optimizing compilers that can somehow fix it all. If you can't tell me a fucking product number and price, then I don't want to hear about it.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Um... (none / 0) (#77)
by trhurler on Mon Apr 14, 2003 at 03:53:00 PM EST

I hate to break this to you, but the difference between 750 milliseconds and 250 milliseconds on a modern CPU is measured in hundreds of millions or billions of instructions. If you think a factor of six in a memory allocation significantly impacts the speed a window resizes, then either your windowing code is really shitty(possible, actually,) or you're wrong.

Incidentally, the reason Java is rare on the client side is because Microsoft doesn't support it and most of the clients are Windows machines. It was catching on, even when machines were much slower, UNTIL Microsoft decided they didn't want to play nice.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bullshit (none / 0) (#83)
by ucblockhead on Mon Apr 14, 2003 at 04:14:17 PM EST

I don't think...I know...I've got the fucking profiler dumps to prove it.

You try resizing multiple bitmaps with transparency on Windows...we'll see how far you get. But no, memory allocation doesn't have anything to do with resize problems. Those have to do with bytecode vs. real code and stupid-ass APIs. But regardless, your flippancy about performance shows that you've never done real client work.

It is quite clear that you've never tried writing a real, production Java client. Not some bullshit, generic looking test app, but a real product with a real UI. No, it isn't Microsoft that is the problem...JVMs run on Windows, you know. The reason is that most of the initial attempts to do client work in Java (like that long-dead Java browser) failed utterly. Yeah, "HotJava" failed because of Microsoft. Right. Uh huh.

Java has its place. That place is called "the server". Because on the server, you can just double memory. You can't do that on the client, at least, not without pissing off customers.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#86)
by trhurler on Mon Apr 14, 2003 at 04:30:12 PM EST

You try resizing multiple bitmaps with transparency on Windows...we'll see how far you get.
So the problem is that your windowing code is shitty, and actually does memory reallocations every time you resize a window? How is that my problem? Real windowing systems use algorithms developed back in, say, the 50s for avoiding this sort of problem:)
But no, memory allocation doesn't have anything to do with resize problems. Those have to do with bytecode vs. real code and stupid-ass APIs.
Nobody said your Java should run interpreted on the client:) (For that matter, I don't even like Java. My point is merely that it is a massively successful language. Your niche notwithstanding, the market is huge. Java programmers are in much more demand than C++ programmers.)
But regardless, your flippancy about performance shows that you've never done real client work.
Sure I have. In C. :)
No, it isn't Microsoft that is the problem...JVMs run on Windows, you know.
Yes, but where can I get Microsoft Visual Java dot NET (TM)? Oh, that's right, I can't, so most Windows shops won't even consider the language.
Yeah, "HotJava" failed because of Microsoft. Right. Uh huh.
HotJava was a demonstrator. It was never intended to be the next Netscape.
Java has its place. That place is called "the server".
For now I more or less agree. I think you'll be eating your words in ten years, because the average lifespan of a PC is less than three; in less than ten years, your average user's system is going to be really, really fast, and nobody will care about the five percent on the low low end of the bell curve, because they can be written out of the requirements spec that goes on the box:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Fucking read (none / 0) (#91)
by ucblockhead on Mon Apr 14, 2003 at 05:07:20 PM EST

Did you read the sentence after the bit about resizing? Aparently not.

The window resizing problem has more to do with bytecode and a stupid API. Not memory allocation. As I said. Try reading.

Sure I have. In C.

Yes...why on earth you haven't moved on to a real language is beyond me.

Yes, but where can I get Microsoft Visual Java dot NET (TM)? Oh, that's right, I can't, so most Windows shops won't even consider the language.

Oh, yeah...that's be a problem for years...

You may well be right about the future...despite what you think about me, I wouldn't mind being able to use a language with, say, real string handling or a reasonable syntax. But right now, I'm gonna stick to using whatever languages allow me to impress my bosses and customers. These days, that's mostly C++.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Oh really? (none / 0) (#96)
by trhurler on Mon Apr 14, 2003 at 05:43:34 PM EST

Yes...why on earth you haven't moved on to a real language is beyond me.
Two reasons. One, because this one has a far higher ratio of salary to hassle than any other I've encountered. Two, because I haven't found such a language. I keep looking, but all languages to date suck ass, and C just sucks a bit LESS ass. C++ is the present day version of PL/1, and will die off shortly when people come to their senses. Just wait.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Heh (none / 0) (#61)
by trhurler on Mon Apr 14, 2003 at 12:47:57 PM EST

I know lots of C++ users who also use Java, Smalltalk. or other languages that got this part RIGHT, and they ALL swear up and down that they want to rip Bjarne's heart out through his asshole for not doing this right. Typically they're not C++ users by choice, but that's what a proper education will do to you:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Not even remotely correct (none / 0) (#60)
by trhurler on Mon Apr 14, 2003 at 12:44:48 PM EST

The market reacted against those systems because they were proprietary, poorly thought out, and NOT integral to the language. This is why languages need to have these things as integral parts, which all implementations must provide in a standard way.

The market reacted against lock-in and bad design - not against singly rooted object trees.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bullshit (none / 0) (#64)
by ucblockhead on Mon Apr 14, 2003 at 12:57:13 PM EST

Yeah, that's why you find programs full of "CString" references, but without deriving anything from "CObject" in Microsoft C++ code, circa '97...

If you've never run into people using badly designed properietary classes, I've got to presume you've never done much maintentance programming.

Especially illuminating was that Borland used to provide two sets of collection classes. One to objects derived from a base object class. The other used void* and casting.

Guess which people used.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Which one they used? (none / 0) (#68)
by trhurler on Mon Apr 14, 2003 at 01:19:39 PM EST

I'm betting on "the one they understood better." IE, the one that looked more like C. Look, I'm not going to argue this with you any further; the massive success of Java is proof enough that the market doesn't hate singly rooted object trees, and there are other less successful languages out there which, if you used them long enough to actually understand them(fat chance; from the sound of it, you're a one trick pony who doesn't want anything disrupting his nice neat little world:), would make you despise C++ forevermore. (See Smalltalk for one example. Frankly, understanding Smalltalk will make you despise just about EVERYTHING else that claims to be object oriented, EVEN if you don't like Smalltalk.)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Massive success? (none / 0) (#72)
by ucblockhead on Mon Apr 14, 2003 at 02:06:46 PM EST

Java is a success...but hardly a massive one. It still barely registers as a client side language.

I knew four programming langauges before C++ even existed. I've spent the last year coding in C#. If I don't understand Smalltalk, it is because it is well over a decade before I fiddled with that language.

One trick pony, my ass.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#79)
by trhurler on Mon Apr 14, 2003 at 03:57:35 PM EST

Look, there are more people writing web apps and middleware in Java than there have ever been producing client side applications for PCs or workstations. That's a "massive" success, even if it is gross. Similarly, COBOL is still the most used programming language ever, and will be for a long time, if you count programmer/hours or lines of code or some similar metric. That's a "massive" success.

Success is not measured in trendiness among people who do a given sort of work, or in trade rag articles, and contrary to popular belief, the desktop is not the biggest market out there when it comes to software sales. Not even close.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
I never said it was (none / 0) (#81)
by ucblockhead on Mon Apr 14, 2003 at 04:04:58 PM EST

But being a client-side programmer, I'll stick to languages that are good at it.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Heh (none / 0) (#87)
by trhurler on Mon Apr 14, 2003 at 04:38:17 PM EST

Even Bjarne doesn't think C++ is the right answer for applications. How do I know? I asked him in person at a conference:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bjarne (none / 0) (#90)
by ucblockhead on Mon Apr 14, 2003 at 04:59:33 PM EST

Bjarne isn't a client-side programmer.

Frankly, C++ isn't the best language. I'd personally prefer to use some Pascal derivative. Just don't make me use some crappy Java derivative for something it's bad at. (C# isn't too bad if you are writing the sort of plain vanila Windows app like people used to use VB for.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Languages (none / 0) (#93)
by jacob on Mon Apr 14, 2003 at 05:33:44 PM EST

Just to throw my two cents in at a more-or-less random point in the argument:

'Applications' programming these days seems to be Model-View-Controller, where Model is some random, generally interactive process, View is a GUI, and Controller is a keyboard/mouse interceptor that does a little multiplexing.

  • Controller isn't difficult.
  • Model's performance isn't generally a big deal in my experience. If the model is too slow after you optimize your algorithms, you can export a few isolated loops to C or FORTRAN or whatever and you'll probably be fine. So, this piece ought to get written in Scheme or ML or Prolog or Perl whatever other high-level language floats your boat. (If that language is a C-alike, you may wish to inspect your boat.)
  • Big pieces of View are still performance-critical on modern systems. It may well need to be written in a language where you spend brainpower deciding exactly how the computer will decide where the bits go and what they look like. Fortunately, computers keep getting faster, but our requirements for a responsive GUI stay the same, so we may not have to put up with this state of affairs forever.


--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Model (none / 0) (#97)
by ucblockhead on Mon Apr 14, 2003 at 05:44:01 PM EST

Usually when the model is too slow, it is too slow because of IO, in which case, using a "fast" language isn't really an issue, anyway.

Though in both the Windows and Linux worlds, you're probably using system APIs, which are often most readibly available in C or C++. (More of an issue in Windows than Linux, probably.) Even with .NET, there are still many important parts of the system that are only available through a C library.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

which parts of the system? (none / 0) (#99)
by jacob on Mon Apr 14, 2003 at 05:47:06 PM EST

I must admit that I've never needed to bail out to C to get any information I needed. Then again, I don't often write system-analysis-type stuff.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Win32 API stuff (none / 0) (#102)
by ucblockhead on Mon Apr 14, 2003 at 05:57:25 PM EST

In the current project, we've had to use the old C API (through PInvoke) for things like using the system shell routines (to manipulate folders and such), to grab the mouse outside our focus area, to manipulate windows outside our program (checking for multiple instances, basically), to deal with old style resource files and to do various low-level GUI tasks that .NET does not support.

We've had to use more extensive C++ to use certain COM objects, to set watches on the filesystem and to hook into the Autoplay system.

Truth is, .NET isn't there yet...it's great for basic tasks, but not so good for more esoteric functionality. (Java, because it is cross-platform, is much worse for controlling particular OSes in specific ways.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

aha (none / 0) (#104)
by jacob on Mon Apr 14, 2003 at 06:05:43 PM EST

Makes sense that I wouldn't have used that stuff, then. I have used features that poked and prodded a fundamentally OS-specific function exactly once, (not counting OS classes :)): when I used COM to control IE in an application that validated various properties of web sites. I used MysterX for that.

Anyway, why can't OS-specific functionality be tucked away in a C-based FFI module that provided peeks and pokes to some higher-level-language controller? In a large application it might be worth it ... Besides, it'd be 32% more object-oriented to do it that way. :)

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]

High level (none / 0) (#109)
by ucblockhead on Mon Apr 14, 2003 at 07:28:18 PM EST

You certainly can, and in fact that's what we do here with C#. (Though I personally find C# a pain in the ass, mostly because it has no generics.)

In the past, it has mostly boiled down to how much of the code is interacting with the various low-level APIs. For much of the last few years, that's been a pretty high percentage of the program. Often when we've need a "high-level" language, we've found it easier to roll our own special purpose language.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Excuse me, sir (none / 0) (#98)
by trhurler on Mon Apr 14, 2003 at 05:44:54 PM EST

Please take your Schemeing deviousness elsewhere. We do not tolerate your kind in this establishment and your heresies regarding C-like languages will not be forgotten!

Scheme is a great language for teaching people to write mergesort though:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
heh (5.00 / 1) (#100)
by jacob on Mon Apr 14, 2003 at 05:52:01 PM EST

I resent your trivializing the One True Programming Language.

It's also good for teaching people to write binary search trees.

"That evil scheme will never work!" -- Overheard at an intro CS lab

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]

MVC ... cost distribution (none / 0) (#105)
by codemonkey_uk on Mon Apr 14, 2003 at 06:11:42 PM EST

In games the M and the V dominate the CPU costs. Depending on the game it might be more "V" (Quake, for instance) or it might be the "M" (most 'thinking' or simulation games). I'm just throwing this in because every time there is this kind of debate, everyone seems to forget that there is more to "applications" than GUI that sit on top of what is basically a database or spreadsheet of some sort or other.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
games (none / 0) (#106)
by jacob on Mon Apr 14, 2003 at 06:20:10 PM EST

How often do simulation and strategy-type games have models that tax the CPU enough to be worth serious micro-optimization? I'm curious, because I can't really think of any examples where it would matter too much -- if Tetris took 10 times as long to calculated whether a line was full, I probably wouldn't notice one bit, for example.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
Some examples (none / 0) (#107)
by codemonkey_uk on Mon Apr 14, 2003 at 06:31:47 PM EST

Any game that involves lots of military units controlled by an AI requires lots of route finding. Not just route finding for paths actually taken, but route finding to evaluate potential options. Can my squad of 5 men get to this location? Does the route go through a danger zone? Do I need to lay down covering fire?

Any game that has 3d physics. Ray-casting, collision detection. Etc, etc.

At 60fps. On a 300mhz CPU. At the same time as doing skeletal deformation animations for characters with poly-counts in the thousands, with up to 3 bones per vertex and with dynamic lighting on all vertices.

Okay, so that last bit is "View" more than model, but for the most part, the model has to share cpu time with the view, so you get a trade off.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Civilization III (none / 0) (#110)
by ucblockhead on Mon Apr 14, 2003 at 07:34:02 PM EST

A well known game that suffered from severe performance problems in the underlying model. (Though I have no idea how well optimized it is.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Heh (none / 0) (#95)
by trhurler on Mon Apr 14, 2003 at 05:41:37 PM EST

C# and Java speed comparisons routinely report inconclusive results. You are espousing a religion.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
What? (none / 0) (#103)
by ucblockhead on Mon Apr 14, 2003 at 06:01:21 PM EST

What are you talking about? Java and C# are about the same, though C#'s collections suck shit.

But C++ is demonstratably about twice as fast as C# because of the IL.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

I don't want to write it, but in short... (none / 0) (#63)
by trhurler on Mon Apr 14, 2003 at 12:56:18 PM EST

Take what Simon said, and add this: in the real world(ie, not Bell Labs, where certain language "designers" might be working,) we have to use third party code which we often neither have nor can reasonably obtain the right to modify. In fact, we typically have dozens of vendors, and the list changes over time. Without a singly rooted object tree, each of these peoples' libraries will have its own ways of doing a lot of common tasks, and its own object tree(or worse, trees.) Add to this legacy code from within our own organization for which there is no budget beyond basic "keep it working" gruntwork. There will be dozens of pieces of such code. Now, add all that together, and you have probably close to a hundred different object trees or more, and you can't treat objects from one like objects from another ever in any way whatsoever except by writing templates - and your templates have to have little adaptor shims for each of these guys in many cases, because there often isn't even the beginning of a shred of commonality between how these different object trees perform the same functionality.

It would be faster, easier, safer, and less painful to write the same program in assembler.

THAT is why single rooted object heirarchies enforced by the language are an important feature. There are some aspects of OO programming for which having a standard - even a half ass standard - that is universally followed - is FAR better than having a million different but absolutely perfect implementations of the same thing.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bah.... (none / 0) (#65)
by ucblockhead on Mon Apr 14, 2003 at 01:06:08 PM EST

Sounds to me like your problem is that the various pieces of code were written before standard collection classes were available.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
HAHA! (none / 0) (#69)
by trhurler on Mon Apr 14, 2003 at 01:25:11 PM EST

If you think collections are the only reason single rooted object trees are good, then you OBVIOUSLY need to spend time with a real OO language. You have no idea what you're missing out on - and you won't ever know if you stay with C++, because most of it is impossible with templates. Collections(which, by the way, is a useless renaming of "containers" perpetrated by the same sort of people who like C++,:) are just one thing you can do in a decent OO language due to its object structure. Generic means of object serialization, proper integration of dynamic loading features, and much more is all possible - if only your language didn't SUCK! Muhahaha...

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Bah... (none / 0) (#76)
by ucblockhead on Mon Apr 14, 2003 at 02:25:58 PM EST

Sounds to me like you just don't understand them.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Um... (none / 0) (#80)
by trhurler on Mon Apr 14, 2003 at 04:00:42 PM EST

Understand what? Templates? I certainly understand them; what I don't understand is why people substitute a half ass syntax sugar whose semantics differ depending on aspects of the runtime not even defined in the language standard and which provides half the illusion of genericity while still exposing lots of nasty warts when used in interesting ways for a natural, easy, expressive language feature that doesn't require excessive contortions or other nastiness, never has any surprises in store for you, and just works. Well, I do understand - it is because C++ is the only language they've really used for OO stuff, and they don't know any better:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
No (none / 0) (#84)
by ucblockhead on Mon Apr 14, 2003 at 04:18:34 PM EST

Most people use C++ because until '99 or so, it was the only OO language (other than Objective-C) that didn't run like utter shit, and because it's still the only OO language usable for writing programs where quick response is necessary programs for either Windows or Linux.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
No... (none / 0) (#88)
by trhurler on Mon Apr 14, 2003 at 04:43:54 PM EST

Actually, it may be the only POPULAR OO language that didn't run like utter shit, but there have been versions of both COBOL(modified with object extensions courtesy of IBM,) and Smalltalk that have been able to consistently beat C++ performance for at least ten years now.

I've written Unix/Linux code that's OO and wasn't in C++ or Objective C that dealt with two hundred users at a time and never exhibited more delay than the network imposed. It ran in an interpreter on a single machine that was at least ten times slower than what's probably on your desk right now. Granted, it didn't have a GUI, but tightly coupled GUIs are a stupid Microsoftism anyway - and a design error of the greatest possible magnitude.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Crock of shit (none / 0) (#92)
by ucblockhead on Mon Apr 14, 2003 at 05:14:52 PM EST

...and Smalltalk that have been able to consistently beat C++ performance for at least ten years now.
Crock of shit. Utter crock of shit.

Having been in close contact with Smalltalk gurus in 1991 (at IBM even), I can tell you that even they recognized that C++ performed better.

I've written Unix/Linux code that's OO and wasn't in C++ or Objective C that dealt with two hundred users at a time and never exhibited more delay than the network imposed.
See, that's utterly meaningless...you don't say what it did, you don't say what language it was in (Smalltalk, I presume), and you certainly don't compare it to C++ or Objective C in speed, so...
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Bunch of Crap (none / 0) (#101)
by codemonkey_uk on Mon Apr 14, 2003 at 05:54:43 PM EST

If you think that having a rooted hierarchy solves third party library integration issues you are living in cloud cuckoo land. If two classes of object, both derived from root, both implementing the same functionality, each from a different vendor, each with it's own unique interface, your in exactly the same world of suck-ass as if they did not share a root type.

So I ask you again: What problem, exactly, does having a rooted object hierarchy solve?
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Heh (none / 0) (#116)
by trhurler on Tue Apr 15, 2003 at 12:19:43 PM EST

Look, for things like object serialization, if the standard for the language includes it, people will use it. Yes, I agree that if two third party libraries each implement the same unforeseen behavior in different ways, you have a problem - but at LEAST you can easily write a single piece of code that takes either one, determines which specialization of Object it is, and then does the right thing, regardless of the exact runtime semantics(ie, dynamic loading, etc.) In C++, you can't quite meet that bar, and that's just pathetic.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
That problem has been solved. (none / 0) (#117)
by ucblockhead on Tue Apr 15, 2003 at 12:41:19 PM EST

Just use boost/any.

void DoStuff(const boost::any & Thing)
{
    if(Thing.type() == typeid(Foo*) ) {
        Foo*fp = any_cast<Foo*>(Thing);
    }
    else if(Thing.type() == typeid(Bar*) ) {
        Bar*fp = any_cast<Bar*>(Thing);
    }
}

Foo* fp = new Foo;
DoStuff(boost::any(fp));

-----------------------
This is k5. We're all tools - duxup
[ Parent ]

So then (none / 0) (#119)
by trhurler on Tue Apr 15, 2003 at 01:02:21 PM EST

What you're saying is that your language sucks less if you bolt on some crap from somewhere else, which of course there will be more than one different version of. So now I have a library that uses other libraries and uses this "any", but then I have another library that uses another implementation of the same idea, and you think this is a good idea. Ok. I suppose for sufficiently lax definitions of "good" that roughly equate to "will compile and run," that's "good."

Why, though, couldn't the language have been done right in the first place? Oh, right, because its chief designers had zero experience as language designers. My mistake.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
boost (none / 0) (#120)
by ucblockhead on Tue Apr 15, 2003 at 02:22:41 PM EST

The boost guys are close to the standards guys...parts of boost are likely to make it into the language at some part.

Anyway, with I think is that I'll worry more about what gets the job done than ideology.

What you really mean is "Why couldn't the language designers of language X do it like I wanted and not like they wanted". Sorry, but C++ meets the stated design goals. If you don't like those goals, go use Java.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#121)
by trhurler on Tue Apr 15, 2003 at 02:36:04 PM EST

The stated design goals are inappropriate for most every software project, though. Too bad, eh?

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
True (none / 0) (#122)
by ucblockhead on Tue Apr 15, 2003 at 02:41:18 PM EST

Unfortunately, every other language available sucks even worse. (Mostly because of poor library support, but heh...)

Delphi is probably better...I should really use it. Java and C# just aren't there yet. (Getting close, but neither has generics and both have substandard UI support.) C is silly for anything other than an environment where it's the only thing available.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Hmm (none / 0) (#123)
by trhurler on Tue Apr 15, 2003 at 02:51:12 PM EST

Well, C's library support certainly can't be questioned, and there are extant systems of millions of lines of code that prove that C can be written in a maintainable, extensible fashion. I think the problem is that you've bitten so hard on the OO language support that you just can't imagine how things got done before, when in fact it isn't bad at all. Were there a GOOD OO language to choose, I would agree wholeheartedly that one should use it where possible, but let's be honest: there isn't one that's both good and suitable for regular work. Contorting yourself and your code day in and day out just to use features that don't save you as much work as the contortions cause may make you feel modern and sophisticated and all that, but it doesn't actually improve your situation any.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
C (none / 0) (#124)
by ucblockhead on Tue Apr 15, 2003 at 03:13:28 PM EST

There's one reason why it is silly to write anything in C: You can use C++ as a non-OO language, and write better, easier to maintain code than you could in C. With C++, you can write non-OO code that has strings, built-in collections, references, templates and a whole slew of other modern language features.

I think the problem is that you've bitten so hard on the OO language support that you just can't imagine how things got done before...
Bah! I've got ten years of C programming experience (not "have known C for ten years"...I've known it for twenty...that's ten solid years writing C professionally) and have written two books on the subject, so yeah, I think I can imagine how things got done before.

What I can't understand is the belief that not having to handcode a dynamic array is a "contortion".
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Hmm (none / 0) (#125)
by trhurler on Tue Apr 15, 2003 at 03:38:27 PM EST

Who exactly is using C++ as a better C, aside from people still learning? Granted, that is possibly the only way in which using it is ever a good idea, but in any case, I don't think I'd use STL, std::whatever, or templates, because they all suck ass VERY badly. I've implemented more featureful and robust arrangements for toy systems for classwork or my own amusement. Just fucking pathetic, really.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
No one (none / 0) (#126)
by ucblockhead on Tue Apr 15, 2003 at 03:46:41 PM EST

Because most of us use C++ for OO, because we get work done that way.

But if one didn't like C++'s way of doing OO, that'd be much smarter than going back to C.

Using C because you don't like the way C++,Java, etc. do OO is like using a hammer because you don't like the way nailguns work.

I'm curious to here why you think the STL "sucks ass". Sure, it can be a bit arcane doing complex stuff, but doing vector<string> is far easier than doing it yourself in C.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#127)
by trhurler on Tue Apr 15, 2003 at 05:11:42 PM EST

If C strings bother you, then this whole argument is probably pointless. Why does STL suck ass? Because the ways in which it abuses C++ to get the job done result in odd behavior here and there that just isn't something anyone ought to have to try to understand. Because it lacks features found in container libraries from, say, thirty years ago. Because by the time you understand all its idiosyncrasies, you could have written a small operating system using C, and yet you have done little or no productive WORK yet. Because frankly the tools for accomplishing the same basic goals in C that you're after in C++(dynamically sized arrays and so on,) really aren't that hard to use. (Your example is telling: you may prefer the ease of using a nailgun, but if you can't use a hammer well enough to get the job done properly, you have no business being paid to do that job.)

Fundamentally, the problem is this: C++ was an attempt to produce a modern OO C. It failed in that regard, because virtually every feature in the language is screwed up somehow. Using it merely prolongs the agony of waiting for someone to do something better. Let it die, and something will come to take its place.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
STL (none / 0) (#128)
by ucblockhead on Tue Apr 15, 2003 at 06:06:22 PM EST

What features? You're not talking about the stuff in <algorithms> are you?

C strings only bother me to the extent that std::string is easier to use. I also understand doing string handling in assembly, but I've got no interesting in doing so.

No, hand-coded dynamically sized arrays aren't that "hard". But they also aren't as easy (or as maintainable) as vector. Sure, I could do:

ArrSize = 10;
Foo* Arr = (Foo*)malloc(ArrSize*sizeof(foo));
int i;
for(i=0;i>Elems;i++) {
    if( i >= ArrSize ) {
        ArrSize*=2;
        Foo* Arr = (Foo*)realloc(Arr,ArrSize*sizeof(foo));
        if( !Arr) exit(1);
    }
    memcpy(Arr[i], FooSet[i], sizeof(Foo));
}

But why, for fuck sake, would I want to reinvent the wheel like that, when I could just do:

vector<Foo*> Arr;
for(int i=0;i>Elems;i++)
    Arr.push_back(FooSet[i]);

It's 2003, why in God's name would anyone want recode shit that's been done a billion times!?

Sure, I can use a fucking hammer. I was coding C interrupt routines when you were in grammer school. I spent about a quarter of my time between 1988 and 1999 coding for a 128k Z80 based box that used bank switching, and for which the only C compiler available used only the old K&R style decls and didn't implement most of the standard libraries, so don't play "I'm mr. 1337 reimplementer" with me. I had to implement my own fucking memory management, not because of some lame-ass "I'm too cool to use modern tools" crap, but because I had no choice. There's no fucking way I'm going to waste my time reimplementing things when perfectly good tools exist that already do it. I'm sure your old-skool act works well with the new kids who don't know any better, but it isn't going to fly with those of us who were actually coding in those days. When I see someone coding a dynamic array by hand in 2003, I think of someone who is too fucking lame to use the perfectly good implementations that already exist.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Um... (none / 0) (#129)
by trhurler on Tue Apr 15, 2003 at 08:30:44 PM EST

I was programming at the ripe old age of four or five. I doubt you've got me by much. In any case, I also don't care. The point is not to have some lame pissing contest. The point is that your example manages to shave about five lines of code. That's nice. Is it worth using a language in which I guarantee you I can find features and side effects that you aren't aware of versus using one that you can actually understand completely? Five lines of code of this length might take you thirty seconds to write, and if you're even marginally clever, you can avoid typing them over and over again.

This is what I hate about C++ OO advocates - their examples of "the right way" are always at most trivially simpler than doing things the way I do them, and inevitably they think this is just great despite the glaring faults of the language. C++ is mostly just harder to read, write, and modify(and no, it isn't because I'm some ignorant punk. It is because the language is huge, unwieldy, and obtuse. If you tried, you could stump its CREATORS with a piece of code. That ought to tell you something. Its needless complexity and nastiness is exceeded in my experience only by languages DESIGNED to be difficult.)

In short, the difficulty of typing a few lines compared to the difficulty of the additional syntactic and semantic complexity is trivial. Sure, there are textbook examples of saving dozens or hundreds of lines of code; they always use a braindead implementation in C and a state of the art "we just invented this using unintended side effects of these language constructs" implementation in C++, and while the former is eminently comprehensible, the latter always has one neat looking part and a bunch of crap that closely resembles line noise and does things that rely on obscure side effects, name resolution, operator precedences, and so on.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
funny ... (none / 0) (#130)
by jacob on Tue Apr 15, 2003 at 09:14:01 PM EST

The difference between the functional-programming and the imperative worlds, I guess. When you saw that code sample, your reaction was, "So what, it's only a few more lines." Mine was, "it takes you two lines to do that?" :)

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]
two lines (none / 0) (#132)
by ucblockhead on Wed Apr 16, 2003 at 12:34:31 AM EST

If FooSet were another container, you could do it in one line (apart from the declaration):

Arr.insert(Arr.end(),FooSet.begin(),FooSet.end());

Though one of my pet peeves about the STL is that they refuse to deal with containers apart from iterators. If I had my way, any method that took a begin and end iterator would be overloaded to take a container. I also think there ought to be a version of insert that defaulted to the end, since that is such a common thing to do.

I've actually gone ahead and done that for some of the standard algorithms like accumulate and transform.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

hm (none / 0) (#137)
by jacob on Wed Apr 16, 2003 at 10:00:56 AM EST

I think this is a basic paradigm problem, though of course this is just wild speculation. At root, no matter how much wacky stuff you tack on to it, the basic operations in C++ are still 1) moving memory around and 2) jumping, and when people design libraries that's the mindset they have.

In functional languages, the basic operations aren't about memory or jumping: they're generally about creating abstractions (i.e., functions) and applying them to arguments1. I think fundamentally that's why in C++ it takes a giant language and three metric tons of intermediate-to-expert-level user library to get to the point where you can say "give me a new container that's just like this one only with some operation applied to all the elements" in one simple phrase, whereas in ML or Scheme or Haskell you'd do it as an example in a beginner class.

In ML:


fun map f []      = []
  | map f (x::xs) = (f x)::(map f xs);

Fully type-checked, generic over lists of any type of element, no possibility of segmentation faults, and so on. Can you do that in 2 lines using no library support in C++?

What's more, while map is illustrative in a point-by-point comparison, I find that advanced functional programmers use it less and less in favor of things like foldl and foldr, which rolls all the list-processing into one ball.

Anyway, I think this difference is one of the big reasons functional programmers can't communicate very effectively with people from imperative traditions.

Not sure exactly why your post inspired me to write this, but there you go ... :)

1This is a lie, of course.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]

Heh (none / 0) (#138)
by trhurler on Wed Apr 16, 2003 at 12:21:34 PM EST

There are imperative languages that can do what you're talking about. They're typically burdened with big runtimes and don't run as fast as the really fast imperative languages, which also happens to be true of most or all functional languages. I think the difference is not paradigm, but rather this heavy runtime. When you think in terms of pure abstractions, you HAVE to have a big runtime and possibly even an interpreter to get the job done, so doing all this neat stuff comes naturally, but that doesn't mean that you have to have the abstractions all the way through the language just to have the features a heavy runtime can provide.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Functional aspects (none / 0) (#145)
by ucblockhead on Wed Apr 16, 2003 at 01:27:12 PM EST

Well, you are right, whatever functional aspects exist in C++ were bolted on top and are mostly just convenience features.

It depends on what you mean by "library support". I presume you mean "external library support", because without the standard libraries, you aren't doing anything.

But yes, with the STL, you can do what you want using transform and list. Of course, "no possibility of seg faults" is an interesting question...assuming the STL implementation has no bugs, you won't get any there, but as this is C++, the programmer could certainly introduce such a problem in the code for the operation itself. But that's a fundamental result of allowing pointers to be modified directly. You can't change that without changing C++ into something entirely different.1

Still, I don't want to oversell it. The current implementation is a bit crippled by the hideous bind library, so you really need boost::bind to get the most out of it. (The supplied bind library is a pain in the but to get to work with member functions.)

It's never going to be where any decent functional language is, and it is currently just barely usable. But it is improving.

So in answer to your question, you can do:

list<Bar> Barlist;
transform(Foolist.begin(),Foolist.end(),Barlist.end(),FooToBar());

Of course, this is misleadingly simple. There's a lot of behind the scenes stuff needed to get this to work. For instance, BarToFoo is not a function but a functor. With standard C++, you've mostly got to roll it yourself, though boost::bind helps you create them on the fly.

1Under modern OSes, the whole idea of possibilities of seg-faulting is, I think, a red herring. In a language like Java, you can get an unhandled exception. In Windows, a seg-fault is, itself, an exception. You can catch it with a catch. So in my mind, this is a null issue. It's no different from Java. Both languages can generate confusing (to the user) messages and crash. The real issue is that in C/C++, overrun buffers, or write into the "wrong" areas of memory without segfaulting. That is the big problem.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Just FYI (none / 0) (#154)
by trhurler on Wed Apr 16, 2003 at 07:50:48 PM EST

You can catch segfaults on UNIX systems too(see signal(2),) but your process is likely to be unrecoverable anyway, as you have likely corrupted memory it is using in ways your recovery code cannot possibly predict.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Windows (none / 0) (#156)
by ucblockhead on Wed Apr 16, 2003 at 09:37:50 PM EST

In Windows, you can safely catch the exception and move on. (Of course, if you are doing nasty things that segfault, you may well be writing to the wrong place in ways that don't segfault...but it least it works with attempts to use NULL pointers.)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Sure (none / 0) (#158)
by trhurler on Thu Apr 17, 2003 at 12:47:28 PM EST

If all you did was try to dereference a NULL and you haven't yet done anything truly stupid, you can recover that on Unix systems too, but what a crappy way to program:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Yeah... (none / 0) (#160)
by ucblockhead on Thu Apr 17, 2003 at 01:01:00 PM EST

I miss the good old days, where writing to a NULL pointer hung the machine.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
What a funny guy (none / 0) (#161)
by trhurler on Thu Apr 17, 2003 at 01:51:43 PM EST

My point is that you're better off if you just let your program die when this happens, because until you figure out what's going on(at which point you're going to fix it anyway, and band-aids aren't needed,) you don't know whether the fault was a simple NULL dereference or whether it was caused by you tromping all over your process image, and if the latter, the program isn't going to work anyway, and could potentially do damage to a dataset or whatever else it might touch - so why not just let it die?

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Sorry (none / 0) (#162)
by ucblockhead on Thu Apr 17, 2003 at 02:07:24 PM EST

That wasn't sarcasm...I was serious. :)
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Well, gee (none / 0) (#131)
by ucblockhead on Wed Apr 16, 2003 at 12:24:09 AM EST

Well, I don't find it hard to code...so is it that I'm some sort of genius, or is it perhaps that it has more to do with your own refusal to leave your safe little C world? If it's the former, well, there must be a lot of geniuses around.

If you seriously think that vector code is harder to read for the average programmer than the hand-rolled dynamic array, well, I think you've been looking at too much C code.

You know, you keep saying crap about how "The STL doesn't do this" and "I can find unintended side effects", but you know, I've noticed that you never actually do. Fine, smart guy, what's the unintended side effects of vector?

Oh, and how is my C code "brain-dead"? Do you have a magic way of writing a simpler, more straightforward dynamic array?

Face it: if you are working in a language without collections, you are reinventing the wheel, over and over. Good for padding the timesheet, perhaps, but not good for getting work done.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#140)
by trhurler on Wed Apr 16, 2003 at 12:32:47 PM EST

If by "hard" you mean that I actually can't do it, then no, it isn't hard. I can write Intercal, too. Does that mean I should go use it for all my projects?

I'm uninterested in going home(I'm at work, and I don't keep C++ books here, because we don't use it,) and reading a bunch of books I haven't opened in at least three years to answer questions regarding the faults of a language that any sane person already knows has faults.

Your C code isn't brain dead, but using it the way you use it might be. Why would you write that out every time you want an array, instead of producing a small interface that will produce the array for you, resize it, and so on? And once you do this, why would you care anymore that you had to do it once? Is it really such a chore to do something like "new_list(elementsize, listsize);" or "size_list(elementsize, newsize);"? Of course it isn't. Granted, you have to pass in one extra argument that a fully typechecked version can do for itself, but if eliminating that trivially easy requirement is worth immense complexity to you, then you don't understand large systems very well. The number one, most important thing ever in programming is keeping things simple.

I don't reinvent the wheel any more often than necessary. If you used to do that, this is your mistake - not mine.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Dynamic arrays (none / 0) (#143)
by ucblockhead on Wed Apr 16, 2003 at 01:03:09 PM EST

So you are saying I should just write my own proprietary dynamic array library? Well, sure... But it'd be a lot smarter to use someone else's stardardized, debug version.

I love your "Oh, there are all these faults, but I don't have the time to tell you what they are!" Bah! You were talking out of your ass and got called on it.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#144)
by trhurler on Wed Apr 16, 2003 at 01:25:48 PM EST

Yeah, since I'm not the world's greatest expert on the obscure corners of a langauge whose description is larger than a big city phone book, I'm lying when I say there are problems. That's it. It's a BIG LIE!

As for writing your own library, the whole thing is about thirty lines of code. I suspect you could do it right pretty quickly. But, if you are in fact so inept that you just can't cut the mustard, let me know and I'll send you one, debugged and all.

I realize that it isn't thirty lines of code in C++. That's part of my point.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Standards (none / 0) (#148)
by ucblockhead on Wed Apr 16, 2003 at 01:40:36 PM EST

Yeah, since I'm not the world's greatest expert on the obscure corners of a langauge whose description is larger than a big city phone book, I'm lying when I say there are problems. That's it. It's a BIG LIE!

Well, you tell me that vector has unintended side effects, and then won't tell me what they are. Sorry, bud, but if you can't tell me what the problems are, I will just assume you are talking out of your ass.

You know, a while back you thought it sucked that people might create propropietary object trees that you have to tie together, but suddenly now you think it's fine and dandy to create proprietary collection code.

But no, I don't want your code. I'd rather use code that's been tested by multiple compiler vendors and that has been successfully used by millions of users.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Heh (none / 0) (#149)
by trhurler on Wed Apr 16, 2003 at 01:48:12 PM EST

You think all those compiler vendors are using the same implementation of the STL? Boy oh boy, are you gullible.

As for "proprietary" collection code, since mine contains and cares about no type information whatsoever, it is usable with anyone's stuff. I also can easily produce versions for elements whose type is carried with them, although those are a bit less agnostic about the data you store, and so on. In any case, C is not the ideal language - and I never except jokingly implied otherwise. It IS far and away a more practical language for creating reliable software than C++ ever was and ever will be, but believe me you, I'm watching, waiting, and hoping for something better. And maybe looking for a chance to help out with it, but I doubt I'll get that chance.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
No... (none / 0) (#150)
by ucblockhead on Wed Apr 16, 2003 at 02:40:06 PM EST

But I know that the three most common versions (The one that ships with Visual Studio, the one that ships with G++, and the STLPort implementation) are very widely used.

But whatever. I know for a fact that C++ improves my productivity.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

re: what I hate about C++ OO advocates (none / 0) (#136)
by codemonkey_uk on Wed Apr 16, 2003 at 05:18:54 AM EST

It's interesting that you said that. As the author of the article, I'm pretty sure this isn't C++ advocacy. I'm also pretty sure that most of the comments in this article that could be read as C++ advocacy are actually just people responding to your utterly pointless, and mostly unfounded "criticisms" of C++.

If you expect to be taken seriously you need to target your attack more tightly. You think C++ is "too complex", well then show me a multiparadigm programming language that does everything C++ does, but better.

Or shall we just sit here and point out all the problems that C++ inherited from C? C isn't exactly the wonder-language you seem to think it is. If I can draw your attention to the Coding Standards section of the article, we will see that C has 267 separate instances of "unspecified, undefined, and implementation defined behaviour". Does just saying that help anyone? No. Do these "holes" in the C language mean that everyone using C should switch to Java (which has no 'undefined' or 'implementation defined' behaviour, just implicitly unspecified behaviour that hardly anyone accepts exists)? No. It might be taken as an argument that some people working in some problem domains might benefit from looking at Java as an alternative implementation language - but for this argument to be of any value then it would need to go into which domains, why, and what the drawbacks of the switch might be.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Hmm... (none / 0) (#139)
by trhurler on Wed Apr 16, 2003 at 12:26:12 PM EST

First of all, I certainly have never advocated "multiparadigm" languages. Neither did Bjarne until C++ became too complicated and bloated for any sensible use, at which time(around the second printing of his book, maybe the third,) all of a sudden C++ went from being "C with objects" to a "multiparadigm" programming language(I suspect some C++ user invented this use of these words,) and was this magical new thing that it hadn't been the dady before! I want a language that is small, general in applicability, but very specific in methods. For instance, C.

Second, I never advocated that any language should inherit the baggage of any other - even a good one. C, as you say, is not a perfect language. However, within the confines of C, C's shortcomings really aren't a big deal. The problem is when you inherit them into a language where they CAN matter more - such as C++. The mistake was Bjarne's, and the result is C++. Don't blame C. (Yes, I know, he claims it was necessary. This is because he apparently doesn't understand that you can link object files produced in different languages. Given this simple fact, there is NO reason why C++ should EVER have been backwards compatible with C, except purely by accident, and certainly no reason to preserve that accident if it caused problems - which it DID.)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Multiparadigm languages (none / 0) (#142)
by ucblockhead on Wed Apr 16, 2003 at 01:00:15 PM EST

Speaking as someone who started programming C++ with cfront back in 1985, you are just plain wrong here. It was sold as a multiparadigm language from the get-go.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
Heh (none / 0) (#146)
by trhurler on Wed Apr 16, 2003 at 01:29:08 PM EST

It was sold as a language that could be used as "a better C" or as an OO langauge in its own right, but I don't recall hearing "multiparadigm" until much later, and then it was being used as a sort of shield against claims that C++ is a lousy OO language(which it is.) "Oh, well then you can always use it in other ways!" Yes, and I can use bad cheese as a doorstop too, but I'd rather just buy better goddamned cheese.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
The "word" (none / 0) (#147)
by ucblockhead on Wed Apr 16, 2003 at 01:35:57 PM EST

Well yes, I don't specifically recall when the term "multiparadigm" showed up. I do specifically remember my prof being excited about this "new extension to C" that he'd just gotten from AT&T that allowed you to do object oriented programming "in C". I remember specific talk about how you could now use "one langauge" for both object oriented programming and structured programming. As opposed to Smalltalk, which forced everything to be object oriented (not my words, but the line the prof and the grad students were feeding us poor students.)

That's what "multiparadigm" means. This was 1985. It was the first release of C++ outside of AT&T.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

multiparadigm (none / 0) (#151)
by codemonkey_uk on Wed Apr 16, 2003 at 05:20:02 PM EST

First of all, I certainly have never advocated "multiparadigm" languages
But I can assume that you do accept that some programming "paradigms" are "better" at solving certain classes of problem, and other "paradigms" are "better" at solving other classes of problem. Right?

And you do accept that large systems can contain a wide selection of problem classes, don't you?

So (and I'm not arguing with the point here, just trying to establish some kind of common understanding) what you would advocate instead is that each problem is handled in the language that is most suited to solving that class of problem, and the system as a whole is "integrated". Somehow.

Now your going to have to pardon my ignorance here - I do very little in the way of multi-language integration - but does this mean you are limited to languages that use the C linkage model for static linking, but can also use, (performance restrictions aside) say, COM, or CORBA, or some kind of network protocol for dynamic linking. But doesn't this mostly limit you to C (structured programming) interfaces? Is this acceptable? What about integrating, say, a generic (compile time bound) sub system with a functional subsystem? Is doing this via a structured language interface cause design problems? And wouldn't this sum of languages and binding/linking models end up just as complex and hard to learn in total as just using C++?

To address your second point - can you clarify for the expectant masses how C's accepted shortcomings suddenly become insurmountable, unacceptable, problems within the context of C++. I'm not denying it - I just think it's about time you started putting your money where your moth is and coming up with some concrete examples, rather than the same old tired and empty rhetoric.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

COM (none / 0) (#152)
by ucblockhead on Wed Apr 16, 2003 at 05:47:06 PM EST

Technically speaking, you can use COM with C, but since COM classes are basically souped up C++ classes, you do so by manually creating vtables. Doable, and Microsoft will tell you how so that they can claim that COM works with C, but no sane person would ever do it.

I don't know enough about Corba, but I suspect that it would be even harder, from what I've seen.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

CORBA (none / 0) (#153)
by trhurler on Wed Apr 16, 2003 at 07:47:53 PM EST

There are C bindings, and as you suspect, they're ugly but functional. The way you do CORBA in C(assuming you can't use any C++ at all,) is you write all the code that touches CORBA in one small part of the program, and then you write code that does what you really want done elsewhere:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Well... (none / 0) (#155)
by trhurler on Wed Apr 16, 2003 at 07:50:51 PM EST

Actually, I must say, for small programs, "structured programming" is quite good enough, and for larger programs, it still is, although you can use OO to good effect if you have the appropriate tools to do so. Beyond that, I really think the rest is academic crap. So, if I had a really good OO language, I'd use it for large projects, but I'd still write small stuff in C, perl, or something similar, because well, for small programs, OO just adds to the typing effort for no gain. I cannot think of any case where I would be in possession of said good OO language(which doesn't exist, sadly,) and say to myself, "boy, I wish this had support for embedding a bunch of functions not associated with any object" or some similar thing.

C shortcomings: The first is the undefined and/or implementation defined behaviors in C; some of these are necessary(maybe even in C++,) but others really aren't, and they cause more trouble for C++ than they do C simply because with the richer syntax and people trying to do a wider variety of things with that syntax, you encounter them more often and they caused more odd design decisions in various parts of C++ than they did in C(where, actually, they caused very few, and those were mainly in the revisions of the standard.) It seems to be that undefined behavior is a problem when you try to revise or expand something, and it just so happens that the biggest revision of C is C++, so it suffers the most. The second thing is C's preference for a minimum of keywords. In C, "static" is only mildly confusing, but in C++, which already is big and hard to know all of, it is worse, and then Bjarne made it even worse(not a C failing, but relevant to the discussion anyway,) by adding even more meanings for the damned word. Then finally, in many places Bjarne kept C syntax that was ugly as hell and provided no alternative, and there's no good reason. He "fixed" struct by allowing for two syntaxes(the old and the new,) but he kept the C function pointer syntax even though many superior examples can be dreamt up - backwards compatibility. There are a few other examples, but that should give the idea.

Give me a truly good OO-ish C-like language, and I might never need or want another language. But, that doesn't exist, no matter who says what.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
So basically (none / 0) (#157)
by codemonkey_uk on Thu Apr 17, 2003 at 05:24:37 AM EST

You agree with Andrew Koenig's conclusion.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Almost (5.00 / 1) (#159)
by trhurler on Thu Apr 17, 2003 at 12:51:43 PM EST

I agree with pretty much everything he said except one part. That part is this: C++ cannot be fixed. There was one chance to get the big things "right," and it was missed, and now you don't just have to contend with backwards compatibility with C, but also with C++, and that basically means the language is hopeless. No standard committee would ever change a language so drastically as you'd have to change C++ to make it right.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Patterns ... (5.00 / 2) (#37)
by Simon Kinahan on Sat Apr 12, 2003 at 08:30:43 AM EST

... go a bit beyond a learning tool. They've created a language that can  be used to describe common .. umm ... patterns of design. It's easier to say "singleton" than "class that only has one instance", and much easier to say "composite" than "collection of objects of some type that has that type itself". Enough people know the language that it's portable between jobs. It's basically the same benefit UML has over random lines-and-blobs diagrams.

I've also found them useful as a rhetorical tool. It can be hard for those of us who can actually design software to convince people who believe in "whatever works" (even if they can't explain how) that their designs suck, especially when the "technical" "leadership" suffer from the same cognitice defficiency. Patterns provide a constructive approach to these problems: "look, this book contains a great way of solving your problem", is more likely to motivate people to fix their code than "here is a way in which I would have done it better", which just sounds egotistical. Admittedly this is just the converse of their being a good learning tool (which I don't dispute).

Simon

If you disagree, post, don't moderate
[ Parent ]

language (none / 0) (#55)
by gdanjo on Mon Apr 14, 2003 at 03:00:48 AM EST

It's easier to say "singleton" than "class that only has one instance" [...]
What about "static class"?

[...] and much easier to say "composite" than "collection of objects of some type that has that type itself". [...]
What about "object"?

Wasn't OO supposed to put an abstraction layer on top of code/data to avoid having to know its internal structure? Why are we now un-abstracting it?

We'll soon have a "patterns in a pattern language" reference book to further narrow down what we mean when we say "dual singleton" or "unified composite."

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
-ToT
[ Parent ]

you're missing the point (5.00 / 1) (#56)
by jacob on Mon Apr 14, 2003 at 09:30:49 AM EST

First of all, neither of your alternatives capture the essence of what's being communicated.

Second: while it's true that object-oriented design entails what you could call "hiding the implementation," that's not to be taken literally to mean that programmers should hide their implementations from other programmers. :) Patterns are about developers communicating with each other and learning general ways successful object-oriented programs have been designed. That's useful.

--
"it's not rocket science" right right insofar as rocket science is boring

--Iced_Up

[ Parent ]

the point (1.00 / 2) (#111)
by gdanjo on Mon Apr 14, 2003 at 08:17:44 PM EST

First of all, neither of your alternatives capture the essence of what's being communicated.
What about both alternatives together?

Second: while it's true that object-oriented design entails what you could call "hiding the implementation," that's not to be taken literally to mean that programmers should hide their implementations from other programmers. :)
Why not? Because we only hide things from stupid people? I know a lot of stupid programmers.

Patterns are about developers communicating with each other and learning general ways successful object-oriented programs have been designed. That's useful.
Patterns are a new language to keep the users (or lesser programmers) from talking our secret code.

We're the new Stone Cutters.

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
-ToT
[ Parent ]

Give me a break (none / 0) (#133)
by MrSnrub on Wed Apr 16, 2003 at 04:28:11 AM EST

Patterns are a new language to keep the users (or lesser programmers) from talking our secret code.

Any profession will develop it's own jargon, simply because it is more efficient for the members of that profession to use a standard term rather than repeatedly giving a vague description ("some class with one thing"), or using terms that don't precisely express the desired meaning ("static class!").

Can you honestly imagine any physician (except Dr. Nick) walking around talking about "that long bone in the leg", or "that bad thing that happens when blood doesn't clot properly"?

[ Parent ]

Get a clue (4.00 / 1) (#57)
by Simon Kinahan on Mon Apr 14, 2003 at 10:18:42 AM EST

<P><I>What about "static class"?</I>

<P>What does that mean ? If you mean "class that has only static data and methods", that doesn't mean the same as "class that only has one instance", since the latter can be polymorphic, and this is an important aspect of what Singletons do.

<P><I>What about "object"?</I>

<P>Obviously not. Do you even have the faintest clue what you're talking about ? Composites are a commonly recurring theme in designs (hence "design pattern"). Non-terminal nodes in abstract syntax trees are composites. Container elements in GUIs are composites. Look it up.

<P><I>Wasn't OO supposed to put an abstraction layer on top of code/data to avoid having to know its internal structure? Why are we now un-abstracting it?</I>

<P>We're not unabstracting anything. Design patterns describe patterns in the public behaviour of classes. How they're implemented is not interesting, at this level. Its not necessary to fetishistically hide every element of a class's state in order for it to be abstract.

Simon

If you disagree, post, don't moderate
[ Parent ]

beh (1.00 / 2) (#112)
by gdanjo on Mon Apr 14, 2003 at 08:31:45 PM EST

What does that mean ? If you mean "class that has only static data and methods", that doesn't mean the same as "class that only has one instance", since the latter can be polymorphic, and this is an important aspect of what Singletons do.
Ah, polymorphic singletons. Let's make a building out of lego just in case we want to re-arrange it some day.

In my language, a static class means just that. Polymorphing is for pussies.

Obviously not. Do you even have the faintest clue what you're talking about ? Composites are a commonly recurring theme in designs (hence "design pattern").
What kind of themes? I see numbers as a commonly recurring theme in all programs. Maybe we should call them singletons.

Non-terminal nodes in abstract syntax trees are composites. Container elements in GUIs are composites. Look it up.
So a composite is everything but a non terminal node?

Does that also apply to buttons? That's a composite of text plus square. Or is that a terminal node since it's not a container element?

Dan ...

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
-ToT
[ Parent ]

Sort of... (none / 0) (#59)
by trhurler on Mon Apr 14, 2003 at 12:41:55 PM EST

But really, one could easily argue that the more common patterns should be explicit syntax in a good OO language, and that it is only the primitive state of those languages that makes them necessary - and the less common ones are things you learn, the same way you'd learn about trees, hash tables, and so on - but typically are ways of structuring code instead of data. I can see your point about convincing stupid people, but I'd rather spend my time looking for a job further insulated from stupid people than trying to teach a pig to sing.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Patterns (none / 0) (#62)
by ucblockhead on Mon Apr 14, 2003 at 12:52:13 PM EST

You know that the Patterns "Gang of Four" were all Smalltalk guys, right?
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
So what? (none / 0) (#70)
by trhurler on Mon Apr 14, 2003 at 01:25:55 PM EST

I doubt any of them would claim that OO language evolution is over, so what about that is meaningful relative to my claim?:)

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Oh, and ... (5.00 / 2) (#38)
by Simon Kinahan on Sat Apr 12, 2003 at 08:31:39 AM EST

... the reason patterns have no place in academia is that academics have no fucking clue about software engineering. They think they've superior to code that actually does useful things.

Simon

If you disagree, post, don't moderate
[ Parent ]
Heh (none / 0) (#58)
by trhurler on Mon Apr 14, 2003 at 12:38:03 PM EST

Software engineering is a non-discipline, but it certainly is taught in universities(including some of the very best universities. CMU for instance.) Also, the guys who wrote the original book aren't exactly strangers to academia, and did NOT introduce patterns as an engineering methodology.

When I say "software engineering is a non-discipline," you probably won't understand what I mean. Go ask a real engineer how his field works, and then you'll understand. No software has ever been "engineered," and none will be in the forseeable future. Properly engineered products generally have zero faults that were humanly correctable within their design specifications and allowances for wear and tear with usage. There has never been a useful program for which that can be said. Ever. Period. Don't try to bullshit. It hasn't happened, and you know it. If you tried to start your car and the gas tank blew up, then you'd have a point. We are still firmly in the realm of software as a craft, and we will be for a long time, despite the best efforts of a lot of bright people.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
"Software engineering" (5.00 / 1) (#115)
by Simon Kinahan on Tue Apr 15, 2003 at 12:16:42 PM EST

I agree it is a non-discipline. We are, as you say, at craft level and will be for a long time. There is, however, a body of established lore, packed though it is with superstition, supposition and downright error and inconsistency, which is the best we have right now. This is what most people understand by "software engineering".

The GoF certainly didn't introduce patterns as a Methodology (god forbid). They did do it as a contribution to "software engineering". A quick read of the preface will show that they were concerned with the issues that normally fall under that name.

Academics normally ignore "software engineering" precisely because it is in no fit state for the kind of tidy, minutiae-obsessed study from which run-of-the-mill academics build careers. Those who do pay it attention either have to get their hands dirty and write popular books and websites (as the GoF did), or live in a fantasy world of "Methodology".

Simon

If you disagree, post, don't moderate
[ Parent ]

C++ (none / 0) (#33)
by gdanjo on Fri Apr 11, 2003 at 10:17:20 PM EST

C++ is like a marriage. If you don't act like she wants you to, you'll get butt-whalloped.

I was married to C++ once. But she was too demanding, so I left her :)

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
-ToT
[ Parent ]

C++ is good (5.00 / 5) (#32)
by gdanjo on Fri Apr 11, 2003 at 09:25:35 PM EST

I love C++ because it gives me job security. I know that as long as Perl, VB, sh, and C++ are around, I will have a job - guaranteed.

C++ is a victim of it's own success - like everyhing, we just keep trying to make it more and more beautiful and it just becomes more and more of an ugly mutant.

I'm glad we don't have the same zeal for contortion with physical objects as we do for computers. We'd have a mousetrap that's connected to your fridge door's internet P2P node that transmits pictures of it's conquests on it's own weblog. With templates.

Dan ...
"Death - oh! fair and `guiling copesmate Death!
Be not a malais'd beggar; claim this bloody jester!"
-ToT
[ Parent ]

Wow. A conference devoted to Lisp. (n/t) (4.83 / 6) (#23)
by jjayson on Fri Apr 11, 2003 at 06:01:28 PM EST


_______
Smile =)
* bt krav magas kitten THE FUCK UP
<bt> Eat Kung Jew, bitch.

LOL (none / 0) (#24)
by codemonkey_uk on Fri Apr 11, 2003 at 06:11:22 PM EST

Indeed there has been a trend towards functional style programming in C++ recently. And to think, I didn't even include a write up of Jaakko Järvi's talk on The Boost Lambda Library! :)
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
(o/t) Boot Lambda (5.00 / 1) (#25)
by jjayson on Fri Apr 11, 2003 at 06:14:37 PM EST

I've tried to use it, but I always hit little problems and it being template based, the offending error messages make it virtually impossible to fix. I keep thinking that you can use a lambda just like any other function. Not quite.... I wish a lambda construct would just be put in the language and be done with it. Template hackery can ony get you so far (and shouldn't even be used to take you that far).
_______
Smile =)
* bt krav magas kitten THE FUCK UP
<bt> Eat Kung Jew, bitch.

[ Parent ]
Maybe (none / 0) (#27)
by codemonkey_uk on Fri Apr 11, 2003 at 06:34:45 PM EST

Difficult error messages were one of the problems mentioned in the talk. I believe the whole thing is more of an academic exercise than a real effort to add real lambda functionality to C++.

I think there is a real chance that C++ will support some kind of lambda functionality at some point in the future, but there are higher priorities for the standardisation teams right now, so don't hold your breath for them! If your design suits a functional language, use a real functional language! :)
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

I like my sofa-bed (5.00 / 1) (#34)
by fluffy grue on Fri Apr 11, 2003 at 10:59:00 PM EST

It's a great sofa when I use it as such, and whenever someone visits me and needs a place to sleep, it makes a decent bed.

Draw whatever parallel with C++ you like.

Then again, I sleep on a futon.
--
"Is not a quine" is not a quine.
I love you.

[ Hug Your Trikuare ]

ACCU Spring Conference 2003 Roundup | 162 comments (145 topical, 17 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!