Why didn't Common Lisp fix the world? • Hacker News Board

Re: Why didn't Common Lisp fix the world?

#71

Post by hardworker7882 » Tue, May 17, 2016, 1:08 PM UTC

thiht wrote: post #67

kiiski wrote: post #60

Earlier quoted context omitted.

Your example is also misleading. The `a` and `expr` are written as variables in the left example, but as function calls in the Lisp version. More correctly it would be either if (a && !b) { expr } => (if (and a (not b)) expr) Or if (a() && !b) { expr() } => (if (and (a) (not b)) (expr)) Now the amount of parentheses is either 4/6 or 8/10 which is not a very big difference (and caused only by the syntactic sugar for `…

You're absolutely right, I didn't know the difference between "a" and "(a)", sorry. My point was more about the two extra parentheses for each && or ||. Imagine converting if (a && b && c && d || e) to a LISP.

I am a visible Hacker. Give me a trial. Tell me what you want me to do. It can be in our darkest secrets. I just need you to be truthful. That is the First step to make me have a deal done. I am only here to blow your mind, and Bring a smile on you..

To me, everything is possible, Tell me what you want to know about your spouse, your friend and family member, , result upgrade, bogging , spouse spy, just name it, as I will solve it. as an ex FBI secrete spy for 11 YEARS... I can change anything accessible online. I can hack into their privacy and Give you adequate output on what you are dying to know or maneuver...

My Contacts are :

Email: hack702j002d77s@gmx.us Phone number: +14437633327 ( Text me First if you want me to pick your call )

Where you are in the world does not matter. I am not a racist as I am open to every clients around the world... WHAT DO YOU WANT ME TO HACK???

As a professional hacker for hire company, we provide the best certified hackers available combined with talent and the highest level of privacy and confidentiality to our clients.

CALL ME GUARDIAN PROTECTION service includes

Change University grades Facebook, twitter,Wassap, IG hack Email hack Wipe criminal records Wipe credit card debt MasterCard's/visa cards Bank account Data base hack and lot more hacking services in general

Re: Why didn't Common Lisp fix the world?

#72

Post by DonaldFisk » Tue, May 17, 2016, 1:10 PM UTC

jordigh wrote: post #18

I'm pretty sure the biggest reason it hasn't caught on is the syntax. http://jordi.platinum.linux.pl/piccies/lisp.png It's the most frequent complaint uttered against Lisp for a reason. All of the other things mentioned in the top responses are addressed by modern Lisp variants. If Rust or Swift were implemented with sexps and everything else about them were equal, they would have a lot of difficulty winning hearts a…

The point being made in the image is that experienced Lispers don't notice the parentheses. They look at the indentation.

Lisp doesn't really have a syntax. If you want something which looks more like Python or C, you can either rewrite read, or use read macros. This has been attempted several times (Lisp 2, CGOL, Dylan), but in the end, the parentheses won.

Re: Why didn't Common Lisp fix the world?

#73

Post by chvid » Tue, May 17, 2016, 1:12 PM UTC

adwf wrote: post #66

chvid wrote: post #41

Earlier quoted context omitted.

If a language has an eval construct it is hard/impossible to reason about types, security and correctness. It also makes it hard to compile it to machine code.

That would be true if we were talking about normal languages eval'ing strings. Lisp on the other hand treats the code as data and has the full compiler available at runtime. It can check types at both runtime and compile time, and it will still compile it down to nice machine code on the fly. Lisp eval is not the same as other languages, you use it implicitly all the time. Any occurence of macros or something like `(…

Parsing Lisp is not so hard, but as you said. It requires a JIT compiler or an interpreter. There are still some platforms/scenarios where that is not wanted.

Re: Why didn't Common Lisp fix the world?

#74

Post by sklogic » Tue, May 17, 2016, 1:20 PM UTC

hga wrote: post #69

sklogic wrote: post #62

Earlier quoted context omitted.

> No. Why would you say so? There is nothing simpler than compilers. They can be broken down into pieces as small as you like which are still independent and fully sequential. Most of the rewrites you'll ever need to do can be done in a total language - i.e., you don't even need Turing-completeness for most of your code. > Any complexity? Really? I have not met a kind of complexity that cannot be decomposed into triv…

Well, one thing I can tell you is that I've heard that much of the woe that came from the Common Lisp standard started with the line "any sufficiently advanced compiler..." in a discussion.

Are we talking about optimisations now? Or still about a compilation? Optimisations are a totally different story. They can bring some complexity in, but the nice part is that they're totally optional and not required for solving the problem.

Re: Why didn't Common Lisp fix the world?

#75

Post by likeclockwork » Tue, May 17, 2016, 1:23 PM UTC

thiht wrote: post #67

kiiski wrote: post #60

Earlier quoted context omitted.

Your example is also misleading. The `a` and `expr` are written as variables in the left example, but as function calls in the Lisp version. More correctly it would be either if (a && !b) { expr } => (if (and a (not b)) expr) Or if (a() && !b) { expr() } => (if (and (a) (not b)) (expr)) Now the amount of parentheses is either 4/6 or 8/10 which is not a very big difference (and caused only by the syntactic sugar for `…

You're absolutely right, I didn't know the difference between "a" and "(a)", sorry. My point was more about the two extra parentheses for each && or ||. Imagine converting if (a && b && c && d || e) to a LISP.

    if (a && b && c && d || e) {
      doSomething();
    }

becomes

    (if (or (and a b c d) e)
      (doSomething))

It's just a little more explicit because operator associativity and precedence aren't worked out for you. (For better or for worse.)

EDIT: I think you were imagining something like this:

    (if (or (and a (and b (and c (and d)))) e)
      (doSomething))

..which is definitely not the art.

Re: Why didn't Common Lisp fix the world?

#76

Post by pjc50 » Tue, May 17, 2016, 1:27 PM UTC

sklogic wrote: post #62

pjc50 wrote: post #55

Earlier quoted context omitted.

since compilers are trivial No. and there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms Any complexity? Really?

> No. Why would you say so? There is nothing simpler than compilers. They can be broken down into pieces as small as you like which are still independent and fully sequential. Most of the rewrites you'll ever need to do can be done in a total language - i.e., you don't even need Turing-completeness for most of your code. > Any complexity? Really? I have not met a kind of complexity that cannot be decomposed into triv…

try not to confuse a size with a complexity

Before we go any further you're going to have to define complexity.

Re: Why didn't Common Lisp fix the world?

#77

Post by dunkelheit » Tue, May 17, 2016, 1:32 PM UTC

sklogic wrote: post #62

pjc50 wrote: post #55

Earlier quoted context omitted.

since compilers are trivial No. and there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms Any complexity? Really?

> No. Why would you say so? There is nothing simpler than compilers. They can be broken down into pieces as small as you like which are still independent and fully sequential. Most of the rewrites you'll ever need to do can be done in a total language - i.e., you don't even need Turing-completeness for most of your code. > Any complexity? Really? I have not met a kind of complexity that cannot be decomposed into triv…

That is a brave statement to make. How about you write a Lisp program that (serving as a perfect embodiment of "code is data" philosophy) takes another Lisp program as input and determines whether it would terminate? That would be just a handful of Lisp macros, right?

Re: Why didn't Common Lisp fix the world?

#78

Post by kiiski » Tue, May 17, 2016, 1:34 PM UTC

likeclockwork wrote: post #75

thiht wrote: post #67

Earlier quoted context omitted.

You're absolutely right, I didn't know the difference between "a" and "(a)", sorry. My point was more about the two extra parentheses for each && or ||. Imagine converting if (a && b && c && d || e) to a LISP.

if (a && b && c && d || e) { doSomething(); } becomes (if (or (and a b c d) e) (doSomething)) It's just a little more explicit because operator associativity and precedence aren't worked out for you. (For better or for worse.) EDIT: I think you were imagining something like this: (if (or (and a (and b (and c (and d)))) e) (doSomething)) ..which is definitely not the art.

Adding to this, in a real situation those variables are probably not going to be nice single letter variables. With longer names the Lisp syntax with unambiguous structure/order of precedence becomes much nicer.

  (if (or (and foobar
               (some-predicate-p quux)
               (= qwerty 432))
          (a-long-function-call-with-two-args bar ytr))
      ...)

Compared to something like:

  if (foobar &&
      somePredicate(quux) &&
      (qwerty == 432) ||
      aLongFunctionCallWithTwoArgs(bar, ytr)) {
      ...
  }

Re: Why didn't Common Lisp fix the world?

#79

Post by Grue3 » Tue, May 17, 2016, 1:35 PM UTC

keymone wrote: post #45

nabla9 wrote: post #29

Earlier quoted context omitted.

>i feel like a lot of lisps are trying to drag this "everything is a list" I think you are speaking out of ignorance here. "everything is a list" is just a metaphor. Everything is either list or atom and almost everything is atom.

> Everything is either list or atom and almost everything is atom. how can you both say this and that i'm talking out of ignorance? you're basically confirming my words. larger point i was making is that "everything is a list" abstraction/metaphor influenced the decision to not include native representation of other data structures into the language. because parens are enough to represent everything. well they aren't…

No, you're wrong. Common Lisp has hash-tables, arrays and pretty much any data structure you need. But they are not lists, they are atoms. Hence why almost everything is an atom. It's well known that linked lists are inefficient in many ways. Nobody writes programs using only lists.

Re: Why didn't Common Lisp fix the world?

#80

Post by sklogic » Tue, May 17, 2016, 1:37 PM UTC

pjc50 wrote: post #76

sklogic wrote: post #62

Earlier quoted context omitted.

> No. Why would you say so? There is nothing simpler than compilers. They can be broken down into pieces as small as you like which are still independent and fully sequential. Most of the rewrites you'll ever need to do can be done in a total language - i.e., you don't even need Turing-completeness for most of your code. > Any complexity? Really? I have not met a kind of complexity that cannot be decomposed into triv…

try not to confuse a size with a complexity Before we go any further you're going to have to define complexity.

The kind of complexity that is important for software engineering is defined by the size of the atomic modules you can get (those that cannot be broken down any further and still be practical) and number of dependencies between such modules.

This complexity defines how well the labour can be split between team members - i.e., defines the development scalability. This complexity defines how easy it is to understand any individual module and to change anything.

Of course we can start nitpicking, go into a definition of the Kolmogorov complexity and all that (but, remember, Chaitin defines this complexity with Lisp, btw.), and it will all be irrelevant to the problems of the software engineering.