4 ms·

As an amateur coder, this really matches my journey, though with a slightly different ordering: after the usual BASIC/Perl/Python homebase, a few years really e

As an amateur coder, this really matches my journey, though with a slightly different ordering: after the usual BASIC/Perl/Python homebase, a few years really expanding my mind in Haskell-land, followed by a "well, I've bounced off Lisp in the past, let's see what I make of it now", then having real joy in writing Clojure, exploring Guile and Scheme, and then coming finally to appreciate Common Lisp, warts and all. I still "see the parentheses", and I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, but I really do enjoy working in the Lisp ecosystems now, and feel like I understand Lispers excitement at what they have.

Y_Y 3y ago
> to integrate the security that a strong typechecker can provide Have you checked out typed-racket? That's a reasonably nice way to get strong typing by tackling type correctness contracts on top of otherwise standard racket. There's also Alexis King's marvellous Hackett, which seems to be finished for now, but was positive proof that you can have - and eat - all the curry-flavoured cake you want while staying in scheme.
medo-bear 3y ago
> I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, Common lisp is optionally strongly typed. SBCL has extensive type checking facilities. Coalton is statically typed. Security does not imply strong (or static) typing, and strong typing definitely does not imply security (thinking your code is secure just because you used strong or static typing is silly). In fact code complexity that static typing introduces can have detrimental effects to overall security. Helpful starting point on state of type checking in common lisp: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html
- dannyobrien 3y ago
  Just to be clearer, I meant security as in confidence in the code running correctly, rather than defended against vulnerabilities.
  - medo-bear 3y ago
    But software correctness is orthogonal to static typing. You most def should not have the confidence that your software is correct (ie solves the practical problem you are trying to solve) just because it compiles.
  - medo-bear 3y ago
    This is from update to SBCL yesterday: enhancement: functions with declared return types have their return values type-checked in optimization regimes with high SAFETY and (DEBUG 3). http://sbcl.org/news.html http://sbcl.org/news.html
chriswarbo 3y ago
> I still "see the parentheses" The parentheses are a serialisation format; there are many alternatives using indentation, braces, infix application, etc. (e.g. those listed at http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html ). The nice thing is, s-expressions are so simple that we can usually convert between them automatically (e.g. piping our indentation-based code through an indentation-to-parentheses converter before it hits an interpreter). However, despite having all these alternative syntaxen, the fact that the vast majority of Lisp code is still written with parenthesised s-expressions tells me that it's really a non-issue :)

Y_Y 3y ago

> to integrate the security that a strong typechecker can provide Have you checked out typed-racket? That's a reasonably nice way to get strong typing by tackling type correctness contracts on top of otherwise standard racket. There's also Alexis King's marvellous Hackett, which seems to be finished for now, but was positive proof that you can have - and eat - all the curry-flavoured cake you want while staying in scheme.

medo-bear 3y ago

> I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, Common lisp is optionally strongly typed. SBCL has extensive type checking facilities. Coalton is statically typed. Security does not imply strong (or static) typing, and strong typing definitely does not imply security (thinking your code is secure just because you used strong or static typing is silly). In fact code complexity that static typing introduces can have detrimental effects to overall security. Helpful starting point on state of type checking in common lisp: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html

dannyobrien 3y ago
Just to be clearer, I meant security as in confidence in the code running correctly, rather than defended against vulnerabilities.
- medo-bear 3y ago
  But software correctness is orthogonal to static typing. You most def should not have the confidence that your software is correct (ie solves the practical problem you are trying to solve) just because it compiles.
- medo-bear 3y ago
  This is from update to SBCL yesterday: enhancement: functions with declared return types have their return values type-checked in optimization regimes with high SAFETY and (DEBUG 3). http://sbcl.org/news.html http://sbcl.org/news.html

chriswarbo 3y ago

> I still "see the parentheses" The parentheses are a serialisation format; there are many alternatives using indentation, braces, infix application, etc. (e.g. those listed at http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html ). The nice thing is, s-expressions are so simple that we can usually convert between them automatically (e.g. piping our indentation-based code through an indentation-to-parentheses converter before it hits an interpreter). However, despite having all these alternative syntaxen, the fact that the vast majority of Lisp code is still written with parenthesised s-expressions tells me that it's really a non-issue :)