m0nastic

I'm not willing to concede that strong static typing is a universal truth though. Too many people much smarter than me seem to disagree.

I think people argue about which language is better for much the same reasons they argue about which mobile phone operating system is better, or which console, or which text editor. They've invested (in the case of programming languages, potentially many years) in something, and want to feel like they've invested wisely. I think that's also probably just human nature.

I disagree with the notion that programming languages need to be popular, at least, as popular as they needed to be in the past.

20 years ago it was important for languages to be popular because that was the only way they'd reach enough critical mass to be discoverable. Growing up, there was only one book store within driving distance of my house that had any programming books. That meant if you wanted to learn programming, you were limited to what had been "blessed" by industry (in my case, one book on C++ that was actually just a syntax reference). That seems to no longer be true (the internet has made discovery of programming languages easier in much the same way it's made the discovery of everything easier).

There is certainly a benefit to having critical mass, but that mass seems to be much smaller than has ever been required in the past. I've seen Haskell developers on several occasions talk about the fact that Haskell's popularity has been in this nice "happy medium" that provides enough eyeballs to flush out issues and provide feedback, but also allows them to not worry about breaking things.

A language getting popular is not all benefits with no drawbacks. It gets harder to make breaking changes to the language (Javascript can be considered a good cautionary tale about what can happen when a language becomes so popular that you are held hostage by backwards compatibility). And you can't read a single article on here about some less popular language that doesn't prompt at least one comment about how because the language isn't popular, the quality of developers using it is higher (which is always posited as a plus for hiring developers in that language). Paul Graham mentioned it regarding Python explicitly in one of his essays.

More people being part of a community means more everything. More of what's good (libraries, eyes looking at bugs, ideas on solving problems) and more of what's bad (bike-shedding, shitty libraries, conflicting programming idioms).

I have no idea if there's some magical sweet spot, where you get all the benefits of a language being popular without any of the detriments; but I suspect it doesn't exist. As it stands, yes, I'd like there to be more Haskell libraries. I'd like there to be more blog posts about using Haskell for things that aren't abstract math. But I'm not necessarily itching for Haskell to become much more popular.

We're already starting to see some of the industry people that use Haskell start to explicitly target evangelism (like the work FP Complete is doing). I think it's great that they want other people to use this thing that they like, but I am worried anytime a community switches from "stealth" mode to "evangelism" mode. Incentives around addressing problems starts to become perverse when you have to worry about messaging, and when you're trying to convert other people. It seems like it evolves eventually to cargo-culting.

As an industry (and a research area) there still doesn't seem to be any real consensus around "what's best"; just a bunch of differing opinions and trade-offs. I don't think any amount of evidence (were it even to exist) would convince someone not amenable to strongly-enforced static types to see their value.

The entire practice of software development seems oriented around feelings and past experience. I can appreciate that their are groups of people doing research to try and bring rigor and quantified data to the process, but if at the end of the day, a developer can spend a weekend putting together a node.js web app and have that take off and prove successful, you've pretty much lost any opportunity to convince them that they should stop using their tools and switch to some different tools.

I don't actually think there's anything wrong with that either; good for them for being suspicious.

I decided to investigate Haskell about 8 months ago when I had an opportunity to write a big system for my job. It fit well within my constraints and requirements, and the little I knew of it at the time seemed like it would be a good language to spend time getting to know.

I liked that everything in the language seemed like it got there through reasoned debate and experimentation, and that it seemed like a language-feature sandbox that more mainstream languages were eventually pulling from (Perl advocates say the same thing about Perl, mainly that it already has all the features that other languages are now trying to figure out how to implement). I liked that they don't seem to punt on the hard problems (which over time become more and more of the problems left for languages to address), even if that means that doing complicated things in Haskell is complicated.

I don't know how I'd feel about Haskell suddenly becoming super popular though. Even aside from the "God I hate that this band I've been into for a while is now suddenly popular" trendiness, I don't think the community would be able to handle sanely what an influx of massive amounts of new users would do to things. It's hard enough getting all the category theorists and abstract algebra professors to deal with the fact that Cabal takes lower and upper bounds on dependencies.

If I could spend the entirety of my career using Haskell for everything, maybe that would be great. I haven't gotten good enough yet to have strong opinions about its failings, so I'm still very much in the honeymoon period.

But that seems like a silly thing to shoot for, even if I feel the same way about Haskell in 10 years that I do now. And it seems silly to expect that everyone else would feel the same way.

