4 ms·

From an engineering perspective, you're right, lisp really does give you too much power. From a linguistic perspective, isn't this the same as accents and dial

From an engineering perspective, you're right, lisp really does give you too much power. 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.

rowang 8y ago
Imagine it more like everybody is free to make their own dialect without ever having the need to actually talk that dialect with someone else. And then require that a team all with different dialect start to communicate effectively together.
- erik_seaberg 8y ago
  The team should be working in a shared domain-specific language. The good thing about Lisp is that creating a DSL isn't a painful ordeal.
  - shagie 8y ago
    Across my Java career, I've done raw servlets, struts, Spring, Stripe, and back to Spring. The vast majority of my Java knowledge transferred seamlessly from one environment to another with only minor changes ("oh, that's how its done in Stripe"). 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)?
    - taeric 8y ago
      I call bullshit. The transition you cite easily went through XML configuration to annotation based magic to modern config libraries, where largely people just stopped caring about the magic. In all, the hard part was internalizing the various life cycles. Not the silly syntactic or configuration tricks to make them happen.
    - kamaal 8y ago
      >>If each LISP team is using their own DSL 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.

rowang 8y ago

Imagine it more like everybody is free to make their own dialect without ever having the need to actually talk that dialect with someone else. And then require that a team all with different dialect start to communicate effectively together.

erik_seaberg 8y ago
The team should be working in a shared domain-specific language. The good thing about Lisp is that creating a DSL isn't a painful ordeal.
- shagie 8y ago
  Across my Java career, I've done raw servlets, struts, Spring, Stripe, and back to Spring. The vast majority of my Java knowledge transferred seamlessly from one environment to another with only minor changes ("oh, that's how its done in Stripe"). 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)?
  - taeric 8y ago
    I call bullshit. The transition you cite easily went through XML configuration to annotation based magic to modern config libraries, where largely people just stopped caring about the magic. In all, the hard part was internalizing the various life cycles. Not the silly syntactic or configuration tricks to make them happen.
  - kamaal 8y ago
    >>If each LISP team is using their own DSL 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.