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

Why Lisp? (2015)

blog.rongarret.info

Post reply on HN
Print view View original

101–110 of 174 posts

Re: Why Lisp? (2015)

#101

Post by dunefox »

1_player wrote: post #24
firebaze wrote: post #3

Better question: why not Lisp?

Can I be extremely shallow? Because the language feels like it's from the 60s. Like writing Fortran or Ada or Algol in 2021. C is timeless, it doesn't count. I love lisps, but Racket, for example, feels more modern than Common Lisp to me. And for shallow people like me, feel and ergonomics are very important when writing code.

> C is timeless, it doesn't count.

Of course C counts. IMO it is a language that should have stayed in the last century.

> feel and ergonomics are very important when writing code

This is the reason why I can't stomach languages like Java, C++, etc.I feel like I'm fighting a very constrained interface.

Re: Why Lisp? (2015)

#102

Post by dunefox »

spicybright wrote: post #57
1_player wrote: post #24

Earlier quoted context omitted.

Can I be extremely shallow? Because the language feels like it's from the 60s. Like writing Fortran or Ada or Algol in 2021. C is timeless, it doesn't count. I love lisps, but Racket, for example, feels more modern than Common Lisp to me. And for shallow people like me, feel and ergonomics are very important when writing code.

Could you elaborate a few specific points on this? Curious because I'm on the same boat. I was annoyed for a while how ruby convention uses '?' characters at the end of method names that return a boolean. I'm not even that old and I still want to yell `[a-zA-Z0-9_]+` identifier names or get off my lawn.

In Julia, the convention is that a function like "swap!" modifies its input. It's extremely handy. Also, "odd?" is just an elegant way to name a predicate.

Re: Why Lisp? (2015)

#103

Post by dunefox »

Zababa wrote: post #56

I think at some point we should clarify why we mean by Lisp. I see a lot of mention of Clojure, while most people seem to assume that Lisp == Common Lisp. I feel like talking about Common Lisp, Racket, Scheme, Clojure at the same time while putting them all under the "Lisp" umbrella seem to be a bit pointless when we're talking about languages. It's like mentionning JS in a conversation about C because "JS is a langu…

> It's like mentionning JS in a conversation about C

It's not. It's like mentioning C++ in a conversation about OOP which is why Lisp is the appropriate umbrella term. For me, CL means Common Lisp.

Re: Why Lisp? (2015)

#104

Post by gpderetta »

Jtsummers wrote: post #65
Zababa wrote: post #63

Earlier quoted context omitted.

I don't think this is drastically limiting, it's a sane subset that gets you 99% of what you need from a function name.

We use punctuation and symbols in typography and writing to provide clarity. Why not use it in our programs?

In fact we do, but as in typography you do not use punctuation to write words.

Then again, I really like '-' in symbol names.

Re: Why Lisp? (2015)

#105

Post by medo-bear »

Zababa wrote: post #30

That article partially validates my idea on why some people think that Lisp is such a force multiplier. The idea would be that compilers are one of the most important tool productivity-wise, and that Lisp allows you write your compilers yourself. That would also explain why not Lisp: First, libaries are the new important tool for productivity, and any language can have that. Second, a shared understanding is very imp…

> That article partially validates my idea on why some people think that Lisp is such a force multiplier. The idea would be that compilers are one of the most important tool productivity-wise, and that Lisp allows you write your compilers yourself

This is a huge selling point for me personally. lisps allows you to have a solution AND its compiler in lisp, without a need for another language. As far as I know Common Lisp is the only industrial strength dialect of lisp to allow this, and with an unmatched interactive development environment

> Shared understanding is important for building and maintaining software. You could also argue that it's important to make programmers more replaceable

in a business sense, if i wanted to hire for a large team of 'developers' i would hire for java / python / js. if i wanted to hire for a small team of 'hackers' i would hire for common lisp / haskell

Re: Why Lisp? (2015)

#106

Post by medo-bear »

gaze wrote: post #69

Why does it feel like there’s more prose about lisp being written than lisp code? I swear there’s like 15 people writing Common Lisp — Nikodemus, Shirakumo, Stylewarning, Christian Schafmeister, Borodust, the ITA folks, and maybe 2 startups.

i am new to lisp in general and common lisp in particular. i will tell you the key reason why i will take my time to promote it on hn. for years i had large misconceptions about lisp: it is slow (in my case for numerical work), it is an academic language, the syntax is ugly unnatural and annoying. it was only by chance that i was (quite happily) proven completely wrong. so my rationale is that if there are people who are like i was then i will be happy to provide information about common lisp and perhaps something useful might come out of it

Re: Why Lisp? (2015)

#107

Post by Zababa »

Jtsummers wrote: post #68
Zababa wrote: post #66

Earlier quoted context omitted.

Programs? Aren't we talking about variable and function names? But for the general case, Lisp does use puncuation and symbols. It just tends to use less. The other side of the balance is operators like ~+#>. Most languages are in the middle ground. All of these options are fine and have their uses. I wouldn't like to see stuff like ~+#> every day, but I like being able to implement <.

Programs are composed of those things.

Sure, but you don't use a lot of punctuation in identifier names. For example, in JS:

    function sumOfArray(arr) {
        return arr.reduce((sum, element) => sum + element, 0)
    }
