That's a myth. Lisp has lots of syntax. It just works different from what one might expect. It even has user-level mechanism to implement custom syntax: Macros.

Lisp usually has a two-level syntax: s-expressions as a data-level syntax and on top of that Lisp program syntax: function calls, built-in special operators (block, catch, if, let, progn, tagbody, quote, function, ...) and macros (lots of macros).

The myth that Lisp has no syntax, comes mostly from computer science education where students learn a very simplified pure Lisp as an educational tool. Telling them Lisp has no syntax, then is the usual trick to get the students of the mental hurdle of a different - Lisp on top of s-expressions - syntax. This Lisp is then just enough to write recursive list processing functions - but has nothing to do with real programming in Lisp. Even slightly more advanced (with respect to Lisp usage) texts like SICP mostly don't use macros for syntactic extension and don't explain them.

That's actually a problem with Lisp, because every programmer would have different mental model and without some syntax rule imposing at least basic structure most of Lisp programs would be PITA to maintain by the unlucky next programmer. It also seriously limits the scale of teams of Lisp programmers (is that even a thing?), because every one of them will have their own "right way" of doing things.

By and large, what you are doing is going to dictate large parts of your tool chain. And, by and large, most people have not built tool chains in lisp. I would caution against reading any technical meaning into either of those facts.

From a linguistic perspective, isn't this the same as accents and dialects developing in isolated groups of people? We don't fault Australians for having unique vocabulary and accent, it's just a different way of speaking. Maybe the beauty of lisp is that each person gets to solve problems in the particular way they feel is most obvious, even if it's not universally accepted as being so.

I could probably switch to another team that uses something else with a different version of Java and become a contributor within a day or two of getting the environment up and running.

If each LISP team is using their own DSL, how much of that LISP knowledge transfers from one shop to another? While the overall structure of the language is the same, how much of the DSL is the same? Is it similarity of Spring to Struts (a few different annotations, all of the data structures are the same)? or is it similarity of Java to C# (different annotations, different data structures, similar syntax, a number of the Patterns shift implementation)?

Lisp already comes with several different 'DSL' built-in:

  * object-system CLOS
  * format strings with control structures
  * LOOP

  * what a the basic language extension patterns?
  * how can one debug it?
  * what a typical pitfalls?
  * what is good design?
  * how to document them?
  * how to present syntax errors to the user?

Much of the stuff in the Java-world, which has used DSLs with different syntax (like being based on XML), can be done directly in Lisp.

A Lisp team will need to learn how to deal with that. There are Lisp code-bases which have been maintained for decades. Even the SBCL compiler, which is written in Lisp, has its roots in code from the 80s (the Python compiler of CMUCL - unrelated to the later language Python).

Macros make things more complex, but the fear that macros make team programming or development of long-living code impossible is just wrong.

In all, the hard part was internalizing the various life cycles. Not the silly syntactic or configuration tricks to make them happen.

Think of it more like each team is using their own class naming and method naming schemes.

The remaining software development methodology is same, its just Lisp allows you to create very powerful abstractions and features(Syntactical by default and very definition). Anything you define for the application becomes a part of the language by default because you are writing the program as AST. And there is no syntax.

This enables you to not write things like AbstractClassFactoryFactoryAdapterMySQLDispatcherFacade. Once you have powerful enough features to express your abstractions you don't have to do boilerplate plate work writing tens(hundreds?) of classes to heavy lift simple meta-programming tasks.

A few other features that might interest you.

* Lisp ecosystem encourages you to write incremental code(Bottom up programming). Like you think about something, then go ahead and write it, often prototype in the REPL and test. So you sort of unit test by default.

* Features like Closures, Macros and higher order programming eliminate largely the need for design patterns and boiler plate heavy code.

* Code comes out short, succinct and represents the problem that is being solved. There won't be code which will be solving meta problems. Like you won't be doing opening stream, then buffers, then byte read etc for simply reading a file. In Lisp when you want to read a file, you read a file.

* As mentioned before you will write less boiler plate code for meta-programming, so no need to write hundreds of classes. At that point in time in Java you are busy solving meta problem using things like Dependency injection and frameworks for simply managing configs. In Lisp you will spend more time thinking about problems you are solving, and not meta problems you have to solve in the language, to solve application problems.

* Hot code swapping. You get great debugging facilities, where you can actually pause, introspect buggy code, swap the fix and test. You can't do this in Java.

* Given all these advantages you don't need large teams of programmers, so you communicate and build efficiently. You build big software with smaller teams. Think 10x reduction in team sizes. And that much reduction in Project management overhead, and other associated people operations.

In short If I have to tell you. In Java you think a lot of meta problems trying to work around limitations in the language using DI, annotations, frameworks etc. In Lisp you think only about the application problem.

This is the biggest development methodology change.

In programming, this is most clearly illustrated by contrasting Lisp and their ilk with Ruby. General considerations of the languages aside, Ruby's syntax is notoriously complex - yet, the language is famous for being one of, if not the most, easiest to read languages currently in use.

Sadly, I have seen the opposite. I, and most of my team, dread dealing with the Ruby package at work. Notorious for obscure tricks and terrible callback based system, where it is ridiculously easy to mess things up.

I could point to dense poetry as an example of hard to read English. Or light prose as examples of the opposite. In reality, I'd likely just be picking examples I like. Largely pivoted in the skill of the writer. Not any intrinsic feature of English.

And, ironically, it likely takes training and experience to appreciate either. Programming and writing.