Slashdot Mirror

C++'s days are numbered.

https://en.wikipedia.org/wiki/...

"The designers were primarily motivated by their shared dislike of C++."

References:
"Dr. Dobb's: Interview with Ken Thompson": http://www.drdobbs.com/open-so...

"Less is exponentially more": http://commandcenter.blogspot....

""The Evolution of Go": https://talks.golang.org/2015/...

And I'm not the only one who agrees.

"Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C"
https://slashdot.org/story/334...

There's a lesson here. If you have a good idea, don't fucking tell Google about it! Don't put it on your android phone, don't discuss it in email, don't type more than you have to in the search bar.

Classic example of availability bias.

The vast majority of inventions are lost to the world because the person who thought it up (in a form that was by no means complete and practicable unto itself) failed to solicit enough outside involvement to fully move the idea forward.

It's simply human nature that ideas die when not shared around and chewed collectively.

This has a lot to do with fueling the lone genius myth, because only weirdos like Tesla (and he was very weird) have what it takes mentally and emotionally to go it alone.

Most clever monkeys who select your recommended door #A seriously overestimate their intestinal fortitude, wherewithal, and life course. Then we tremendously celebrate the few who prevail over these dim prospects. Probably in most cases, clever monkey is far better served by selecting door #B: ensconce the idea into the public domain as quickly, and vigorously, and thoroughly as possible. Definitely mention all the ways the idea might play out or become applied in a practical scenario.

If the idea seems to gain any kind of social or economic traction, patent some lucrative corner case. I don't counsel against withholding some narrow, special tricks. If you've invented anything substantial enough to be worth this conversation, you've probably accumulated in your (years worth of) preliminary thrashing more than few exceedingly narrow, special tricks.

So You Want To Write Your Own Language? — January 2014 by Walter Bright

First off, you're in for a lot of work ⦠years of work ⦠most of which will be wandering in the desert. The odds of success are heavily stacked against you. If you are not strongly self-motivated to do this, it isn't going to happen. If you need validation and encouragement from others, it isn't going to happen.

No, I didn't look that up before writing the above. And it was on the first page of links that came up in a Google search "inventing a computer language difficulty".

Over the years, as the world has become ever more social, I've become increasingly convinced that this antisocial stiff-upper-lip door #A is tragic advice, 99 times out of 100.

If you're Walter Bright, YMMV. But Walter certainly wasn't reading Slashdot for prudent counsel. He was entirely of his own mind from the get go. The bright solitary lights tend to come fully equipped with a blanket-armour disdain for the rubes around them (sometimes graceful, sometimes polite, sometimes neither).

Moral of the story: if you need to ask, you can't afford it.

It does not magically reveal itself. Nothing does. But readable text is easy to compare, even to the human eye.
If I were to read code I wrote or supported, I would likely recognize it.

You could even consider using a computer.

https://en.wikipedia.org/wiki/...

http://www.drdobbs.com/archite...

https://academia.stackexchange...

...

I guess you find statistics on the net for that quite easy.

There doesn't seem to be that much out there.I googled for "comparative productivity of programming languages", and looked for fairly recent results that aren't paywalled or blocked by the company firewall. There wasn't that much..

Dr. Dobb's gives Java about a 20% advantage over C++. this arxiv paper essentially says Java is better for web development and C++ for systems programming, with no numbers given.

but as you hate Java you never will figure why the productivity is so much higher in it, so I give you a few hints:

This applies to you and C++. You clearly don't know C++ well enough to make your judgments. Also, I don't hate Java. I'm kinda meh on it.

First: the huge amount of open source libraries and frameworks

There's a lot for C++ also, but Java and the JVM have the advantage.

f) refactoring, Java is easier to parse due to lack of header files and macros, so refactoring on big projects can be done with the IDE

Also because C has some parse problems. Definitely an advantage for Java. There are some C++ refactoring tools out there, but they will continue to lag behind Java and C#.

g) "forward code engineering" due to f) I simply write code as a SmallTalk programmer would. Non existing method calls I purposefully write get red underlined. The IDE asks if I want to fix that to an existing method name or if I want to introduce a new method in the affected class.

In other words, you save a few seconds now and then in the development process. Switching between files is not a major time sink in development.

Database access, concurrency, networking: all those things are super simple in Java and require manual work in C++

C++ has concurrency support that works great for simple concurrency (since clearly you were talking about simple cases, since the harder stuff is not simple in any C-type language (I have to learn more about Erlang sometime)). The other two are matters of libraries, which exist for C++ also.

Python has many of the benefits of Java, too, but no byte code morphing and I'm not sure how much introspection/reflection can be done in python but on the other hand you can do a lot of meta programming in it, too.

Python has simple syntax, unlike Java or C++, and when you need performance it's easy to embed C or C++ routines. I'm not a real Python guy, but for fairly simple stuff I find Perl faster to develop in than Java or C++.

