CEO Friday: Why we don't hire .NET programmers - <AUTHOR> http://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire-net-programmers/ <comment><USER2> This strikes me as the rantings of a CEO who doesn't have any touch with the reality of development. Thanks for the offer, but I wouldn't want to work for you anyway ;)

In all seriousness, I just don't buy that .NET is an amateur language that prevents you from doing certain things. C# is a great, rapidly evolving language with a lot of functional programming features built in. On the other hand (as a developer who used C# for almost 4 years), I felt it gave me more freedom than most other environments. You can even drop down to pointer manipulation in performance critical areas when needed...

And with all the support for asynchronous programming, it makes it easy to write truly scalable web applications with a similar paradigm to Node.js.

And ASP.Net MVC is really nice... if I weren't developing on a Mac and in love with Heroku, I'd probably be using it over Ruby on Rails.

tl;dr; - your rant is only applicable if you are only talking about VBA developers. Modern C# on .NET with ASP.NET MVC is a pretty nice environment.

<comment><USER3> .NET is a pretty good implementation of a Better Java. It doesn't even suffer from some of the cultural problems of Java. (FooDelegatorHandleFactorySingleton...)

It _is_ a thoroughly corporate ecosystem, though. The vast majority of .NET programmers are work-a-day IT department developers. There is a lot of deference to MS on tools, language features, and libraries. MS developers will tend to wait for MS to incorporate something into the official platform rather than creating open-source projects to fill the same need. (eg. ASP.NET MVC) Even Java is better in this regard. It's hard to imagine something like Clojure emerging from the .NET community.

<comment><USER4> From <http://en.wikipedia.org/wiki/Rich_Hickey> \--

"Before Clojure, [Rich Hickey] developed dotLisp, a similar project based on the .NET platform."

Thus it looks like Rich Hickey was in fact a .NET developer at some point, and so Clojure did, in a way, emerge from the .NET community.

<comment><USER3> Interesting. I'd never heard of dotLisp. I'd love to know why he decided to move to the JVM.

</comment></comment></comment></comment><comment><USER5> I wish the author of this piece the very best with his squirrel restaurant franchise.

Seriously, what the hell is this guy going on about? The fact that large companies that create huge ecosystems also create cookie-cutter ways of doing things? And this is bad?

I've coded in just about everything out there except Haskell and Lisp. I've worked with heavy web-centric systems, distributed systems, P2P systems, and so on. I've written drivers, shell extensions, and rules-based database applications. And yes, it's true, I'm moving more to linux and F# on mono lately. But that's because of licensing and scaling issues, not because the .NET stack is somehow defective. In fact, if .NET were a liability, I would very quickly jump into something else. But it's not.

It's also true that there are a LOT of .NET developers who understand the cookie-cutter approach and can't go outside a very small comfort zone. But that's a product of being the world-wide standard, not a product of something gone wrong. When you own the game, hundreds of thousands of folks are going to go through 6-week "learn .NET!" courses and come out the other end button- pushers. If anything, those guys are a sign of a mature market, which is a good thing.

And what's this about .NET being a language? He acts like this entire system is similar to what? Javascript? .NET is a platform which runs dozens of languages with hundreds of thousands of easily pluggable libraries. If you're coding C++ in .NET writing unmanaged code you're doing something completely different from some guy dragging and dropping controls on a web page in VB.NET

This article shows the worst thing about all of us as programmers: we tend to run on assuming that we are experts in areas where we have the slimmest idea of what the hell we are actually talking about.

In fact, I feel this article is so bad that it has to be a joke: a poke with a sharp stick just to incite a lot of invective comments, like this one. Fricking linkbait. Bah.

<comment><USER6> I don't think its a joke, I think the CEO was genuinely trying to share that he had seen a lot of correlation between folks who programmed in .NET and people who weren't a good fit for his company.

I get similar negative vibe when I talk to people who don't use data structures (seriously I interviewed a guy who wrote a frickin' file system that was linear arrays, all the way down)

But it doesn't mean there aren't jobs that aren't a great fit for those folks, and this is where I think a lot of these discussions go off the rails (if you will forgive the pun).

If I am a programmer who loves .NET, and I read this, I can choose to take it in a couple of ways, I can be offended that this guy has just hugely disrespected me and all my .NET lovin' friends, or I can be glad to know that I don't need to bother myself talking to any of his recruiters that are scouring the globe. As I tried early and often to drill into my kids, you can't control what people say but you can control how you choose to feel about it.

"This article shows the worst thing about all of us as programmers: we tend to run on assuming that we are experts in areas where we have the slimmest idea of what the hell we are actually talking about." -- I think what you were trying to say here (but don't let me put words in your mouth) is that it is a mistake for programmer's to take what they know about themselves and to generalize it to everyone else indiscriminately. I would be happy to interview .NET programmers if they were willing to try other methodologies and languages. However I will relate that I have met people who have found God's Own Language (and it varies from person to person which one it is) and refuse to try any other language, or any other development methodology. If that isn't compatible with mine then we both should know that it won't work well.

The author gives a good description of the kind of people he would like to work with, that is valuable because in reading it you can get a feel for whether or not you would like to work with him. So its a win - win.

<comment><USER5> In your reply, I think you touch on an interesting aspect of this: why did it push so many buttons?

I really think it has very little to do with .NET -- I can take .NET or leave it, depending on the nature of my needs.

I think it has much more to do with the smart-ass feeling you get reading it, combined with the fact that, if you're any good at all in the .NET universe, _you know better_.

That made me think of all the times I've spoken to developers when they just _knew_ that such-and-such was true. And it wasn't. That same snarky attitude, that same over-generalizing, that same use of silliness to try to mask the predjudice.

I wouldn't throw out working with this clown. Who knows? Might be fun. But the attitude is worthy of comment, and, since I have been known to be this way myself, I feel like I can honestly jump in.

But really, who this guy wants or doesn't want, or what his opinions are don't matter that much. The interesting question would be how he deals with realizing he doesn't know so much. That's true for anybody.

</comment></comment></comment><comment><USER7> Great assertions. How about some evidence or examples?

.NET was created to be as different as possible from everything else out there? Show me at least one example. Further, show that it was deliberately done in order to be different.

Backslashes in path names? What does this have to do with .NET?

Left-handed coordinate system in DirectX? What does this have to do with .NET?

A dozen complex files before you even write a line of code? When I start a new .NET project (desktop), I get an XML and a basically-XML file that are so straight-forward that I regularly modify them in a plain text editor, and I've never even read the documentation on them.

Allergic to open-source licensing? I use at least a half dozen open source .NET projects on a daily basis.

Every day with .NET takes two days to unlearn? The author is just throwing out random numbers and ideas at this point.

The author comes across as having nothing but preconceived notions of .NET. I'm with the others. I wouldn't want to work for you... or even with you.

</comment><comment><USER8> I'm really not sure where to begin with my criticism of this article. Perhaps the McDonalds kitchen straw man. Or maybe the outright fabrications like:

"Big things, like obscuring the networking stack under so many countless layers of abstraction that it's virtually impossible to even imagine what bytes are actually going over the wire."

The only actual examples of "incompatibilities" that weren't lies were trivialities -- who cares if DirectX is left handed or right handed? Flipping your Z axis is trivial.

As someone who has extensively used both .NET and other platforms (C++, Java, etc.), this article strikes me as the naive views of someone who hasn't learned enough .NET to form a cogent opinion.

</comment><comment><USER9> Wow I hope this guy is just trolling. I haven't done much C# programming myself but the best coder I know built a HFT platform on .NET that made millions of dollars.

If this CEO wouldn't hire that guy because he's a ".NET programmer" then he has more important issues to deal with than his technology stack.

Also, his definition of a .NET programmer is hopelessly out of of date:

 _Programming with .NET is like cooking in a McDonalds kitchen. It is full of amazing tools that automate absolutely everything. Just press the right button and follow the beeping lights, and you can churn out flawless 1.6 oz burgers faster than anybody else on the planet._

Ummmm no. You're not describing the .NET platform. What you're describing is the old VB6 winforms-style or MS-ACCESS-style coding that was popular 5-10 years ago. The .NET platform has moved much much further than that in a short period of time.

</comment><comment><USER10> I realize this is just linkbait, but I'll bite.

I probably wouldn't want to work for such a narrow-minded person and I am not a .NET coder (may I never write Enterprisey code again!)

I realize he's probably just trying to use an imperfect filter to narrow the field of candidates but a lot of his criticisms extend to any framework, whether we're talking about Swing or RoR. Every tool you choose will limit you in some way. Oh well.

</comment><comment><USER11> Wow, this is the most personally insulting article I've ever read on HN. I've been programming since I was 8, worked at a successful startup (that used .NET exclusively), and do most of my pet projects on the MS stack.

I can't agree with him on any of his examples on why .NET is a bad platform. Backslashes and coordinates systems are trivial. I can't imagine any point for any startup where it's necessary to know the bytes going over the wire when dealing with networking. Code generation is an incredible time saver, and can easily be deleted if the generated code is unnecessary. Expensive servers have nothing to do with quality of code. I've never heard of a .NET developer allergic to open source, not to mention that also has very little bearing on quality of code.

I would propose that the platform is a tool, and a developer who can only use that one tool is limited. But it's totally ridiculous to discriminate against someone for knowing how to use the tool and having experience with it.

<comment><USER12> hes wrong about the "bytes over the wire" bit anyhow, it's pretty straightforward actually

</comment></comment><comment><USER13> While the McDonalds kitchen analogy is _kinda_ applicable, the theory of malicious lock-in is just plain silly.

Did it ever occur to you that just maybe Microsoft's customers are big corporations that routinely employ the programmer equivalent of french fry managers? And maybe, just maybe, Microsoft's products are highly successful at achieving the benevolent goal of engineering a product for their target audience?

As a former hard-core .NET developer and Microsoft employee -- who hasn't run a Windows box at home since nearly two years before quitting Microsoft -- I agree that most .NET developers are kinda lost in a Microsoft-crafted echo- chamber la-la land. But I don't agree that it's got anything to do with nefarious intentions, rather it's got to do with social dynamics and product/market fit.

</comment><comment><USER14> This article deserves to be slammed, and it's been well slammed, but there's a nugget of wisdom inside it:

Once you've exhausted your friend-of-a-friend type referral hiring, you need some way of turning thousands of resumes into tens of resumes for interviewing.

And no matter what filter you use, there are lots of examples of good candidates who fail it. The canonical example is GPA. The ratio of good programmers to poor programmers is higher in those with high GPA's (IMO), but there are tons of good programmers who flunked out of college.

There are lots of crappy .NET programmers out there, so filtering out .NET programmers will discard a lot of chaff. There'll still be wheat in the chaff, but you've got to get a shortlist somehow.

An even better filter might be to filter out anybody who calls .NET a language. Would that mean they have to fire the CEO too?

</comment><comment><USER15> > They write everything from assembly to jQuery, on PCs to mobile phones, > doing hard core computer graphics to high level social networking. They've > tried everything. Everything, that is, but .NET.

I've written everything from assembly to jQuery and written software in C++ for mobile phones. I'm not a fan of either computer graphics or social networking but I've written a ray-tracer and built a few popular websites. When I'm not working in other technologies (which is much of my day job) I also dabble in .Net. Why? Because it's an absolutely fantastic platform for getting stuff done in Windows.

I'm working on a little hobby project right now in .Net that interfaces with a piece of embedded hardware. .Net has been crazy effective for it: low-level bit twiddling is a breeze without the programmer overhead of C/C++ (don't even bother trying it in Java). I even made sure it's possible to port it to Mono for Linux users. And those tools that "make 1.6oz burgers"; I'm using those. The project also requires a whole bunch of boring CRUD work and I auto- generated at least half that work away. Sometimes you don't need 1.7oz burgers so why waste a lot of time and effort replicating that capability for nothing?

