Toy Store: ORM for Riak, Redis, Cassandra, Memcached, darn near anything - <AUTHOR> http://thechangelog.com/post/2960631110/toystore-orm-for-key-value-data-stores

<comment><USER2> And it's ActiveModel-based! Hallelujah!

For those not of a rails persuasion, ActiveModel is basically all the non- datastore stuff abstracted out from ActiveRecord, rails' ORM.

So, this Toy Store lib will share all its validation, accessor etc. apis with ActiveRecord and so will already automatically be compatible with the huge range of rails libraries out there. A good example is simple_form, a rails gem for doing lovely forms without any markup. In theory you should be able to hook this into Toy Store and therefore all those key/value stores with zero effort.

<https://github.com/plataformatec/simple_form>

ActiveModel is on course to become Rack for data objects. When this idea is fully explored it's gonna make so many things so easy.

Soon we're all going to be auto-generating javascript client-side validation code from our server-side activemodel validation definitions, without ever having to think for a second about how or where the data is actually stored.

<comment><USER3> abstraction abstraction abstraction

</comment></comment><comment><USER4> I'm not sure I quite get this.

The code looks great. The mapping features seem strong (thanks in part to the power of ActiveModel). However, by restricting the adapter interface to a simple key/value store, don't you lose access to many of the features that make each backend distinct?

I think Redis, Cassandra, MongoDB, etc. are great, but to me it't the differences amongst them which are interesting, not the similarities.

<comment><USER5> New does travel quick. I was just reading about this thing this morning.

[http://railstips.org/blog/archives/2011/01/27/data- modeling-...](http://railstips.org/blog/archives/2011/01/27/data-modeling-in- performant-systems/)

So John in the above link was talking about how when you scale, you end up looking at bottlenecks, which are usually slow data accesses, and moving them into some sort of key-value store--that usually are based on a key-value access pattern. So by the time you're well into scaling your app, you noticed that much of your data access has turned into limiting yourself to doing key lookups to attain the performance you need.

Since (according to his experiences scaling) most of the performance bottlenecks seem to have this pattern, he asked, "what if you restricted your data access to just using key-value pairs from the very beginning?" That way you avoid some of the data access headaches later on. In answering that question, this is what they got.

<comment><USER6> The same tactic was used by Google for Google App Engine - "if it doesn't scale then we're not including it as a feature". This is why so much of Google App Engine's documentation focuses on scaling [1]. Depending on who you ask this is genius or folly.

By forcing yourself into this tactic you end up having to consider all the scaling complexity in the prototyping stage before your app has even proven itself potentially successful. If your app becomes wildly popular then the combination of your early work and Google's behind the scene scaling means there are far less problems for you to worry about.

My major concern with this method is that people already focus far too much on premature optimizations before they even know where the real bottlenecks are in their application. If premature optimization leads to burn out or less features then it's a poison to our projects and should be avoided.

[1] [http://code.google.com/appengine/articles/scaling/overview.h...](http://code.google.com/appengine/articles/scaling/overview.html)

</comment></comment></comment><comment><USER7> This NoSQL stuff has me confused. I didn't think those systems were considered relational.

Why does one need an object-relational mapper?

<comment><USER8> NoSQL systems are not SQL, but this does not mean they are unable to model relations. For instance in Redis you often have something like:

        user:1000

That is an hash with a few attributes, and among this attribs you can have 'group_id", that is an integer, for instance 50. Then if you access

        group:50

You have another data structure representing the group the user is associated with.

</comment></comment><comment><USER9> There's a better article on the rationale here: [http://railstips.org/blog/archives/2011/01/27/data- modeling-...](http://railstips.org/blog/archives/2011/01/27/data-modeling-in- performant-systems)

</comment><comment><USER10> I wrote something similar for Python. Not quite as robust, but on a similar path.

DictShield: <https://github.com/j2labs/dictshield>

</comment><comment><USER11> if you need a ORM for key/value storage, you're doing it (very) wrong

<comment><USER12> Exactly. I'm not sure why this is necessary. If you want to store rich objects, just serialize them and create your indexes as necessary.

Anyways, I'll definitely check it out. Maybe I'm missing something.

<comment><USER13> The scale of the application affects how much you can really do just by adding indexes to tables and throwing more hardware at it.

At a certain point, servers are only so fast and disks only so large and fast.

</comment></comment></comment><comment><USER14> So basically, Elephant or KiokuDB, but for Ruby? I think people tend to call these "object databases" rather than ORMs.</comment>


An Old Fogey's Analysis of a Teenager's View on Social Media - <AUTHOR> https://medium.com/message/an-old-fogeys-analysis-of-a-teenagers-view-on-social-media-5be16981034d <comment><USER2> Happy to see this article from danah. I strongly disagreed with Andrew's characterization of Twitter for this exact reason -- my timeline, full of black/Hispanic/Latin@ people protesting recent events (I'm one of them, to a degree), did not correspond to Andrew's description at all.</comment>


Show HN: Eligible API for 700+ Health Insurance Companies - <AUTHOR> https://eligibleapi.com/ <comment><USER2> I applaud the initiative, but I think the JSON needs to be friendlier.

* Use REST.

* Use HTTP Basic auth instead of cluttering the URL query string with the API key.

* Use ISO 8601 for dates, no exceptions.

* Use lower_case or lowerCamelCased keys.

* Don't use spaces or other non-alphanumeric/underscore characters in keys, otherwise you can't easily index child objects with dot notation in many languages.

* Instead of liberally using dictionaries, use arrays with a type field. For example (I couldn't finish the example because the example JSON on your site is indented too poorly to comprehend):

        active_coverage: [
          {
            title: "Item #1",
            description: "Choice Fund HRA Open Access Plus",
            free_text: "Member is in network based on NPI ID provided in request",
            ...
          }
        ]

* Why are percentages expressed as a string? Instead of ".1" which will need to be parsed again by the consuming app, use a raw number, or to avoid floating points, multiply by 100 to ensure whole numbers.

* Same goes for balance, make it a number (use cents to avoid floating points), and provide units like "USD".

The JSON example at <https://eligibleapi.com/overview/how-it-works> is incomplete and invalid. I'd be interested in seeing the entire JSON envelope to see how to actually get at the data and what other metadata is exposed.

This looks like a straight up EDI translation into JSON, and thus not natural at all. I'd try to abstract it out a bit more into what people might use it for, and build a truly consumable REST API.

<comment><AUTHOR> can we hire you?

I love your feedback, we know this is still raw (early beta) but its great hearing constructive suggestions. Please email when you have a chance email@example.com so that I can provide you with a full data set of JSON response.

<comment><USER3> In case ammmir decides takes you up on your offer, I'd advise him to ensure that a contract is in place before committing to do any work.

<comment><AUTHOR> Waiting for that bad boy. In case anyone is curious of what gman is referring to you can read my response here katgleason.tumblr.com

</comment></comment></comment></comment><comment><USER4> If I understand it correctly, this is an EDI to JSON API? At 5c/call, it seems like one of the most expensive APIs out there but I'm guessing it does something that is very difficult to setup on your own. Reading the front-page, did not make it clear what is it that it really simplifies. And how can I as a developer (who might want to make a mobile app for the medical industry) make use of this service?

<comment><AUTHOR> Thanks for your comment. We handle the connections to the insurance companies and the EDI to JSON transformation. I respect your point about 5 cents being high. We, of course, will evaluate that as time goes on.

To start, you as a developer can make an app for the medical industry that checks patient's health insurance eligibility. Details you can call include: health spending accounts, deductibles remaining, coinsurance/copayment, whether or not they have coverage for MRI, etc.

<comment><USER5> > Thanks for your comment.

Perhaps I am having a bad day, but is it really necessary to thank someone for their question? Seriously, this makes me feel like I am dumb for asking a question.

I understand you trying to be extra polite, but I am sure you won't start a conversation with "thank you" every time your wife, son, daughter, lover or employee ask you a question. So while many will appreciate your "politeness throw-up" attitude, personally you just caused my red flag to pop up, because I honestly feel your politeness is fake.

> I respect your point about 5 cents being high. We, of course, will evaluate > that as time goes on.

His, and everyone else who ever paid for API and knows what is reasonable price what's not. To me this "We, of course, will evaluate that as time goes on." stripped out of bullshit means this "We will try to make fortune (or something like 100,000% profit margin on those simple text requests to our server) and will benchmark traffic, and if we don't get enough suckers to sign up, then we, of course will lower our price".

I can bet you $50 that after the initial wave of HN interest, your value versus cost ratio will scare 99% of those who need to use service similar to yours. Please don't forget to post a news where you go down to a reasonable rates, like 1,000 hits for 1 cent (Sendgrid, MailChimp, etc, etc).

<comment><USER6> Terrible, shortsighted comment. You're really judging the value of an informational API on absolute price per dip??

I know of a guy who has a database for which he charges $5000 per lookup. Is that not a "reasonable price?" Well, turns out it contains contract details, including expiration and re-bidding dates, for multi $-MM corporate contracts. If you're a sales team angling for a $500k commission, paying $5k to look up a single record suddenly makes sense.

(I agree that ideally the info that Eligible is selling should be available for free, in real-time, from insurance companies. Guess what; it's not. But redirect your anger, buddy: Eligible is part of the solution, not part of the problem.)

<comment><USER7> I am insanely interested in knowing more about this guy and his database.

Is it very specific to a certain type of business contract?

</comment></comment></comment></comment></comment><comment><USER8> Just one nit: tell us more about who you are.

When dealing with something like health insurance data (or really any service, to be honest) I like to know there's a human or corporation behind it. Your contact page just lists an anonymous email address.

Knowing who the team are that built this thing would give some assurance — particularly because your signup page asks quite a lot of information, way more than you give away about yourselves.

<comment><USER9> You are right, we will update our Contact page ;-)

As a sneak preview, please find below our respective LinkedIn profiles:

* <http://www.linkedin.com/in/katelyngleason>

* <http://be.linkedin.com/in/patricekrakow>

</comment></comment><comment><USER10> Just fyi, there's a "mint for healthcare" startup called simplee.com that's been around for a year or two. You link the site up to your various health insurance plans.

I've used it but haven't really gotten any interesting out of it before.

</comment><comment><USER11> The deeply nested JSON (9 levels) seems difficult to understand without some kind of schema/detailed docs - though maybe domain users are already familiar with the underlying data's schema? Part of the problem is intrinsic data complexity, aside from EDI format. <https://eligibleapi.com/restful-json- api/response>

Also, it's simulating JSON [] lists as objects with fields named _"Item #1", "Item #2", ..._ Seems an odd choice. e.g.

      "Deductible": {
        "Item #1": {
          "Calendar Year": "1500"
        },
        "Item #2": {
          "Remaining": "500"
        }
      },

EDIT: To clarify, below is the same snippet using JSON lists. The list syntax gives schema information (i.e. that it is a list), and is standard, readable and concise. Most parsers will map it to a list in the destination language, making it more natural to address and loop over; i.e. easier to process in general.

      "Deductible": [
        {
          "Calendar Year": "1500"
        },
        {
          "Remaining": "500"
        }
      ],

<comment><USER9> As already said in a previous comment: << To be fully honest, it has been an internal debate: "use or not use array" ;-) I personally wanted to use them... so, thanks for your feedback ;-) >>

@Kat, this is the 2nd point for using array ;-)

