Windows Programming Languages going forward

[Richardk]

Now with Windows 8 around the corner and things constantly changing, what's a "good" programming language going forward?

Months ago the talk was .Net is dead and Javascript / HTML 5 - full steam ahead.

Is anyone close to this environment to update us on how things are shaping up? Last I heard, write for Win 7 and everything will work just fine on Win 8, though you'll probably not take full advantage of what's available.

[The Gorn]

I've given up trying to stay current with this sh*t.

For me it's web interfaces all the way. That's universal and that is not going away anytime soon.

[I D Shukhov]

Now with Windows 8 around the corner and things constantly changing, what's a "good" programming language going forward?

Months ago the talk was .Net is dead and Javascript / HTML 5 - full steam ahead.

Is anyone close to this environment to update us on how things are shaping up? Last I heard, write for Win 7 and everything will work just fine on Win 8, though you'll probably not take full advantage of what's available.

Java EE frameworks for enterprise development are a safe bet.   JavaScript frameworks/libraries and HTML5 would be fine.   In general, I think frameworks and domain skills (as always) are the important things to be focusing on rather than languages.   

I'm listening to http://www.amazon.com/Super-Crunchers-Thinking-Numbers-Smart/dp/0553805401 on my way to work.   Data analytics  would be a good specialty.




     

[Richardk]

That's about how I feel. It's more about having one relevant tool going forward rather than keeping up.

Also web interfaces is one thing but I'm still on the fence about this whole cloud thing. Maybe I remember internal networks going down and translate that to the web but at the same time I get my power off the grid instead of running my own generator.

I don't know, is it the same thing? I don't think so. I can always run out and get any generator available but with the cloud, my "stuff" is all in one place. How many companies have a "Plan B" that they can quickly implement if their service goes 'poof'? Ah, sorry for the tangent.

[TRexx]

I don't know, is it the same thing? I don't think so. I can always run out and get any generator available but with the cloud, my "stuff" is all in one place. How many companies have a "Plan B" that they can quickly implement if their service goes 'poof'? Ah, sorry for the tangent.

I've been involved in disaster recover aka "contingency planning" for a long time and the answer is "very few".   The reason is that it is incredibly expensive to do properly.  Few C levels are willing to spend huge amounts of money on resources that they will probably never use.

[DG9]

DR is pretty cool though, I used to work for a big bank as an fte back in the day (as the old man says) and when we would do DR tests at the super secret DR site it was quite the big deal.  I got into it at the time.  With the more casual, good enough, dispoable attitudes I see around these days I am guessing standards are much lower.

Man I sound like an old curmudgeon!  Better go eat bran muffin...

[Richardk]

With the more casual, good enough, dispoable attitudes I see around these days I am guessing standards are much lower.

I'm thinking and wondering the same thing. Even with the cloud aside, past companies would fly a team out with backup tapes to some site and see how long it would take them to get back up and running. Do they still spend that kind of money?

And what about a cloud service? It's much cheaper to write into the fine print "oops!" instead of having a backup site. And when they do, I wonder how often it's tested, is it verifiable and what happens if they miss their target or fail altogether? Also, is it the same performance?

And what if the service provider is fine but something breaks in the middle? One client lost access when someone planting trees cut a cable.

All of these issues that might be "good enough" yet if we don't have X then we're not qualified. Go figure.

[The Gorn]

Learn whatever you see being used on your client's or employer's site in the next 12-18 months. Otherwise, learn enough to fake it convincingly.

Otherwise the investment is just a speculation.

Development has fragmented so much in so many different directions that putting all of your eggs in one basket is a sucker's game today.

IE: back in the early 90s I learned Windows API development in the early 90s and that provided significant traction to obtain about 1/2 dozen very small contract projects and many independent projects that sustained me through 2010. I learned VB as a self study thing around 1994, and that provided some work for a couple of years.

I cannot see just one development platform being a strong enough platform alone to get you new work. In other words, the worst thing (biggest waste of time and effort)  I believe you can do today is to obey the development evangelist gurus and worship at the altar of HTML 5 (or any other single technology.)

