kyleburton

If you're interested in learning about them, those two links are going to do a better job of explaining what both Typed Clojure and Schema are that I am across a few comments.

Wrt the typing of Maps and Arrays, what Clojure supports goes way beyond what Java's type system supports: you can specify that the first element of an array has to be of type X, the second is of type Y, the third can be either NULL or Z. For maps, you can specify that a key must have a particular type and must be in the map, with a specific value while other keys may be present (required or not) and you can compose any of the constraints mentioned on the values the keys may take.

This is different from Generics in that Generics constrain to homogeneity for an entire collection.

You could create formal objects in your Java code to express similar constraints, but you're not achieving the same result: a Java object actually has the property (even if it's null) while a map (or an array) with an optional member will only have it if it's present. With Java you'd need many classes to model all the specific combinations. Java's current type system is significantly less expressive and doesn't have the same power. I realize those are subjective. By expressive and power I am referring to whether you can declare an idea in your code or whether you have to write the imperative logic to implement an idea (the former meeting my definition of expression or power).

Thanks for the question.

Clojure supports strong typing if you want it:

https://github.com/Prismatic/schema

https://github.com/clojure/core.typed

These are both libraries that you can choose to use. Both Typed Clojure and Schema are more powerful than Java's type system. By powerful I mean you can declare types and constraints that aren't expressible in most type systems (eg: an object can not be NULL, or a Map or Array must have specific keys or type'd values). Schema is run-time (we only leverage it in development and testing), while Typed Clojure is more akin to compile time.

This is very cool.

I'd pay $ (5ish) for a couple of other ways to use this:

* a bookmarklet that allowed me to select text on my blog or on one of my github pages and analyze it * emacs integration * a command line tool that worked like ispell/aspell to help analyze things I've already written

Philadelphia, PA (full time)

Relay Network - http://www.relaynetwork.com/

-------------------------------------------------------

Relay is a simple and secure way for businesses and customers to instantly connect and share private communications.

We are looking for (multiple) full-stack engineers to join our team. We use Clojure (no previous FP experience required, learn it working with the team), Devops (Chef) and practice Agile (weekly sprints and pair-programming).

-------------------------------------------------------

* Full Stack Engineers - http://www.relaynetwork.com/files/Relay_Software_Engineer.pd... * Front-End Developer - http://www.relaynetwork.com/files/Relay_Front_End_Developer....

For More Info, email me at [email protected]

I lead a team of 4 at a company in the Philadelphia, PA suburbs. We'll be adding more members later this year and Clojure is our primary back-end language (we also use Ruby and lots of JavaScript). We have been quite happy with it for many of the same reasons Alex mentioned.

I am talking about the cultures surrounding these languages and frameworks. Node's community rejects blocking libraries. Java's does not. I've used the non-blocking frameworks in Perl (POE and my own), C (select, and some of the poll variants), Ruby (event machine) and they are fine if you can avoid blocking libraries -- in these communities it is generally acceptable to write blocking libraries. I don't see it as a technical hurdle, I see it as a cultural one.

This. The biggest difference is in the two cultures: blocking is anathema to the Node.js community - they will literally reject libraries or code that blocks because it destroys the entire model; the JVM community does not value non-blocking code - most of the core (JDBC, Networking in general, File system operations) is all written in a blocking style - the JVM community accepts this with the implicit assumption that threads will help assuage those issues.

Python, Ruby and Perl all have the same cultural tolerance for blocking code. The Node.js community has a complete lack of tolerance for blocking code.

I work with the JVM every day (Clojure) and wish it was different wrt the common use of non-blocking code, but it's going to be a long road to get there on the JVM.

Kyle

I think the article is a great explanation. I'm not sure I (exactly) agree with the conclusion "dynamic vars also breaks referential transparency" - isn't it the combination of lexical closure (referring to symbols from outside the function) as well as mutable state that breaks referential transparency?

If I have a function that takes a java collection and returns the count, it has no referential transparency because the collection is mutable, not necessarily b/c of how it's operating on its arguments.

Of course this is one of the things I love about Clojure and Rich Hickey's use of immutability as the default behavior (as often as possible) - much [more] of the Clojure I write has referential transparency, hardly any of the Java I wrote did.

Thanks!

Kyle

One of the advantages I find in pair-programming is that the 'navigator' (the one who's not typing) will often catch this kind of thing as it is happening. "Hey, that's just a while loop, or better yet just use `Clear`". There are other (greater) advantages to pairing, but this example is something we typically avoid before it gets committed.

As nano-tech advances and replicators become more commonplace, hardware will face the same issues with patents and the seeming absurdity of patenting an 'obvious idea'.

In the 1st you could say I snuck JScheme in under the radar when I first introduced it.

For the 2nd I was actively recruited to the team. I personally believe that this was because I made a conscious effort in the fall of 2008 to start being much more active in the community at large. I started doing more visibile things on the internet: a blog, putting up a sandbox on github. I also started speaking at local user groups (god bless them for listening to my first talks and my horrible, horrendous presentation skills).

The 3rd (current) is a startup, where I was also actively recruited into, to join at the time the first technologist at the company. They subsequently left about 7wks later for another startup. Taking on the role as head of technology I became responsible. I mean that in all the gravity of what it implies: I chose Clojure and I am responsible for that - as part of such I must ensure that the organization can keep moving forward and has a plan if I am no longer part of it. To do that I've started a local Clojure group, we have meetings at our office and I ensure that the developers working on my team get every single ounce of technical experience I can transfer to them.

By 'recruited into' I mean that not in the sense that either side used a recruiter. I mean I was approached through my network because of the effort I put into building the netowrk and the effort I put into building a personal brand (as slimy as that sounds, it is working).

Actively working at networking has been wonderful. I can't recommend it enough. I was involved in starting a "tech breakfast" meeting that takes place 1x a month. The local groups (esp volunteering to speak), the breakfast sessions, and buying people lunch (an hour of interesting conversation is totally worth the $10, and every time it has come back to me) has gone a long way to building a local network.

Networking will help - you'll have access to more of the places that might be willing to use Clojure, and more places that would be willing to let you choose the stack.

Be happy to share more if you have more questions.

Regards,

Kyle

I'm at my 3rd organization with Clojure, started in late 2008 (I think). In the first I had used Jscheme as an extension and scripting language for one of our JVM based systems. I moved to Clojure for prototyping tasks, other developers working with me showed interest and we were able to use it for small development tools at first. Once those started to show productivity improvements we were able to leverage it for small and then larger projects. Part of getting it adopted was getting the other devs on the team interested and excited about it.

The second company was with a team that I joined who was specifically looking for Clojure developers. It ended up being 4 developers, only 2 of which really knew any Clojure previously. The other 2 were Ruby devs. We paired over the entire life of the project and it was a very effective way of transferring skill sets - for all involved. We all learned more and more quickly than I've experienced during any other equivalent time on a project.

At my current engagement, I'm the head of tech and was able to choose the technology. I have the permission of the rest of the executive team and given my activity with the local technology community I've had no difficulty finding good developers who are enthusiastic about using Clojure. This may change as we grow, but I know I've still got a pool to pull from.

Choosing a non-mainstream technology is often additional work for whomever is leading the decision in any organization. For me it's been worth it: we've gotten passionate people who are more engaged because we're using something they care about. The fallback is to just go with a more mainstream JVM language (Java) - hasn't been and doesn't seem like it'll be ann issue.

Could that be the basis for an IP based startup? Seems like a clever hack of the patent & legal system surrounding patents. Of course once there is 1 of these, there will be copycats - which could lead to a race to capture the largest share of patents. Patent wars indeed.

Feynman diagrams are the only thing that comes to mind - mathematicians and physicists still use a code-like notation to describe concepts. Are there any examples from those areas to use as a guide?

Looks like a recruiter's dashboard. :/

Thanks!

You're correct, you can set it up for free but you can't maintain it indefinitely for free. I think you only need the $1/mo if you reserve an actual phone number, if you stick w/the sandbox I think it stays as $0.01/min until you deploy for real - Heroku is kinda the same, it's only free if you use minimal resources. That's what I was shooting for: a prototype for effectively free.

Regards,

Kyle

Ah, lein-daemon - didn't know about that, thanks!

I don't think FP is all about concurrency - it's about more than that. In my experience it reduces the possible bugs in code (type inference / checking, referential transparency) - these aspects make concurrency easier to achieve, but that's not all there is to FP.

Policy updated (ianal though), does it work for you?

Thanks, I appreciate hearing that. I had thought of putting an ad in the email, or even adding one to the bottom of the image itself - though I felt like that would be too intrusive and decided against it (adding to the image itself). Thanks for the feedback.

I hadn't considered an API - what do you have in mind? An HTTP post & response? What would you use it for? I just hadn't thought of this since the graphics libraries and routines are readily available. An API seems to cut out any possible ad opportunities - is an api something you'd be willing to pay to use? Thanks for the idea.