Ah yes, and meta programming in C++ does not exist besides the decades old "open C++" compiler.

You're fifteen or twenty years behind on that.

You simply don't know enough about C++ and C++ development to make the tenfold productivity claim. You clearly know significantly more about Java development than I do, so I'm not really qualified to make productivity claims,

You only need to learn how to do one thing.

http://www.drdobbs.com/embedde...

The rest is repetition.

This was covered 1.5 years ago in this DrDobbs article: http://www.drdobbs.com/embedde...
Been there, done that, the breadboarded ARM is a cool toy but not very practical.

Yup, author of the Graphics Programming Black Book amongst others.

Every object that can be thrown/caught must implement the Throwable interface

Then have all exceptions extend a subclass of std::exception . The guidelines mention use of a subclass as opposed to using the built-in exceptions directly.

the C++ alternative is only allocating objects on the stack and implementing destructors that clean up their resources

Also called Resource Acquisition Is Initialization (RAII), or "automatic resource destruction" if you don't want to remind readers of the record industry (RIAA).

but then you have the restriction of not being able to allocate on the heap

You can take advantage of automatic resource destruction if you wrap your object on the heap in a smart pointer type (std::unique_ptr or std::shared_ptr as appropriate) on the stack. If that isn't appropriate in a given situation, C++11 supports a scope guard idiom using std::shared_ptr and lambda expressions. The finally factory described in the Guidelines is ultimately an update of a method described in a 2000 article by Andrei Alexandrescu in Dr. Dobb's .

SoftRAM's problem was that it didn't actually do what it claimed to. It adjusted some parameters that improved swapping performance on Windows 3.1, but on Windows 95 it was effectively a nop, and could actually cause problems due to non-reentrant code.

We published a report recently at the NHTSA's Enhanced Safety of Vehicles (ESV) conference that surveys many recent electrical/electronics (E/E) problems. Software defects fall into electrical/electronic systems in the ISO 26262 lingo. This includes a statistical analysis of recalls (classifying into those due to E/E problems) and ancedotes of many software defects resulting in recalls, including several examples of unintended braking, unintended acceleration, etc.: A Survey of Electrical and Electronic (E/E) Notifications for Motor Vehicles (PDF warning)

While writing this, we found a nice overview from Dr. Dobbs that's still fun to read: But I Never Did That Before!.

The Dr. Dobbs overview has a related recall from about 2 decades ago, where a car would not let occupants leave the vehicle:
"BMW 535i 1994: The double-lock feature can engage with occupants and the door/ignition key inside the vehicle. The occupants of the vehicle would be unable to exit either from the doors or from the windows of the vehicle. Drive-away protection would prevent the engine from starting. Dealers will replace the general control module with one containing the revised software to permit window opening with the double-lock engaged and key in the ignition."

By building the browser yourself (with CFLAGS, CXXFLAGS and even CC and CXX set to something unusual — such as to target only your specific -march) — rather than downloading prebuilt binaries — you make the attacker's job much harder. To successfully exploit your browser, he'll now need to make a custom exploit just for you.

And, if you include -fstack-protector or equivalent among your compiler-flags, you may even be able to make such attacks impossible for good.

Technically, this is correct.

However, I've tried to make my own custom builds of Firefox and it's a nightmare. The build process used by Firefox is so complicated and convoluted, it would make Rube Goldberg laugh. I haven't tried building Chrome, but reading the build instructions, it appears to be only marginally better.

A security researcher identified by HP only as ilxu1a delivered the first exploit of the day with an out-of-bounds memory vulnerability in Firefox that took less than one second to execute. For his efforts, ilxu1a was awarded $15,000.

To successfully exploit such a vulnerability (other than to make the browser to simply crash), and attacker needs to craft the attack to place just the right content into memory.

By building the browser yourself (with CFLAGS, CXXFLAGS and even CC and CXX set to something unusual — such as to target only your specific -march) — rather than downloading prebuilt binaries — you make the attacker's job much harder. To successfully exploit your browser, he'll now need to make a custom exploit just for you.

And, if you include -fstack-protector or equivalent among your compiler-flags, you may even be able to make such attacks impossible for good.

That TCO is implemented by both Scala and Clojure sort of demonstrates the point really. I mean, why would they bother if the Java Compiler did it already?

In fact, both Scala and Clojure implement it in the same way -- they remove the function (method) recursive call. In otherwords, you see a recursive call in Clojure/Scala but there is not one in the byte code. Method calls in Java consume stack. Try the answer that I gave you earlier. Otherwise, can you please show me the part of the JVM spec which describes TCO on the JVM. It has to be there, because TCO changes the way that you program.

There is a nice write-up on Java and how it does not implement TCO here at DrDobbs.

http://www.drdobbs.com/jvm/tai...

These just came out, so I haven't read them, but you can't go wrong with these authors:
A Tour of C++ by Bjarne Stroustrup (the original creator of C++)
Effective Modern C++ by Scott Meyers

