Instant Language Form

Everybody wants a language that best models their own mind and work habits and mistake patterns. No language will ever satisfy everybody and debates over which features are better will never be settled. Maybe someday there will be a language creator whereby you select which features you want and don't want, and the language generator then generates the language with the features you select. (However, the hard part would be to get everyone else to use it.)

As a whimsical thought experiment, here is a hypothetical form with feature selections. You can get ideas for features from topics such as LetsDesignProgrammingLanguage, ItsTimeToDumpCeeSyntax, IdealProgrammingLanguage, SyntaxFollowsSemantics, RethinkingCompilerDesign, FutureOfProgrammingLanguages.

Features in each group are mutually-exclusive if they have round brackets, but not if square brackets.

Maybe someday new technology or an overzealous programmer will actually build such a thing.

--top

(Square brackets are check-boxes and round ones are radio-buttons)

Compile Level

Model for Linking and Modularity Modularity and Linkage Features Resource Management: Language-supported Models of Computation: (requires a convenient syntax, and support via the standard language or standard libraries) Language Primary Decision Logic (the one integrated with common libraries and predicates) Language support for Collections: (assuming SymmetryOfLanguage: features should apply to all 'standard' collections). Language support for pattern-matching: Language standard support for User Interface: Language standard User Interface Features: Language support for Parallel Operation: Language support for Safe Shared Memory access: Support for Distributed Operation: Language Supported Forms of Implicit Context: Syntactic Abstraction Syntactic Abstraction Features: Semantics Manipulation Semantics Manipulation Features Language Versioning Support (prepare to fail to get it right the first time...) Default Failure Handling: internal handling of errors (as observed in standard libraries) Default Failure Reporting: support for external indications of errors Failure Reporting Features: as observed in the standard mechanism Syntax Design Principles: (perhaps order these in terms of priority?) Ambiguity Handling: ambiguity is not always an enemy; it can be used to simplify syntax and even leveraged (e.g. Polymorphism is designed to take advantage of ambiguity). Block Syntax Statement Delineation Statement Delineation Token Type Indicator Syntax Native Null-Handling Dynamic Type Enforcement Type-Tag Sensitivity Etc...

Symbol allocation:

