Your programming language is probably unproductive

> The introduction of braces in the code was a trigger for a number of religious wars, and it made us, developers, focus on the design of the language instead of focusing on the most important thing in our work - solving real problems.

How can you correctly solve problems without being able to look at your code and reason, instantly, about what is grouped together. Let alone tracing through your code but just seeing what statements are grouped with what.

One such suggestion, as provided by the author, is whitespace.

I can't tell you how bad of an idea this is. Just from a teaching perspective. I help tutor for CS100 at my university and a large part of the errors I have to deal with are whitespace errors. People don't understand where a block starts and ends. It's less key strokes but that doesn't mean it's easier or better.

> Languages like Java and C# made it to the almost ridiculous point where not only we have to be very explicit about every aspect of our code, but also made us split this code into an endless amount of files

I see no issue with splitting up a problem into multiple parts that, if sufficiently different, could be hidden from each other.

In the end, I don't think a language can be (un)productive. A language is the means for expressing a solution. Your job as a programmer is to conceive a solution to a problem and pick a language that will best let you express that problem.

Some times functional languages are better at this, some times other languages are better. The thing we should be arguing about is what is best expressed in which language.

What is it about programming that just causes people to constantly bash languages they don't use?

I think one of the most impressive things I ever saw was at a programming competition while I was in college. I was paired with a suspenders and graybeard and we needed to optimize the brute forcing of a password. He opened a hex editor and kicked out some SPARC assembly that was many times faster than what I was doing in Bash. Lesson: You can be productive anywhere.

Here's the thing when it comes to language design: Define a single way to do something. Yes, be politically incorrect and realize you might hurt some people's feelings if you make braces mandatory. Or make them close their tags on HTML. But in the end, what you're adding is simplicity: The arguments move from "you don't write code the way I do" to other more important things.

blah blah blah. clickbait title, same old complaints about language syntax that doesn't agree with someone's personal preference, etc...

Some people like braces, like me. It doesn't matter at the beginning/middle of a code block much, but the clearly visible terminating } is what does it for me. I need that.

If every whitespace significant language had strict formatting standards, shipped with a formatting utility (e.g. gofmt), and actually enforced formatting standards everywhere (including stuff like number of empty lines between functions, etc...), then I would be on board with no braces and whitespace significance. Until then, the inconsistencies you run in to in whitespace significant land just don't work for my brain.

Then, some people hate braces and love whitespace significance. Cool. doesn't matter. the end.

I program in embedded C, you don't have to tell me it's 'unproductive'. It's just convenient and familiar.

A while ago I started writing something about meter in programming languages; what could we gain by thinking not just about making them look more like English but more able to be read aloud? I didn't come to any useful conclusions, but I do note that of all the unpronouncable symbols we use the semantic whitespace of python is the most difficult to convey adequately.

Counterpoint to the remarks about braces and partial application:

Implicit partial application is a poor idea that makes programs incomprehensible. If you pass only three arguments to a four-argument function foo, you should see a "foo: insufficient arguments" error, and not a function of one argument popping out.

