Live data from Hacker News

Lisp is still a secret weapon

kep.io

111–120 of 145 posts

Re: Lisp is still a secret weapon

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

Seeing Common Lisp fans arguing against Clojure fans is funny since your market share combined is insignificant compared with the mainstream choices. You should learn from each other and grow that pie together. I also don't agree with you. Intuitively Lisp might be a secret weapon for startups, but not for open source where the communities of the mainstream choices are more productive, simply because of popularity. J…

  > Intuitively Lisp might be a secret weapon for startups, but not for open source 
  > where the communities of the mainstream choices are more productive, simply because
  > of popularity
Open source is not a popularity contest. In fact, open source, and specially free and libre software, is a great place for leftfield technologies to flourish. In fact, Lisp had a place in free software before Github even existed, with various flavours being the scripting language of choice in popular projects like Emacs, Gimp or Gnome.

It is rather in the proprietary corporate world where there is often resistance to adopt languages outside of the mainstream. The more supply of developers for a technology is available, the lower cost of labour. It's hard for the merits of a technology to argue against this fact in the face of management.

Re: Lisp is still a secret weapon

#112
post #99

Earlier quoted context omitted.

> but I'd say that just comes down to what language you're most comfortable with and how good of a problem solver you are. Techniques and concepts influence your ability to reason about problems. If you don't understand dictionaries (hashes), or trees, or macros, or reflection, or first class functions etc, then you will think about a problem very differently. If you understand the concepts then you can usually get a…

That's why CS matters. Anyone with a good CS background can think abstractly in terms of algorithms and data structures, instead of focusing in language X with feature list Y.

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.

Re: Lisp is still a secret weapon

#113
post #99

Earlier quoted context omitted.

That's why CS matters. Anyone with a good CS background can think abstractly in terms of algorithms and data structures, instead of focusing in language X with feature list Y.

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.

Re: Lisp is still a secret weapon

#114

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…

This works for small programs you write on your own. Even then, the kind of problems you even try to solve in Matlab are different from the ones you try to solve in JavaScript.

But in business, you often program within some framework (which makes some things easy, other things hard), glue together tons of open source libraries (what's available in different languages differs a lot), and you work on huge codebases in teams (and different languages get in your way in different ways).

Re: Lisp is still a secret weapon

#115
Flamewar in the comments here... Just throwing in my 2c.

I've been programming Clojure on the side for about a year now. It all started when I did the exercises in the Clojure for the Brave and True-book, and also simultaneously picked up Emacs and Cider (a nice IDE indeed, and keyboard-based).

Clj is just code like anything else. Anything you can do in Clojure you can do in Java. But with that language, I find myself creating things which I could not in other languages. Solutions come easier. Programs don't become long, but they get a lot done, and are performant.

I dig it, and really recommend it to anyone who is bored with their day job.

Re: Lisp is still a secret weapon

#116

Earlier quoted context omitted.

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).

So this is why the golang community prefers: for c := range(ns) { // some blah }

The golang community likes being safe:

  a, err := doFirstThing()
  if err != nil {
    return err
  }

  b, err := doSecondThing(a)
  if err != nil {
    return err
  }

  c, err := doThirdThing(b)
  if err != nil {
    return err
  }
until your keyboard keys go off.

(and I'm a happy gopher myself)

Re: Lisp is still a secret weapon

#117

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. All my training is in abstract math

Back in mainframe days, that training would've been the easiest way to get work as a programmer. Nowadays, much "programming" is gluing together pre-written open source stuff using glue languages like Bash, Javascript or Groovy by staff who entered programming as business people transferring from other departments then left a big mess for someone else to clean up when they used their embellished experience to get another job, probably with "architect" in its job title, somewhere else. If you've done any hobbyist stuff using something like Lisp or Haskell, then think twice before saying you're "not really" a programmer.

Re: Lisp is still a secret weapon

#118

But we need types people! Properly static ones that can be used to encode your intentions and handle inconsistency before even running the program. And yes I know that Clojure has an optional type system. But optional means that you cannot rely on having types in the libraries that you use. So you can't fit your stuff together with their stuff and have reasonable expectations that it will work once the user does that…

I fully agree. Without types you just can't do much, or at least, if you're super good, compiler can't do much. And most of the time you're trying to make something faster.

HackerNews, a type hating community.

Re: Lisp is still a secret weapon

#119

Earlier quoted context omitted.

Types + pattern matching -- best combination for working with trees. I'm not sure if there's a library in F# similar to HXT, but in Haskell, working with large xml structures is a breeze.

I use a pattern matcher that can match against types in Scheme, a language without static typing. Static types are just not the crucial feature that some people make them out to be. I believe this criticism of Pascal and C from SICP applies to other languages with static types (sans the pointer stuff): Pascal and C admit structures whose elements are structures. However, this requires that the programmer manipulate p…

Well, I was definitely not mentioning Pascal and C. Haskell's type system is much easier to work with.

The thing is that any operation you are using on those arguments (of which the type is none of the procedure's business) can be described by an interface which the argument implements.

You're much safer knowing in compile time that the operations you'll use will be valid, instead of hoping something doesn't crash in runtime.

Re: Lisp is still a secret weapon

#120
post #99

Earlier quoted context omitted.

> but I'd say that just comes down to what language you're most comfortable with and how good of a problem solver you are. Techniques and concepts influence your ability to reason about problems. If you don't understand dictionaries (hashes), or trees, or macros, or reflection, or first class functions etc, then you will think about a problem very differently. If you understand the concepts then you can usually get a…

That's why CS matters. Anyone with a good CS background can think abstractly in terms of algorithms and data structures, instead of focusing in language X with feature list Y.

Algorithms and data structures are on a too low level of abstraction in order to be useful in solving real world problems. Most problem domains are not expressed in terms of algorithms and data structures, they're rather formalised as languages.
Post reply on HN