Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not Lisp again (2009)

funcall.blogspot.com

Post reply on HN
Print view View original

151–160 of 276 posts

Re: Not Lisp again (2009)

#151

Post by dreamcompiler »

vog wrote: post #49
ungzd wrote: post #32

Earlier quoted context omitted.

Better example would be symbolic differentiation[1][2] which requires more quirks even in modern languages[3][4] [1] https://mitpress.mit.edu/sicp/full-text/sicp/book/node39.htm... [2] https://github.com/clojure-numerics/expresso [3] http://docs.sympy.org/latest/tutorial/intro.html#a-more-inte... [4] https://github.com/yuemingl/SymJava#examples

Note that the simplistic approach doesn't scale well, as terms tend to "explode" in size and hence computation time. There is a whole sub field of mathematics / computer science called "algorithmic differentiation", also known as "automatic differentiation". The goal is to take an existing computer program and transform it into another computer program that calculates the derivatice just as efficiently (up to a const…

Exactly. I've just started exploring dual numbers which are needed for automatic differentiation [0]. It's mind-blowing stuff, and it's easy to code in Lisp.

[0] https://en.m.wikipedia.org/wiki/Dual_number

Re: Not Lisp again (2009)

#152

Post by brianberns »

lisper wrote: post #138
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

> 1 - All those parenthesis. (Still a top objection) If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.: https://github.com/rongarret/ergolib and in particular the…

>> 1 - All those parenthesis. (Still a top objection)

> If you actually count parens fairly you will find that Lisp has no more than any other language

Bull. For example, compare the Lisp factorial function from the article:

    (define (fact x)
      (if (zero? x)
          1
          (* x (fact (- x 1)))))
with the corresponding F# implementation:

    let rec fact x =
        if x = 0 then 1
        else x * fact (x - 1)
That's 7 vs. 1 pair of parens.

Also, the problem isn't just that Lisp has so many parens, but that they nest so deeply and quickly. Five nested levels of parens for factorial alone.

Re: Not Lisp again (2009)

#153

Post by oxryly1 »

pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

Using Lisp (in the form of Racket) for many years in a production environment, I've observed:

1. People do complain about the parentheses but they generally get to work dealing with them right away. It's the loudest complaint, but it doesn't really even slow people down.

2. This is a similar complaint, and does scare people off from jumping in if they have a real choice.

3. Racket in particular solves this one to an extent. We've used it with Redis, JSON, MySQL, Perforce, etc etc productively. More commentary below, though...

4. This one is a non-issue as far as I've seen. If you hire someone who can program, then can quickly learn and be productive in Lisp.

5. This is tied in with 4, a non-issue.

6. This is an issue with perception. The problem is more that people believe they know something about Lisp because they've heard of it, and they come in with the expectation that it'll be weird or difficult, which is a bit of a speed bump to getting to work right away.

Ultimately the biggest issue we've seen is that the broader ecosystem of organizations using Lisp (or Racket) in production environments is missing. As such, there are many sharp corners that you have to file off yourself as you deploy your usage. Useful resources like Stack Overflow just don't have the answers prepackaged because it's likely you're the first to use Perforce to deploy a precompiled version of your Racket application on Windows (for example).

It's easy to underestimate just how much work people have put into making ecosystems in C++, Java, and Python contain all the pieces, experience, and knowledge you'll need to solve your particular problems quickly and effectively.

Another pieced missing along with that ecosystem: outside of the implementation of the language itself, no one has taken an application of significant size and age and added a major feature to it. This is something that happens in production all the time -- and it happens on a schedule with a budget. Virtually no one using a small or academically minded languages ever does this, though. And it's not until you try that do you discover all those sharp corners and missing support tools and libraries.

Re: Not Lisp again (2009)

#154

Post by [deleted] »

smitherfield wrote: post #127
AnimalMuppet wrote: post #46

Earlier quoted context omitted.

Well, in 1992 (IIRC), I did a numerical integration in C. For a "first class function", it just took a function pointer. That approach would have been available in C in 1983...

He is right, you could do something roughly equivalent in 1983-era C, albeit a fair amount clunkier due to the lack of partial application or (any kind of) type-checking: #define DX (double)0.0001 double f_prime(f, x) register double (*f)(); double x; { return ((*f)(x + DX) - (*f)(x)) / DX; } #define DERIV(F, X) f_prime((F), (double)(X)) double cube(x) double x; { return x * x * x; } #define DERIV_CUBE(X) DERIV(cube,…

[deleted]

Re: Not Lisp again (2009)

#155

Post by AnimalMuppet »

phailhaus wrote: post #92
AnimalMuppet wrote: post #79

Earlier quoted context omitted.

OK, for the example given , I don't see how closures are relevant. I could write the exact same derivative function in C in 1983. Are you saying that in general , closures are essential to first-class functions? Or are you saying that, in the derivative example, there's something going on with closures?

Are you sure? Because in the example given, it seems that the inner function needs access to the function f

See smitherfield's examples. Yes, the inner function needs access to f. This means that it has to be passed in to the inner function. But in my view, that's not any different than (in the original example) having deriv-cube calling deriv with cube as an argument (or composing deriv and cube, if you prefer).

You may say that the difference is that in Lisp, deriv-cube is a partial application, whereas in C you really can't do that. And you'd be right. But for this example, I don't see what difference it makes.