Dr Dobbs journal is always good.
Microsoft's Channel 9 has a lot of good talks like these and these.
The ISO C++ committee has a great website.

"Old Educational Computer Resurrected As a Spreadsheet" http://science.slashdot.org/st...

Which links to:
http://www.drdobbs.com/embedde...

See also:
https://www.cs.drexel.edu/~bls...
http://en.wikipedia.org/wiki/C...

A downloadable emulator mentioned in the Dr. Dobbs article:
http://www.kaleberg.com/softwa...

But ideally it would be in JavaScript and run in a web browser... Could make a nice small project for someone...

http://www.minix3.org/

How workable could it be as a general desktop at this point, like to read email and browse the web? And do some development whether with Eclipse or something else, for C, Java, and JavaScript)?

Does Node.js work on it yet?
http://stackoverflow.com/quest...
"Thanks! I did try getting NodeJS to work in Minix3 but it simply did not work, worked with a couple of guys and there are too many unresolved dependencies and its just a pain... I will try other microkernels and see if I have better luck. Thanks for your reply! -- Purefan Sep 15 '11 at 8:11"

Personally, it seems to me we could have a much simpler OS than something UNIX-y based around Forth and Smalltalk somehow... There seems a lot of clutter and inconsistency of naming things in the UNIX world with various abbreviations (especially including command-line programs and their arguments). But perhaps something like Minix as a microkernel could still form a core for that...

Alan Kay's FONC project was a hopeful step in that direction, but I'm not sure it has really delivered more than some interesting experiments?
http://vpri.org/mailman/listin...

But Alan Kay's heart is in the right place, regardless of recent outcomes. It would have been fun to work with him and maybe become the next Dan Ingalls! :-)
http://www.drdobbs.com/article...
"Kay: Yeah. You want to get those from the objects. You want it to be a mini-operating system, and the people who did the browser mistook it as an application. They flunked Operating Systems 101.
    Binstock: How so?
    Kay: I mean, look at it: The job of an operating system is to run arbitrary code safely. It's not there to tell you what kind of code you can run. Most operating systems have way too many features. The nice thing about UNIX when it was first done is not just that there were only 20 system commands, but the kernel was only about 1,000 lines of code. This is true of Linux also.
    Binstock: Yes.
    Kay: One of the ways of looking at it is the reason that WYSIWYG is slowly showing up in the browser is that it's a better way of interacting with the computer than the way they first did it. So of course they're going to reinvent it. I like to say that in the old days, if you reinvented the wheel, you would get your wrist slapped for not reading. But nowadays people are reinventing the flat tire. I'd personally be happy if they reinvented the wheel, because at least we'd be moving forward. If they reinvented what Engelbart, did we'd be way ahead of where we are now. "

Not lazy enough for me; here's a link with both the archive DVD and the Small C one: https://store.drdobbs.com/category/4/CDROM.

The link for those nostalgic, but lazy: https://store.drdobbs.com/prod...

http://www.drdobbs.com/are-the...

I've used it and could list SystemD's various technical issues, but that isn't and never has been the point.

The complaints we have about SystemD - and the Poettering cabal in geneal - is not about any technical issues. Bugs can be fixed; bad design, antisocial not-invented-here attitudes, and disregard/blindness to any use case outside their experience are what we have been complaining about. After about 2 years of arguing the topic, we've had to add rudeness, blatant propaganda, and attempts to bully opposing views to the list of complaints.

Typically, SystemD defenders - such as yourself - spend a lot of time and effort disrupting forums and discussion threads by posting strawmen, non-sequiters, or simply praising SystemD as it applies to very narrow use-cases. Recently, the tactic has bene what you are doing right now: accuse the opposition of being "old" or "luddite" or "hating change". It is quite telling, actually: a big complaint against SystemD's development style (as mentioned in this article if you bothered to RTFA) is that they don't bother to understand how people outside their immediate group actually use their computers, or what their needs are. Comments like this are exactly what we're talking about.

Nobody has been saying systemd should be banned or that you wanting to use it is bad. Nobody has said OpenRC or sysvinit should be the only option. If some tool solves problems for you or make your life easier - or even if you just like the tool's style/asthetics - then use it. What we're complaining about, more than anything else, is the tight coupling that SystemD has been doing, as it prevents everbody else from having that same freedom of choice.

Once, a very long time ago (internet years) when an image of a certain borg-ified CEO was common, there was a phrase that was commonly used to describe Microsoft's monopolistic actions against competing technologies: embrace, extend and extinguish. Many discussions on slashdot warned about how Microsoft was trying to "embrace and extend" various standards such as Kerberos.

So instult us if you like - it makes our arguments against SystemD's attitude for us. You can even sit in ignorance, if you desire, while Poettering embraces and extends linux so he can remove all the useful parts form it. The rest of us that have watched this happen before will continue using Free Software that preserves freedoms such as the freedom to choose your init system. We have been marginalized and a social outcast in the past and are used to crap like this. Just remember that it was that same freedom of choice that provided a place for SystemD to be developed in the first place.