References (such as C's "&"): _____

Object path element separator (such as "." in Java) _______

String concatenation: ______

Name-space element separator/indicator: ____________

(Etc.)

I note how much of the above is about picking and choosing syntax. SyntaxMatters, but not that much.

[Indeed. Syntax is about as important as what kind of keyboard you use -- it might have an effect on individual productivity, but it's of no theoretical or conceptual significance.]

{Unfortunately, theory and reality are only theoretically related. SyntaxMatters a great deal. Get used to it.}

That "just a theory" fallacy is so damn tired and old. Gravity, and the whole notion that something will fall if you drop it, is also only a theory. And so is 'SyntaxMatters'.

Syntax does matter. It's a vehicle for semantics, and good syntax abstraction (e.g. RealMacros) can help where the semantic abstractions of the language are insufficient. But the people who think SyntaxMatters a "great deal" tend to be victims of Parkinson's law of triviality. People will argue for weeks on braces vs. whitespace because that's all they really know about language design.

{This is naturally contradictory. If syntax has impacts on productivity, as is claimed above, and productivity of a coder translates into income of a corporation, then clearly syntax must have an impact on a company's bottom-line. This is very, very, very, very, very, very, very, very far from being theoretical.}

I do not doubt that it does have an impact. But the nature of that impact is quite theoretical at the moment. At best, we can usefully predict how certain decisions in syntax will catch or be prone to particular errors, support or hinder particular patterns of syntactic abstraction, and simplify or make more complicated given use cases. Considering overall productivity? not a chance. Of course, the people who argue for weeks on braces vs. whitespace and such rarely even know about these predictable impacts, and their frivolous pursuit of syntax is more religion than sound engineering.

In any case, choice of syntax doesn't make nearly the amount of difference as does design and careful choice of semantics. Compared to semantics, syntax is a very shallow subject. People who believe syntax is all there is to language are people who haven't seriously studied language.

{Remember that a happy coder makes better code, just as happy cows make better cheese.}

I wouldn't be surprised if coder happiness and code quality are weakly correlated, but I doubt there is a causal relationship involved in the direction you imply.

I generally agree with the "happy cows" statement (not my statement). It's a variation of PsychologyMatters. A closer fit to a person's brain is better text-to-human communication, and better communication makes for less misunderstandings and perception mistakes. --top

Here is a glass-half-empty vs. glass-half-full question for you, top. Are you naturally inclined to believe that happy cows make better cheese because they're happy? or are you naturally inclined to reject such a conclusion as premature, thinking that cow happiness and quality of cow cheese could both have a positive causal relation with, say, cow health?

You've been peddling pseudoscientific beliefs like 'PsychologyMatters' on this wiki since you got here, despite neither making any useful or falsifiable predictions nor having any evidence to back you on it. If you're the type of person who jumps to premature conclusions, I can, perhaps, see how you come to insist on these beliefs as though they were more than speculation.

{ In support of the happy cows hypothesis, there appears to be a distinct correlation between adoption of XP practices, individual programmer happiness, and product quality. The practices, ultimately, are what enforces product quality, but nonetheless, coders seem happiest when practicing XP. Perhaps the next best example would be Scrum. Meanwhile, those which rely on BDUF-methodologies seem pretty consistently unhappy, and the quality of the product, with very rare exception, seems to be horrible.

However, there is a rarity -- that of the SpaceShuttle's software, which is the epitome of BDUF, and yet has stellar quality. And, if public record is to be believed, the coders on the project are happy to be there. They have a process which works for them, and they've expressed no desire to abandon it for greener pastures. Again, a correlation between happiness and product quality.

The Shuttle software team has one benefit that the rest of us in BDUF-land do not have - their spec are set in stone - no deviations are allowed, unless a full impact study is done, and all schedules adjusted in the proper direction. They are not trying to hit a moving target.

There are, in fact, many instances in history (not just software related) where the reverse occurs (nonhappiness closely correlated with lack of product quality). The most extreme, of course, is when Verner Von Braun was working on the V2 program in Nazi Germany, where the slave labor urinated in the mechanisms and electronics, left screws untightened or over-tightened, et. al., all in an effort to deliberately sabotage the project. A bit less extreme an example might well be Microsoft Windows itself. }

[There may indeed be a correlation between developer happiness and product quality -- it's hard to say, without experimental results that clearly isolate happiness from other factors that may affect quality and vice versa -- but correlation obviously does not imply causality. The above suggests to me that successful projects may be causal in producing both developer happiness and high quality, but again, without experimental evidence this is mere speculation, as is the reasonable -- but unproven -- supposition that happy people (for whatever reason) are more likely to produce good quality than unhappy people. However, I'm not sure what this has to do with the significance of syntax. Anecdotally, I've observed that experienced developers with numerous languages under their belt are far less likely than junior programmers (typically familiar with only a few languages) to be concerned with trivialities of syntax, such as block and statement delimiters and delineation. Indeed, experienced developers are more likely to regard (for example) one statically-typed, manifest-typed, compiled, imperative, object-oriented, structured language as pretty much interchangeable with any other regardless of syntax (and therefore be equally happy or unhappy with any of them), while the junior developer may naively regard C# as completely different from Java purely on the basis of syntax, or ObjectPascal completely different from C++ (and therefore be happier with one over the other), with the distinctions between (say) C++ and Haskell -- which are conceptually significant -- barely comprehended.]

What's a "vague type"? (BTW, all languages can be implemented without type tags.)

I've changed it to "dynamic type", as I can only assume that is what was meant.

I'm afraid I don't recognise much in the "Type-Tag Sensitivity" section. A "type tag" is a specific implementation-level mechanism used in some languages. Even if we assume "type-tag" is intended to mean "type reference", it still doesn't make much sense.

CategoryLanguageDesign

SeptemberZeroEight

EditText of this page (last edited June 19, 2014) or FindPage with title or text search