Brendan Eich did just that, in 1995. He put this weird Java-Scheme-Self-HyperCard hybrid of his into browsers, and now all the king’s horses and all the king’s men can’t take it out again. I’m not saying Eich is an evil overlord; I’m saying if he were, this would have been a very clever move indeed on his part. Witness me clapping slowly.
Three stages of grief
- Learn the language extremely well, so we can use it well.
- Improve the language step by step (without breaking anything).
- Wrap the language in a nicer language and use that instead.
Option 2 is also underway, and seems to be picking up speed. Not only do we have a mostly-complete transition to EcmaScript 5 behind us, but EcmaScript 6 is looking good and more stable every day. Sometimes when the weather is just right, you even hear soft whispers of EcmaScript 7 in the wind. Evergreen browsers are becoming more common and help speed up adoption of newer features. All in all, given that we’re stuck with this language, it feels like we’re doing a very decent job of fixing it.
Option 3… now there’s a Cambrian explosion for you.
On that list, you’ll find existing languages, original languages, languages with interesting ideas, and languages that won’t ever have 10 simultaneous users. There are behemoths like CoffeeScript and GWT on there. Even Perl 6 is on that list. It’s a long list.
Everyone is helping. The people from option 1 have shown us, across the years, how to emulate classes and interfaces and modules, how to fake it without strong typing, and how to hack the DOM in various ways to emulate features. The result is a lot of so-called “boilerplate” code: a lot of code with a low oomph-per-character ratio. You’re not paid to like it, you’re paid to make it work across all browsers, kiddo.
A bit more in detail:
Try it now
Several Edumenters attended Build Stuff 2013, and two of us gave talks. All of them were recorded by InfoQ, and they’re now starting to appear online! The first one to appear is my invokedynamic talk. The invokedynamic instruction was introduced in JDK7, and was aimed at helping compiler developers targeting the JVM to more efficiently implement a wide range of language features. While the name suggests a role mainly for the things we like to call dynamic languages, invokedynamic has in fact been used as part of implementing lambda expressions in Java 8.
My own application of invokedynamic was implementing JVM support for the Rakudo Perl 6 compiler. While the talk is not just about that – it covers invokedynamic in a much more general sense – I was able to draw on my concrete experiences of using it, which is something I always like to be able to do in a presentation. Also it was nice to do a talk on compiler-related things – an area I greatly enjoy working in.
Carl reports about his week-long Git teaching in China, and the various thoughts he had along the way.
While here in China, I’ve been thinking of traffic.
Compared to Sweden, there’s a proliferation of vehicle types. In Sweden you’d see cars, trucks, and bikes on the road. Here you see that and more: mopeds of different sizes, bikes and motorcycles with flatbeds on them, mopeds that pretend they are cars, cars that look like half a car, and various hybrid types between these. It’s as if China has already experienced the traffic equivalent of polyglot persistence.
Not only that, but everyone seems to get by with lots fewer traffic rules. That’s my impression at least, as a safety-minded Swede. Pedestrians crossing the street everywhere, dodging in front of or between cars. Bikes and mopeds going against traffic. Oh, and apparently one of the few traffic rules here says that you’re free to turn right any time, regardless of what the lights say.
But the amazing this is, it works. There are very few accidents. I haven’t seen one, at least. The whole system seems to work through honking. Whereas in Sweden, a car honk would mean something very much like “Pay attention, you’re doing something quite wrong!”, in China it means something much more like “Oh hey, I’m here! Hi! Got space for me in this jam?”
A Git conflict is a bit like a traffic jam: two developers wanted to occupy the same piece of source code at the same time, and now they’re honking at each other, waiting for a solution to present itself. In traditional (centralized) version control systems, the tendency has been to introduce traffic lights everywhere, to make it clear who gets to modify the source code, and who has to wait. It’s a sensible model, and it certainly has safety to speak for it.
But Git (among other contemporary distributed systems) offers an interesting alternative: let’s ditch the traffic lights, and just handle conflicts as they occur. Does your change conflict with someone else’s? Well, then it’s your mess to clear up, go right ahead and write yourself out of that tangle. If you’re of the old centralized school, or a Swede, this sounds like madness at first — who in their right mind would want to give up the safety conferred by traffic lights in favor of… anarchy?
But it does work, and there are even some hidden advantages. In the literature, the traditional model of providing traffic lights everywhere is called pessimistic concurrency, whereas Git’s laissez-faire model is called optimistic concurrency. Interestingly enough, processor manufacturers and developers of concurrent algorithms face the exact same choice, between pessimistic and optimistic concurrency. And their conclusion is largely the same: optimistic concurrency scales better.
Basically, the old centralized version control systems give you safety whether you need it or not, at the cost of slowing everything down a little. The new distributed systems have an attitude of “OK, there will be conflicts on the way, but we’ll handle them when we get to them”. Since usually there aren’t conflicts, normal work progresses faster, with fewer distractions. Most cars meeting on the road do not head straight for each other and start honking.
All of this makes for a cute analogy, I guess, and it was something that struck me at the beginning of the teaching week in Shanghai. I even told the first group about it. If someone else had made the comparison, I would probably have nodded and said “yeah, sounds about right”.
The teaching week itself went fine. There’s something about Chinese audiences that makes them a little extra rewarding to teach to. I think they simply pay a lot of attention. Any teacher will tell you that that in itself makes a big difference.
Besides which, the questions were interesting, and showed that people were following along.
On the Friday, we had a Q&A session for people who were interested enough to come ask Git questions outside of the curriculum. Now, it turns out that when you arrange such a session, the people who turn up tend to be the people who are not based in Shanghai — likely because they are away from their daily work anyway, and don’t have competing priorities. But we were a cozy gang of about ten people, and filled a morning of discussion about the different bits of Git.
After doing Git for a week like this, I experienced another insight, one I hadn’t had before. Git (and distributed version control) mirrors the way the Internet works. The Web is a big tangle of servers and clients, all talking to each other without any central authority. Peer-to-peer services like Bittorrent have disrupted the way we think about content distribution. Cryptocurrencies like Bitcoin are beginning to do the same thing with money. Git belongs in this bucket of fast-moving, fluent, net-enabled technologies.
…weirdly enough, since one of the big selling points of distributed systems is that you don’t need a network connection.
Git is the technological enabler of meritocracy within a project. In a real meritocracy, it doesn’t matter who you are, only what your contributions are. I just accepted a contribution in a Git project from a person I’ve never met and whose name I can’t recall. I chose to accept the contribution because the content looked good. In Git, the one who pens the contribution is called the author and the one who accepts it into a project is called the committer. Before I had started using Git, it hadn’t even occurred to me that author and committer could be different roles. Every time the author and committer are different people, a contribution happens to a project that likely wouldn’t have happened before.
Git encourages this kind of distributed collaboration. It does it very well. The whole branching model is geared towards giving everyone equal status. By default, there’s no privileged central repository, there’s no privileged developer, and no-one tells you which workflows you have to pick. (The last point is kind of disorienting for people who come from one of the old systems, where there’s usually One True Way to do things. Entering into the world of Git where there’s lots of possibilities tends to lead to a feeling of vertigo.)
Perhaps the best example of this kind of meritocracy is Github. Github doesn’t really add much new on top of Git, it just exposes it in ways that tend make people contribute to each others’ projects. Whereas on Facebook you “like” people’s posts, and on Twitter you “retweet” them, on Github you “fork” someone else’s project, make a contribution, and then ask them to reintegrate it into theirs. Again, I don’t really think of Github as something more than Git. They did a remarkably good job of creating a web interface for the things you normally want to do with Git, and adding wikis and issues and web pages around each project… but in the end, what they are doing is harnessing Git’s powers, not extending them.
All this explains to me a bit better why I like Git so much, and why I want to invest time in learning it well. Because Git is essentially version control’s reply to the Internet. It’s the way we should be working if we’re aware that the net is becoming more and more of a natural part of our lives.
Even on this social level, what we’re harnessing is a kind of anarchy. The occasional motto in an early open-source project I was a part of was “Trust the anarchy”. In other words, lots of chaotic contributions will mix together, and if we just do some minimal guidance, then the sum of all those contributions will be greater than each individual one. In this sense, Git inherently trusts the anarchy.
What’s next for Edument and Git? We’re going to be doing a deep dive into our Elite Git course, for people who want to implement Git workflows inside an organization.
It was around a year ago that I first suggested to my colleagues at Edument that we might want to build a C# course focused on parallel, asynchronous and concurrent programming. The inspiration came from teaching the final two modules of our popular C# Masterclass, which provide a little coverage of these areas. I noticed it was one area of the course that participants particularly enjoyed – despite it being at the end of 3 information-dense days. And I found myself often jokingly pointing out that it’s a big enough area that we could spend 3 days on this area alone.
Turns out, the joke has become a sales pitch: we now really do have a 3-day course on those topics. It’s already been run twice, and already it’s confirmed that we will be running it twice more, in Stockholm in April and then in Malmo in May. Given this initial level of interest, I’m hopeful of many future deliveries – including some beyond Sweden.
For me, this is an enormously fun course to teach. I had the fortune of being lectured in concurrency by one of the leading experts in lock-free data structures back in my university days, and it created a curiosity for the topic that has never gone away. Since then, languages and libraries have evolved enormously. The .Net framework’s offerings these days are a huge improvement over what was available in the early days. However, there’s now a heck of a lot of choice:
- Traditional threads and locks
- Concurrent collections
- Parallel iteration
- Parallel Linq
- TPL Dataflow
What do they do? How do you know when to use what? What sorts of problems do they solve? The course looks at all of the above, covering the basic theory before moving on to practical examples of how they are applied. Participants get to take away my sample applications for all of them, as well as being able to try them out in exercises (which also come with sample solutions).
The prerequisites for the course are set fairly high: participants need not have experience in the areas covered, but should most certainly have up-to-date C# skills. That means being comfortable with generics, lambda expressions and Linq – key ingredients of elegant C# code. These are used quite heavily in the .Net framework’s parallel, async and concurrent programming features, and therefore are relied upon heavily in the course. Thankfully, for anybody who feels they aren’t really up on these topics, we’ve other courses to get you there.
Anyway, I look forward to bringing the course to Stockholm later this month, and doing it on home turf at Edument’s Malmo teaching center in May. There are certainly some spots left in Malmo, and probably some in Stockholm too. And, as with all of our courses, we’re happy to offer it on-site at your company too!
Edument fortsätter att växa. Vi har därför förstärkt vårt team med ytterligare två Account Managers till kontoren i Malmö och Helsingborg.
Låt oss presentera Emelie Andersson, en positiv tjej med många års säljerfarenhet från både utbildnings- och mediebranschen. Samt Olof Brodén, som tidigare har drivit sin egen e-handelssite och arbetat som säljare med projektledningsansvar inom media.
Emelie når du på: 0763- 05 14 93 och firstname.lastname@example.org
Olof når du på: 0735-31 61 01 och email@example.com
A while ago we published our Intentful Testing Starter Kit. To persist events, it needs an implementation of the IEventStore interface. In the starter kit so far we’ve had two implementations: an in-memory event store, and one that builds a simple event store using a SQL database. However, there are many other options out there, including the wonderful EventStore!
It’s not too hard to write an implementation of IEventStore that uses EventStore, but for those not quite sure how to do it (or just too lazy!), there is now an example in the starter kit repository.
Lately, we at Edument have been teaching Git in different places around the world. Scandinavia, Spain, Saudi Arabia, China. Now it’s time for Shanghai for the second time.
Different parts of the world feel different to teach to. I for one, look forward to a room full of voraciously interested participants, like I had in Shanghai last time.
In some ways, it feels surprising that we spend so much effort talking about Git, and that there is such a demand for it. After all, Git is just a version control system. We’ve been version controlling stuff for decades. How different can Git be? It’s almost like someone buying a new kind of running shoe, and then spending their days convincing friends and relatives to buy it, too. “Really, you’ve got to give this running shoe a try! It’s awesome.”
Does Git really live up to the hype around it? Yes, we believe so. At Edument, we’ve been relying on Git since the company was founded, and Git operations thread through our work every day. Here are the things that we feel make Git different:
- Git is built to support fast branching and merging from the ground up
- Git has a few basic primitives that it uses consistently across the whole system
- Git is very transparent and open-ended
- Git allows you to choose your own workflows, tailored to your project
- Where Git ends, it has various tools — hooks, scripts, custom subcommands — that you can use to make it even more useful for you
- All of this means that you can focus on your project, not struggle with the version control itself
So yes, Git is clearly superior to the previous generation of version control tools we had. And it’s liberating and fun to travel around to various groups and teach this tool that we know has made our own workflows better, and can help make our clients’ lives better too.
Git gives you a certain measure of freedom. Not only is it a light and comfortable running shoe; Git is the running shoe that allows you to run along walls and do crazy jumps between buildings that you wouldn’t even have dared contemplate before.
Hoping to give a progress update by the end of the next week; not just about the week of Git teaching, but also about our future plans with Git courses.