I had the same question about how it compares to clang though. I suppose now that it's open source, someone can do some testing.

If you find reading other people's comments fulfilling (either on your own site or on sites that you visit), that's awesome.

I tend not to read comments on any site that has them. I consider sites like HN which exist solely for comments an exception. If I had a blog, I certainly wouldn't let other people comment on it. I suppose this means there's a chance I might miss out on some really enlightening comment that someone makes. Based on ~20 years of reading comments on the internet, I'm willing to take that chance.

It might just be my innate negative reaction to someone telling people what to do, but listening to someone make bullshit blanket statements about how you should spend your time pisses me off (although at least he said "please").

When I originally looked at using Yesod, it seemed fairly complicated for what I needed (which is basically just the crud-iest of crud apps). I'd only been using Haskell for a couple of months, and I'd never done any web programming; so I figured I should try to use something that wouldn't require quite so much "stuff".

I finally decided to try out Clojure because I'm planning on using Datomic for the main datastore (because it looks like I can have it backed by Cassandra, which lets me store all of our data in an HDFS cluster.) and the "Web Programming with Clojure" book just came out. I figured I could probably figure out a very basic database-driven view web app just by going through the book. That turned out to be true, actually, and it wasn't that hard to get my app up and running.

What dawned on me going through the book was that what seemed complicated to me really wasn't a function of the language, but the way almost all mvc web libraries seem to be laid out; and that actually once I understood how they worked, I could probably implement the same thing very similarly in almost any language that has a similar library.

So I might eventually look into making a REST api using Snap to handle the requests, and sort of encapsulating all input and output in the system with Haskell.

It looks like the new Planet that you guys just shipped doesn't have all the legacy mzscheme packages that used to seem to be the majority of packages. I don't know if that was intentional, but if not, I think that it's a nice tangential benefit.

I just remember every time I'd search for something on Planet, most of the results I'd get back were for old scheme libraries.

I know it's annoying as a developer to hear a vague criticism like "there's less useful libraries" without being able to provide a list of concrete items; but I'm going to annoy you by not being able to come up with anything specific right now. Sorry ;)

I will say though, I think Marketplace looks really neat, and I'm looking forward to testing it out for some things internally.

While I could probably do everything in one language, I'm not sold on the idea that that's actually a good idea (aside from developer convenience, which considering I'm the only developer I don't rate very highly). I also don't feel qualified enough as a language person to really hold defensible opinions about their relative strengths and weaknesses yet.

For example, part of the system is a network service that runs deployed on servers in our environment. All that code is Haskell. I didn't want to have to deploy and manage an interpreter or JVM on those systems, and I don't trust myself to write C that I feel confident deploying in production. Haskell seemed like a good win there (other folks might use Go, or whatever). It turned out to be really easy to write a network server in Haskell that receives the messages that the service needs to receive. Also, it was the first time I used a language that had good (or really, any) pattern matching, and I'm sold on it.

The "business" logic of the system is all currently in Racket. It could certainly have been written in Haskell, but I'm still getting up to speed in it, whereas I was able to get pretty minimal functionality up and running with Racket very easily.

Right now only the web interface is Clojure. I briefly considered using Yesod for the web piece, but it seemed really complicated. And although Racket has a nice web server, it requires buying into the "continuations" style that they advocate (or rolling your own web libraries, which seemed like a bad idea for this project).

I think the continuation-based approach for web servers is certainly valid, and maybe even technically better, but they're swimming against the tide with that approach, and as web programming is so far my least favorite part of building this system, I wasn't willing to buy into that enterprise.

Thankfully, I was able to get a Clojure web app up and running very quickly (basically just Ring and Compojure).

The system is designed where there's pretty hard boundaries between all the parts, so by the time all is said and done, it might all be written in the same language; but that's not necessarily a design-goal. I figure different languages seem to have different strengths, and there's not really a good reason for me to try and shoehorn everything into one.

Also, that's not a listing of the total number of libraries; it's ranked based on the number of useful ones (where "useful" is a completely subjective term that relates to how often I've looked to see if a library exists that does what I want).

Racket actually has more overall libraries than you'd expect considering its popularity, but I've found that many of them are old, no longer updated, scheme libraries (from the days before Racket rebranded from Dr. Scheme). That certainly doesn't make them useless, but I'm reticent to mix scheme-style code into my project.

I'm least familiar with Clojure (I've only been deploying it for the past two weeks or so), so I'm sure my opinion will change, but right now it feels like a slightly less good Racket with a philosophy I find agreeable and more practical libraries (plus Java interop).

