3 ms·

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 imp

by Zababa 5y ago

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 important, either for building programs, or building the libraries. Writing your own compilers may reduce that shared understanding. You can see this in some ecosystems where there is a split between people using the language in different ways (OCaml with Async and Lwt, the few alternative standard libraries; Scala with Zio, Cats, the base language; C++ with C with classes, the standard library and probably a lot of other styles that I haven't met yet; JS with the "classic JS", the frontend framework people, the functional/immutable people; many language with the FRP). Shared understanding is important for building and maintaining software. You could also argue that it's important to make programmers more replacable. Another interesting thing is that some ecosystems are getting their macros: JavaScript has Babel, Coffeescript, Typescript.

nemo1618 5y ago
> 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 by a piece of Go code again." (This has been true for me for at least 4 years.) 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! 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." :/
- pharmakom 5y ago
  I take a different view, that shared understanding comes from clear, concise code, which is not bogged down in ceremony. Lines of Go in isolation are easy to understand. However, Go is so lacking in expressiveness, that Go code-bases are hard to follow for any complex domain. The language doesn’t give you enough tools to tame complexity.
- dunefox 5y ago
  I don't want this kind of "shared understanding" if it means that I have to program in the most basic, underdeveloped language. It's the interface with the computer and used to convey meaning.
- Zababa 5y ago
  > 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.
dunefox 5y ago
This is no different from any other language lacking libraries, except that with Lisp you're using a proven, powerful language. And if you want libraries there's a python bridge and a whole CL on the JVM with interop.
medo-bear 5y ago
> 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
IshKebab 5y ago
Coffeescript, Babel and Typescript are not macros.
- Zababa 5y ago
  Macros are compilers (well, an AST pass), all of these tools are compilers. A specific transformation of Babel or Typescript or Coffeescript is a macro.

by Zababa 5y ago

nemo1618 5y ago

> 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 by a piece of Go code again." (This has been true for me for at least 4 years.) 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! 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." :/

pharmakom 5y ago
I take a different view, that shared understanding comes from clear, concise code, which is not bogged down in ceremony. Lines of Go in isolation are easy to understand. However, Go is so lacking in expressiveness, that Go code-bases are hard to follow for any complex domain. The language doesn’t give you enough tools to tame complexity.
dunefox 5y ago
I don't want this kind of "shared understanding" if it means that I have to program in the most basic, underdeveloped language. It's the interface with the computer and used to convey meaning.
Zababa 5y ago
> 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.

dunefox 5y ago

This is no different from any other language lacking libraries, except that with Lisp you're using a proven, powerful language. And if you want libraries there's a python bridge and a whole CL on the JVM with interop.

medo-bear 5y ago

> 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

IshKebab 5y ago

Coffeescript, Babel and Typescript are not macros.

Zababa 5y ago
Macros are compilers (well, an AST pass), all of these tools are compilers. A specific transformation of Babel or Typescript or Coffeescript is a macro.