Seldom without a computer of some sort since graduating from the University of British Columbia in 1978, I have been a full-time Linux user since 2005, a full-time Solaris and SunOS user from 1986 through 2005, and UNIX System V user before that.
On the technical side of things, I have spent a great deal of my career as a consultant, doing data analysis and visualization; especially spatial data analysis. I have a substantial amount of related programming experience, using C, awk, Java, Python, PostgreSQL, PostGIS and lately Groovy. I'm looking at Julia with great interest. I have also built a few desktop and web-based applications, primarily in Java and lately in Grails with lots of JavaScript on the front end and PostgreSQL as my database of choice.
Aside from that, I spend a considerable amount of time writing proposals, technical reports and - of course - stuff on https://www.opensource.com.
Authored Comments
Thanks for your comment, Golman. Generally I agree with you - there's a lot (perhaps too much) appreciation for shiny new objects in the developer's world.
Having said that, I believe there is value in brevity and conciseness, especially as expressed in Don't Repeat Yourself (DRY). To me, functional interfaces in Java 8 and onward are a huge benefit to code maintainers as well as developers, simply by reducing the boilerplate code arising from "here" objects whose only purpose is to provide an implementation for a single function. The obvious fact that this reduces typing is kind of by the way; the real benefit is the code is more compact and readable, and the "what" is much more clearly visible when not surrounded by large quantities of "how".
The whole enhanced collections is another good example of this, from my perspective, with internal iterators and lambdas being seriously good stuff.
My Java (and Groovy) functional fu is still pretty rudimentary. For example, if I have an input file where each line contains several different key-value pairs to be loaded into several different maps, I know of no way to process that only once and deliver all maps as a functional result. Maybe it's there, and I just haven't yet seen it; but in Groovy, where I tend to do most of this kind of stuff, I find myself declaring all the maps and then using an "each" to iterate through the file, assigning map1[key1] = value1, map2[key2] = value2, etc as I go.
100% in agreement on the spending time on design concept. I find these days that an alternative to whiteboarding is to prototype with Groovy. I'm not a terribly visual person, so the lack of diagrams doesn't perturb me. I might make several prototypes before I settle on one that seems to be headed in a good direction; and I often use the prototyping as an excuse to test relative performance, too. Same story when SQL is involved. But I suspect this all may be more of an indicator as to what works with the kinds of problems I find myself solving, rather than a general rule.
Anyway, thanks again for your thoughtful comment.
Thanks for the comment, Riccardo. Strong static typing is a big win in Java as far as my experience is concerned. I agree that we differ on preferring terse versus verbose syntax, and to each her/his own, I say.
The other thing that makes a huge difference for me is all the good stuff that comes with Java. For example, back in "the good old Pascal days" where I had severely limited memory available, I would build accumulators based on code values by having an intermediate lookup array that converted a code value (say in the range 1-500) to an "occurrence index" (say in the range 1-25). That occurrence index would be used to index into an array of pointers to heap structures to accumulate. Of course this type of structure was prone to carelessly using a code value instead of index of code value to lookup in the array of pointers, which would bring on all sorts of hard to track bugs.
Awk's associative arrays, and later Java's full set of HashMaps, got around this kind of problem entirely. Of course by then my memory restrictions weren't nearly as problematic, either. And the combo of things like HashMap with the type checking provide by generics was a further boon to detecting errors at compile time.
So, not really being familiar with what kind of "batteries" Ada brings, I don't know for sure that we're quite on the same page! But anyway, again thanks for writing, and I invite you to consider writing an ariticle "Why I use Ada" for opensource.com!