Forgot your password?
typodupeerror

Comment: Good luck with that. (Score 4, Insightful) 49

by dfenstrate (#47565021) Attached to: Ford, GM Sued Over Vehicles' Ability To Rip CD Music To Hard Drive
I'm sure GM and Ford have better lawyers, and I imagine they have more resources to throw at the affair as well. I also imagine that GM and Ford will team up for their defense, and make AARC cry. GM and Ford's lawyers signed off on the system before it was even developed, let alone installed in cars. The AARC is going to waste millions and go home with nothing.

Comment: Re:Functional Programming? (Score 1) 269

by gweihir (#47562557) Attached to: Programming Languages You'll Need Next Year (and Beyond)

The author really has no clue. He also doe snot understand what static and dynamic typing means and that it is orthogonal to weak and strong typing. Or that whether you have GC or not is not necessarily dependent on the language. You can attach a GC to C and have it working reasonably well.

This article was written by an incompetent wannabe.

Comment: Re:Erlang is overrated crap (Score 3, Informative) 269

by gweihir (#47560731) Attached to: Programming Languages You'll Need Next Year (and Beyond)

Erlang is pretty cool for the intended application scenarios. It is not really a general-purpose language. If you need, for example, excellent crash-proofness, updates to running code and massive multi-threading, Erlang is what you want to use. (Ever tried to run 1000 threads in Java? I know people who did, for this Java is a completely unusable toy...)

The second problem is that Erlang is decidedly experts-only. Real understanding of advanced programing concepts is mandatory. Don't even think about doing anything with Erlang unless you have top-notch people. (These people do not need to already know Erlang before though.) Of course, one top-notch coder is more productive than 10 of the typical mediocre ones.

Comment: Re:Author thinks strong typing == static typing? (Score 1) 269

by gweihir (#47560655) Attached to: Programming Languages You'll Need Next Year (and Beyond)

It is not. Strong typing can be implemented by attaching types to data. Static typing always attaches types to variables and they are fixed. But strong typing can also mean type-less variables, but no implicit conversion of values. For example, Perl is weakly typed, but that is because it will, for example, happily convert a string to a number all on its own. Python, on the other hand, is strongly typed, despite its variables not having types just like in Perl. The values assigned to the variables in Python have types and all type conversions have to be explicitly requested by the programmer.

With such a stupid article, it is really no surprise the author gets basic things wrong.

Comment: Re:Bullshit.... (Score 1) 133

by gweihir (#47555365) Attached to: A Fictional Compression Metric Moves Into the Real World

Whether measuring speed is a meaningful benchmark depends on what you measure the speed of, relatively to what and what the circumstances are. There are many situations where "speed" is not meaningful, and others that are limited enough that it is.

However, the metric under discussion will not be meaningful in any but the most bizarre and specific circumstances, hence it is generally useless. For the special situations where it could be useful, it is much saner to adapt another metric than define a specific one as this pollutes the terminology.

Comment: Re:Bullshit.... (Score 1) 133

by gweihir (#47554407) Attached to: A Fictional Compression Metric Moves Into the Real World

The uses for that single number are as follows:

a) Some class of people like to claim "mine is bigger", which requires a single number. While that is stupid, most people "understand" this type of reasoning.
b) Anything beyond a single number is far to complicated for the average person watching TV.

In reality, things are even more complicated, as speed and compression ratio depend both on the data being compressed, and do that independently to some degree. This means, some data may compress really well and do that fast, while other data may compress exceedingly bad, but also fast, while a third data set may compress well, but slowly and a 4th may compress badly and slow. So in reality, you need to state several numbers (speed, ratio, memory consumption) for benchmark data and in addition describe the benchmark data itself to get an idea of an algorithm's performance. If it is a lossy algorithm, it gets even more murky as then you need typically several quality measures. For video, you may get things like color accuracy, sharpness of lines, accuracy of contrast, behavior for fast moving parts, etc.

Old programmers never die, they just become managers.

Working...