larsberg

I should mention that I and other hiring managers I've talked with are moving away from posting on the "Who is hiring?" post.

It was pretty useful ~6 months ago. But, the amount of spam generated from recruiting and sourcing firms, various startups trying to push their revolutionary new online coding tools, etc. is pretty ridiculous and many of them, especially the SV-area startups, have been quite aggressive (e.g., phone calls and switching to my personal e-mail address after I told them I was not interested).

Posting jobs on twitter has been a far more effective sourcing tool than HN "Who is hiring" has become recently, at least in the free space.

It just takes time to do, and given that it's been a long time since there were any "infrastructure" grants to handle student or faculty time to support adding those instructions, adding and debugging them just takes time that nobody has to take out of doing research.

It also doesn't help that everybody who has worked on MLRISC has long since moved on to other projects, so when you find what you think is a bug in something core, there's really nobody to chat with about it, get feedback on where the right place to make a fix is, etc.

Yes, SML/NJ and Manticore (which have more than a bit of overlap) are still the main supporters. The x86_64 backend is only used by Manticore today; SML/NJ is still only 32-bit, though there's some work going on to migrate it to 64-bit, at which point it would also exercise that backend.

It isn't listed on that somewhat-old page, but as part of the Manticore project we (primarily Mike Rainey) also added an x86_64 backend to MLRISC:

https://smlnj-gforge.cs.uchicago.edu/scm/viewvc.php/MLRISC/?...

In the long run, we on Manticore - like most other projects - will probably give up the flexibility of MLRISC and contort our code generation to work with LLVM. It's hard to keep adding new instructions to MLRISC!

Yes, this is mentioned in the paper, right next to where they talk about the correlation.

The most telling part, though, is where they take some of the lower-25% from cubicle farm/open office spaces and put them in private office spaces. Guess what happens?

One of my favorite pieces of research in this space is DeMarco & Lister's "Programmer Performance and the Effects of the Workplace." Basically (go read it! it's short!), they show that the difference between private offices and tiny cube/open floor plans is strongly correlated with being in the top 25% vs. the bottom 25% of developers, which is a difference of around 2.6x.

Not 10x, but also non-trivial for those of us who don't have Facebook-like dollars to throw at filling desks in an ever-larger open floor plans.

> Yes, they are paying a high initial cost to develop these offerings.

I certainly agree that for organizations who can afford these high initial costs internally this is a great development model. My challenge (as a manager at Mozilla) is that, given we don't have such resources available, how do we build partnerships with groups or other projects that do in order to ensure such offerings are built?

Of course, another interesting approach would be to say that GitHub, Travis, Heroku, etc. show that DevOps-as-company is a viable business model and really what we should be doing is spinning up companies that raise funding and build products around each of the areas that are still lacking products that serve enterprises (read: customers with money) today.

> they've repeatedly rejected suggestions for improving them.

I certainly agree that it's easy to imagine better issue management or patch review than GitHub has today - like many other projects we use other systems. When I've talked with GitHub engineers, all of our issues are well understood and they have plans to address them.

My skepticism is around the strategy of building and supporting our own things vs. partnering with places like GitHub that make a living building and supporting such software. In the Mozilla-specific case, they have proven open to working with us in the past, by pony-trading enhancements to Firefox for enhancements to GitHub, and the inability to deliver has been more on our side :-/

This talk and my experiences at Microsoft are why I tend to try to steer our projects at Mozilla Research to partner with external offerings rather than doing too much building of our own. It's hard to imagine a world where we build and continue to improve a source control / issue tracking system better than GitHub; a continuous integration solution better than Travis CI; a build system; etc.

Even if we can imagine building a better product today, the ongoing maintenance and extension of those services quickly become full-time multi-person investments with many hundreds of dedicated machines, neither of which even our core infra teams have, much less the little tiny research org.

Since last July or so, Servo has been tracking all of the major features we'd like to see that have been postponed to post-1.0: https://github.com/servo/servo/issues/2854

You've probably already thought about this, but you might want to make sure clients understand the legal side of things. We've certainly had some cases at Mozilla where remote workers had to be "reminded" that we could only pay them if they maintained residency in their official company of employment, that they would be in violation of the tourist visa they had traveled to these other locations under if they worked there for 3 months, etc.

It's a bit of a minefield, and I only know the warnings that legal/HR tell managers :-)

