6 ms·

What is it like? 50 years of historic cruft. Questionable whether there are more trip hazards than usefulness for ordinary coding. A fractured community which f

• chamomeal 2y ago
  What do you mean by LISP as a siren call? I’ve just started learning clojure and besides the lack of static types (which is pretty harsh for me), it seems like a fun and practical language.
  • epgui 2y ago
    Clojure is probably the most beautiful language I've ever worked with. Nothing is perfect, but Clojure is very simple and elegant.
    • 7thaccount 2y ago
      Only downside is I don't know Java, so some things that should be obvious are opaque to me.
      • xyproto 2y ago
        Java frolicks in opaqueness.
      • epgui 2y ago
        You really don’t need to know any java. I don’t know java either. Even if you’re doing java interop, it’s quite easy to figure it out.
        • 7thaccount 2y ago
          Last time I looked about file IO it involves calling out to some Java class that I had no clue about as I don't use Java. All the doc of the time just assumed you should be able to figure this all out. Edit: it's been like 5 years
          • andrewflnr 2y ago
            This was my experience too, at about the same time. I should really dig back into it at some point.
          • fulafel 2y ago
            The docs are better now (eg https://clojure-doc.org/articles/cookbooks/files_and_directories/ https://clojure-doc.org/articles/cookbooks/files_and_directo... ) but you still need to follow a Javadoc link every now and then for the full story. Alternatively you can use a library such as https://github.com/babashka/fs https://github.com/babashka/fs . I agree with the GP that you don't need to know any Java.
    • xigoi 2y ago
      What makes Clojure a non-starter for me is that it runs on the JVM.
      • harperlee 2y ago
        Could you expand why? It's not immediately obvious why would that be, my understanding is that the general consensus around here is that the JVM is a superb piece of tech with a bad rap due to java the language.
        • xigoi 2y ago
          Slow startup, huge memory consumption, design that inherently favors class-based languages like Java, the frequent need to use Java libraries.
          • epgui 2y ago
            > Slow startup This makes the jvm a bit less suitable for programmes with short lifetimes (like lambdas), depending on how sensitive startup times are in context... But is mostly irrelevant in long-lived applications like services. > design that inherently favors class-based languages like Java Clojure abstracts over this so well that it's really a non-issue for a wide array of use cases / applications. When programming in Clojure, you really don't have to think about objects and classes at all, unless you really insist on doing so. > frequent need to use Java libraries This would be going against the grain: you will have a much better time by staying within native Clojure. I've worked on commercial/production applications that barely had any java interop, and whatever java interop there was was rarely ever involved in day to day work. --- Disclaimer: I also am not a huge fan of the JVM and I really dislike the Java world generally, but it never stood in the way of me getting stuff done with Clojure.
  • ethagnawl 2y ago
    core.logic is pretty neat, too. Especially as it applies to this thread and the ancestor comments.
  • wk_end 2y ago
    Imagine it's, like, 1980 - or even earlier - and you can work in a language roughly as nice as Clojure, except the rest of the world is stuck working with pre-ANSI C or Pascal or FORTRAN or COBOL or raw assembly language. There's no Python or Java or C# or Ruby or Perl or Haskell or Scala or Kotlin or Rust or JS/TS. Nothing really resembling our modern idea of a high-level language. (OK, there was Smalltalk. Let's ignore Smalltalk. Lord knows everyone else did.) That'll alter your perception of reality a bit. Here they were, in possession of a tool massively more powerful - and more elegant - than what everyone else is using. And moreover, everyone else took a look at it and turned their noses up. Clearly, you and your fellow Lisp programmers are a different breed, capable of seeing further than the rest of the unwashed masses. In a word, you were better than them. It sounds like I'm being disparaging, but to a certain extent, I don't even think this was totally a wrong attitude to have. Elitist, definitely, but not wholly unwarranted. Lisp really was - in terms of expressiveness, anyway - really that far ahead of the competition. And yet somehow that competition won. The world is cruel and unjust. So Lisp becomes a kind of Us v. Them cult: if you've heard the good word of McCarthy, you're one of Us. If not, you're best ignored - too stupid to possibly have anything worthwhile to say. (If you think I'm exaggerating, spend some time reading the words of Usenet Lisp institution Erik Naggum - R.I.P. - who serves as the most extreme but hardly the only example.) This blinded Lisp diehards to the outside world, which slowly but surely, in many respects, began to catch up or even exceed Lisp. The other thing is - not only is Lisp a powerful language, at its core is a beautiful and simple and expressive mathematical idea. Combine that with the way macros allow you to extend the language virtually infinitely, there can be a near religiosity at the heart of Lisp - from one lambda all things depend. Lisp isn't just good engineering - it's a glimpse at the fundamental nature of computation, of the universe itself. I'm not going to sit here and tell you that this is somehow a terrible thing, per se. But it can be incredibly alluring to the right kind of mind, and once you're in its thralls it's hard to get out. You might be working with the tool, but in another sense the tool is working with you. A Siren Song.
    • forgetfulness 2y ago
      There's also the not all small factor that there was glam to Lisp. Early Internet discourse around programming was dominated by people who had ties to elite universities in the 1980s, who yearned for the times when the US Government was throwing an abundance of money to the AI industry of the time. They were the ones rubbing elbows with researchers from MIT, Stanford, Harvard, and Berkeley, who were using specialized hardware and software beyond the capabilities available to that of developers working on more mundane applications, all graciously funded by DARPA initiatives. That experience was, in truth, unrelatable to young people reading the recollections of ESR and RMS of the period, the in-jokes of these people, their ideas and interactions, but the tales of Lisp, the Lisp hackers and their fabled Lisp machines would be extremely appealing to someone who was very passionate about programming, striving for excellence as a programmer, and to advance in life through merit. Paul Graham would seal the deal with his essays.
  • jolt42 2y ago
    Lisps don't get in your way, but they also have no opinions, which is problematic for community development. As a static type fan, it's the only language I think the pros outweigh than one con.
• slashdave 2y ago
  Who still has nightmares of infinitely nested parenthesis?
  • jolt42 2y ago
    They seem to disappear with parinfer.
  • forgetfulness 2y ago
    The more nightmarish thing about Clojure is realizing that, in truth, you have no idea what all these dicts you are passing around the terse, nil-punning functions of your codebase hold at any given time.
    • nogridbag 2y ago
      That was the case for me. I went all in drinking the Clojure koolaid and wrote some small internal CLI tools with it. If I came back to that code a month or two later I could only properly understand it if I opened up a REPL to debug it. I ported those tools to Java and they were dead simple to comprehend.
      • kamaal 2y ago
        After a while, lesser the magic, the better. One of the reasons Golang has had a use case in today's age is there is a need for a programming language with just functions, loops and if/else statements.
    • koito17 2y ago
      Yup. I learned Clojure just so I can use a Lisp and get paid for it, but there is some weird cult against all forms of typing. Even coming from a Common Lisp background, this was strange to me. In Common Lisp, there are implementations (like SBCL and ECL) that can make use of type declarations to produce efficient machine code and allow the compiler to catch errors that would otherwise be run-time errors. There's also other benefits like contextual autocomplete. The autocomplete in Clojure tooling is very basic, and many Clojure libraries try to make up for this by using qualified keywords everywhere. That way, rather than seeing all keywords ever interned, you can type ":some.namespace/" and your editor shows a dozen keys instead of hundreds of unrelated keys. Many in the Clojure community believe that occasionally validating maps against a schema "at the boundaries" is good enough. In practice, I have found this to be insufficient. Nearly every Clojure programmer I know has had to "chase nils" as a result of a map no longer including a key and several functions passing down a nil value until some function throws an exception. (Note: I don't specify which exception, because it depends on how that nil value gets used!) Refactoring Clojure code in general is a nightmare, and I suspect it is why many in the community are reluctant to change code in existing libraries and build entirely new things in parallel instead. Backwards compatibility is one often-cited reason, but I do think another reason is that refactoring Clojure code creates an endless game of bug fixing unless you have full test coverage of your codebase and use generative testing everywhere. (I've never seen a Clojure codebase with both of these things. I can count on one hand the number of Clojure codebases where generative testing is used at all). Function spec instrumentation provides something that feels like runtime type checks in Common Lisp, but now you have to manually run certain functions at the REPL just to ensure some change in your codebase did not introduce a type error. On the flip side, Java has things like DTOs which always felt too boilerplate-ish for me (though at least it provides useful names for endpoint data when generating Swagger/OpenAPI documentation). Even then, records in Java provide what are essentially maps with type safety and similar characteristics as DTOs. I think the structural typing offered by languages like OCaml and TypeScript provide exactly what I'd want in Clojure. But when faced with feature requests in Clojure, people will state something like "I have never had a use-case for X, therefore you don't need X". In the case of criticisms, the response is often "I may have ran into X before, but it's so rare that I don't consider it a problem".
• everforward 2y ago
  > A few dedicated clever people and idealists and dreamers talking about ontologies and building things I don't understand I was briefly deeply interested in ontologies via OWL and I suspect Prolog has the same issues that I think plague ontologies in general. They are a fantastic tool for a system complex enough to be nearly useless. Modelling an ontology for a reasonably complex domain is unreasonably difficult. Not because the tools are bad, but because trying to define concrete boundaries around abstract ideas is hard. What is a camera? A naive attempt would say an item that takes pictures, but that would include X-rays. Are deep-space radio telescopes cameras? Trying to fix those issues then causes second order issues; you can say it’s something that takes images from the visible light spectrum, but then night vision cameras aren’t cameras anymore. The reasoning systems work well, they just don’t solve the hard part of designing the model.
  • riku_iki 2y ago
    your camera example demonstrates that human knowledge is loosely structured and formalized in general, so you can't create strict onthology. One way to work around is to assign some confidence score on statements, so you will have something like that Nikon device is likely camera, and x-ray machine is unlikely camera based on current world model.
  • wslh 2y ago
    Yes, I think that is the experience, for example, in what we called (or call) data science: most of the time is spent in ETLs rather than using ML methods. In a real company linking data difficulty is not technical but time and resource consuming.
  • strangattractor 2y ago
    I had similar discussions with people that wanted to encode published research into ontologies. I would ask researchers what they think - the answer was always great idea. I would then follow up with - How would you use it? No response. I finally concluded that it would never happen. 1. No one wanted it enough to pay for it to happen. 2. There is always a turn over of ideas coming and going which can never be sufficiently updated to keep it useful. Again no one would pay anyway. Tools like LLMs seem to be fill the role now. I would like to see a Prolog integrated with LLMs is someway (lack of imagination fails me how that would happen).
• deleted 2y ago
  [deleted]