Since no one answered this question, I did a simple google search which threw up these results :-

Nimrod: A New Systems Programming Language
Category:Nimrod
Consider the Nimrod Programming Language
What I like about the Nimrod programming language
Araq/Nimrod
Nimrod: A New Approach to Metaprogramming
Nimrod: A new statically typed, compiled programming language which supports metaprogramming

I am just a layman when it comes to Wikipedia editing, but it looks pretty substantial to me. It would appear that the complaint that notability requirements are too strict has just cause.

> the web would likely have been replaced by some other set of technologies.

A dream. I can no more stand this pile of crap.

The Web, [...], is a joke. The Web was done by amateurs -- Alan Kay

The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs

Alan Kay

http://www.drdobbs.com/archite...

I encourage you to test drive the languages that sound interesting. Choose a small slice of a problem (parsing & reformatting a *.CSV file perhaps); something small enough that you solved it with < 1000 lines of C code. Then try coding up the same with Python and one or two more languages recommended here.

One of the scripting things I look for is portability. While Java itself is pretty awful for rapid development (at least for me Java is painfully verbose), if you want to piggyback on Java's virtual machines you can go a long way with Groovy, Clojure, and maybe Python (here's an interesting review of JVM languages). It turns out for my day job there is always a JVM in the environments I need to work in, so I look for easier languages to work with in that regard.

My current personal favorite is Clojure; great leverage, you get a lot of bang for your buck for a line of clojure vs. a line of Java or C.

The one with faulty math.

Lack of openess.

From Walter Bright, creator of D (emphasis mine):

My natural tendency is to work solo on things. My work performance reviews at the various jobs I've had usually included comments like "Walter needs to learn to work better with others." My desire to control everything nearly wrecked the D community at one point, and I've had to change.

Source:
http://www.drdobbs.com/archite...

not really - what you need is to pick a few libraries and pull them in. Unlike other languages where you use what comes with your IDE, with C/C++ you are encouraged to find and use reusable libraries.

So if you want XML, get tinyXML and use that. If you want http - boost::asio or curl. Web Services (REST or SOAP?) gsoap or boost::asio or civetweb/mongoose, and so on.

This is a huge advantage. If I want an embedded webserver in my code then I'll include civetweb in it and with 4 lines of code and 2 c files, I have my code answering http requests. It will be limited in functionality, but that's ok as my embedded server only has 40k added to it by doing this. If I want something much more featured, I'll use a different server library.

If I want JSON, I'll go grab a JSON library, good luck using JSON in your that didn't see fit to include a parser for it. I would like to see boost wrappers/reimplementations of many common libraries like XML or SQL, but ... maybe one day I'll have a go at contributing one.

The only disadvantage to this is finding which library is the most suitable for you.

PS. async in cpp?

For people who want to give the Graphics Programming Black Book a read, you can do so here. Chapters 64 to 70 are relevant to his work on Quake with Carmack.

And the ones who want to roll their own version from the eBook sources can go here!

I've only ever had the online version. Apparently someone recently converted it to Markdown (hopefully the generated epub is better than the one I made from the PDF files a while back).

I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.

Humpty Dumpty said "When I use a word, it means just what I choose it to meanâ"neither more nor less." The rest of us try to stick with the established uses of words and phrases.

The term "spaghetti code" was coined as the antonym of "structured code". Deeply nested but nevertheless structured code is not spaghetti code.

Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if .... return statements.

Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:

http://www.drdobbs.com/archite...

You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox)

Exceptions aren't really unstructured. Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.

The main problem with early exits is using them in C.

Right, but this section of the discussion was under the condition: "if you are taking the step to remove gotos from a language...". Yes, C is old fashioned, and it's lack of exceptions calls for emulating them with gotos or early returns. But that's not the topic.

Its a common fallacy that server side stuff if just shuffling disk to network, hence the (current, but fading) popularity of node.js

What I find in all systems that are not trivial is that the middle tier gets a lot of processing bundled into it - read that disk or DB data, and fiddle with it, often combining it with other data sources and then send it down to a client. That fiddling requires quite a bit of processing.

Its one reason why Microsoft went as native-code as it did a couple of years back, their 'Casablanca' project (now released as C++ REST Services) because someone measured how much electricity their cloud services were sucking up with managed code (and to be fair, .NET is less resource intensive than many script-based languages) and they needed something more efficient. (Either that or someone noticed how seriously faster C WWS web services were compared to .NET WCF services :-) )

All the places I've worked that do serious stuff, base their distributed services over 3 tiers - the usual web presentation (or sometimes thick desktop) calling a middle tier business logic layer that calls the DB. The middle tier does all the heavy lifting, so its never just IO shuffling.

I'm sure many websites simply call a web server that calls a DB and does the mapping of data to UI in the client via javascript, but its not the most efficient way of presenting that, especially if there's a lot of data, or it needs processing.