I think you'd be remiss to hire someone who _only_ knows a single technology, whether that be .Net, Java, or PHP. But I don't think .Net is some kind of poison for the mind.

<comment><USER16> Moreover, if you _did_ need 1.7oz burgers (Jesus, what a horrendous analogy), the only thing potentially standing in your way would be your own ignorance of the framework.

Sort of like what's standing between this company and some very talented developers.

</comment></comment><comment><USER17> I honestly would never work for this guy. I have a C, Python, Java, Ruby background (as in what I've used in past jobs), and I'm working with .Net currently even though I'm a Ruby fan. I find C# and ASP MVC, pretty freaking good, even though I'm a Windows hater. Close minded people like this dude don't deserve good programming talent at all.

I might not be one of the best programers ever (I'm probably not!), but even if I was I'd send the same message to this guy: "I play almost every stringed instrument from the violin to the piano. I can juggle up to 5 objects with ease. I know a quite a few magic tricks. I'm freaking special and I will never work for a narrow minded person such as yourself. Even if you pay me a quadrillion nigerian dollars."

</comment><comment><USER12> i applied for a job with expensify about 3 months ago. the interviewer asked in what language i wrote a web app from my portfolio. i said c#. he said, and i quote "you can make websites in c#?" he literally had never heard of asp.net. yet is ragging on .net in this blog post.

their office was just 1 room, with 3 guys sitting at a single table. they kept offering me a beer. i guess it was to seem hip, seeing there's no real reason to have a beer during a job interview.

another funny thing from applying is in the coding test they show you how to connect to their api using javascript, but it would never work because of cross domain restrictions. they probably have only tried it over localhost ;p

i wound up not getting the job because i used the kohana mvc framework in the coding test and they 'couldnt understand my code.' i think in all i wrote less than 150 lines of clear, commented code, but they dismissed it outright because i used these things called classes. im sort of glad i didnt get the job, because i got a job paying literally double their offering salary the next day.

</comment><comment><USER18> "keeping the programmer far away from the details such that they're wholly and utterly dependent on Microsoft's truly amazing suite of programming tools to do all the thinking for them."

Kind of the whole point of frameworks. Including jQuery which they're using.

</comment><comment><USER19> "But choosing .NET is a choice, and whenever anybody does it, I can't help but ask "why?""

Because in certain pockets of the country 90%+ of the jobs are in .NET.

"See, Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there"

? It's almost exactly like java.

<comment><USER20> I was pretty much a 100% .NET guy before joining Amazon in January. Without reading a book, I was immediately able to start writing Java at Amazon because of how similar it is to C#.

</comment></comment><comment><USER21> Follow up article: Why I would never hire a CEO as clueless as this guy...

</comment><comment><USER22> Actually, I'm surprised no one else touched on this part yet:

 _See, experience is cheap. All it takes is time. Skill is harder, but really only requires hard work — a lot of people can get that. But attitude. You either have it, or you don't._

So, what he's saying is, experience is cheap, hard work is cheap (seriously???), but attitude, now _that's_ worth something? I think I see the point about his programmers beating up everyone else's.

I say, let him have all the attitude he can choke on. I'll settle for the hard work and experience, thankuveddymuch!

</comment><comment><USER23> I'm going to keep my response brief: 1) .NET is not a language, and calling it such is just silly. 2) I've built everything from insanely high-performance emulators (IronBabel) to kernels (Renraku) to computer vision applications (not announced yet) using .NET; all of these are "1.7oz burgers", and all of them were performant, flexible, and easy to build.

Troll, troll, troll...

</comment><comment><USER24> This should be a giant red flag to anyone who is considering working at Expensify (as long as this CEO is around). I see this "we're hiring the best developers in the world" mentality from time to time at small startups and honestly it borders on delusional. You write software which makes expense reports and you've made some money. You aren't working on anything that would interest one of the best developers in the world and I seriously doubt you're prepared to pay what it takes to employ one.

We all know that working in .Net means about as much as a carpenter using a saw. Drawing conclusions from it is just another example of very poor reasoning skills.

In the end this is just linkbait and I hope the CEO apologizes publicly for making a poor decision in publishing it.

</comment><comment><USER25> Why does a company that creates expense reports need "the best programmers in the world"?

<comment><USER22> Apparently, so they can beat up everyone else's programmers.

Exactly what that contributes to programming _or_ expense reports is anyone's guess.

</comment></comment><comment><USER26> This article probably does more to hurt expensify than it says anything about .NET development. I'd seriously hope that any CEO I work with would come talk to a dev before writing something like this.

</comment><comment><USER27> I have a hard time taking this seriously beyond the ".NET is a language" statements. I don't think most of his statements really apply to C#, but they certainly don't apply to F#.

This is cargo cult management at its finest. The author is clearly one step above knowing absolutely nothing about this at all. It reads like he got burned by a bad hire and now everyone who shares traits in common with that person is also a bad hire.

</comment><comment><USER28> I feel like he is both right and wrong, and for all the wrong reasons.

His hunch is that for the most part .Net developers are bad, and by and large I agree with that. Because .Net is used in a lot of Enterprisey places, and it's so easy to get a job in it right out of school you find a lot of just horrible code, and broken mindsets about programming _in general_. All of the idiocy I find in .Net is usually just someone who wouldn't know how to solve their problem in any other programming language either.

But he's wrong that that is a direct result of .Net in general. I feel you could swap out .Net for Rails: "oh all you know is how to run `rails g scaffold` therefore you're not worth my time". That is _wrong_. Like Rails, .Net provides abstractions over _mechanics_ , but you will be a happier, more confident programmer when you can understand the intent of those abstractions, and maybe even take a theoretical stab at how you would implement it. That goes for any platform you develop on.

Personally I think I've grown a lot as a developer in general over the past few years using .Net professionally. Despite the stigma I've met a lot of smart developers, and C# has helped me hone how I like to think about and solve problems in general. I'm sure it helps that I do a healthy amount of other hacking outside of it all to give me perspective, but I certainly don't feel stupider for being exposed to things like LINQ, which helped my grok Monads and embrace more Composition style programming in a fuller way.

</comment><comment><USER29> The Author of this article obviously has some misconceptions about .NET, and has probably had some bad experiences with enterprise developers. I've worked at two very successful startups that have used .NET for high traffic web development (and no, I'm not talking about MySpace). Some sites dealing with 5million + page views a day, and some of our .NET services would handle 5billion+ requests a month. It is great for large teams, the CLR is well optimized, and C# is a beautiful language in itself (although the platform supports many scripting and functional languages). I believe what the Author really means, is stay away from seasoned Asp.net web form developers who have never strayed from .NET and have no experience in an agile environment... if you are looking to hire for your startup. I've been hiring quite a few developers recently for the once startup I'm currently working at, and when recruiting I make sure to never start discriminating based on the language that an engineer develops in. I've hired programmers who were mainly developing in C++, Java, Python, PHP, and many other languages. If they are Jr, you just need to be super smart problem solver with decent programming skills. If you are Sr./Lead, you need high traffic experience, along with being well skilled with a strongly typed language, among other requirements. These kind of candidates have done extremely well, and enjoy the .NET platform that we mainly develop in. And me personally, I prefer .NET, but if the team and product is great, I would be happy to work with Ruby, Python, .NET, Java, etc... I think my PHP days are over though=)

</comment><comment><USER30> I dislike .Net. I enjoy perl/python more.

I work on a .Net app now. It has tons of complexity that any other app has, if anything more complexity because of the requirements put around you.

Perl and Python are like poetry. You can do whatever you want.

.Net is like a haiku. You have limitations, but often times those very limitations are what allow you to focus on the true meaning of the code, and what it should be doing.

I think there is some level of truth to the article, but it's overstating it, which is clear.

"Why we don't hire .Net programmers" turns into ".NET on your resume isn't an instant showstopper. " turns into "If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it's there."

So ask why it's there. Just like ask why Python is there, or ask why Perl is there.

So really, what you're saying is, it's important to ask why they programmer in the particular languages they choose, and use that information to determine why they do what they do. Prefer people who do it like a hobby as opposed to those that do it as a job.

Great. But what does that have to do with .Net? Oh yeah, you just don't like it.

That's fine, I don't either but I don't immediately think a programmer is bad because they use .Net.

I think that they are bad because they use PHP.

</comment><comment><USER31> What. A. Moron. Talk about a mega-facepalm! How is bigotry supposed to entice people to your firm?

</comment><comment><USER32> Apparently, this guy skipped "Intro to the Theory of Computation" class on the day they covered the concept of Turing completeness. The notion that there is any program that can be written in any other Turing complete language that cannot also be written in one of the Turing complete .NET languages is provably wrong. End of story.

</comment><comment><USER33> Excuse me while I go and remove Expensify...

I started programming out with MSC 5.1-> Borland C++ 5.0-> MS C++-> MS C# and have never looked back.

It's elegant, powerful and gets out of your way when you need to deep dive.

I would suggest you take another look at it and don't confuse all .NET developers with VBA script kiddies.

</comment><comment><USER34> I'd say this is clearly written by someone who hasn't worked with .NET.

</comment><comment><USER35> That's fine I guess but you will miss out on good people even though you don't think you will. The reasoning here suggests that .Net doesn't require you to do anything outside of controls and drag and drop which isn't in my experience very true at all. I've been able to some the occasional control for what I do but it's never anything fancy at all.

What platform are you using that doesn't abstract the networking stack? Network programming in C isn't that _that_ different than in C#. The same basic concept of I/O is there and the APIs basically work the same way.

Also .Net isn't a language. I guess you are referring to C#.

</comment><comment><USER36> I agree with previous posts, I don't know any programmer who can 'choose' the language. Usually it's the boss who selects the language the whole team uses.

And then it's a job to pay bills and maybe child support.

But, clearly it's just his opinion, as he makes references to backslashes or forward slashes. It's an uninformed opinion?

In certain circles, we call this trolling. He knows what kind of response he will get. He's attacking .NET programmers. Let's see how they respond, etc.

</comment><comment><USER37> Wow. Circa 1980's "Micro$oft" rant from a 2011 CEO. No wonder they're having a hard time hiring.

I think the real moral of this story is: (1) avoid technology religion and it's practitioners, (2) if you're cooking steaks on a gas grill and you see your CTO warming up a dead squirrel over a book of matches, find another job.

</comment><comment><USER38> Ok I am going to defend the guy somewhat. He clealy can't be talking about C# or any other CLR languages themselves, that would be just plain dumb and I'm going to give him the benefit of the doubt.

I guess he is talking about the various Microsoft supplied frameworks. Within say, Silverlight, it is easy to dip your toe in, get to something like databinding, and go off the rails, trying to bend silverlight to your will to do something that should be easy, and coming away with the impression that what you are doing is totally impossible within silverlight. Then you spend 20 minutes actually thinking instead of in a Microsoft hate fugue state and you see that it actually is easy if you don't fight the framework. So you are like "fuck you .net I want to do it my way!"

But that is the nature of frameworks, not endemic to .net.

</comment><comment><USER39> He should consider switching to a digital tabloid as a writer. He might not be great at recruiting or how to identify great programmers but he seems to have a gift for getting his trolling just right.

Some startup here should take him up on the developer vs developer challenge.

</comment><comment><USER40> I am a .NET developer, and I am trying to hire excellent, well-rounded .NET developers (hint), and I can tell you that it is non-trivial, specifically because many .NET developers are not particularly well-rounded, nor have the vast majority of them much experience outside the .NET ecosystem, nor more than a basic understanding of the technologies which underly the very powerful abstractions MS has built on top of them.

So I can certainly sympathize that someone who is building something that requires more fundamental knowledge might find .NET to be an effective bunny- filter.

I did stop reading the article when I got to "I'm sure .NET is a dandy language."

</comment><comment><USER41> Stop

Feeding

The

Troll

</comment><comment><USER42> I've read much bullshit over the years, but this tops it all. I personally have wrote code in more than a dozen languages and would still prefer .net any-day. You can write almost anything with any language. You can develop web.apps in assembly language if you insist, but it'll take 10 times more time and money than doing it with .net, php, ror or other modern languages and you'll have 10 times more bugs to deal with. This attitude is plain stupid arrogance. If it were a company doing embedded systems for the defense industry I'd understand, but from a company that deals with invoices... they must be kidding!

</comment><comment><USER43> First of all, what flamebait but I'll bite

"Even worse, every day spent learning a Microsoft kitchen takes TWO days to unlearn, meaning once you get a reasonable way down the .NET career path, there is almost no going back."

That's not true in my experience.

I work at small, profitable company using Linux / Python / Amazon Web Services, we have some fantastic developers who came from a pure .NET background - some worked at Microsoft.

They transitioned successfully because of their attitude. If you commit yourself to learning the tools and not fighting them, you can make the transition in a couple months - no problem.

</comment><comment><USER44> You're full of it. In what way does .NET hamper you? Why can't you make a "1.7oz burger"? It's a full-blown programming environment - the limit to what you build is what your mind can conceive.

</comment><comment><USER45> Is this guy qualified to talk about hiring programmers? Based on all the little errors in detail in his blog, I assume he's the non-technical co- founder of his company, not the technical guy.

</comment><comment><USER46> I think this is just a rant by some CEO who hasn't had much real world experience. Sadly, it doesn't give any examples of why .NET is worse.

I would question why he REALLY doesn't like .NET. This article to me it like a person stuck inside a box with only peep hole towards the java stack. When he realizes that there is more to life and academics than just java or objective C, then maybe we will talk.

Can we please not keep up voting this rant that I didn't learn anything from except for the comments posted here on HN?

</comment><comment><USER47> It's great that he posted this.

Most of us may not agree with his philosophy, and have questions about his basic technical and leadership competencies. But right or wrong, he's being very transparent about their hiring and development philosophies.

This is a good thing. It helps his company attract the kind of person that will work well in that environment, and gives clear warning to the rest of us that this is not the place for us, and that we are better of not wasting our time seeking a career there.

</comment><comment><USER48> Although I also dislike .NET, it seems the primary complaint here about .NET is that it abstracts programmers too much away from the bare metal. But doesn't that apply equally to non-MS languages like Python and Ruby? In fact, isn't abstraction in general a good thing?

The author also bewails .NET's lack of configurability. But what is it about C# that instantly defiles any programmer who touches it, that doesn't also apply to, say, Java?

</comment><comment><USER49> This is a really bad take on Microsoft technology lol.

I've wrapped a lot of my stuff around .NET technology and is very happy with it. You can definitely save a lot of time and launch your product fast to draw attracting with .NET. In a B2C business, you need to bring your product to the market as fast as possible before you can present, the end user doesn't care what you are built based on. Just take a look at match.com..

</comment><comment><USER50> Just because he managed to attain the title of CEO, doesn't mean all he speaks would be gospel. Having a closed mindset is, more often than not, detrimental to one's ventures.

</comment><comment><USER51> wow that sounds really arrogant.

Skills shouldn't be rated by the IDE developer use.

Not everbody wants to be that kind of geek, that's hacking into a console all day long, rather than using an good IDE.

Rate people by their abilitity to handle those programming languages (e.g. readability, cleanness, layout, speed and so on).

If you don't need C# developers fine, but don't say people should be aware of C# programmers.

By the way, I worked with really good developers, which also programmed in C#, many of them were real experts and absolutly passionated.

</comment><comment><USER52> I think every developer who reads the article should link to it. That way when any future employee googles them they will see what an ass they would be working for.

</comment><comment><USER53> If you ever want to work in a startup, avoid .NET. It does you no favors.

\</comment><comment></comment><comment></comment><comment>--

Got to love how he extrapolates his own little idiosyncrasy to _every_ startup.

</comment><comment><USER54> Maybe the difficulty in hiring good people is because the CEO is clueless?

Any hacker with half a brain would stay far, far away from this company.

</comment><comment><USER55> it's like saying real singers, the ones with true talent, the ones that have sung since they were young and not just voice trained year after year are rare. Except opera singers - they are truly hacks without the range or talent to do anything else but belt out high pitched drivel in god awful costumes.

</comment><comment><USER56> there's no (well, hardly any) such thing as bad languages, just bad programmers, managers and business people.

this stuff honestly makes me sad for this industry. There are probably 100's of programmers that will now never get to work in the start up world because they list c#/.net etc on there resumes.

</comment><comment><USER57> I should probably be ashamed, but I stopped reading after he claimed that .NET is a language.

<comment><USER58> Actually, you shouldn't. I was getting fumed by the end of his first paragraph where he bragged about his decent programmers being able to fence and do knife play. If he's looking for mercenaries* who can code I should email him! Anyway, I read on and he made several contradictions to his own points. I can't take him seriously now.

*not a mercenary but I'm a runner who flies planes and is a good shot with a Glock, but I sure as hell wouldn't put that on my resume

</comment></comment><comment><USER59> I think it's unfortunate an article like this even gets up-votes on Hacker News.

</comment><comment><USER60> "Now let me clarify - .NET is a dandy language"

Why I don't listen to CEOs.

</comment><comment><USER61> Is this site becoming Slashdot? Visual Studio does have some features that can make you lazy I suppose. ASP.NET web forms does suck, but ASP.NET MVC is good. Is Java supposed to be better than .NET?

</comment><comment><USER62> This is nice linkbait. I will add to my swipefile.

</comment><comment><USER63> "Kelso, did you ever FINISH Lord of the Flies ?"

</comment><comment> oleg-d this is so arrogant..

</comment><comment><USER64> I'll bite...

.Net as a framework is designed to get stuff done so you can go home and play with your kids, not pander to the whims of a CEO with his head up his behind.

According to him, I shall have to "unlearn" all those ever so bad practices and technologies such as ORM/DDD (NHibernate), DI (Autofac), SoC (MVC), SOLID, Messaging (NServiceBus), SOA (WCF)...

I will give him one thing; at least 75%+ of the "developers" on the market in the UK couldn't put a web page together without the ASP.Net webforms designer but the same is true with all technologies otherwise we wouldn't have dreamweaver and the likes.

The guy is a total muppet.

</comment><comment><USER65> Fuck this guy, and everything about him. I can program in Assembly, C, C++, Java, and Lisp fairly competently, but frankly I like C# because I can see results almost as fast as I can imagine them. It has an amazing tool set. Does it really make those other programmers better than me because they prefer needless complexity?

If I need a 1.7oz hamburger, I'll use one of those other tools. But 99% of the time 1.6oz is just fine.

</comment><comment><USER66> McDonald's has lambdas? Who knew.</comment>


The SQL Guru - The Daily WTF - <AUTHOR> http://thedailywtf.com/Articles/The-SQL-Guru.aspx <comment><USER2> Lessons here are about a) change control b) backups and c) never trust anyone who calls themselves a "guru".</comment>


Wi-Fi and Neighborhood Conflicts: An Algorithm to Keep the Peace - <AUTHOR> http://actu.epfl.ch/news/wi-fi-and-neighborhood-conflicts-an-algorithm-to-k/

<comment><USER2> These sorts of technologies are really interesting, and will play a big part in getting the most out of limited wireless spectrum. But the big picture problem is that we're shoe-horning all this incredibly useful technology into the ghetto that is ISM band. We need more unlicensed spectrum, and we need better rules for that unlicensed spectrum that prohibit anti-social behavior: [http://esd.mit.edu/WPS/esd-wp-2006-01.pdf](http://esd.mit.edu/WPS/esd- wp-2006-01.pdf).

</comment><comment><AUTHOR> Link to technical paper: [http://infoscience.epfl.ch/record/186014/files/saw- infocom13...](http://infoscience.epfl.ch/record/186014/files/saw- infocom13.pdf)

</comment><comment><USER3> Hmm, I have not read his paper, but based on the article's mention of "divided into 13 channels" this is clearly speaking of the 2.4Ghz spectrum. Rather than try to distribute that evenly, you are FAR better off upgrading your AP and switching to a 5Ghz channel. First, there are far more potential channels in 5Ghz. Second, they are wider bandwidth (40Mhz, 80Mhz if 80211ac). And third, 5Ghz does not propagate through walls as well (a _feature_ when you have neighbors also using the spectrum).

My other thoughts: if he is using 8 channels instead of the standard 3 (1,6,11) then there will be some overlap; 80211 devices tends to better handle in-channel interference. [http://en.wikipedia.org/wiki/List_of_WLAN_channels](http://en.wikipedia.org/wiki/List_of_WLAN_channels)

<comment><USER4> I switched to 5g last year, but all of my neighbours have caught up. Worse still — we all have legacy networks on the 2.4ghz spectrum so that our older devices can access the Internet. There are probably two dozen networks accessible from my couch. It's crazy in apartment buildings.

I would suggest that it should become part of our condo fees / building management, but I have little confidence in our board.

<comment><USER5> Not to mention there are many devices that still don't support 5ghz (a notable/annoying example being Chromecasts). Switching to 5ghz is not a solution to the problem outlined in this paper, it's a bandaid.

</comment></comment></comment><comment><USER6> I'm glad someone at least seems to be addressing congestion. Every 802.11 standard seems to have hopped on the "multiple bandwidth by 2x" bandwagon, which is great if I live in a single family house with tons of space.

I don't, I live in a city, in an apartment building, surrounded by apartment buildings. I can frequently see 30+ networks. I'm sure there are wireless phones and other devices crowding the spectrum as well. Give me more channels, or better ways to share spectrum, anything other than dividing the number of usable channels with every update.

<comment><USER7> > Every 802.11 standard seems to have hopped on the "multiple bandwidth by 2x" > bandwagon, [...] anything other than dividing the number of usable channels > with every update.

It might use 2x the bandwidth, but it will use it for half the time for the same amount of data, so it all evens out (almost; there's an unused "border" between channels, so 2x the bandwidth is a bit more than 2x faster, and it will use a bit less than half the time).

And the 802.11ac standard has a way to better share the wide channels and the narrow channels; see the "Dynamic Bandwidth Operation" chapter of the "802.11ac: A Survival Guide" book at [http://chimera.labs.oreilly.com/books/1234000001739/ch03.htm...](http://chimera.labs.oreilly.com/books/1234000001739/ch03.html#section- mac-dynbw)

</comment></comment><comment><USER8> I actually had a similar idea recently but assumed it must have already been part of the protocol. Obviously it wasn't, and truly good ideas are never unique, so kudos to this guy for doing the work and coming up with a functional algorithm.

One question I have is how this would perform in an incredibly congested area like an apartment building. The author only modeled out 2-way conflict; I have no idea how this algorithm would react if placed in a situation with 15 competing Wi-Fi access points.

Overall a good, nerdy read - this is the kind of shit I keep coming to HN for.

<comment><USER9> I'm the main inventor. Thanks a lot for the positive feedback!

You are actually right, similar ideas have already been proposed before. The main novelty here is that the algorithm adapts not only the channel (center frequency), but also the bandwidth (i.e., the actual amount of spectrum that is consumed).

Adapting the bandwidth gives a precious additional degree of freedom; in particular, in a case with many competing WLANs, the algorithm would typically tend to reduce the bandwidth consumed by each WLAN (assuming the interfering WLANs are not idle and actually sending traffic). Reducing the bandwidth potentially reduces the available capacity (if you were alone), but it's still much more efficient than letting Wi-Fi use the time domain to avoid interference, so it results in increased throughput compared to current situations.

It turns out that adapting the bandwidth is becoming a necessity, because newer versions of Wi-Fi consume more and more bandwidth. This is better if you are alone, but may be harmful if you have many neighbors.

<comment><USER7> > in a case with many competing WLANs, the algorithm would typically tend to > reduce the bandwidth consumed by each WLAN

Wouldn't that use more battery, since for a narrower channel the radio would have to be kept on for longer to transmit (or receive) the same amount of data?

<comment><USER9> Usually, 802.11 devices don't turn off between transmissions, so this has no effect. In fact, it's actually the opposite; using a narrower channel requires a slower clock rate, which also significantly reduces power consumption of the wireless device.

</comment></comment></comment></comment><comment><USER10> Dynamic Frequency Selection and Transmit Power Control (part of 802.11h) is already a requirement for 5GHz in many countries: [http://en.wikipedia.org/wiki/Channel_allocation_schemes#DCA_...](http://en.wikipedia.org/wiki/Channel_allocation_schemes#DCA_and_DFS)

<comment><USER2> Kind of. DFS is about sharing the 5 GHz band with incumbent radar installations. Basically how it works is that you have to listen for radars using the channel, and if you hear one, you have to get off the channel within a certain number of milliseconds. But DFS systems don't switch channels in response to other Wi-Fi networks, nor do they switch channels in order to optimize aggregate bandwidth.

</comment></comment><comment><USER11> When I chose a channel for my router, there was a clear option labelled "auto". If this algorithm for channel selection is novel, what does "auto" do?

Also, kudos for the idea. This is a much needed feature in today's crowded condos.

<comment><USER12> Auto usually just means scan channels at boot time and pick one that seems good (presumably the least amount of traffic).

And on at least one SoC I worked with (Realtek) I swear the algorithm was "return 6".</comment></comment>


Win this auto race, get the stadium for a prize - <AUTHOR> https://www.argusleader.com/story/news/business-journal/2019/07/01/brennan-says-hell-prove-doubters-wrong-husets-speedway-race/1593964001/ <comment><AUTHOR> The racetrack is famous in the US midwest. If it goes off, the winner will be happy.

The second place finisher will be disapointed. (As Ricky Bobby says, "If you ain't first, you're last.")</comment>


This is why I don't believe in remote workers - <AUTHOR> http://kswizz.com/post/15538993641/chance-encounters

<comment><USER2> That really has nothing to do with remote workers. It's just about brainstorming ideas.

I agree that it's difficult to match the creativity that comes from a face to face meeting. It's by no means impossible. Living outside Silicon Valley has forced me to learn how to generate that creativity over the internet. I do get a different kind of excitement when brainstorming face to face, but I have been forced to brainstorm my best ideas over the phone or on Skype.

</comment><comment><USER3> It's always great to see people turn their (potentially quite narrow) personal experience into broad proclamations.

"I have never had a productive exchange via IRC, therefore it is not possible for anybody to do so!"

Meanwhile I have productive IRC, Skype and e-mail discussions all the time, both with colleagues at work and in the open source communities I participate in.

</comment><comment><USER4> Some kinds of work are much easier in person, like brainstorming and high- level product design. Many other kinds of work--the ones that take up the bulk of the time in my experience--are best done alone. This includes most of the hashing-out-the-details stuff like coding, graphic design, and copy-writing.

The most important thing is finding people independent enough to function remotely. There some also work to be done in breaking down social boundaries-- remote workers need to be willing to reach out immediately when they are stuck, have ideas, or need to talk something through. Many introverted people have trouble with this idea, especially at first.

</comment><comment><USER5> Creativity comes from A) within, B) sharing with others. Nothing says it has to be in person, within the same physical room... heck, even if there was a requirement for eye-to-eye contact, webcams (et al.) provide that. The tools are there. If the creative spark is now catching on, the problem must be elsewhere: not the right people, or mix of people (or simply not the right time.. people are not necessarily brilliant 100% of the time throughout their entire life)

</comment><comment><USER6> Different people communicate well in different ways. There's a tendency to think there's a right way to do these things. There isn't. You have to have a way for people to chat with each other informally that works for the real people on a real team, and a work environment and culture that encourage it. Whether that can be done remotely or not, or whether it actually works better remotely, depends on the specific people and the relational chemistry of the team.

</comment><comment><USER7> To me this then boils down to: Are the people in my organisation the ones that are most likely to make me say 'Wow!' or would it be better if my water cooler conversations happen at the local coffeeshop / meetup.

And I've got to say as the founder of a very small firm, I know what people in my org are doing, but wow are there a lot of talented people doing amazing things in Seattle.

</comment><comment><USER8> I work remotely and I'm in GotoMeeting all day. My other coworkers are on there too. All day. As far as I'm concerned, it feels like we're all working in the same office.

Email and chat? It doesn't have to be that way. I agree with Jobs that people have a natural desire to see and hear other people, and that that fosters creativity. You can still get that working remotely.

</comment><comment><USER9> This to me doesn't disqualify working remotely. One can still engage with peers, it does take a bit more effort. A great example of this is simply attending Meetups. Most of the time, however, working involves sitting down by yourself and getting stuff done, even when implementing that great idea that just came to you from talking to someone else during your lunch break.

</comment><comment><USER10> There are better ways of working remotely than email and chat. Always-on video screens and telepresence robots allow a good deal of spontaneity and bumping into people.

</comment><comment><USER11> >Creativity comes from spontaneous meetings, from random discussions.

Does Creativity have to be a collaborative process?

</comment><comment><USER12> probably true when we only had email and chat</comment>


Metapost programming language: Examples - <AUTHOR> http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.html

<comment><USER2> See also the metafun addition, which works well with ConTeXt, a TeX macro package.

metafun: [http://mirror.contextgarden.net/general/manuals/metafun-p.pd...](http://mirror.contextgarden.net/general/manuals/metafun-p.pdf)

ConTeXt: <http://wiki.contextgarden.net>

</comment><comment><USER3> Also see: <http://www.math.ubc.ca/~cass/graphics/manual/>

</comment><comment><USER3> It would be fun if someone wrote a metapost implementation on top of SVG.

<comment><USER4> It would indeed.

I think SVG is a great idea, in theory; however, I've found SVG creation tools to be uniformly disappointing. Your suggestion, if reasonably well executed, would definitely be a step in the right direction.</comment></comment>


JDK 9 modules voted down by EC - <AUTHOR> https://jcp.org/en/jsr/results?id=5959 <comment><USER3> This is unambiguously a good thing. Jigsaw didn't solve the toughest problems it had hoped to solve, and there are much less impactful ways to accomplish some of these goals. As it stood, Jigsaw broke tons of applications that did non-trivial things with class loaders, reflection or even circular deps. As a consequence, while Jigsaw (after significant effort) might not be disastrous for Java, it's pretty awful for most things that aren't Java that target the JVM, like Clojure. Meanwhile, significant incremental engineering benefits in JDK9 were being held back by this sweeping change; so now maybe we can just get a better JVM without breaking the world.

As it stood, Jigsaw required a ton of engineering effort internally and externally and severely broke the backwards compatibility that has made Java such a workhorse of the enterprise. All of that at very questionable benefit to the end user: still no module-level versioning of deps. That doesn't mean this effort is totally wasted: the oldest parts of the stdlib were due for a touch-up.

Lord knows that I have my differences with how Red Hat operates sometimes, but I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi or JBoss modules is reasonable. (FWIW: I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt- in.) That theory has little explanatory power: why are all of these other companies voting against?

Disclaimer: I have no stake in any of the voting parties, but I do write a lot of JVM-targeting software.

<comment><USER4> > I don't think suggesting their vote against Jigsaw is somehow a political > plot to benefit OSGi or JBoss modules is reasonable. (FWIW: I also don't > think OSGi's and JBoss' alternatives are great, but that's OK, because > they're opt-in.) That theory has little explanatory power: why are all of > these other companies voting against?

I think RedHat/IBM are opposing it because it isn't OSGi/JBoss (and whether that's for nefarious reasons or because they genuinely believe OSGi/JBoss are the Right Thing is beside the point), and most of the other opposition is following their lead.

I think OSGi/JBoss are failures in the market because they're hideously overengineered, and if Jigsaw is to succeed it should avoid solving most of the problems that OSGi/JBoss claim to. Rather it should solve the common case while being much simpler. The current proposal seemed like a pretty good effort to me.

<comment><USER5> Anyone who believes OSGi is good is either (a) deluded or (b) ignorant.

Having just implemented a plugin solution using it I can safely say that in the past 20+ years of software development it is the most awful technology I've ever seen. The complexity and over engineering is simply breath taking. It is worse than EJB 1.0, worse than the crazy abuses I have seen with Spring and DI, worse than than dark days of J2EE.

I have lost a lot of respect for Red Hat and IBM after this.

<comment><USER6> What has J2EE/Java EE been replaced with?

<comment><USER4> No single thing, rather it's been displaced by using specific targeted libraries instead of enormous frameworks.

<comment><USER6> Ah, thanks very much for your reply.

</comment></comment></comment></comment></comment></comment><comment><USER7> Hi all, I'm the EC representative for the London Java community (~6000 Java developers, have lots of global outreach programmes etc) - here's our more detailed post on why we voted "No". [https://londonjavacommunity.wordpress.com/2017/05/09/explana...](https://londonjavacommunity.wordpress.com/2017/05/09/explanation- of-our-no-vote-on-jsr-376-java-platform-module-system/) \- Happy to answer further questions although I've probably found this thread too late :-)

<comment><USER8> Thanks for the post (you're not too late at all). I do have a couple of questions if you don't mind:

"For our membership, interoperability with the Maven build ecosystem and the ability to build an alternative compiler implementation (i.e. Eclipse's ejc compiler) is paramount."

Do you believe that package manager interoperability (even if it is the de- facto one) is the responsibility of the JDK? Assuming not, do you believe that Maven would be unable to work with the module system as proposed? If so, why?

Also, and forgive me if I missed it discussed elsewhere, but what is hindering other JVM implementations with the current spec. If anything, I would think one could argue there are too many features for easy independent implementation as opposed to not enough.

Finally, do you believe those two issues warranted a no? If there were an option for "mostly-expecting-couple-of-future-features", would y'all have chosen that?

<comment><USER7> We believe that that the Java specification for a new module system does need to have an interoperability story with the package management system that Gradle/Maven provides. In particular, the module system needs to be able to bridge/utilise the packages provided by Maven Central (>1 Million IIRC) and allow the Java ecosystem to transition over time. A hard 'break' from the Maven Central world would have meant two separate Java's (a bit like Python 2/3), which for us meant a No vote. These issues are being ironed out, but they weren't at the time of the voting period, so we erred on the side of caution

There were concerns raised by the Eclipse JDT team (ecj authors) - <USER2> here: [http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-May/0...](http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-May/012524.html)

We think those issues will be resolved, but we'd prefer to see them resolved before voting yes. In particular:

The grammar for the module-info.java with its "restricted keywords" is highly problematic, since the language it defines is not processable by established compiler technology. Hacks are possible, but they are costly and prevent established error recovery techniques from working.

The JCP's mandate is to ensure that competing implementations can be built and at time of spec submission this was very unclear (better now).

<comment><USER9> Could you elaborate on "not processable by established compiler technology"? The module spec grammar _looks_ like a conventional programming language grammar and javac can apparently process it just fine. Is this an odd way of saying "it doesn't look like Java therefore it can't be integrated with a Java compiler"?

 _edit: seems there 's something about it here:[http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-May/0...](http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-May/012560.html*)

<comment><USER10> Fixed link: [http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-May/0...](http://mail.openjdk.java.net/pipermail/jigsaw- dev/2017-May/012560.html)

</comment></comment></comment></comment></comment><comment><USER11> Red Hat has voiced their concerns in the following document, linked in their comment: [https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical- deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns)

Found a follow up in this blog post: [https://blog.plan99.net/is-jigsaw-good- or-is-it-wack-ec634d3...](https://blog.plan99.net/is-jigsaw-good-or-is-it- wack-ec634d36dd6f)

Interesting to see Twitter voting No as well, with the comment " _Our main concern is that it is likely that this JSR will prove disruptive to Java developers, while ultimately not providing the benefits that would be expected of such a system_ ".

<comment><USER12> I opened the second link for the funny title, and its a worthy read.

>Jigsaw has had a multi-year development and feedback period in which the views of other module system creators have been led to substantial design changes again and again. Feedback has been taken from anyone who turned up, even Java nobodies like myself. So given how often Red Hat's feedback has affected the design of Jigsaw, it seems both petty and wrong to describe it as "cleanroom", implying it was developed in isolation from the outside world.

>I think we have to cut the Oracle team some slack. They're attempting to build a module system for the masses, which may entail not supporting out of the box every possible use case that has been put into OSGi or JBoss Modules over the years.

</comment></comment><comment><USER13> I realize that there are some actual technical questions here but I can't help but be fascinated by the politics of this.

Are IBM and RedHat just against Jigsaw because of commercial interests in JBoss Modules and OSGI? Do they actually care about the technical merits? How can Oracle get to this point in the process without more buy in from the community?

Also I never knew who was part of the EC. Interesting breakdown on who voted for or against.

Will Java 9 go out without Jigsaw? I imagine if they have already modularized the JDK then it's impossible to release Java 9 without Jigsaw.

<comment><USER3> Given the detail of the post RH put up, and the fact that many companies that aren't RH also voted against, I think the onus is on the claimant to demonstrate that politics are in fact involved. I disagree with a lot of what RH does, have no stake in any voting party, but unambiguously think Jigsaw can not go forward in its current state.

Releasing the JDK9 without Jigsaw enabled is not a major problem.

<comment><USER14> _" I think the onus is on the claimant to demonstrate that politics are in fact involved."_

When has there ever been a technical decision made on the technical merits?

It's always politics. Scratch that. It's _only_ politics.

Pieter Hintjens' telling of how RedHat spiked the process around AMQP shows that RedHat is no different from any other player. [http://hintjens.com/blog:125#toc15](http://hintjens.com/blog:125#toc15)

I had a brief flirtation with a standardization effort. Standards bodies are just another battlefield for belligerents. And I have no problem with that.

<comment><USER3> By that logic, literally anything Red Hat does is intrinsically bad. I did misspeak: I'll happily believe there is some politics, but that's not what I meant to say; the claim elsewhere is that it's purely or primarily politics.

I've already argued that simply reducing it to "it's politics" is not a reasonable argument unless you can also explain why the RH technical detail post is really just a bunch of politics and not technical arguments, and if you can explain why all of these organizations that don't own a module system _also_ voted against.

<comment><USER14> _" anything Red Hat does is intrinsically bad"_

Not at all. I'm saying that politics is normal and good. I _want_ RedHat, IBM, Oracle, etc to fight it out. Legally.

\--

Before replying, I took a step back, wondering what my position is. Here it is:

This modules effort feels like generics. JDK 1.5 adopted the least objectionable, and therefore least useful, design for generics. The rationalization was "backward compatibility", then and now. The correct answer was to retool the JVM and JDK as needed to do generics properly.

IMHO, Java has leaned too far towards backward compatibility. But what do I know? Java continues to do quite well, despite my objections.

<comment><USER15> re: feels like generics. Quite right. From Spec Lead, Mark Reinhold: [https://youtu.be/fxB9cVNcyZo?t=41m50s](https://youtu.be/fxB9cVNcyZo?t=41m50s)

</comment></comment></comment></comment></comment></comment><comment><USER16> I have no idea how the JCP works, but I find it odd that Google doesn't have a vote in this process. They're clearly one of the biggest users and developers of Java in the world, even if you discount Android. Did they choose to abstain from this process, or were they kept out somehow?

<comment><USER17> I don't know for sure, ([https://jcp.org/en/participation/committee](https://jcp.org/en/participation/committee) shows they were in 2013) but I suspect Oracle v Google might be the reason?

</comment></comment><comment><USER18> I was involved in these discussions when I was at Sun.. ten years ago! The major players and their opinions haven't changed. There is no solution that will please everyone.

</comment><comment><USER19> For others who aren't familiar with Java's governing structure,

EC = Executive Committee

[https://www.jcp.org/en/home/index](https://www.jcp.org/en/home/index)

</comment><comment><USER20> I feel like some of these complaints, such as (edit: some of) those by redhat, could have actually been mentioned even before any development on jigsaw began.

It's a bit odd to me that these really large complaints come out now, instead of much earlier in the stage of JDK9. Maybe even before any work would have been done on red hat.

Such as noted here [https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical- deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member- concerns?_sscc=t):

> Fragmentation of the Java community

That seems like a valid concern, which could have been made much earlier. Or maybe they have but people decide to push on with jigsaw anyway?

I did not really follow JDK9 development all that much, apart from the occasional blog. But it just feels to me like at least _some_ of these issues should have been raised much earlier.

<comment><USER11> I don't know the history of this, but it's entirely reasonable that this was a case of _mismanaged expectations_ , a phenomenon that happens a lot in this industry.

In other words, maybe they thought Jigsaw will evolve into an OSGi replacement and it didn't, while introducing migration challenges. It's reasonable because the current implementation is an evolution of the original plan and maybe it evolved in a direction that Red Hat eventually disagreed with.

Of course, maybe this version was scaled back in order for it to be actually released, but note that the main complaint of the others voting No is that there's a lack of consensus on the open issues.

The " _fragmentation of Java 's community_" will happen regardless, upgrades to Java 9 and Jigsaw will be slow, much slower than to Java 8. Consider that there are companies still on Java 6 and 7 and both have reached end of life. Along with an ecosystem of libraries that still maintain backwards compatibility.

If you're going to go through this migration pain, the benefit / cost ratio has to be worth it. Jigsaw has to solve big problems that Java developers face, to convince the community it's worth it, because projects and libraries have to be changed to support it, risking a very unhealthy fragmentation in that process.

</comment></comment><comment><USER21> Why Red Hat voted no: [https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical- deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns)

</comment><comment><USER22> How can one join the EC? Smaller and larger companies with very different focus, and even a community. Interesting.

      Azul Systems, Inc.         Yes
      Credit Suisse              No
      Eclipse Foundation, Inc    No
      Fujitsu Limited            Yes
      Gemalto M2M GmbH           Yes
      Goldman Sachs & Co.        Yes
      Grimstad, Ivar             No
      Hazelcast                  No
      Hewlett Packard Enterprise No
      IBM                        No
      Intel Corp.                Yes
      Keil, Werner               No
      London Java Community      No
      MicroDoc                   Yes
      NXP Semiconductors         Yes
      Oracle                     Yes
      Red Hat                    No
      SAP SE                     No
      Software AG                No
      SouJava                    Yes
      Tomitribe                  No
      Twitter, Inc.              No
      V2COM                      Yes

<comment><USER23> And an individual - Ivar Grimstad. Most surprising one there for me.

</comment></comment><comment><USER24> "Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!"

Ouch, can anyone explain this drama and attitude to me? I've seen it ruin or stall the development of language or platforms multiple times now.

</comment><comment><USER25> Jigsaw would have helped thousands of developers. Yes it does not solve all use cases, but no none of the use cases are solved.

Killed for political reasons because OSGi/IBM/Redhat and money. What the OSGi evangelists would not understand is how Jigsaw does not aim to solve the same problems as OSGi.

Bonus: If OSGi was a good thing, most developers would use it after decades of existence compared to practically noone. Which proves that OSGi does not solve the problems of the mainstream developer, which means making Jigsaw into OSGi- NG is not the way to go.

</comment><comment><USER26> I am afraid this is the death knell for the Java community process. I simply don't see Oracle taking out Jigsaw from Java 9 after investing so much effort into it. Also, a lot of folks were looking forward towards Jigsaw as a lightweight module system compared to heavyweight OSGi.

<comment><USER27> My guess is that they will work closely on open issues with the community and after they are resolved (2-6 months) they will vote again and get enough votes to include it in JDK 9.

</comment></comment><comment><USER28> I like to think of the Java ecosystem as a giant elephant balancing on one leg, careening downhill on its squeaky little JVM roller skate.

I still remember that Java started as a toy language. And for all its security features and incremental improvements to JVM byte codes over the years, it still looks like a toy.

The classloader is the roller skate and the zillions of interoperating jars are the elephant. For the most part, the elephant stays up and continues blasting down that hill.

I used to think the scene was funny, but now I'm uncertain. Only through tools like Gradle and Maven have we papered over the inadequacies of the classloader system and gotten some control of it.

I had hopes that jigsaw would give the elephant an option of a little car to drive or at least a second skate to aid with balance. But safety trumps all, and such a huge breaking change should be avoided if we can.

<comment><USER29> I disagree. I'm very fond of the way Java classloaders work, and how they let me do non-trivial things with relative ease.

Tools like Maven don't solve anything related to classloading in my book. All they do is make it (a lot) easier to figure out dependencies. Judging by the "no"-votes, I doubt Jigsaw would have made that much easier.

As for the Java ecosystem, it seems to be doing better than ever. Can you elaborate on why you think the roller skate is squeaky and about to topple?

<comment><USER28> > Can you elaborate on why you think the roller skate is squeaky and about to > topple?

Maybe 'topple' is taking things a bit too far since Java works far more often than it doesn't. How about 'teetering'?

But the roller skate is most definitely squeaky, and that's mainly because of the lack of help and organization that the built-in java systems give. I can reference two incompatible versions of libraries and the classloader will blithely load from both of them. You can claim "pilot error", but I reply that it's 2017 and we have huge memories and processors that we aren't using effectively to abstract the problem.

Why are we allowed to slam together these huge, sloppy code edifices atop a system that otherwise puts so much focus on security and safety?

Along with the standard "jar hell" arguments, I've got problems mixing cantankerous legacy spring and pre-spring era jars with post Java 8, CDI, JavaEE, etc jars. I need to containerize/componentize these assets and keep them separate from one another because they don't play nice nice with each other. Sure, I can roll my own JarClassLoaders and build a separation between groups of jars by-hand, but I never would because I want the computer to do that work for me - hence "modules".

In my opinion, if tools like Maven don't solve anything related to classloading in your book, then you are either:

1) off in your own corner rolling classpaths by hand and checking your .jar files into Git, or

2) you aren't working effectively at-scale on large software projects with groups of other people

In my case, Gradle was a revelation - it is a Groovy DSL veneer over Ant and Ivy, and it makes rolling custom classloaders extremely pleasant. Maven is very unpleasant because of its declarative XML language, but the Maven artifact coordinate scheme was a brillant stroke. I'm happy the Gradle folks were so successful in melding the platform compatibility tools of Ant, the artifacts of Maven, and the expressiveness of Groovy into a build system that even a dummy like me can grok and use effectively.

<comment><USER30> > Maven is very unpleasant because of its declarative XML language

Maven was intended to be configured via a GUI. If you want to configure it directly, try _Polyglot Maven_ at [https://github.com/takari/polyglot- maven](https://github.com/takari/polyglot-maven) which is a very light wrapper around Maven enabling you to use many other languages instead, e.g. Scala, Clojure, and Ruby as well as Apache Groovy.

The Gradle people marketed their product by slagging the XML which was never intended to be directly manipulated by humans. If you really want to use Gradle (and get a coffee whenever it builds something), it also lets you use Kotlin for writing build files.

<comment><USER28> > Maven was intended to be configured via a GUI.

This is something I didn't know. Did the maven company, Sonatype, ever produce such a tool? It seemed to take years for Java IDE's to finally interoperate seamlessly with maven (was it 10 years for Eclipse?), and by then Gradle was popular and set to unseat it.

I use Gradle daemon when performance becomes an issue, and Gradle is fast enough with that. Maven is no performance superstar.

The maven plugin ecosystem also seemed impenetrable, whereas Gradle promoted plugin development and, lo and behold, they have a vibrant plugin ecosystem! The Maven XML language deserves to be slagged, it seemed designed to frustrate and hamstring the developer.

</comment></comment></comment></comment></comment><comment><USER31> Am I interpreting Reinhold's comments correctly: Jigsaw isn't perfect but we need to get something out there, see what breaks, fix it, and iterate?

<comment><USER32> The problem is such an approach unfortunately does not work with changes to one of the largest programming languages on the planet, especially one that moves as slow as Java. Jigsaw cannot afford to be pushed out half-baked, Java has long prided itself on backwards compatibility and right now we're looking at a Python 2/3 split that will do serious harm to the ecosystem.

<comment><USER27> Agree! Java Module System needs another 6-9 months for polishing, especially in the backwards compatibility area.

</comment></comment></comment><comment><USER33> Bye bye JCP then. Oracle's just going to go it alone from now on.

<comment><USER3> If the JCP isn't allowed to disagree, it was never much of a Community Process, and we were in Oracle-runs-the-show all along.

I wonder what Oracle will do; burning the JCP is not something that will go unpunished.

<comment><USER34> No love for Oracle here (except for all the money they spend having talented engineers work on the JVM. ie fuck their databases).

It's still laughable to call IBM and RedHat a community. They're consultants. Government consultants, mostly. This is an entrenched politics play and surprisingly, Oracle is playing the part of the little guy by virtue of not giving enough of a shit to micromanage the Java ecosystem.

</comment></comment></comment><comment><USER35> It's really a shame as OSGi is a nightmare.

<comment><USER11> Unfortunately Jigsaw is not a replacement for OSGi, this being a valid complaint, since it's a disruptive upgrade for the Java community, while not delivering much.

</comment></comment><comment><USER36> This is not a good thing.

They were finally getting to have a fully built out environment - which could lead to better end user packaging, stripping down a library to its bare essentials.

For instance: what have jpackage achieved for a distribution like RedHat? Does anyone's Java App even pick up these RPM based dependencies for Classpath? Heck no.

Every known large scale Java application pretty much bundles a bunch of JARs. (Probably not logstash - but only one exception)

It is very clear that JDK9 will not be as awesome as it was originally supposed to be. Deeply disappointed.

</comment><comment><USER37> can somebody provide a bit of background? I was looking forward to JDK 9 modules, but i didn't spent much time reading into it. I am quite surprised that it was voted down, since i think introducing modules is a step in the right direction. Also, judging from the comments, it seems that there will be a second vote?

<comment><USER38> The link also has the feedback given by the EC; check out the comments from Red Hat.

That covers a lot of it. To summarize:

Jigsaw started out as just a thing to modularize the JDK itself. It then tried to expand into being a general module system for java apps too. At which point, a whole bunch of concerns were raised about catering to needs that the JDK itself didn't have, but other things might.

At that point, the scope was reduced back down to just modularizing the JDK. And somewhere along the line the scope crept back _up_ to being a general module system, backed by a pretty big baseball bat: jigsaw breaks reflection and requires tons (as in, half a screen full if you're unlucky) of command line switches to make most libraries work.

So, there are now 2 concerns posited with the implementing team (with Mark Reinhold as the lead of that team): What can you do to fill needs that jigsaw does not fill and which we think the java community needs, even if _YOU_ (for the job of modularizing the JDK) do not, and, can you address the issues raised about how jigsaw makes it harder than it needs to be for existing java code to migrate, given that we've been here before (JDK4->JDK5 was a big update), and back then lots of projects effectively forced their users to stick to old versions of java for _years_, and those days weren't fun.

A few downvoters have voted this down because they think these are showstopping concerns and the EC hasn't given suitable answers.

However, most downvoters do not necessarily agree that these are showstoppers, but they have voted this JSR down because they feel the EC owes answers.

Given that Mark Reinhold has already shot down another attempt by Red Hat to suggest a way to address their concerns, right now it looks like this entire JSR is going to get killed in 30 days.

At that point, one of the following will happen:

* JDK9 will get delayed _A LOT_ because a new JSR will be started to continue work on jigsaw. Presumably the same issues will plague it so they'll have to be addressed after all.

* Oracle invokes the nuclear option and gets rid of the EC, or does something virtually as drastic by for example releasing 'oracle java 9' whilst not actually releasing a java 9 spec or the OpenJDK, or trying to eject Red Hat etc from the EC. Any attempt to do that will probably result in the EC voting down everything based on that alone, so, basically all these options lead to: No more EC.

* Jigsaw's scope is reduced to only being a way to modularize the JDK, probably still breaking lots of existing code (because of breaking reflection), but no EC vote is needed because oracle sells it as an 'implementation detail'.

* Jigsaw is removed entirely, and the efforts are refocussed for JDK10, under a new JSR number.

* Even crazier things.

<comment><USER39> > _right now it looks like this entire JSR is going to get killed in 30 days._

I don't think so.

I suspect Eclipse/IBM/RedHat will still vote against it, but the others will accept that voting "yes" is better than the alternatives (as you have described) and let it through.

There are a small number of members who think that Jigsaw if fundamentally bad. For them, it's solving the problem the wrong way, ignoring their beloved existing module systems, and is a waste of effort that ought to be killed. They will alway vote no, and will look for relevant technical reasons to justify that. And there's always _something_ wrong with a spec if you want to find it. I don't specifically mean "this is political" so much as "they are predisposed to be against Jigsaw, and will always find flaws in it because they simply don't believe in it".

Most of the other members who voted no, seem to think that Jigsaw can be salvaged, but don't want to simply wave it through when there's still so much angst, _and_ there's hope that, with time, some of that angst can be reduced and the spec will be improved along the way.

Once they get to the critical point where it's vote yes, or kill it entirely, that decision changes. At that point, voting no creates more angst and more problems, and won't improve the spec. I expect that they'll vote "yes" then, and accept that they got the best outcome that they could possibly achieve.

Perhaps there will be one or two who will still vote no because they don't think enough progress was made and they will take a principled position over a pragmatic one (which is not necessarily a virtue in a standard committee), but I think it will get through, simply because the alternative is so much worse.

</comment></comment></comment><comment><USER40> Interesting to see NXP Semiconductors there. Being primarily a semiconductor manufacturer how do they use JVM based (Java etc) language ecosystem in their products? SDK to program their boards for development purposes?

<comment><USER41> NXP makes smart cards, which frequently run JCOS. This is an embedded OS for microcontrollers which runs on Java bytecode. However, they use Java bytecode version 1.2 and language level 1.3 with Stirings removed, so I don't know quite why they would be influincing later Java versions.

<comment><USER42> They also make IoT devices with Java on them.

[http://www.nxp.com/assets/documents/data/en/reports-or- prese...](http://www.nxp.com/assets/documents/data/en/reports-or- presentations/DWF13_APF_ENT_T0887.pdf)

</comment></comment></comment><comment><USER43> The single most important feature of Java is reverse compatibility. It is a temporal prerequisite of "write once, run everywhere".

<comment><USER5> Do you mean forwards compatibility ?

I can't take Java 1.8 code and run it on a Java 1.7 JVM.

<comment><USER44> The 1.8 JVM implementation is compatible with the interface provided by earlier ones. That's what's meant by backwards-compatible.

</comment></comment></comment><comment><USER45> Glad to see this, not a fan of "requires / exports" keywords.

Java packages already use import. So, logically export should be associated with packages not modules.

Module being meta-package, should follow these.

"requires <package>"

"declares <package>"

</comment><comment><USER46> Excuse me. Could someone please explain why is goldman on the list? I do not think they are qualified as a reviewer based on their engineering standard.

<comment><USER47> What engineering standard are you referring to ?

<comment><USER46> slang...

</comment></comment></comment><comment><USER48> Oracle (the neXt Micro$oft) is killing ex-Sun's Java language and software.

<comment><USER49> Oracle voted yes on this proposal.

<comment><USER50> Yes, that's his point.

</comment></comment></comment><comment><USER51> > Many disagree with circular module dependencies (I am one) at least at this > initial stage.

Does disagreeing with gravity allow you to fly?

<comment><USER52> Would you please stop posting unsubstantively? We've asked you several times already and eventually we ban accounts that won't.

<comment><USER53> Please take this elsewhere, as to your point, replies such as this are even further removed from the subject

<comment><USER52> Fair enough, we've detached the OP from [https://news.ycombinator.com/item?id=14302499](https://news.ycombinator.com/item?id=14302499) and marked it off-topic.

</comment></comment></comment></comment><comment><USER54> I have little idea about cars (Java), but in carpet land (JS): we had the largest module ecosystem ever and it was pretty much ignored by TC39 in favor of a new solution, which has technical benefits (it's async), but there's no migration path from the current standard to the new anointed 'standard'. Sometimes technical committees just refuse to pave cowpaths. Look at the amount of lines it takes to do an XHR in the 'fetch' API vs superagent in, say, 2012.

<comment><USER55> What do you mean by cars and carpet?

<comment><USER56> Also drawing distinction between Java and JavaScript naming, as they really aren't related aside from those first few letters.

</comment></comment></comment><comment><USER57> Most no votes are only because they are concerned about their might with the JCP.... This is a sad day for software development.

        ... is concerned about the lack of a healthy consensus among the members of the Expert Group
        From our point of view the lack of consensus inside the EG is a dangerous sign
        I understand IBM's and others reason for their "No" vote and heard many similar concerns by e.g. the OSGi community or contributors behind major build systems like Maven, Gradle or Ant. Most of their concerns are still unanswered by the EG or Spec Leads
        What we are especially concerned about however, is the lack of direct communication within the expert group
        We echo ... comments in that we absolutely recognize the tremendous achievements and the great work that has been carried out until now by the EG members as well as (and especially) by the Spec Lead himself.

policits will either delay Java 9 or completly kill it. some people just want to show their teeth. sad.

<comment><USER3> How is this politics? They raise specific technical concerns by, amongst others, the de facto package manager! Who would have to raise concerns for you to not simply dismiss this as teeth-baring?

<comment><USER57> they don't raise specific technical concerns. they want to have more time to address/disucss stuff about the specification. also maven is not the de facto package manager. the only thing which might be defacto is the publishing style, however there are many other package manager in the java world. also a lot of this stuff could've been cleared up way way earlier.

p.s.: even if the one outlined is not a policitcal move, some votes definitly are.

<comment><USER3> None of those other package managers have had their issues (mostly the same) addressed either; it's a lowest common denominator: people are complaining that _not even_ Maven has been addressed.

Even if it were true that somehow Maven isn't the de facto package manager (I disagree), it is certainly more than big enough that the JCP doesn't get to casually ignore its existence.</comment></comment></comment></comment>


2M PV in 2 weeks – biggest content marketing launch ever? - <AUTHOR> http://relevance.com/pokemon-go-and-a-record-breaking-content-launch-key-takeaways-for-marketers/ <comment><AUTHOR> 2 million pageviews, 1 million sessions, all in two weeks with zero advertising budget. Curious if this might be the "biggest" content marketing launch ever, from a traffic perspective</comment>