8 ms·

> It's also dynamically typed which disqualifies it for large collaborative projects. I've been around the block for long enough to see how far the pendulum sw

> It's also dynamically typed which disqualifies it for large collaborative projects. I've been around the block for long enough to see how far the pendulum swings on this one. I'm guessing that it starts going the other way soon.

ballpark 5y ago
I'm not following, could you elaborate?
- varjag 5y ago
  Dynamic/static typing came in/out of fashion several times already. Any trend is temporary; neither kind of type system is a help or impediment in collaboration.
  - brundolf 5y ago
    I think it originally tanked as a backlash against how verbose and painful it was in Java and friends (as well as the limited benefits because of things like nullability) Modern static type systems are a totally different beast: inference and duck-typing cut down on noise/boilerplate, and the number of bugs that can be caught is dramatically higher thanks to maybe-types, tagged unions/exhaustiveness checking, etc. I think we've circled around to a happy best-of-both-worlds and the pendulum is settling there.
    - blacktriangle 5y ago
      Line noise is a red herring in the static/dynamic comparison. You will still run into serious problems trying to shove ugly human-generated data into your nice clean type system. For mechanical things where you the programmer are building the abstractions (compilers, operating systems, drivers) this is a non-issue, but for dealing with the ugly real world dynamic is still the way to go.
      - brundolf 5y ago
        This has not been my experience.
      - bitwize 5y ago
        Alexis King's "Parse, don't validate" is pretty much the final word on using type systems to deal with "messy real world data": https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... tl;dr when used properly, static type systems are an enormous advantage when dealing with data from the real world because you can write a total function that accepts unstructured data like a string or byte stream and returns either a successful result with a parsed data structure, a partial result, or a value that indicates failure, without having to do a separate validation step at all -- and the type system will check that all your intermediate results are correct, type-wise.
        blacktriangle 5y ago
        You're not the first, nor fourth for that matter, person to respond to dynamic typing advocation with that blog post, and it's an interesting post but it misses the whole point. The problem is not enforcing rules on data coming in and out of the system. The problem is that I have perfectly valid collections of data that I want to shove through an information processing pipeline while preserving much of the original data and static typing systems make this very powerful and legitimate task a nightmare.
        brundolf 5y ago
        They don't, though. For example: a technique I've used to work with arbitrary, unknown JSON values, is to type them as a union of primitives + arrays of json values + objects of json values. And then I can pick these values apart in a way that's totally safe while making no dangerous assumptions about their contents. Of course this opens the door for lots of potential mistakes (though runtime errors at least are impossible), but it's 100% compatible with any statically-typed language that has unions.
        rewma 5y ago
    - codr7 5y ago
      Common Lisp was on the right track with gradual typing and decent inference, which makes a nice compromise compared to jumping static hoops to wrap the problem around a more rigid language. The type declaration syntax definitely could use some love, I think it's a shame a more convenient syntax was never standardized. And sum types etc would be nice of course. It's all perfectly possible.
    - nerdponx 5y ago
      I agree with everything you said here. However, you have to consider that Common Lisp itself is quite different from other dynamically typed languages. I find that, after the initial adjustment period with the language (which is significant, I admit), it's surprisingly hard to write messy code in CL, certainly harder than in Python or Ruby. At the very least, the temptation to do so is lower, because there are fewer obstacles to expressing sophisticated ideas succinctly. And no, I am not talking about the ability to define your own macros and create DSLs. I think it has to do with the extensive selection of tools for creating short-lived local bindings, the huge selection of tools for flow control, and the strict distinction between dynamic and lexical variables. There's just something about it that sets it apart from other dynamically-typed languages, even without the gradual typing aspect and even without the speed difference. Navigating a source codebase in Python without strict type annotations is like navigating in the dark in a swamp. I don't have the same issues in Common Lisp for the most part. Maybe this has more to do with undisciplined programmers self-selecting out of CL than it has to do with any aspect of CL itself. And on top of the excellent and unique language design, you have: * A powerful CFFI * An official specification * The "REPL-driven" development style (if you want it) * Several well-maintained implementations that generate high-performance machine code * The unique condition system * Literally decades of backward compatibility * A core of stable, well-designed packages, including bindings to a lot of "foundational" libraries * Macros if you really do want to invent your own syntax or DSL Probably the only big downside is that the developer ecosystem is still focused around Emacs. That too is changing gradually but steadily, with Slyblime (SLY/SLYNK ported to Sublime Text), Slimv and Vlime (Vim ports of SLIME/SWANK), the free version of LispWorks for light-duty stuff, and at least one Jupyter kernel. Also, Roswell (like Rbenv or Pyenv) and Qlot or CLPM (like Bundler or Pipenv) help create a "project-local" dev experience that's similar to how things are done in other language ecosystems. And of course there is Quicklisp itself, which is a rock solid piece of software, and fast too! Python and Ruby have their own merits, for sure, and there are plenty of things I have in Python that I wish I had in CL. But it really doesn't seem right to compare them, CL seems like a totally different category of language.
      - varjag 5y ago
        I think the tradition of using long-descriptive-names in Common Lisp for all identifiers cements much of that experience. Using 1-3 character variable names feels natural in C but (outside of most trivial use circumstances) faux pas in Common Lisp. A better vocabulary allows for clearer formulation of nature and intent of the constructs, improving readability greatly.
  - dtech 5y ago
    Can you elaborate on that? As I see it dynamic was popular in the 90's (Python, JS, Ruby), but outside of that it's always been pretty much dynamic for scripting and static for everything else.
    - varjag 5y ago
      Consider that first Fortran (statically typed) and Lisp (dynamic) implementations date back to late 1950s. Since then there was a constant tug of war between these camps, including BASIC, COBOL, Smalltalk, Pascal, and trends falling in and out of favour. All this however is rather orthogonal to the strengths of type systems. CL type system, for instance, is stronger than one of Java or C.
    - bcrosby95 5y ago
      None of those languages were popular in the 90s.
      - brabel 5y ago
        Pearl was!
      - dragonwriter 5y ago
        > None of those languages were popular in the 90s. JS was, because browsers. Python was starting to be toward the end of the 90s. Ruby (as I understand) was in Japan though it wasn't until Rails took off that it became popular elsewhere. Perl (not on the list but similar to those on the list) definitely was.
        deleted 5y ago
        [deleted]
