×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Programming Clojure

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Books 109

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review.First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

109 comments

on LISP (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32240996)

Any sufficiently complex programming language will, over time, expand its features until it reinvents LISP.

Re:on LISP (0)

Anonymous Coward | more than 3 years ago | (#32244754)

On a related note...could someone briefly explain why Clojure as opposed to another Lisp?

I mean, there are enough variants of Lisp, and it's really unclear to me what Clojure provides other than tight integration with a popular imperative language on an extremely popular VM.

It seems every new language ends up having to seriously address the question "why another programming language", and in this case it seems the bar is higher because it is basically another language.

I'm not trying to be a troll, I'm just curious because I like Lisp quite a bit, and I don't really understand why you'd want to use Clojure when there are more mature frameworks in place. Clojure seems just similar enough to not make a difference, but different enough to cause headaches. I could see the speed of implementation issue, but what I've read isn't too promising in that regard.

*sigh* (0)

Anonymous Coward | more than 3 years ago | (#32241002)

Who here has ever heard of this "Clojure"? Would it have killed /. to explain things just a little bit in the summary?

Re:*sigh* (2, Interesting)

bb5ch39t (786551) | more than 3 years ago | (#32242132)

Yes, I've heard of Clojure. I have even read this book and enjoyed it. But I am a bit of a dilettante when it comes to programming languages. I've read a good number of the books from Pragmatic and like them. I especially like that they are PDF and DRM-free. Of course, each book is unique in that it is water marked on each page with my name. I've not used the language myself for anything other than "playing around". I also like Groovy and Scala, which are also JVM based languages which makes it easy to inter-operate with them.

First! Lisp! Rant! (0, Flamebait)

Mybrid (410232) | more than 3 years ago | (#32241024)

/rant on

LISP? My claim has always been that people who think in functional programming come from out space and are secretly trying to take over the world by twisting computer languages to be something completely alien.

I mean, LISP is to programming languages like Babylon 5 is to SciFi. Cdr and car? /rant off

Those who do not understand Lisp - (1)

RichMan (8097) | more than 3 years ago | (#32241108)

are forced to reinvent it.

I presume that explains the existence of Clojure.

But hey, on top of Java. This now means your browser can run Lisp.

Re:Those who do not understand Lisp - (2)

ByteSlicer (735276) | more than 3 years ago | (#32241516)

Clojure is Lisp. It just runs on top of a Java VM instead of the usual Lisp VM.
I assume you meant EcmaScript/JavaScript instead of Java. Which by the way has many Lisp like features.

Re:Those who do not understand Lisp - (0)

Anonymous Coward | more than 3 years ago | (#32241898)

Actually ECMAScript is more like Scheme or rather based on scheme with a C-like syntax due to management pressure and a broken floating point implementation. Why people hate parentheses while they live and breathe curly braces is beyond me, even as someone who still prefers C over any other medium level language.

Re:Those who do not understand Lisp - (2, Interesting)

nschubach (922175) | more than 3 years ago | (#32242946)

I've been looking into Clojure and the parenthesis vs. curly braces thing is one that stuck out to me. Braces define blocks and only blocks of code in most OO programming languages. Clojure's parenthesis enclose lists of data, defn functions (ignore redundancy in that), and practically everything besides vectors. So it's sometimes hard to tell where one logical block stands apart from another. Not to mention, the "recommended" indentation style feels counter-intuitive coming from an OO development background. Be it "Java Style", "Linux Style", or what have you... braces always mean a block of logic and it's easy to see it as one entity. That's been my biggest hurdle with adopting Clojure to do anything... and I really want to learn to use it.

Re:Those who do not understand Lisp - (3, Interesting)

stuart.halloway (1813346) | more than 3 years ago | (#32247686)

It's worth fighting through this initial impression to get to the other side. Lisps syntax is very regular, which makes reading/writing/tooling remarkably easy (once you are familiar). And, almost any kind of expression can go anywhere, encouraging maximal reuse. Mainstream OO languages, on the other hand, are built using all kinds of special syntax that cannot be composed together. If you and everyone around you have memorized the rules, they seem easy, but they are not simple at all. Consider the idea that "braces always mean a block of logic," which conceals a ton of hard-won special-case knowledge: Some blocks must be enclosed with {}, some have optional {}, and some cannot have {} at all. Some blocks are statements and cannot be used on the right hand side of an assignment, while others are expressions. Some blocks are not logic at all, but groupings of related methods (into a class) or classes (into a namespace). Some blocks (method bodies) can be preceded by a throws declaration, but others (class bodies, flow control) can't. Every kind of block has rules about what other kinds of blocks it can nest inside (Can I declare a static method in a finally block? Create a new named class in the else branch of an if?) Familiarity feels simple, but it may not be. Hang in until Clojure syntax gels for your, and your life will be simpler.

Re:Those who do not understand Lisp - (1)

drewhk (1744562) | more than 3 years ago | (#32250254)

Well, clojure's slightly changed syntax shows that there is a need for more visual structure. Our visual systems do not work like formal language parsers -- not necessarily the simplest (or more "elegant") syntax is the best. Also, the richness and complexity of natural languages indicate that (some) complexity is more natural to us.

Anyway, I tried many time to USE Lisp-like languages (scheme, clojure), but I ended up reverting to other languages. On the other hand, I use now Scala daily and moved almost all of my development from Java to Scala.

Re:First! Lisp! Rant! (3, Informative)

stuart.halloway (1813346) | more than 3 years ago | (#32241114)

One of the nice things about Clojure is Rich's willingness to dispense with old names that have gone stale with time. Clojure has no 'car' or 'cdr' functions. 'cons'(truct) lives on, as its mnemonic is useful.

Re:First! Lisp! Rant! (2, Insightful)

Peach Rings (1782482) | more than 3 years ago | (#32241208)

So what, just write your own.
(define (car z)
    (z (lambda (p q) p)))
(define (cdr z)
    (z (lambda (p q) q)))

Re:First! Lisp! Rant! (0)

ari_j (90255) | more than 3 years ago | (#32241340)

I actually like car and cdr, because of the equal length of their names and the ease with which you can combine them in various forms to get specific pieces of a nested list, such as caddaddr. However, my approach to programming is that the name of a function is not as important as the language it finds itself in. You could write car and cdr for Basic and it still wouldn't be a good language to write real software in.

Re:First! Lisp! Rant! (2, Informative)

stuart.halloway (1813346) | more than 3 years ago | (#32241462)

In Clojure you would likely use destructuring to dig pieces out of a sequence, avoiding explicit function calls altogether. Agreed that languages need more than just good naming conventions. In Clojure's case, that 'more' is a careful set of abstractions, including some for modeling time. A good conceptual overview on time, state, and identity is online at http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey [infoq.com] .

Re:First! Lisp! Rant! (1)

camperdave (969942) | more than 3 years ago | (#32242020)

What meaning does Contents of Address portion of Register and Contents of Decrement portion of Register have for anyone? Only 123 of the IBM 704s were built and sold, and they have long since disintegrated into the dust from which they were formed. The thing ran on vacuum tubes for goodness sakes! IBM sold its last one before Kennedy took office.

Re:First! Lisp! Rant! (0)

Anonymous Coward | more than 3 years ago | (#32242160)

Well, Newtonian physics or calculus for instance were also developed long before Kennedy took office. Does that make them any less valid than they were, say, 50 years ago?

Re:First! Lisp! Rant! (0)

Anonymous Coward | more than 3 years ago | (#32242420)

Not a stupid question at all seeing as how we're talking about IBM 704s and not... functional programming languages or something like that.

Re:First! Lisp! Rant! (1)

ari_j (90255) | more than 3 years ago | (#32243184)

What they stand for doesn't really matter that much. You have to name the two elements of a pair something, and as long as the name is arbitrary it may as well be easily composed the way car and cdr are. But if you want to name them something else, that's fine, too.

I just don't think that a language can be judged based on the names it uses for these things. It's not like they're hard to remember if you actually use Lisp and, in that regard, they are no different from a wide variety of other names in various languages, including but not limited to cout, println, < as a class inheritance syntax, variable sigils, etc.

All that being said, I think we can probably agree that the terminology of the 704 was stupid to begin with.

Re:First! Lisp! Rant! (1)

K. S. Kyosuke (729550) | more than 3 years ago | (#32244696)

What meaning does Contents of Address portion of Register and Contents of Decrement portion of Register have for anyone?

I don't know, what meaning does Source Index, Destination Index and Base Pointer etc. have for anyone?

Re:First! Lisp! Rant! (1)

hoggoth (414195) | more than 3 years ago | (#32245080)

Why is that a big deal?

(defun first (l) (car l))
(defun rest (l) (cdr l))

There. Was that so hard?
(first mylist)
(rest mylist)

No (0, Flamebait)

For a Free Internet (1594621) | more than 3 years ago | (#32241040)

Programmeng is for losers, immigrints and poor people on welfar. If you want to be suxsessful, you need to invest in real estate and electrical surveilince of criminals for JUSTICE and AMERICA!

The JVM is a dying platform. (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32241048)

The JVM is on its way out. With Sun gone, people are unsure of what Oracle's going to do with Java. Although Java and apps targeting the JVM will still be around for a long, long time, anyone with half a mind is thinking twice about targeting it for new application development.

If Sun, and Java, had ended up in IBM's hands instead, things would've turned out much differently. There likely wouldn't be as much doubt as there currently is.

Unfortunately, many people are turning to .NET as an alternative.

Re:The JVM is a dying platform. (1)

Peach Rings (1782482) | more than 3 years ago | (#32241152)

Well the code's there, it's not just going to disappear if Oracle abandons it. And it's free. So if it meets people's needs then there's no reason they should refuse to use it just because it's no longer supported.

Re:The JVM is a dying platform. (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32241270)

An excellent troll attempt, except you sound too much like twitter talking about "M$".

Re:The JVM is a dying platform. (2, Informative)

nvrrobx (71970) | more than 3 years ago | (#32241278)

Can you provide some evidence to back this theory?

Sure, no one knows what Oracle is going to do here except Larry Ellison, but that isn't stopping Java development.

Android?

IBM?

There's already Apache Harmony, and IBM has their JDK. If the Sun/Oracle JVM goes away, it's not the end of the world. As a matter of fact, that would probably be a *good* thing. Java has languished behind C# and .NET in terms of language features (you can argue all you want if they're useful or not), and JDK7 is still a pipe dream. The community would be able to solve these deadlocks and such without Sun's BS control of the language.

Re:The JVM is a dying platform. (0)

Anonymous Coward | more than 3 years ago | (#32241460)

Have you ever done any Android development? Sure, it's using Java the language, but Dalvik is hardly a full-featured JVM. Also, Sun's mobile APIs have been discarded in favor of Android-specific class libraries. Android development can barely be considered Java development.

Apache Harmony is basically a dead project. We haven't seen anything useful out of it yet, and likely never will.

IBM is off in their own world, writing custom software for big clients running on expensive IBM hardware.

It's doubtful the Java community will be able to bring the JVM up to par with .NET, or Java up to par with C#, even if they had full reign. It's mainly a resource problem, rather than one of agreement. It will take a huge amount of effort to make the JVM viable again.

Re:The JVM is a dying platform. (1, Informative)

Anonymous Coward | more than 3 years ago | (#32241704)

Android does not use any variety of Sun JVM. It uses Dalvik, which runs its own bytecode.

But nobody sane is going to build extensions to Java on their own. Without Sun, there's nobody in charge of developing the Java language. It's going to be a long time before it progresses, and the far more likely result is that it will shrivel and die. Good riddance. Dalvik can be adapted to run other languages, and everyone will move on.

Re:The JVM is a dying platform. (1)

Bearhouse (1034238) | more than 3 years ago | (#32245114)

Sure, no one knows what Oracle is going to do here except Larry Ellison

I admire your confidence...

Re:The JVM is a dying platform. (1)

K. S. Kyosuke (729550) | more than 3 years ago | (#32241656)

Oh yes, JVM is dying, and that's why JVM for Java 7 will improve HotSpot and will be eventually merged with JRockit - so that you would be able to monitor the one last breath of the dying platform with one of the best VM monitoring systems in the world - and complemented with a superior GC. All that only so that it could feel well while dying. Sure.

Re:The JVM is a dying platform. (0)

Anonymous Coward | more than 3 years ago | (#32242098)

That sounds fantastic! But I don't think people will want to wait until 2017 or 2018, when that would all finally be production-ready.

Re:The JVM is a dying platform. (1)

DrXym (126579) | more than 3 years ago | (#32243236)

Groovy, Scala, Clojure (which I'd never heard of), Jython, JRuby, Beanshell etc. all say bollocks to that. Java 7 also delivers dynamic invocation which is likely to mean even more new languages will appear that utilise the JVM.

Re:The JVM is a dying platform. (0)

Anonymous Coward | more than 3 years ago | (#32243572)

So, uhhhhh, when will Java 7 actually be production-ready? I know they're saying "late 2010", but that's still a long way off.

Before Java 7, we only ever waited two years between major revisions. Java 6 was released over 3.5 years ago. That's not very promising for what are basically just incremental improvements.

Re:The JVM is a dying platform. (1)

DrXym (126579) | more than 3 years ago | (#32246638)

If you want radical improvements, go mess with Groovy. Java is a mature language with a mature feature set and doesn't change rapidly for pretty obvious reasons. The invokedynamic thing is anticipated by dynamic languages, but it doesn't stop you from using them right now if you want.

Re:The JVM is a dying platform. (1)

Tablizer (95088) | more than 3 years ago | (#32248828)

The JVM is on its way out.

Everything's on its way out. As a society we go through programming languages faster than socks. If you only target "in" languages, you will be spending more time learning than doing. Most languages are "good enough" to get the job done. Stop chasing shiny new features that may improve productivity by 2%, if you are lucky, and when you master it, you'll find it's time to retire anyhow.
       

Re:The JVM is a dying platform. (0)

Anonymous Coward | more than 3 years ago | (#32249038)

I'd much rather write a functor instance than a factory, even though they implement the same mathematical construct. There's much less boilerplate to write. Boilerplate kills productivity.

Re:The JVM is a dying platform. (1)

Tablizer (95088) | more than 3 years ago | (#32249142)

If you go meta, then a dynamic language is generally the smoother route. But there are ways to adjust in static languages. The devil's in the details.

Re:The JVM is a dying platform. (1)

drewhk (1744562) | more than 3 years ago | (#32250296)

Go, use Scala, and you can use functors instead of factories whenever you want.

All languages suck (0, Troll)

yttrstein (891553) | more than 3 years ago | (#32241196)

Since no one and their uncle is using Java for its portability anymore (maybe the nice folks at Limewire still are), and since Java is so piss-poor at multithreading that even with books hardly anyone is willing to attempt it...

It's beyond me why people don't just use a different damn language. I lost my objectivity on this years ago; is Java ridiculously easy to learn for the kids these days or something? Is it like Pascal for the new millenium? I think I'd rather try to make Pascal thread properly than Java, frankly.

Re:All languages suck (1)

abigor (540274) | more than 3 years ago | (#32241352)

Your rant is a bit misguided. Java is no worse at multithreading than anything else. The problem is with threading itself ("share everything"), versus multiprocessing ("share nothing").

Java is so heavily used on the server side that I'm pretty sure all new development could stop tomorrow, and there'd still be near-full employment for Java developers just doing code maintenance for the next 20 years.

It's spelled "millennium", by the way.

Re:All languages suck (1)

yttrstein (891553) | more than 3 years ago | (#32242770)

The only possible way that you could seriously posit that Java is no worse at multithreading than anything else is if you've never actually used anything else in any kind of meaningful way.

Java's intrinsic implementation of multithreading is one of hard mutual exclusion, which is awesome in a few ways, but really crappy if portability is your goal. Which it isn't, anymore, as I covered in my first post. The best thing that anyone can possibly say about Java's intrinsic multithread support is that it's very, very easy to implement.

And that seems to be the clarion call for the "best languages" these days. See the popularity of VB and .NET for details.

Re:All languages suck (0)

Anonymous Coward | more than 3 years ago | (#32244412)

I've never done any Java programming, but I've done quite a bit with pthreads. I'm curious about how Java's implementation of threading affects its portability. Can you explain what is "hard mutual exclusion"? Google only returns 3 hits. How does it affect portability? Thanks.

Re:All languages suck (1)

jonabbey (2498) | more than 3 years ago | (#32245036)

Java's strength in a multithreading context is due to the fact that multithreadedness was built into the language, and library authors and programmers have known to explicitly document what libraries are safe for multithreaded use and which are not.

Java the language provides just enough support (the Hoare Monitor and explicit memory model) to enable higher level thread-aware libraries, like the Java 5 concurrency classes.

Using those higher level classes can give you really good support, better than anything this side of Erlang, anyway.

Re:All languages suck (1)

abigor (540274) | more than 3 years ago | (#32245884)

To be honest, I have used lots of other languages to do multithreaded programming for many years - C++, C, and Python most recently. They all use critical sections etc. (ie mutual exclusion, as you mentioned) to hide stuff.

It's why I generally dislike threaded progamming - the "share everything" model is fundamentally wrong, in my opinion, which I mentioned in my original post. It sounds like you agree with this position.

I realise that other languages, like Erlang, use variants of the Actor pattern to exchange state - classic multiprocessing (I am a fan of Python's multiprocessing module). And I also realise that Erlang isn't using processes, but instead threads, so I guess it's an exception to my "all languages do threads badly" position. But it's not "typical" threaded programming.

I suppose I took exception to the fact that you were picking on Java in particular, rather than the entire family of languages (Java, C, C++, etc.) that does multithreading badly.

Re:All languages suck (1)

QuoteMstr (55051) | more than 3 years ago | (#32246410)

And I also realise that Erlang isn't using processes, but instead threads, so I guess it's an exception to my "all languages do threads badly" position. But it's not "typical" threaded programming.

It's not "threading" that you're opposed to. Your actual position (which is very sensible) is that it's a bad idea to mix concurrency and shared memory. Erlang actors don't share memory with each other (at least at the Erlang level), which is why you say threading is okay in that instance. You can write a program in C that passes messages like Erlang processes do and it'd be almost as pleasant.

Re:All languages suck (1)

drewhk (1744562) | more than 3 years ago | (#32250344)

In Java there are other abstractions than threads, just look into the concurrent package.

Also, Clojure supports STM (Software Transaction Memory)
and Scala supports Actors

The thing is, that there is no silver bullet.

STM does not scale really well.
Actors' message passing, asynchronous nature will make even trivial code quite complex -- we implemented blocking calls for a reason!

Sometimes I just go back to plain old threads as they solve the problem better.

Re:All languages suck (2, Interesting)

bb5ch39t (786551) | more than 3 years ago | (#32242250)

I f you don't like Java's multithreading, give Erlang a look. An interesting functional programming language.

My impression (0)

Anonymous Coward | more than 3 years ago | (#32241200)

Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine

I'll pass.

While FP permits some useful constructs (like Ruby's blocks), writing everything as a FP is a pain in the ass. Combining FP with Java cranks it up from mildly interesting albeit somewhat annoying to full-blown annoying.

Posting as anonymous because it's a knee jerk reaction. I just can't stand the bloat associated with the JVM.

Re:My impression (3, Informative)

eldavojohn (898314) | more than 3 years ago | (#32241324)

Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine

I'll pass.

While FP permits some useful constructs (like Ruby's blocks), writing everything as a FP is a pain in the ass. Combining FP with Java cranks it up from mildly interesting albeit somewhat annoying to full-blown annoying.

Well, had you read a bit more ... or even read the summary ... you might have noticed that you can interact between Java and Clojure. To the point that -- as is pointed out in the book -- you could isolate packages in Java that have little "side effects" (meaning they are good candidates for pure functional programming) and you could optimize them from a functional standpoint. Which is hypothetically much much easier for some tasks. You do not have to write a whole project in Clojure to take advantage of this. I hope this was clear in my review.

Posting as anonymous because it's a knee jerk reaction.

You can say that again ...

I just can't stand the bloat associated with the JVM.

You might end up liking Clojure much more than you think. What if you didn't have any objects so that the garbage collector rarely (if ever) had to run? This is what Clojure could offer you with the platform pervasiveness and audience that comes with the bloated JVM.

Re:My impression (2, Insightful)

metamatic (202216) | more than 3 years ago | (#32243432)

While FP permits some useful constructs (like Ruby's blocks), writing everything as a FP is a pain in the ass.

Any programming paradigm is a pain in the ass when used exclusively.

Procedural programming, with no OO features or first class functions available? Absolute pain in the ass.

Pure object-oriented programming, where you're not allowed to write simple procedural code for (say) OpenGL, but are forced to turn it all into objects? Absolute pain in the ass.

Pick the paradigm that suits the problem.

Re:My impression (0)

Anonymous Coward | more than 3 years ago | (#32247892)

Scala mixes functional and object paradigms. Seems promising to me.

Re:My impression (1)

shutdown -p now (807394) | more than 3 years ago | (#32249176)

It's not just Scala. It's the new mainstream. Java of all things is getting closures in v7 (see lambda-dev [java.net] mailing list for the ongoing discussion of the language changes).

On .NET front, closures have been there for 5 years now (since v2.0) in C#, and for 2 years in VB (!), and they come complete with type inference - where in Ruby you'd write something like xs.find_all {|x| x > 0}, in C# these days it's xs.Where(x => x > 0) - spot 10 differences... And then, of course, LINQ - which is just a fancy name for list comprehensions. And F#, which is explicitly designed as hybrid OO/FP from the start (unlike C#, which started as typical OO language, and FP gradually creeped in over time), much like Scala.

Then, of course, Ruby - where hybrid OO/FP style is extremely pervasive from the most fundamental libraries to all frameworks - and Python, which is more imperative in typical usage, but hey, it's got "lambda" as a keyword in it, too!

Heck, even C++0x has got closures, even if they are pretty low-level with respect to things such as lifetime of captured variables (but, they, it's C++).

Frameworks are catching up, too. A lot of new ones for .NET have APIs that are pretty much designed around the use of lambdas, even if you could, in theory, avoid them - if you try really hard. Java is lagging behind somewhat due to the lack of short and expressive syntax for closures so far (anonymous inner classes are horrendously verbose and rather limiting), but even then, the main reason why they are trying to get that into Java 7 is because there is already a line-up of libraries - most importantly, for high-level parallel programming - that pretty much need lambdas to be usable.

Oh, and Grand Central Dispatch and __block on the most popular mobile development platform today - 'nuff said.

To sum it up, if someone hasn't grokked first-class functions yet, they'll be relegated to the role of supporting legacy code in a few years or so, similar to how COBOL is handled today. Which may not be a bad thing for everyone, but still... you've been warned.

Re:My impression (1)

drewhk (1744562) | more than 3 years ago | (#32250362)

Scala is uber-cool. I use it daily now -- I moved from Java 2-3 months ago.

However:
  - tool support is very infant
  - documentation sucks
  - books and introduction materials concentrate on the shiny new things, not the day-by-day use. This can confuse newcomers as there is a lot of stuff to digest -- but you rarely use (although later you should learn).

Re:My impression (1)

drewhk (1744562) | more than 3 years ago | (#32250400)

Exactly! Wery well said.

My problem is the people who always strive for some divine "elegance". If someone (especially an academic) calls something "elegant" you can be 99% sure that it is pain in the ass in practice.

  - Elegant theorems are usually oversimplified -- therefore unusable in practice (at least in the original form)
  - Elegant proofs are too compressed -- you are not able to learn from them, because the original ideas and failures of the prover got weeded out. They need a mental reverse engineering without "source code" or "documentation"
  - Elegant programming languages are too opinionated and constrained -- pure OO, pure FP, pure whatever. Static vs Dynamic typing.

etc.

Some Guidance (0, Flamebait)

ari_j (90255) | more than 3 years ago | (#32241296)

As you read through the many comments that will be posted on this article, please keep the following advice in mind: People who spell it LISP are not qualified to judge modern (read: post-1984) Lisp-family languages, probably having 100% of their exposure come from a one-hour lecture and small homework assignment in a programming languages course taught by someone who thought that Common Lisp is a single-paradigm functional language.

Re:Some Guidance (0)

Anonymous Coward | more than 3 years ago | (#32241518)

How cavalier of you! Go get 'em Captain Uppercase!
 

Re:Some Guidance (0)

Anonymous Coward | more than 3 years ago | (#32246970)

Not really flamebait. There's a concept I picked up in a college class that says, to paraphrase, let the group of people pick what they want to be called, and use that. The lisp community avoids using "LISP." It's an archaic term. If the Lisp Community says they call it Lisp, you too should call it Lisp.

As far as paradigms, Common Lisp is probably the most paradigm neutral language I've ever used. It's also pretty damn cool.

As for Clojure, Java is already losing out to Ruby on many websites. If I want to use a lisp, I'll just use Common Lisp with Hunchentoot or Weblocks for any web-related stuff.

Re:Some Guidance (1)

ari_j (90255) | more than 3 years ago | (#32248590)

Exactly. My comment was a metric to help people judge how knowledgeable others are when it comes to actually writing Lisp code. People who spell it LISP are generally much less so.

Clojure is worth a serious look (2, Informative)

prpatel (1813544) | more than 3 years ago | (#32241688)

"Programming Clojure" is a great book. Any book on a new programming language is going to evangelize the language - it's up to the reader to keep an open mind and decide for herself that it's a good fit for what they do. The book is started to get a bit dated now with Clojure up to release 1.2 now, but is still worth getting in eBook form to get a good understanding of the language fundamentals. I would also recommend the "Joy of Clojure" which is in early-access from Manning. They take a different approach to learning Clojure and are both useful to learn Clojure. Even if you aren't planning of using Clojure, it's worth a read to understand some FP concepts and apply them in [insert your fav lang here].

cue new business buzz-word (1)

nimbius (983462) | more than 3 years ago | (#32241846)

in three...two...one...

Asynchronous and self modifying code. (1, Interesting)

Mybrid (410232) | more than 3 years ago | (#32241932)

In all seriousness there are two concepts are are especially onerous and difficult to do well in computer science:

1.) Asynchronous code (threads).
2.) Self modifying code (functional programming).

Both concepts are difficult for typical developers to get right. What the world needs is a revolutionary approach to these two topics such that average developers have the necessary tools to produce quality code for multi-core machines.

Someone needs to take design patterns to the concrete level and create design pattern libraries that model asynchronous and self-modifying code in robust ways that the common API programmer can use.

In my opinion trying to bring robustness to asynchronous code by using self-modifying code is going the wrong direction: compounding one onerous concept with one just as equally onerous.

Re:Asynchronous and self modifying code. (0)

Anonymous Coward | more than 3 years ago | (#32242264)

FP is no more "self-modifying" than OO is.

And you clearly haven't looked at Clojure's strategy for dealing with asynchronous code.

Re:Asynchronous and self modifying code. (1)

Mybrid (410232) | more than 3 years ago | (#32242968)

http://en.wikipedia.org/wiki/Self_modifying_code#High_level_languages [wikipedia.org]

Some high level languages/ interpreters such as SNOBOL4, the Lisp programming language...

If one is really going to claim that Lisp is no more "self-modifying" than OO, I'd invite you to defend this on Wikipedia.

A good FP design dynamically creates and composes anonymous lamba functions on the fly, myself and professors at Berkeley would argue the very essence of FP. Never have I seen this spelled out as a requirement for OO.

If you really want to be honest about this, visit CPAN and do a catalog of all the FP in the thousands of modules there. Every developer has FP at their finger tips: how many do it? Perl's eval function does allow one to create lamba functions, but is this a common design pattern? Most Perl eval code is for exception handling, not for processing strings of code.

Re:Asynchronous and self modifying code. (4, Informative)

Nadaka (224565) | more than 3 years ago | (#32243866)

You are mistaking how you use certain functional programming languages for what functional programming is.

There is no requirement that a functional language allow self modifying code, only that it is expressed as the composition of functions, is stateless and avoids mutable data.

Re:Asynchronous and self modifying code. (1)

Mybrid (410232) | more than 3 years ago | (#32244204)

There is no requirement that a functional language allow self modifying code, only that it is expressed as the composition of functions, is stateless and avoids mutable data.

FP without lambda functions, eh?

Re:Asynchronous and self modifying code. (0)

Anonymous Coward | more than 3 years ago | (#32244324)

Lambda functions are not "self-modifying code". You appear to be confusing the "eval" function with lambda functions.

Or, you have some very serious gaps in your understanding of how functional languages are implemented.

Re:Asynchronous and self modifying code. (1)

Sneftel (15416) | more than 3 years ago | (#32244338)

You seem to have this weird idea that lambdas == self-modifying code. It's just the opposite -- lambdas are the alternative to self-modifying code. Lambdas represent the ability for code to create other code, without having to modify any existing code. In fact

Re:Asynchronous and self modifying code. (0)

Anonymous Coward | more than 3 years ago | (#32248726)

The GP has thrown around the term lambda functions in at least a half-a-dozen posts. He's latched on to a piece of jargon I'm not sure he completely understands.

Re:Asynchronous and self modifying code. (1)

giuseppemag (1100721) | more than 3 years ago | (#32244246)

You are missing a big chunk of functional programming: functions as data. The ability to treat functions as data means that you can pass them around, generating code that is very similar to OO virtual methods: so much so that a struct of functions ({'a -> 'b, 'b -> 'c}) could be easily seen as no more than an interface or an abstract class.

Re:Asynchronous and self modifying code. (1)

hey! (33014) | more than 3 years ago | (#32245972)

Permitting self-modifying code and requiring that are two different things entirely.

The possibility of self-modifying code is entailed in a language which allows code as data. That's not tantamount to self-modifying code either. Compilers take code as data and generate code as output but they aren't self-modifying.

Data formats are essentially special purpose programming languages. That's clear to anyone who's ever looked at a postscript file, but it's also true of things like word processing formats. The distinction between code and data is arbitrary. Code is data at the machine language level.

Now it's true that *usually* self-modifying code is a bad idea. But the design philosophy that it's important to prevent programmers from deliberately making bad design choices is broken.

Re:Asynchronous and self modifying code. (1)

AReilly (9339) | more than 3 years ago | (#32247772)

"creating and composing anonymous lambda functions on the fly" is usually referred to as closing over lexically-scoped variables. It is certainly something that happens as a common idiom in functional languages, but it is *not* self-modifying code. It's more like creating an ad-hoc object that holds some data, and has an over-ridden "operator-()" (to use a C++ idiom).
Yes, many lisps can and do generate code at run-time. So do several object-oriented languages, like Smalltalk. There are many dialects of lisp (including common lisp and scheme) that compile to pure executable code, either directly or through C, and have no compiler in the result. No compiler or self-modifcation, but they still operate with closures.

Re:Asynchronous and self modifying code. (1)

shutdown -p now (807394) | more than 3 years ago | (#32249204)

If one is really going to claim that Lisp is no more "self-modifying" than OO, I'd invite you to defend this on Wikipedia.

GP is claiming that FP is no more self-modifying than OO. He is entirely correct - indeed, just looking at the list of languages, most FP ones are not self-modifying. Indeed, even large families of languages that are considered "stereotypically FP", such as ML, are not self-modifying.

There's a good reason for that, too. A large part of FP deals with advanced static typing systems, and it's damn tricky to combine that with dynamic code generation - how do you typecheck, then?

Also, ironically, the language that is perhaps closest to "self-modifying" - Common Lisp - isn't particularly functional: it has more imperative constructs, and general philosophy that's stronger aligned with imperative approach rather than declarative/functional one, compared to most other Lisp dialects (and most notably Scheme).

Re:Asynchronous and self modifying code. (4, Informative)

stuart.halloway (1813346) | more than 3 years ago | (#32242332)

"Functional programming" and "self-modifying" code are closer to opposites than synonyms. Functional programs work with immutable data, eliminating the confusion that ensues when things can change behind your back. Clojure makes functional programming efficient (via persistent data structures) and accessible to mainstream developers (on the JVM). Also, Clojure connects FP to an understandable model for state and time (see http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey [infoq.com] ). People have been taking design patterns to a concrete level for years now, it's called copy/paste reuse. Lisp has had the design patterns problem solved for decades, and Clojure is no exception.

Re:Asynchronous and self modifying code. (0)

Anonymous Coward | more than 3 years ago | (#32243242)

Pure functional programming is not self-modifying, in my understanding.

However, the introduction of macros breaks that in some sense. You can create the macro code, pass it as an argument, get a new function in return and evaluate it. Still purely functional? Perhaps, but "looks like a duck, quacks like a duck". It's self-modifying code the way I see it.

It's funny. I once turned in an assignment (in assembly language) that used a small bit of self-modifying code. I thought it was an elegant approach to the given problem. The professor marked me down for it! Self-modifying code was considered BAD.

Now self-modifying code is "metaprogramming" and there are people who think it's "powerful" and good. Funny how that works.

I agree with the general idea of your post. If not too many people can grok it, it probably shouldn't be promoted. In particular, self-modifying code, call/cc, and even the familiar fork() call. I don't use them unless the problem is absolutely SCREAMING for them as the solution. And when you do use these bizarre branching, non-local jumping, kinds of things--extra comments to explain what you are doing are a good idea... unless it's a common idiom in the language.

Re:Asynchronous and self modifying code. (1)

shutdown -p now (807394) | more than 3 years ago | (#32249244)

However, the introduction of macros breaks that in some sense. You can create the macro code, pass it as an argument, get a new function in return and evaluate it. Still purely functional? Perhaps, but "looks like a duck, quacks like a duck". It's self-modifying code the way I see it.

Can you point out the "modifying" party in your sequence of actions? Combining code (and data in general) is not the same as modifying it, you know...

It's funny. I once turned in an assignment (in assembly language) that used a small bit of self-modifying code. I thought it was an elegant approach to the given problem.

Back in the days which most /. readers (including myself) haven't seen, self-modifying code wasn't only normal, but effectively required. For example, some older Soviet mainframes had opcodes for array access, where the index was always a hardcoded integer - so, to write a loop that iterates over an array, you had to patch up the command that accesses array elements on every iteration, incrementing the index part.

Re:Asynchronous and self modifying code. (4, Informative)

Nadaka (224565) | more than 3 years ago | (#32243346)

2: functional programming and self modifying code have nothing to do with one another. functional programming transforms a set of inputs into a set of outputs without reference to any external state. It is a purely mathematical expression. Functional programming languages can be used to write self modifying code, but so can can most languages.

1: if you understand what you are doing, asynchronous programming is easy. All you have to do is prevent screwing up the shared state between threads. Since functional languages have no state to share, you can avoid 99% of the pitfalls of dealing with threading.

I deal with threading every single day. Problems occur when the problem is intractable (and then nothing can help it split), the solution is poorly designed (to much shared state), the language is poorly documented/designed (ambiguous thread safety, inability to be thread safe) or the developer just does not know what they are doing.

Functional programming is good at threading because it eliminates shared state completely. The question is no longer "can I split this, what do I have to rewrite from scratch, and will it be worth it?", but rather "will splitting this be worth the overhead of creating, context switching and synchronizing the threads?"

Abstracting multi-threading to make the syntax easier for inexperience developers is a mistake unless you can also fundamentally prevent most of the issues that make multi-threading a pain in the ass as well. Adding real closures to more traditional languages like c++, java, c# etc would go a long way towards making multi-threading easier to deal with because the vast majority of problematic code in relation to multi-threading will produce a compile error if used within a real closure.

Re:Asynchronous and self modifying code. (3, Insightful)

Mybrid (410232) | more than 3 years ago | (#32244000)

2: functional programming and self modifying code have nothing to do with one another.

This is the equivalent of saying lamda functions have nothing to do with functional programming.

1: if you understand what you are doing, asynchronous programming is easy. All you have to do is prevent screwing up the shared state between threads. Since functional languages have no state to share, you can avoid 99% of the pitfalls of dealing with threading.

Therein lies the rub and I'm glad you put it out there. Take any class of computer science students you wish and test them on asynchronous programming and synchronous programming. Guess which one will have the lower scores? Not for all people though, and presumably you are one of those for which asynchronous programming comes natural and easy too. Therein lies the rub. This concept also applies to functional programming vs imperative and came up in a code review I had recently for some Perl code. The reviewer asked my why I used "for loops" as opposed to "map". I never use map. I said because it has been proven time-and-time again that people do not understand "map" as well as they do "for loops", especially the side effects in Perl (not truly functional). There is no performance difference either way, but there is a human difference. I argue my code is more maintainable at the expense of a few lines of ASCII text. You have no idea if the person following you finds what you find to be understandable equally understandable and in the case of "map" using a for loop is trivial; the cost to me is nothing and the opportunity for maintainability greater.

Re:Asynchronous and self modifying code. (1)

DiegoBravo (324012) | more than 3 years ago | (#32248316)

> Not for all people though, and presumably you are one of those for which asynchronous programming comes natural and easy too. Therein lies the rub.

It's really easier to write multithreading code that works "most of the time" (than the ST counterpart.) What's difficult is to discover and avoid the potential race conditions; most people just assume it's ok if their 30 functional unit tests pass clean.

Re:Asynchronous and self modifying code. (1)

poopdeville (841677) | more than 3 years ago | (#32249074)

This is the equivalent of saying lamda functions have nothing to do with functional programming.

No it's not. The whole point of functional programming is to maintain referential transparency. It is literally impossible to modify a named value, including functions.

Self-modifying code is what you get when you make your imperative, referentially opaque code modify itself. You CANNOT do that in a pure language. Although purity isn't the gold standard in functional programming, it is a goal functional programmers strive for unless it is absolutely necessary to break that very important (and conceptually clarifying) assumption.

Re:Asynchronous and self modifying code. (2, Insightful)

arevos (659374) | more than 3 years ago | (#32250196)

2: functional programming and self modifying code have nothing to do with one another.

This is the equivalent of saying lamda functions have nothing to do with functional programming.

No, it's equivalent to saying that lambda functions have nothing to do with self-modifying code.

I'm not sure where this confusion of yours has arisen. Why would you think an anonymous function is self-modifying code?

Re:Asynchronous and self modifying code. (2, Insightful)

drewhk (1744562) | more than 3 years ago | (#32250510)

Asynchronous programming sucks big time (at least for programs that are beyond trivial). There is a reason for the idea of "blocking calls" -- it makes code much more readable. Although the asynchronous model leads to faster code.

I earn part of my money by doing Discrete-Event Simulations, which are by their nature much like Actors - everything is done through message passing, and asynchronously (i.e - no blocking calls).

It always make me twitch when people come and try to sell abstractions like STM or Actors as the Final and Ultimate Answer. There is no silver bullet, I had to learn it the hard way.

Re:Asynchronous and self modifying code. (1)

master_p (608214) | more than 3 years ago | (#32250394)

I deal with threading every single day...the language is poorly documented/designed (ambiguous thread safety, inability to be thread safe)

I also deal with threading every single day, and in C++, which is a poorly designed language as you describe it. But I don't have any problems with it, due to the following simple conventions:

  1. synchronization primitives must always be locked in the same order and unlocked in the exact reverse order.
  2. races between threads are solved by sending results in another thread.

I have found the Actor model to be an excellent solution to threading. I've recently coded a slightly complex c++ app that had between 1 and 30 threads, all threads being different actors talking to each other, and I had no real problem with threading. The data sent between actors were immutable, and if I wanted to share mutable data between actors, then those data became actors themselves. Actors communicated their results to the environment using asynchronous signals (i.e. signals and slots that fired in the context of the sender but activated in the context of the receiver, again as Actor messages).

Re:Asynchronous and self modifying code. (1)

QuoteMstr (55051) | more than 3 years ago | (#32243766)

If metaprogramming is self-modifying code, then every compiled program is self-modifying: there is no fundamental difference between translating a program to assembly and translating it to the same language in which it was written; if macros were inherently self-modifying, MACROEXPAND would be useless. If closures were self-modifying, then every C callback system that incorporated an opaque user-data parameter would also consist of self-modifying code.

In all my years*, I have seen no poster demonstrating a more profound cognitive deficit than yours. It's not ignorance. It's stupidity: by using technical terms, you demonstrate that you have some relevant experience. But your ideas show such a marked inability to connect these terms to each other in a consistent and coherent way that I wonder whether you've suffered some localized damage to the logic portions of your brain. Please, see a doctor. There are therapies available which can restore a semblance of a normal life.

* check my UID

Clojure's LISP does not enforce abstraction (1)

peter303 (12292) | more than 3 years ago | (#32243110)

I am concerned about using this for large software engineering problems about having data and methods scattered loosely about the code because Clojure does not enforce encapsulation. That brings up the old joke about "Chinese programming in LISP": an hour later you will have forgotten what you coded. More recent versions of LISP such as Scheme implement OOP more soundly that the version in Clojure.

Soem of the nice thing in Clojure like the rich set of set-notation are not LISP-specific. There is talk of putting these in Java 1.8.

Re:Clojure's LISP does not enforce abstraction (3, Informative)

stuart.halloway (1813346) | more than 3 years ago | (#32243344)

I am not sure if you know what you are concerned about, as you use the word 'abstraction' in the title of your post, the word 'encapsulation' in the first sentence, and then conclude with 'OOP'. So I will take them one at a time. (1) Clojure is built around abstractions, there is a rich set of carefully designed interfaces. (2) Clojure's approach to data is certainly not what an OO person would expect. In Clojure, *data* encapsulation is considered folly. However, this must be taken in the context of several synergistic ideas: persistent data structures, the unified update model, and a rich, general approach to data. (3) For an introduction to Clojure's approach to OO concepts, check out my video introducing clojure protocols (http://vimeo.com/11236603). I would welcome (and have been seeking) an informed debate on the soundness of protocols in comparison to the options available in other OOP languages.

Re:Clojure's LISP does not enforce abstraction (1)

shutdown -p now (807394) | more than 3 years ago | (#32249270)

Clojure's approach to data is certainly not what an OO person would expect. In Clojure, *data* encapsulation is considered folly.

Wait, what? How can data encapsulation be "considered folly", in a language which is quite deliberately called "Clojure" - when closures are, perhaps, the most succinct way to tightly encapsulate data?

Just close over some scoped variables, and return the closure from that scope [wordpress.com] - and there's your encapsulation!

In fact, this technique is widely practiced in JavaScript today for exact same purpose.

Re:Clojure's LISP does not enforce abstraction (1)

poopdeville (841677) | more than 3 years ago | (#32249120)

In my experience with functional languages, the trouble isn't remembering what you coded, but where you put it. Reading functional programming is really easy. You barely even have to understand the operators, as long as you understand that a (mathematical) function is a certain type of relation (a many-to-one relation). Equivalently, a function is the same as a set of ordered pairs with the property that if (x,y) and (x', y') are in the set, and x = x', then y = y'. Equivalently a (computable) function is a state machine. Etc.

Notice that I put "mathematical" in there. There are plenty of levels of abstraction in a language like Haskell, but the point of them is to let you define (mathematical) functions at various points of the computation cycle: before compile time, at compile time, at run time; or on different "kinds" of objects. As long as you find the two key types at are being joined into a functional relation, you can read the code.

"This fits me perfectly as a Java programmer," (3, Interesting)

Bob Hearn (61879) | more than 3 years ago | (#32243160)

Exactly. That was the big problem I had with the book: it's written for Java programmers. I am intrigued by the language, but I would much prefer a book that treats the language on its own terms.

Functional programming, JFYI (0, Redundant)

Mybrid (410232) | more than 3 years ago | (#32243474)

http://en.wikipedia.org/wiki/Functional_programming [wikipedia.org]

Concepts A number of concepts and paradigms are specific to functional programming, and generally foreign to imperative programming (including object oriented programming). However, programming languages are often hybrids of several programming paradigms so programmers using "mostly imperative" languages may have utilized some of these concepts.[24] Comparison of functional and imperative programming. Functional programming is very different from imperative programming. The most significant differences stem from the fact that functional programming avoids side effects, which are used in imperative programming to implement state and I/O. Pure functional programming disallows side effects completely. Disallowing side effects provides for referential transparency, which makes it easier to verify, optimize, and parallelize programs, and easier to write automated tools to perform those tasks. Higher order functions are rarely used in older imperative programming. Where a traditional imperative program might use a loop to traverse a list, a functional style would often use a higher-order function, map, that takes as arguments a function and a list, applies the function to each element of the list, and returns a list of the results.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...