It's a hard problem, which the COMPlus team knew when they started out. During the early pre-release period, there was a then-NDA-only project, Project 7, which gave grants to people trying to port both commercial languages like perl and academic languages like scheme. I was at Northwestern, where we got a Project 7 grant to work on a scheme implementation (under Ian Horswill, done by Pinku Surana in my group) and scheme language service (done by me).

We provided a lot of feedback, but it's tough for a group of a couple of students (or in the case of Perl, one commercial dev) to keep up with the then massive-breaking-changes drops we'd get from DevDiv every 3 months or so and provide feedback when it was on stuff that was, to the developers, around 6 months old. Often, by the time feedback landed, it was "too late" to incorporate because of product cycles and got postponed. Or the stuff we'd request was a dupe of "add tail call instruction" which had been postponed long before any of us got started in Project 7.

I say this as somebody who then graduated and then went to work in DevDiv for the next 7 years, where I was treated very well, so I certainly have no axes to grind on that front :-)

> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs.

What, you mean like we do in Servo? https://github.com/servo/servo :-)

Our main thread (if you can call it that) just does compositing and handles dispatching UI events. Script, layout, resource loading, and the rest run concurrently in background threads.

> I guess it's no surprise that microsoft software has a human-edited source file that's over 35000 lines...

IIRC, it was originally machine-generated... from LISP code written by David Bacon, under contract from the then-GC owner Patrick Dussud.

Mozilla Research (Remote or any of our offices)

I will be hiring for two positions in the coming month, associated primarily with Servo (https://github.com/servo/servo ) and Rust (https://github.com/rust-lang/rust/ ).

1) Senior browser engineer. I am looking for a developer with deep familiarity with web platform standards, especially related to the implementation of the DOM and integration with the JS engine, to help build out this support in Servo. Experience developing systems software required.

2) Experienced operations engineer. Working in concert with the larger Mozilla release and build teams, build out the Mozilla Research continuous automation, release, testing, etc. systems, focusing first on Servo and Rust. We explicitly want candidates with a history of reuse and contribution to existing projects. Experience with build systems, automation, and cloud systems preferred.

Please feel free to contact me directly with more questions - larsberg AT mozilla DOT com. Job postings with more details should be coming online soon...

> making a big fraction of users into programmers is that we don't know how to do it

It depends on how you define "programmer." At Microsoft in the late 90s/early 00s we were very happy that there were so many Visual Basic programmers, but several million of those included people who would not self-identify as a programmer. That is, they were people who would write VB oneliners in either Excel or Access; people who would make or modify "keyboard record & replay" macros; etc.

I agree that trying to make everybody a full-blown systems or application programmer seems like a very hard problem.

> I know these people exist everywhere today but there's an unusually large number concentrated in Chicago. Must be something in the water?

Finance is also an extremely tempting lure. The pay is quite good (e.g., significantly better than Google), the hours are better, and the firms are generally supportive of external work. Many of the finance firms my friends work at (I've lived in the Chicago area most of my life) allow/encourage/hire people to serve on the C++ standardization committee, were co-founders of major open source projects such as R, etc.

It's hard to lure people away from jobs like that where you're paid a lot and have a ton of freedom for a potential exit that's smaller than what you currently make, unless your startup becomes Google.

I work at Mozilla (I believe ~70% remote workers) and certainly see people do things like this all the time, though often on a smaller scale. For example, if they have a conference or meeting in Europe or Asia, they might extend the trip to visit other locations and work from either hotels, coworking spaces, coffee shops, trains, or "camping" in our other offices.

I certainly encourage it, for people who both want to do it and whose lifestyle supports it! Caveat international work and visa laws, where prohibited, of course :-)

> I have friends who will be working at Microsoft, and other friends who criticize said 'Microsoft' friends, saying that they won't learn much.

There are many things to criticize about the dev experience at Microsoft, but that's definitely not one of them. Unless you're in a quite dysfunctional group, there is extensive early-career training and explicit mid- to late- career mentoring there that really distinguishes it from startups and other big companies. As a manager there, I was held responsible for growing my organization's devs much more explicitly and to a much further "minimum ceiling" career stage than I've seen or heard of from any peers at other companies or other places I've worked.

Of course, things may have changed since I left that position in ~2006.

