Live data from Hacker News

Lisp is still a secret weapon

kep.io

81–90 of 145 posts

Re: Lisp is still a secret weapon

#81

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…

> I'm not really a programmer.

The real question is do you understand how a computer works. There's mapping a solution into a programming language, but programming language is just a tool to help with the real goal which is to map the solution to the computer itself.

> The fundamental bottleneck is always what's in your head.

Expressing a correct solution in a programming language is just the first step. It also has to be performant, usable, and accessible. Language choice usually has implications in those categories.

Re: Lisp is still a secret weapon

#82
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 "…

I love Common Lisp, and as you say, there are many outstanding libraries that Quicklisp gives you easy access to. ABCL hasn't been "marketed" enough to the Java community, so it has less mind share. When I last looked at ABCL the Java interop was not as clean as Clojure's, so while it was there it felt more clunky. This was at least a year ago, so things are probably better.

I use Clojure to implement a portion of a semantic search engine: it is packaged as a REST servlet that responds to requests from a medical POC application. Because of the Java interop I utilize our internal libraries and from the ops perspective they are just deploying a WAR file that plays nicely in their reporting infrastructure.

I've been using Clojure since its first release and am comfortable with it and its ecosystem. ABCL is a contender, but I have yet to do a performance comparison, both for native and interop tests. And in reality the only part of Common Lisp I really miss is the condition system. Clojure as an implementation of CL's format and I was never a big user of loop, so...

Re: Lisp is still a secret weapon

#83

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.

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 never seen a good team fail because of a bad one. We argue over languages not because it makes or breaks companies, but because that's the most obvious feature of our days. We form tribes around languages the way non-programmers do around sports teams, and as with sports teams, minor differences get blown up into major social divisions. It's our own version of the streetlight effect: https://en.wikipedia.org/wiki/Streetlight_effect

I'm all for people arguing about language features when they are actually designing languages. But as far as building businesses around software, I think "Language X is a secret weapon" is absurd. If a good team picks something they're happy working in, then the biggest problem with a project will almost never be the language they picked.

Re: Lisp is still a secret weapon

#84
Aside, the size of the NPM database ... is that really indicative of the amount of JS code out there? For example, how many trivial modules like "isarray" are there, whose sole active code is this single line?

     return Object.prototype.toString.call(arr) == '[object Array]';
Is npm really the largest codebase, larger than PyPI, Maven and Ruby Gems?

On a more subjective level, does npm solve more nontrivial problems than any other programming language repository?

Re: Lisp is still a secret weapon

#86

Are there any examples of companies that achieved success by way of language choice other than Viaweb?

Viaweb is not even an example of that. They're a startup that succeeded while using a niche language. That's correlation, not causation, despite everything pg says.

Re: Lisp is still a secret weapon

#87

Earlier quoted context omitted.

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…

> and by necessity I have to disentangle the syntax of the language from the essence of the problem. Doing that is why programmers prefer different languages, some language allow that to be easier than others do. Some language allow a much more direct expression of the essence of the problem. > Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. Sure it does,…

In my experience, the more interesting reasons to choose languages come from the "platform and ecosystem" categories rather than syntax.

Lua: It has clean, clear syntax but its real value is the implementation, which is geared towards use as an embedded language.

Javascript: The language isn't bad but were it not for being the browser scripting language it never would have gotten so popular and tools like node.js probably wouldn't even exist.

Java: Native language on the powerful JVM.

C/C++: Direct access to various operating system and hardware libraries not available anywhere else.

Perl: Deployed widely on unix systems making it very useful for scripting and system administration.

SQL: For querying relational databases.

Granted, within each category, you might have syntax preferences. I would never use Ruby or Perl if I could use Python, for example. I prefer JSON for serialization(robust and simple) but for manually encoding a complex data structure, YAML is far more comfortable. That's all syntax. But picking the right language for a job usually requires going beyond the syntax.

Re: Lisp is still a secret weapon

#88
> Clojure hit the scene as a modern lisp that embraced the JVM.

> By now, Clojure is the de facto standard lisp for new applications.

What's with the whole, "modern," meme when people talk about Clojure? SBCL only forked off from CMU CL in 1999. Clozure CL is still well supported and actively developed. It's not like CL was written in the 1960s and had never changed ever since. The final standard was published in 1994. The alpha and beta of the JDK weren't released until a year later. Given that Clojure leverages so much of the JVM what exactly makes it the modern, de-facto standard for new applications? Don't we already have an ANSI standard for such a Lisp?

Is it modern because it can invent without restriction of a specification? That's a good thing and plenty of other Lisps are doing that... but what makes it, "modern," and why is it the standard? Is its relative immaturity a feature when you're taking on the world in a startup?

Either way it's not much of a secret anymore but I still don't see many startups advertising that they use Lisp -- even Clojure is rather rare. I hope more people give Lisp a try and kick butt.

Re: Lisp is still a secret weapon

#89

Earlier quoted context omitted.

But in some languages bloat is a best practice.

It's all about how many adjectives you can get into your class name. e.g. SingletonFactoryAdaptorFacadeProviderEnumerator myClass; With Haskell it is about how big your monad stack is StateT ReaderT WriterT LensifierT MaybeT BeerT (IO Int).

Monad stacks are so last decade.

Re: Lisp is still a secret weapon

#90

It's not secret, it's just that everybody who knows about it chooses not to use it. Additionally, the fact that it's dynamically typed probably seals its fate (which is already pretty darned sealed).

How does being dynamically typed seal it's fate?

Dynamic typing does not seem to be on the way out at all, cases in point; Javascript (everywhere), Python, Ruby to name the big ones.

Post reply on HN