51–60 of 179 posts
Earlier quoted context omitted.
Can you be more specific? In particular, about stuff you'd consider to be lacking in Clojure?
Restarts, call/cc, reasonable error reporting, reasonable error reporting , real tail-call elimination.
I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that…
While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to doc…
Earlier quoted context omitted.
Are there (m)any advantages to doing this? I've seen a number of shell-interop modules for various languages but they all appear to add an extra layer that reduces portability or ease of maintenance.
> Are there (m)any advantages to doing this? In the general case, as always, "it depends". I'm of the opinion that shell scripts are very powerful for quickly prototyping something, but as soon as you need to do real software engineering (e.g. test suites, etc.) then it's probably worth porting over to a saner language (yes, there are test frameworks for bash; no, that doesn't make bash's semantics any more sane ;) )…
Surely if you're doing that then shell is the way to go?
What cases are there for performing that sort of piping inside a "real software engineering" program? (And if you're doing it inside a single program, why aren't you making several independent programs that pipe to each other?)
Earlier quoted context omitted.
Conditions and restarts, read macros, interactive debugging, native code compilation, extremely easy interface with C, intrinsics, compiler macros, full control of code generation, built-in disassembler and so on and so forth. Clojure is ok if all you're doing is based on the JVM. If that's not the case, then it simply doesn't exist.
You're just saying 'Clojure isn't as good as CL because it's not CL'. When one of the the biggest selling point is "it works seamlessly on the JVM" it's a bit disingenuous to say "it's not as good as CL because it doesn't have a good C interface".
[0] https://nakkaya.com/2009/11/16/java-native-access-from-cloju...
Earlier quoted context omitted.
I have been trying to get into the whole Lisp paradigm for 1-2 years now. I own Realm of Racket, amongst a collection of Lisp books. Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame. I recommend you watch one of the core devs, Matt Flath, build a a hygenic macro expander. https://www.youtube.com/watch?v=Or_yKiI3Ha4 Notice how his talk, likely written in its own documentation…
> Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame. Have you ever used a commercial Common Lisp like Allegro ?
Only natural hobbyists overlook this. But, yes, LispWorks and Allegro are very powerful environments. Comparing AllegroCache to Hibernate might be fun for newcomers too. Haha.
Earlier quoted context omitted.
> Are there (m)any advantages to doing this? [trigger warning: cynicism distilled from 15+ years of bitter tears] More fun and better job security for the current maintainer. The former because one hacks away in the preferred language, the latter because one cannot be replaced easily by some unix geek unless s/he happens to speak the same language fluently. One can chose from various implementations in various langua…
Remind me never to hire you for anything ever. You've truly internalized the Tao of the BOFH.
I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that…
I think this conceptual disconnect can happen even without a DSL. So, then you have the huge amount of code, plus , a bunch of new and confusing concepts applied in ways that don't fit with your understanding of those concepts. A DSL may mean that the language doesn't fit how you think about a given problem, sure, but a poorly fitting abstraction can happen with or without those language abilities. I tend to think th…
Earlier quoted context omitted.
> Are there (m)any advantages to doing this? In the general case, as always, "it depends". I'm of the opinion that shell scripts are very powerful for quickly prototyping something, but as soon as you need to do real software engineering (e.g. test suites, etc.) then it's probably worth porting over to a saner language (yes, there are test frameworks for bash; no, that doesn't make bash's semantics any more sane ;) )…
> bog-standard "foo | bar | baz | ..." Surely if you're doing that then shell is the way to go? What cases are there for performing that sort of piping inside a "real software engineering" program? (And if you're doing it inside a single program, why aren't you making several independent programs that pipe to each other?)
The problem is that invoking subprocesses can be quite verbose.
If you do the naive thing and pass strings in/out of each step, it increases verbosity, gives you temporary variables to abstract away and can eat up a lot of memory with temporary data.
If you do the clever thing and set up pipes between the subprocesses, it removes some of the variables, but takes more code and hits deadlocks when the buffers fill up.
If you do the right thing and spawn separate threads to read/write data to the pipeline then it takes even more code, and now you have to worry about multithreading.
Hiding that sort of boilerplate is why I like shells and shell-like libraries. Both are rather unsuited to anything else, but at least with a shell-like library you can fall back to a decent language.
I'd think Common Lisp is the Lisp beyond Clojure. Also, I just see slides that have (googleable) terms, is there a recording of this presentation? EDIT: see mkozlows' comment (THANKS!!!)
UI is weird. Left/right goes between main topics, up/down goes through the slides on that topic. So if you just go right, right, right, you're only seeing the headings.
Earlier quoted context omitted.
I have been trying to get into the whole Lisp paradigm for 1-2 years now. I own Realm of Racket, amongst a collection of Lisp books. Racket is all the promise of developer-centric power tooling that puts Common Lisp to shame. I recommend you watch one of the core devs, Matt Flath, build a a hygenic macro expander. https://www.youtube.com/watch?v=Or_yKiI3Ha4 Notice how his talk, likely written in its own documentation…
Cider's integration of Clojure into Emacs is reasonably comparable to what traditional SLIME integration for Common Lisp is like, as a user experience. Likewise, Geiser is a sort-of capable mode for most of the other more prominent Schemes; though it is not quite as elegant or polished as Cider.
