Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:High-brow fails [Re:It depends on the use] (Score 1) 405

"High brow" programming has never proven itself in practice for multiple projects.

Sure it has. Assembler proved itself against writing binary, high-level languages proved themselves against assembler, managed languages proved themselves against languages compiled to machine code, regular expressions proved themselves against writing custom parsers... most new technologies were "high brow" once.

Comment Re:functional composition (Score 1) 405

My impression is that functional programming comes from Lambda calculus which was introduced in the 1930's.

Mostly correct. The Lisp family of languages borrow the lambda notation, but they're not based on lambda calculus in the Church/Tarski sense.

The differences (and the differences between functional programming and the theory of sets-and-functions that we teach to high school students) don't really matter at a basic level.

How are functional programs translated into machine code?

Here you go. This book is 30 years old, but the basic principles are the same.

That same complex algorithm that is simplified thanks to lambda calculus techniques might be so difficult to translate to machine code that the resulting program is less efficient.

For what it's worth, the same is true of any high-level language. CPUs don't understand virtual dispatch natively, either.

Comment Re:Fluid type manipulation with unions (Score 1) 405

Granted, you're not making it worse in any way by representing it with a union.

More to the point, you can't make it better by avoiding using a union. Because it's optimum as is.

The right tool for the right job.

pretty much the essence of obscure legacy cruft.

The job is the job. I have no problem using the right tool for the job.

Comment Re:structs and fundamental OO (Score 1) 405

You are just reinventing machine language where data, instructions, and address pointers can be mixed willy-nilly.

Because machine language varies hugely, and c varies little or none, when working on one platform and then another, c is a convenient low-level way to get as many advantages of working close to the metal (obvious ones are speed and executable size) as possible.

Higher-level languages merely try to introduce discipline and consistency to such practices.

Yes, they do. And in the process, they often cause the resulting product to suffer in speed and/or execution size (and the source code in clarity.) When "mere" means "the product is less good", I translate it as "not mere."

There are reasons to go one way or another. It's not as simple as "HLL's are always better." Sometimes even machine language is the best place to go, embedded controllers with limited storage and small tasks that must be accomplished efficiently, for instance.

Comment Impartial journalism? (Score 1) 161

impartial journalism is entirely possible.

It's certainly possible, but if you can actually show me an instance of it, I'd be quite surprised. I don't recall seeing such a thing. Ever.

There's selection bias, where the story that is told is not the only story, and/or leaves out pertinent details that variously pollute the information transfer to the information consumer. This occurs at the publisher, editorial, reporter and information source levels.

There are errors in collecting information, which can be characterized as "impartial but wrong" which entirely undermines the value of "impartial."

There's the social underpinning, such as the assumptions by the platform from publisher down to reporter buy into memes like the drug war, human trafficking, mommyism, military adventurism, etc. as right and proper undertakings and tell stories in the context of the presumptive matrix that results from those memes.

There's ad-pumping, where the advertising pays more money in when more eyes are attracted, which creates a loop based on popularity rather than accuracy.

There's comment "moderation", where "I disagree / am offended / am trolling" can strongly affect visibility of information -- depending on the site, that can come from privileged (and usually wholly unqualified) individuals, as here on slashdot, or from the crowd, as on reddit.

It all adds up to an extremely formidable gauntlet that information has to run in order to get from wherever it arises over to the consideration of the consumer.

And, not that it's part of the problem of actually achieving impartial journalism, but were you to completely get past every aspect of that somehow, then you still have to find an impartial audience or all that work is for nothing.

IOW, if you manage to present the facts, all the facts, nothing but the facts, and your audience cries "fake news" or drags prejudice, superstition, confirmation bias, or anything from a very long list of similar cognitive failure modes into it, well, there you go. You might as well have written an SF novel.

Comment Just an overview (Score 1) 161

If there's anything I've learned about journalism in the last 41 years, it's that everyone puts their own slant on it.

o Publishers - slant, selection bias
o Advertisers - selection bias on source and slant by rewarding max eyeballs
o Editors - slant, selection bias for stories
o Reporters - slant, selection bias for sources
o Information sources - slant, winners get to write history
o Reader's choice of media - slant, selection bias
 
...it's not like it's showing any signs of getting better, either.

Comment Re:We already had this sales pitch... (Score 1) 136

There are a few things wrong with your analysis. The first is that disk writes tend to be bursty for desktop users. You write a few hundred MBs (or a few GBs) and then drop down to an average of a few tens or hundreds of KBs per second. Spinning rust can easily keep up with the average write throughput of a typical user, it's the bursts that it has problems with. If you can buffer a few hundred MBs of writes, reorder them to reduce head movement, and then write them out behind the user, then you'll get much better performance. Obviously, this won't help for server workloads where you're I/O limited all of the time, but it will help a lot with desktop / laptop use.

The second is that one of the big bottlenecks for modern filesystems is the wait until data is safely in persistent storage. System RAM doesn't help here, because it goes away with power failure. To ensure consistency, you have to pause writing parts of an update until you've received confirmation that the previous part is written. In a conventional journaled FS, for example, you don't start writing the updates until you've confirmed that the journal has been committed to disk. With NV cache, you can get this confirmation practically instantly. If there's a power failure, then the drive just has to replay the transactions from NVRAM.

Slashdot Top Deals

Memory fault -- core...uh...um...core... Oh dammit, I forget!

Working...