- deleted 5y ago
  [deleted]
kubb 5y ago
In my opinion after years in the industry, the benefits of type safety are too compelling and well known, to the point that I don't even feel like debating it. It's not a fad that will change periodically.
- deleted 5y ago
  [deleted]
- dragonwriter 5y ago
  Its a fad that has changed periodically, though I think the convergence of static and dynamically typed languages to include dynamic holes in the former and gradual typing or optional static typecheckers for the latter will continue to reduce the significance of the current state of the fad on language selection in practice. It probably won't reduce the intensity of the way a small minority of the community treats the language-level difference in holy wars, though.

ballpark 5y ago

I'm not following, could you elaborate?

varjag 5y ago
Dynamic/static typing came in/out of fashion several times already. Any trend is temporary; neither kind of type system is a help or impediment in collaboration.
- brundolf 5y ago
  I think it originally tanked as a backlash against how verbose and painful it was in Java and friends (as well as the limited benefits because of things like nullability) Modern static type systems are a totally different beast: inference and duck-typing cut down on noise/boilerplate, and the number of bugs that can be caught is dramatically higher thanks to maybe-types, tagged unions/exhaustiveness checking, etc. I think we've circled around to a happy best-of-both-worlds and the pendulum is settling there.
  - blacktriangle 5y ago
    Line noise is a red herring in the static/dynamic comparison. You will still run into serious problems trying to shove ugly human-generated data into your nice clean type system. For mechanical things where you the programmer are building the abstractions (compilers, operating systems, drivers) this is a non-issue, but for dealing with the ugly real world dynamic is still the way to go.
    - brundolf 5y ago
      This has not been my experience.
    - bitwize 5y ago
      Alexis King's "Parse, don't validate" is pretty much the final word on using type systems to deal with "messy real world data": https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... tl;dr when used properly, static type systems are an enormous advantage when dealing with data from the real world because you can write a total function that accepts unstructured data like a string or byte stream and returns either a successful result with a parsed data structure, a partial result, or a value that indicates failure, without having to do a separate validation step at all -- and the type system will check that all your intermediate results are correct, type-wise.
      - blacktriangle 5y ago
        You're not the first, nor fourth for that matter, person to respond to dynamic typing advocation with that blog post, and it's an interesting post but it misses the whole point. The problem is not enforcing rules on data coming in and out of the system. The problem is that I have perfectly valid collections of data that I want to shove through an information processing pipeline while preserving much of the original data and static typing systems make this very powerful and legitimate task a nightmare.
        brundolf 5y ago
        They don't, though. For example: a technique I've used to work with arbitrary, unknown JSON values, is to type them as a union of primitives + arrays of json values + objects of json values. And then I can pick these values apart in a way that's totally safe while making no dangerous assumptions about their contents. Of course this opens the door for lots of potential mistakes (though runtime errors at least are impossible), but it's 100% compatible with any statically-typed language that has unions.
        rewma 5y ago
  - codr7 5y ago
    Common Lisp was on the right track with gradual typing and decent inference, which makes a nice compromise compared to jumping static hoops to wrap the problem around a more rigid language. The type declaration syntax definitely could use some love, I think it's a shame a more convenient syntax was never standardized. And sum types etc would be nice of course. It's all perfectly possible.
  - nerdponx 5y ago
    I agree with everything you said here. However, you have to consider that Common Lisp itself is quite different from other dynamically typed languages. I find that, after the initial adjustment period with the language (which is significant, I admit), it's surprisingly hard to write messy code in CL, certainly harder than in Python or Ruby. At the very least, the temptation to do so is lower, because there are fewer obstacles to expressing sophisticated ideas succinctly. And no, I am not talking about the ability to define your own macros and create DSLs. I think it has to do with the extensive selection of tools for creating short-lived local bindings, the huge selection of tools for flow control, and the strict distinction between dynamic and lexical variables. There's just something about it that sets it apart from other dynamically-typed languages, even without the gradual typing aspect and even without the speed difference. Navigating a source codebase in Python without strict type annotations is like navigating in the dark in a swamp. I don't have the same issues in Common Lisp for the most part. Maybe this has more to do with undisciplined programmers self-selecting out of CL than it has to do with any aspect of CL itself. And on top of the excellent and unique language design, you have: * A powerful CFFI * An official specification * The "REPL-driven" development style (if you want it) * Several well-maintained implementations that generate high-performance machine code * The unique condition system * Literally decades of backward compatibility * A core of stable, well-designed packages, including bindings to a lot of "foundational" libraries * Macros if you really do want to invent your own syntax or DSL Probably the only big downside is that the developer ecosystem is still focused around Emacs. That too is changing gradually but steadily, with Slyblime (SLY/SLYNK ported to Sublime Text), Slimv and Vlime (Vim ports of SLIME/SWANK), the free version of LispWorks for light-duty stuff, and at least one Jupyter kernel. Also, Roswell (like Rbenv or Pyenv) and Qlot or CLPM (like Bundler or Pipenv) help create a "project-local" dev experience that's similar to how things are done in other language ecosystems. And of course there is Quicklisp itself, which is a rock solid piece of software, and fast too! Python and Ruby have their own merits, for sure, and there are plenty of things I have in Python that I wish I had in CL. But it really doesn't seem right to compare them, CL seems like a totally different category of language.
    - varjag 5y ago
      I think the tradition of using long-descriptive-names in Common Lisp for all identifiers cements much of that experience. Using 1-3 character variable names feels natural in C but (outside of most trivial use circumstances) faux pas in Common Lisp. A better vocabulary allows for clearer formulation of nature and intent of the constructs, improving readability greatly.