<comment><AUTHOR> Three points from Max, lets do it!

</comment></comment></comment><comment><USER12> Some questions that immediately came to mind after reading through the docs:

1\. Does the response contain more than just the 271 EB segments? The demographics segments are important, as are payer contact segments.

2\. How do you deal with payers that require provider registration? Do you have a standard registration form that can be used to expedite the process. Do you, can you, register on behalf of the provider?

3\. JSON is web service friendly and stuff, but your output sure is verbose. Is there any reason you choose to print entire descriptions of codes instead of just returning the code? (for example "Diagnostic Lab" instead of simply "5"). Personally I think sticking to the standard X12 codes would make the data easier for software to consume. In my honest opinion it's hard to beat X12 for EDI transactions given its well defined structure. Though it's very unfortunate that it's not "open".

4\. Do you accept multiple service type codes on a single request?

5\. Can you accept a Service Date in the request? Often times it is useful to retroactively check for coverage. A good example is Medicaid: providers often batch eligibility requests for their self-pay patients at the end of the calendar month to see if they now have coverage (new Medicaid coverage can be retroactive in some cases).

6\. How reliable are your connections? Have you setup your own direct payer connections, or is mostly hopping through other EDI vendors (Emdeon, ENS, Meddata, etc)?

</comment><comment><USER13> I've been using Eligible API for just over a week and I must say that I'm loving it so far.

Kate & Patrice have been extremely responsive and improving incredibly fast.

<comment><AUTHOR> Your team has helped us improve 100% over past week alone. Thanks again.

</comment></comment><comment><USER14> I am impressed by this site's use of Bootstrap. Most Bootstrap sites look like exact clones of the example templates with some colors swapped. The Bootstrap origin on this site is obvious yet not tired.

All they did was add a background and position one element yet it looks unique. I think the key thing was that they avoided the Bootstrap's black navigation bar.

<comment><USER15> IMO what matters most is Bootstrap was used _well_. They took the purpose of Bootstrap (CSS/HTML Framework and well designed common elements) and then used that alongside their own understanding of how their site should be fit for the purpose.

So many people take Bootstrap as an excuse to not give a single thought to the usability of their site. It's a shame really, Bootstrap is a great tool but inevitably the people that rely on it are relying on it because they have no clue, so they butcher it.

<comment><AUTHOR> thanks :) we put a lot of thought into how best to use it. glad that comes through.

</comment></comment></comment><comment><USER16> Anything involving health data is interesting and has the potential to improve lives, however there isn't enough information on the landing page here to indicate what this data is or why I might want to use it. Could do with a better landing page.

<comment><AUTHOR> Great feedback, we will do that and include samples from some companies currently using the API.

<comment><USER17> Maybe also put up a comparison with your competitors and/or highlight the features that make you a better choice.

</comment></comment></comment><comment><USER18> I wish the raw data was available (is it, somewhere?). I'd love to do some statistical analysis on this and get some real insight about how different insurance companies treat claims.

<comment><AUTHOR> absolutely. I'll send you over as much raw X12, with removed patient info of course, as you want! Please email email@example.com

<comment><USER19> You mean you also have claim data (837)? Or do you just have enrollment data (834)?

If the former, I wonder if some statistical analysis could be done in order to detect possible fraud, waste, and abuse. (I'm not a data geek or anything, but have I always wanted to learn.)

<comment><AUTHOR> Nope, sorry we do not handle 837 or 834 EDI transactions at this time.

</comment></comment></comment></comment><comment><USER20> Healthcare and Health IT are plagued with an insurmountable amount of complexity, administrative burden and draconian policies which hinder a lot of the potential for innovation.

Solutions like this are absolutely vital in getting the next generation of startups, developers, and healthcare providers the kind of infrastructure that can otherwise be cost-prohibitive.

It's really great to see someone hyper-focused on solving one part of the puzzle.

<comment><AUTHOR> Thanks Mike. We are starting at the source and will not leave it until there is a genuine shift in how eligibility for healthcare is handled.

</comment></comment><comment><USER21> I was surprised by the read-only aspect of the API. How do doctors/medical providers/employers submit records and or update billing information? I guess I am under the impression that when I visit the doctors office that they transmit data to my insurance provider.

 _Nota Bene: I dislike the malicious sentiment that often pops up in threads like this. My question is driven by pure curiosity._

<comment><USER13> Eligibility is a different beast from filing insurance claims.

Eligibility checking is performed prior to filing a claim. It tells the provider if the patient's insurance covers the requested procedure at the requested facility.

Filing claims is typically done through an EMR system that submits claims to a clearinghouse.

</comment></comment><comment><USER22> It would be cool to provide a sample API with test data. You could either require sign-up (as individual or organization, but not necessarily a registered company) or don't. This would enable someone to hack something together before they establish a company.

<comment><USER9> Thanks for your feedback! Following your comment, we might soon provide a public test API key that will return a predefined anonymized JSON answer so developers can hack the API straight away ;-)

</comment></comment><comment><AUTHOR> We've had a lot of people sign up and start building already :). If you have any questions please jump into our campfire chat room: <https://eligibleapi.campfirenow.com/e30aa>.

</comment><comment><USER23> My father's a chiropractor and I just asked him about this. Apparently checking insurance eligibility is a "pain in the ass" and involves a phone call with wait times.

I'm excited to see if I can quickly put something together for him.

<comment><AUTHOR> we'd love that. email me firstname.lastname@example.com

</comment></comment><comment><USER24> I don't get this.

I'm a physician, and every insurance company to which I submit claims already has a web service in place to check eligibility...at no charge. Already.

There aren't many interface differences between insurance companies: you typically enter two identifiers, usually either an id number or last name, and birth date. You get full eligibility info immediately.

There's nothing difficult about it. We almost never call insurance companies to get eligibility info - web querying is already in place, and has been for a while.

