Slashdot Log In
Staying On-Top of Programming Trends?
Posted by
Cliff
on Thu Jun 15, 2006 09:25 PM
from the never-obsolete-yourself dept.
from the never-obsolete-yourself dept.
GhettoPeanut asks: "Trends are constantly changing, upgrading, or become popular due to high end user demand or just basic usefulness. I do my best to keep up with the trends, believing that for the most part they will be better then the current methods in place, or just comfort in knowing that if enough people use it, that there will be allot of help out there. Ultimately though, its keeping up with these trends and trying to figure out what's a fad versus what's actually useful that's the difficult part. What do some of you do to keep up with the trends? Websites? Magazines such as Dr. Dobbs? Forums? I know there's not one solve all, but for the sake of argument, suppose you wanted to stay on the forefront of Java based web development, what would you do?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Well... (Score:2, Funny)
Four things: (Score:5, Informative)
2. The plethora of content Sun, Java, MySQL, Microsoft, Oracle, and many other high-profile "framework sponsors" push out on various developer networks, such as MSDN, DevZone, OTN...
3. Whatever the hell O'Reilly is making books about.
4. Seminars and conventions, often made/endorsed/branded by computer publishers such as O'Reilly and aforementioned "framework sponsors".
Recommendation: (Score:5, Funny)
Ignore them... (Score:5, Insightful)
Re:Ignore them... (Score:4, Interesting)
See, here's a problem. Most CS instructors will cram down students' throats that if they concentrate on principles they can pick up any language/platform as if it's nothing at all. It's a lie, but that's what they say. This is where this "Ask Slashdot" is coming from--an idealized mindset leading to severe programming attention deficit disorder.
When I was a programmer full time, I tried to ignore the covers of magazines, knowing that it's just hyped up B.S. However, my co-workers would be drooling over whatever Java database framework was released that week (everyone and their uncle was writing Java frameworks!!!) and end up with some twisted mess of undocumented APIs and un-debuggable problems. It was awful. Couple that with high turnover and whole projects would just get flushed and re-done from scratch (again, done badly...perhaps they found a real money tree and didn't tell us?).
Oh, and trash the UML! Simultaneously with writing terrible software, everyone was on some sort of UML pilgramage to Software Engineer Paradise somewhere. Barf!
I would have been in programmer heaven to just do it all in C and
Parent
Re:Ignore them... (Score:4, Informative)
Actually, it's not a lie. I'm a CS undergrad at GA Tech, and from classes I have experience in Scheme, Java, C (with UNIX), and Smalltalk. Anyway, I got a job this summer programming in a C++ .NET and ObjectARX [autodesk.com] environment using Visual Studio, even though I had absolutely zero prior experience with any of it.
Long story short, it took me about a week to figure it all out. It was cake.
They're planning to migrate their whole program to C# soon; I figure learning that language will take me about a day and a half.
Parent
Mastering it will take a lot longer (Score:5, Interesting)
True, C# isn't a hard language to learn. I find it a little disjointed as I'm primarily a Java guy, but it's simple to understand.
The problem with C#, or indeed Java, is that the API and associated frameworks do so much for you, but take a long time to master. Some of my early Java code is needlessly verbose because i simply didn't know that the API made certain functionality available. Now that i'm competant in a small number of frameworks and have better learned the development tools, i find i can work a lot faster.
It doesn't take long before you become so used to the framework that programming in C or asm seems like reinventing the wheel.
Parent
Re:Ignore them... (Score:4, Insightful)
And contains tons of stuff which is meaningless to memorize.
"I say now, as I said then, that a man should keep his little brain-attic stocked with all the furniture that he is likely to use, and the rest he can put away in the lumber-room of his library, where he can get it if he wants it. --Sherlock Holmes
Parent
Re:Ignore them... (Score:2)
I had a database class that the teacher wanted picture perfect examples as homework. In other words, "Write this query, have it print out the output, and hand in a screenshot with your query"
I tried to explain that if it was in the book, then someone already knew how to do it, and therefore my time was being wasted, but unfortunately, that didn't go over so well.
Now, I have no degree, but I do have a fairly decent job NOT reinventing the wheel.
Re:Ignore them... (Score:2)
I tried to explain that if it was in the book, then someone already knew how to do it, and therefore my time was being wasted, but unfortunately, that didn't go over so well.
It's a class - of course somebody's already done it. Unless you're in a special topics course or dealing with actual research, then it's probably prepackaged. I can't really explain the screenshot nonsense, save to wonder if that's an anti cheating tactic.
Re:Ignore them... (Score:5, Funny)
Now, I have no school education, but I do have a fairly decent job NOT reinventing the wheel.
Parent
Re:Ignore them... (Score:4, Interesting)
In my Undergraduate Physics course (My first degree) my calculator broke just before class one day. Half way through the class the guy sitting next to me realised that I was only six questions into the problems we were doing when he was on question twelve. This is because I was doing all of the long divisions (six plus digit numbers) by hand while he was using a calculator. He was surpirsed that anyone could even do that...
Z,
Parent
Re:Ignore them... (Score:3, Insightful)
Re:Ignore them... (Score:4, Insightful)
While you make some good points, you also have a couple of mistakes there. First of all, it's been quite a while since any of Stroustrop's books was really the C++ spec. Anymore, the spec. is the 2003 edition of the C++ standard (aka ISO 14882), and before that it was the 1998 edition of the same. Oh, and FWIW, while it's certainly densely written, it's less than 800 pages long. :-)
That's a direct contrast to, for example, the Boost Library [boost.org] or the Loki Library [sourceforge.net], which are a lot smaller, but a whole lot deeper. Here much of mastery is simply wrapping your head around some of the concepts involved. A few people accustomed to Lisp, Scheme, Ocaml, etc., may already be accustomed to some of them, but most typical programmer have never even considered doing the kinds of things it covers (and even the Lisp crowd is likely to find a fair amount of it somewhat challenging as well).
To put that contrast a bit differently: if you were accustomed to Java (for example), using .NET would mostly mean learning different names for classes and member functions, but the classes and member functions would still be on the same order as you were used to (a bit cleaner in some places, a bit grungier in others, but ultimately the same general kind of thing). By constrast, either Boost or Loki is much more likely to cause fundamental alterations in how you think about and solve your problems.
Parent
Re:Ignore them... (Score:2)
I guess in my mind they don't contradict. My main complaint about the message given by the instructors is that it tends to trivialize the extent of learning a new language. It isn't just syntax and program flow, but standard libraries, other libraries, nuances of the OS, compiler, and other tools, holes in documentation, varying vendor support, etc. There is no way to just jump from one language to another, IMO, and maintain the same leve
Re:Ignore them... (Score:2)
That is a problem to a programmer? In any case, UML is hardly that complicated. All it takes to obtain a basic understanding of class diagrams, for example, is a couple of hours reading "UML Distilled" or various sources freely available via Google. Having a simple (yes, simple), graphical way to explain objects and relationships is well worth the investment. It's like design patterns. Sure, you don't need to know them, but it sure makes things a lot simpler when you do.
Mono? (Score:5, Informative)
8^p
Re:Mono? (Score:2)
And aside from the evil overtones, it's a fantastic language. Come to the dark side.
----
Besides, Darth Vader can kill people across the galaxies on a viewscreen with a motion of his han
Read and Succeed (Score:5, Insightful)
Read
First, you need to read a lot. Dr Dobbs, MSDN, developer blogs, books. To separate fad from rad, I recommend you use your own common sense.
For example, a few years back I worked hard to learn and understand the Unified Process. There were a lot of great ideas in there, but I felt it was too heavyweight and over the top for what I was doing. But I did feel it had brilliant ideas and revolutionary concepts. So I took what I thought were the most practical ideas and used them. The most important ideas I took were things like 1) throwing out the waterfall approach and developing iteratively, testing and "releasing" after each iteration, 2) identifying the biggest show-stopper risks up front and doing research to make them not so scary, 3) getting the customer/end user involved up front and through the whole process. A lot of people might shoot me for saying this, but it turns out that the Unified Process was pretty much a fad, and those key concepts turn out to be the foundation for "Agile Development" and "Extreme Programming."
The point is, read and study anything that interests you, and decide for yourself what's useful.
Succeed
Second, you need to do stuff to get success stories you can tell when you're interviewing or selling yourself to your current employer. A lot of book knowledge doesn't do diddley if you don't put things in the done basket. Ever see people at work with dozens of spiffy certifications that can't code their way out of a paper bag? Don't be like that. Do lots of stuff and do it successfully.
I recommend you work on anything you have some passion for, even if it's not directly work related. For example, I did a lot of 3D programming when I was working as an Oracle PL/SQL developer. Totally unrelated to work. But I honed my OO skills, learned OpenGL and DirectX, learned a lot about 3D math. Although it took a while to pay off, all of it did eventually pay off. Knowledge of C++ helped me answer tricky STL interview questions, and I later got a job with a company that makes interactive 3D training software for jet mechanics-- way cooler than Oracle. And even though this wasn't work-related, I was able to include that work in my list of success stories I could tell potential employers and other people making decisions about me.
So do whatever you have a passion for, and do it successfully and to completion.
Re:Read and Succeed (Score:2)
But I did feel it had brilliant ideas and revolutionary concepts.
Those aren't revolutionary - they're basic project management and some real world development mixed together. Nobody uses waterfall. Identifying risks is a basic part of requirements analysis, and talking to customers (and identifying them at all) is necessary so you have a chance at success. Who cares if your code works if nobody wants it.
Re:Read and Succeed (Score:2)
Absolutely.
I've met plenty of both types of people. Its clear which people love to code and which people just consider it a job. When you love to code, you make time for reading programming books, having pet open source projects, getting into silly programming conversations on slashdot...
My advice is that if you don't love programming, find a different occupation.
Re:Read and Succeed (Score:3, Insightful)
There are those of us who really do like what we do, but still consider it a job and want to do other things besides on our free time.
Pick a language (Score:2, Informative)
Immerse yourself in RSS feeds (Score:4, Insightful)
The key is that that it's really quantity and regularity that's most important- If you spend a little time each day immersing yourself in the terminology you'll start to get a feeling of who has the most credible opinions in that field and what those persons are excited about (so eventually you'll have quality covered as well).
There's a good chance that this will, of time, allow you to spot patterns and predict technology trends.
Trends? Um, no... (Score:4, Informative)
Slashdot (Score:4, Informative)
Also, as others will say ad infinitum, focusing on the basics is much more important than trying new fads or styles.
Don't limit yourself to Java (Score:5, Insightful)
Several of my coworkers attended JavaOne, and while I would have liked to have gone, I'm much happier going to Agile 2006 where I will get exposed to a wider variety of things going on. For example, if you haven't tried Rails, it is a great way of seeing how using sensible defaults can get something up and running quickly, and how extension can keep it maintainable as it grows.
Same thing with ASP.NET. The event model for web pages is really great, and I've built some neat apps in ASP.NET which let me use some of the cleanest MVP seperation possible.
So, if you want to know more about Java, pick up some other languages. You'll find yourself wanting to do even more.
Re:Don't limit yourself to Java (Score:2)
It's not about the language any more (Score:2)
And it's so unrewarding, because you're expected to work around the flaws in the libraries. I miss aerospace, where, when a vendor doesn;t meet specification, the contracts people pound on the vendor until it's fixed.
Re:Don't limit yourself to Java (Score:2)
- you get to know a lot of different programming paradims, ways of solving problems, that would be completely lost to you, if you stick to just one language. The least it does is to give you an understanding, when someone tries to explicitely implement one of those paradigms in a language that isn't meant for it (because the problem requires it). Tremendo
learn fundamentals (Score:4, Interesting)
Like: LISP, the relational model, etc.
Then after a while you'll notice that most everything is a subset of something that's already been invented, but with a different name, or a different syntax, or a different "marketing angle".
Ruby? Python? Different subsets of Lisp with more interesting syntax.
Ajax? A more complicated way of doing client/server communication.
SQL databases? Kinda like a relational database, but simpler.
Object databases? Take the relational model and add a large number of constraints, tada, there's an OO database.
FreeBSD vs. Linux? Mostly the same.
You might also become quite bitter and annoyed with the IT industry after a few years.. try not to take it out on others.
But seriously, concentrate more on what make things ALIKE. Vendors and people who haven't been in the IT industry very long will try and convince you that what they have is revolutionary and exciting, etc. They'll try and ridicule your "old-fashioned" view of whatever it is. Just smile politely and try and apply your existing knowledge with the syntax or the pretty face of "their" technology.
Ignore it. (Score:5, Insightful)
Shoot myself.
More seriously, trying to stay up to date on every new trend is pointless. You're better off picking a few things and learning them well.
Re:Ignore it. (Score:4, Interesting)
Seconded. When I was in high school I took whatever programming classes I could get into. I started with Basic and moved on to Pascal. That gave me some good fundamentals to work with. When I entered the work-force, I found myself scripting quite a bit for Lightwave. (For the uninitiated: Lightwave is a 3D program commonly used in television effects.) Recently we've been using Maya a lot more. I was able to shift over and start writing scripts for it. Why? Lightwave scripting gave me the experience I needed to know what I'm looking for, so when it came time to use another language, I had what I needed to get going fairly quickly. This has even spilled over into writing a little bit of PHP code and so on.
I took the scenic route here, but yeah, develop a solid skill, and when you need to move into another language it'll go pretty smoothly. I was involved in the process of hiring engineers and we had a number of applicants who were dabblers. "I know OpenGL!" "Great! What have you done with it?" "I made a box rotate on the screen! (It was really hard!)" "Okay, so what's your expertise?" "..." We didn't feel comfortable hiring those people because we had no idea where they would have been best suited. Jack of all trades, master of none, yadda yadda yadda.
Parent
Be good at what will always be needed. (Score:4, Insightful)
I know Java very well, but my true strength is in design. It doesn't matter what languages come and go, those skills will always be useful.
Learn good communication skills [toastmasters.org] so others will think you are competent. Even if you aren't.
Learn persuasion skills so you get good compensation.
Prepare side interests that you can ramp up into money-making ventures in a few months. If your company folds, you get laid off, or you decide to retire (or just plain quit) and the job market sucks, you at least have an avenue to pursue.
Re:Be good at what will always be needed. (Score:3, Insightful)
And, remember, writing is communication. In fact, it's a form of communication that lingers on long after you've forgotten about it, making you look smart or stupid, as the case may be, the whole time.
My point here, of course, is that the submitter's summary is chock-full of screwups.
GhettoPeanut, please: the language you should be working on is not Java or Ruby or SuperDuperCPlusPlusPlus. It's English.
A blend of sites. (Score:3, Insightful)
I find that I generally have a good idea what's going on by frequenting
Bottom line is, to use your example, if you were looking for what was going down on cutting-edge Java, you would simply spend a good portion of your time researching Java. But the point I'm trying to shoehorn in here is that to stay on edge, you have to be on edge. Which means investing time and researching and *actually* knowing what's going on. Otherwise you'll remain a tool to the hype-machines that have felled so many good programmers / managers.
Sorry... I wish I could give you the "visit site X" answer that you're looking for. I really do.
Look at C++/CLI (Score:2, Informative)
In a nutshell... (Score:5, Funny)
2) You will only ever need to know Java, Ruby or Python to make it as a Web Programmer.
3) RoR is teh hawt. On the Java side, knowing Spring, Hibernate, struts, jUnit, JSF and (hold your nose) Beans will get you far. Python? HA!
4) Python was in, now it's on its way out. Python geeks can keep the perl geeks warm when it snows. Take comfort, the Ruby guys will be there to huddle up with you in five years. PHP guys don't get paid, but will be wanted by people who don't like to pay programmers.
5) C++. How quaint. You must have come from the game programming field. Perhaps you should go back there? We sure as hell don't want you. Go and keep the LISP guy company at the geezer end of the bar.
SoupTellsItLikeIt Is
Re:In a nutshell... (Score:3, Interesting)
Perl had a killer head-start because in 1996 nobody did CGI like Perl did CGI. But Perl is s system glue language. It's a mighty system glue language, and there will always be work for Perl gurus, since all those custom scripts holding the infrastructure of every Unix shop on earth together are always going to need maintanence an
C/C++ (Score:3, Insightful)
What it really comes down to is knowing your data structures, knowing how much memory you're using, knowing how brutal your algorithms are, knowing the time to add/remove/find elements in your structures, and once you know C/C++, everything is a cakewalk. Seriously. Jesus I still wish I was doing web programming, where wasting massive cpu was okay. Learn C/C++ and find a job where you need to keep things speedy like games or web servers that need to deliver massive amounts of requests per second. Spend 2 years doing that, and you'll need and know everything you need to know for a career in programming.
Re:C/C++ (Score:4, Interesting)
bloatware that is used to run web apps these days (Hello IBM , are you listening?) and
not necessarily the coders themselves. Though IMO web programming is a bad place to
learn how to code , even java , since you don't have to worry about memory management
etc you can program somewhat sloppier than if you had to do C or C++.
In fact I'd go so far as to suggest that ALL coders should do at least a few months
of C (not C++) or even assembler coding so they get a real feel of what really goes on
with memory, cpu, interrupts etc and so a better feel of how a computer really works.
Parent
Java Posse (Score:4, Informative)
To keep up with what's happening in the Java world, I'd recommend listening to the excellent Java Posse podcast [slashdot.org] and as well as reading The Server Side [serverside.com].
User Demands? (Score:3, Insightful)
Trends are constantly changing, upgrading, or become popular due to high end user demand
Why the hell should users care what language their stuff is written in? They're USERS!
books (Score:3, Informative)
Devon
No tricks, just consistent hard work. (Score:5, Informative)
2. Don't just concentrate on technologies. Study Project Management, Emotional
Maturity, Presentation skills and public speaking. Think of yourself as an
investment, you want to hedge your down-side by making sure you have skills
completely outside the particular situation you are in at any given time.
3. Review yourself every 6 months or so. Are you stuck in a learning rut, continuing to
read the same types of junky "Visual Basic in 21 nanoseconds" or are you actually
challenging yourself?
4. Review the basics every so often. Go back and read a deep book on analysis of
algorithms or databases or language design.
5. Try to push yourself out of your comfort zone every few years.
6. Don't get too hung-up on the buzz-word du jure. 90% of them will last a millisecond
in your career.
7. Treat everyone you come into contact with as a teacher.
Programming trends (Score:5, Informative)
Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.
My advice: read Lambda the Ultimate [lambda-the-ultimate.org] and Steve Yegge's blog [blogspot.com]. Endeavor to learn what the lambda calculus [wikipedia.org] and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church [wikipedia.org] was then so help me God I will kick you in the balls. Learn about SML [smlnj.org] and type inference [wikipedia.org]. Learn about Haskell [haskell.org] and monads [nomaware.com]. Learn about process calculi [wikipedia.org] and Erlang [erlang.org]. Learn about Lisp [wikipedia.org] and code generation [codegeneration.net] and domain-specific languages [martinfowler.com]. Learn about Scheme [mit.edu] and lexical closures [wikipedia.org] and continuations [wikipedia.org]. Learn about Smalltalk [squeak.org] and what OO was really supposed to be [wikiquote.org]. Learn about type theory [lambda-the-ultimate.org] and formalism and the Curry-Howard correspondence [wikipedia.org]. Learn about Forth [forth.org] and Joy [latrobe.edu.au] and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal [catb.org] and Befunge [wikipedia.org] and just how badly your choice of programming language can torture you. Learn about UML [uml.org] and Ruby on Rails [rubyonrails.org] and Seaside [seaside.st] and agile programming [wikipedia.org] and Java generics [angelikalanger.com] and Python generators [python.org]. Learn about aspect-oriented programming [aosd.net], context-oriented programming [common-lisp.net] and concept programming [sf.net]. Learn about multi-paradigm languages like OCaml [inria.fr] or Oz [mozart-oz.org]. Learn about weird Lisp dialects with syntax like Rebol [rebol.com] or Dylan [opendylan.org].
Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc
Don't Follow (Score:3, Insightful)
Boring anecdote: I am glad that I fended off the EJB hype. Now, most of the industry has realized what I suspected all along - EJBs are mostly useless and usually create more problems than they solve. About 5 years ago I had a technical manager that insisted we use EJBs for all our new development. I resisted the best I could. One engineer on the team even proved that for database access, the EJBs were 10x slower. The manager didn't seem to care. We ended up putting in enough EJBs to satiate his mandate, but mostly avoided them like the plague. EJB == Extra Java Bloat
Re:lol, java (Score:2, Funny)
1998 called, and they want their troll back.
Read Slashdot (Score:5, Insightful)
Yes. Slashdot has quite a reputation for attracting knowledgeable people, yet be aware that some are rather biased towards OpenSource. And don't forget that people who do OpenSource (me including) have a rather absolute opinion. So as long as you are a little sceptic you should be able extract the trends.
As you mention Java you may well notice that currently any Java discussion always tends toward flame wars. Flame wars are always signs that something isn't good, that the there isn't an uphill trend. Flame wars always arises when the future (a trend) isn't going as wished.
I'm probably much biased but IMO the future trend in software development is "cross-platform". So far for many years you could do resonable cross-platform development only with Java. Today you can equally well do cross-plaform development with AJAX or with wyoGuide (binary applications, http://wyoguide.sf.net/ [sf.net]). So regardless which of the different technology takes the lead, cross-platform development will increase to the point where single-platform development won't be accepted.
O. Wyss
Parent
Re:Read Slashdot (Score:3, Insightful)
Ok, so call me an un-trendy old-fart. Let's see ..... a quick review of my resume since
1980, when I first became a programmer .....
I wrote my first Fortran program in 1974 and it work fine on an IBM computer and a few years later on a Digital PDP-11. Albeit it was my first cross-platform code, there's no way to sell it these days.
Languages were never the problem and even for the same task several different