|
Beef posted:Talking of real-world stuff with Scheme. If you're doing arduino-like embedded programming, check out Armpit Scheme. We've been using it for a few years to get students to do some bit-level fuckery without leaving the kiddiepool. That's really cool. I was thinking about something like that yesterday, I was looking at Parallela and I was thinking about how cool it would be to program for those epiphany cores in a Lisp. SBCL can almost directly compete with Java, and it won't be long before it challenges C++, I think. Lisps are definitely coming back. 4th gen lispers are going to have an advantage when it does. Cumulative Self-lulz Caused: Bans: 0 | Probations: 6 Days 6 hours 15 min | Lang: Racket, Ruby | Public Projects: (none so far) |
|
#
?
Oct 26, 2012 16:03
|
|
|
|
| # ? Jun 2, 2024 01:22 |
|
|
A little note on Common Lisp performance: it can definitely beat C++. The quality of the programmers and the actual approach matter more than actual baseline runtime performance in practice. I don't mean that just in general, but from the C++ vs Lisp cases I've observed around me. ( For example, implementation re-writes to C++ to make the work more publishable often came out slower) When comparing performance of microbenchmarks, zooming in on specific features, C++ will often come on top. (note: strangely enough, CL is better at instantiating new objects, heh) But CL implementations often include optimizations of higher-order or simply more complex features that inevitably creep in on large-scale projects. For instance, C++ doesn't cache your method lookups when you hack in multiple dispatch, but the single dispatch case in CL stays just as fast as C. That said, high-performance CL looks a lot like C++, but in a more verbose syntax. The difference is that you can start from a working prototype using powerful language features, then just dumb it down to the bare necessities when you modify your program for performance. The Lisp developer mantra is: 1) make it work 2) make it nice 3) make it fast
|
|
#
?
Oct 26, 2012 16:24
|
|
|
Ok, I see. that's very interesting. Have you ever worked with a parallel system in CL?
Cumulative Self-lulz Caused: Bans: 0 | Probations: 6 Days 6 hours 15 min | Lang: Racket, Ruby | Public Projects: (none so far) |
|
|
#
?
Oct 26, 2012 16:33
|
|
|
luxxx posted:Ok, I see. that's very interesting. Have you ever worked with a parallel system in CL? The Lisp I've done has been almost exclusively parallel. The environments all support your basic OS threads & locking mechanisms, but CL is really nice in that macros can scope your locks, continuations, barriers, and other metaphors well. There are plenty of libraries out there to provide internal message passing, auto-parallelizing map equivalents and the like. As mentioned, allocation is faster in Lisp than most C++ libs, since allocation in Lisp tends just to be a bounded pointer increment. Each thread gets its own preallocated memory block to stream its allocations through, only accessing shared resources when the block is used up. A speed downside is that all CL implementations I've worked with use a stop-the-world garbage collector, which sucks when the number of cores in your machine is high. Special variables (effectively CL's "globals") are automatically thread-local when used in a 'let' block inside a thread, which is really cool. I tend to use this a lot, probably more than others recommend, due to all the side-band context in the processing tasks we do.
|
|
#
?
Oct 27, 2012 05:22
|
|
|
Globals sound really cool. I'm still a lisp beginner, for all intents and purposes, but I have big plans for the future.
Cumulative Self-lulz Caused: Bans: 0 | Probations: 6 Days 6 hours 15 min | Lang: Racket, Ruby | Public Projects: (none so far) |
|
|
#
?
Oct 27, 2012 19:39
|
|
|
GC is an issue in multicores indeed. There was a really successful crowdfunding campaign by Nikodemus which has as one of the stretch goals to remove the global GC lock, but for various reasons he hasn't succeeded yet. If you can identify the 'steady state' of your system, you can avoid consing in that part of the program, which would avoid that performance penalty. You can even just turn off the GC in a certain code block via directives, not sure if that's CL standard or implementation-specific though. ITA software, from what I can remember, hacked part of their runtime in C (called via FFI) to avoid consing during critical parts of the application. edit: vvv I stand corrected. Beef fucked around with this message at 10:46 on Nov 2, 2012 |
|
#
?
Oct 29, 2012 11:56
|
|
|
Nikodemus' goal was to eliminate the "big compiler lock" (I presume **world-lock**), not to make the GC concurrent. Doing runtime codegen can get pretty slow with the current compiler. I think he got a lot of that done, at least from the compiler's view of things. Other stuff still might use the big lock. Maybe somebody can point me to others, but I think the only truly concurrent GC I've come across is the C4 collector (PDF). It focuses on Java, but apart from the scope of the project I don't think there's any game-breaking technical assumptions preventing dropping that algo into SBCL from what I know. Not sure where the default Java GC options have gotten to by now.
|
|
#
?
Nov 1, 2012 05:05
|
|
|
I can ask around on the next workday. But, as far as I know, parallel shared-memory GC is an absolute nightmare.
|
|
#
?
Nov 2, 2012 10:48
|
|
|
I found Cream (http://en.wikipedia.org/wiki/Cream_(software)) and have been using it lately. I wouldn't say that I'm a raving fan quite yet, but it has a lot of features that I really really enjoy. It's not specifically optimized for Lisp, but it has ParEdit and some other things that make simple. sudo apt-get cream should work too on most distros, assuming your OS isn't lovely. Just thought I would post this and see what the SA lispers think of it. Cumulative Self-lulz Caused: Bans: 0 | Probations: 6 Days 6 hours 15 min | Lang: Racket, Ruby | Public Projects: (none so far) | luxxx fucked around with this message at 16:41 on Nov 22, 2012 |
|
#
?
Nov 22, 2012 05:53
|
|
|
luxxx posted:I found Cream (http://en.wikipedia.org/wiki/Cream_(software)) and have been using it lately. I wouldn't say that I'm a raving fan quite yet, but it has a lot of features that I really really enjoy. It's not specifically optimized for Lisp, but it has ParEdit and some other things that make simple. I haven't used it much for lisp in particular, but cream has just enough differences with what I expect from vim that it drives me mad. Most of it is just default config changes, but there is still something I couldn't deal with on it. I prefer to just use gvim if I want to vim things up (or just console vim if I need to make a quick change to a file).
|
|
#
?
Nov 25, 2012 03:57
|
|
|
Cream just makes me angry because it added a ton of context menu shortcuts that it didn't delete when I removed it, and I'm too lazy to actually go through the registry and delete it by hand. Just seeing "Edit with Cream/Vim" at the top of every right-click menu makes me literally angry with rage.
|
|
#
?
Nov 25, 2012 04:25
|
|
|
Does anyone use Light Table seriously yet for Clojure development? It looks cool but I'm afraid to stray from the familiar safe haven that is SLIMV / SWANK / xterm
|
|
#
?
Nov 26, 2012 17:21
|
|
|
On a slightly related note, has anyone done Android development with Clojure recently? (my... passive income  )
|
|
#
?
Nov 26, 2012 17:47
|
|
|
A MIRACLE posted:Does anyone use Light Table seriously yet for Clojure development? It looks cool but I'm afraid to stray from the familiar safe haven that is SLIMV / SWANK / xterm I was this close to using light table, and then I just started using La Clojure for Intellij and that was that.
|
|
#
?
Nov 26, 2012 17:51
|
|
|
I want to like Clojure, but I can't justify to myself the expenditure of the required amount of time learning two languages at once. The biggest thing about Clojure that turns me off is that you can't write effective Clojure without knowing Java. I know that Clojure/core is cool on its own, but it just doesn't compare to real Clojure. I have never liked Java, its syntax is awful, its use case is obnoxious, and the ratio of time spent coding to ideas expressed is pitiful. I'd love to be able to not worry about platform issues, and to just compile and release it without making those OSX tweaks and all of that, but to me, it's not worth going back to Java hell. (ps naming it Clojure was a dick move because we know drat well that Hickey knew about ClozureCL.) In addition to all of that, I'd like to clarify that I don't have anything against people who use Clojure. I mean, PHP is a piece of poo poo, but it doesn't bother me to know that people still use it. Cumulative Self-lulz Caused: Bans: 0 | Probations: 6 Days 6 hours 15 min | Lang: Racket, Ruby | Public Projects: (none so far) |
|
|
#
?
Nov 27, 2012 06:04
|
|
|
luxxx posted:(ps naming it Clojure was a dick move because we know drat well that Hickey knew about ClozureCL.) But closures are just a general thing in functional programming? Taking the name of an existing concept and sticking a random J somewhere to indicate "hey this runs on the JVM" is how basically all these things are named anyway.
|
|
#
?
Nov 27, 2012 07:58
|
|
|
Jabor posted:But closures are just a general thing in functional programming? From Hickey, https://groups.google.com/forum/?fromgroups=#!topic/clojure/4uDxeOS8pwY "The name was chosen to be unique. I wanted to involve c (c#), l (lisp) and j (java). Once I came up with Clojure, given the pun on closure, the available domains and vast emptiness of the googlespace, it was an easy decision."
|
|
#
?
Nov 27, 2012 14:26
|
|
|
luxxx: are you aware that Clojure fixes many of Java's flaws which you listed? I write in Java at my job, and I use Clojure to demo libraries and create prototypes. It's so much quicker than producing pages of object-oriented dreck. (Sadly, my boss persistently refuses to let me use Clojure for production code.)
Tequila Bob fucked around with this message at 04:32 on Nov 28, 2012 |
|
#
?
Nov 28, 2012 04:16
|
|
|
You still have to know enough to work in Java's ecosystem - jars, classpath, maven, etc. And enough Java to use libraries that haven't already been wrapped. And you generally have to deal with a Java IDE unless you're comfortable with Emacs. All that is why I've never actually done anything with Clojure, despite liking it a lot. And I already know all that stuff, it's just that I use other languages partially to get away from all that crap.
|
|
#
?
Nov 29, 2012 18:51
|
|
|
SavageMessiah posted:You still have to know enough to work in Java's ecosystem - jars, classpath, maven, etc. And enough Java to use libraries that haven't already been wrapped. And you generally have to deal with a Java IDE unless you're comfortable with Emacs. This is mostly untrue. My Java is extremely rusty, I never learned how to use maven/ant or most of the surrounding ecosystem, and I don't need to because lein handles it all automatically. There's Clojure support not just for emacs and Eclipse but for IDEA, JEdit, vim, Sublime Text, and Textmate, among others. You're correct that you need to know enough Java to be able to understand the javadocs for any unwrapped Java library you want to call (although at no point do you actually have to write Java code). It's been a while since I actually had to call an unwrapped library, though.
|
|
#
?
Nov 30, 2012 00:55
|
|
|
SavageMessiah posted:You still have to know enough to work in Java's ecosystem - jars, classpath, maven, etc. And enough Java to use libraries that haven't already been wrapped. And you generally have to deal with a Java IDE unless you're comfortable with Emacs. Use leiningen and avoid most of the JVM hassle. It is standard now for all those reasons. Many libraries already have Java wrappers at this point, but knowing a little Java doesn't hurt.
|
|
#
?
Nov 30, 2012 01:42
|
|
|
Have to agree that you can get a very long way with clojure without knowing any java at all. What libraries that clojure lacks have you wanted? I've written some crappy java in clojure before due to lack of a library, but I've never had to mess with any of the ecosystem stuff you've mentioned ("jars, classpath, maven, etc"). I agree with ToxicFrog, if you can read javadocs you should be good.
|
|
#
?
Nov 30, 2012 03:40
|
|
|
How is Clojure in the speed department nowadays? Most of the Lisp I write is in very CPU-heavy projects, but the deployment benefits of being on the JVM would be something worthwhile.
Insufferable Git fucked around with this message at 11:32 on Nov 30, 2012 |
|
#
?
Nov 30, 2012 04:45
|
|
|
Insufferable Git posted:How is Clojure in the speed department nowadays? Most of the Lisp I write is in very CPU-heavy projects. Single core is meh, but it really shines with 4+ cores. I still use some finely tuned C via JNI for certain memory efficient bits but Clojure performance on a big multicore (8+) server is shockingly good. Depends on your workload though, if it's parallelizable you'll be fine.
|
|
#
?
Nov 30, 2012 11:35
|
|
|
The fact remains that you have to work with Java to some degree to use Clojure. Learning Java is one reason I won't use it, but it's mere association with Java is another reason. I don't like Java or anything about the "Java Way," so I won't do anything to prolong Java as a language. If people stop using it, it'll go away eventually. For this reason, I won't use anything that uses Java unless it's absolutely necessary. It's as much of a functionality thing as it is ego. I think it's important to consider both when choosing a lisp for a project. Cumulative Self-lulz Caused: Bans: 0 | Probations: 6 Days 6 hours 15 min | Lang: Racket, Ruby | Public Projects: (none so far) |
|
|
#
?
Dec 1, 2012 21:41
|
|
|
luxxx posted:The fact remains that you have to work with Java to some degree to use Clojure. Learning Java is one reason I won't use it, but it's mere association with Java is another reason. I don't like Java or anything about the "Java Way," so I won't do anything to prolong Java as a language. If people stop using it, it'll go away eventually. For this reason, I won't use anything that uses Java unless it's absolutely necessary. I think you are confusing the Java language with the jvm. As others have said, as long as you can read the javadocs for any java libraries you are using, that is basically all the Java knowledge you need. If you don't want to touch Java at all, you don't really have to. Everything else is jvm-related.
|
|
#
?
Dec 3, 2012 01:21
|
|
|
luxxx posted:The fact remains that you have to work with Java to some degree to use Clojure. Learning Java is one reason I won't use it, but it's mere association with Java is another reason. I don't like Java or anything about the "Java Way," so I won't do anything to prolong Java as a language. If people stop using it, it'll go away eventually. For this reason, I won't use anything that uses Java unless it's absolutely necessary. This doesn't strike me as an argument that was born from rational thought. You should try Clojure, it's actually really good.
|
|
#
?
Dec 3, 2012 05:25
|
|
|
luxxx: from the way you're talking, it sounds like you think you need to learn Java the language in order to use Clojure. Is that the case, and we just need to reassure you that it's not so? Or is there some other issue you haven't mentioned yet? If you just don't want to learn Clojure, period, that's fine. What gets me is that you said you want to like it, and then you showed us all that your misconceptions are preventing you from giving it a try. That's why I replied in the first place. As far as your plan to get everyone to stop using Java entirely: good luck. It's become too ingrained both in industry and open-source to stop now. Consider, however, that the vast body of work people have pumped into the JVM ecosystem is now accessible through an awesome, modern language. Isn't that a good thing?
|
|
#
?
Dec 3, 2012 08:36
|
|
|
It sounded to me like he's more worried about having to deal with the Java standard library.
|
|
#
?
Dec 3, 2012 08:59
|
|
|
Bongo Bill posted:It sounded to me like he's more worried about having to deal with the Java standard library. I wonder if clojure-clr is usable yet.
|
|
#
?
Dec 3, 2012 19:06
|
|
|
God of Mischief posted:I think you are confusing the Java language with the jvm. As others have said, as long as you can read the javadocs for any java libraries you are using, that is basically all the Java knowledge you need. If you don't want to touch Java at all, you don't really have to. Everything else is jvm-related. To be fair, this is only true until you encounter your first error/exception, at which point all the awfulness bursts forth. Also, (Integer/parseInt "42") sucks. Saying that, I find other lisps hard to go back to after working in Clojure the past few years. Having vectors and maps be first order data structures with their own syntax is a significant improvement. Things like the excellent sequence library, and now reducers; will likely prevent me from using an older lisp for any future work. If you're not in some sort of Ivory tower, and are a fan of lisp; you should learn Clojure.
|
|
#
?
Dec 4, 2012 00:10
|
|
|
Meiwaku posted:Single core is meh, but it really shines with 4+ cores. I still use some finely tuned C via JNI for certain memory efficient bits but Clojure performance on a big multicore (8+) server is shockingly good. I think I need a bit more explanation on this. If it has poor single-core performance, then how could it effectively "catch up" on parallelizable tasks? If the same type of task is implemented on another platform with much better performance per-core, I can't see how Clojure would all of a sudden pull ahead.
|
|
#
?
Dec 4, 2012 00:24
|
|
|
Insufferable Git posted:I think I need a bit more explanation on this. If it has poor single-core performance, then how could it effectively "catch up" on parallelizable tasks? If the same type of task is implemented on another platform with much better performance per-core, I can't see how Clojure would all of a sudden pull ahead.
|
|
#
?
Dec 4, 2012 01:03
|
|
|
Most of the SBCL stuff we work on has all cores running at >90%. Clojure likely isn't going to utilize the CPU at a greater capacity than that. If its single-core performance is significantly less, then even if it runs each core at flat-out 100% then it would likely be slower overall, in a similar same ratio as its single-core performance is to SBCL single-core. What specifically & technically is its multi-core advantage? I could see the JVM's garbage collector being faster, and that's something that we do face as a challenge.
|
|
#
?
Dec 4, 2012 01:26
|
|
|
Insufferable Git posted:I could see the JVM's garbage collector being faster, and that's something that we do face as a challenge. meh, SBCL's gc is pretty good, I would suspect that whether it or the jvm's gc is better is workload-dependent. I would expect that the advantage in parallelizability for Clojure would come from pervasive const-ness.
|
|
#
?
Dec 4, 2012 01:43
|
|
|
It's not actually hard to write a parallelized non-P-language program though.
|
|
#
?
Dec 4, 2012 02:01
|
|
|
Otto Skorzeny posted:meh, SBCL's gc is pretty good, I would suspect that whether it or the jvm's gc is better is workload-dependent. I would expect that the advantage in parallelizability for Clojure would come from pervasive const-ness. SBCL runs the entire GC single-threaded, so it leaves the rest of your machine idle while collection happens. Java's default GC, last I checked, ran the majority of GC operations multithreaded (parallel stop-the-world, not concurrent with the program), so at least it uses all the cores and would be expected to finish faster given the same load. Does Clojure automatically decide to run certain const or sequence operations in parallel? Or do you need to manage threads & call parallel equivalents manually? The latter is exactly the same if you're doing a lot of functional style in Lisp or any other functional-friendly language, and take advantage of the constness yourself. I don't want to knock Clojure for the things I'm unaware of. I see the lack of vector & map literals as a real nuisance in CL, as well as some other legacy cruft that the little bit of Clojure I've seen seems to do in a more clean manner. However, the realities of speed are make-or-break issues for me, so I'm interested in the details of "why" when it's mentioned it's "shockingly good" in multicore. Insufferable Git fucked around with this message at 03:47 on Dec 4, 2012 |
|
#
?
Dec 4, 2012 03:43
|
|
|
Clojure does make some calls on parallelism on its own by querying the jvm for your processor count. Using data structures like Agents (and all async structures IIRC) and also explicit parallel calls like pmap will automatically take advantage of as much parallelism as is available.
|
|
#
?
Dec 4, 2012 04:04
|
|
|
Insufferable Git posted:Does Clojure automatically decide to run certain const or sequence operations in parallel? Or do you need to manage threads & call parallel equivalents manually? The latter is exactly the same if you're doing a lot of functional style in Lisp or any other functional-friendly language, and take advantage of the constness yourself. You won't switch to Clojure for performance, unless you're coming from Ruby/Python, but may switch for simpler code and/or Java interop. Coming from CL I suspect it'll really depend on your use case whether Clojure would provide significant benefit to you. Performance is one of those terms that means five different things to five different people... Re multicore: Idiomatic Clojure is multicore, so instead of tuning for it you'll get it by default for the most part. I'd say reducers are the biggest new development, but that's still in beta.
|
|
#
?
Dec 4, 2012 12:00
|
|
|
|
| # ? Jun 2, 2024 01:22 |
|
|
h_double posted:Good idea for a thread. Could anyone who has read both SICP and How to Design Programs comment a little more on which would be best for someone taking a first read through this material? I've watch the first lecture in SICP and read the accompanying material, and I love it so far coming from only a Python and minimal C background. I'm just wondering if HtDP would be more practical, especially since it specifically uses Racket. There is a while paper here by the authors of HtDP in which they talk about the drawbacks of SICP, and if anyone could comment on those that would be really helpful as well. http://www.cs.brown.edu/~sk/Publications/Papers/Published/fffk-htdp-vs-sicp-journal/paper.pdf All in all it seems to me that both resources are excellent and I'm getting some analysis paralysis in picking one.
|
|
#
?
Dec 9, 2012 06:42
|
|