If you just count *.rs files, rust and its in-tree libraries are around 400k lines, and Servo and its immediate dependencies are around 310k lines.

Caveat: use of 'find' and 'wc' is almost invariably totally misleading :-)

Nick Cameron's been gathering some requirements about what would have to happen to enable tooling support: https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c

I tried to revive as much information as I could from my days in Visual Studio, but if you have additional feedback, I'm sure he'd be very interested to hear it! Obvious caveats about it being a long-term goal, no immediate plans to tackle it, larsberg is on Servo so what does he know, etc. :-)

I definitely saw the "being totally unplugged" problem both previously when I worked at Microsoft and now when working at Mozilla. It's arguably even worse at Mozilla with the shift of many people (myself included) to IRCCloud, which is a wonderful service but turns what was supposed to be an asynchronous, loose availability chat system into a realtime, all-hours interruption mechanism.

Do you not have to park? Or are you assuming Uber?

Parking got quicker in Chicago since the metered fares went through the roof, but it can still easily dominate the total travel time, as leaving and entering large multi-floor parking structures downtown takes a really long time.

It's a slide deck template I've been using for some joint Mozilla/Samsung presentations lately (LinuxCon NA, EU). The logo tabs are a cute way of indicating when the talk switches between a Mozilla and Samsung speaker.

We did the first part and very recently put http://www.sml-family.org/ online and announced the opening of the definition (whew!).

I'm primarily concerned with the parallelism and concurrency-related features, which we're trying to first clean up a bit more in the context of Manticore before trying to do something like proposing standardization for those features.

Also (IMO) you should take those slides more as a research direction for years of research investigating alternatives that eventually get standardized, not a 2015 implementation plan :-) Each of those topics casually mentions non-trivial extensions to problems that already have each had researcher-decades of investigation.

I agree completely with your library statements.

> I think one of the biggest mistakes in the life cycle of SML was premature specification.

I disagree. There were some earlier Successor ML efforts ~10 years ago (see: http://successor-ml.org/index.php?title=Main_Page ), but as I understand it, there was agreement on many of the small issues but larger challenges reaching consensus on bigger changes. You can see some notes from Bob Harper at the ML Workshop in 2013 on how we're moving forward currently:

http://www.cs.cmu.edu/~rwh/talks/mlw13.pdf

My intern, Laleh Beni, gave a talk last week where she compared the performance of Servo on a synthetic benchmark to that of Firefox on Android: https://air.mozilla.org/servos-power-struggle/

We're not publishing comparisons with other engines for now because we don't support the full web platform yet in Servo and it doesn't make for a fair comparison against them. Certainly, we benchmark against other engines internally and try to ensure Servo's page load times are at least as fast as the other engines. That said, we don't have incremental layout yet, so Servo is _way_ behind on any measurement involving dynamic page updates.

Lots of good progress, but we also still have lots of work to do!

(shameless plug to solicit contributors: https://github.com/servo/servo/blob/master/CONTRIBUTING.md )

I'll be very interested to see how this goes.

In a former life, I worked on developer tools and as part of that we did some extensive on-site filming of experienced developers, in order to do some new product development (I think we used 10 years of professional development as the minimum bar). I don't remember the exact numbers, but it was over 75% of the time was spent reading code - just navigating, stepping through a debugger (without making any changes), and just staring at huge piles of code.

Hey! I was the one running the build environment stuff in VS at the time.

IIRC, CoreXT didn't handle some really oddball scenarios we had that involved self-hosted compilers and runtimes. e.g., rerunning the build with the compiler you just built or just the runtime you just built, or...

We were also trying to shift as much of the managed parts of the stack as possible to using MSBuild natively, which required a custom local runtime build to support asmmeta (which rudi and I created to solve the circular build dependencies in managed libraries in VS).

We were also using subtly different versions of build.exe whose parallel build support and support for scenarios with files over 2^31 bytes differed in non-trivial ways.

In the end, I think I stole everything I liked in CoreXT (which was a lot!) but we couldn't really adopt the workflow without breaking basic requirements that VS had that nobody outside of a compiler toolchain really sees.

(BTW, I apologize if some of this is off. Like you pointed out, this is more than 10 years ago.)

Is there a way to search by the status flags? It's now harder to see them since they're no longer in the same column, and I use the "has passed tests" filter frequently to check which PRs might need shepherding on Servo (https://github.com/servo/servo/pulls )