Want to affect the way you think about programming?
Learn Prolog.
Clojure will affect the way you think about programming
101–110 of 226 posts
Re: Clojure will affect the way you think about programming
#102Having spent some time programming in Clojure, for the purpose of expanding my brain, I suspect a better Lisp to start with might be one of the classics - Racket, Common Lisp, etc... One of the reasons I gave up on Clojure was the lack of documentation of libraries, the bad debugging experience (those stack traces!) and the fact that there's no avoiding the JVM. They're all distractions to the learning (that was 2 ye…
I agree. I read through Clojure for the Brave and True, and played with it a bit, but it was too much new stuff at once coming from an only Python background. I'm reading Structure and Interpretation of Computer Programs right now and everything is clicking. I'm looking forward to going back to Clojure after I get through more of SICP.
Many people say that clojure is the one that clicked for them, but I suspect it's really not due to clojure itself, just that it's more recent and likely not to be the first lisp people have tried to learn.
I think the exposure of trying to learn different lisps is the key, and when you get to a point where one clicks, run with it!
Re: Clojure will affect the way you think about programming
#103I would love to use Clojure (it's probably the only language I would consider moving to right now) but the JVM just doesn't work for me. Clojure-native that offered all of Clojure and was realistic - there was one that indirectly used Gambit Scheme at one time, and an incomplete Python version - would be awesome. Clojure that requires you to use the current Java approaches to interfacing with C is not of interest.
Re: Clojure will affect the way you think about programming
#104Earlier quoted context omitted.
If you are curious about core.async and want to learn more you can have a look at the post I wrote on it-- [ http://abhirag.in/articles/batman_clojure.html ]. I wrote it while trying to learn it myself so not the most advanced resource but I hope somebody finds it helpful :) Note -- The page is kinda resource intensive because it contains a running clojurescript interpreter for interactive code snippets.
thanks for this. btw, your blog is great as well
Glad you liked it :)
Re: Clojure will affect the way you think about programming
#105I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…
I worked on a large-ish clojure project with ~15 (people left and joined) person team for years and I haven't experienced any of your points. Sounds more like an new project with a group of people not quite familiar with the language yet, which would have the problems you listed in any language.
Re: Clojure will affect the way you think about programming
#106Earlier quoted context omitted.
> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's…
> What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespac…
I've never seen anyone put more than one namespace in a single file in clojure. I don't think the compiler would even understand that...
While you can define classes in clojure, it's not the common way to do things, and so namespaces take the role of classes insofar as compartmentalizing code.
It's not normal to operate on data in another namespace directly... you can do it, but it doesn't feel natural in the language. You do it through an interface (called a protocol in clojure), or through functions in that namespace. So in that sense, you are still using getters and setters for everything.
But yeah, there is a lot of freedom in clojure. And that favors the writer, not the reader. Hence it can be difficult to grok somebody's code if they are more comfortable using the more advanced features of the language.
Re: Clojure will affect the way you think about programming
#107Having spent some time programming in Clojure, for the purpose of expanding my brain, I suspect a better Lisp to start with might be one of the classics - Racket, Common Lisp, etc... One of the reasons I gave up on Clojure was the lack of documentation of libraries, the bad debugging experience (those stack traces!) and the fact that there's no avoiding the JVM. They're all distractions to the learning (that was 2 ye…
I can occasionally get away with writing Clojure for "real" work, but for hobbying (and inshallah for real work someday) my goto is Racket. I feel like Racket is something of an optimum among the lisps in terms of brain expanding, modernity, tooling, libraries, docs, and community.
I tried Googling bcrypt; one C wrapper that hasn't been updated in 3 years pops for Racket, there's at least 3 recently updated libraries for Clojure. I'd suspect the library availability is gonna be similarly tilted in Clojure's favor in most domains. Clojure has lots of compelling and new stuff - Figwheel, re-frame, Neanderthal.
What's Racket's killer library that's doing something no one else is?
Re: Clojure will affect the way you think about programming
#108Earlier quoted context omitted.
> - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I personally don't find LISP languages to be the most readable, but I'm fairly sure it's…
> What on earth does this have to do with clojure? Programmers will do this in any language, there's nothing special about clojure here. I haven't programmed in Java in over ten years, but one if its "advantages" (at least back in the day) was what I called its object-oriented handcuffs, which prevented programmers from being too fancy with their code. Every file had to be a class. Every class was an object. Namespac…
Java still has same issue too with bored engineers. Over engineering happens. AbstractSingletonProxyFactoryBean anyone? But really strongly typed languages like java is easier than most dynamic typing language to jump into _if the project is sane_.
Re: Clojure will affect the way you think about programming
#109That's true of any language. Even within the same language paradigm.
If you know C#/Java then learn C++ or vice versa and it'll affect the way you think about programming.
Go outside of the statically typed OO world and try out the dynamically typed OO languages like ruby or python.
Even better, learn a weakly typed procedural language like C ( lingua franca for CS ).
Or choose an architecture and learn some assembly. Now that will affect the way you think about programming.
Move out of onto a different domain altogether and try one of the flavors of a declarative language like SQL.
Learning a bit here and there of many different languages and paradigms will affect the way you think. Clojure isn't special.
You can even just stay within a framework and try to get a deep understanding of .Net language/IL/Framework Libraries/Runtime stack. Then you get into the debate of breadth vs depth. Should you learn one language/framework/paradigm exceptionally well or should you learn a bit about a lot of a lot languages/paradigms?
Re: Clojure will affect the way you think about programming
#110I would love to use Clojure (it's probably the only language I would consider moving to right now) but the JVM just doesn't work for me. Clojure-native that offered all of Clojure and was realistic - there was one that indirectly used Gambit Scheme at one time, and an incomplete Python version - would be awesome. Clojure that requires you to use the current Java approaches to interfacing with C is not of interest.
I've felt that way about clojure native, but what makes a language is the ecosystem, and the JVM brings a fantastic ecosystem.
There really is no way to offer "all of clojure" as native because the ecosystem is part of what "all of clojure" offers.
I've long thought about ways of doing a "native" clojure, and have eventually come to the conclusion that it doesn't offer anything compelling.
If you want fast start up time and scripting, you can do that with node and clojurescript. Or Lumo or whatever else there is in that area.
Once running, the JVM is pretty performant in a lot of cases... Where it struggles are where all garbage collected languages struggle. If that's the pain point, you could probably bootstrap a scheme from Gambit or Chicken that did manual memory management...I struggle to imagine what that would look like in the end though. Lisp flavored C maybe.
People smarter than me have said that the Clojurescript compiler is an excellent starting point for making a compiler that emits other languages. It's over my head, but maybe it would be a worthwhile project to emit golang or something.
I believe some of the clojure-schemes that floated around briefly bootstrapped from clojurescript compiler to emit Gambit Scheme...
Without the libraries/ecosystem I don't think it would be worth it.