What does it matter how many you write? How many do you delete?

I have a project that is 5k lines of code and roughly 11k of tests and specs(cucumber). It is a rewrite of a project that was 50k lines of code with 1.2k lines of tests and had less functionality and features than what it does now.

Lines of code are meaningless when it comes to how much value they provide. I personally prefer when a codebase is smaller because it means some thought was put into it and most likely has less bugs as a result.

I believe jblows games (braid, the witness) have less lines of code than one would typically expect. I think you should assume hes not writing code like a government contractor.

upvote for government contractor, I once saw 5k lines of code for simple change of address in the front end alone !!!

I said shipping code, by which I specifically mean that which is left after all deletions (of which there are many).

Some of the gain in concision is from the language it seems but I think this case is very much from the view of leveraging frameworks and libraries which themselves are quite a bit bigger than the app. I cloned a few of the repositories and excluded tooling that was used for documentation, testing, and so on. It's non-exhaustive since I only wanted to get a ballpark figure but we have:

    1.4 million lines of Erlang

    309 thousand lines of C

    120 thousand lines of Elixir

... And lots of other code and things I've excluded. These are lines of code, not counting blank or comment-lines.

Now we could argue that we could unwrap this count at any layer? Why stop at Erlang/OTP? Why not include the C runtime and the Kernel? The real effect here is that a lot of this code implement things that are directly used by Phoenix apps, so I think it's fair to say, it's concision comes from being very good at leveraging other code.

(I don't write Elixir code but I've seen some good results from teams who have. None of it is magic though.)

I don't really think one can judge the work of someone else by the line of codes he writes a year. I thought IBM management failures demonstrated that kind of metric is meaningless. Furthermore, 10,000 lines of elixir/Ruby is not like 10,000 of say Java that don't do much except wiring dependencies.

INDEED. 10K lines RoR = 100K lines JEE. More or less.

(OK, I made those numbers up, but reading Java code is bloody tiring due to the silly walks and typical paste-o-graphic work styles)

One interesting thing I've found with my limited experience with Elixir is that the code is very compact. What would often take 10+ LoC in other languages can be succinctly expressed as 1-2 lines.

But I do in general agree with your take on it :)

> would often take 10+ LoC in other languages can be succinctly expressed as 1-2 lines.

Every time I have heard this kind of claim (with modern languages), it turned out not to be true except for trivial code or straw-man bad code in the 'bigger' language. So if you have real-world examples that have real-world effort put in, I'd like to see them! (I would be happy to be wrong.)

5x-10x productivity increase would be huge if it actually existed; it would be so unstoppable that everyone would switch to the new really-great language immediately. That hasn't happened, which should be a clue that maybe the increase is not there.

Even a 20% decrease in cost of engineering would be so large as to be unignorable.

Concurrent, preemptive socket servers with robust failure handling are "trivial" in Erlang. I'd say 10x productivity would be an understatement compared to other languages. Writing FPU code? 0.1x productivity would be generous. It depends on the problem you're solving.

Obviously we're throwing around random values like 5x and 10x "productivity" but it's more nuanced than that. There's more than LoC that can be measured as "productivity": how about bug count and severity per LoC written, refactoring cost, performance, robustness, library support, setup time, etc. And many more metrics.

Metrics are valued differently depending on the programmer and the problem. Eg, who cares if my CRUD web app has memory leaks and crashes randomly, it's stateless! There's not one really great language because every programmer their own productivity priorities.

Often, though, LoC is used as a poor proxy for this multi-dimensional "productivity" value.

> 5x-10x productivity increase would be huge if it actually existed

When writing software, how fast you can type the code is rarely the limiting factor for speed of development – the architecting and consideration of interplay between components takes the bulk of the time. The grandparent claimed code reduction (which has intrinsic maintainability benefits) but made no statements about general cost of engineering.

> the architecting and consideration of interplay between components takes the bulk of the time.

Which is supposed to be what is simplified as LOC goes down.

