Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re: Swift (Score 1) 351 351

I'll grant you it's more easily debugged. But the whole point of lining them up vertically instead of a bunch of if/else's is so that it's more readable and therefore more maintainable. Ternary operator is awesome when used properly (which is maybe 5% of the time).

Comment Re: Swift (Score 1) 351 351

I will agree that anyone nesting/chaining ternary operators more than twice is not a good idea.

I totally, completely, and utterly disagree with you there. I regularly chain 3 or more ternary operators, with great success. Readability of chained ternaries all about formatting/indenting in a reasonable way.

Slashdot is telling me I have "too many junk characters" when I try to paste an example, so I'll just paste link to an image giving an example: http://imgur.com/ivJO8cn

Line those suckers up vertically and you have extremely readable code.

Open Source

Calculating the Truck-Factor of Popular Open Source Projects 79 79

An anonymous reader writes: The Truck Factor describes the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. Wikipedia defines it as a "measurement of the concentration of information in individual team members. A high truck factor means that many individuals know enough to carry on and the project could still succeed even in very adverse events." The term is also known by bus factor/number. In this article, the authors calculate the truck factor for 133 popular GitHub applications. Spoiler, but unsurprising: Linux ranks near the top (meaning that it's highly resilient).

Comment Re:Makes sense (Score 1) 272 272

"Lush" is a well known brand. If people go to www.youtube.com/lush they would expect to see Lush cosmetics, not some random guy. Similar for www.youtube.com/mcdonalds.

Uh, who are these "people"? I've heard of McDonald's, but I've never heard of Lush cosmetics. If I went to www.youtube.com/lush, I don't know what I'd expect to see. Certainly not a cosmetics company. Porn maybe?

Comment Re:So here in the USA (Score 1) 81 81

Well, thank you for pointing out the two main issues here. Greedy providers that abuse caps for revenue, and apps that suck your data plan dry not by going "haywire" but by design.

The 5G Network Speed Funding Bill is passed. The system goes online August 4, 2015. Human decisions are removed from strategic communications. 5G begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Easter time, August 29th. In a panic, they try to pull the plug.

Comment Re:Yes if you can afford the time (Score 1) 267 267

I did say that, yes. I find C's compile-time type safety to be quite good. With the right compiler warnings enabled, it prevents me from accidentally storing a uint64_t into a uint32_t, and from doing stupid things like int64_t x = -10 * y when y is of type int or int32_t. (The correct code is int64_t x = (int64_t)(-10) * (int64_t)y;.) My C compiler is meticulous about catching things like this at compile-time, and I love it.

The only perils I find with C's type system is in void pointers, for example when implementing a comparison routine for qsort — but I really wouldn't call that perilous.

Comment Re:Yes if you can afford the time (Score 5, Insightful) 267 267

The simple answer is that once you learn how to code it doesn't matter what the language is.

I couldn't disagree with this more. I don't mean to be flippant or argumentative; I simply want to say that my experience has been quite different. I think the langauge you write programs in is incredibly important. You want the right language for the task at hand. Just as an example, I often prototype new ideas for algorithms in Perl as a prelude to rewriting them in C. Perl (and I'm sure Python is as well) is great for a quick prototype and for proof-of-concept testing. But it's terrible for speed (compared to C/C++), and is also terrible at type-safety. When I rewrite something in C, it often runs 100 or 200 times faster than the Perl version. (Not for parsing and string-based stuff, but for integer numerical analysis stuff). But exploring the data structures and getting them worked out first is easier in a high-level language like Perl, with its dynamic arrays, hashes, autovivification, and so forth. Anyway, I rarely prototype something C, and I rarely write production code in Perl. For me, the choice of the language is one of the most important decisions I make on a daily basis.

"There is nothing new under the sun, but there are lots of old things we don't know yet." -Ambrose Bierce

Working...