5 ms·

I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys https

by lenkite 10y ago

I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang. Golang now has https://github.com/glycerine/zygomys https://github.com/glycerine/zygomys for scripting. For that matter, why would one choose Common Lisp over GNU guile ? (guile now supports fibers). What does Common Lisp offer for the working programmer that is an advantage over other languages ?

kruhft 10y ago
Stability of (most) implementations and solid language standard.
kgwgk 10y ago
You can run the code you wrote 15 years ago, and (hopefully) you will be able to run in 15 years the code you write today.
SomeHacker44 10y ago
Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.
- deleted 10y ago
  [deleted]
- jerf 10y ago
  Most of the traditional definitions of "memory safety" are not violated by having null pointers, as long as they just crash when used incorrectly. nils in Go don't let you start accessing things you shouldn't or anything. Golang is memory safe by most definitions. (Possibly not by a definition that includes concurrent memory safety. I expect in 20 or 30 years the term "memory safe" will indeed involve that. But at the moment, it doesn't, because almost no language has that right now.) This doesn't invalidate your underlying point that you want to use a language without implicit nulls... it's just the wrong terminology.
  - Zak 10y ago
    I'd put that one under type safety, and it definitely seems bizarre to me to make a new language that claims to have strong, static typing and allow arbitrary types, or pointers to arbitrary types to be null.
    - pekk 10y ago
      Pascal has null. Does that mean it is dynamically typed?
      - Zak 10y ago
        It means every type in Pascal is actually a union of itself and null.
    - jerf 10y ago
      Go's nil is statically-typed. The nil keyword is polymorphic (as numbers in the source code are) but individual nils that occur at runtime in Go are actually typed. You can actually put methods on them and they execute just fine: type S struct{} func (s *S) Test() { if s == nil { fmt.Println("Nil pointer") } else { fmt.Println("Not nil pointer") } } func main () { var p *S p.Test() } That will print "Nil pointer", not crash. While I'm actually still in agreement that I don't love a language with nil pointers, it is less bad in Go because they are less pointy and stabby. It's not like C where they are automatically a crashing offense; they are valid values treated in sensible ways in a lot more places than in C, because in Go they still have their type associated with them. But I'd still like to be able to declare a non-nillable pointer type. Please do note carefully the difference between less bad and not bad.
      - Zak 10y ago
        The type of s/p there can't be guaranteed to be (S not nil) at compile time, which is a bizarre decision in an otherwise-statically-typed language where the type system is designed to provide runtime type safety. You still have to do a null check at runtime if you want to be safe here While it's nicer that you can perform the check inside Test() instead of before the call, I don't understand why the type system doesn't just prohibit this and make you use a union type if you want (S or nil) given that a lot more situations call for (S not nil) than (S or nil).
- aidenn0 10y ago
  I don't use Go, but I thought that nulls in it were memory safe (i.e. they abort rather than corrupt); am I wrong? If I'm not wrong, this is a non-sequitor on a post about Common Lisp as Common Lisp is untyped, but (by default; some implementations allow you to disable safety) safe.
  - lokedhs 10y ago
    Technically Common Lisp is optionally typed. You can add static typing if you feel like it, and it can give you a significant performance boost when you do. Fortunately, I don't have to bother with it most of the time since the amount of code that is time-critical enough for it to matter is very small.
yarrel 10y ago
I like Go and Guile. I love Common Lisp. It's an expressive language with a powerful development environment in the form of the REPL plus Slime. I love using Lisp for exploratory programming, as it's so simple to write something that both works now and makes sense later. It has a wider range of built-in programming paradigms more fully realised than Go or guile. In comparison to CLOS, all other object systems are just kidding. Or you can program functionally or procedurally if you like. This gives you a better toolbox. It's a mature and stable environment. I can run code from 15 years ago or I can update it to use the latest libraries at my option. And I just find the regularity of the parentheses has much less of a screeching brakes effect on the experience of the code. It's smoother to read and write. So I find common Lisp a productive pleasure to use. If I was working on a project other people had to read and maintain I'd use Go, though, as it's easier to apply skills from more common languages to more quickly.
- _delirium 10y ago
  > In comparison to CLOS, all other object systems are just kidding. I almost agree, with the exception, oddly enough, of Perl (either Perl6 or Perl5+Moose). It's just about as full-featured as CLOS, complete with a usable MOP.
deleted 10y ago
[deleted]
jerf 10y ago
"I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang." Those are two very languages. Very few people would find themselves ever staring at a choice of what language to use, having narrowed it down to just those two. Lisp is notorious for its mind-expanding freedom. I think perhaps this attribute of it is less unique than it used to be, but it is still present. While I have hard time recommending it for production usage, you can still learn a lot about programming from using it for a while. It is still one of the most programmer-empowering languages there is. (Indeed, I think the vast bulk of the reason why it's not really all that great of a language and why it has never taken off is that it is too programmer empowering; it grants power the vast, vast bulk of programmers are not actually capable of handling well at scale. It makes it so that two programmers separated by some communication gap rapidly find it challenging to write code that works together. That said, deliberately spending some time in such an environment is an important step for the budding systems developer, I think.)
- lispm 10y ago
  > It makes it so that two programmers separated by some communication gap rapidly find it challenging to write code that works together. The problem is not within a team, distributed or not. That will work, even for larger teams with some guidance. It's more the application and libraries which the team produces over time. 'Syncing' them with the outside can be hard. But you'll experience that in Java applications which use large frameworks, too. Same in Javascript. This made it important to use a common Lisp standard and was the reason DARPA called for the creation of Common Lisp. Every DoD contractor brought their own Lisp dialect with their application, which made maintenance and sharing difficult and costly. The standard could have been about more, concurrency/graphics/..., but much of that was rapidly evolving technology and it made little sense at that time to create a real standard for graphics - later Lisp didn't have enough commercial backing for these things and people were moving on to simpler / more conventional languages like Java with lots of industry support.

by lenkite 10y ago

kruhft 10y ago

Stability of (most) implementations and solid language standard.

kgwgk 10y ago

You can run the code you wrote 15 years ago, and (hopefully) you will be able to run in 15 years the code you write today.

SomeHacker44 10y ago

Given a reasonable choice, I would almost never use a language like Golang that doesn't enforce memory safety (at least, by default). Null pointers, ugh.

deleted 10y ago
[deleted]
jerf 10y ago
Most of the traditional definitions of "memory safety" are not violated by having null pointers, as long as they just crash when used incorrectly. nils in Go don't let you start accessing things you shouldn't or anything. Golang is memory safe by most definitions. (Possibly not by a definition that includes concurrent memory safety. I expect in 20 or 30 years the term "memory safe" will indeed involve that. But at the moment, it doesn't, because almost no language has that right now.) This doesn't invalidate your underlying point that you want to use a language without implicit nulls... it's just the wrong terminology.
- Zak 10y ago
  I'd put that one under type safety, and it definitely seems bizarre to me to make a new language that claims to have strong, static typing and allow arbitrary types, or pointers to arbitrary types to be null.
  - pekk 10y ago
    Pascal has null. Does that mean it is dynamically typed?
    - Zak 10y ago
      It means every type in Pascal is actually a union of itself and null.
  - jerf 10y ago
    Go's nil is statically-typed. The nil keyword is polymorphic (as numbers in the source code are) but individual nils that occur at runtime in Go are actually typed. You can actually put methods on them and they execute just fine: type S struct{} func (s *S) Test() { if s == nil { fmt.Println("Nil pointer") } else { fmt.Println("Not nil pointer") } } func main () { var p *S p.Test() } That will print "Nil pointer", not crash. While I'm actually still in agreement that I don't love a language with nil pointers, it is less bad in Go because they are less pointy and stabby. It's not like C where they are automatically a crashing offense; they are valid values treated in sensible ways in a lot more places than in C, because in Go they still have their type associated with them. But I'd still like to be able to declare a non-nillable pointer type. Please do note carefully the difference between less bad and not bad.
    - Zak 10y ago
      The type of s/p there can't be guaranteed to be (S not nil) at compile time, which is a bizarre decision in an otherwise-statically-typed language where the type system is designed to provide runtime type safety. You still have to do a null check at runtime if you want to be safe here While it's nicer that you can perform the check inside Test() instead of before the call, I don't understand why the type system doesn't just prohibit this and make you use a union type if you want (S or nil) given that a lot more situations call for (S not nil) than (S or nil).
aidenn0 10y ago
I don't use Go, but I thought that nulls in it were memory safe (i.e. they abort rather than corrupt); am I wrong? If I'm not wrong, this is a non-sequitor on a post about Common Lisp as Common Lisp is untyped, but (by default; some implementations allow you to disable safety) safe.
- lokedhs 10y ago
  Technically Common Lisp is optionally typed. You can add static typing if you feel like it, and it can give you a significant performance boost when you do. Fortunately, I don't have to bother with it most of the time since the amount of code that is time-critical enough for it to matter is very small.

yarrel 10y ago

I like Go and Guile. I love Common Lisp. It's an expressive language with a powerful development environment in the form of the REPL plus Slime. I love using Lisp for exploratory programming, as it's so simple to write something that both works now and makes sense later. It has a wider range of built-in programming paradigms more fully realised than Go or guile. In comparison to CLOS, all other object systems are just kidding. Or you can program functionally or procedurally if you like. This gives you a better toolbox. It's a mature and stable environment. I can run code from 15 years ago or I can update it to use the latest libraries at my option. And I just find the regularity of the parentheses has much less of a screeching brakes effect on the experience of the code. It's smoother to read and write. So I find common Lisp a productive pleasure to use. If I was working on a project other people had to read and maintain I'd use Go, though, as it's easier to apply skills from more common languages to more quickly.

_delirium 10y ago
> In comparison to CLOS, all other object systems are just kidding. I almost agree, with the exception, oddly enough, of Perl (either Perl6 or Perl5+Moose). It's just about as full-featured as CLOS, complete with a usable MOP.

deleted 10y ago

[deleted]

jerf 10y ago

"I wish an experienced LISPer would explain why should one use Common Lisp over a language like Golang." Those are two very languages. Very few people would find themselves ever staring at a choice of what language to use, having narrowed it down to just those two. Lisp is notorious for its mind-expanding freedom. I think perhaps this attribute of it is less unique than it used to be, but it is still present. While I have hard time recommending it for production usage, you can still learn a lot about programming from using it for a while. It is still one of the most programmer-empowering languages there is. (Indeed, I think the vast bulk of the reason why it's not really all that great of a language and why it has never taken off is that it is too programmer empowering; it grants power the vast, vast bulk of programmers are not actually capable of handling well at scale. It makes it so that two programmers separated by some communication gap rapidly find it challenging to write code that works together. That said, deliberately spending some time in such an environment is an important step for the budding systems developer, I think.)

lispm 10y ago
> It makes it so that two programmers separated by some communication gap rapidly find it challenging to write code that works together. The problem is not within a team, distributed or not. That will work, even for larger teams with some guidance. It's more the application and libraries which the team produces over time. 'Syncing' them with the outside can be hard. But you'll experience that in Java applications which use large frameworks, too. Same in Javascript. This made it important to use a common Lisp standard and was the reason DARPA called for the creation of Common Lisp. Every DoD contractor brought their own Lisp dialect with their application, which made maintenance and sharing difficult and costly. The standard could have been about more, concurrency/graphics/..., but much of that was rapidly evolving technology and it made little sense at that time to create a real standard for graphics - later Lisp didn't have enough commercial backing for these things and people were moving on to simpler / more conventional languages like Java with lots of industry support.