So if a supposed 5x-10x code reduction (which I've never seen real evidence of) doesn't lead to 5x-10x productivity increase, how much increase is there supposed to be? Surely more than zero?

> Which is supposed to be what is simplified as LOC goes down.

I don't think so. If you can express the same concepts with the same interfaces and functionality in 1kloc vs 10kloc, most of your time has probably still gone into figuring out the interfaces and connections.

> So if a supposed 5x-10x code reduction (which I've never seen real evidence of) doesn't lead to 5x-10x productivity increase, how much increase is there supposed to be? Surely more than zero?

Oh, certainly more than zero! Sometimes much more. But there's simply not a one-size-fits-all formula for the relationship between lines of code written and productivity.

Anyways, not really sure what you're getting at. Your original comment was that 10kloc isn't "big"; the rebuttal is that lines of code is a naive way of looking at system complexity, which is presumably what you mean by "big".

You find having to read 1kloc vs 10kloc the same?

I don't believe that's what was said. But in any case, the answer is generally no, depending on your definition of "read".

20% is a low enough bar that you can cite a well-known example: Objective C vs. Swift removes entire sections like headers and adds sorely needed typechecks. Our internal results are less code and fewer defects per line of code. However, a large number of people haven't switched. I don't blame them either; the transition (split code base) is painful and Apple makes things worse with language churn.

For your 5x-10x case, what is true is that the gain is genuinely possible, but it is just as likely to come from libraries than it is language constructs. Because of that it's often 5x-10x in a limited area.

In Elixir you never have to write an iteration, no need to dance the "for-loop-with-counter" dance.

Pattern matching makes it easy to bind variables and validate their values in one line (so no needs for if statement).

In Elixir, you usually don't catch exceptions, you let it crash. So all the code to handle failures/errors doesn't exist, it is handled by OTP.

No need to write any communication layer since it's built-in OTP that implements location transparency.

These are kind of the low hanging fruits on top of my head. I'll point out that fewer lines of code doesn't automatically translate to increased productivity. Also, transitioning to a brand new stack is not always justifiable/possible even with the promise of significant increased in productivity, it's really not that simple.

It's more like there are a lot of things you get for free with OTP/BEAM that you can not get at all or would take a lot of effort in other environments. So in those instances it can be easily even 20 to 1 or more those are also far from trivial. From hot code reload to calling code on any cluster node to process supervision and on and on

Checked exceptions

Lack of functional composition

Mandatory types (for every trivial parameter object or "lambda")

Excessive Object-Whatever-Mapping

Coping with mutable state in large amounts of effectively global data.

Excessive partitioning due to the size impacts of above hardships

Then we can start to talk about the lengths of the lines...

FYI: criticism aimed at a certain "Enterprise" language / libraries / culture which is pretty much mandatory outside of the Bay Area.

Note that a decrease in LOC does not imply a corresponding increase in productivity. Our Scala code is easily smaller than its equivalent Java representation, but:

1. Thinking about the problem and modeling it properly is still hard, and language independent

2. The language still has its own quirks/failings that you have to work around

PS. My comment has nothing to do with Scala per se - I'm using it as an example.

Even if you multiply it by 3 it's a small codebase. And Phoenix does bunch of code generation from what I've seen.

10,000 lines is actually a lot for Elixir. Its syntax and built-in standard library makes the code very compact.

two things:

1) elixir is relatively young so there aren't many projects that have had a chance to grow to be huge. so yea, take everything you read about it with that grain of salt. people haven't grown to hate it yet...maybe everyone will always love it, but I wouldn't bet on it.

2) when used in certain contexts, elixir applications may end up being quite a bit smaller than comparable java/scala/python/whatever apps. A lot of what we end up writing with microservices is just basic RPC and fault tolerance boilerplate stuff, which OTP takes care of out of the box. Example, pinterest re-writing a 10kloc java app in 1kloc of elixir, running it on fewer servers: https://engineering.pinterest.com/blog/introducing-new-open-...

Pro-tip: never look at number of LOCs to measure the size or complexity of a project, unless you are comparing two systems written in the same language. Even then, comparisons might be tricky due to factors such as libraries used.

This is why I'm wary of posts about Elixir. I love the language a lot but the blog posts and articles on it are mostly hype by people without much experience.

I'd say 10k LoC is where design and architecture start to become vital, you can't just hack away without breaking stuff.

I personally think copy & paste is an anti-pattern (instead, use features such as generics), but many think it is a godsend. Using code reuse rather than copying code can make a massive difference in size and maintainability, less is definitely more!

Dealing with that at work now. Dev added to project won't use the existing structure, just recreates and pastes stuff in over and over :-(

Part of that is a political problem, of course, but was not an issue earlier.

I spent the best part of yesterday's afternoon writing a complex SQL query. I could have written a few straightforward queries instead and still be here writing, debugging and testing the code to merge their results. I have this single LOC now instead of 100+. That line is worth 100.

I regularly delete or replace several thousands of lines of code without changing the functionality of application, put in by programmers like you, who are obsessed with the amount of LOC they produce. I am not sure why anybody thinks that a lengthy solution is great or we should judge programmers by the LOC they produce. I strongly believe that the better the programmer is the shorter the solution will be produced by her/him.

It's like judging the quality of a book by number of pages.

Run a code duplication detector in your code. I am curious to see if you actually need 250,000 SLOC, or if it's actually just copying and pasting around.