HN user

bitsai

935 karma
Posts27
Comments88
View on HN
blog.gateless.com 4y ago

Gaming Our Way Through the Remote Divide: Remote Culture at Gateless

bitsai
1pts0
theringer.com 9y ago

How Seattle Could Solve America’s Traffic Problem

bitsai
1pts0
techcrunch.com 10y ago

Facebook’s new chatbots still need work

bitsai
2pts1
www.chiark.greenend.org.uk 12y ago

How to Report Bugs Effectively

bitsai
2pts0
www.newrepublic.com 13y ago

The Lethality of Loneliness

bitsai
321pts157
www.dartlang.org 14y ago

Dart: Improving the DOM

bitsai
8pts0
www.ustream.tv 15y ago

Live stream for Rich Hickey's talk at NYC Clojure tonight (6:45pm EDT)

bitsai
6pts1
www.grantland.com 15y ago

Is the Fastest Human Ever Already Alive?

bitsai
7pts0
www.grantland.com 15y ago

Interview with Bill James on Crime

bitsai
1pts0
www.theatlantic.com 15y ago

50 Years of Making Fuzz, The Sound That Defines Rock 'n Roll

bitsai
3pts1
web.mit.edu 15y ago

The next operating system: building an OS for hundreds, thousands of cores

bitsai
101pts38
clojure.blip.tv 15y ago

State of Counterclockwise (Clojure plugins for Eclipse)

bitsai
2pts0
family.go.com 15y ago

Build your own Tron Light Cycle paper model

bitsai
2pts0
ocw.mit.edu 15y ago

MIT OpenCourseWare programming lecture videos (in Python)

bitsai
160pts27
code.google.com 15y ago

Google-diff-match-patch: libraries in multiple languages for sync-ing text

bitsai
8pts0
sourceforge.net 15y ago

Java port of DosBox

bitsai
7pts0
lwn.net 15y ago

Moving to Python 3

bitsai
32pts13
www.boingboing.net 15y ago

Women "computers" of World War II

bitsai
1pts0
lwn.net 15y ago

Lessons from 30 years of Sendmail

bitsai
9pts1
snapframework.com 15y ago

Snap (Haskell web framework) 0.4 released

bitsai
3pts0
deskthority.net 15y ago

Photo overview of original Lisp keyboards

bitsai
11pts2
www.cse.chalmers.se 15y ago

Why Functional Programming Matters

bitsai
2pts0
clojure.blip.tv 15y ago

One Ring to Bind Them: Clojure web development

bitsai
51pts1
www.janestreetcapital.com 15y ago

Experiences with functional programming on Wall Street (Jane Street, 2008)

bitsai
3pts0
www.cam.hi-ho.ne.jp 15y ago

Emacs key bindings in all Windows applications

bitsai
1pts0
groups.google.com 15y ago

Clojure 1.2 RC3 released

bitsai
39pts2
news.sciencemag.org 15y ago

The Physics of a Rolling Rubberband

bitsai
3pts0

"That said I believe front and backend should work closely together. There is no reason that the frontend should be blocked because the API design can be figured out before the backend is written and the frontend can mock out the missing features until they are available."

Came here to say exactly this. At my current workplace, one of the very first steps in any project that involves both FE and BE work is for FE and BE engineers to get together and design the API. Once that's done, work can proceed on both sides in a largely asynchronous and independent manner. And one of the first things to be implemented on the BE is API endpoints with multiple mocks that can be requested by the FE, so the FE can start integrating with the endpoints as early as possible.

Mmm, I've never used Ruby or Rails professionally, so I can't really speak to that. Prior to Clojure, I mostly worked with C++, Java, C#, and Python.

At its core, Clojure is basically just data and functions. Once the switch flipped in my mind, I found that to be simpler and more straight forward than any of the languages I worked with before.

When the majority of your code is side-effect-free, pure functions (and Clojure makes it very easy to structure your code this way), it becomes very easy to reason about. And very easy to test, with minimal ceremony!

P.S. When I was learning Clojure, I kinda devoured all the resources I could find. A couple interesting looks at the language from the perspective of Rubyists:

http://briancarper.net/blog/536/clojure-from-a-ruby-perspect...

http://confreaks.tv/videos/rubyconf2009-clojure-for-ruby-pro...

IMHO, absolutely. There are many wins, but the 2 biggest for us have been:

1. Clojure's tools for making abstractions are orders of magnitude better than Java's, so our codebase is significantly smaller and simpler than what it'd look like in Java.

2. Clojure lends itself very well to a REPL-oriented kind of iterative development that speeds up writing and testing code tremendously, compared to the typical Java workflow.

I vote that it's worthwhile as well. We've been using Clojure full-time at ReadyForZero for over 3 years now (for web-dev as well as other tasks), and are very happy with our choice.

As of Clojure 1.3, defrecord (and deftype) automatically define factory functions in the same namespace as the record itself. defrecord generates 2 such functions, one that takes positional arguments and one that takes a map. So once you have :use'd or :require'd the namespace, you can do stuff like the following without having to import anymore:

    (->World [:foo])
    (->World {:tiles [:foo]})
More details here:

http://dev.clojure.org/display/design/defrecord+improvements

Precisely. Clojure was my first Lisp, and I got spoiled by the "every collection is a seq" uniformity. In Clojure, functions like 'count' can operate on all collections, whereas in, say, Racket, you have an explosion of methods like:

length

vector-length

string-length

hash-count

set-count

...

Clojure embodies Alan Perlis' idea that "It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.", which is one of the many reasons why I enjoy the language so much.

I believe jashkenas' example defines both a pre-condition and a post-condition, specifying that f accepts only odd numbers and returns only even numbers ('!' here is the operator for new contract, rather than logical negation). If f is called with anything other than an odd number, an error will be thrown right away, before the body of the function is run.

I had the pleasure of reading this paper during a computer security course. To complement the paper, the prof gave us the task of writing a 2-level polyglot quine (a program in language X that outputs a program in language Y, which outputs the original program). It was my first exposure to quines, let alone polyglot quines, so you can imagine how much I struggled. This paper will always remind me of the frustrations I experienced, and the brilliance of the moment when the "trick" finally clicked for me.

Fly-by-wire avionics go beyond "just" self-landing and auto-pilot (and these are no small accomplishments!). In fly-by-wire aircraft, when the flight controls are moved, it's the software that calculates how to move the control surfaces to achieve the desired result. Also, modern fighters are often designed to be inherently unstable, to achieve greater maneuverability. So even in level flight, the software must calculate and order constant tiny movements to maintain stability. These movements happen dozens to hundreds of times a second, and must take into account factors such as current speed, attitude, air flow across the aircraft, etc.

> The guy he cites who declared macros evil is obviously not a part of 'mainstream' Clojure culture

I think Yegge was referring to Christophe Grand's talk on DSL's and macros. Grand has written several notable Clojure libraries, so I do consider him part of 'mainstream' Clojure culture. But he didn't say "macros are dangerous and you should never use them". Quoting Phil Hagelberg's response in the linked discussion:

  The talk I saw was about how functions are generally more
  composable than macros, so they should be the first tool
  you reach for. I think it was more directed at folks who
  come to lisp and are drunk with the power of macros.
 
  (Assuming it was this talk: http://clojure.blip.tv/file/4522250/)
Towards the end of the talk, Grand discusses how macros can be useful for optimizing or adding syntactic sugar to DSL's.

That's one of the goals of the Clojure team. While the main 'branch' targets the JVM, there is also a branch targeting .NET. And there is an initiative, Clojure-in-Clojure, to de-couple the main branch from the JVM as much as possible, to facilitate re-targeting.