The latest expert opinions, articles, and guides for the Java professional.
Not sure about you, but I’m personally one of those guys who swears by an IDE and usually doesn’t like to work with just a text editor. My IDE decreases development turnaround time for me.
However, I’m getting sick of everything being crammed into one window/application (see image above). And what if you suddenly need to use a new tool, but it is not integrated into your IDE? Or maybe you like to build a Maven project from command line because the IDE integration doesn’t make building easy. Just Alt+Tab (or equivalent) to the right terminal window, press Up to get last command again, and rebuild.
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.
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?
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.