I think a developer today has to be associated with a "sector", like mobile or Web Ajax development. And become a well performing bullshit artist at supposedly knowing all about whatever the client du jour quizzes him on in interviews.

[Richardk]

I cannot see just one development platform being a strong enough platform alone to get you new work. In other words, the worst thing (biggest waste of time and effort)  I believe you can do today is to obey the development evangelist gurus and worship at the altar of HTML 5 (or any other single technology.)

Agreed. This isn't for employability purposes but rather to have one current and relevant language that 'could' be used even if it's "the wrong one" in the client's eyes. And needs are many so it's more likely to be a handful of languages.

This is starting to sound like I'm building a toolkit and maybe that's what I'm asking? Today it wouldn't include things like Ada, Cobol and FORTRAN but what would be the must haves'?

I think a developer today has to be associated with a "sector", like mobile or Web Ajax development. And become a well performing bullshit artist at supposedly knowing all about whatever the client du jour quizzes him on in interviews.

This is probably the better approach since there will always be something 'missing' in the client's eyes.

[The Gorn]

This is probably the better approach since there will always be something 'missing' in the client's eyes.

The cultural fit with the position is the single most important aspect to being seriously considered.

If you're interviewing with a bunch of social media based smartasses who don't do any hard work, you need to come off like a non serious social media douche, then you're golden. A serious more mature IT person will look like a grumpy old man to those infants.

It has nothing to do with specific knowledge or deep knowledge, even though that's always what hiring organizations claim. It has to do with the appearance of taking the local culture seriously and fitting in. Not being intimidating or clashing.

Being too mature clashes in many cases today.

Cynical? Me? Never.... 

[choppedwood]

A friend of mine believes that you should learn a new language every year.  I'm not talking about "mastering" it, rather knowing just enough to get by on an interview.

Anyways, without giving specific advice I'd go to indeed.com and do a general search in my preferred geography.  Indeed also has a tool that graphs demand over time.  I suspect it's a pretty simple analysis but it gets the idea across.

Whatever you pick it won't be one thing.

[David Randolph]

Now with Windows 8 around the corner and things constantly changing, what's a "good" programming language going forward?

Months ago the talk was .Net is dead and Javascript / HTML 5 - full steam ahead.

Is anyone close to this environment to update us on how things are shaping up? Last I heard, write for Win 7 and everything will work just fine on Win 8, though you'll probably not take full advantage of what's available.

This really depends on where your code will be residing. If you are talking about server code, I suspect that .NET will have a long life. If you are talking about client code, .NET never made it out of the gate. That has always been HTML / Javascript. If you are talking about local applications, that depends on which platform you want to deal with.

From a business point of view, the question isn't which language, but what process do you want to have done. When I talk to businesses, they do not care which platform; they want to work with them all. (So, you want your application to run on all credit card platforms and all cell phones. That would be $100,000 development for the credit card platforms and another $60,000 for the cell phones. Is that in your budget?)

[The Gorn]

From a business point of view, the question isn't which language, but what process do you want to have done. When I talk to businesses, they do not care which platform; they want to work with them all. (So, you want your application to run on all credit card platforms and all cell phones. That would be $100,000 development for the credit card platforms and another $60,000 for the cell phones. Is that in your budget?)

Well, you don't let that stupid a discussion even take place. As soon as you tell the average business person what could potentially be available, they want it all, but they can't pay for it, but they will stall their decision making until they get it all, at very low cost. Which means that such a discussion kills any deal. So, again, that discussion should not take place.

So you pick a lowest common denominator platform and you run with that. And you can explain how your choice works on virtually everything, so the business person is not out any potential opportunities.

For example, web sites work really well on smartphones once you have designed the site for dual use on mobile browsers and desktops. Javascript and HTML can be relied upon to be found everywhere.

With technology, you definitely have to control the conversation, or business does not take place. The client will often take the conversation to unproductive black holes because they don't know any better, or, for God knows what reason.

Allowing the client to disqualify you because you don't span the globe with your solutions is a common error. It may happen anyway, but don't feed it.