Re: Not Lisp again (2009)

#156

Post by Chyzwar »

gedy wrote: post #130
Chyzwar wrote: post #113

Earlier quoted context omitted.

1. Lisp have less symbols than other language (defun averagenum (n1 n2 n3 n4) (/ ( + n1 n2 n3 n4) 4) ) vs function averagenum(n1, n2, n3, n4){ return (n1 + n2 + n3 + n4)/4 } Lisp 9 vs 13 JavaScript(excluding keywords and return) 2, 3 ,4 , 5, 6 -> Chicken and egg problems, Lisp is not popular enough an this makes things difficult. Lisp real issues are: 1. Fragmentation: Scheme, CL, Clojure, ELisp, Racket... 2. Tooling…

True, but the issue is that most academic and vast majority of paid coding roughly looks like the JavaScript example (C/C++/Java/JS/etc) - so to most the Lisp style looks odd and hard to parse, not the raw symbol count.

Lisp style is more elegant, almost everything is either data or function. Other languages you mention are massively more complex and difficult to understand. For me C++ is some kind of clusterfuck of symbols/keywords/operators and plain magic.

After you learn prefix notation, Lisp is super easy. Unfortunately in the world were "worse is better" we discard beautiful and smart: Smalltalk, Lisp and ML. Instead we build our towers of Babel using PHP, JavaScript and C++.

It is so ridiculous that people choose to spend whole career using PHP because it is easy learn.

Re: Not Lisp again (2009)

#157

Post by gizmo385 »

Jach wrote: post #141
icc97 wrote: post #133

Earlier quoted context omitted.

> SICP uses Scheme, which is not Lisp. Wikipedia [0]: > Scheme is a functional programming language and one of the two main dialects of the programming language Lisp. [0]: https://en.wikipedia.org/wiki/Scheme_%28programming_language...

Keyword: dialect . But Erik Naggum, 2002 [0]: > The "Lisp" Scheme is a dialect of is no longer the current meaning of "Lisp". It is somewhat like calling English a dialect of German because of ancient history that has since between invalidated by each of their separate evolution, Fahrvergnügen, Weltanschauung, Kindergarten, and Pennsylvania to the contrary notwithstanding. There is also a very limited value in talkin…

I feel like there should be a "No True LISP" fallacy in CS...

It expresses pretty much all of the core principals of a LISP. If it looks like a LISP, thinks like a LISP, behaves like a LISP; then do you really gain anything by trying to separate from other LISPs?

Re: Not Lisp again (2009)

#158

Post by davexunit »

concede_pluto wrote: post #148
davexunit wrote: post #114

Earlier quoted context omitted.

Functional programming is but one of the many paradigms that you can use in Lisp, along with imperative, object-oriented, relational, etc. When you say a language is a functional language, you are saying that it is the paradigm supported, which is not the case here.

Lisp has lots of mutable types and lots of ways to smuggle them into and out of a procedure. I'd say pure functions are tolerated but not supported. Still hard to beat for creating domain-specific languages, though, and a carefully designed DSL can rule out nondeterminism and side effects.

A language need not force purity to allow for purely functional programs. Besides, purely functional languages all need a way to cheat to actually do anything useful. Any nontrivial program needs a mix of paradigms.

Re: Not Lisp again (2009)

#159

Post by Roboprog »

brianberns wrote: post #152
lisper wrote: post #138

Earlier quoted context omitted.

> 1 - All those parenthesis. (Still a top objection) If you actually count parens fairly you will find that Lisp has no more than any other language, it's just that other languages use a mix of parens, square brackets and curly braces whereas Lisp only uses parens. Also, if you really don't like parens, you can get rid of a lot of them using macros. See e.g.: https://github.com/rongarret/ergolib and in particular the…

>> 1 - All those parenthesis. (Still a top objection) > If you actually count parens fairly you will find that Lisp has no more than any other language Bull. For example, compare the Lisp factorial function from the article: (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))))) with the corresponding F# implementation: let rec fact x = if x = 0 then 1 else x * fact (x - 1) That's 7 vs. 1 pair of parens. Also, the p…

Try putting the closing parens on a line aligned with the opening one, as if they were K&R style closing braces (ignoring that open-paren goes before keyword/func-name, rather than after)

    (define (fact x)
        (if (zero? x)
            1
            (* x (fact (- x 1)))
        )
    )
Square brackets work in some dialects, as well:

    [define (fact x)
        (if (zero? x)
            1
            (* x (fact (- x 1 ]

Re: Not Lisp again (2009)

#160

Post by Roboprog »

jacquesm wrote: post #121
pmoriarty wrote: post #6

The objections the author had way back in the day are no longer the objections programmers of mainstream languages have to Lisp today. Today the objections I hear are more along the lines of: 1 - All those parenthesis. (Still a top objection) 2 - Lisp doesn't look like or work like what I'm used to. 3 - Lisp doesn't have as many libraries as the most popular mainstream programming languages. 4 - There aren't nearly a…

To me the hard part about lisp is that every programmer that uses lisp tailors it so to their own taste that it can become quite hard to read the 'top level' of a lisp program without first having gone through all the lower layers. It is as if every project in lisp somehow magically develops its own DSL. That's a high hurdle for newbies to clear.

Fortunately, JEE & Spring are MUCH easier to get started with :-)

Let them eat COBOL...

Post reply on HN