Maybe there;'s a distinction to be made between the "website" devs and the "professional" devs in the type of systems they develop. I think its a shame the "website" style where everything is placed in the web server (bad security choice that) should be designed with 3 tiers from the start, and for these types of system, a C++ based service layer is not any more difficult than any other language to develop for. .NET, its easy to develop for, which is why everyone seems to be using it. Its not nice when it goes wrong (like the bug I struggle with today - reading event log entries returns null on my colleague's box, for no F*** good reason.. damn you Microsoft) but even Microsoft knows its their RAD tool, not the one that should be used for performance or resource efficient systems. To put it another way, .NET is the new Visual Basic - where VB used to be used, .NET fills that gap. The trouble is, it also attempts to fill every other gap (but I guess VB devs back in the day used to do that anyway)

Java.. no need for that anywhere IMHO :-)

While there are some compilers that ATTEMPT to convert C/C++ into a hardware representation - These will usually fail unless you understand the target hardware.

http://www.drdobbs.com/embedded-systems/c-for-fpgas/230800194

One thing is: Even if you can successfully compile from C to Verilog or VHDL, there is no guarantee that the Verilog or VHDL will successfully synthesize on your target hardware.

Even if it successfully synthesizes, there is no guarantee that it will be in any way an optimal implementation.

Some C algorithms may never transfer well into a hardware implementation.

The more interesting article is this one: "Our survey of more than 3,000 developers and managers shows...salaries are on the rise once again"

The "compilers" in the first stage of Wheeler's construction need not be compilers; they can also be interpreters. Good luck making a backdoor that recognizes picoc, Ch, and CINT, which I found through Google c interpreter, especially if written in a different language following Herb Schildt's guide to writing a C interpreter. And good luck making a binary-propagating backdoor portable across CPU architectures. It's not entirely foolproof, but if one of the "compilers" is an ARM-to-x86 cross-compiler and another is a C interpreter running in an x86 interpreter such as DOSBox (to exclude microcode backdoors), I can reduce the probability of a backdoor to less than a rounding error.

Dr. Dobbs Journal anyone? This quote's WHY I steer clear of FLASH SSD's:

"SSDs do have one important flaw, however, which is that the cells that store the data can be written to only a finite number of times before they can no longer be used reliably. Most SSDs solve this problem by distributing writes all over the disk, so that no one group of cells gets rewritten too frequently. How much of a problem this will be is hard to tell. I've spoken with some users who have had to replace SSDs due to this issue. If consumer devices see only four or five years of light use, I expect most of them will work fine for the expected life of the device. Power users, such as developers, however, may encounter this problem more frequently." - From http://www.drdobbs.com/architecture-and-design/the-demise-of-hard-disks/240161048

As that's something I'd DEFINITELY run into eventually, since much of the work I do & have done, is File I/O oriented (by the 100's - 1,000's quite often) - & it's the "WHY" of why I don't go FLASH based SSD's... yet (until they are not only mature, but PROVEN, for the reasons stated above - perfornance not an issue anymore, but rather durability!).

---

So - Do I use SSD's here? Yes! However, NOT Flash RAM based hardware units (but rather those based on DDR-2 RAM or PCI-2.2 SDRAM):

( & for a LOT LONGER than most worldwide have typically!)

Since 1992 or so, 1st using separate HDDs (slower seek/access by FAR) & then using software ramdisks per the list below (on a MS-DDK based one I wrote in fact, on how I apply them):

Then applying Software-Based Ramdrives to database work with EEC Systems/SuperSpeed.com on paid contract (which did me VERY WELL @ both Windows IT Pro magazine in reviews, & also MS TechEd 2000-2002 in its hardest category: SQLServer Performance Enhancement & SuperSpeed.com too - since I improved their wares efficacy by up to 40% via programmatic control & tuning programs for them) - which, only the past few years now it seems, OTHERS are finally "latching onto" for performance purposes in database work in industrial environs! The EEC/SuperSpeed.com unit had 1 great thing going for it - mirroring back to HDD to save state of data!)

I move the following off my wd Velociraptor SATA II 10,000 rpm 16mb buffered harddisks that are driven off a Promise Ex-8350 128mb ECC ram caching raid sata 1/2 controller (which defers/delays writes via said cache, & also lessens physical head movement on disks & this is where I am going to make it even faster via lessening its workloads, read on & reduces fragmentation as well in the same stroke - "bonus") onto my 4gb DDR2 Gigabyte IRAM PCIExpress ramdisk card 2006-present (& before it, a CENATEK "RocketDrive" 4gb PC-133 SDRAM based one on PCI 2.2 bus circa 2002-2006):

---

