Suspicious Semicolon: CDT at EclipseCon France 2016

before_suppress

The CDT project was well represented in Toulouse this year.

CDT Latest & Greatest

Jonah Graham gave a CDT overview with CDT: Latest & Greatest Tooling for C/C++. Mostly hands-on, Jonah used the C-implementation of the Python interpreter to demonstrate how to set-up, build and debug a substantial sized project with CDT.

 

This included showing some of the new features in Neon like suppressing Codan warnings and the enhanced memory view. Jonah also talked about the upcoming features including the new GDB console and improved multicore breakpoint support. Continue reading “Suspicious Semicolon: CDT at EclipseCon France 2016”

Whose job is it promote diversity in the Eclipse community?

IMG_20160511_184220-002

I received an email inviting me to join a group to help improve diversity at an upcoming EclipseCon. I was surprised at how reluctant I was to help.  My first reaction was ‘I do my bit and it’s just not my job‘. Maybe it hadn’t help I had just been reading research suggesting women and minorities are the ones most penalized for promoting diversity. Nevertheless, the request had come from Alex Schladebeck, someone I have a lot of respect and admiration for and I simply could not say no to her. And I’m really glad I did say yes. One meeting had us all thinking, raised a lot of questions and generated useful suggestions. It also inspired me to look into the topic more thoroughly and I was surprised where the research led me and what the solutions should be. Continue reading “Whose job is it promote diversity in the Eclipse community?”

Why it’s time to kill the Eclipse release names:Neon, Oxygen, etc

noneonmarsluna

I thought I’d heard all the arguments for why developers choose IntelliJ IDEA over Eclipse IDE, but this was a new one. I was at a meet-up with lots of Java developers, and inevitably the conversation went to the topic of preferred Java IDE. One developer raised the point ‘I never understand the different versions of Eclipse, you know, Luna, Mars, Neon – what does what, which is the Java one I should download? With IntelliJ it’s just IntelliJ community or ultimate,I know what to get.’ I had to stop myself from launching into a let-me-explain-it’s-simple-and-alphabetic explanation and instead just listen and look around to see others were nodding along in agreement with the speaker.

Not long after that I was reading this article: Kill extra brand names to make your open source project more powerful by Chris Grams. In the article, Grams talks about the ‘mental brand tax‘  incurred when projects have additional brand names users are expected to understand. This was the name for what the developers were expressing. As Grams explains “…having a bunch of different brand names can be exclusionary to those who do not have the time to figure out what they all are and what they all do.” This sounded like those developers who are busy solving their problems and keeping pace with the fast developments in software.

From my corporate days, engineering often had a working project name. For example, there were the projects named after US state names: ‘New Jersey’, ‘California’, etc. However, when it came to release, these internal names were always scrubbed out by the product marketing department and never referred to from the user perspective. In those cases it was easy to see how the project names could cause real confusion out in the world.

In Eclipse, the names are part of the development flow. It’s a nice way for the community to get together to choose them and it is a common language for us as Eclipse developers to use. Often we don’t differentiate between developer-users and developer-extenders. We expect all users to know they are alphabetic and follow a similar theme. But if you think about it isn’t that just another level of abstraction put onto Eclipse versioning? Should these names really be going out to the Eclipse users? Should we expect our users to know Neon is the same as Eclipse 4.6 which is the same as the version that was released in 2016? Ditto for all previous versions? (And that is before we get into the different flavours of the IDE e.g. Java, C/C++, etc).

So what could we use instead? I don’t have all the answers, but want to kick off the conversation with a proposal. As Grams summarizes “Sometimes the most powerful naming strategy is an un-naming strategy”. What if we did that? The Eclipse simultaneous release is reliably once a year. How about we use the year it comes out to version it. So this year, Neon would be Eclipse IDE 2016, Oxygen becomes Eclipse IDE 2017 and so on. The added benefit to users is that it becomes immediately obvious how old previous versions are. So instead of ‘Are you going to fix my bug in Luna?‘ someone might ask ‘Are you going to fix my bug in Eclipse.2014?‘ It might be more straightforward for them to see they are already 2-3 years behind the latest release.

As we, as a community, move towards thinking and treating Eclipse more as a product, this is a change that could be well worth the effort. As Grams notes:Just because you have a weak confederation of unsupported brands today doesn’t mean you can’t change. Try killing some brand names, replacing them with descriptors, and channel that power back into your core brand.”

“Hello World!” – One Small Step for Python Scripting in Eclipse

helloworld

We are excited to be able to run a ‘hello world’ command using EASE and CPython in Eclipse (quickly followed by running the ‘Zen of Python’ for good measure :). It is the first key stage of proving our approach of using Py4J as the enabling technology to getting scripting available with EASE for Eclipse. It is a small step, but a significant leap towards unprecedented automation, dramatically easier Eclipse extensions and powerful third-party library integration using Python. Continue reading ““Hello World!” – One Small Step for Python Scripting in Eclipse”

Join us at EclipseCon France 2016

eclipsecon-728x90

Kichwa Coders are looking forward to EclipseCon France this June in lovely Toulouse.

We’ve teamed up with Christian Pontesegger to deliver the first ever EASE Python Scripting workshop. We’re looking forward to helping folks use scripting to really make the most out of their IDE. There are  also lots of other great workshops at the conference: Tracy Miranda, as part of the program committee,  has written a summary of them here.

Jonah Graham will be speaking at the conference on “CDT: Latest & Greatest Tooling for C/C++“. Join us to keep up to date about all things CDT.

And finally, we’ll be sticking around for the Unconference (on the 10th) with the Science Working Group. We’re currently making plans for a code sprint (or two). Everybody’s welcome to join!