What problem, at 5 cents for each API CALL (c'mon, really?) is this solving? Why would I want to pay to pass my patient's protected health information through yet another layer (and store? see my comment below about this company's offer of a data "sample") of potential privacy loss?

<comment><AUTHOR> What's your specialty?

<comment><AUTHOR> Also, how many insurance companies do you currently accept?

<comment><USER24> Many many. I just discussed this with our office manger - checking eligibility is not a problem for us (nor would it be for most practices in my opinion) using web services already in place....and especially not free vs a dollar per 20 queries.

I'm not actually a fan of insurance companies, but please explain why I would want to pay for the hassle of dealing with Yet Another third-party and at the same time expose my patient's protected health info to Yet Another layer of risk?

<comment><AUTHOR> I see. We certainly would not expose your patient's data. My reply at bottom should help clear that up for you. You forgot to mention what specialty you are?

<comment><USER24> No, actually your reply doesn't describe your security practices at all. Why are you retaining live data at all?

Forgive me, but just claiming "we certainly would not expose your patient's data" is hollow at best - I take the responsibility for protecting my patient's health information very seriously, as do most physicians, and it is ultimately our responsibility to do no harm in that regard.

Not saying this is true of you guys, but there are a lot of incentives out there for "mining" and even selling health info. At the very least, storing health data on multiple, geographically disparate servers, logging access, retention policy, etc is a nightmare waiting to happen.

<comment><AUTHOR> You forgot to mention what specialty you are? Take a look at our privacy, terms of service, and security pages to answer the rest of your questions above. If you do not think the service is useful then you don't need to use it. That's the beauty of the free market. One man's junk is another man's treasure.

<comment><USER24> I'm a family medicine doc in a practice with several other docs. Why do you ask?

I already read your site's security pages, which in large measure do NOT address the questions I've asked here.

However, I believe you're right - neither I nor the software folks I consult with here in Bay Area will be interested in using your tool. Good luck to you.</comment></comment></comment></comment></comment></comment></comment></comment>


Standing in the beam line of a neutrino detector - <AUTHOR> http://arstechnica.com/science/news/2011/05/ars-photo-essay-standing-in-the-beam-line-of-a-neutrino-detector.ars

<comment><USER2> Reminds of an article I have seen here before:

Several physicists weigh in on what would happen if you were to place your hand in the proton stream of the Large Hadron Collider at CERN.

[http://kottke.org/10/09/putting-your-hand-in-the-large- hadro...](http://kottke.org/10/09/putting-your-hand-in-the-large-hadron- collider)

</comment><comment><USER3> Great article, but they seem to barely mention the most mind bending fact about the experiment:

They are generating a 1km wide blast of neutrinos in suburban Chicago and sending it 450 miles through the ground to mine in Minnesota.

I had to read parts of the article 3 times and follow some of the links to make sure that is really what is going on.

</comment><comment><USER4> All technical issues set a part, beams of neutrinos sounds like an excellent way to transmit information. A beam travelling at the speed of light, trough matter - without any interaction or distortion when passing trough.

Goodbye satellites and fiber-optic cables, we can now transmit ones and zeroes straight trough mother earth.

<comment><USER5> Sure, but how are you going to receive them? Packet loss would seem to be an issue.

<comment><USER4> Indeed. The detector, or receiver, I imagine would have to detect variations in the density of neutrons. Given a large enough density range, one could assign different ranges to different integers. Still a technical issue disclaimer attached.

</comment></comment></comment><comment><USER6> Physics is so unbearably sexy. It's a cave and an office and a research facility and they're shooting signal beams of particles through the earth with giant tunnels bored through the planet and filled with pipes and lights and equipment. Nobody else does these things! Well, except maybe high reliability data centers.

</comment><comment><USER7> <http://operaweb.lngs.infn.it>

<http://proj-cngs.web.cern.ch/proj-cngs/>

</comment><comment><USER8> It's amazing how one can stop reading physics news for a couple of years, and all of a sudden, a neutrino gets mass. I wasn't aware of that.</comment>


Want to help startups? Just give them money - <AUTHOR> http://www.rookieoven.com/2013/04/04/help-startups-give-them-money/

<comment><USER4> This feels like a One More Level of Indirection solution. [1] The problem, I think most everyone agrees, is that the government isn't the greatest at growing businesses. The obvious, delete-all-the-code approach would be to leave more money in the hands of the businesses by lowering taxes.

Or, as the article suggests, we could pile on another layer of indirection: encourage the government to keep taking my money, hope they're halfway decent at identifying smart startups (which I'm sure they would be, the government is awesome at everything else they do right?), and, wonder of wonders, they identify the next Facebook 9 times out of 10, we still have to lose a significant percentage of the wealth to paperwork, inefficiencies, and bureaucracy.

> I'd be confident that I could do more for my startup, Plantedd, with > whatever equivalent amount spent by government organisations to pay > consultants to help us with marketing or IT or training.

Dude, I'd love that. Plantedd looks stellar. I think we want the same things. I also think it's far more straightforward to lobby for more tax breaks for startups and call it a day.

[1] <http://c2.com/cgi/wiki?OneMoreLevelOfIndirection>

<comment><AUTHOR> (The One Direction solution??)

I agree that more tax breaks for startups would help and it would be a more straightforward thing to achieve. The two things don't have to be mutually exclusive though, so I'd say we need both. For early-stage startups though, sometimes the challenge is more in actually reaching the stage where there's anything to tax - which is why I still think actually giving them the money in their pockets is vital.

Thanks for the compliment about Plantedd!

<comment><USER4> > For early-stage startups though, sometimes the challenge is more in actually > reaching the stage where there's anything to tax

Sure, I get that. I live in the startup world too. I just disagree that it's the government's job to take my money and give it to you — and, of course, vice versa: I won't ask the government to take your money and give it to me.

We already have a solution for the problem you bring up. It's called investing. You exchange a percentage of your company for the capital you need to get going. If a startup has trouble convincing an angel investor to part with his money, he may need to revisit his business idea or iterate a bit further. That's a good thing, it helps improve the startup.

But "government money" is really my money, and you're proposing that the government force me to fund startups that have been unable to secure angel investment. To be blunt, this seems really lame. I'd rather keep my money that I've worked hard for and invest it into my own ventures.

[I should also note this is a debate of principles for me: I'm not saying "oh in my opinion startups aren't worth my tax dollars", so much as "government is inefficient at everything, and $PROPOSAL is a subset of everything, therefore, government shouldn't be $PROPOSAL when another solution already exists.", where $PROPOSAL = 'funding startups' in this instance.]

<comment><AUTHOR> You're right, it's a difference about the principles of the matter and no doubt we disagree over the government's role (especially in an economic downturn). Setting that to one side though, the truth is that the government is spending your tax dollars already and I'm suggesting that there may be a better way for them to do it.

<comment><USER5> _the government is spending your tax dollars already_

They should be spending a lot less of them, shouldn't they?

<http://www.usdebtclock.org/>

I mean, what business would ever be allowed to spend money endlessly without thought to income? Why do we let the government do it?

Besides, we already have angel funding, ycombinator, venture capital, self funding, debt funding, crowd funding, etc.

[http://www.instigatorblog.com/an-introductory-guide-to- start...](http://www.instigatorblog.com/an-introductory-guide-to-startup- funding/2007/10/17/)

We should not be taking tax money by force from some to fund the next facebook.

<comment><USER6> The gov't isn't a business. If it were it would not be serving everyone. The post office (sorta of a gov't/business half breed) would charge you more to send a letter from Miami to Fairbanks, Alaska than from your town to the next town 10 miles down the road. Gov't has more responsibility than a business.

There are plenty of business with large amounts of debt.

This being said I don't back the proposal.

<comment><USER5> _The gov't isn't a business._

Right. Businesses have more direct financial accountability. That's why the government stinks at doing business-like things and I'm objecting to a proposal that thinks government should do more business-like things.

Not sure what your point is with the post office. It's a great example of the government trying to do something that business came along and did ten times better - accomplishing things that the post office said were impossible like overnight delivery.

What's the merit in the subsidizing of people to live in out-of-the-way places? This isn't the 1800s.

 _There are plenty of business with large amounts of debt._

1X yearly revenue in current debt and 5X in long-term liabilities? Hardly.

People at Enron went to jail for the type of accounting shenanigans that the government considers to be common practice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> As someone who is running a business whose main occupation is to help the government give money to tech companies and startups, I actually disagree with this.

I think most startups don't need money (and they typically don't get any, because most government funding is match funding, and so you have to spend to get, and very early startups don't spend anything). Or rather, they need money, but probably not from investors, and _certainly_ not from the government. They need money from customers.

My thoughts on why money is toxic to most entrepreneurs are pretty well summarised in this article: <http://swombat.com/2011/12/8/investment-cushion- springboard>

Growing companies that have figured out how to make their own money already _do_ need money, but the reason they can make good use of it is also the reason why they don't need it as much as the cash-starved early startups.

To a functioning company, money is lifeblood, and more money can help make the company a bigger success than it already is (or make it more competitive against other companies in the same space).

To an early startup, money is a toxic sludge that will slow it down, cause weird and unpredictable mutations, and possibly kill it when it might have lived.

Disclaimer: I'm talking about startups operating outside of the Magical Land of Silicon Bubbles, who have to actually create a viable business rather than just build something popular that makes no money and then sell it for a billion dollars.

<comment><USER8> Ehhh, I don't know. I mean, yeah, I agree with the general gist of your blog post there, but... For some startups, especially early-stage startups, they _do_ need money...not necessarily _big_ money, but _enough_ money to actually start at all. Or, let me put it a different way, even for the very early stage startups, capital can be very important - in at least some cases.

I'm thinking of the bootstrapper scenario, where the founders don't have the kind of cash reserves just lying around, to enable them to quit and work on the startup fulltime right away. So they're forced to keep dayjobs and work on the project nights and weekends. Now, you can get a lot done, especially from a product standpoint, working nights and weekends. But when you need to go out and meet people (potential customers, partners, distributors, investors, whatever)... well, those people usually expect to do business during "business hours". If you have a potential customer on the table, but you can't meet with them because you're at work at your 9-5 all day, or because you can't afford to fly to $EAST_BUMFUCK, or whatever, it really puts a crimp in things.

Of course, I'm not saying it can't be done... In fact, I'm in the middle of doing this myself, and we find workarounds: I meet people over lunch, or come in early and leave early at the $DAYJOB so I can meet early afternoon (or flip it around for a breakfast meeting), and I use Skype, chat, etc. to do remote meetings. And we solve the travel expense problem by focusing on customers who are geographically close to us. And for us, the advantages of bootstrapping justify doing this for now. But I can see where many startups would really need - at a bare minimum - enough money for the founders to be able to work on the project fulltime, and maybe some money to cover incidental expenses from going through Customer Development.

<comment><USER7> There are many things that a person can do to liberate their time so they have the flexibility to spend good chunks of flexible time on their startup. Those things (e.g. moving to a more consulting/self-employed type role, not an employee role) also teach that person how to run a profitable business, deal with taxes, cash flow, sales, etc. Having someone else's money in your bank account teaches none of that.

I agree that it is far better to be in a position to work full-time on your startup, but I think it is not so valuable that it is worth taking the downside of raising funds just for that. "Relentlessly resourceful" (to use pg's words) people find the time to make it happen somehow.

Similarly, relentlessly resourceful people make it happen without having to fly to east bumfuck. Shit, in today's world, with all the remote communications available, and the fact that most companies (at least the SMEs) are perfectly happy to do business remotely. And if your business requires you to go to east bumfuck to make sales in person, and you don't have the resources to do so, then you're just doing the wrong business. Pivot to one where you _can_ do the sales remotely, or there are enough clients nearby to sell to.

<comment><USER8> Sure, and like I said... I know it's possible, because I'm doing it. And as much as I'm opposed to overly focusing on raising money[1], I can certainly see how some entrepreneurs would be better served to go ahead and raise money - at least some small amounts - earlier.

One reason, among others, is the risk of missing an opportunity because you can't move fast enough to capitalize on it, due to lack of resources. For most of us, there _is_ competition out there, and if they're moving faster, capturing mindshare and establishing their position in the market, it could be pretty damaging (psychologically, if nothing else) to not be in a position to respond.

[1]: [http://www.fogbeam.blogspot.com/2013/03/the-point-of- startup...](http://www.fogbeam.blogspot.com/2013/03/the-point-of-startup-is- to-make-money.html)

</comment></comment></comment></comment><comment><USER9> Good article.

I must say that a unique benefit about Scotland for entrepreneurs is that higher education is free. This reduces the debt burden of a new graduate significantly that helps with any new venture.

I do agree that the money spent on bureaucracy by government bodies that are meant to boost enterprise is wasteful, although the new gov.uk web project suggests that sometimes projects can be done well at a decent price.

I echo nthj's comments in saying that tax breaks are the easiest way to benefit all small enterprises, from tech start ups, to new retail shops, plumbers starting their first business etc.

</comment><comment><USER10> I know of a few VCs who just can't help themselves...not just giving them money, but telling them how to spend it too. And for some reason, they all seem to want them to spend it on a hotshot HBS-trained former big consulting general partner that will suck up all their cash and equity and give them a failed business in return.

They like to claim that there is some value-add with having their experience as "part of the team"...but for 90% of the VCs out there, it is bullshit. It is just a ploy to get better deals.

</comment><comment><USER11> In context this is a really strange article. The government bodies listed in this article do give money to startups, and the bar is extremely low. In addition, private investors (angels and angel syndicates) get matching funds "for free" where the public money matches private money. I'm not sure why this isn't exactly what's being described in the article.

<comment><USER12> The point is rather than these bodies acting as gatekeepers deciding what they think will work or not, funds should be distributed via a lottery subject to some basic criteria.

In fact, that is rather the point of the matching funds you mentioned - <USER2> let the private sector decide the winners and come in on the same times. That said, there's still a checklist of what sectors they will and won't fund - <USER3> it so happens that some startups get unreasonably pigeonholed.

<comment><USER13> If you make it a lottery subject to criteria X, then it will be a profitable "financial startup" business to cheaply make thousands of fresh companies matching criteria X, extracting the "free money" out of the startup ecosystem.

I've seen it many times for various subsidy programs - where a few "entrepreneurs" who learn how to game the system aren't just 'a few bad apples' but actually obtain the majority or even 100% of such programs.

</comment></comment></comment><comment><USER14> How come your plantedd doesn't sell shrubberys? You are from the UK, you need to add a special search result for when the users search "shrubbery" <http://www.plantedd.com/t/categories?keywords=shrubbery>

<comment><AUTHOR> We have a category just for shrubs here <http://www.plantedd.com/t/categories/plants/shrubs>, but yeh, our search isn't clever enough at the moment.

</comment></comment><comment><USER15> Is there no equivalent of the NW Fund in Scotland? <http://www.thenorthwestfund.co.uk/>

<comment><AUTHOR> We've got things like the West of Scotland Loan Fund and similar schemes. The equity or loan funding support is better, but there's still essentially a large degree of inefficiency and a lack of effectiveness in the process because you've got teams making decisions on who to pick without the benefit of any randomised evaluation, so you're not gathering any objective data on what's actually effective.

</comment></comment><comment><USER16> There's good and bad here.

The good: right now, the funding racket for startups (unless they can get clients, and under-35's tend not to have those kinds of relationships yet) is unfair and, due to the illegal comparing-of-notes whereby a VC can turn off interest in supposed competitors, probably extortionate. It sucks. A lot of good businesses are shut out. Here's some writing I did on how to fix that: [http://michaelochurch.wordpress.com/2013/03/26/gervais- macle...](http://michaelochurch.wordpress.com/2013/03/26/gervais- macleod-17-building-the-future-and-financing-lifestyle-businesses/) .

The bad: this means that startups are funded based on their ability to attract attention and raise money (tip-jar model) when they really should be funded according to provision of value. These will probably converge over time, so you get eventual consistency.

On the whole, I think the good outweighs the bad. It's just that you couldn't use a tip-jar model to fund, say, a new GPU-aware C compiler. There's a lot of infrastructural technology that can't easily be funded by "dumb money" of the populace nor by the "I-think-I'm-smart money" of meddlesome VCs and executives.

There are a lot of hard financial problems to solve, but ideas like this are bringing us in the right direction.

<comment><USER8> I'm really intrigued by the possibilities that crowdfunding may offer, once the SEC fully implements the JOBS ACT stuff. I'm not sure I see the rosy picture that this guy paints:

[http://radar.oreilly.com/2013/03/how-crowdfunding-and-the- jo...](http://radar.oreilly.com/2013/03/how-crowdfunding-and-the-jobs-act- will-shape-open-source-companies.html)

But I think he makes some interesting points. I don't think this just relevant to Open Source companies either, although they may be uniquely positioned to really tap into this mode of funding (or not... I need to spend a lot more time thinking about this, especially since I run an Open Source startup).

I'd be curious to hear your thoughts on crowdfunding, michaelochurch.

<comment><USER16> I think crowdfunding is an excellent idea but it's too early to see how it plays out. It could fail; it could be The New Thing. Too early to tell.

One idea I've had, which I think has major steam, is passive payment. Given that my consulting rate is high (full rate I don't disclose but it's _well_ over $200/h; however, I give lower rates, sometimes zero, for businesses I believe in and non-profits) it really isn't a major cost to pay $2/hour for websurfing. That's a rounding error. I have no problem paying $0.25 for the time it took to write this post because the value of the time itself is an order of magnitude greater.

People would need to have the ability to calibrate their passive payment, obviously. For me, $2/hour is nothing; for the developed world, it's far too much.

Right now, advertising is the only passive payment system we have and it's extraordinarily inefficient.

Passive payment would make living by blogging much easier. For example, I get about 1700 hits per day (2.5 minutes each) on my blog. If we assume the average web user sets his passive payment level to $1.00 per hour (median would be lower; mean might be around that) then I'd be making $70 per day. Not enough to live on (in New York) but it would almost cover my too-damn-high rent.

Passive payment would also be great for time-tracking. I probably wouldn't waste as much time if I realized "holy shit, I wasted $0.73 reading that garbage!"

Finally, it would obsolete those damn paywalls. I don't mind paying 95 cents to read a good NYT article (again, the time is much a greater expense) but bringing out my credit card is a hassle.</comment></comment></comment>


Oklahoma used wrong drug in January execution - <AUTHOR> http://www.miamiherald.com/news/nation-world/article38173836.html <comment><AUTHOR> "The Oklahoman reported Thursday that corrections officials used potassium acetate — not potassium chloride, as required under the state's protocol — to execute Charles Frederick Warner. Last week, Gov. Mary Fallin issued a last- minute stay for inmate Richard Glossip after officials discovered that potassium acetate had been delivered on the day of his scheduled execution."</comment>


Clojure vs. Scala - <AUTHOR> http://programming-puzzler.blogspot.se/2013/12/clojure-vs-scala.html <comment><USER4> Scala guy here

Suits would surely be case objects rather than classes, or I'd be tempted to just use a Java enum (Scala could really do with an equivalent). With card ranks, either you want to be able to compare them - in which case integers are the correct representation - or they're just 13 "things", in which case again an enum-like representation is good; I can't imagine why you'd ever want to represent a card rank as int-or-string.

Case classes are java-serializable by default. Any number of other serializers (json, database...) exist that work seamlessly with case classes. I do think it would be nice to have an abstraction for something weaker than a class, something that was guaranteed to be inert data, but still typed.

And yeah, I might implement a deck as something that contains a sequence. But I could then derive typeclasses for sequence operations quite cheaply using lenses. (I do wish there was a nicer way of doing this kind of delegation though).

Sure, Scala steers you towards making a type straightjacket for yourself; you definitely can operate on stringly typed or maply typed data, as it sounds like Clojure encourages you to do all the time. And maybe it's not the best language for exploratory manipulation of semi-structured data. But when the time comes to write a production-ready system, the strong types that Scala gives you are a much faster way to achieve the level of reliability you need than the level of testing you need in a less typed language.

(And even if you don't need the safety, I find types are a great aid to figuring out WTF you were doing if you come back to the code in six months' time)

<comment><USER5> > Scala gives you are a much faster way to achieve the level of reliability > you need than the level of testing you need in a less typed language

I have serious doubts about this since practically everything in the Scala standard library is horribly broken (collections, views, everything in scala.io, scala.xml and scala.actors etc.). The number of bugs found by Paul Phillips alone is absolutely ludicrous.

As it stands now, both Haskell and Clojure have vastly superior libraries, build systems that actually work, and implementations that people actually understand and can modify.

<comment><USER4> The scala collections library is the most powerful/flexible I've ever seen in a strongly typed language; it combines the safety of Haskell with the flexibility of Clojure. Given the amount of ongoing complaints I see around cabal I don't think it's fair to say it "actually works" (fwiw I'm very happily using maven to build my Scala projects, so I never really know what the sbt fuss is about). And the rate of features and other progress in recent scala releases clearly demonstrates there are plenty of people who understand the implementation well enough to modify it.

<comment><USER5> > it combines the safety of Haskell with the flexibility of Clojure

Foldable, Traversable, Monoid etc. are all far better abstractions than what Scala collections provide, and they don't lead to unmanageable inheritance hierarchies and ridiculous APIs. How many bugs have been caused by that? A few hundred maybe? Does Set equality work in the current release or is that broken again? Is it possible to do thread safe efficient merges in immutable collections yet?

The only thing Scala collections offers that Haskell doesn't is the CanBuildFrom travesty. At least in Clojure you can chain transformations together without generating tons of intermediate values. In Scala you're forced to choose between being ridiculously inefficient or using iterators.

<comment><USER6> Can you expand on the CanBuildFrom travesty?

(It seems like you've got interesting things to say, but you're being a bit strident. It bums me out that Scala discussions on HN take such a heated tone.)

<comment><USER5> CanBuildFrom is essentially a typeclass in Scala that is used for converting between collection types. Ignoring the coherency issues associated with using implicits for typeclasses, it makes the implementation of the collections library significantly more complicated and causes issues with type inference.

In the rare cases where you actually need to convert between collection types, it's usually trivial and more efficient to do it manually. Essentially they've added tons of complexity for negligible benefit. One of my main gripes with the Scala collections library is that it's overly complex and that this complexity has been the source of hundreds of bugs.

If there was any real benefit to the way it's currently done they wouldn't be hiding the true type signature for things like `List.map` in the official Scaladocs.

<comment><USER7> You are kind of either ignoring or not knowing the core use-case of CanBuildFrom. Why talk about things you don't understand?

<comment><USER5> The reasons other than the ones I've outlined are caused by implementation details and wouldn't exist if they chose the correct abstractions.

<comment><USER7> That's wrong.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> So the Scala solution for this is: [http://ideone.com/Vussjh](http://ideone.com/Vussjh)

      object Cards {
        sealed trait Suit
        case object Spades extends Suit
        case object Clubs extends Suit
        case object Hearts extends Suit
        case object Diamonds extends Suit

        sealed trait Rank
        trait FaceCard extends Rank

        case object Jack  extends FaceCard
        case object Queen extends FaceCard
        case object King  extends FaceCard
        case object Ace   extends FaceCard

        case class ValueCard(n: Int) extends Rank

        case class Card(rank: Rank, suit: Suit)

        type Deck = IndexedSeq[Card]

        def numberToRank(n: Int): Rank = n match {
          case 1 => Ace
          case x if x <= 10 => ValueCard(x)
          case 11 => Jack
          case 12 => Queen
          case 13 => King
          case 14 => Ace
          case _ => throw new IllegalArgumentException
        }

        def numberToSuit(n: Int): Suit = n match {
          case 0 => Spades
          case 1 => Clubs
          case 2 => Hearts
          case 3 => Diamonds
        }

        def apply(): Deck = for(rank <- 1 to 13; suit <- 0 to 3) yield Card(numberToRank(rank), numberToSuit(suit))
      }

Now I have: normal operations bound to Deck (head, take, drop etc) and the ability to pattern match on cards. Also strongly typed. This took about 5 minutes top to write.

edit: I'd say the 'numberToRank' parts are probably code smells, but given that its Christmas Eve, I really can't be bothered to think of a better solution right now. Implementing ordering etc can be done on the traits very easily too, but that is game specific (for example are aces high or low, is a King ranked higher than a Jack etc).

<comment><USER9> Some things are strongly typed and playing cards are among them. It is just that playing cards are strongly typed as playing cards, not integers or pairs of integers.

In blackjack:

        case 10 => Jack or Queen or King or 10

and

        case Ace => 1 or 11

and poker with "Dr Pepper"

        case 10 => ace or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or jack or queen or king
        case 2 => ace or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or jack or queen or king
        case 4 => ace or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or 10 or jack or queen or king

It is sometimes better if the data type provides abstractions over the messy details of the world rather than adding another one to it and planning for the possibility of a Joker in the deck might make sense.

<comment><USER8> Heh, same time as my edit. Those methods should be private (i.e. they just exist for building the deck, its the consumers responsibility to shuffle / split into multiple decks etc, as well as assigning value to each card).

<comment><USER9> So what then does 13=king get me over king=king? And does forgetting to privatise implementation details suggest that the necessary language idioms make the data structure complex in a way that is orthogonal to the real world complexity of the objects it represents, and wasn't the opportunity to avoid that complexity the advantage suggested by the author. To put it another way, private and sealed and trait don't reflect characteristics of a deck of playing cards. They are overhead from the language. It is a case where a static type system, because it is biased toward it's and strings and objects, makes it more difficult to reason about our code - leaving jokers aside, how much of the Scala code makes sense if I want to play Pinnocle versus the data approach advanced by the author? Now I'll admit that Lisp has shaped the way I see the two approaches to representing cards. and this may be why I see implementation of jokers and pinnocle as easy extensions of lists and rather more complex under an object system with static type checking. But I will point out that this model got me to thinking about card games rather than card data types pretty quickly, and card games are probably the reason we're draining the swamp.

</comment></comment></comment></comment><comment><USER10> I think people here are totally missing out on appreciating a very thoughtfully written post by focusing on the fact that he may be comparing programs written in his favorite language to your favorite language. He is not asking for Scala solutions to any problem - and he has not contrived a deceptive Scala solution to "prove" the superiority of his language of choice.

He's comparing the structure and design of programs between two great languages of similar capabilities (features) and philosophies. I think his point about lightweight data modeling is spot on - Clojure is a language that goes out of its way to make modeling your problems idiomatically painless and dramatically simpler than most other languages.

It's idiomatic in Clojure to use plain old maps to represent structures or entities in your program that you would otherwise represent with a class or equivalent construct in many Object Oriented languages. That isn't a code smell either - it's idiomatic and wonderful. Keywords (similar to Ruby symbols in both use and philosophy) are wonderful things that together with maps make enums as a language primitive irrelevant.

<comment><USER11> It's basically a kind of step back to the Lisp of the 60s and seventies. Unfortunately I don't think this approach scales well. For example I prefer to look in a debugger or inspector at an object and not at some other map.

<comment><USER10> I'm going to be honest - you are coming off as very contrarian for the sake of being contrarian. You seem to be consistently responding to my comments in this thread with the equivalent of "You're wrong, because I like to do things this way."

That isn't an argument against any point I've made. Please show me some code and give me some context that will make me rethink my assumptions and arguments if you feel the need to point out my flawed thinking.

<comment><USER11> No, plain maps are nothing more like plain assoc lists (and similar stuff) in plain old Lisp. We were modelling key/value data structures like that from the earliest Lisp. Sure its easy to use. Up to a point. Lisp had an evolution. Things changed. I've seen quite a bit larger Lisp software over the years and the ones not using explicit classes turned out to be harder to maintain.

</comment></comment></comment></comment><comment><USER12> Sounds like idiomatic Clojure has more in common with Python than it does with Java. I'm finding that to be true as I teach myself Clojure. My background is an ex-advanced-Java programmer who left that all behind and has built production systems in Python for the last ~5 years. I'm learning Clojure now because the Java ecosystem is important to me, but I simply refuse to use Java to interact with it :)

Lightweight data modeling is important and Java is truly terrible at this. I illustrated this in a gist about creating and iterating over a list and a map, and contrasting that to the equivalent Python: [https://gist.github.com/amontalenti/8114359](https://gist.github.com/amontalenti/8114359)

The author says about Scala: "Due to its highly detailed static type system, Scala attracts the kind of programmers that like to carefully categorize and enumerate all the possible data structures."

It turns out, this describes expert Java programmers very well, too -- so it's no surprise that Scala is a very popular language with Java programmers. I'm finding that Clojure is the more attractive language if your sensitivities lean toward the "simplicity" and "dynamism" camp. I was reading some Scala code being used in production at Twitter and found this marvel: [https://twitter.com/amontalenti/status/410977749629546496](https://twitter.com/amontalenti/status/410977749629546496) \-- you would simply never see anything like this in Clojure or Python codebases.

The point about multi-paradigm is interesting. It's very true that Clojure, unlike Python, does not support true multi-paradigm. Then again, Python does not support "true" functional programming. It's close, but no cigar, due to the lack of full-featured lambdas / blocks. If you have to pick one paradigm, functional is definitely the simpler and more essential one.

Illustration: imagine a variant of Python that forced all code to live in classes -- ick. But imagine a variant of Python without classes -- that's not so bad.

It's worth reading about Clojure's take on object-orientation-atop-functional using multimethods and hierarchies: [http://clojure.org/multimethods](http://clojure.org/multimethods)

<comment><USER10> Great points all around.

I'll add one thing to your point - multimethods are a fantastic example of how Clojure allows you to structure programs in functional way that takes a programming feature (in this case polymorphic method dispatch based on the arguments at runtime) to the nth degree.

In Java and many other languages that have polymorphic method dispatch - <USER2> dispatch value is usually the type of the object for whom the method is being called on. Functional languages like Haskell take a much more powerful and expressive approach to this and extend it to matching the dispatch values for the called function on the type or pattern matched value of any argument.

Multimethods are essentially Clojure's take on this in a dynamic language. They allow the programmer to define a function that constructs the dispatch value however it wants - usually from the arguments given as input, in any order, on any condition.

To illustrate, I'll give an example I showed my wife yesterday. She's writing a roguelike game in ClojureScript at the moment that you can play in the browser - naturally she needed a way to represent the game world and the players position as they move around.

So, for illustration I'll omit the code for the world state, but she needed to bind event listeners for the keyboard to properly dispatch the proper movement logic. So the code she wrote looked like this:

[https://gist.github.com/aamedina/8114944](https://gist.github.com/aamedina/8114944)

She came to me with this code with the following problem - how do I think she should organize it? Clearly the handling logic is going to be more complex than a single line per direction (:up, :down, :left, :right) could handle, she has to account for terrain differences, buildings, monsters, what have you.

So I suggested using multimethods to accomplish this. This is what the multimethod solution I cooked up would look like in this case.

[https://gist.github.com/aamedina/8114949](https://gist.github.com/aamedina/8114949)

Now she has room in those multimethods to handle the potentially complex logic needed to make those arrow keys move the character properly. But another effect of this is that it hides the underlying state mutation from the implementation.

Now your move functions are pure and isolated from the coords atom, in addition to the fact that multimethods made the logic more organized, at the expense of a few more lines of code.

edit: moved code to gist

<comment><USER13> In my experience mulltimethods get you a long way when writing Clojure code. My projects use them often and add two or three macros. That is normally the only "overhead" I have to impose over regular functions.

That said, in the example you posted I don't think you are using all the power of the multimethods, because you did not replace the case statement. You went from a case statement to a multimethod+a case statement. In this case, why not let the mutimethod dispatching to do all the routing/case functionality for you? Just use (.-keyCode e) as your dispatch function and use the different values of KeyCodes.XXX for each implementation of the multimethod. And you can even add a :default implementation that leaves the coords untouched.

In my experience the natural use of multimethods arise when you can choose the dispatch function for an element based on either some piece of data from the element or a computed value derived fron the element. But if you have to rely on case/cond/if statements the value of the multimetod is lessened, as you still have to touch your dispatch function when your hierarchy of values change.

edit:typos in the code

<comment><USER10> Very good point. This was an artifact of the way my wife originally structured the function (dispatching on the keywords :up, :down, :left, :right), and I just kept that.

</comment></comment></comment></comment><comment><USER14> I actually had something similar a couple of weeks ago. My initial model was just:

      val cards = for {
        rank <- 'a, '2, [...], 'j, 'q, 'k
        suit <- 'h, 'c, 'd, 's
      } yield (rank, suit)
      val deck = scala.util.Random.shuffle(cards)

which gives you something to play with to validate your model. It's not an api I'd choose to publish, of course, there are many better type-safe ones written here, though I'm sad none of them have used Unicode for suits (I know someone working on a dating app who used a method called ❤ to compare two users: so something like "if (sappho ❤ rhodopis > 95) { ... }")

But my point is that Scala gives you the option, and is tolerant, of working in this slightly dirty way, and then lets you clean it up (and a type-safe compiler will flag up where you are using your old api). I don't know clojure well enough, so, what's the similar workflow there?

<comment><USER15> So some developers will love type-systems, and some will prefer to stay in Lisp-land forever. :-) The OP seems to be a lisp hacker at heart, and Clojure is the batteries-included Lisp du "jure". (sic)

</comment></comment><comment><USER16> The article starts saying that Scala gives you lots of options while Clojure guides you to a certain style, but the Scala example takes the most complicated solution as if every programmer would solve it that way. He's contradicting himself.

Scala can solve it in a way quite similar to Clojure. The author is trying to hammer a point about Clojure which doesn't emerge from the example, as most Scala programmers can notice.

It would have been great if he had listed all the possible solutions and told us "Scala lets you solve it in all these very different ways without the language guiding you, Clojure guides you to the simpler solution". That's a fair point, and one Scala programmers will tend to agree with.

<comment><USER17> Agreed, any problem may be better solved by one or the other. What I notice, having never used Clojure, is that the Clojure devs may well finish the implementation while the Scala devs are still discussing the design. Of course, that level of flexibility will better suit some problems. I read a high profile project's coding guidelines recently: "Scala is a very flexible language. Use restraint." Perl's TMTOWTDI is the reason I moved to Python. I've recently been using Go instead of Scala, partly again because TMTOWTDI, whereas Go is supremely clean, but also, I think, Scala is just too big for my needs, a skyscraper when I need a house. This sounds a bit like sql vs nosql, rather than when should I use x vs y. I look forward to trying Clojure.

<comment><USER4> Have you considered F# (or Ocaml), or Haskell? I can see good reasons to move away from Scala, but I don't think you need to throw away all that wonderful functional typing goodness.

</comment></comment></comment><comment><USER18> The example cited here is insulting to everyone's intelligence:

      The possibility of representing face cards with a name would likely never occur to you, because it would be too complicated to go through the effort of defining the type of a rank to be a "integer or a class comprised of four case classes -- jack,queen,king,ace".

I'm sure every competent Scala developer will see that the equivalent in Clojure can be done with _val King = 13; val Queen = 12; ..._ , which also means you get ordering for free as you're not mixing ints and keywords.

I do agree with the author's point that Clojure almost forces you to adopt a simpler design, but I feel that long-term maintainability requires a delicate balance of simplicity and structure that can be achieved with Scala, but takes more self-control with Clojure.

<comment><USER19> Using _val King = 13; val Queen = 12;_ in Scala is not equivalent with using Clojure keywords, as their printed variant will be 13 and 12, not :king and :queen. Reading debugging output or logs would force you to manually convert those values.

Ordering for free is valuable, I guess, but it sort of depends on the situation. Sometimes face cards are worth 10, other times they are worth 11, 12, 13. If you use _val King = 10;_ , then it suddenly is impossible to distinguish between face cards and tens.

<comment><USER20> Right, if you wanted to have an ordering around, you would use an enum. The enum's values would print as Ace, 2, 3, 4, ..., Jack, Queen, King, and then when you wanted to implement a particular game the game could define the mapping from rank -> set of possible values. You wouldn't want to map each rank to a single value, since in commonly played games aces are worth both 1 and 11 or both 1 and 14.

If you didn't want the ordering (or the compiler warning when your blackjack implementation omits queens), you could use Scala's symbols, which are more or less the same as Clojure's keywords:

      scala> 'king
      res0: Symbol = 'king

<comment><USER21> Or use value classes and get the best of both worlds.

</comment></comment></comment></comment><comment><USER22> Scala feels like the Perl of the modern era: there is more than one way to do it. There is value in that mode of thinking, and Perl is a better language than people give it credit for.

However, I think there's a reason Python and Ruby have overtaken Perl in the interpreted language space: Python values simpler solutions [1]. Ruby also values a certain type of beauty over Perl.

Clojure/Scala is a similar dichotomy. Scala has everything you might need, while Clojure is rooted in the spartan power lisp provides.

Also, I wonder: if they weren't both JVM languages, would we even be having this type of discussion? I mean, we aren't comparing Clojure to Cobra or D.

[1] See the Zen of Python [http://www.python.org/dev/peps/pep-0020/](http://www.python.org/dev/peps/pep-0020/)

<comment><USER23> Back in my uni days, aka not that long ago, the scala (which I love)/perl (which I hate) comparison is what made me realise that language arguments are almost always pointless. Any choice you make in a certain class of language is probably going to be roughly equal in terms of ease of use, productivity, whatever; so you might as well just go with what you are comfortable with.

<comment><USER4> I also love scala and hate perl. I wonder how close the correlation actually is - do the same type of people really like both, or is this just something people who don't like scala say?

<comment><USER24> I am not as fluent in Scala as I am in Perl, but I do like both. Perhaps, I am an exception.

</comment></comment></comment></comment><comment><USER20>
      type Card = (Any, Any)
      type Deck = Seq[Card]
      val foo: Deck = Seq((4, 'clubs), ('king, 'diamonds))

It seems to work over here. I would have to be a bit out of my mind to actually want to write code this way, though.

As to the "Lightweight data modeling" pitch, there's a pretty large number of other languages that are better suited to this because they have TCO (when run on their main platforms, the analogues of the Sun JVM) and don't require you to debug apparently-endless stack traces in a different language when your completely untyped exploration/prototype inevitably explodes.

</comment><comment><USER25> Looks like a slow news day.

A dynamically typed language is _obviously_ easier to begin coding in, especially with a trivial example. The problems that statically typed language solve are usually found in larger code bases and in performance critical applications.

<comment><USER26> There is an orthogonal Clojure/Scala axis of interest for code bases of appreciating size: Mutability.

Clojure programmers choose immutability by default. Scala, however, makes it just as easy to write "var" as it is to write "val", and just as easy to create a mutable collection as it is to create an immutable one.

In my experience, this is far more important for larger code bases than static typing. Luckily, Scala offers immutability as a feature, which is more than can be said about Java/C++/Go/etc.

<comment><USER27> Interesting! I suppose var and val are as easy to type, but in Scala my mental default is always val; var is a smell to me. Isn't that the case for most people writing in Scala?

</comment></comment></comment><comment><USER28> > On the other hand, in Scala, you'd be more likely to create a card Class > with a rank and suit field.

No, if I was trying to do something intended to be generic, I'd be tempted to start out with this definition of Card:

      trait Card

Scala makes it cheap to use descriptive type names while starting out making minimal assumptions. This helps avoid making too many assumptions up front, like the whole model-cards-as-ints one.

> For modeling the deck, you probably wouldn't say a Deck is-a sequence, > because composition is favored over inheritance.

"X is favored over Y" does not mean "never use Y". And, in Scala, "favor composition over inheritance" mostly strongly applies when you are talking about classes, particular classes as the thing being either composed or inherited from.

I'd probably say something like:

      trait Deck[C<:Card] extends Seq[C] {
        ...whatever special behavior Decks need to support in general...
      }

</comment><comment><USER29> I find it interesting that there are about 50 comments in this thread discussing the best/better ways to model the problem in Scala, and no controversy at all about the Clojure implementation.

That's a feature of Clojure, IMO.

</comment><comment><USER30> I am not sure I would agree that the deck example he gave represents the Scala idiom. I myself would probably start with something like

</comment><comment></comment><comment></comment><comment></comment><comment>

object Cards {

type Deck = Seq[Card]

case class Card(r:Rank, s:Suite)

type Rank = Int

sealed trait Suite

case object Spade extends Suite

case object Heart extends Suite

case object Diamond extends Suite

case object Club extends Suite

}

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>====

Granted, all this code is unnecessary in Clojure but there are two benefits of writing them:

1) compilation type check

2) for developers who have no context of playing cards, this provides a clearer picture, while in the Clojure code they will have to browse more code to get the full picture of the data domain.

<comment><USER27> I think that last part can be especially important.

I'm perfectly comfortable with both approaches, but as things get bigger, I value explicit structure more than convenience. When I'm dealing with implicit structure, I definitely notice the increased cognitive load.

That's fine for something small, short-lived, and personal. But if I'm doing something large, long-lived, and shared across many people, I think implicit structure gets more and more dangerous. It's hard to keep everybody's mental models aligned over time, which makes it easy to end up with a code base whose coherency declines.

</comment></comment><comment><USER31> After modeling Clojure's Card Deck as a simple sequence of maps, the author models Scala's card deck in an overly complex way using a Deck Class with a nested card class, and each card nesting four distinct case classes to represent suit (Yikes!). The author defends the terrible Scala design by writing:

> Sure, you could eschew objects in Scala and mimic Clojure by using generic > maps/vectors/lists/sets for all your structured data needs, but that's > clearly not how Scala is meant to be used.

Scala isn't "meant to be used" any way. Scala is a lots of things (often times to its detriment) but opinionated is not one. The author even alludes to this early in the post:

> Ten years ago, I would have said that my ideal dream language is one that > provides the flexibility to program in any style. I want to be able to > choose object-oriented or functional, immutable or mutable, high-level > abstractions or low-level speed. With respect to this ideal, Scala clearly > wins, supporting more programming styles than Clojure.

Classic fanboyism, as the author purposely created a shitty Scala example. I would advise that someone investigating functional languages on the JVM take this post with a grain of salt.

<comment><USER32> Not surprised by this comment. Scala has the most bitter community I've ever seen. Contrast that to the Clojure community

<comment><USER31> Why would you paint an entire programming community as bitter? That is extremely close minded.

The author clearly contradicted themself. Did you read the article before downvoting? Also why invoke a false duality like someone being part of the Scala or Clojure community is mutually exclusive? For what its worth, I have used and am a fan of both languages. That won't stop me from pointing out a flawed post though.

</comment></comment></comment><comment><USER33> _Well, imagine if you could represent all your data as JSON, rather than a complex hierarchy of objects and methods, and the language was designed around making that kind of data super-easy to work with._

Then imagine that you could represent your code as JSON and also that a database existed that let you store and build queries on JSON directly (i.e., Datomic).

<comment><USER8> Come back to me when there's a standard for JSON schemas so my data can be actually strongly-typed + verified.

<comment><USER33> JSON was used in the original article as a placeholder for Clojure forms. You can (optionally) get strong typing using Clojure records[1] (see defrecord) or using core.typed[2]. Datomic also lets you specify types[3].

I'm not "coming back" to you, as I don't appreciate your snarky, know-it-all tone. I'm replying for the benefit of others reading who may not be familiar with Clojure.

[1] [http://clojure.org/datatypes](http://clojure.org/datatypes)

[2] [https://github.com/clojure/core.typed](https://github.com/clojure/core.typed)

[3] [http://docs.datomic.com/schema.html](http://docs.datomic.com/schema.html)

<comment><USER34> I think the parent is saying basically: Greenspun's eleventh rule

       Any sufficiently complex Lisp implementation contains
       an ad hoc, informally-specified, bug-ridden, slow
       implementation of half of Haskell's type system.

</comment></comment></comment></comment><comment><USER35> I actually think that Clojure's relatively unique feature which differentiates it from most languages (other than, perhaps, Erlang and Haskell) is its emphasis on managing state, especially in the face of concurrency.

<comment><USER36> Sort of. But I don't think most people are actually using the concurrency primitives in Clojure all that much. How many systems out there that people are writing make heavy, or even significant, use of concurrency primitives? I'd guess it's definitely the minority.

Immutability and programming with data structure literals are what Clojure's all about. Lisp, dynamic, and functional are obviously the other big choices that were made to achieve the overarching goal of the language - simplification. But imo, programming with performant, immutable persistent data structures is the essence of Clojure programming.

<comment><USER10> I agree that immutability is central to Clojure and the resulting code definitely reflects that. But managing state, as the OP put it, truly is what Clojure is all about - and immutability falls out of that very deliberate design decision.

Let's not confuse the lack of significant STM transactions with refs and its irk with representing the totality of Clojure's concurrency story. Many Clojure libraries make use of atoms, agents, and dynamic scope (which is arguably a concurrency primitive, given the thread locality of the bindings, but not unique to Clojure).

While "concurrency is not parallelism", parallelism is a special case of concurrent programs that is often challenging. Clojure's offerings here too are compelling - we have the amazing Reducers library which allows you to write higher order functions for collections that, as Rich Hickey put it, "know how to reduce themselves" \- and get parallelism (without locks, without even thinking about it really) on top of that.

And then there's the lazy parallel functions - pmap, pcalls, pvalues. Check them out if you haven't. I use Clojure often in a machine learning context with Hadoop/Storm, these abstractions are highly valuable in crafting solutions.

Futures/promises are also widely used in Clojure.

I'm confused as to why you think data structure literals are part of Clojure's core thesis. Perhaps I just don't understand what mean - are you saying that the fact that the Lisp reader can read strings as data structures as being part of what Clojure is about? If so, that statement would apply to all Lisps, not just Clojure.

<comment><USER36> >I'm confused as to why you think data structure literals are part of Clojure's core thesis.

I use refs, atoms, and agents very sparingly. You just don't need them very much when you have a suite of performant, immutable data structures (with literals). These data structures, and the assortment of polymorphic functions provided in the language to operate on them, imo are the crux of the language. They dominate the experience of the programmer. As far as managing state goes, they make it so that you rarely have to reach for the explicit constructs listed above.

</comment></comment></comment></comment><comment><USER37> If object-oriented programmers (here represented by Scala-ites) are excessively fond of modelling the crap out of stuff, to the detriment of the code they're trying to write, there is also a problem with the opposite, "lightweight data modelling" approach: a weird fascination with representations of data, instead of the structure of it.

Here's an example from _Land of Lisp_ :

        (defun limit-tree-depth (tree depth)
          (list (car tree)
                (cadr tree)
                (if (zerop depth)
                    (lazy-nil)
                    (lazy-mapcar (lambda (move)
                                    (list (car move)
                                          (limit-tree-depth (cadr move) (1- depth))))
                                 (caddr tree)))))

and here's the version that I re-wrote, using your friend and mine, defstruct:

        (defun limit-tree-depth (tree depth)
          (labels ((limit-depth-move (move)
                     (let* ((next-tree (limit-tree-depth (get-tree move) (1- depth))))
                       (if (passing-move-p move)
                           (make-passing-move :tree next-tree)
                           (make-attacking-move :src (attacking-move-src move)
                                                :dst (attacking-move-dst move)
                                                :tree next-tree)))))
            (make-tree-node :player (tree-node-player tree)
                            :board (tree-node-board tree)
                            :moves (if (zerop depth)
                                       (lazy-nil)
                                       (lazy-mapcar #'limit-depth-move
                                                    (tree-node-moves tree))))))

I submit that the second may be preferable, even if it is a bit more verbose.

<comment><USER11> agreed

</comment></comment><comment><USER38> > All or nearly all of the functional aspects of Clojure have counterparts in > Scala. On top of that, Scala provides [...]

Scala doesn't provide the syntactic macros, or the same simpler approach to concurrency.

<comment><USER39> Scala macros are different. We deeply respect the Lisp tradition, in which we are rooted, but we also accommodate and empower our language's values - <USER3> types and rich syntax [1]. The end result is admittedly less flexible, but it also opens a number of interesting possibilities beyond those available in Lisp [2]. Our design is also not set in stone, and we're experimenting with different macro flavors [3], but it's too early to say something definitive about those.

[1] [http://scalamacros.org/paperstalks/2013-09-19-PhilosophyOfSc...](http://scalamacros.org/paperstalks/2013-09-19-PhilosophyOfScalaMacros.pdf)

[2] [http://scalamacros.org/paperstalks/2013-12-02-WhatAreMacrosG...](http://scalamacros.org/paperstalks/2013-12-02-WhatAreMacrosGoodFor.pdf)

[3] [http://docs.scala- lang.org/overviews/macros/annotations.html](http://docs.scala- lang.org/overviews/macros/annotations.html)

</comment></comment><comment><USER38> There seem to be 4 primary programming paradigms available on the JVM...

Clojure - concurrency (immutable by default), macros (lisp-style)

Scala - object/functional fusion, lazy evaluation

Ruby dialect (JRuby or Groovy) - "methodMissing" meta-object protocol

Java - low-level OOP (but functional lambdas and lazy streams coming in Java 8)

COMING SOON: Javascript (Rhino or Nashorn) - functional with prototype-style OOP

<comment><USER40> Clojure uses a lot of lazy evaluation in its collections library. Does that count?

<comment><USER38> Yes, I just listed the features of Clojure that weren't available in any other production-ready JVM language.

</comment></comment></comment><comment><USER41> So it seems sometimes that being 'forced' to adhere to lightweight data structures and functional methods makes all the difference. I'd tend to agree with you, as I have noticed that it is hard to avoid OO and imperative techniques when I have that option.

</comment><comment><USER42> Perhaps I'm missing something about Clojure, but it looks completely and utterly foreign. As someone who didn't have much trouble learning a "complex" language like Scala I find Clojure really hard to fathom.

<comment><USER43> Have you learned other Lisp-like languages before? Lisp exists truly in its own realm, syntax wise.

My experience so far is Logo when I was 6 and reading Godel, Escher, Bach, but I was thinking yesterday of investigating Clojure and that's my task for today. I'll check back.

<comment><USER38> > Lisp exists truly in its own realm, syntax wise.

It's fairly easy to put another syntax atop Clojure if you want, though in my experience the net effect is to _restrict_ what Clojure can do, beginning with disallowing macros.

<comment><USER43> I'm looking forward to embracing its lispiness.

</comment></comment></comment></comment><comment><USER44> It seems to me what he calls "lighweight data modeling" is a synonym for "untyped data". Use ints, strings, arrays and maps to model everything (his JSON example).

It's great for prototyping but when you start getting big, you really need to tighten these models down to real types.

</comment><comment><USER45> Why vs? What a false choice, I love both of them.

</comment><comment><USER46> There is no language I love more than Clojure but I would never describe it as "lightweight" (as I wait 5-10 seconds for lein repl to load).

</comment><comment><USER32> Despite the "kumbaya, we're functional brothers...we all win", I know for fact (very reliable sources) that the Typesafe guys absolutely hate the traction that Clojure is getting, especially that they need to get a ROI on their funding.</comment>


Don't Panic: there's more TTL - <AUTHOR> https://karla.io/2016/06/12/dont-panic.html <comment><USER2> This could be a really neat canary too</comment>


Tweet You and The Horse You Rode In On - <AUTHOR> http://tweetagewasteland.com/2010/05/tweet-you-and-the-horse-you-rode-in-on/

<comment><USER2> Before I write long pieces these days, I will usually email or instant message with a buddy of mine and work out the ideas in realtime or near realtime. In some ways, my longer stuff is a collection of these short blurbs.</comment>