The semantics of obtaining a partially applied function doesn't depend on syntax. It can work fine when function arguments are delimited by parentheses. For instance, suppose that if we write (cons 3) we automatically get the equivalent of (lambda (x) (cons 3 x)). That's partial application, with parens. We can then do (mapcar (cons 0) '(1 2 3)) and get ((0 . 1) (0 . 2) (0 . 3)). Is that a good idea? Firstly, we lose variadic functions and functions with optional arguments. (list 0) can't return a lambda; it already has a meaning; (list) produces the empty list, (list x) a list of one element which is the value of x, and so on. We could end up with an embarrassing proliferation of fixed arity functions like list1, list2 and list3.

It's not that much of a chore to have an explicit partial application operator: Say:

   (op list)     -> (lambda (. args) (apply list args))

   (op list _ 1) -> (lambda (arg) (list arg 1))

If that is too verbose, and used often, we can dedicate alternative closure punctuators to it:

   {list}        ->  (op list)

   {list _ 1}    ->  (op list _ 1)

So braces now help with partial application, enabling it when we want it. The notation keeps code crystal clear because everything is delimited. We know that (op foo 1 2 3) or {foo 1 2 3} partially applies exactly three arguments to foo, no more or less, and we know that (foo 1 2 3) calls foo with exactly three arguments.

tl:dr: personal preferences about visual style in coding.

Productivity isn't a subjective quality, it's a measurable quantity. Without measurements, you're just bikeshedding.

I think we should go back to LISP/Scheme, the only language that supports whatever you want, how you want it and when you want it while still being functional.

Tho admittedly, most LISP libraries tend to strive for the same age as LISP itself, as it looks.

I don't like C-like languages. Prefer pascal/python. In delimiters think is far better "begin or do /end" than "{}", but mainly because if you have keywords like "if, while, for" then switch to symbol then switch again is "ugly". I think symbols are for data structures or math or operators, not keywords. key...WORDS. That is.

However apart for that, and also dislike the use of space and implicit type. I use F# and like it, except for how ambiguous is for a lot of things.

What is the point of have a super-strong type engine and when you look at:

let getProductById repository id

You still need to use intelli-sense or check the code as with dynamic languages? If I'm into a static typing, I wanna fully use it.

When I see:

getProductById repository id

Type inference defeat me as a user: The computer know what that is, yet, is hidden from me. Not much different than in dynamic languages. Ah, you can annotate it if want! But then you break the language convention. Is bad to let the user decide, because then everyone will decide, but different.

So, I think is better in a type-static language to annotate the types, all the time. Because that is how the language really is, and is the way to unlock the benefit of better documentation/clarity that is one of the benefits of static type.

This is my main gripe with F#/OCalm.

Also apply code require gymnastic because something is unclear in a secuence:

let result = getId code save result bla bla

When things start or end?. And F# have let fun = and let fun()= both things different. This create a compile time bomb where call some effect trigger before things are ready.

In short: have a way to group and mark blocks is great. Python is closer to how do things with space/indentation. -----

Syntax is very important. I don't dismiss it like other people that think is just "sugar".

Syntax is our user-interface. When is closer to what the language is, better.

I find this kind of logic to be a common problem among people designing programming languages. It's an interface to talk to a machine, it's not really a toy to play with. And for any good interface the goal is to make sure people have to think as little as possible, learn as little as possible new things and be able to predict behaviors easily. It doesn't matter whether you like braces or not, we have them, they are predictable, no one has to learn them again. Anything else would force thinking and learning and ultimately cannot be a better choice for decades ahead.

Apparently unproductive == has curly braces.

Placing braces in their own lines, using optional braces and not inlining short ifs are almost always styling choices, not programming language faults. The "simple example" is ridiculously biased.

I'm wondering if this guy ever had to maintain other people's code or work with a large code base. IMO readability trumps a lot of these points.

I don’t think the complaint about braces is looking at the right issue.

The issue with braces is that many languages allow multiple lines and indentation when there are no braces. If languages required you to either say "if (foo) bar()" ON ONE LINE or use braces, 99.2% of all the issues would disappear. Heck, I’d be in favor of a new C17 standard just to add this restriction.

For small programs, dynamic, runtime tag checked languages as pioneered by LISP are great environments! (Python, Ruby, JavaScript, Smalltalk, PHP, ...)

For large programs, making the computer instantly tell you where you remembered wrong is more important (like Haskell, as well as Pascal, C++, Java, C#, etc.)

By comparison, small syntactic differences fade into the background noise. This is not news.

I beg to differ, Mr. Sokol -- I use LOLCODE.

In the example provided under "White space", I find the first (9-line "bad") example significantly better than the 3-line replacement.

I can see in a fraction of a second what the first one does. The second one? 3-4 seconds to be about 85% sure I know what it's doing, and about 6-10 to be certain.

Actually his example has noise in both cases. Compare that to Lua's:

    return id > 0 and repository:get(id)

Also in C you can #define maybe(cond, ptr) ((cond)?(ptr):NULL) macro and use it everywhere.

I personally find python to be the sweet spot for me with all of its libraries and syntax. I use other languages when I need to squeeze every drop of performance from some hardware.

So functional programming seems to be the bleeding edge programming paradigm that hackers seem to agree on.

What other paradigms are highly regarded among hackers?

elegant =/= productive .

Granted F# is backed by .NET so it has access to a large existing ecosystem (on Windows) which makes it fairly productive ... once it has been learned.