adrianm

How do you feel about the possibility of a HAL-9000 like scenario where oversights in the design of the program lead to it exhibiting unpredictable and dangerous decision making behavior under certain conditions?

The novel of '2001' goes into deeper detail than the film regarding the context in which HAL was programmed. To summarize, his mission was to deliberately withhold certain information about the mission from the crew due to the likelihood of xenophobic sentiment developing amongst them if they knew they were traveling to the site of extra terrestrial intelligence. In a sense, he was fulfilling the parameters of his mission in a way which was contrary to the purpose of it. I always interpreted this story as showing us that the more complex a system, the less accurate our predictions of its failure modes are going to be.

I do not think absolute destruction of humanity is likely either, but I also don't think our first steps with AI on this level will be without the loss of life either (of both human and machine). Keep in mind, the same was and is true of space exploration and is essentially an inherent danger of working with the unknown and on the frontier of our knowledge.

I think you're thinking of a master and apprentice (albeit through the lens of a world which resembles that of Westeros...) In any event, not the mentor relationship the OP was inquiring about.

I actually don't view mutation in Common Lisp as a downside. I find writing high performance (usually numerical, but sometimes not) code in Clojure to be painfully obtuse compared to Common Lisp, but I love Clojure otherwise. Writing highly optimized code can be quite elegant in Common Lisp, and I appreciate that when the problem at hand calls for it.

Indeed. Common Lisp is similar with regard to the proliferation of mutation.

The article (especially the headline) implies that the new Macbook is somehow more at risk because of its reliance on one USB port. But if the root of the problem is USB more generally, wouldn't the only "secure" design preclude the inclusion of any USB ports whatsoever? My issue with the article is that by singling out the Macbook (due to its single port) they are not actually contributing any useful information back to the consumer about its potential security. If I'm missing something, I would appreciate clarification.

"You're thinking of that email that someone sent on a mailing list a while back about how LLVM isn't really a bytecode because it includes architecture-specific codes."

No, I'm not. In fact, I have no idea what email you're referencing.

LLVM as an intermediate language (I guess you could call it bytecode if you really wanted to) for compilers of arbitrary languages (expressly not a virtual machine!) is the only point I intended to make.

LLVM is not a VM by any stretch of the imagination. It is an intermediate language for compilers whose primary utility is to provide a common target for code generation and optimization. LLVM's name is a misnomer.

Om is fast at checking if a component's state has changed because you can do a very fast identity comparison on the persistent hash map holding state, but persistent data structures are not faster than their mutable cousins simply because of immutability. That immutability leads to significantly more objects being allocated, which means to really take advantage of these features in a managed language you need a VM with a very high performance garbage collector. This is partly why Clojure on the JVM works so well. That being said, non JIT compiled JavaScript VMs generally provide terrible performance for ClojureScript. I do not believe JavaScriptCore JITs anything, so I don't know how immediately useful ClojureScript with React Native will be outside of toy examples.

You're both talking about two different generations of the demoscene. Bohol oversimplifies the history in the same way you oversimplify the history; you're both tracing it back to the points of reference you're familiar with. That being said, I think a more forgiving interpretation of "The cracking scene, demoscene and games industry was almost exclusively built on Windows." is that the modern state of each scene stems from the mid 90s. I don't believe that would be an entirely false mischaracterization, because Windows' influence has been pervasive on the scene since the mid 90s. In the end, Bohol is looking at it from "when did the greats of today get their start?" and you're looking at it from "when did the greats that influenced the kids in the 90s come from?". At least that's my interpretation of the argument. In a sense, you're both right.

I think that is still a valid concern. Features first hit the C++ API and then slowly migrate to a C expressible subset.

I can't speak for everyone, but I appreciate the mirrors because I enjoy reading and searching through codebases on Github, so having the repository mirrored there is useful.

Just because someone is incredibly passionate about something technical that you don't understand doesn't mean that person has a mental illness. It's pretty clear from reading what he's written that it isn't technobabble or nonsense in the least. Schizonphrenic individuals do not generally write comprehensible and logically sound ideas down. The worst you could characterize graycat's comments as are "quirky". Your comment is both hurtful, since it was made publicly, and completely wrong.

All GC algorithms are not created equal.

What algorithm are you referring to when you say "better throughput at the expense of significantly increased memory usage"?

Also, why is unpredictable latency acceptable for you on servers but not phones? Wouldn't a latency spike on remote requests from an application degrade user experience just as much as if that latency were localized to the phone?

I didn't mean to imply that the original post was not worthy in anyway whatsoever, in fact I think all of the work he is doing in the CL ecosystem is awesome and I look forward to playing around with it soon in my next CL project.

But apgwoz's general point about how we evaluate software is spot on. In general, I think benchmarks and the like have a sort of "woo"ing effect on people (in the James Randi sense), and we should probably take a few moments to reflect on that before making any major architectural decisions. :)

I think this is truly sagely advice.

My grand takeaway from Aphyr's Jepsen series (http://aphyr.com/tags/jepsen) is that the more sophisticated software becomes in the never-ending quest for features and performance, the more likely the fundamentals underlying it have been overlooked, glossed over, or ignored completely.

Out of curiosity, do you know if this translation is used in the Portuguese versions of SimCity?

This is beautiful stuff. Are you looking for contributors? I'd love to work on this with you.