A.) Pagefile.sys (partition #1 1gb size, rest is on 3gb partition next - this I didn't do on software ramdrives though)
B.) OS & App level logging (EventLogs + App Logging)
C.) WebBrowser caches, histories, sessions & browsers too
D.) Print Spooling
E.) %Temp% ops (OS & user level temp ops environmental variable values alterations)
F.) %Tmp% ops (OS & user level temp ops environmental variable values alterations)
G.) %Comspec% (command interpreter location, cmd.exe in this case, & in DOS/Win9x years before, command.com also)
H.) Lastly - I also place my custom hosts file onto it, via redirecting where it's referenced by the OS, here in the registry (for performance AND security):

HKLM\system\CurrentControlSet\services\Tcpip\Parameters

(Specifically altering the "DataBasePath" parameter there which also acts more-or-less, like a *NIX shadow password system also!)

---

* All of which lessen the amount of work my "main" OS & programs slower mechanical hard disks have to do, "speeding the

In theory. But in reality it just created a new DLL hell. http://www.drdobbs.com/windows/no-end-to-dll-hell/227300037

What next? Null pointers are bad, m'kay...?

Well, then there is a recommendation of replacing fopen() with fopen_s() for improved safety. It was previously a Microsoft extension, but now is part of the C11 standard (Annex K).

Print:
1) The Economist. Very informative. Their politics are not hidden, and socially, they're definitely left of center. Financially, they're the "Voice of the Plutonomy." But, it works. The articles are typically quite informative.

Online magazines:
1) IEEE Spectrum
2) Communications of the ACM
3) Dr. Dobbs
4) Infoworld
5) Linux Journal
6) Machine Design

And a variety of online information sources for current events. Typically, Google and Google News are good starting points.

You underestimate how unenlightened is the self-interest of our tyrants.

They have intransigently pursued a narcissistic course creating a civil infrastructure so fragile that it hardly requires organized or coordinated attacks to inflict unacceptable cost. Mere recognition that one should, entirely at one's convenience and leisure, inflict whatever damage one can get away with on the supply lines to the cities, is sufficient to bring down the tyranny.

Since I just turned 59, I've a senior's license to wax loquacious on the topic:

A young Nebraska farmer's son went to war against Germany and came back with code-breaking skills, as well as good DoD contacts. His name was William Norris. He started Control Data Corporation with a young engineer named Seymour Cray and, with 34 people out on Seymour's farm in Wisconsin (only one of whom was a PhD and he was a Jr. programmer) built what is widely regarded as the first supercomputer -- even as IBM's armies of PhD's and unlimited resources foundered in the effort much to the dismay of IBM's CEO, Thomas Watson, Jr.

Somewhere along the line, they hired me.

What I learned was that both Bill and Seymour had very strong feelings about the national security implications of an increasingly urbanized population. That's one reason Seymour had his lab out in the north woods of Wisconsin. Bill, as CEO of CDC, had made this allowance for Seymour while keeping CDC HQ in Minneapolis St. Paul (right across from the airport).

The reason I signed on with them was the promise that I could fulfill part of Bill's vision for America:

National security through dispersed population structure -- both its preservation as an American heritage and its promotion as recovery from the recent urbanization that threatened that heritage. Basically, its virtually impossible to take out a decentralized society -- whether you are a nuclear superpower or an international terrorist organization.

My particular part in this effort was that I was to prototype a mass-marketable version of the PLATO network, which I did circa 1980. I won't go into the details of that network except to say that the contribution it would have made to national security would have been to connect "smart" rural homesteads with information, education and business resources that would contribute to their self-sufficiency. Yes, I know, this is starting to be realized today, but a lot of water has passed under the bridge since 1980, no?

The rest of Bill's vision was that these smart homesteads would be energy and food self-sufficient.

The reason you never heard of these things is that they were in direct conflict with Wall Street's interests and Wall Street made no secret of its hatred of Bill's vision.

I succeeded in prototyping the mass market PLATO system and it was quashed by a mutinous middle management more identified with Wall Street than the "crazy old koot" in the executive suite. Unlike many of Bill's other technology directions in support of decentralized population structure, the PLATO system was poised to make immediate profits and roll out mass produced Macintosh equivalent network computers for a service that would have cost $40/month in 1980 dollars -- and that includes terminal rental. So it was particularly egregious that this technology was killed for the noble purpose of making America vulnerable to 9/11 type attacks.

Bottom line, as technology advances, there is an increasing call for oppression to maintain the centralized population structure, just as there was to create it by moving the boomers out of their small midwestern towns, through universities and into the sterilizing urban environments in which they could not afford children -- but the attack on na

No worries, I caught that.

You may want to check out this article from earlier this year:
http://www.drdobbs.com/mobile/the-rise-and-fall-of-programming-languag/232400093

It was too old to make my earlier list (January 2012), but it's still quite relevant and informative. It should also help you make much better sense of the TIOBE data.

You could do that because that code was disabled in the production version - though still present.
For the technical details see this fine article.

Disclaimer: I'm an Objective C Programmer by day

