Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment It depends! (Score 1) 466

For me, having invested immensely more in Clojure than other languages (I think that's an anomaly), it's faster for me to write Clojure than anything else going forward. I've been having a lot of fun using the same knowledge on multiple platforms, be it JVM-Clojure or JS with Clojurescript. I've also used python and ruby (and PHP), but I'm finding that node.js is a lot of fun, and npm is a coherent package manager. If you're just starting out, I recommend doing Javascript + Node for max bang for your time-buck. You'll get your backend and frontend at the same time, and it's quite a fast runtime. Javascript itself has some thorny edges, but it's a relatively simple language compared to the others you're considering.

Submission + - Your Car Will Soon Sense If You're Tired Or Not Paying Attention

cartechboy writes: Distracted driving is a large issue, and it's getting worse as we become more entangled with our technology. To help combat this growing problem Volvo is showing off new technology that allows the car to sense when a driver is tired or not paying attention. The system bathes the driver in infrared light that can pick up the driver's position and eye movements. If the driver becomes inattentive or begins to drift off to sleep, it will alert you. Besides the safety aspect of this system, it will also be able to recognize the person sitting behind the wheel, allowing the car to tailor itself to that person's stored preferences. Further, it will be able to adjust the vehicle's exterior lighting in the direction the driver is looking based on the detected eye movement. Volvo's quick to note the system can't photograph the driver. People, the future is coming, and your vehicle is going to be watching you.

Comment still young (Score 1) 306

I'm 4 years experienced, I still remember when I had 0 years experience.

The difference between then and now is a few things:

  1. 1. I actually, objectively, learn faster, I have more experience, more techniques at my disposal, and fast paths in my brain to do so.
  2. 2. The discomfort of not knowing something is much more pronounced relative to my usual competency.

When I was just starting out, the relative cost of #2 was the same for a number of topics.

Once you are an expert in one, working through feeling dumb all the time I imagine is much more frustrating.

What worked for me and the best advice I could possibly give is to identify the smartest programming writers and speakers that are doing what you want to do, read their books, watch their talks, and embody their viewpoints of code.

In the course of a few years of this you will gain a foundation whose benefits become more apparent over time.

Dealing with the perceived discomfort from #2, I'm not sure as I'm super-crabby and still young, but the most up-to-date and fresh experienced developers I've had the pleasure to work with embody a childlike curiosity.

#2 can be mitigated

#1 is a little more biological

I think #2 and related perceived tradeoffs dominate the learning equilibrium.

Submission + - Strongest evidence yet of two distinct human cognitive systems (

Maria_Celeste writes: New research appears to demonstrate that humans use two distinguishable systems to categorize the objects in their world. They've termed these systems explicit and implicit. Lead author J. David Smith, Ph.D. (University of Buffalo) explains the difference this way in Science Daily. When you select a cereal named 'Chocoholic' from the store shelf, consider why you are doing so. Is it a deliberate, explicit choice, or is it possibly an implicit-procedural chocolate reaction, one triggered by processes, memories and so on, of which you are generally unaware? The paper appears in the the journal Psychological Science.

Submission + - The End of Moore's Law, one more time (

GLMDesigns writes: At the SPIE Advanced Lithography conference at the end of February, a group of lithography engineers — men and women who have spent their careers pushing the boundaries of Moore’s law — toasted its death.

Comment Software (Score 1) 401

Take your EE background and rigor, and get a career in software. You'll have an edge over the hipsters and will find it easy to rise.


BS Biomedical Engineering from Georgia Tech.

MS Electrical and Computer Engineering from Georgia Tech

Some of the most talented programmers I work with are EE or physics guys.

Comment Re: PHP 6.0 without the stupid? (Score 1) 219

yea, I don't really miss the 'one right way to do anything' attitude. I wouldn't really say python's a paradigm, it's sort of just a highly-opinionated and dynamic OO language and community. Ruby tries to be friendlier, but I don't use that either. The whitespace thing.. I guess it can be inconvenient. I just always use spaces. I have felt the pain (in java) of badly formatted and mixed-formatted code being weird in different editors, but I use a lisp full-time now, which means I'm willing to trudge through syntax unfamiliarity for the sake of some benefits. I prefer the regularity, though you can't control how other people format their code or what editors they use. If it's code that I'm working on, I make sure it's indented properly.

Comment Re:PHP 6.0 without the stupid? (Score 1) 219

You can redefine the functions w/ your own.

This is a road fraught with peril, likely because the people that implemented the original functions are the same ones that made crappy language choices that prevent new functions from being used effectively, so it's possible to both paper over issues, conveniently in the short term, and simultaneously creating more issues in the long-term.

Comment Re: PHP 6.0 without the stupid? (Score 1) 219

Hate for python whitespace is a sure sign of a superficial appreciation for its tradeoffs. It doesn't say anything bad about the language, it just shows you haven't actually used it for anything and are willing to make egregious statements based on unfamiliarity and ignorance. Why learn a language if it's not a bit unfamiliar in the first place? (disclaimer, haven't used python since 2010)

Comment Re:Build it and run it (Score 1) 254

Maybe you're a good coder, but this would not be advice I'd give anyone except the most elite folks, who don't need it. I personally prefer to spend extra up-front time to learn a system and would advise anyone I work with to do the same. How do you know when things might interact when you don't know the premises of the system? You would have to rely on someone else to provide negative feedback. The approach seems a little flippant, but the details of how you implement it might make it work.

Comment a systematic approach (Score 1) 254

I've always been a little ADD and impatient with having to do things systematically, unfortunately I found this is the only approach that works for me. If I don't do this, I end up staring at the screen for long periods of time and not getting anywhere. So, I wrote up a worksheet to help myself in these situations, here are the steps I identified as helpful to deal with massive levels of complexity in unfamiliar code:

1. Establish a clear goal and sub-goals.
2. Use the goals to determine the scope of your reading.
3. Allocate quite a bit of time in large chunks.
4. Identify key layers of abstraction.
5. Enumerate classes (functions, namespaces) of interest.
6. Systematically, read through each class superficially.
7. Pick 8 classes to focus on.
8. Do a deep dive.
9. List/sketch inputs and outputs in terms of function names, types referenced.
10. Look at relevant tests for usage as needed.
11. Check off each class once looked through.
12. Measure the complexity of a component by how many checks are required for full understanding.
13. Iterate until goals achieved.

Slashdot Top Deals

Thus mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true. -- Bertrand Russell