How much do you all value conciseness, generally? There's that observation that bugs/SLOC seems to be constant across languages. I know it's possible to go crazy with the conciseness: code golfing, point-free style insanity, etc, etc. But, putting that aside, idiomatic code does seem to vary a lot in verbosity. I've noticed that FRP seems to be verbose. So, just now I wanted to test out my impression for frontend. I looked at TodoMVC examples for CycleJS, Reflex, Turbine, among others. I know it's not an elaborate example but generally these are coded to show idiomatic usage so it's decent. I removed comments and measured lines and characters without whitespace. Of all the ones I looked at, these 3 FRP ones are the most verbose by characters. All three are at least 3 times longer than the Svelte example. (Svelte and Cycle aren't typed. Turbine and Reflex are.) (The Svelte example isn't codegolfing or doing anything funky). Anyone have thoughts on this? How much should we value types or purity/referential transparency over verbosity?

Verbosity of syntax is an ergonomic concern only when you have to edit text by hand, but a structured / projectional editor could solve that, for example by picking some good defaults that you can optionally change. There are many such programming language concerns that almost entirely disappear with a non-textual editor. Of course, regardless of the editor, we want to be able to be concise through abstraction. That kind of concision is of paramount importance, and FP excels at that kind of conciseness: of ideas, not of syntax.

@Deklan Webster could you please link/add the exact pieces of code?

@stevekrouse That feels a bit too reductionist - verbosity has an effect on reading as well, which is the more important case. Anything that obscures the intent of the code, comes at a heavy cost.

@Pezo - Zoltan Peto I guess so. They can all be found pretty much by searching "TodoMVC ___"

@ibdknox in a structural editor you can come up with various concise views of the some verbose underlying data. We don't need to be as worried about meta-data in a projectional editor world, because it's more like a database. I don't care how many attributes Slack stores about my messages. It just hides most of it and displays it concisely

at that point, you're designing a language to be concise though 🙂

@Deklan Webster However I am not a big FRP guy, I am interested in these topics, this is just an opinion: it seems to me these examples are quite different, because the “meaning” of the implementations vary a lot. They might do the same, but it might harder to extend the more concise code: it probably holds less meaning/intention/constraint which might or might not be useful for future changes/refactors. If you are composing your code using the same “tiny” parts over and over again introducing the minimum amount of new abstractions (which seems a good idea on the long term) you might end up with a bigger surface of core abstractions and more “plumbing” by joining the same core parts over and over again. But (in theory, lol) they should be already tested parts and you get used to them and this seems more scaleable. My problem is with TodoMVC that it does not involve refactoring at all. My problems usually arise when I have to change production code and related test code already written, I want do delete the less code and less related test possible. I am just not sure the svelte code would be easier to change. Note, despite we are talking about UI frameworks the part that varies is mostly “business logic” of the view not the “clean” view.

I've been using svelte for a personal project and absolutely loving it. I feel like the comparison is a bit disingenuous though—svelte just moves the FRP into the runtime in the same way that elm moves effects into the runtime

@Garth Goldwater I didn't choose Svelte because it's FRP in any sense. I just chose it for having a concise todomvc implementation. And, fwiw, Svelte moves the RP into the compiled code at compile-time. The runtime is basically nothing. There is no FRP. Just RP.

good point

@Pezo - Zoltan Peto I see where you're coming from. It seems to me that less code is easier to refactor than more code (modulo codegolfing**, and ignoring the visual editor questino for now). It seems plausible to me that Svelte might become harder to refactor with VERY large apps. Let's assume this code size scaled. 100k Svelte app vs. a 300k FRP-framework-app which is equivalent. Do you suppose the latter is easier to refactor?

I suspect you could evaluate something like "refactorability" by looking at how much indirection is present in the various options

@ibdknox Also, Chris, I'm not ignoring your good replies above. They're just difficult for me to understand. I've never used let alone coded a visual programming tool. Is this accurate? Steve seems to be saying you can get around the verbosity by hiding it away in a visual programming tool. The main view would only show more grokable high-level structure which you can zoom in on as you need. You're saying that it's not quite so easy. Visual programming tools bring their own difficult issues. It's not obvious how much detail to show. Etc.

yep! To see the tradeoff between reading and writing, it's easiest to look at the extremes: something like K or Perl (before 6) optimizes for writing at the cost of being able to read it

incidentally I have not used any of those < _ <

a visual tool is a language in the same way that a purely textual one is, since you haven't used visual tools, I used textual examples instead

hmm im just having trouble imagining an example of difficulty reading vs writing in a visual tool (outside excel, which I also havent used very much but I get that example 😛 )

In boxes and arrows style dataflow tools like Labview, you see this: it's very easy to wire up a couple of simple examples but in the end sacrifices readability (wires everywhere!)

@Deklan Webster To be honest I never worked codebases that large (speaking about the frontend part, even with tests), sorry I just can’t answer that. But! What I have found is that even in tiny apps complexity can go out of the roof if the app extends vertically not horizontally (vertically: (few) overlapping/complex features, horizontally: (more) separate features). If you say: “less code is easier to refactor than more code” I think that is totally right, I really want to keep code simple and I have learned and acknowledged that a simple hacky solution might not be just “nice” but also REALLY useful to avoid “medium” complexity. And I can just get completely rid of it if the specification changes without losing much energy. However what I want to note is that the really “hard parts” (/high complexity?) for me are the ones where I have to partially alter the implementation and but partially still satisfy some existing constraints: more meaningful set/layers of abstractions would be much more useful. Of course most time we don’t know what part will explode in complexity so we just pray and promise: this is the last ugly(/ultrasmart, but not flexible) if we don’t design for change in the right directions (which might be just impossible). So what I want to say that it seems to me that the linked TodoMVCs are just betting different directions of possible changes in future and that is why they differ so much. I might be just totally wrong, but then we should be able to examine what exact features do make Svelte more concise. I’ve seen a couple of videos on Svelte, but it seems to me that its really about 2 things: speed (with AOT) + embracing HTML. But yes, Svelte seems really terse, but not because the lack of FRP, it is “just a really good DSL”.

yeah I think the most exciting part of projectional editors is the idea that you might be able to switch from terse writing to clear reading on the fly

@ibdknox The subdiagram example makes sense. It seems to me that if the visualization software never lags, and the design is good then this is relatively minor. You're a visual programming tool kind of guy, right? So you think these are a better set of problems?

it is, but every operator is contextual which makes it significantly more difficult to understand

What side are you on o.O

"How much do you all value conciseness, generally?" I place a high value on simplicity. Some programming languages (or APIs) require a lot of boilerplate or add a lot of incidental complexity, which bloats your code, makes it harder to read and write. Some examples: idiomatic object oriented programming where you create far too many classes in order to encapsulate every concept, or manual memory management in C. Fighting the borrow checker in Rust. Or imperative programming in general: I find imperative style programming bloated and clunky compared to functional style programming in a proper functional language. I prefer to use languages/APIs/DSLs and programming styles that minimize incidental complexity and let me write short, clean, clear code.

@Deklan Webster I suspect @ibdknox is on the side of visual-text synthesis.

I’m not aware of evidence that defects/kloc is constant between different languages. My thought was that it’s inconsistent with comparisons of bug rates between different languages. Most of those studies show small or inconsistent effects, but some languages are much more concise than others. So if defects/line was constant, those languages would have much fewer bugs. https://twitter.com/hillelogram/status/1119733770838528001 https://twitter.com/hyperpape/status/1119717643156635648 (the threading is totally broken here)

Deklan has the right idea, of taking a relatively simple task and examining that same project expressed in many different languages/frameworks. The only problem in his test case was using TodoMVC, which as a task relies too heavily on the underlying OS libraries to yield useful information. There is over a million lines of code to handle a text entry field and draw text in the OS, so you are merely encoding the tip of the iceberg. I suggest you start with a progression of test programs, like i have been using for Beads, where i have an analog clock, then a wristwatch simulation, then snake, tic tac toe, minesweeper, chess. Those types of programs which are graphical and interactive really highlight the differences in languages/frameworks. In the tiniest example projects, which are only about a few hundred words most of the languages look alike but by the time you reach chess which is about 1500 words, the differences in verbosity and clarity between languages really starts to manifest. My own goal is to reach the optimum readability, which is a balance between compactness, abstraction, amount of punctuation, regularity of grammar, and aesthetics. The number of defects per lines of code varies greatly depending on the language, but my long experience shows that a more concise language is more productive, up to a point. When you reach the stratosphere of conciseness as in APL, FORTH and LISP, code gets very hard to read and repair. There was a reputation back in its heyday, that APL was a "write-only" language. We all know that single character variable names are very compact, fast to type, but obscure the meaning of the program. So that is why i count program size in words, not characters, because i don't want to reward intentional obfuscation.

@Justin Blank I'm not surprised the bugs/KLOC thing is folklore. It's an interesting conversation nonetheless

Nice chat friends. I'll reiterate that conciseness is not a virtue once to control for ease of change. Point-free style is a good example since it is often elegant but it goes wonky relatively easily.

My point about TodoMVC is that if you rely on the OS standard library too heavily in your test cases, you are really testing the OS not the language on top of it. One typically does not handle all the myriad complexities that are inside a text edit box. One gets a lot more information about the merits of a language when you code a more complex project like the chess program i mentioned. In the Mythical Man Month book, Prof. Brooks mentions that coding speed is relatively constant in terms of lines per day, so a more concise language is indeed more productive. He did not state any data about errors per line, but noted that overall productivity in terms of lines per code finished per day was remarkably constant. So conciseness is a major virtue as it also delivers more cost effectiveness. The virtues of conciseness was demonstrated in the switch from Assembler in OS/360 and the transition to PL1 in the Multics OS. PL/1 was unfortunately shunned by the other mainframe companies for competitive reasons, and thus COBOL was enthroned, beating out the other contender FORTRAN, but PL/1 was much more concise and productive than COBOL. But the most productive and effective language has never been adopted as the standard by the programming community, which overall pursues maximal billable hours rather than maximum cost effectiveness. This is how Java become #1 in enterprise coding. The staffers wanted the most verbose, most ponderous and spaghetti-capable language available. Those of us rebels who like to work in less popular languages purely for productivity gains of small teams, will always be aware of nice languages that are overlooked.