Product Updates, Company News & Fun
This is not another Maven rant nor intended as a flame war–we could even think of this as an “anti-rant”, if you like. I didn’t even bother to see how many other dozens of blog posts on this subject have been written. But let’s face it, one of the most commonly ranted-against tools in the Java development industry is Maven. According to recent results in our 2012 Developer Productivity Report (check out our really popular 2013 version too), Maven is the #1 build tool used by developers.
So what is a build tool supposed to do? Basically, it should automate a bunch of processes that developers need to do regularly, removing some of the manual sting from compiling your source code, packaging and running tests on it, etc.
Let’s start by reviewing the top 5 things that a Build Tool should do really, really well…
Many syntax highlighters have at some point made a wrong choice about a simple aspect of how they do syntax coloring and present code: they make keywords bold and emphasize the wrong thing – the boilerplate instead of the intentional code. This applies to many language IDEs, text editors and other syntax highlighters, but I’m mostly focusing on Java IDEs in this post, which have more information about code than a simple highlighter. Both Eclipse and IntelliJ IDEA have decided to make keywords bold, but NetBeans has a better default highlighting scheme.
I don’t know the exact original reason (probably from decades ago) for making keywords bold, but I imagine that it was desired to distinguish keywords from identifiers and to make all identifiers bold was out of the question, so keywords were made bold instead. And this style has remained common for years and years…
People love Eclipse, or love to hate it, or, as non-geek coders, feel more or less indifferent about their IDE. However one thing is true–the majority of Java and Java EE developers use Eclipse. This RebelLabs report starts shallow and goes deep into orbit around the ecosystem of Eclipse, showing you the best things that Eclipse has to offer, and letting you know how to turn off some of those annoying bits (“Why does content assist keep asking me about awt??!?!”). From packaged solutions to plugins and customizations, it’s all in here, from n00b to ninja in 40 pages.
I’ve been trying to write code in a more functional way lately. I haven’t fully bought into functional programming yet, but it has more and more influence on my code. And yet, not long that ago I was fully convinced–like many programmers today–that the object-oriented way of doing things was the right way.
I designed class hierarchies that had mostly mutable properties–this kind of code seems to follow naturally from design-thinking that starts with object hierarchies or class diagrams. I’m now wondering if that was just an artifact of a computer science education that put an (over-)emphasis on object-oriented design and related subjects.
Functional programming doesn’t mean anything else than programming with pure functions (in the mathematical sense). However, this simple statement has wide ramifications when you think about whole programs. Ideally, a program is also nothing more than a pure function, composed of smaller functions. And most programmers (including me) don’t really know how to design complete programs this way.
The Eclipse IDE, according to some recent numbers on IDE usage, sits in nearly 2/3 of developer workstations. The ecosystem for Eclipse plug-ins, as you can imagine, is quite vast: about 1600 plug-in solutions are hosted on the Eclipse Marketplace, and have been downloaded nearly 6 million times collectively.Read more
In this third post on the untyped lambda calculus, we’ll look at implementing an evaluator in Scala. We already did a parser and the framework for a REPL last time in Parsing Lambda Calculus. Hopefully, the conclusion to this post also has a better answer to the question we asked in What is Lambda Calculus and should you care?Read more
In a previous post we introduced the pure untyped λ-calculus. Summed up in one sentence: it’s the smallest universal programming language with only a few language constructs (anonymous functions, variables and function applications), and is useful in understanding computing at a hardware-independent level.
In this post we will implement the beginnings of a λ-calculus interpreter consisting of an AST, a parser and a basic read-print-loop to exercise the parser. Adding evaluation to get a functioning REPL will be left for later. We’ll do the implementation in Scala, and demonstrate some Scala features/libraries in the process. You could of course follow along in your favourite language (hopefully it has a parser combinator library). The full source code is available on GitHub , with commits roughly corresponding to code snippets in this post.
Introduction to λ-calculus
In this post we try to give a really short overview of what’s λ-calculus and why you might want to know about it. In parts two and three we will see a basic implementation in Scala. Lets start with a short description (quote from Wikipedia):
“Lambda calculus (also written as λ-calculus or called “the lambda calculus”) is a formal system in mathematical logic and computer science for expressing computation by way of variable binding and substitution. First formulated by Alonzo Church, lambda calculus found early successes in the area of computability theory, such as a negative answer to Hilbert’s Entscheidungsproblem.
50-Page Tech ReportWhy do we need so many JVM languages?
It’s 2013 and you have over 50 JVM languages to choose from for your next project. But even if you can name more than a dozen or so, are you going to pick a new one for your next project?Nowadays it’s easier than ever to create a new language with support from tooling like Xtext and ANTLR. Many new JVM languages have emerged as a result of limitations and disadvantages, either for creative individual coders or the masses, perceived in existing JVM languages, historically Java.Read more