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


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:c++? (Score 1) 394

As far as the example you give, this is because C++ always adheres to the "zero-cost principle"

Also describable as the "zero-flexibility principle". In Objective-C extending existing code is super trivial. In C++, unless the author of your library *expected* what you're about to do, you're pretty much SOL. For example implementing a native RPC mechanism in Objective-C is about as complicated as implementing -forwardInvocation: and ferrying the serialized NSInvocation object between sockets. In C++, it just can't be done (well, unless you're willing to write some sort of custom VM!). Also, in practice, the overhead of Objective-C's dynamism is pretty much negligible (speaking from experience having written some pretty heavily real-time code for video streaming in Objective-C that's running the server-facing portion of a few dozen thousand STBs in the field right now). 90% of the time you're running 10% of your code. Write that portion in highly optimized pure C and the rest in objects and you'll get the best of both worlds.

For programmers like me who value C++ primarily for it's runtime efficiency, this is absolutely the correct design decision.

TBH, I've never seen the logic of this statement. Given that most code written in pretty much any app is just high-level scaffolding around a few really core high-perf algorithms, why try and shoehorn the same language into these two completely different usage scenarios. That's IMO asinine and C++'s extreme levels of complexity and sheer volume of features is a testament to that fact.

BTW, you're a bit out of date regarding C++ and allocation. Modern C++ now has several built-in smart pointers (including ref-counted versions) which makes modern C++ feel a lot closer to C# with it's garbage collection than to C-style manual memory management.

I stopped paying attention to C++ by the time the spec document collapsed under its own gravity to form a black hole.

Comment: Re:Objective-C is a lot of work (Score 1) 394

Wait, so you're porting or implementing it anew? One is not the other. Also, runtime != base library. Did you try to port the base library, or the runtime? Porting or even rewriting the runtime is pretty straightforward and I'm aware of at least one project where a single person did it without much trouble. The base library, yeah, a lot less simple, but still simpler than writing a new stdc++. Also share your sentiment on C++. It's way, way too big for my tastes. For the kinds of work I do (systems stuff, OS stuff, like you), C is plenty expressive enough.

Comment: Re:Objective-C is a lot of work (Score 1) 394

Implementing a new Base Library is hard, I've gotten a tiny subset working on my own to see just what is involved. I wouldn't recommend writing the full thing unless you have a burning desire to do it.

Contrast with implementing the C++ base libraries (such as the STL) and you'll quickly see which is simpler. The real difference is that C++ already has more implementations for more platforms. I agree with your conclusion - availability can make its use for your project a non-starter. However, unless we're talking about pretty weird embedded stuff or some weird OS platform like Haiku or something, GNUstep has been already been ported to lots and lots of platforms (including most of the major *nixes and Windows).

Comment: Re:c++? (Score 1) 394

Dynamic binding and loading is ugly and clunky.

So dynamic binding and loading is ugly and clunky. Remember this boys and girls...

It's much more touchy about types and is geared toward catching as much as it can at compile time.

And the reason for that is because it's statically bound (well, for the most part, apart from "virtual" methods). It has dick-all to do with "correctness" or whatever. It's simply because even if a subclass has its own implementation of a parent's method, it'll still call the parent method - this goes against one of the core principles of OO: polymorphism. This means that even *if* you wanted to override a method from a parent class in your subclass, unless the parent has it marked as virtual, you're SOL. In Objective-C, meanwhile, it'll work exactly as you'd expect - the child method will get called. Also don't assume that simply because Objective-C is dynamically bound that it doesn't watch your fingers. If you aren't a stupid programmer and have warnings turned on, it'll warn you of weird stuff, such as sending a message to an object of a class which is not known to have it declared. I've written a fair amount of Objective-C code and only encountered sending an incorrect message to an object a few times. Now allocation-related stuff, that's the killer! But it's the same in both languages (in fact, one could argue that ObjC is a bit better, as it at least gives you a ref-count garbage collector, whereas in C++ you're on your own).

[C++ is] big and clunky, has a lot of rules to memorize and its error messages are hideous.

And so now C++ is the clunky one? TBH, it really comes down to personal preference. I like dynamically bound languages, because it fits my style of thinking. If you're writing complex interactions between objects, it cuts down on the amount of code needed to write quite a bit and if you follow the suggestions of the compiler, you're very unlikely to shoot yourself in the foot. OTOH, I understand that if you're after 100% valid programs where static analysis gives you a lot of confidence ahead of time, then C++ is probably the way to go (although I'd prefer C in that case). It's really about style and personal preference. Neither is more or less clunky, it depends on what you want to do with and how you want to do it.

Comment: Re:Some potential, but hardly for a genuine leap (Score 5, Insightful) 282

