7 ms·

What matters the sum of total complexity: the language spec + adhoc idioms/patterns/conventions/workarounds used in actual codebases. This is a great one sente

What matters the sum of total complexity: the language spec + adhoc idioms/patterns/conventions/workarounds used in actual codebases. This is a great one sentence summary of the history of C++. (Would also do for a history of programming.) Any hoary Ruby veteran probably has a story about the misuse of missing_method. (Likely one in which they were the antagonist.) The way that the programming field has shaken out, it turns out that there is a group of programmers who are fine with application programming and using well thought out libraries. However, only a minority of these programmers have the ability to engage in the thinking about other-POV and 2nd/3rd order effects that are needed to make a good library or meta-level tool. (Not to mention the community management skills needed to keep people happy while not giving them absolutely everything they want.) As a relative noob, I was listening to hoary Smalltalk veterans talking about this in the early 2000's. This situation is pretty analogous to the one surrounding crypto, except that the consequences of hubris are somewhat milder. The lesson learned from history is to talk about about simplicity/complexity in a more holistic way. Also from the early 2000's -- The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design.

bcbrown 9y ago
> The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design. When I reread the GoF book a few years ago, I was struck by the number of patterns that are just built-in to modern languages.
- rrobukef 9y ago
  Most of the behavioural patterns are eased by fp techniques like lambdas+currying and adt/pattern matching (visitors are well known losers). The structural patterns are however much more a pain in fp while they feel natural in oo. Facades and decorators need type hiding that's only nice(r) with existential types. The creational patterns are a mixed bag. Builder, singleton fit with fp, Abstract Factory fits with oo and factory methods with both. What do you think? How are the oo patterns improved by other techniques. Though a lot of those patterns are probably for C style oo.
buzzybee 9y ago
I've been musing about these sorts of issues of "what is really complex" lately, too. I started evaluating new languages for low-level application code again after spending a lot of time overly close to web browsers, and then ended up deciding that Free Pascal beat them on the stuff I cared about, relative to C compilers as a baseline: * Best-in-class compile times * Modules; preprocessor is relevant, but not dominant * Generics, variant records, function and operator overloads, exceptions, safe string and dynamic array types * Libraries for common things, with a reasonably conventional style: APIs, containers, bindings, etc. * No GC; pointers are available, but language features discourage casual usage. RAII pattern is achievable. * Strong + static types, nominal types and type aliasing. * Good IDE support, mature tooling, compiler has very broad platform support. The new languages do win on a lot of the language-feature aspects(particularly memory safety when performing deep optimizations), but they don't have as good a story on the tooling. The compile speed is a major feature and is only likely to remain advantageous over time - and the features already in place are quite effective at limiting source code size, boilerplate, and dangerous constructs. This despite "Pascal is verbose" being memetic. And if I want more high-level power, I've found that writing a FSM is the most probable path to achieving it. A FSM that embraces the problem domain is a tiny compiler: input source constructs, FSM checks them, applies appropriate algorithms, then emits a list of actions. More power? Add a second FSM to make it a two-pass compiler. Add a stack, or attach it to a database. If it has to be fast, it can generate code in the last step, too. Those things add tons of power to model the problem and aren't heavily dependent on language-side support.
- pjmlp 9y ago
  Yup, we already had all of that in Turbo Pascal for MS-DOS, hence why I never saw any value in C back in 1993. On those days outside UNIX, C was just yet another systems language, with most home micros being written mostly in Assembly. Also Turbo Pascal OOP features were adopted from Apple's Object Pascal, used to write the initial versions of Lisa, Mac OS and known software like Photoshop.

bcbrown 9y ago

> The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design. When I reread the GoF book a few years ago, I was struck by the number of patterns that are just built-in to modern languages.

rrobukef 9y ago
Most of the behavioural patterns are eased by fp techniques like lambdas+currying and adt/pattern matching (visitors are well known losers). The structural patterns are however much more a pain in fp while they feel natural in oo. Facades and decorators need type hiding that's only nice(r) with existential types. The creational patterns are a mixed bag. Builder, singleton fit with fp, Abstract Factory fits with oo and factory methods with both. What do you think? How are the oo patterns improved by other techniques. Though a lot of those patterns are probably for C style oo.

buzzybee 9y ago

I've been musing about these sorts of issues of "what is really complex" lately, too. I started evaluating new languages for low-level application code again after spending a lot of time overly close to web browsers, and then ended up deciding that Free Pascal beat them on the stuff I cared about, relative to C compilers as a baseline: * Best-in-class compile times * Modules; preprocessor is relevant, but not dominant * Generics, variant records, function and operator overloads, exceptions, safe string and dynamic array types * Libraries for common things, with a reasonably conventional style: APIs, containers, bindings, etc. * No GC; pointers are available, but language features discourage casual usage. RAII pattern is achievable. * Strong + static types, nominal types and type aliasing. * Good IDE support, mature tooling, compiler has very broad platform support. The new languages do win on a lot of the language-feature aspects(particularly memory safety when performing deep optimizations), but they don't have as good a story on the tooling. The compile speed is a major feature and is only likely to remain advantageous over time - and the features already in place are quite effective at limiting source code size, boilerplate, and dangerous constructs. This despite "Pascal is verbose" being memetic. And if I want more high-level power, I've found that writing a FSM is the most probable path to achieving it. A FSM that embraces the problem domain is a tiny compiler: input source constructs, FSM checks them, applies appropriate algorithms, then emits a list of actions. More power? Add a second FSM to make it a two-pass compiler. Add a stack, or attach it to a database. If it has to be fast, it can generate code in the last step, too. Those things add tons of power to model the problem and aren't heavily dependent on language-side support.

pjmlp 9y ago
Yup, we already had all of that in Turbo Pascal for MS-DOS, hence why I never saw any value in C back in 1993. On those days outside UNIX, C was just yet another systems language, with most home micros being written mostly in Assembly. Also Turbo Pascal OOP features were adopted from Apple's Object Pascal, used to write the initial versions of Lisa, Mac OS and known software like Photoshop.