3 ms·

Am I weird because I have no interest in terseness that you have to tease apart. It feels counter-productive. The programming golf (Code golf) contests and obfu

Am I weird because I have no interest in terseness that you have to tease apart. It feels counter-productive. The programming golf (Code golf) contests and obfuscated C contests just seem like a waste of time to me. The whole point of programming languages is to allow humans to produce machine code using a more natural language closer human language that we are all already fluent in.

smabie 7y ago
That's not the point of programming languages. The point of programming languages is to be more productive, it has nothing to do with natural language. In fact, natural languages are a poor fit for programming languages (see Cobol).
- ben509 7y ago
  Counterpoint: SQL is incredibly successful and its syntax uses natural language structures quite heavily. The problem Cobol has is that uses some natural structures, but then becomes very verbose because it only uses a few, and they often can't be combined, so it is very repetitive. It's not natural to say, I will buy eggs at the grocery store. And I will buy ham at the grocery store. And I will buy cheese at the grocery store. > The point of programming languages is to be more productive... But you should be productive not only in initially writing the code, but also in reading it later when you do maintenance. And what you see with most languages is extensive commentary to help future authors understand what's going on, and that's partly because terse languages tend to be cryptic.
  - strbean 7y ago
    I get anonymously downvoted to hell whenever I post this, but SQL is an absolutely awful language. Fundamental aspects like consistent representation of the same semantics in different places are missing in the very core of the language. The ubiquity of SQL generators is a sign of how little most people want to work with it, and a major reason we haven't jumped ship.
  - ken 7y ago
    In my experience, SQL is successful despite its syntax, not because of it. Wasn't it originally intended to be an end-user interface? It's failed at that. Now even programmers choose to use an ORM to insulate themselves from it. Even the programmers I know who don't use OO still use an abstraction library to avoid the need to touch SQL directly. SQL isn't even one language. It's a family of incompatible dialects. I've never written more than the most trivial SQL that would even be valid (much less the same result) on any other SQL dialect. Even though it has ISO and ANSI standards, every database in the world requires proprietary rules and conventions and extensions. How do you quote identifiers? Are strings case sensitive? Is '' the same as NULL? How do you create an index? What data types are there? We can't even agree on the most basic aspects of syntax. It's "incredibly successful" in the same way that early HTML and JS was. People wanted access to the underlying platform so badly they'll put up with a nutty design and gratuitous incompatibilities. They don't really have a choice, and many are going out of their way to build their own alternatives because the vendors won't.
- okareaman 7y ago
  I wasn't advocating programming in natural language. Much too ambiguous. I'm saying "closer" to natural language so our cognitive load is reduced reading and writing in the language so we can focus on what matters - to be more productive as you point out.
  - AnimalMuppet 7y ago
    There was an attempt to do so, so that professional programmers would be unnecessary. The result was COBOL. I don't want "close to natural language" because it's too verbose. It's like reading an article in The New Yorker - it takes so long to get anything said that you forget what the point was. Of course, "too terse" isn't the answer either. There's a sweet spot. I suspect that the sweet spot varies, depending on the person and the kind of code.
    - okareaman 7y ago
      I'm not sure why ppl are misunderstanding what I am saying. I'm not advocating COBOL-like languages. I'm saying assembler is better than writing in machine code, C is better than assembler and it would appear for most programmers, Python and JavaScript are the best choice but nobody who wants to keep their job writes code in the style of minified JavaScript or obfuscated C.
      - eggy 7y ago
        To some APL and J are the equivalent of C to assembler. It is not obfuscated, it is concise: brief but comprehensive, and easy to understand if you take the time to learn it like you would other PLs. I think Ken Iverson's "Notation as a Tool of Thought" covers this pretty well [1 PDF]. [1] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...
        okareaman 7y ago
        Thank you, that's a fascinating article and I'm going to finish reading it, but I'm ot arguing against languages that are designed to be terse and expressive to a certain mode of thought, but rather languages like JavaScript that are not designed to be terse and are deliberately made so at the cost of readability. I just don't find it interesting. It does not follow that the resulting machine code is faster or smaller, so I don't see the point beyond playing a game with language.
