Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

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:What makes it so expensive? (Score 1) 56

by hattig (#49334563) Attached to: Stanford Breakthrough Could Make Better Chips Cheaper

Well, they re-use the same wafer 50-100 times, but I presume the additional processing steps add some additional per-re-use cost.

It's still $5 versus $50, but given that wafer processing itself can cost $5000 to $10000 per wafer, the wafer cost is now insignificant - especially if GaAS processing is cheaper in any way than silicon wafer processing.

Comment: Re:Deja vu all over again (Score 3, Interesting) 112

In this case there is no legacy software advantage for x86, and a lot of cost disadvantage. Intel are subsidising their products in the mobile area massively but that can't last forever.

In addition, some manufacturers are doing their own chips now, and will not see any benefit to losing control of design to Intel in this area.

The Atom core is not great either in terms of performance - an A57 core should be more powerful, and Samsung have got their 14nm process working so that advantage for Intel is not as clear-cut as it once was.

Comment: Quite a weak X3 line ... cost determines success (Score 4, Interesting) 112

The X3 line is very weak, and will be competing against $5 to $10 SoCs from MediaTek, AllWinner, etc. This market is very price sensitive, and battery life is also important.

The X5 and X7 look more capable, it will be interesting to see how they compare against the competitor SoCs using A57 cores. The 14nm process will also help with the battery life significantly.

Comment: Re:Simple methodology (Score 1) 347

by hattig (#49145311) Attached to: The Programmers Who Want To Get Rid of Software Estimates

Simple guide for managers:

Double developer estimates then add some. Indeed, don't use days as a timeunit, just vague (fibonacci) numbers.
If task includes the words "timezones", "character sets" or "dependency on another team" then triple ... no quadruple the estimate.
And then consider unit tests, component tests and regression tests.

Oddly enough some things that a manager might look at and think "oh, that'll take loads of time" due to their lack of experience (for example, service should return JSON instead of XML) actually can turn out to be quite quick (as simple as configuring a different content negotiator / resolver on your project). OTOH the developer will probably have to redo all the component tests as well.

Comment: Re:Are you freaking serious? (Score 1) 83

by hattig (#49086401) Attached to: Building a Procedural Dungeon Generator In C#

I wrote one last week in a single line of BASIC running on a 4MHz Z80 system. Admittedly the level size is only 80x24, and it is more random than procedural (i.e., rooms can be left isolated), but that's the nature of trying to fit that into a single line of code (monster placement and gold placement take up another line).

It takes a few seconds to complete - mainly due to it being interpreted BASIC on a 4MHz Amstrad CPC.

I figure that most "dungeon generating algorithms" are quite unrealistic anyway. If you are going to build a dungeon, you're going to start somewhere, and excavate from there in a fairly compact manner (dwarf fortress/dungeon keeper style), not subdivide a massive open space, or make long tunnels into very isolated rooms (although in mines that could be viable). A realistic dungeon would also probably be quite boring to play.

Comment: If I wanted those apps, I'd get a MS phone (Score 1) 148

by hattig (#49065295) Attached to: Report: Samsung Replacing Its Apps With Microsoft's For Galaxy S6

As long as they can be uninstalled, great. If they're always installed then boo.

I've got a long term investment in the Google infrastructure, for better or worse. I don't want to be directed to use a different infrastructure (OneDrive, etc), and I don't want that cluttering up my phone. Luckily I expect it is easily fixed this time round via installing the correct apps from the Play store, but what about the future?

Some major money must have passed hands. Shame.

Comment: Re:Makes sense to me (Score 1) 411

by hattig (#49039491) Attached to: Your Java Code Is Mostly Fluff, New Research Finds

Coming from a Java background, I have found it very refreshing to start coding Clojure (which is a lisp family language that runs on the JVM).

It does appear to me that it becomes possible to write extremely compact code in Clojure compared to the equivalent Java code.

Also, the language really encourages you to just deal with the built in "primitive" collections (obviously behind the scenes they aren't primitive, but at the syntax/function level they are) - sets, maps, vectors, lists, etc for your data structures and passing data around. Java, even with Apache/Google collections help, is often a load of collection herding, shuffling and copying, which comes for free with Clojure (and will become a lot more concise with Java 8's Lambdas too).

Modern programming practices (separation of concerns, patterns, etc) also means that code often has a lot of the same boilerplate structure around it, with a little functionality in the middle. The benefit is, of course, maintainability and clarity.

Put your best foot forward. Or just call in and say you're sick.

Working...