
Your programming language is probably unproductive - douche
http://bart-sokol.info/blog/2016/09-18-your-programming-language-is-probably-unproductive/index.html
======
gravypod
> 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.

~~~
6DM
I started a project out using jade in nodejs, after a while I had a page with
enough elements/nesting going on that I was having a hard time keeping track
of what was grouped where. Particularly when taking some work a designer did,
making it jade compliant, then pasting in.

Aside from a short "if" statement, I now no longer think it's sexy to abandon
ending notation whether it be braces, elements, etc.

~~~
gravypod
I'd suggest you not leave if statements un-braced. I remember a study where
they found the most common bug in most experienced open source developers was
leaving out the braced initially, going back to make a change, and having that
change introduce a bug.

Basically they had

    
    
       if (x)
          then()
    

and went back and did

    
    
       if (x)
          new_call()
          then()
    

and caused an error that happened silently.

This is something you definitely want to avoid and I personally don't trust
myself, after a no-sleep code fixing bender, to remember to add {} around
something if I'm editing an if. I'd probably forget.

Again, I'd say shorter does not mean better.

~~~
papaf
One way round this is to put single statement ifs on a single line:

    
    
        if (x) then();
    

If you add another statement to the if, its obvious from the indent that you
need to use braces.

~~~
petre
Yup, I _always_ do this when writing JavaScript or other languages that allow
prefix single statements with or without braces. Otherwise I use braces if the
statement is too long to fit in the editor w/o forcing you to scroll. Perl
only allows postfixed single statements w/o braces, so you're safe:

    
    
        say "yes" if $condition;
        if ($condition) {
            say "yes";
            $affirmative++;
        }

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

~~~
alec_theriault
When a person learns a language, they are making an investment of sorts - they
are saying "I think this is a language that I will invest time into learning
because ...". That "..." is usually (unfortunately) "it is becoming more
popular and I will have a competitive edge being familiar with it before
others". The bashing of other people's languages is a way of either (1)
rooting for what you're invested in or (2) reassuring yourself you made a good
investment.

------
exabrial
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.

------
jdc0589
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.

~~~
unsignedqword
I've been using a language that uses python-style indentation (Nim) and while
I've grown to like to like the language itself, the back of my mind pines for
braces. At least using braces, I can immediately auto-indent a region of code
and not have to worry about anything. I sucked it up, though, and I got used
to the pythonic syntax anyway.

Either way, opening an article that says "Your programming language is
probably unproductive" which immediately devotes itself to whining over
pedantic syntax bullshit...makes me not want to read it.

------
pjc50
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.

~~~
hackinthebochs
>what could we gain by thinking not just about making them look more like
English but more able to be read aloud?

I wouldn't be in favor of a programming language that tried to enforce
verbalizability (I'm thinking something like basic here). But I do think that
having a program "tell a story" is a boon for comprehension. Have operations,
variable names, function names, choice of where and when to use a function,
etc be in such a way to optimize the narrative quality of the code. But I
don't immediately see a way for the language construction itself to benefit
here. I think having clear structural code is a boon to quickly scanning and
understanding the structure of code.

~~~
pjc50
Mm. Taking literate programming literally. Perl certainly tried to do this,
Wall being a linguist. It resulted in things like the Perl fridge poetry set,
but it didn't _enforce_ it and also allowed a line noise style.

------
kazinator
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.

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

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

------
tscs37
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.

~~~
phyrex
There's a whole bunch of more modern lisps than Common Lisp, such as Racket
and Clojure

~~~
tscs37
I don't find either to be a very attractive alternative, Common Lisp just has
that kind of ... air around it.

Although I admit that Clojure is a decent language.

------
mamcx
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.

~~~
dllthomas
> So, I think is better in a type-static language to annotate the types, all
> the time.

I agree. ((int)((int) 5) + ((int) 5)) - ((int)2) is way clearer than 5 + 5 -
2.

~~~
mamcx
Is well understood that that apply to function/classes/types, etc.. not the
non-sense example you pick.

And by the way, a + b + c is not more clear than Int + Int + Int... or
sum(customer, products) vs. sum(Customer, ProductArray)

~~~
dllthomas
My real point was that it's a spectrum. Type information should go where it
clarifies and should not go where it obscures.

We should omit the type from intermediate expressions when (and only when!) it
will be sufficiently clear from context and it does not serve as a clearer
specification of intent than your terms. I contend that this is not a special
property of expressions.

~~~
mamcx
Then we agree ;)

------
zzzcpan
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.

~~~
emodendroket
We have a few models and they all seem to work fine.

------
yellowapple
Apparently unproductive == has curly braces.

------
FranOntanaya
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.

------
angryasian
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.

~~~
emodendroket
Arguably, braces make it harder to read code because you can have misleading
whitespace. But I mean, this is what linters and formatters are for.

------
makecheck
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.

------
jwatte
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.

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

------
chias
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.

------
wruza
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.

------
MollyR
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.

~~~
kvark
For some performance, check out the Boo language. I got hooked up on it for
quite a while. Python syntax + .Net platform and rich meta-programming = lots
of fun.

~~~
jdc0589
a couple jobs ago, for some reason we used boo, in an otherwise 100% c# .net
project, to manage our IoC/Dependency injection configuration layer.

I still have no idea why.

------
anondon
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?

~~~
virtualwhys
> What other paradigms are highly regarded among hackers?

None, but hybrid object functional languages have been on the rise in recent
years (though, like FP based languages, still very much niche). See Scala,
Ceylon, OCaml, among others.

Language functionality aside, multi-target is the next great wave. For
example, came across this today[1], pretty awesome -- compiles to server-side,
client-side, and native!

Would be quite nice to write-once run literally everywhere with a single
language, but that looks to be a couple of years off (if there are production
ready tri-target languages out there, I'd like to check them out).

[1] [https://github.com/mkotsbak/scala-native-tellstick-
example/t...](https://github.com/mkotsbak/scala-native-tellstick-
example/tree/crossProjectWithSJS)

------
aikah
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.

