News for hackers. Stuff that matters.
Re:What Made Lisp Different (2002) by Buttons840 on Sunday February 18, 2018 @06:25PM (#16409526)
I thought about it some more and I think it would go the other way too. APL has a lot of very terse array operations, but in Go you might find a mix of loops and if-statements. Translating those arbitrary combinations of loops and if-statements into APL might be very very ugly, or even impossible.

Consider assembly or basic, which use a lot of goto-statements. It can get very ugly trying to fit some arbitrary goto's into the more structured loops and if-statements we're accustomed to.

Re:What Made Lisp Different (2002) by dang on Sunday February 18, 2018 @06:45PM (#16409623)
Exactly. There's a kind of entropic arrow from higher-level to lower. Moreover the different high-level languages occupy different places in that same space. It isn't just that you can't easily translate between them. It's that they lead to different classes of system being created in the first place.
Re:What Made Lisp Different (2002) by fiddlerwoaroof on Sunday February 18, 2018 @08:49PM (#16410181)
What should be possible, though, would be to distinguish a surface-syntax from the underlying code: e.g. a language that can transparently convert to/from c-style curly brace blocks, Pascal-style begin/end and s-expressions. possibly implemented as a bunch of git hooks that transforms to a normalized representation (as, e.g. prettier does for JS) on push and transforms to the programmer's preferred representation on pull.
Re:What Made Lisp Different (2002) by dang on Monday February 19, 2018 @01:10AM (#16411071)
I suspect you'd find that what look like surface differences actually go deeper into the meanings of programs, like a plant whose roots go deeper than one would expect.
Re:What Made Lisp Different (2002) by le-mark on Monday February 19, 2018 @10:38AM (#16413470)
There's a special level of Hell that involves streaming xml processing and cobol. Since cobol lacks dynamic memory allocation (speaking of cobol 85 here) and you don't generally build things like linked lists or trees, there's a limited number of things you can conveniently do with streaming xml data. Many cobol programmers are left with a feeling of despair, I wager.

The Sapir-Whorf hypothesis is certainly real in programming languages[1].

[1] http://wiki.c2.com/?BlubParadox

Re:What Made Lisp Different (2002) by le-mark on Monday February 19, 2018 @10:30AM (#16413425)
Consider assembly or basic, which use a lot of goto-statements. It can get very ugly trying to fit some arbitrary goto's into the more structured loops and if-statements we're accustomed to.

There was a lot of work around equivalance of control flow between goto/conditional branch instructions/unconditional branch instructions and "while programs" in the 70's that showed there's actually a limited variety of control flow patterns, and while programs can be made equivalent. I think the result of this is the nowadays presence of break/continue loop constructs in most languages. Maybe this is a folk theorem, I don't recall really.

Re:What Made Lisp Different (2002) by throwaway7645 on Sunday February 18, 2018 @08:00PM (#16409988)
I think with a sufficiently advanced compiler pretty much any page of Go code would compile to a few lines of APL albeit in a different style. I have no source for this view though I can't imagine something in Go being more terse.