Programming Languages

Xyzzy Oriented Language

Object-Oriented Languages

I have programmed in quite a few different languages over the years.  My current language at work is C♯.

C♯ is an object-oriented language.  One of the three mainstream .NET languages:  C♯, F♯, and VB.NET.

C♯ has three egregious shortcomings that make the language suck.

• lacks non-nullable references
• lacks immutability
• lacks design-by-contract, such as in Eiffel or D

Non-nullable references is baked into the heart of Swift.  Non-nullable references are part of C++.

“I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.”
~ Tony Hoare

Gee, thanks Tony.  Billion dollar mistake for ALGOL W, but a trillion dollar mistake for C♯.

With 20/20 hindsight, one might have thought the .NET brainiacs would have avoided that mistake.  Alas, no.

The lack of immutability—true, deep, transitive immutable (as found in D or F♯)—is insurmountable in C♯.  At best a C♯ developer can mimic immutability (initialization on construction, private backing store, and getters without setter properties), but the C♯ type system gives you bupkis.

Lack of design-by-contract in C♯ can be compensated by doing TDD-style unit tests, xUnit.NET, and NSubstitute along with continuous unit test runner like NCrunch.  A lot of extra work to make up for a language shortcoming, but a viable option.

Function-Oriented Languages

While C♯ is an object-oriented language, F♯ is a function-oriented language.

If you are familiar with function-oriented languages like Haskell or OCaml, F♯ will seem right at home.

F♯ is pretty much “OCaml for .NET”, and large swatches of OCaml will compile as-is under the F♯ compiler.  Cool!

If you have programmed in LISP or Scheme, you may consider those languages themselves to be function-oriented.  I do not.

I consider LISP and Scheme to be language-oriented, and provide nuts-and-bolts level access to AST manipulation.  They lend themselves readily to functional-style programming, because functions are first-class data types.  But not function-oriented.  LISP and Scheme are as close to function-oriented programming as C♯.

Now that my flame-bait is out on the table, let me try to summarize key features of function-oriented languages, which LISP and Scheme lack some of them.

• immutable data
• ability to compose functions
• functions can be composed
• lazy evaluation
• pattern matching
• simple, succinct, spartan syntax
• discriminated unions

Enough of that sidebar.  F♯ also has...

• fluid interop with other .NET languages
• variables (making it an impure functional programming language)
• strong typing
• static (compiled) language, not a dynamic (scripting) language
• whitespace “off-sides rule” for code blocks (like Python or Makefile)

Language-Oriented Languages

So languages such as LISP and Scheme I consider language-oriented languages.

“[Scheme is...] the world's most unportable programming language.”
~ Scheme Steering Committee

One of my co-workers had worked on a large-scale Scheme programming project.  This project was large enough to be unfathomable, hard to maintain, and when the Scheme guru left the project, the project died.

These are not hallmarks of a function-oriented programming language, but they do not surprise me for a language-oriented language like Scheme.

Oh, and as for the quote above, Scheme is such a spartan specified language that it lacks standardized libraries and I/O.  So everyone’s implementation is different.  That smells like the same problem that Pascal had in the 1980s where different implementations had their own non-standardized proprietary I/O subsystem.

Domain Specific Languages

There are two kinds of DSL.  There are embedded dynamic specific languages (EDSL), and there are DSL’s that have their own syntax and grammar.

I’ve taken a looksee at Gherkin, the BDD language used by Cucumber.  That looks like an excellent language for BDD.  It is a DSL proper.  It is a language that allows expression of the problem domain by the product owner author (in collaboration with developers and testers), in a “stilted English” style.

I’ve taken a looksee at RSpec, another BDD language.  That looks like the worst possible language for BDD.  It is a EDSL.  It appears that the author of an RSpec BDD would be a developer, and that’s the wrong person to do that work.

Sorry RSpec.  But that is how I read the tea leaves.  If BDD stories and scenarios are not being authored by the product owner (in collaboration with the rest of the team*), then it is a fail.

* The biggest value proposition (*cough* everyone drink) of BDD is that it facilitates communication in the team, so everyone is on the same page as to what is being created.  The BDD stories and scenarios then become artifacts that have residual value, in that they allow continuous regression testing over time to make sure features are still working.  The developers are burdened with making the Gherkin glue layer, which is no trivial matter either—Gherkin isn’t magic and isn’t free.  Despite the overhead costs, it looks amazing to me.

If the product owner is also a Ruby programmer, okay, then RSpec is a viable option.  In my experience, it is very rare that the product owners—domain experts, business analysts, project managers, feature managers—are also competent programmers.

---

2015-Mar-15, by Eljay
first blog post, testing out the waters

Keywords: OOP F# C# FSharp CSharp BDD