7

Currently, I'm following a course on embedded software development. The lecturer has chosen J as an architecture language for model-driven software development. J itself is a very terse programming language and one of his main arguments for this language is its terseness. For instance, this is a Quicksoft implementation in J:

quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#)

Another argument is that through such a language and the reduced number of characters, you introduce less bugs and the time to fix bugs is reduced.

Since I have a strong software engineering background and through various books like Clean Code, Pragmatic Programmer and others, I feel that these arguments aren't valid. I find that there is a strong movement towards descriptive names and code that reads like natural language (alright, this might only be related to applications with lots of business logic and less math).

The question therefore is, can you really argue that usage of a terse programming language will result in less errors and that time to fix a bug is reduced? Also, since the language is terse, the number of lines of code is reduced and you would get a better COCOMO rating. But can this be applied in the first place or does the COCOMO model use the number of lines of code as a way to estimate a project's overall size (project size should be the same whether you implement it in a terse language or in an imperative one, but again, maybe I didn't understand the COCOMO model correctly)?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
TommyMason
  • 945
  • 5
  • 13
  • There is no ubiquitous model for estimating software cost. COCOMO is based on a lot of metrics and you can play with it to get an improved rating. But I believe that the major hitch in generating cost for any model is the dynamism involved with changing requirements and the cascading effects of an error. More than terseness and SLOC, if your model is orthogonal with an easy syntax,useful comments, a standard convention, aided by decent documentation, its good. You should be able to read and understand your code after some time and somebody with the same ability should also be able to read it. – Ubermensch Jan 04 '12 at 14:01
  • 6
    that quicksort implementation looks like line noise to me, I don't see how that would be maintainable by a broad set of of the software development community. It almost makes the most obfuscated Perl look reasonable. **Terseness isn't a virtue if it sacrifices maintainability.** Maybe you are missing another more substantial reason for your instructor picking this obscure language. Like *"the traditional use of J – programs are entered into a J interpreter session"*. Which might be a valid reason, in an interactive teaching environment. –  Jan 04 '12 at 18:27
  • @Jarrod Roberson, the question wasn't meant to include all the rationale behind this decision. According to the solution of a test exam question: _"J descriptions are compact and have a reduced risk for side effects"_. Also, I picked the quicksort example from Wikipedia and I believe that this isn't the way most J programs look (at least if you wan't to keep it maintainable). – TommyMason Jan 04 '12 at 18:44
  • 1
    if you interpret *"J descriptions are compact and have a reduced risk for side effects".* for *"reduced number of characters, you introduce less bugs"* you misunderstand what he means by **side effects**. –  Jan 04 '12 at 19:12
  • _"reduced number of characters, you introduce less bugs"_ was a different statement and is not based on _"J descriptions are compact and have a reduced risk for side effects"_. – TommyMason Jan 04 '12 at 19:52
  • if you are using Cocomo to estimate, then compare your results ONLY to other Cocomo estimates for projects in J.. – chesscov77 Aug 31 '14 at 23:36

3 Answers3

9

Is the COCOMO model a good argument when defending a programming language choice?

No. COCOMO says nothing about language choice at all. It is a cost estimation tool to determine how much it will cost to build a given software system given a series of inputs. The latest iteration is COCOMO II, and there are web based tools to use when applying this model. Some of the inputs that go into COCOMO II include the estimated size in SLOC or function points, the team cohesion, maturity of the process, desired reliability, complexity, the capability of people filling different roles on the team, platform constraints, and schedule. The output is the estimate for effort, schedule, and cost for the project.

Only a handful of the inputs are related to technology and programming language. The key adjustment factors that cover these areas are the capabilities of the programmer, experience of the programmer in the application domain, experience with the platform and language, and the ability to obtain and use supporting tools.

As far as defending a language, the best that you can do with COCOMO is produce multiple estimates for different technologies and languages that the team knows to varying degrees. Perhaps there's one technology that the entire team knows and has successfully used before, so platform and language experience would be high, but that language has very few supporting tools so that would be lower. You can compare that to a language that perhaps only one person knows extremely well and a few people know a little about, calling the experience nominal, yet factoring in the rich tool set. Given two (or more) sets of effort, schedule, and cost estimates, you can compare to see which might be more effective to use.

Also, since the language is terse, the number of lines of code is reduced and you would get a better COCOMO rating.

There is no such thing as a COCOMO rating. COCOMO is an estimation tool that you can use to try to determine how much effort (person-months), schedule (months), and cost a project will require to complete. When estimating, this data is compared against the size of the project team and the business schedule to determine if it's realistic and to provide the project manager with information needed to control the project schedule.

For example, COCOMO might produce a schedule estimate of 15 months and a cost estimate of $500,000. However, the business schedule might call for 12 months and $450,000. This schedule and isn't unreasonable, and the project manager can use this information when controlling the project and negotiating with the customer.

But can this be applied in the first place or does the COCOMO model use the number of lines of code as a way to estimate a project's overall size (project size should be the same whether you implement it in a terse language or in an imperative one, but again, maybe I didn't understand the COCOMO model correctly)?

