5 ms·
>> because it has basically no syntax, so any program will be a direct representation of a programmer's mental model for how their program works That's actuall
by mamon 8y ago
>> because it has basically no syntax, so any program will be a direct representation of a programmer's mental model for how their program works
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.
- deleted 8y ago[deleted]
- taeric 8y agoThis is a criticism that just feels fabricated. Worse, it is all assertion, but no evidence. 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.
- guhidalg 8y agoFrom 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 agoImagine 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 agoThe 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 agoAcross 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 agoI 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.
- cultus 8y agoI think this criticism of lisp is overblown. It’s never idiomatic to introduce a macro unless you really need one. In the clojure community at least, macros are used pretty sparsely. The base language is is expressive enough.
- pharrington 8y agoMacros are only tangentally related to mamon's point.
- cultus 8y agoReally? Because apart from macros, Lisp has less syntax and little complexity compared to most languages. The issue mamon was talking about is about different programmers using different mental models or features. If macros aren't overused, this isn't nearly as big of a deal as it is for C++ or Scala. I should except common lisp here. That is indeed a complex language. But Clojure and Scheme aren't/
- zeveb 8y agoNo need to except Common Lisp here. I typically find it quite easy to understand other programmers' Common Lisp. It's not a difficult-to-understand language, and neither are macros, properly used (and they are indeed rarely improperly used).
- lispm 8y agoClojure is a different language - it borrows stuff from Lisp, but it can't run any non-trivial Lisp code from the past decades without more or less rewriting it. Even primitive stuff like math operators work differently - because Clojure mostly uses the math stack of the host language.
- pharrington 8y agoYeah. As a branch from rowang's points, humans are primed from birth to grok complex syntax and specifically leverage that syntax to ingest information streams. 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.
- taeric 8y agoRuby is famous for it's advocates claiming it is the easiest to read language. I have yet to see evidence of said claim. 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.
- ioquatix 8y agoCan you point to some examples with the properties you suggest make Ruby unreadable?
- taeric 8y agoThis implies I think it is unreadable as an intrinsic property of the language. A claim I do not understand, and I am not making. 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.
- deleted 8y ago[deleted]
- pharrington 8y agoCan you point to some specific examples with the properties you suggest make Ruby unreadable?