by brambus (#48949705) Attached to: NASA Looking At Nuclear Thermal Rockets To Explore the Solar System
Whoever the hell moded this tripe Insightful needs to have their head examined, along with the author.

ancient discredited NERVA/ROVER program which began in 1956 and dragged on to a miserable failed end in 1973

You mean the discredited program that produced working engines and test-fired them on vacuum stands, proving they are practical and work? You might also note another program that was terminated in 1972: Apollo. Oh my, what an abominable failure that one was...

the fact that any rocket has to carry and throw away a vast load of reaction mass

And how else would you propose to move in space? Mr Newton might have something to say here.

But the actual raw energy needed to lift 118 tonnes to 200 km is...

If you think the difficulty in achieving orbit is just lifting something sufficiently high up, you're more dense than I thought... Here's an idea, first learn about something, then start lecturing about it.

No other mode of transportation has to carry its own reaction mass and throw it away. Not bicycles, cars, trains, ships, submarines, or airplanes.

Please note that all of the above modes of transportation have one thing in common: they only work on the Earth. Or when was the last time you last saw a car drive through outer space?

Comment: Re:Don't mess with my jetset lifestyle (Score 1) 232

by brambus (#48721585) Attached to: Aircraft Responsible For 2.5% of Global Carbon Dioxide Emissions
P.S. just to set everything 100% accurately, I forgot about one detail. Fuel can result in more greenhouse gas emissions due to the binding of atmospheric oxygen, so I need to correct myself. However, the number for airplanes is still way off. For cars it might just about work out (930kg of CO2 contains about 250kg of carbon, which is in the ballpark), but for airplanes it's still way off (by about a factor of 4x).

Comment: Re:Don't mess with my jetset lifestyle (Score 2) 232

by brambus (#48721541) Attached to: Aircraft Responsible For 2.5% of Global Carbon Dioxide Emissions

I don't how great a source it is

Apparently not a very good one. Google maps says that the optimal driving distance from SF to BOS is about 3000 miles, which, on a 30mpg car, results in 100 gallons of fuel burn. Gasoline is typically around 0.75kg/L, so that comes to 284kg of fuel. Unless your vehicle manages to break the laws of physics somehow, you're never going to emit 930 kg of just greenhouse gases per vehicle. Now the same trip using a plane is about 2700 miles (from a real flight plan). A typical Airbus A320 or Boeing 737 comes to about 0.03L/km/seat, and given that Jet-A is typically around 0.82kg/L, this comes to ~100kg per seat.
So it really comes down to occupancy. A nearly fully-booked plane wins over a single-occupancy car hands down easily. The break even point is at about 2-3 passengers per car, so a car can be more efficient, assuming you car pool. One thing frequently forgotten in these comparisons, though, is the cost of time. The flight is 6 hours. The drive is 4 days of non-stop driving. In any case, just wanted to let your know that the source you cited is quite off.

Comment: Re:How the fuck are those screens built? (Score 1) 142

by brambus (#48045497) Attached to: Boeing Told To Replace Cockpit Screens Affected By Wi-Fi
That's what we have shielding for. All modern digital signaling cabling worth a damn is shielded end-to-end. Now not all on-board electronics in consumer products is shielded, true, but pretty much all of the electronics on board of an airplane is. The screens you see on flight decks are housed in separate grounded metal cases, and all cabling going to/from them is shielded as well. My guess is either your 1W UHF transmitter does a lot more than 1W output, or your electronics is so badly shielded, it's a wonder it's working at all. Another possibility would be interference through the power supply. Cell phones have 1-2W UHF transmitters and I just checked, yep, I can have a phone conversation while working at my computer desk.

Comment: Re:How the fuck are those screens built? (Score 1) 142

by brambus (#48043033) Attached to: Boeing Told To Replace Cockpit Screens Affected By Wi-Fi
Depends on which screen you're talking about. For the primary flight displays, they can just be LCD screens connected to an in-panel computer. The FMS and similar stand-alone things are self-contained computers connected to a data bus. However, all of these components are housed in separate grounded metal cases with shielded wiring going to them, so it shouldn't be a problem in the first place.

Comment: Re:How the fuck are those screens built? (Score 1) 142

by brambus (#48042963) Attached to: Boeing Told To Replace Cockpit Screens Affected By Wi-Fi
I've got 3 cell phones sitting 3 inches beneath my LCD screen all doing wifi & GSM and nothing has ever happened. I've had dozens of tablets sitting on a single desk, all going wifi at full blast downloading firmware updates and nothing happened to other screens around them. I've never ever seen wifi being a problem for the power and control electronics of an LCD screen. So I'm still utterly mystified - what the hell did they do? How could they have induced a radio signal so strong as to get the screens to blank out (presumably by frying the power electronics in them, can't imagine any other obvious way).

Comment: Re:How the fuck are those screens built? (Score 1) 142

by brambus (#48042937) Attached to: Boeing Told To Replace Cockpit Screens Affected By Wi-Fi
Might interest you: with speakers, it only interferes if you're inducing it into a pre-amplified line (where the signal levels of the wifi and the regular audio line are comparable and amplified together). Once past that, the audio signal is so strong that any induced wifi noise is essentially imperceptible. For example, a rather powerful antenna signal is about -40 dBmW, whereas audio amp output power level is approximately +40dBmW (for a ~10W speaker). That's a good 80 dB of delta, or about the difference between a whisper in a really, really quiet room at 6 feet (30 dB) and a jet at takeoff (110 dB).
ISS radiation is rather different - it's ionizing, i.e. the individual particles are powerful enough to knock electrons off of atoms. Radio signals aren't like that, they can only interact with materials by inducing minuscule electric currents by EM field interactions - you'd see that as line noise. While line noise is real enough, I can't imagine how it could be causing any trouble inside of a freakin' LCD screen and causing it to blank out. The only way I can imagine that to happen is if you literally fry the power electronics by excessive induced currents and the only way to do that is by a really, really powerful EM signal (in the kW range at really close proximity). Either that or Honeywell is making LCD screens with some really shitty electronics.

The sooner you make your first 5000 mistakes, the sooner you will be able to correct them. -- Nicolaides