Now in Scheme:

    (define (sum-of-list lst)
        (reduce + 0 lst))
Both have punctuation, but usually not in the identifiers (except for - and _)

Re: Why Lisp? (2015)

#108

Post by tincholio »

Zababa wrote: post #33
Mikeb85 wrote: post #19

Earlier quoted context omitted.

> Getting Lisp to run as fast as C takes major effort when at all possible. But Lisp is faster than almost every widely used language that's not C/C++/Rust, around Java speed. > Lisp needs a lot of space to do it's thing; and while it's certainly possible to downsize it, you're left with something that's not really Lisp anymore Dunno, by modern standards it seems pretty small. > Finding solid libraries is tricky sinc…

> There's code out there for most use cases, at least for back-end-y things. I'm not sure about that. These days in the backend you need a lot of libraries for cloud providers and new databases/services. For example, is there a Common Lisp library for AWS/Azure/Google cloud? Is there one for Clickhouse?

Related to this, there's an AWS SDK for Clojure [0] (created by the same people who are behind Clojure), which is generated from the AWS specs themselves. Carmine, a popular Clojure library for Redis does something very similar. There's also a library for generating SDKs from Swagger specs [2]. I implemented a similar solution (generating Python bindings for some of our APIs from Postman exports), and it was super simple, really.

I suspect doing the same in CL would be similarly simple.

[0] https://github.com/cognitect-labs/aws-api

[1] https://github.com/ptaoussanis/carmine

[2] https://github.com/oliyh/martian

Re: Why Lisp? (2015)

#109

Post by medo-bear »

tmm84 wrote: post #70
pddpro wrote: post #62

I started my programming in the more "traditional" way i.e., C/C++ and then later python. When I started doing python, I was flabbergasted to find that I could just do 100**100 and get a complete number without using any additional libraries. Similarly, reversing string was trivial using the [::-1] notation. Heterogeneity of Lists, Dictionaries and the resulting versatility blew my mind. I now understand that I was d…

Simple digestable examples that show off power is kind of a cart before horse situation. However, I will try to feed your curiosity. One simple example I can describe is from the book Practical Common Lisp and it is talked about to some degree in the SICP videos. The idea of the environment being captured as well as what it points to is a big idea. At the risk of not getting it explained 100% to everyone's satisfacti…

i think PAIP is an absolute gem! not just for learning lisp, but for software engineering in general. not only that but you can read it online in .md format with proper syntax highlighting, which provides for a much better experience. and in fact not only even that (!!), but if you use org-mode you can convert .md files to .org files flawlessly via pandoc and enjoy the whole experience interactively (like jupyter notebook, but only on a whole different leve)

useful link:

https://github.com/norvig/paip-lisp

https://orgmode.org/

https://emacs.stackexchange.com/questions/5465/how-to-migrat...

Re: Why Lisp? (2015)

#110

Post by Zababa »

nemo1618 wrote: post #81
Zababa wrote: post #30

That article partially validates my idea on why some people think that Lisp is such a force multiplier. The idea would be that compilers are one of the most important tool productivity-wise, and that Lisp allows you write your compilers yourself. That would also explain why not Lisp: First, libaries are the new important tool for productivity, and any language can have that. Second, a shared understanding is very imp…

> Shared understanding is important for building and maintaining software. I think this is where Go (the language) really shines. Go is "boring" -- there are no macros, no operator overloading, no default arguments, none of that sort of thing. But if your goal is shared understanding, "boring" is a compliment. "Boring" means "after using the language for a few years, I can be confident that I will never be surprised…

> I think this is where Go (the language) really shines. Go is "boring" -- there are no macros, no operator overloading, no default arguments, none of that sort of thing. But if your goal is shared understanding, "boring" is a compliment.

I think one of the most important points is the standard library rather than macros, operator overloading, default arguments and details like that. What makes a simple Go http server easier to understand than one in pretty much every other language is that most of the time it will be from the standard library. With Python, Java, C++, C#, Ruby, JS, TS, Kotlin, C and pretty much everything else, you're going to have to understand a framework/library first.

> "Boring" means "after using the language for a few years, I can be confident that I will never be surprised by a piece of Go code again." (This has been true for me for at least 4 years.)

That's a good definition, and whether you consider this good or bad is a great way to know if you will like Go.

> In the same vein, Go famously doesn't support user-defined generics; the only generics it has are reified "builtins," baked into the language. People gripe about that, but the upshot is that every Go programmer understands the semantics of those builtin functions. They're Schelling points!

User-defined generics are one point, no support for inheritance is another, almost no iterators is still another, no support for map/reduce/filter or list comprehensions is probably still another, one way of doing concurrency is again another, no support for FP is another.

> When user-defined generics are added in the next version of Go, I worry that we'll lose some shared understanding. It will be a subtle shift, but the language will feel a bit less "cozy." :/

I can see why. Right now I would love to add a custom < operator to a JS codebase, I can't, and it's a bit frustrating. But on the other hand, I'm a bit glad other people can't add it too. Some people will call this humility, some others will call it a race to the bottom. Maybe there's something to say about optimising for your "best" days or your "worst" days.

Post reply on HN