There aren't as many libraries available compared to more popular languages, but I haven't yet had too much trouble getting things accomplished. For the above-mentioned languages we're using, I'd put the useful library situation at: Racket-> Haskell-> Clojure in order of least to greatest.

Depending on what you need it to interoperate with, it's totally usable in production environments as it stands.

By most reporting[1], the office team has already had versions of office for iOS (and presumably Android) ready for quite some time. Their lack of release has been an internal political battle at Microsoft based on whether to postpone them until after the equivalent office apps are ready for RT. This is one of the biggest examples of decision making that people have been criticizing Microsoft for (handicapping their non-Windows business units to provide Windows a competitive advantage; which is a sensible strategy, but that seems ill-suited longterm, as those other business units like Office now eclipse Windows in revenue).

It's entirely possible that part of Nokia releasing this phone is related to that recent shift in strategy.

How are Microsoft going to be able to maintain two mobile OSs?

Nokia already has experience in managing operating systems. I don't know how much work "porting" over all the Nokia apps was to Android, but it seems like they've done it. They already went through the experience of porting many of them over from Symbian (and alas, Maemo didn't really have much in the way of Nokia apps). I don't think this is a serious issue for their engineering organization (even aside from Microsoft's much larger engineering organization that presumably could be made available).

Are Nokia going to see this through? I think it is a smart play, if they go after it whole-heartedly like Amazon and provide a decent amount of differentiation. One could easily see Samsung going this route.

I think this is a logical play from a risk perspective. The low-end is currently where all their sales are (as the mid and high end have dried up faster than their increasing Windows Phone sales have grown); and even though the low-end isn't the desirable part of the market (see every phone manufacturer other than Apple and Samsung as examples), the effort required isn't much greater than they're already doing for the Asha lines.

I think they'll have a better chance at building an ecosystem that's piggy-backed off of Android than in building their own. I still don't know that this is a great long-term play, but it could be.

Samsung has been alleged to be heading in this direction for ages (first reported as the reasons for them releasing Bada, and later, Tizen). The new Gear 2 watch-thing runs Tizen instead of Android (which considering it's not really a stand-alone device, is probably a good place to test the waters).

It seems like the issue with Samsung taking the plunge is how much they attribute their recent success to their own products, vs. the Google ecosystem. Once they cross that threshold, they'll ship their own OS with TouchWiz on top of it. Maybe they'll similarly have an environment that can run Android apps (it's all Linux underneath).

[1] http://www.zdnet.com/microsoft-office-on-ipad-its-alive-and-...

We made a Suite B implementation for TPM's (where smaller key sizes are very very important).

I certainly can't think of any way to spin the way this turned out to be positive for Google, but I don't think the absolute numbers will worry them all that much.

I haven't seen anyone here mention that at the time of the acquisition, Motorola was attempting to sue all the other Android manufacturers over its patents; and it was posited that Google was basically forced to buy Motorola to keep them from poisoning the ecosystem.

I assume that not happening was probably worth more to Google than what they would up having to pay for Motorola.

Psychologically, it does help reinforce the idea that Google really doesn't know what it's doing with regards to hardware (although hey, they just paid more for Nest than potentially what they're selling Motorola for).

SQL? Like in relational databases? Like in relational algebra?

I think this demonstrates the point someone made upthread that people don't consider a lot of math to be math.

San Jose was pretty shitty then (I have no idea what it's like now, but it sounds like it's basically the same).

I also didn't find anything redeeming about San Francisco (which I realize is a minority opinion), so I stayed in Santa Cruz as long as I could (before eventually relocating to DC after the company closed the rest of our offices out west).

I don't think the software has any intrinsic value; it wasn't constructed from precious metals, which could be re-smelted and sold for scrap. If continuing to develop it/maintain it is costing them money (either in real terms because of development costs, or by lost opportunity costs), than they should look at how that's trending. At what point does the thing cost more than it's worth to them? (Maybe it never does, I've had banking customers who spend millions of dollars a year keeping a thirty year old, p.o.s. Cobol application running because it's the backbone of their operations).

And I didn't mean to imply that they should rewrite parts of it in another language, just that they should start decomplecting pieces of it so that they can replace those pieces with better-designed ones. If they want to stick with Perl, because that's what their expertise is, than I think they should do that. I would agree that it's probably counterproductive to take on both rebuilding the application while at the same time switching to a new language.

But unless the entire application is passing around internal Perl data structures, it seems crazy that they can't identify edges to the application functionality, and start to peel those edges away and encapsulate that functionality in a better way.

It would seem like the obvious answer would be to not sit down and rewrite the whole thing from scratch, but start replacing pieces (with whatever language they think they'll be successful at).

The idea that they should somehow just be stuck forever with a shitty mess of a perl application seems incredibly defeatist.

I think there is a kind of idealized scientist that nerds want to look up to. A great sense of humility, a clear sense of purpose, an unwavering commitment to reason and rationality. Yet I can think of no famous scientist that actually fits that mold.

Another poster brings up Kanye West, someone that people seethe over that he isn't humble enough.

I read in the parent's comment a sense of great frustration, that somehow Wolfram isn't being sufficiently reverent to someone who they clearly idolize. I can almost see spittle forming at the corners of their mouth. It makes me a little sad.

Wolfram certainly doesn't do himself any favors by reinforcing the narrative that he has a big ego, and always working in a reference to his book (which I think this essay is much more appropriate for then how he shoe-horns it into his other writing).

But I get it. People don't like it when you toot your own horn. Although if I spent ten years writing a giant science tome I'd probably want to bring it up all the time as well. I suspect Wolfram is aware of this perception of him (I think I've actually read him mention it before). I kind of hope he ignores it though.

Maybe that's not true if you're a C programmer, but pretty much any other language has a fairly good, "just what's necessary" web framework.

If you're coming from a less popular language, your options might be limited, but I can't think of any even moderately mainstream language that doesn't have at least one decent option.

If you like Java/Scala, you might look into something like Spark.

I don't know how feasible a system would be though (I've heard of places that do that for regular PTO, but not vacation).

I don't particularly worry about my individual privacy, or care about securing my things. If someone managed to get a hold of my email, I wouldn't be very put out. I don't encrypt my hard drives, or even back anything up. My lack of security and privacy hygiene, however, doesn't extend to my work stuff. I care about maintaining the confidentiality and privacy of that stuff because it's part of a social contract (and I suppose also an employment contract) that I have with my work and my clients.

Instead of his diary example, what if he had asked his friend "Can I copy all of the emails off of your phone, or all the phone numbers in your addressbook?" Maybe they still wouldn't care, or maybe they'd now have to take into account the fact that all that data also involves other people, and maybe they wouldn't find it acceptable for you to give our their cell phone number to anybody who asks.

So much of the data that we accrue is increasingly more interconnected with other people. I feel like that's where we run into trouble, because there is no universal consensus around what's private and what isn't. We have rudimentary laws protecting the smallest subset of data which the government has decided should be considered private, but everything else is a value judgement for individuals (and is part of the current internet company land-grab).

I feel like his position is going to be harder and harder to maintain, as more and more of the "personal" data he's okay with sharing includes other people's data.

I actually didn't see the BH talk, but I saw a similar talk that Halvar gave at CanSecWest shortly after.

The gist of it is, imagine that you have a binary that you are looking to find vulnerabilities in to exploit. You can go through all the trouble of discovering a vulnerability, and then hope it doesn't get patched; or you can sit and wait for a patch for said binary. There's reams of data out there about how long it takes for systems to apply patches, but in general, you can find vulnerable versions of patched software long after the patch has been released.

Using binary differential analysis you are basically zeroing in on the parts that were changed (which you can imagine is a much smaller subset of the overall binary) and find the vulnerability much more quickly.

There are tools (there is/was a product called Bindiff that I don't know if Zynamics still sells after they got bought by Google), which help you do this in a more automated fashion.

That means that with much less work, you can write up a working exploit that will still work on some decent percentage of the install base for the application (until everyone patches it).

Additionally, you can imagine that a lot of times when vulnerabilities get fixed, they aren't necessarily fixed with the utmost rigor. There's a lot of cases where an individual vulnerability might be fixed, but if you look at what was done, you can find other parts of the binary that are vulnerable to the same underlying flaw. Knowing what gets changed in the patch can tell you a lot about underlying issues.

1.) We didn't have any existing infrastructure, so there were no requirements around language, environment, or tooling.

2.) I was the only person who would be developing the system.

3.) I was predominantly the only person who would be interacting with the system once it was deployed.

4.) Existing solutions to the problem I'm trying to solve are generally very expensive (either directly through the cost of the software, or indirectly through having to have professional services consultants do the integration), so it was pretty easy for this project to prove it's worth.

5.) I'm not actually paid to be a developer, so if the whole thing turned out to be a dismal failure, my boss doesn't care.

So I used this project as an opportunity to try out Haskell and Racket, two languages I didn't have any prior experience with (I had learned Scheme in school through SICP but hadn't touched it in 15 years).

I settled on Haskell for the parts of the system that were going to be deployed out in our environment. So far, that's been a server that collects events, parses them, and then forwards them along. I liked that Haskell compiled to native code (I didn't want the additional complexity of dealing with deploying an interpreter or virtual machine). I looked at using C and Go as well, as they both met all my criteria. Go doesn't really do anything for me, which admittedly isn't a great reason for not using it, but as I didn't have to sell anyone else on my decisions, that was enough. C is actually a more conventional fit for the type of server I built, and the only reason I didn't go with C is that I honestly don't trust myself to write performant, safe, C that I'd be comfortable deploying all around my enterprise.

