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

Lisp is still a secret weapon

kep.io

Post reply on HN
Print view View original

121–130 of 145 posts

Re: Lisp is still a secret weapon

#121

Post by sklogic »

dkarapetyan wrote: post #35
agumonkey wrote: post #32

Earlier quoted context omitted.

It goes hand in hand. Back in the days people said lisp in newbies hands will be backfire, but handled by those with abstraction skills it will give you ability to express things you cannot with other systems. Many here agree that technology should not matter, but it does at one point. Some trait of the culture behind and around languages are very very important. Lisp tree recursion, "lexicality" and ad-hoc genericit…

I'm not really a programmer. All my training is in abstract math so whenever I see people arguing over language X and Y it always seems weird to me. I don't write code until I've sketched things out with pencil and paper and by necessity I have to disentagle the syntax of the language from the essence of the problem. Turns out when I do things that way translating the solution back into a language X ends up being the…

A way from your formal specification of a solution down to a particular language set of features can be enormously long.

A trivial example can be translating a formal grammar - codified as just few lines of BNF - into a low level language (say, C, or Java). Good if your grammar can be expressed as recursive descent directly, and even in this case you'll end up spitting out hundreds of lines of code, most likely making a lot stupid mistakes.

So, language does matter a lot. BNF is a right language for this task. C or Java are not right, period. Programmers should not waste their precious time translating abstract concepts down to the boring languages minutiae - they must always use the same level of abstraction as their problem domain requires.

Re: Lisp is still a secret weapon

#122

Post by sklogic »

pjmlp wrote: post #113
Scarblac wrote: post #112

Earlier quoted context omitted.

But languages differ in how much of that they abstract away from you. If the language already does a lot of those algorithms and data structures with minimal syntax, the CS guy can think on an even higher level of abstraction.

There is not much more level abstraction than lambda calculus, logic, denotational semantics and similar though processes. But I get your point of not having to deal with low level details.

You'd be surprised - there is an infinite hierarchy of abstractions above the primitive level you're talking about.

Re: Lisp is still a secret weapon

#123

Post by sklogic »

sjatkins wrote: post #74
dkarapetyan wrote: post #25

Here are some heretical thoughts. The language is irrelevant. The text editor is irrelevant. The OS is irrelevant. The size of your monitor is irrelevant. All your productivity hacks are irrelevant. The only relevant thing is your ability to formulate and solve problems. You might say the language can help with both the formulation and the solution but I'd say that just comes down to what language you're most comfort…

Heretical or not you are dead wrong. Don't think so? Go program in Forth or Assembler instead of your current main language for a while and get back to me. There would have been no reason to invent any HLL or even assembler if you were correct. Put aside your ruby and try to do the same work in vanilla C and get back to me.

Forth should not be in this list, it is a meta-language. It can be quickly turned into something equally or more powerful than you current Blub (pick any, does not matter).

Re: Lisp is still a secret weapon

#125

Post by spronkey »

noir_lord wrote: post #14
jorams wrote: post #6

The author almost immediately writes off Common Lisp for lack of "frictionless access to a rich ecosystem of code written in the same language as your software", then recommends Clojure. Most of the ecosystem you have access to in Clojure is, in fact, not built in Clojure, and most Clojure libraries were/are wrappers around Java or Javascript. Footnote 1 makes no sense, suggesting that the only way to get access to "…

That 200k figure isn't very comparable to other languages either as there are a lot of pacakages that just do a tiny thing and a hell if a lot of overlap in packages. While that's got upsides I must admit I prefer one or two relatively complete and stable packages over way more numerically but leas stable complete packages. But I come from a desktop background so I'm spoilt in that regard I guess. I view every additi…

Completely agree. Maintaining a node project is a nightmare job if you rely on any more than a trivial number of packages. The ecosystem is quicksand.

Re: Lisp is still a secret weapon

#126

Post by Per_Bothner »

jlarocco wrote: post #64

I can't believe an article about Lisp left out QuickLisp. It's the most popular Common Lisp package manager and has over 1200 open source libraries in it, and most of them are written in Common Lisp, or are bindings to native C/C++ libraries. Using libraries written in the same language you're using has a lot of advantages. Using Java libraries from a Lisp seems clunky. Also, judging solely by the number of available…