clarry 7y ago
I think the idea is that you learn it, and then you reap the benefits. Not much different from e.g. maths. You could figure out how to rotate a point about the origin with some haphazard application of multiplication, addition, sine, and cosine. Or you can learn you some linear algebra and then, tersely, multiply your vector with a matrix. When you learn this, you also learn the vocabulary to talk about it.. and then you have human language that you are fluent in. Maybe someone else isn't, but that's ok, you don't need to hold back and we, for sure, shouldn't hold back the entire industry just because some programmers are unwilling to graduate from goto and for loops. (I think any field would be seriously held back if we couldn't make up new concepts and extend our vocabulary) And like the symbols in math, symbols in K (and presumably other APLs) have names and a programmer who learned the language can just read a line of code out loud; it sounds quite like natural language, but probably comes closer to describing the entire solution than a corresponding read-out of the 50-line chunk of C that performs all these little steps and manipulations of temporary variables and individual array members to arrive at the same result. For similar reasons, modern programmers tend to prefer stronger abstractions like folds, maps, or function composition to achieve some terseness (and eliminate unneeded variables and manual iteration). These generally bring the solution closer to what its description in a natural language would be. After that, it gets a bit more controversial. How much whitespace do you need? How long are your identifiers going to be? How many assignments will you nest in a single expression? My experience is that it gets easier to work with terse code if you get into it, and once you're into it, it actually does save you time (in reading and writing) while more verbose style becomes irritating to work with. It's like reading an article that gets sidetracked and says a lot but doesn't ever seem to get to the point, and once it's finally over, you realize you didn't get the point because it was buried in fluff. (Fwiw, my personal style isn't quite Whitney level, but it's way more terse than what we have at work, and honestly the verbosity of work-code feels counter-productive to me.) And so, aside from my opinion about how it is to work with terse code, there's another point: making the trees smaller makes it easier to see the forest for the trees. And if you really need to study the trees (because one of them is wrong and you have a bug?), well, you can still do it (because you learned how to work with terse code). In other words, the point is actually to improve readability! It's the exact opposite of deliberate obfuscation, even if the end result might seem similar to the untrained eye. Down this thread ben509 writes that > what you see with most languages is extensive commentary to help future authors understand what's going on, and that's partly because terse languages tend to be cryptic. I'm not sure I agree. What I see with modern language developments is that they're trying to empower the programmer to make the forest smaller by eliminating the trees or making them smaller where it's feasible. We're making things higher level and more terse (but the APL family is way ahead of any mainstream language). It's the low level languages that make code seem cryptic, because you get lost in the low level details. I still work with C day to day and the actual comments in the code bases I'm involved in tend to reflect this: C forces you to deal with lots of details (trees), and it is painfully easy to see them but not see what's actually going on at a higher level (the forest). So people write comments to explain what's going on.
brudgers 7y ago
J is terse in the way regex syntax is terse. Using ”Kleene_star” doesn’t make the idea clearer so we use “*” notation. J is a notation for specifying programs. Notations allow high conceptual density with very high specificity. That’s why mathematicians use notation for communicating ideas among themselves. Natural language would be longer and no more precise. J is a tool. It’s not a likely a good replacement for Cucumber and it’s probably not a good idea to cowboy J into an operational Python codebase at a typical workplace. Rivet guns for riveting, hammers for nailing.
recursive 7y ago
> The whole point of programming languages is Next, can you tell me the point of art?
- okareaman 7y ago
  Would you be happier if I said raison d'être of programming languages?
  - recursive 7y ago
    Well, I'm also super into code golf, so I think the best I'm going to be able to do is respect your point of view. Happiness might be too far.

smabie 7y ago

That's not the point of programming languages. The point of programming languages is to be more productive, it has nothing to do with natural language. In fact, natural languages are a poor fit for programming languages (see Cobol).

ben509 7y ago
Counterpoint: SQL is incredibly successful and its syntax uses natural language structures quite heavily. The problem Cobol has is that uses some natural structures, but then becomes very verbose because it only uses a few, and they often can't be combined, so it is very repetitive. It's not natural to say, I will buy eggs at the grocery store. And I will buy ham at the grocery store. And I will buy cheese at the grocery store. > The point of programming languages is to be more productive... But you should be productive not only in initially writing the code, but also in reading it later when you do maintenance. And what you see with most languages is extensive commentary to help future authors understand what's going on, and that's partly because terse languages tend to be cryptic.
- strbean 7y ago
  I get anonymously downvoted to hell whenever I post this, but SQL is an absolutely awful language. Fundamental aspects like consistent representation of the same semantics in different places are missing in the very core of the language. The ubiquity of SQL generators is a sign of how little most people want to work with it, and a major reason we haven't jumped ship.
- ken 7y ago
  In my experience, SQL is successful despite its syntax, not because of it. Wasn't it originally intended to be an end-user interface? It's failed at that. Now even programmers choose to use an ORM to insulate themselves from it. Even the programmers I know who don't use OO still use an abstraction library to avoid the need to touch SQL directly. SQL isn't even one language. It's a family of incompatible dialects. I've never written more than the most trivial SQL that would even be valid (much less the same result) on any other SQL dialect. Even though it has ISO and ANSI standards, every database in the world requires proprietary rules and conventions and extensions. How do you quote identifiers? Are strings case sensitive? Is '' the same as NULL? How do you create an index? What data types are there? We can't even agree on the most basic aspects of syntax. It's "incredibly successful" in the same way that early HTML and JS was. People wanted access to the underlying platform so badly they'll put up with a nutty design and gratuitous incompatibilities. They don't really have a choice, and many are going out of their way to build their own alternatives because the vendors won't.
okareaman 7y ago
I wasn't advocating programming in natural language. Much too ambiguous. I'm saying "closer" to natural language so our cognitive load is reduced reading and writing in the language so we can focus on what matters - to be more productive as you point out.
- AnimalMuppet 7y ago
  There was an attempt to do so, so that professional programmers would be unnecessary. The result was COBOL. I don't want "close to natural language" because it's too verbose. It's like reading an article in The New Yorker - it takes so long to get anything said that you forget what the point was. Of course, "too terse" isn't the answer either. There's a sweet spot. I suspect that the sweet spot varies, depending on the person and the kind of code.
  - okareaman 7y ago
    I'm not sure why ppl are misunderstanding what I am saying. I'm not advocating COBOL-like languages. I'm saying assembler is better than writing in machine code, C is better than assembler and it would appear for most programmers, Python and JavaScript are the best choice but nobody who wants to keep their job writes code in the style of minified JavaScript or obfuscated C.
    - eggy 7y ago
      To some APL and J are the equivalent of C to assembler. It is not obfuscated, it is concise: brief but comprehensive, and easy to understand if you take the time to learn it like you would other PLs. I think Ken Iverson's "Notation as a Tool of Thought" covers this pretty well [1 PDF]. [1] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...
      - okareaman 7y ago
        Thank you, that's a fascinating article and I'm going to finish reading it, but I'm ot arguing against languages that are designed to be terse and expressive to a certain mode of thought, but rather languages like JavaScript that are not designed to be terse and are deliberately made so at the cost of readability. I just don't find it interesting. It does not follow that the resulting machine code is faster or smaller, so I don't see the point beyond playing a game with language.

clarry 7y ago

I think the idea is that you learn it, and then you reap the benefits. Not much different from e.g. maths. You could figure out how to rotate a point about the origin with some haphazard application of multiplication, addition, sine, and cosine. Or you can learn you some linear algebra and then, tersely, multiply your vector with a matrix. When you learn this, you also learn the vocabulary to talk about it.. and then you have human language that you are fluent in. Maybe someone else isn't, but that's ok, you don't need to hold back and we, for sure, shouldn't hold back the entire industry just because some programmers are unwilling to graduate from goto and for loops. (I think any field would be seriously held back if we couldn't make up new concepts and extend our vocabulary) And like the symbols in math, symbols in K (and presumably other APLs) have names and a programmer who learned the language can just read a line of code out loud; it sounds quite like natural language, but probably comes closer to describing the entire solution than a corresponding read-out of the 50-line chunk of C that performs all these little steps and manipulations of temporary variables and individual array members to arrive at the same result. For similar reasons, modern programmers tend to prefer stronger abstractions like folds, maps, or function composition to achieve some terseness (and eliminate unneeded variables and manual iteration). These generally bring the solution closer to what its description in a natural language would be. After that, it gets a bit more controversial. How much whitespace do you need? How long are your identifiers going to be? How many assignments will you nest in a single expression? My experience is that it gets easier to work with terse code if you get into it, and once you're into it, it actually does save you time (in reading and writing) while more verbose style becomes irritating to work with. It's like reading an article that gets sidetracked and says a lot but doesn't ever seem to get to the point, and once it's finally over, you realize you didn't get the point because it was buried in fluff. (Fwiw, my personal style isn't quite Whitney level, but it's way more terse than what we have at work, and honestly the verbosity of work-code feels counter-productive to me.) And so, aside from my opinion about how it is to work with terse code, there's another point: making the trees smaller makes it easier to see the forest for the trees. And if you really need to study the trees (because one of them is wrong and you have a bug?), well, you can still do it (because you learned how to work with terse code). In other words, the point is actually to improve readability! It's the exact opposite of deliberate obfuscation, even if the end result might seem similar to the untrained eye. Down this thread ben509 writes that > what you see with most languages is extensive commentary to help future authors understand what's going on, and that's partly because terse languages tend to be cryptic. I'm not sure I agree. What I see with modern language developments is that they're trying to empower the programmer to make the forest smaller by eliminating the trees or making them smaller where it's feasible. We're making things higher level and more terse (but the APL family is way ahead of any mainstream language). It's the low level languages that make code seem cryptic, because you get lost in the low level details. I still work with C day to day and the actual comments in the code bases I'm involved in tend to reflect this: C forces you to deal with lots of details (trees), and it is painfully easy to see them but not see what's actually going on at a higher level (the forest). So people write comments to explain what's going on.

brudgers 7y ago

J is terse in the way regex syntax is terse. Using ”Kleene_star” doesn’t make the idea clearer so we use “*” notation. J is a notation for specifying programs. Notations allow high conceptual density with very high specificity. That’s why mathematicians use notation for communicating ideas among themselves. Natural language would be longer and no more precise. J is a tool. It’s not a likely a good replacement for Cucumber and it’s probably not a good idea to cowboy J into an operational Python codebase at a typical workplace. Rivet guns for riveting, hammers for nailing.

recursive 7y ago

> The whole point of programming languages is Next, can you tell me the point of art?

okareaman 7y ago
Would you be happier if I said raison d'être of programming languages?
- recursive 7y ago
  Well, I'm also super into code golf, so I think the best I'm going to be able to do is respect your point of view. Happiness might be too far.