The LLVM compiler suite is tremendously powerful with Apple's billions advancing many select features, but key to it's success from a users prospective the core use of reference counted object graphs (of type 'id') and reflection (RTTI - via 'isa' and 'Class'). Obviously this means the entire language is dynamically typed at runtime, but with express qualification in 99% of the code you'll use there's absolutely no performance hit despite the ubiquity of the core object.

I worry that many C programmers will remember RTTI was once considered an unportable disaster in C++ because of the the many differing implementations owing to a spec that left the implementation up to each compiler... Don't let this kind of talk scare you! Although objective, objc is contained to a well defined spec, single inheritance and nary a template in sight.

I consider my programming work to be relatively easy. 50% of my ease comes from the object system above. The other 50% from the fast messaging system used in place of raw ADTs: In the objc world a nil object doesn't fault when messaged (in a C world dereferencing a NULL pointer, common if a struct fetching function fails and then passes NULL on failure) leads to all manner of crashes, or as seen recently, kernel exploits. The messaging system can even push around primitive values, not just nasty objects.

If you program in C, you may have missed Automatic Reference Counting, if you have, low and behold, it's amazing: at *compile time* the compiler adds lifetime qualifiers to the IR that automatically inserts retain and release messages (retain is +1 on alloc, -1 on dealloc - release occurs at 0). In other words the lifetime of an object in objective-c is now exactly the period of acquisition to last use. Yes, last use. ARC's use of a new 'weak' reference means that dangling pointers are a thing of the past: a __weak object is automatically nil'ed after last use: in all local instances of that object (did I say nil objects don't fault on message?).

Admittedly most of what I've mentioned is thanks to the advances in LLVM's Clang compiler, in particular it's static analyser, therefore much objc analysis also benefits C (LLVM's IR is quite specular ).

I could go on: methods can be heap objects with cblocks, objc encourages abstract programming with delegates, you can method swizzle at runtime, extend existing classes and link to C/C++ code.

Source codes:
http://drdobbs.com/windows/226700457 (2010)
http://www.easterbrook.ca/steve/?p=667 (2009)

Raw data:
http://www.newscientist.com/article/dn20739-ok-climate-sceptics-heres-the-raw-data-you-wanted.html (July 28 2011)
http://www.forbes.com/sites/williampentland/2011/07/28/climategate-researchers-release-long-sought-raw-data-on-global-temperatures/

No need for a public apology for failing Google search.

I was in a similar situation a few years ago. This was the most useful article I found,

          http://drdobbs.com/architecture-and-design/217701907

But really don't worry that you are not a verse in SE. I would say the majority who program have just a small working knowledge. The smartest thing to do is when you get to your job is ask what their processes are and what they expect. Use the terminology, like agile, cmmi, unit test, process development, etc. If they have a process or model they are following, they will be thrilled your asking. If they don't then hope they are all master programmers and everyone works well together.

US has had some very good programming and embedded systems related magazines like C/C++ User's Journal, Dr.Dobbs and Embedded Systems Programming. Ten years ago there were many good articles on each of these magazines and in every issue. I found the magazines to be of great quality. I was a fresh engineer and I enjoyed each and every issue very much. All of them had excellent people writing to them like Herb Sutter, Michael Barr, Jack Crenshaw and many others.

But then there was steady decline: paper quality, number of pages, quality articles all went down slowly but steadily.

And now the situation is:
- Dr.Dobbs had its final issue on 2009. They still publish it in pdf format. Website is there: http://drdobbs.com/ .Not _quite_ the same.
- C/C++ User's Journal was discontinued on 2006. The own website is gone, but Dr.Dobbs hosts old content and some new articles at: http://drdobbs.com/cpp . Again, not quite the same.
- Embedded Systems Programming is now named Embedded Systems Design. Most of the editors still write to the mag. The website is alive and well on http://www.eetimes.com/design/embedded . This has somehow managed to maintain most of its quality.

But for the UK or euro alternatives: There is practically none I know of. So the situation in this field is quite bad.

US has had some very good programming and embedded systems related magazines like C/C++ User's Journal, Dr.Dobbs and Embedded Systems Programming. Ten years ago there were many good articles on each of these magazines and in every issue. I found the magazines to be of great quality. I was a fresh engineer and I enjoyed each and every issue very much. All of them had excellent people writing to them like Herb Sutter, Michael Barr, Jack Crenshaw and many others.

But then there was steady decline: paper quality, number of pages, quality articles all went down slowly but steadily.

And now the situation is:
- Dr.Dobbs had its final issue on 2009. They still publish it in pdf format. Website is there: http://drdobbs.com/ .Not _quite_ the same.
- C/C++ User's Journal was discontinued on 2006. The own website is gone, but Dr.Dobbs hosts old content and some new articles at: http://drdobbs.com/cpp . Again, not quite the same.
- Embedded Systems Programming is now named Embedded Systems Design. Most of the editors still write to the mag. The website is alive and well on http://www.eetimes.com/design/embedded . This has somehow managed to maintain most of its quality.