Although source lines of code (SLOC) is a valid input to COCOMO, estimating size using source lines of code is not recommended because the number of SLOC varies depending on programming language (among a number of other problems). Function points are a preferred method of size estimation. There are conversion ratios that allow you to estimate a number of function points and apply the ratio to determine the size of the system in a given programming language.

Now, comes the other parts to your question.

Currently, I'm following a course on embedded software development. The lecturer has chosen J as an architecture language for model-driven software development. J itself is a very terse programming language and one of his main arguments for this language is its terseness. Another argument is that through such a language and the reduced number of characters, you introduce less bugs and the time to fix bugs is reduced. [...] I feel that these arguments aren't valid. I find that there is a strong movement towards descriptive names and code that reads like natural language (alright, this might only be related to applications with lots of business logic and less math).

That's nice. In my experiences, the lecturer has more experience in the topic than the typical student. When they choose a given language, framework, platform, or technology to use to teach their content, they have a good reason to.

Terseness is, in my opinion, a rather poor measure to discuss a language on. There are far better criteria to use when choosing a language to implement a project in - platform support, tool support, available resources, team knowledge. With never having seen J before, it seems rather difficult to read. However, it might be very good at solving the particular problems that the project is trying to solve, and the people on the team might have experience with it. It might also be easy to learn.

In your specific case, of a class, you need to focus on the point - learning concepts and techniques. Not only will you learn about J (and learning new tools is always good), but you'll learn techniques that can probably be applied to other languages as well.

The question therefore is, can you really argue that usage of a terse programming language will result in less errors and that time to fix a bug is reduced?

My intuition says no, but that's beside the point. You need to factor in knowledge of the language, supporting tools (compilers, IDEs, static analysis), and process methodology (pair programming, code reviews, style guidelines), and more to have an adequate discussion of how to reduce errors and time-to-fix.

If you're interested in more about COCOMO and what it's all about, I'd recommend reading Software Engineering Economics and Software Cost Estimation with COCOMO II, both by Barry Boehm. Software Engineering Economics is mostly general software project management, cost estimation, and effort estimation. The portion of the book that discusses COCOMO discuses the COCOMO 89 version, which Boehm has said should no longer be used due to inaccuracies that were corrected in the COCOMO II version, however the rest of the sections of the book are still relevant.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • I wish I'd had you to explain COCOMO to me at University. My lecturer presented it as a magic formula, where you put in guesses and somehow came out with a meaningful number, so I basically sat there muttering "Garbage In, Garbage Out". If they had instead said "you can use it to estimate the impact of different design decisions", maybe I'd have learned something I could apply in real life. – IMSoP Apr 20 '21 at 16:46
6

It may result in fewer faulty characters per program, but that is all you can predict. And the COCOMO metric doesn't account for the natural verbosity of different languages, therefore it is meaningless to use it as an argument for one language over another.

No, the question of whether a language promotes better, more error-free code or not can only be solved through rigorously controlled contrastive experiments. Unfortunately there are few really unbiased research studies, and it seems there is always a reason why a non-advocate will reject the findings of an advocate in favor of one particular language.

Perhaps the most convincing argument is real-world use. Granted, there is a lot of inertia, backward-compatibility constraints, willful ignorance etc. in the world of commercial software development, but you have to ask yourself: if Wonder Language X (be it J, or Lisp, or Haskell, or whatever) really consistently produced better programs faster - wouldn't at least some of the less backward managers eventually notice that and at least try to gain an edge over the competition by using it? And note that it has to bring actual benefits, not benefits that only work for academic toy problem sizes, or only if you have extremely smart people use it.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 1
    If you use function points as an input to COCOMO, I believe there is an adjustment factor for different languages to account for time. If you use SLOC, you can only compare COCOMO output against projects in the same language. Unfortunately, I only have Software Engineering Economics, which covers COCOMO 89 and not COCOMO II (the preferred COCOMO implementation these days). – Thomas Owens Jan 04 '12 at 10:44
3

First. Do you want to pass the course? If so, learn J rather than argue with the lecturer. Learning J has value.

Second. COCOMO backs up the lecturer, not you.

can you really argue that usage of a terse programming language will result in less errors and that time to fix a bug is reduced?

Yes. That's what COCOMO says. Lines of code ➜ effort ➜ duration (and staffing and cost).

