[Turing_Machine]

> you can't tell whether an identifier refers to a function or variable in Scheme by sight alone

Nor in C. Nor in JavaScript. Nor in Java. Nor in...

I mean, what is "foo"? Could be the name of a function. Could be a char variable. Could be a double precision float. Could be a pointer to an array of pointers to functions returning doubles. Without going back to its definition (or prototype, for function arguments) you can't tell, much the same as you can't tell in Scheme without looking for the matching define or set!

I feel like I must be missing something here. What?

[troad]

> I feel like I must be missing something here. What?

If I were to hazard a guess at what the original poster was getting at, it might be the culture of those languages, combined with the power of Lisp to redefine its own syntax.

Lispers value concision, love higher-order functions, and love wrapping things in other things to reuse code, so you might easily see a non-trivial stretch of code without a single function call you recognise. Imagine code where the smallest chunk look something like (dq red foo '(hat n (ddl m) f)). There could be anywhere between zero and eight functions in that snippet, or any one of those might be a macro which re-orders the others in any way (or perhaps its parents include a macro, in which case you really can't assume anything about how / if this stretch is executed at all), it could be a wrapper around something that in other languages would need to be an operator (perhaps it's an if statement?), etc etc.

It's absolutely true you can shoot yourself in the foot in any language, but Lisp is unusually good for it. It's part of its power, but that power comes with a cost. Imagine talking with someone that had a proclivity for making up words. In small doses, this might be fun and save time. In larger doses, you begin losing the thread of the conversation. Lisp is sorta like that. It might seem flammorous, but before you prac it grombles, and you plink trooble blamador!

[kazinator]

> Imagine talking with someone that had a proclivity for making up words.

All software is written by making up new words. The bigger the software, the more words.

> you can shoot yourself in the foot in any language, but Lisp is unusually good for it

I've never shot myself in the foot writing Lisp, and have not heard any anecdotes about it. (Well, maybe the one about Cycorp's Cyc decades old code base being large and inscrutable.)

You're making shit up.

[troad]

> I've never shot myself in the foot writing Lisp, and have not heard any anecdotes about it. (Well, maybe the one about Cycorp's Cyc decades old code base being large and inscrutable.)

> You're making shit up.

An unnecessarily abrasive way of saying you disagree, no? Your own lived experience doesn't match mine, and therefore I must be lying? You're being irrational and mean spirited.

Lisp can't at the same time be uniquely powerful, but also no different to any other language. Lisp is a uniquely flexible language, which is one of its main strengths. Uniquely flexible languages impose a cost for readability and collaboration. You're free to disagree and insult me further, but I think this is self-apparent. Lisp's flexibility makes it a great lone wolf language (well, if you neither want access to a majority of libraries nor closeness to bare metal, which is a bit of an odd middle ground for a lone wolf), but it's awkward in organisations and collaborative contexts, where other, less flexible languages have generally overtaken it.

[lispm]

> Lisp can't at the same time be uniquely powerful, but also no different to any other language

There are lots of programming languages which are "uniquely powerful": C++, Prolog, Haskell, ...

> Lisp is a uniquely flexible language

I'm not sure if I buy "uniquely", but "very" would be fine.

> Uniquely flexible languages impose a cost for readability and collaboration.

At the same time it provides also important features for readability and collaboration. There are code bases of complex Lisp software, which are maintained by small&changing teams for several decades.

Lisp is effective not so much for "lone wolfs", but for small teams (5 to 100 people) working in a shared infrastructure with larger groups. Example: SBCL is a complex Common Lisp implementation, which goes back to the early 80s (-> Spice Lisp). SBCL is maintained by a group of people and has monthly releases. Around it there is an eco-system of software.

Simpler Lisp dialects can also be effective for larger groups. For example there are many people using "AutoLisp" (or versions of it), a simple Lisp dialect for scripting AutoCAD (and various competitors).

[troad]

Fair thoughts, all. I'm a big fan of Haskell, but I'm not without sympathy to Lisp, even if my own experience of the latter has been somewhat bumpy.

I'm curious, what are some of the important features for readability and collaboration that you mention Lisp offers?

[lispm]

Assuming Common Lisp. Many features found their way into other languages (or were provided there early, too -> for example named arguments in Smalltalk). Thus some may not look novel, but a practically used since several decades and are well integrated into the language, tools and designed for interactive usage: development, coding, extending and also reading code can be done in parallel while using the software.

It's actually very different to 'read source code and use batch compilation', from 'interactively exploring the source code and the running program at the same time'.

Relatively typical is the preference for long and descriptive names in larger software bases, with lots of documentation strings and named arguments.

* Development environments come with many introspection capabilities: describe, documentation, inspect, break, ...

* There are standard features for built in documentation strings for functions, variables, macros, classes, ...

* Macros allow very descriptive code. One can extended the language such that the constructs are very descriptive and declarative.

* Macros allow embedded domain specific code, which makes the code very readable, and gets rid of unnecessary programming details.

* Symbols can get arbitrary long and can contain arbitrary identifiers.