But for the UK or euro alternatives: There is practically none I know of. So the situation in this field is quite bad.

Hypercard didn't have any access natively to the serial port or similar interfaces. To do this, one had to write an XCMD (wow, Dr Dobbs has a good archive) resource in pascal or C (or possibly assembly) to talk to the low level system/hardware. This created an additional command / function that Hypercard could call. To an extent, this did cause some fragmentation of the language

Looking at an old archive at umich, you can get an idea of what these xcmds could do.

To do anything beyond the basic capability of Hypertalk, it required you to be able to go in with resedit, download (or write) and add the appropriate additional functionality. This was a tool that was part of a programmer's toolkit - not a user's.

Evernote Abandons Microsoft .NET

  "The blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted"

“There is a substantive effort in open source to bring such an implementation of .Net to market, known as Mono and being driven by Novell, and one of the attributes of the agreement we made with Novell is that the intellectual property associated with that is available to Novell customers” link

The latency problem in non-networked applications is ultimately caused by poor software engineering, starting with system-provided APIs. Most of "bog standard" system libraries were designed for something entirely different than what they end up used for. The "normal" C I/O paradigm is used everywhere, yet it was really designed for batch applications, not for interactive use. The only way to do almost any filesystem and network interaction should be to submit a request, then react when the results come back, all the while being receptive to other "results" (events) coming in. Unfortunately, designing things this way requires a certain discipline and a mindset, and default APIs and "industry practices" simply don't encourage it at all.

A correctly engineered system API should not have any blocking calls apart from the "wait for events" call, it's as simple as that. It's very rare that an application is only waiting for one thing to happen. Even something as simple as a UNIX cat has two file descriptors open, and simultaneously waits for stuff to come and and for stuff to finish going out, with a buffer in-between (I'm ignoring no-copy APIs for a moment). Coding it up as a read followed by a write is, at best, wishful thinking. Of course event-based programming is something that seems like a lot of extra work, but it's just a matter of getting used to doing things the right way.

In fact, if you decide to code up your whole system in an entirely reactive way, you gain other benefits. By reactive I mean you could reduce every application thread's interface to a single processEvent(event), run-to-completion function that you implement. As it turns out, it becomes almost natural to get the guts of the processEvent() function implemented as a state machine. The state machine formalism often helps in producing better quality code, and it certainly makes it very easy to trace interaction with the outside world. Miro Samek shows a striking example: the supposedly "so simple it couldn't possibly go wrong" calculator example from old Visual Basic has several bugs that stem from its bug-prone yet commonplace design. The calculator's state is spread out in an ad-hoc manner in various variables, and the tests done on those variables in response to external UI events pretty much amount to a buggy reconstruction of a single state variable to drive a state machine.

The state machine paradigm is in somewhat stark contrast to the way a typical GUI application is designed, where you have on_fooBar methods that get invoked when fooBar event happens. In the fooBar method it's up to you to verify that the application is in the correct state to do whatever fooBar calls for. This requires forethought, and status quo indicates that it's easy to get it wrong. Perhaps that's the reason: the de-facto mode of implementing reactions to external events is so broken that it's not used for much besides the GUI. Perhaps this is why "quick" system calls are usually done in line and end up blocking the whole application, or at least one thread, and those are not free either so why waste them with blocking APIs?! Apart from perhaps querying the current time or current username, there are really no "quick" system calls. Simple things like listing a directory or getting a key's value from the registry can potentially take seconds if your drive is thrashing around due to high I/O demand, or if the network happens to be slow.

Of course the line has to be drawn somewhere, so let's assume that paging of code, libraries and heap is something we should not worry about because it cannot be helped much. At that point one realizes that indiscriminate memmapping of data files can be problematic in itself: a memory-mapped file is, after all, supposed to hide the fact that you are doing a request-response that can be either very fast or very, very slow. The latter is something you should explicitly handle, and with memmap it's at best cumbersome: you have to use some API to check if given page is av

I've spent years programming in both Java and C++, and I really wish Java supported operator overloading. When used correctly, it's a fantastic feature that produces cleaner, simpler, more readable, less buggy code.

Consider this example. You want a resizable array of integers. In C++ that's a vector<int>. In Java it's an ArrayList<Integer>. Now suppose you want to add i to the j'th element. Here's the Java code to do it:

list.set(j, list.get(j)+i);

And here's the C++ code:

list[j] += i;

Which one would you rather write? And notice the Java version forces you to specify the index j twice, which is a great opportunity for bugs.

People who object to operator overloading point out that you can abuse it. You could overload the = operator so that a=b does something bizarre, like interpret b as a URL, download whatever is found at that URL, and save it in the file referenced by a. But you can do that regardless. If you can't overload =, then instead you provide a set() function wherever you really want to define an assignment operator, so a=b becomes a.set(b). And you can just as easily define set() to do something completely bizarre. Either way, you're relying on conventions and good sense to keep people from doing that.