since the language is terse, the number of lines of code is reduced and you would get a better COCOMO rating.

Correct.

But can this be applied in the first place

What?

or does the COCOMO model use the number of lines of code as a way to estimate a project's overall size (project size should be the same whether you implement it in a terse language or in an imperative one,

No.

maybe I didn't understand the COCOMO model correctly)?

You did. CoCoMo says lines of code == effort, and J will minimize lines of code.

Third. J has value even if you initially find it unclear.

A predecessor to J, APL, was invented specifically to mirror mathematical notions of reasoning, the way operators work across various data types and the way functions can be combined in a functional programming sense.

The point of APL (and J) is to allow you to create new, higher-order, application-specific operators so that your code looks (and feels) like ordinary mathematics. It reduces the "gap" between specification, design and implementation.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • First of all, thank you for your answer. I should point out that I'm at the end of the course and that I already studied J. So this is not one of the _"I just don't want to learn this so please give me arguments against it"_ questions. I'm really interested in the reasoning and the way the COCOMO model takes SLOC into account. As Thomas Owens also pointed out, there is a notable difference between various programming languages which should be recognized. – TommyMason Jan 04 '12 at 11:45
  • 1
    @BenR: "So this is not one of the "I just don't want to learn this so please give me arguments against it" questions.". That's false. Reread the question. It's entirely that question. If you don't want it to be that question, the edit it so that it's not that question. If you just want to know about COCOMO, then get rid of the entire "I disagree with J as a language" part of the question. – S.Lott Jan 04 '12 at 11:47
  • Sorry S.Lott, but I never wrote this in my question. While I wouldn't have chosen J personally, this question was not meant to find alternatives or further reasons against it but instead I'm interested in the reasoning. Specifically, I'm asking for information on COCOMO and don't even mention J after the code snippet. – TommyMason Jan 04 '12 at 11:59
  • 1
    Sorry, @BenR, but you're not reading my comments. You clearly have an idea of what you hoped your question said. However, I'm trying to explain that your hoped-for message did not actually arrive. Your question has four paragraphs complaining about J. And only one paragraph with a question. Really. You may hope that it reads like "context" or "background". I'm trying to explain that it's sounds like complaining. Perhaps you should consider rewriting it a bit rather than insisting that people are misreading it. If your audience doesn't get your message, it might be your presentation. – S.Lott Jan 04 '12 at 12:18
  • Size is one input into COCOMO, so SLOC == effort is wrong. Effort and cost are functions of size (SLOC or function points, preferrably function points), team cohesion, process maturity, required reliability, complexity, the capability and experiences of team members, and more. If all other things are equal, using tools and platforms that the developers are familiar with in order to reduce effort and cost. However, the whole concept of using COCOMO in an academic setting to argue language choice is pointless. The purpose of a class is not to reduce cost/effort, but to learn concepts/techniques. – Thomas Owens Jan 04 '12 at 12:22
  • @ThomasOwens: Size (SLOC) is the primary driver. All other effects are intended to be minor. The essential effort equation is E = A * S ^ B. Effort is a function of two parameters (A and B) that define a "management style" and SLOC. The other adjustment factors are *intended* to be minor tweaks. COCOMO II adds factors but doesn't change the essential form of the equation. And "using COCOMO in an academic setting to argue language choice is pointless". Absolutely true. – S.Lott Jan 04 '12 at 12:26
  • The other effects are pretty significant, at least in COCOMO II. According to Steve McConnell's Software Estimation, experience with the given language and toolchain has a 40% impact on productivity and using the weakest tool set and environment can increase effort by 50%. The influence of platform experience is 1.40 and the influence of programmer capability is 1.76, meaning that low experience and low capability means 1.40 and 1.76 times more effort than very high capability. Although size is primary, you definitly can't discount the other factors at all. – Thomas Owens Jan 04 '12 at 13:04
  • @ThomasOwens: "The other effects are pretty significant". No disagreement. 50% impact is significant. I didn't discount anything. I'm only talking about the **primary** effects which are lines of code. It's difficult to enumerate every possible nuance of cost in an answer to a question like this. You can, however, enumerate every possible effect in the comments if you find that it helps you. – S.Lott Jan 04 '12 at 13:36
  • That's a valid point. The reason I picked out those particular factors (of the 20-something, I think, in COCOMO II) is because they are the ones that are most relevant to technology choice without considering the technical feasibility behind technology choice. A full discussion of cost and effort would be several volumes of text and not suitable for an answer, much less a comment (Software Engineering Economics is almost 800 pages, Software Estimation is nearly 300, and those don't even cover everything together). – Thomas Owens Jan 04 '12 at 14:04