You might want to check out Kawa: http://www/gnu.org/software/kawa . It's mature (since 1996); runs on the JVM; compatible with Scheme standards (basically full R7RS except for continuations); great Java/JVM interop; trivial and flexible deployment (just a jar, unlike Clojure which assumes its own eco-system); extremely fast start-up (easily beats ABCL and Clojure); good compile-time and run-type error-reporting; and best-of-class runtime speed (comparable to Java/Scala with appropriate use of optional type specifiers).

Re: Lisp is still a secret weapon

#127

Post by TheOtherHobbes »

wpietri wrote: post #83
sjatkins wrote: post #74

Earlier quoted context omitted.

Heretical or not you are dead wrong. Don't think so? Go program in Forth or Assembler instead of your current main language for a while and get back to me. There would have been no reason to invent any HLL or even assembler if you were correct. Put aside your ruby and try to do the same work in vanilla C and get back to me.

I think you're taking his point too literally. Yes, you can find a pathological interpretation of his words and beat that up. But his point is that most of the arguments people have here over language choice are irrelevant, because whether you're using PHP or Python or Ruby or Scala or Go is not the bottleneck in the system. Personally, I agree. I've never seen a bad team succeed because of a good language, and I've…

I think that's wrong for at least some contexts, because - for example - Python is so slow that it can literally become the bottleneck on any non-toy server. So unless you're running a one-person blog or don't carDjango should probably not be your first choice for a scalable production server.

People argue about languages because they all have different trade-offs for performance/efficiency, initial development time, developer cost, developer availability, and maintenance.

The differences are real, and they have real effects on the profitability and the prospects of success/failure of any project.

Management quality and culture do too, obviously. But you can assume that for a given level of management competence, different languages will still create different business outcomes.

Re: Lisp is still a secret weapon

#128

Post by agentultra »

jwr wrote: post #96
Guthur wrote: post #91

Earlier quoted context omitted.

I too would love to know the basis of the "Modern Lisp" meme. There is very little in Clojure that has not been done before.

As a long time Common Lisper, allow me to disagree. The STM and concurrency features of Clojure are what brought me in, and they certainly haven't been "done before". Common Lisp's concurrency story was always poor. You could also argue that the effects of lazy evalutation and transducers could have been achieved before using SERIES package, but then you surely haven't tried to actually use and debug SERIES code.

> The STM and concurrency features of Clojure are what brought me in, and they certainly haven't been "done before". Common Lisp's concurrency story was always poor.

It's the JVM that does most of the work here for Clojure. You get the same features when working in Java if you wanted them.

Most CL implementations provide access to native threads and kernel polling facilities (kqueue, select, epoll, etc).

If "modern," means, "leverages the libraries and implementation of a well-funded ecosystem" then I suppose you have a point. Clojure is quite modern. And that is confusing.

> You could also argue that the effects of lazy evalutation and transducers could have been achieved before using SERIES package, but then you surely haven't tried to actually use and debug SERIES code.

I'd much rather debug CL code any day. Even at its worst it is still far ahead of Java's tracebacks and having to mentally map them back to where the error occurred in your Clojure code.

Re: Lisp is still a secret weapon

#130

Post by wpietri »

TheOtherHobbes wrote: post #127
wpietri wrote: post #83

Earlier quoted context omitted.

I think you're taking his point too literally. Yes, you can find a pathological interpretation of his words and beat that up. But his point is that most of the arguments people have here over language choice are irrelevant, because whether you're using PHP or Python or Ruby or Scala or Go is not the bottleneck in the system. Personally, I agree. I've never seen a bad team succeed because of a good language, and I've…

I think that's wrong for at least some contexts, because - for example - Python is so slow that it can literally become the bottleneck on any non-toy server. So unless you're running a one-person blog or don't carDjango should probably not be your first choice for a scalable production server. People argue about languages because they all have different trade-offs for performance/efficiency, initial development time,…

Can you give an example of a company that failed because somebody chose Python? Or even one with materially worse business results, say a 20% reduction in revenue?

My guess is no, because people make fine businesses out of nominally unscalable technologies all the time. Rails is a notorious performance pig, for example, but there are plenty of successful businesses built in it. When server bottlenecks become an issue, modest performance tricks and ops magic are applied, and suddenly per-server performance is no longer the problem. And still, despite being a pig, Rails is a great place to start, because its real power is not CPU efficiency, but ease with which you can get something workable up and then iterate.

There is no language that is so fast that it's infinitely scalable out of the box. Every software company that grows hits performance problems with naive uses of the tools at hand. Every successful one figures out how to make things work. And making technologies serve the human purpose at hand isn't a characteristic of good languages; it's a characteristic of good teams.

Post reply on HN