That's not an indictment of C, it's an indictment of my abilities as a programmer. Thankfully, I'm not really a programmer, so I can still sleep at night.

In writing the server piece in Haskell, I discovered that most of my worries about it being an esoteric academic language were unfounded. I think most of that reputation comes from the fact that a large portion of the community using it is academic, so they use it for academic things, and tend to talk about it using "computer science-y" terminology. The Haskell planet blog aggregator, for instance, I've almost never found to be comprehensible. That's not their fault though, it just doesn't seem like muggles are writing blog posts about using Haskell to solve real problems. Hopefully that'll change over time as the language becomes more wide-spread.

I was very impressed with using Haskell to parse events though; I think I'm ruined on ever going back to a language that only lets you use RegEx's.

I was worried about how usable Haskell would be for really cookie-cutter systems type programming, as there isn't a lot of material online to help you do that type of stuff. Real World Haskell turned out to be a super good book though, as it was much more closely aligned with what I was doing. I was also worried about the small number of libraries compared to 1st-tier languages, but for what it's worth, that hasn't really been an issue.

If I were a good Haskell programmer, I'd have no qualms about using it for everything, but I'm not (at least not yet), so I'm doing all the application logic and web UI stuff in Racket. Obviously, people use Haskell for web programming, and it seems like Yesod is getting much better, but it was much easier for me to get a simple web application thrown together with Racket, so that's at least what I'll be doing for the time being.