- dtech 5y ago
  Can you elaborate on that? As I see it dynamic was popular in the 90's (Python, JS, Ruby), but outside of that it's always been pretty much dynamic for scripting and static for everything else.
  - varjag 5y ago
    Consider that first Fortran (statically typed) and Lisp (dynamic) implementations date back to late 1950s. Since then there was a constant tug of war between these camps, including BASIC, COBOL, Smalltalk, Pascal, and trends falling in and out of favour. All this however is rather orthogonal to the strengths of type systems. CL type system, for instance, is stronger than one of Java or C.
  - bcrosby95 5y ago
    None of those languages were popular in the 90s.
    - brabel 5y ago
      Pearl was!
    - dragonwriter 5y ago
      > None of those languages were popular in the 90s. JS was, because browsers. Python was starting to be toward the end of the 90s. Ruby (as I understand) was in Japan though it wasn't until Rails took off that it became popular elsewhere. Perl (not on the list but similar to those on the list) definitely was.
      - deleted 5y ago
        [deleted]
deleted 5y ago
[deleted]

kubb 5y ago

In my opinion after years in the industry, the benefits of type safety are too compelling and well known, to the point that I don't even feel like debating it. It's not a fad that will change periodically.

deleted 5y ago
[deleted]
dragonwriter 5y ago
Its a fad that has changed periodically, though I think the convergence of static and dynamically typed languages to include dynamic holes in the former and gradual typing or optional static typecheckers for the latter will continue to reduce the significance of the current state of the fad on language selection in practice. It probably won't reduce the intensity of the way a small minority of the community treats the language-level difference in holy wars, though.