Comment Re:This is not news for nerds! (Score 1) 1183
Comment Physical security? (Score 2) 374
What are you doing with your phone that makes it possible that you've had 3 stolen from you? Are these thefts physically violent? I just can't imagine, for myself, that it would be super-easy to get my phone from inside my pocket or out of my hand without violence.
Submission + - Strong AI and the imminent revolution in robotics (zdnet.com)
An anonymous reader writes: Google director of research Peter Norvig and AI pioneer Judea Pearl give their view on the prospects of developing a strong AI and how progress in the field is about to usher in a new age of household robotics to rival the explosion of home computing in the 1980s.
Submission + - Programming Clojure by Stuart Halloway (oreilly.com) 2
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. It 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 as 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. It was released in May of 2009, it's currently the only book out there devoted to Clojure and the introduction is written by the languages 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.
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 langauges. 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 on O'Reilly, Amazon or 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.
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 langauges. 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 on O'Reilly, Amazon or 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.
Comment Re:!newsfornerds (Score 5, Insightful) 413
Great, block politics from your home page. This is not a tech news site, it is a news for nerds site. If you don't like politics, feel free to modify your preferences. This appointment could have very significant consequences on dozens of issues to be decided at the Supreme Court level. Many of those, no doubt, will be news for nerds as well.
Comment Re:Ahh Slashdot (Score 4, Informative) 550
Your point would make sense if it were at all true that the common description of the law had any legal weight outside of the actual text of the law and the applicable case law. That you can call something the "Was Being Bad" law doesn't mean that's what legal standard is applied by judge or jury. Presumably this description is applicable in New York:
http://law.onecle.com/new-york/penal/PEN0195.05_195.05.html
A reasonable person may disagree with the law or it's exact wording (we are "free" to do so), but don't imply that the title of the law somehow proves a vague catch-all conspiracy.
Comment Re:Smoking -bah hum bug! (Score 1) 383
I'm been using it on Ubuntu for a while now. .
Submission + - Major bug in snow leopard deletes all user data (neowin.net)
inglishmayjer writes: From the article:
"Reports have been cropping up on the Apple Support forums that users have been losing all their data due to a nasty bug in Snow Leopard, Apple's latest Operating System. Many users are reporting that all settings are being reset and most data is gone, according to iTWire."
The issue is caused by logging into a guest account, the user finds "that their account has been fully reset with all data wiped and lost — the account is like a brand new one."
D'oh.
"Reports have been cropping up on the Apple Support forums that users have been losing all their data due to a nasty bug in Snow Leopard, Apple's latest Operating System. Many users are reporting that all settings are being reset and most data is gone, according to iTWire."
The issue is caused by logging into a guest account, the user finds "that their account has been fully reset with all data wiped and lost — the account is like a brand new one."
D'oh.
Submission + - Is working for the gambling industry a black mark? 5
An anonymous reader writes: I'm a recent university graduate. I and have been offered a software developer position in a company that supplies software to the gambling and betting industry. At first I was very excited about the opportunity. However, a few of my friends have told me that working for the gambling industry will put a permanent black mark on my career as a software developer. I don't know that many people in the industry with experience in hiring. Google has not helped in any way. And everybody else I ask doesn't know. So I'm asking slashdot. In your experience is this true? When you hire developers, is the fact that they worked for a gambling company a big turn off? Also, I'm currently in the UK, but would like the freedom of working in US or somewhere else later on in life. So experience from anywhere in the world is welcome.
Comment Summary (Score 1) 262
Sadly this summary has no information at all, provides no description of the issue to be discussed, and provides no content other than links to other sources. Perhaps the submission could have contained:
- A description of the issue at hand
- A reason why an uninformed reader would care about patent royalties at 24-40 dollars (per what?)
- An explicit argument about why this is or is not a good thing
I have been a member of this website for years, and while I am as guilty of not reading the article(s) as the cliche suggest of most readers, I still do so if the summary has some, any, information as to why I should. This summary provides no context whatsoever to evaluate the article's worth nor describes in any way it's content.
Submission + - Intel cache poisoning is dangerously easy on Linux (networkworld.com)
Julie188 writes: "A researcher recently released proof-of-concept code for an exploit that allows a hacker to overrun an Intel CPU cache and plant a rootkit. A second, independent researcher has examined the exploit and noted that it is so simple and so stealthy that it is likely out in the wild now, unbeknownst to its victims. The attack works best on a Linux system with an Intel DQ35 motherboard with 2GB of memory. It turns out that Linux allows the root user to access MTR registers incredibly easily. With Windows this exploit can be used, but requires much more work and skill and so while the Linux exploit code is readily available now, no Windows exploit code has, so far, been released or seen. This attack is hardware specific, but unfortunately, it is specific to Intel's popular DQ35 motherboards."
Comment Re:I just call them Web Designers (Score 1) 586
Interesting, you've misinterpreted me I think. I'm not sure I said it was a rote task; I said it wasn't web design. I didn't intend to put web production people "below" anyone. They have a very specific skill, a valuable one, that isn't the same skill that web designers have.
In many roles and organizations these may very well be the same people. In my organization, they are typically not as it's hard to find people who are experts at both tasks. The designers produce Photoshop documents of the web page, the producers optimize, slice, and produce HTML and potentially some UI effects.
So while I agree that you could call them designers in some sense (the individuals I know who do this certainly are creative) that muddies the waters a bit when there are people who are Web Designers who don't do what they do. The value is in both roles, and some people, again, fill both roles. But they are nonetheless fundamentally different tasks.
Comment Re:I just call them Web Designers (Score 2, Interesting) 586
These people don't design, they take a design and create web pages from it. We have always called them Web Production Artists or Web Production Specialists. They are not designers, nor developers. Just like the print world, where Print Production is a widely recognized discipline.
Submission + - Space elevators are lethal
Maggie McKee writes: "A new study reports that passengers could be killed by radiation on space elevators. Even travelling at 200 kilometres per hour, passengers would spend several days in the Van Allen radiation belts, long enough to kill them."
Slashdot Top Deals
Whoever dies with the most toys wins.
