101–110 of 160 posts
Earlier quoted context omitted.
Why did you feel the need to deride someone for simply expressing their opinion? Do you think it helps the discussion?
I meant no disrespect. The horse poop outside was a metaphor for side effects. During my brief exploration of Haskell, I went to great lengths to avoid dealing with side effects, and when I couldn't avoid them, the pure functional solutions were pretty painful to learn.
I don't believe you.
Earlier quoted context omitted.
You confuse powerful with popular. Many startups don't need powerful tools, other than a CRUD framework and JQuery. Also, existence and abundance of libraries is a factor, and Lisp didn't get much love from the OSS web folks til recently.
Well, no, I'm not confusing powerful and popular. I'm asking why, for all lisp's power, there's almost no examples of that power actually doing anyone any good. Is it because most projects don't need something powerful? The benefits of that power aren't actually that great compared to the rest of the lisp baggage? We have this trope of the smug lisp weenie and there's definitely a whiff of high wizardry around lisp,…
How many unsuccessful languages have multiple long-lived commercial offerings?[0][1]
Earlier quoted context omitted.
I'm biased, but there's a big difference between "learning lisp" (well enough to transliterate that python program) and really getting the code as data concept. I'd say that learning X really well is always a positive because whenever you learn something in depth you can then apply the concepts elsewhere. And there are still lisp-only concepts, so learning lisp is positive. ML is good too. Also spending time with a w…
I personally think the "code as data" concept is not so important in lisp. It is critical to writing macros, but you often don't write macros and beginners to lisp often abuse macros. I've written Clojure professionally now for a couple years and am pretty fast and proficient at it, but when I write a function call, I don't think of it as a list, even though that is what it is. I don't think any lisper does. It's jus…
I do actually think of my code as a tree/graph structure. Not just in lisps but in other languages as well, I'm always manipulating a stack of trees and thinking about how the data flows through the branches.
I'm of the opinion that there is only one lisp right now with some serious potential to dominate in the future, and that is Racket. Why? For one very simple reason: unlike all other lisps, there is serious, ongoing, and lengthy research into correctly bringing a static type-checking process to the language. Clojure's core.typed doesn't count here, as it is full of significant holes that invalidate its entire point --…
Earlier quoted context omitted.
I'm biased, but there's a big difference between "learning lisp" (well enough to transliterate that python program) and really getting the code as data concept. I'd say that learning X really well is always a positive because whenever you learn something in depth you can then apply the concepts elsewhere. And there are still lisp-only concepts, so learning lisp is positive. ML is good too. Also spending time with a w…
With Lisp I get the data thing but with ML you learn almost everything is a language. I can't really explain it but the whole variant/ADT pattern matching really forces to make you think of your problem domain as a specification or language (e.g. DSL). It is one of the reason why I think so many compilers are written in ML (that and the toolset is awesome for it).
Earlier quoted context omitted.
I meant no disrespect. The horse poop outside was a metaphor for side effects. During my brief exploration of Haskell, I went to great lengths to avoid dealing with side effects, and when I couldn't avoid them, the pure functional solutions were pretty painful to learn.
> I meant no disrespect. I don't believe you.
I'm of the opinion that there is only one lisp right now with some serious potential to dominate in the future, and that is Racket. Why? For one very simple reason: unlike all other lisps, there is serious, ongoing, and lengthy research into correctly bringing a static type-checking process to the language. Clojure's core.typed doesn't count here, as it is full of significant holes that invalidate its entire point --…
Racket could have literally the most advanced and robust type system out of all programming languages in existence, and still be used by the same amount of people as today and have a hard time convincing anyone else to use it.
What makes a language popular from what I have seen are libraries, frameworks, and community.
Edit: Racket has all of the above, so obviously there are other factors as well.
Earlier quoted context omitted.
I personally think the "code as data" concept is not so important in lisp. It is critical to writing macros, but you often don't write macros and beginners to lisp often abuse macros. I've written Clojure professionally now for a couple years and am pretty fast and proficient at it, but when I write a function call, I don't think of it as a list, even though that is what it is. I don't think any lisper does. It's jus…
With respect to Clojure, you don't write macros, but many of the really interesting language features within Clojure are built upon macros. (core.async and core.match come to mind). It would be difficult to add them without macros. I do actually think of my code as a tree/graph structure. Not just in lisps but in other languages as well, I'm always manipulating a stack of trees and thinking about how the data flows t…
That's true with any lisp. But that doesn't mean the the ability to write macros is a requirement for most development work on a daily basis, and homoiconicity is often touted as amazing specifically because of its help in writing macros. Therefore, since writing macros is not super common or necessary most of the time, I would say that "code as data" is also not a big deal most of the time.
I really like lisp, I just don't think some of its unique features are as big a deal as they advertise.
Earlier quoted context omitted.
I like Scheme/Lisp but I don't know if I buy the whole "learning Lisp turns you into a better programmer". Maybe more knowledgeable but not necessarily a better a developer. In some ways learning a really flexible language like Lisp can turn you even into a really bad developer. I say "developer" instead of "programer" because I want to emphasize working with others and thus sharing code with others. Of course this i…
There are some Lisp-related things which provide developers with new tools and new ways to think, maybe making them better: a) code as data b) interactive software development c) user-defined language extensions where the developer is part-time language designer, syntactic abstraction d) dynamic object-oriented programming e) meta-object programming
Earlier quoted context omitted.
With Lisp I get the data thing but with ML you learn almost everything is a language. I can't really explain it but the whole variant/ADT pattern matching really forces to make you think of your problem domain as a specification or language (e.g. DSL). It is one of the reason why I think so many compilers are written in ML (that and the toolset is awesome for it).
Having looked up variants just now, I can definitely see how it would be useful. It seems (to me) to fall into the same category of macro-like things that enhance the expressiveness of the language. I think the most important point is the idea of lifting the programming language into the problem domain. When you can do this in a clean way, the result is a very readable solution that you can reason about.
With Lisp macros, though, you change the syntax of Lisp. You take things that were not valid Lisp syntax, and you make them valid for your program.
So ML "language building" is in terms of semantics, but in Lisp, it's both semantics and syntax. (Again, IIUC).