5 ms·
I do think LISP remains the major language that can encompass the strange loop idea he explored in his work. I know LISP is not the only homoiconic language, b
by taeric 2y ago
I do think LISP remains the major language that can encompass the strange loop idea he explored in his work. I know LISP is not the only homoiconic language, but it is the biggest that people know how to use where the "eval" function doesn't take in a string that has to be parsed.
I hate that people are convinced LISP == functional programming, writ large. Not that I dislike functional programming, but the symbolic nature of it is far more interesting to me. And it amuses me to no end that I can easily make a section of code that is driven by (go tag) sections, such that I can get GOTO programming in it very easily.
- nine_k 2y agoAnother (properly functional) homoiconic language that enjoyed mainstream adoption briefly in '00s is XSLT. Its metaprogramming features were rather widely used, that is, producing an XSLT from XSLT and maybe some more XML, instead of hand-coding something repetitive, was rather normal. The syntax was a bigger problem than Lisp's syntax, though. It's not easy to produce a language with a syntax that's good as daily use syntax, but is also not unwieldy as an AST. Lisp is one of the few relatively successful examples.
- AnimalMuppet 2y ago> The syntax was a bigger problem than Lisp's syntax, though. Yeah. XML and S expressions are pretty close to functionally equivalent. But once you've seen S expressions, XML is disgustingly clumsy.
- nine_k 2y agoSGML was intended for sparse markup in mostly plaintext files. From it grew HTML that is markup-heavy, and XML which is often 100% markup. What made sense for rare markup nodes became... suboptimal when applied in a very different role.
- jll29 2y ago1. GML => SGML => XML 2. rm * 3. JSON 4. rm -rf /
- pfdietz 2y ago"Any data can be turned into Big Data by encoding it in XML."
- fuzztester 2y agoWow. Also: XML: eXtremely Murky Language or Mindblowing
- chubot 2y agoThey have a different model -- one is better for documents, and one is better for programs/data XML and HTML are attributed text, while S-expressions are more like a homogeneous tree If you have more text than metadata, then they are more natural than S-expressions e.g. The closing </p> may seem redundant, until you have big paragraphs of free form text, which you generally don't in programs
- apex_sloth 2y agoThanks for this little flashback to when I had to write XSLT for apache cocoon as my student job
- pmarreck 2y agoI don't know how many other languages use it but I've long admired Elixir's approach to giving devs access to the AST using its basic types in order to write macros: https://hexdocs.pm/elixir/macros.html https://hexdocs.pm/elixir/macros.html It is certainly possible to implement this sort of thing in other languages, I think, depending on the compilation or preprocessing setup
- medo-bear 2y agoPossible doesnt mean "requires same ammount of effort"
- pmarreck 2y agoThat's fair. I think it's a big win, though. Macros, when the situation calls for it, are amazing. For example, I believe most of the UTF8 handling code in Elixir was done via macros which brought down the amount of code that had to be maintained by quite a bit.
- pjmlp 2y agoFor a while that is how I made my Website dynamic, by writing everything in XML and linking XSLT stylesheets, however the future ended up not being XHTML, and eventually I rewrote those stylesheets in PHP. Doesn't win any price, or content worth of "I rewrote X in Y" blogpost, but does the job.
- throwaway19972 2y agoNot to mention specifically with Scheme and continuation-oriented programming, the line between functional and non-functional programming becomes so blurry as to become nearly meaningless.
- brucehoult 2y agoLambda: the ultimate GOTO
- fuzztester 2y agoThe definition of functional programming is itself quite blurry, says Chris Lattner (of Swift, LLVM, Mojo), in this talk I posted here recently: https://news.ycombinator.com/item?id=41822811 https://news.ycombinator.com/item?id=41822811
- medo-bear 2y agoEven the definition of a lisp is blurry when we zoom in to find the seperation boundry
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- bbor 2y agoI love and relate to any impassioned plea on SWE esoterica, so this seems like as good of a place as any to ask: What, in practice, is this deep level of "homoiconic" or "symbolic" support used for that Python's functools (https://docs.python.org/3/library/functools.html https://docs.python.org/3/library/functools.html) doesn't do well? As someone building a completely LISPless symbolic AGI (sacrilege, I know), I've always struggled with this and would love any pointers the experts here have. Is it something to do with Monads? I never did understand Monads... To make this comment more actionable, my understanding of Python's homoiconic functionality comes down to these methods, more-or-less: 1. Functions that apply other functions to iterables, e.g. filter(), map(), and reduce(). AKA the bread-n-butter of modern day JavaScript. 2. Functions that wrap a group of functions and routes calls accordingly, e.g. @singledispatch. 3. Functions that provide more general control flow or performance conveniences for other functions, e.g. @cache and and partial(). 3. Functions that arbitrarily wrap other functions, namely wraps(). Certainly not every language has all these defined in a standard library, but none of them seem that challenging to implement by hand when necessary -- in other words, they basically come down to conviences for calling functions in weird ways. Certainly none of these live up to the glorious descriptions of homoiconic languages in essays like this one, where "self-introspection" is treated as a first class concern. What would a programmer in 2024 get from LISP that isn't implemented above?
- taeric 2y agoI'm basically a shill for my one decent blog post from a while back. :D https://taeric.github.io/CodeAsData.html https://taeric.github.io/CodeAsData.html The key for me really is in the signature for "eval." In python, as an example, eval takes in a string. So, to work with the expression, it has to fully parse it with all of the danger that takes in. For lisp, eval takes in a form. Still dangerous to evaluate random code, mind. But you can walk the code without evaluating it.
- bbor 2y agoHackerNews sadly never fails to disappoint. Thanks for taking the time to share, that was exactly what I was looking for! Would endorse this link for any lurkers. The LISP (elisp?) syntax itself gives me a headache to parse so I think I'll stay away for now, but I'll definitely be thinking about how to build similar functionality into my high level application code -- self modification is naturally a big part of any decent AGI project. At the risk of speaking the obvious, the last sentence was what drove it home for me: It is not just some opaque string that gets to enjoy all of the benefits of your language. It is a first class list of elements that you can inspect and have fun with. I'm already working with LLM-centric "grammars" representing sets of standpoint-specific functions ("pipelines"), but so far I've only been thinking about how to construct, modify, and employ them. Intelligently composing them feels like quite an interesting rabbit hole... Especially since they mostly consist of prose in minimally-symbolic wrappers, which are probably a lot easier for an engineer to mentally model--human or otherwise. Reminds me of the words of wonderful diehard LISP-a-holic Marvin Minsky: The future work of mind design will not be much like what we do today. ...what we know as programming will change its character entirely-to an activity that I envision to be more like sculpturing. To program today, we must describe things very carefully because nowhere is there any margin for error. But once we have modules that know how to learn, we won’t have to specify nearly so much-and we’ll program on a grander scale, relying on learning to fill in details. In other words: What if the problem with Lisp this whole time really was the parentheses? ;) source is Logical Versus Analogical or Symbolic Versus Connectionist or Neat Versus Scruffy: https://onlinelibrary.wiley.com/doi/full/10.1609/aimag.v12i2.894 https://onlinelibrary.wiley.com/doi/full/10.1609/aimag.v12i2...
- kazinator 2y agoSome of it is because many people's only contact with Lisp is via academia, and the academics who teach it actually don't care about developing anything with Lisp. They use it as a vehicle for concepts, and those concepts typically revolve around functional recursion. The Scheme language and it surrounding culture are also culprits. Though Scheme isn't functional, it emphasizes pure programming more than its Lisp family predecessors. The basic language provides tail recursive constructs instead of iterative ones, and demands implementations to implement optimized tail calls.