* Functions often have named parameters. Source code typical makes extensive use of named parameters.

* Details like manual memory management are not needed. -> code is simplified

* Many language constructs have an explicit and tight scope. -> for examples variables can't be introduced in arbitrary places in a scope.

* The language standard is very stable.

* Language extension is built-in (macros, reader, meta-object protocol, ...) and everyone uses the same mechanisms, with full language support in the extensions. -> no need tof additional and external macro processors, templating engine, XML engines, ...

* Users can more easily share/improve/collect deep language extensions, without the need to hack specific compiler implementation details, since the extension language is Lisp itself.

* Typical code is not using short identifiers or one letter identifiers with a complex operator hierarchy.

* Development is typically interactive, where one loads a program into Lisp and then one can query the Lisp system about the software (edit, who-calls, graph classes, show documentation, ...). Thus the developer does not work only with text, but can live interact and inspect the software, which is always in a debug mode.

* The code can contain examples and tests, which can be immediately tried out by a programmer while reading the code.

* There is a standardized language with widely different implementations. For collaboration it is can be very helpful that even then much of the core code can be shared, instead of having to reinvent the wheel for those different environments. The Lisp code can query the runtime and adapt itself to the implementation. Other systems have that too with an extra external configuration tools. Often it is possible for a different user that shipped source changes can be loaded into a running software. It is then immediately active and information about argument lists, documentation, class hierarchies, etc. is instantly updated.

Here is an example for a interactive definition of a function with documentation, type declarations and named arguments.

    CL-USER 12 > (defun some-example-for-hackernews (&key author to title text)

                  (declare (type symbol author to)
                           (type list text))

                  "This code is an example for Hackernews, to show off readability features."

                  (print (list author 'writes 'to to))
                  (print (list 'title 'is title))
                  (print text)

                  (values))
    SOME-EXAMPLE-FOR-HACKERNEWS

    CL-USER 13 > (some-example-for-hackernews
                  :author 'lispm
                  :to 'troad
                  :title 'lisp-features
                  :text '("example for a function with documentation, type declaration and named arguments"))

    (LISPM WRITES TO TROAD) 
    (TITLE IS LISP-FEATURES) 
    ("example for a function with documentation, type declaration and named arguments") 

    CL-USER 14 > (documentation 'some-example-for-hackernews 'function)
    "This code is an example for Hackernews, to show off readability features."

Another example: DEFCLASS is a macro for defining classes. Again, documentation and introspection is built-in. The developer does not need to read and work with dead text, but can interactively explore and try out the software, while using self-documentation features. As one can see the macro uses similar named argument lists as functions. There is a slot named WARP-CLASS and arguments for types, initialization arguments, documentation, and so on. The macro then expand this form to larger code and saves the user a lot of typing. The language can use similar mechanisms to be extend with other features, without the need to go into compiler hacking. Thus language extensions can be written and documented by users in a standard way, which greatly enhances the way how to use and understand language extensions.

    CL-USER 31 > (defclass space-ship ()

                   ((name :type 'string :initarg :name :documentation "The space ship name")
                    (warp-class :type 'number :initarg :warp-class :documentation "The warp class describes the generation of the warp propulsion system. 1 is the slowest and 5 is the fastest")
                    (warp-speed :type 'number :initform 0 :documentation "The current warp speed"))

                   (:documentation "this class describes space ships with warp propulsion"))
    #<STANDARD-CLASS SPACE-SHIP 8220381C2B>

    CL-USER 32 > (make-instance 'space-ship
                                :name "Gondor"
                                :warp-class 3)
    #<SPACE-SHIP 8010170AE3>

    CL-USER 33 > (describe *)

    #<SPACE-SHIP 8010170AE3> is a SPACE-SHIP
    NAME            "Gondor"
    WARP-CLASS      3
    WARP-SPEED      0

    CL-USER 34 > (documentation 'space-ship 'type)
    "this class describes space ships with warp propulsion"

[kazinator]

> awkward in organisations and collaborative contexts

Name three concrete anecdotes with organization names, projects and timelines.

Any language can be a "lone wolf" language. People have collaborated in making very large, well-documented projects in C. They have also made things like this:

https://www.ioccc.org/2001/herrmann2.c

a random-dot-stereogram-generating program whose source is a random-dot stereogram.

A language that doesn't let you be a Lone Wolf if you are so inclined is something that is not designed for grown ups, and not worth using if it has any alternatives at all in its space.

[troad]

Relatively banal point re Turing complete languages. You could run a space program with bash scripts if you really wanted to, doesn't make the statement "Bash scripts are not generally well suited for running a space program" less true or meaningful.

I'm honestly unsure what the point of this exchange is. Your response style seems to be to pick one sentence, seemingly at random, and launch a hyperbolic and extremely abrasive tirade against it. Which is both unpleasant and unlikely to lead to any meaningful exchange of perspectives or ideas.

[kazinator]

> Bash scripts are not generally well suited for running a space program

I completely agree. This may be more of an area that finds you on sure footing.

> What the point of this exchange is

I identify with Lisp, and take the trolling personally.