Become a fan of Slashdot on Facebook


Forgot your password?

Comment Re:Missing the point (Score 1) 188

You call that "cloud", the rest of us call that a data center. The only part that has changed is the marketing.

You can't see the forest for the trees.

Lots has changed besides marketing: visualization, elasticity, transparency, etc.

Taken alone, no single factor is revolutionary... it's all evolutionary improvements of time-tested concepts. Put them all together at a never-before seen price point and the effect is revolutionary. The whole is more than the sum of it's parts.

Comment Re:Naive, because most investors (especially VCs). (Score 1) 438

If you're going to start out our relationship with crap like that, why should I bother?

Because that's how the game is played. You don't get dealt into the game until you ante up.

Again, where is the consideration for me?

The consideration is that you're being invited to play with the big boys. Either make a show of good faith and get dealt in or go away and play with yourself.

Comment Re:FORTRAN? (Score 2) 204

The problem is that "modern computer langauges" are designed by PhD's in computer science who know what they learned in grad school, which is heavy on the "delegates? Anonymous functions? Closures? Reflection" axis of desiderata and pffs away questions of fast numerical support with "link to C"---mostly because something like that wouldn't be seen as New And Cool by tenure committees.

Citation needed. Looking at the modern language landscape, what I see is are languages that were:
a) created by lone hackers looking to scratch a personal itch (EG: Perl, Ruby)
b) created internally by a corporation to solve an otherwise intractable engineering problem (EG: C, Erlang)
c) created by corporations looking to sell developer seats and/or create vendor lock-in (EG: Java, Visual *, *.net)

Languages designed primarily as academic exercises / thesis projects have historically had very small user bases outside of academia, with a few exceptions.

Anonymous functions, closures, reflection, etc are not esoteric Ivory Tower language features that are important because they're "cool" -- they're important because they're essential for efficient metaprogramming and higher order programming.

Comment Re:That's the point (Score 1) 269

Too many CIO get bogged down into detail they shouldn't care about.

That's true of any (bad) leader. Micromanagement is almost always bad leadership. A good leader needs to know how (and what) to delegate; having a solid understanding of the fundamentals of what you are delegating is essential in being able to delegate effectively.

Comment Re:just like Pfizer- selling alll the cash cows (Score 1) 120

The time to sell a cash cow is when it's still giving milk. Selling your current cash cow, knowing that it won't go on giving milk forever, lets you invest that money in NEW cash cows that have a future. If you try and milk every last drop out of it, no one will want to buy it.

This is why IBM is still going strong after 100+ years and Kodak is bankrupt. If Kodak had sold off all their film assets to Ilford or Fuji a decade ago and invested it all in digital, they'd be at in great position now. Instead they clung to a dying business model long for far too long and are now having to sell off their crown jewels at pennies on the dollar.

Comment Re:There is a lot of money in hardware (Score 1) 120

Noone in the US could live on $290 a month (Foxconn wages for iPad line person).

Sure they could, if (like the Foxconn workers) they lived in the company barracks, ate at the company mess hall, and wore company uniforms. 3 hots and a cot doesn't sound like much, but it's better than being homeless and starving.

Comment Re:There is a lot of money in hardware (Score 1) 120

In my opinion there is a lot of money in hardware.

That is not the same as saying there is a lot of PROFIT in hardware.

Most mature hardware is a commodity item. In an ideal marketplace, the cost of a commodity approaches the cost of production. There is money to be made in a commodity market, but what profit there is generally comes from efficiencies of scale, cost reduction, etc. Competing in a commodity market is almost always a race to the bottom.

IBM has survived as long as it has because it knows when it's time to leave a market. They look forward rather than trying to cling to past glories. They know the time to sell a cash cow is when it's still close to it's peak, not when it's dried up and worthless. This is why IBM is profitable and Kodak is in bankruptcy.

Comment Re:Yeah... no (Score 1) 715

Ruby is *not* basically Perl, I've used both for quite a while now. Ruby's concepts are much easier to comprehend and use in everyday coding.

That's a matter of opinion. I personally find Perl to be a better (more expressive) language for most tasks. Mostly I use Ruby (JRuby, specifically) when I have to write code that will run in a JVM, otherwise I default to Perl. RubyGems is nice, but it's still (at least) a decade behind CPAN. I'll grant you that Perl's learning curve is steeper than Ruby's, but I'll maintain that it's worth the effort.

Classes are not some weird afterthought that feels like it's falling apart every second now, they are first class members.

I'll give you that one for classic Perl OO. OTOH, Moose solves most of those complaints. Moose is basically a backport of Perl6's OO system, which is heavily influenced by Ruby's. This gives you pretty much everything you need to do serious OOP without having to drink the everything-is-an-object kool-aid.

The Perl interpreter is way quicker, which is nice,

Even nicer is the ability to use other (faster) languages inline once you've identified hotspots in your code through profiling. I am not aware of anything in Ruby that can compare to the simple elegance of Inline::C for this purpose.

there's sooo much unnecessary syntactic explicitness compared to Ruby.

Huh? Examples, please. "Syntactic explicitness" is NOT a complaint that's levied against Perl often.

Comment Re:Have you ever been to a Ruby conference? (Score 1) 715

You can write perl that looks like modem line noise, but you don't have to. Feature!

Specifically, it's a feature designed to let you write efficient one-liners. One-liner Perl is practically an entirely different language than 'application' Perl, and (IMHO) should be treated as such.

You don't have to make it hard to read or maintain, though some programmers do.

Even as a die-hard Perl programmer, I have to admit that Perl culture often encourages it. Perl Golf is an interesting intellectual exercise, but you shouldn't be playing it when writing production code. TIMTOWTDI is a powerful concept, but it gives you plenty of rope with which to hang yourself if you are undisciplined.

Adopting the mandatory use of perlcritic is a good first step towards managing Perl development. Perl Best Practices should be required reading for any modern Perl programmer.

Comment Re:Naive, because most investors (especially VCs). (Score 4, Insightful) 438

That goes both ways - if you want me to sign an NDA, show me the money.

I don't have problems with an NDA (or even a non-compete) as long as it is a) reasonable in scope and duration, and b) isn't bundled with an IP rights grab. If you don't want me to steal your ideas, don't try to steal mine either. I routinely strike clauses in contracts / agreements that are overreaching and unreasonable - and have gotten very little push-back about it.

Comment Re:Cliche, but... (Score 2, Insightful) 438

Cliche, but... Coders are a dime a dozen.

Coders are a dime a dozen. GOOD coders are rarer than hen's teeth.

Coding is not an assembly-line process, and programmers are not interchangeable. You don't create great software by hiring more programmers. You create great software by hiring better programmers.

we'd have 100's of implementations of EVERY idea.
We don't, but we do have 1000's of coders for every idea.

You haven't browsed Github or Sourceforge (or CPAN, or RubyGems, or any other open source repository) recently, have you? We do have hundreds of implementations of every idea.

Comment Re:Extend the lifespan of B-52 beyond 2040? (Score 1) 403

Actually the B-52 was designed to deliver a nuclear weapon from an altitude so high that nothing in the day could touch it. Of course that untouchability only lasted a few years until the Soviets designed interceptors and SAMs that could reach the B-52s service ceiling.

Dropping massive amounts of conventional ordinance was a capability that was retrofitted.

The fact that the B-52s mission profile has changed so many times over it's lifespan is testimony of how flexible the airframe is.

Slashdot Top Deals

"Mr. Watson, come here, I want you." -- Alexander Graham Bell