My experience with Racket has been similar: not many resources on people actually using it to solve real problems, not many libraries; but for doing a really simple CRUD web app that talks to Postgres, it wasn't too bad to get working. The community is really great, maybe as a testament to its size, but I've been impressed by how helpful they are.

Deciding to use Racket over Clojure was a tough decision. Ultimately it came down to the fact that there was less cognitive load for me in how Racket worked when I didn't also have any of the Java infrastructure underneath. I think one of Clojure's greatest strengths is that it gives you all the interoperability with the Java ecosystem (which I think is one reason for it's adoption); but I've never programmed in Java, so all of that familiarity isn't present for me; it just seems like an albatross. Even all the tooling around builds and deployment seemed like a lot to get acclimated to, although I'm sure if I had just gone ahead and used Clojure, I'd have figured all that stuff out.

I'm envious of the fact that a lot of Clojure's libraries seem to be created by people solving concrete problems, and in general I like the pragmatism of that community. Maybe eventually I'll move from Racket to Clojure, but I haven't yet tried to do anything in Racket that makes me regret having chosen it.

I always liked the idea of declarative programming, it felt very natural when I first learned about it. That being said, I didn't have much use for Prolog after finishing that class. (I wrote one fairly small application at my first job, but really nothing else).

I think that if you're interested by any of the recent developments around the Kanrens (or Core.Logic if you're a Clojure programmer), you'll find yourself better served by at least having a passing familiarity with Prolog.

I also find that SQL feels to me quite a bit like Prolog (you have to sort of squint), and I find myself liking writing SQL way more than you're apparently supposed to from how much people complain about it online. That might have nothing to do with having learned Prolog, maybe my brain is just wired wrong.

It is a little disconcerting to wonder that if the same case happened today, would it result in a katamari of charges meant to steamroll RTM?