I can't speak for everyone but I can speak for myself: because it makes me happy to program in. I love programming in Clojure. It makes my work a joy and that lets me produce higher quality software over the long term.

More concretely, Clojure's mechanisms for abstraction are both simple and extensible. You can create interfaces (called protocols) for writing polymorphic and efficient code against both your own and existing library classes. Transducers, the topic of the article, are an incredible abstraction that allows you to write powerful transforming functions on sequences of data that are not tied to any concrete representation. This means the same transducers you write will work on lazy sequences, non-lazy collections, and even values asynchronously put on core.async channels (a library for asynchronous programming in Clojure).

I think most languages look weird when you first see them and are unfamiliar with their syntax. But if you give it a chance, the nesting that seems confusing at first might actually come to be something you appreciate.

Actually, you can have real mutable variables as fields in a type, although you should think twice about doing so in practice as mutable variables are often not the solution. But here's an example!

(deftype SomeTypeWithMutableFields [^:unsynchronized-mutable some-mutable-field ^:volatile-mutable another-mutable-field])

:unsynchronized-mutable corresponds to a normal mutable Java variable, and :volatile-mutable corresponds to a Java variable with the volatile modifier.

They are private by default, you can only set! them within the lexical scope of the deftype definition. If you needed to expose fast host mutation to the public, I would create a setter/getter interface (via definterface) and implement it on your deftype and use set! locally to mutate the field there.

Color me impressed with this. Kudos to the author! It's a fantastic example of not only how to progress through concept to implementation with a game, but how interactive development can make this process all the more enjoyable for the developer, with a much faster feedback loop than more traditional (statically compiled) game design allows.

You are very wrong about this. Clojure libraries are a very diverse ecosystem, and even a cursory analysis of the most widely used libraries will prove your assertion wrong. Heck, you can't even make custom printers (for your own types) in Clojure without extending the print-method multimethod.

Please don't speak for the Clojure community as a whole, because it spreads misinformation about both the libraries and the language itself. If you want to relate your personal experiences, fine, but your original post and this both convey a sense of absolutism in your characterization about Clojure's features that are just not true.

One thing I remain unclear about after reading this introduction... How do you reconcile monomorphic lists with function invocation while maintaining homoiconicity? Your use of the terminology here confuses me because elsewhere you claim the first value in a list is of a generic type; but the CDR of any list is also a list. Ergo the CAR of some lists CDR must be generic to maintain consistency. But here's the rub: that means you support polymorphic lists, so clearly I must be misunderstanding you.

Yes. Run some Swift code in Xcode with the debugger and step through its execution; you can see that Objective-C objects proliferate through Swift. Cocoa APIs are especially Objective-C compatible, as to be expected.

This looks like a really fun project. I'd be interested in any good Verilog resources anyone can recommend. Also, does anyone know if there is there an affordable way to get components you design manufactured on a small scale? (Not in the thousands of units, I mean.)

Your last point is just, ugh, oh so true. You don't get to be an expert in any field without diving head first into them at some point as an inquisitive amateur. Having a curious, naive spirit who isn't afraid to do things "the wrong way" and break a few things along the way is something we should be encouraging in our fellow hackers!

The OP's misaligned sense of responsibility honestly terrifies the child in me. I would not be where I am today were it not for the countless circuit boards I went through (nice way of saying completely destroyed) when I was 12.

I think you've hit the nail right on the head. The added complexity of these tools, created ostensibly to simplify configuration, simply cannot accomplish what they set out to do by trading in one language for another.

My experience has been in the reverse, which just goes to show you how bad anecdotal evidence is at proving any point. Without any hard data, it's impossible to say for certain. All I know is that there is definitely enough demand for Clojure work that I didn't have to search for any leads when I left my last job; I already had four promising prospects to choose from that either emailed me directly or messaged me on Linkedin within the previous month.

You claim to disagree with my premise, but you did not address the premise of my statement.

I did not say it was unreasonable to "gain a sense of the uniquely different cultural attitudes and priorities that are prevalent in a society".

Based on your analysis, I think you have misinterpreted both the intent and premise of my comment.

What I actually said was precisely what I did say: that you should not be quick to publicly espouse these generalizations that you have anecdotally observed. To a general audience of people who do not know you, the words that you write on here are the only basis we have on which to understand you as a person, short of getting to know you personally.

Perhaps you have never been on the receiving end of a racial stereotype or generalization, even an "innocent" one. Even if the comments are not made with malicious intent, and believe me I know the OP had absolutely no malicious intent at all, stereotypes can and do make some people uncomfortable to hear.

Why is that? Well, there are lots of reasons. If for nothing else, it makes the member of the group in question the "Other". If only for a brief moment in time the individual ceases to exist; their racial characteristics are being now being discussed, rationalized, and analyzed by the others in the room.

I really just wanted to give my honest advice to a nice guy (the OP), that it would be wise to avoid allowing this sort of discussion be associated with him as a person, unintentionally immortalized by the internet.

Friendly advice: you should think twice before posting long comments where you systematically examine racial generalizations (and dare I say it: stereotypes!) you find to be anecdotally valid.

It's this sort of "reasoning by anecdote" that, while convincing to the individuals relating them, can easily mislead others into believing your conclusions are rational.

Really? I've gotten my fair share of recruiter emails looking for Clojure work. I introduced Clojure into my last job quite easily as well. If you're doing anything Java or JavaScript related, I've found it's pretty easy to get Clojure in the door once people see what you can do with it.