Slashdot Mirror

C++'s days are numbered.

Techincally everything's days are numbered.

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

Euch. You could insert "irrational" or "misinformed" into that sentnce. I use C++ a lot. I could give you a long list of complaints about it. A very long list. There are things I'd love to see fixed, or a "better" language replace it.

That language isn't golang.

In fact that article you posted:

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

Basically degenerates into a whiny rant about go is too awesome for C++ programmers and that's why C++ programmers have been pretty uninterested in go. It seems he can't really cope with the possibility that go isn't that amazing and certainly doesn't cover as many use cases as C++.

"Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C"

Yeah well, ESR is a bit of a plonker. What are you going to post next? His guide to sex? (no realy this is a thing http://www.catb.org/esr/writin...)

This is something that Eric Raymond put out in 2006 and it's just as relevant today.

http://www.catb.org/~esr/writi...

Users don't want to know what's going on under the hood as long as it's simple and works. Linux UX development still hasn't caught up to Apple and MS on the "Stupidly Simple" interfaces. And likely never will.

WTF? how is this guy in anyway a "security researcher", he was nothing of the fucking sort, he was a straight up hacker/thief.

Bonus point for having used "Hacker": the previous word that used to mean something else but was eventually cooped into meaning the malicious attacker that apparently called "security researcher" nowadays by the press.

April Fool's Day is the Hacker's Holiday.

http://catb.org/~esr/jargon/html/A/AFJ.html

http://esr.ibiblio.org/?p=3084

Microsoft is essentially saying "Hacker's not welcome here!"

Couldn't find any mention of Guy Steele, so I'll throw in The New Hacker's Dictionary , which I once owned in dead tree form. Not sure if Version 4.4.7 http://catb.org/jargon/html/ is the latest online... Also remember a couple of his language manuals. Probably used the Common Lisp one the most...

Didn't find any mention of a lot of books that I consider highly relevant, but that may reflect my personal bias towards history. Not really relevant for most programmers.

TMI, but if I open up my database on all the computer science stuff, the "score" is 352, of which the first 22 are in Japanese.

http://shanenj.tripod.com/cgi-...

Yes, sometimes decentralized, small encapsulated components are a win, but sometimes monolithic designs where the pieces can talk to each other easily are a win

I actually do see what you're saying, here. In The Art of UNIX Programming, Eric Raymond mentions that occasionally there are tasks where it simply isn't possible to make them small.

I don't have a problem with systemd being monolithic, as much as with the parts of said monolith being so tightly welded together. The other problem is lack of transparency and discoverability. Systemd is hard to understand, and for a big, monolithic project, transparency becomes more important, not less.

Lennart Poettering is an arrogant bully, with a proven track record of writing bad software and attempting to shove it down everyone else's throats. Systemd isn't his first nightmare; some of us remember PulseAudio as well. If you don't believe me about his software being excessively complex, go and look at Pulse's configuration files, and see if you can understand them.

sure sounds like it to me

(I'm about a third of the way through reading the paper, and I decided to check for substantive comment here. Depressing, isn't it?)

I suppose I'd better RTFA before commenting further. But a 10:1 end-over-end light curve does not sound very optimal to me.

Learn these words.

I don't see how EEE[1] applies here, though I don't know how it applies since unless it is GPL'd it'll never find its way into core distros.

1: fun fact, it's roughly the 20th anniversary of the Halloween documents.

Those accusations are not falsifiable. Pretty much everyone can get accused. As long as they can be called "Russian". I'm lucky that I'm not in US. Because I wouldn't survive in the coming night of long knives. I happen to be a Russian, and I'm a "hacker", at least according to one of definitions.

> ...giving names to things which don't really need naming.

See: The Jargon File

Home page: http://www.catb.org/esr/pytogo...

This is not too surprising given his recent work on reposurgeon, his previous statements that Python is simply not performant enough for converting the gcc repository from Subversion to git, and his exploration of Rust vs Go as systems programming languages.

I am not a developer. I am a self taught system administrator.

...

These two pieces of news this week have re-invigorated me into a desire to get more involved in the things I love(d). Now regardless of the motivation of Linus or the communities ideas here, at least one person will be coming back to the fold. Hopefully that is what the mission is here and the ruthlessness and "RTFM n00b" stuff is in the past now.

Self-taught administrator here too. The thing is, OSS projects are voluntary. It, and the hacker ethic beforehand, relied on individual contributions, individual contributors, and individuals pulling their own weight. That does indeed mean that RTFM is important -- a willingness to put in the effort (by RTFMing) before demanding effort from others (answer my question) is part and parcel of the mutual respect that's necessary for a community of any type.

This is WHY hacker communities for so long have led to standardized texts like How To Ask Questions The Smart Way.

Were people ruthless? Sometimes. Did people sometimes go overboard? Almost certainly. (Hello, Theo and DJB, and everyone else from the late '90s and early 2000s!) But correcting that does *NOT* require the philosophical change that this code, and the Post-Meritocracy Manifesto behind it, represent.

Do you remember the Halloween documents?

The Halloween documents first came out 20 years ago.

A lot can change in 20 years.

long ago. And has been forking users continuously.

Frankly, The Management of Mozilla can go fork themselves!

Second time in two days I've had occasion to post my favorite Master Foo story:
http://www.catb.org/esr/writin...
(the story doesn't say anything about PhDs, but it does talk about elegant)

I do a fair amount of programming in Python. My most recent program was extracting certain fields from TSV files (dumped from spreadsheets) and outputting them if they met certain conditions. If the data had been clean, it would have been a simple program.

The problem was that the data was not clean. I needed to collapse records that contained the same text data, but there were misspellings, use of quote marks in some records and not in others, etc. etc. By the time I got done, I had to convert lat/long to distance (to know whether two similar names might refer to the same place), decide on a cutoff on how far apart two places could be to be considered the same, do spelling normalization of names in both Roman and Arabic scripts (in Arabic, this involved collapsing certain Unicode code points that are often not correctly distinguished by typists), and use Levenshtein distance to further collapse place names. Some of this can be done with library calls, and some requires special coding.

The resulting code was several times longer than it would have been if the problem had been as simple as I thought it was when I started. Which brings up another point: a lot of coding requires domain-specific knowledge (e.g. what Arabic characters should be collapsed--I had to consult with Arabic speakers for that), and it requires knowing when the answer you're getting could be improved (again, I had to pass some questionable results by Arabic speakers, who found mistakes I had made).

You might think that this was an unusual case, that most programming problems are simpler. I can't say whether most problems are, I can only say that virtually all the problems I've worked on have suffered from dirty data, so that most of the work lies in testing for data that breaks assumptions, and deciding how to deal with it (output a warning, silently ignore it, silently fix it where the fix is obvious, edit the data, go back to the drawing board...) Seldom is the problem one of logic (although I found one of those kinds of errors in my program yesterday: 'if A and B then c else d' should have been 'if A then if B then c else e else d', sorry for the lack of indents...).

Oh, and there's the problem of making the program human-understandable, so that it can be modified by someone in the future (including the future me, http://www.catb.org/esr/writin...).

So no, I don't think programming can be easy, at least not for the average problem that can be solved by writing a program.

Zawinski's Law demands it.

That sounds like a response I would expect if I sent "this is crap".

I've read and re-read this semi-humorous article to make sure I remember the serious points it includes:
http://www.catb.org/esr/faqs/s...

The gist of it is, if I want something done, I do as much of it as I can, sometimes that's describing the problem in as much detail as possible, including describing what I expected to see happen instead. For a feature request, that means identifying the use case - who would use this new feature, fot what? Other times I send a pull request - I do fix the problem. Normally I only do a pull request (fix) for very simple problems. For more complex ones I send a message describing what I plan to fix first, asking for feedback.

the Holy Market was busy trying to hedge everyone into Walled Gardens of BBSes

No one was forcing anybody there. Once it became practical to link up, resources linked up. (Whether the Internet benefited from that is another question.)

How lovely to see Dunning-Kruger strike so obviously.

Putting a label on an argument does not refute it...

Eric Raymond did an essay 15 years ago on why so many open source interfaces are so bad. Among other flaws, they're driven by the "oooohhh, shiny!!" desire of developers to show off features that no one actually wants or cares about. The essay is at http://www.catb.org/esr/writin..., and it dates back to 2003.

Note that the software he wrote about, "CUPS", never has fixed the built-in GUI of any of the flaws he pointed out, even though developers on the project acknowledged most of the flaws and promised to do so.

The Unix philosophy is not "each piece does one thing." It's complex and you should understand it.

If I were designing it, the init system and the hot swapping system would completely separate, but the init system would call into the hot swapping system through a minimal interface when needed. That would give you maximal flexibility.

So Microsoft cannot buy Linux or Linus, but the closest thing they can do is to acquire a company based on software that Linus wrote. MS have also taken note of developers on the internet, they need a means to collaborate and I see the purchase of github as a way of buying that collaboration platform. Metadata will be lost in the collaboration tool, all the history will be stored in an import-only tool. This was true when it was github alone, but I fear that MS will employ predatory tactics and make this an issue as they may decide to modify the standard git tools a little in their favour, perhaps making things noticeably harder to work with if you don't use their brand (see HTML-ised email and their versions of javascript in the earlier days).

Greater focus on ease-of-use in the toolkit

Beat commodity protocols / services

Linux's homebase is currently commodity network and server infrastructure. By folding extended functionality into today's commodity services and create new protocols, we raise the bar & change the rules of the game.

http://www.catb.org/esr/hallow...

Had they just fucking called we both would have been able to quickly sort out who knew what and who was going to do anything about it.

That is actually misrepresenting the problem. A call requires you to drop everything and give it your full attention. It doesn't allow for editing your answer, or asking a careful question. The upside is indeed that you can quickly go back-and-forth. But the cost is that you lose your flow and are out of it for at least another 15 minutes. If I was dug into something deep and you call me around four, I might as well go home since I won't be able to get back in for the day. That's a fairly steep but hidden cost to your two minute call you could've resolved yourself with thirty seconds thinking or a minute or two of searching for yourself.

But the root cause is muddled thinking. This is quite common, and several essays on the issue immediately spring to mind.

There is that and also depending on your job you may even be required to have everything in writing whenever talking with a client or even for interdepartmental communications. Some of it is for CYA purposes but also for dealing with those people who just won't take notes and call you again with the same question the very next day because they already forgot. If someone insists on leaving me a long-winded voicemail I'll just email them and claim that it was garbled or such and to please reply to the email with their question. In my experience the ones who try to avoid email are trying to hinder you from documenting what they said.

Had they just fucking called we both would have been able to quickly sort out who knew what and who was going to do anything about it.

That is actually misrepresenting the problem. A call requires you to drop everything and give it your full attention. It doesn't allow for editing your answer, or asking a careful question. The upside is indeed that you can quickly go back-and-forth. But the cost is that you lose your flow and are out of it for at least another 15 minutes. If I was dug into something deep and you call me around four, I might as well go home since I won't be able to get back in for the day. That's a fairly steep but hidden cost to your two minute call you could've resolved yourself with thirty seconds thinking or a minute or two of searching for yourself.

But the root cause is muddled thinking. This is quite common, and several essays on the issue immediately spring to mind.

Notice how the kids (I'm 40, but I feel much older) treat "texting" like a phone call, or worse: Half-sentences or just loose words strung along across many messages. So they're trying to suck all your attention to them over the text.

Me, I prefer messages like I used to exchange on USENET (and FidoNet's Echomail). Properly interleave-quoted, edited for brevity, to the point, easily readable. It takes quite a bit of effort to make such a thing work but if you do you can get massive content through with lots of detail and nuance.

You don' t get that with a phone call, nor with "texting". You just get lots of attentiongrabbing, and a very low signal-to-noise ratio. This seems to be par for the course for "business" these days. Even before "texting" became a thing, truth be told. Mealy-mouthed "we value your custom so we're putting you on hold" and other such bullshit, not just on the phone. It's everywhere, and besides being full of obvious lies, it's a searing insult to my intelligence.

And now it's not just phone calls and texting, but all sorts of do-overs, do-agains, me-toos, and other imitations. Whatsapp, twitter, facebook, and previously icq, msn, aol messenger, jabber, what-have-you. None of those add anything worthwhile beyond being popular for a while, they just manage to fragment your messaging archive beyond all integration.

So for anything official, I'm back to letters.

Was his name Mel?

Obviously the OP hasn't read The Story of Mel

http://www.catb.org/jargon/htm...

Mel. See http://catb.org/jargon/html/st...

TI-99/4A GPL (programming language). Auto increment +1 +1 +1.... Mel was sold in K-Mart stores in 1982 for $99.

Mel. See http://catb.org/jargon/html/st...

Imagine that, Microsoft doing something correctly.

I suspect it wasn't a matter of doing things correctly, but rather had more to do with the limitations of computer technology at the time. Unix was written in the 1970s, when RAM and storage space were measured in single digit kilobytes or less. Some developer probably counted how many rows of text there were in all the text files of code he had written, and figured out that ~3% of the memory and storage space would be wasted holding the extra byte in the CR/LF combo. So he shortened it to just LF.

By the time DOS rolled out in 1981, 16-64 kB of RAM and 160 kB floppies were the norm. So DOS could afford to be more profligate with the space occupied by text files.

These sorts of constraints on storage space and processing speed forced programmers of that era to resort to innovative shortcuts to save a little bit of space or time here or there.

Not a complete answer, but http://www.catb.org/esr/faqs/s... is already a good start.

A million years ago I found an older version of this posted somewhere:How To Ask Questions The Smart Way where the reason people are jerks is spelled out in the introduction quite well. They're protecting the culture, quality of posts, and reputation of the group/site. I have no problem with elitism/hostility if it means SO doesn't turn into Yahoo Answers.

The word is informative. http://catb.org/jargon/html/C/... That fact that you are too lazy to understand it does not change that. That's the job of a journalist, to educate people. They missed used the word. They need to do their fucking job an inform and educate.

In this case, there was no circumvention.

The access attempts violated policies. Now it is the poor software implementation that led to the lack of enforcement of policy, but that isn't the same as being authorized access.

I consider the New Hackers Dictionary to be the authority on the definition of the term "hacker". Applicable definitions quoted below.

1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users' Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.

7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.

8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence password hacker, network hacker. The correct term for this sense is cracker.

If you disagree, then please cite an authority other than yourself.

Thank you, Vatican, for using the word "hacking" in the original sense as hackers themselves defined it. Before the mainstream press appropriated it and turned it into a perjorative.

How To Become A Hacker, by Eric S. Raymond http://www.catb.org/esr/faqs/h... There's other stuff by ESR, like The Art of Unix Programming: http://catb.org/~esr/writings/... But essentially, I think you'll find the first web page gives you a good start.

How To Become A Hacker, by Eric S. Raymond http://www.catb.org/esr/faqs/h... There's other stuff by ESR, like The Art of Unix Programming: http://catb.org/~esr/writings/... But essentially, I think you'll find the first web page gives you a good start.

My phone can run the same software that I ran on a Cray Y-MP4 in college.And with a 4x better clock speed and 128x more memory should do it just as fast. A dumb terminal like a vt-100 was a 2MHz 8bit computer. Yes, it too was a computer, but had no way of loading user software. Have you ever used a dumb terminal?

Yes, I have used a dumb terminal.

Have you ever used a smartphone without network access? It turns about as dumb as your argument here.

My phone can run the same software that I ran on a Cray Y-MP4 in college.And with a 4x better clock speed and 128x more memory should do it just as fast. A dumb terminal like a vt-100 was a 2MHz 8bit computer. Yes, it too was a computer, but had no way of loading user software. Have you ever used a dumb terminal?

Eric Raymond laid out this problem over 20 ywars ago, in his essay "The Luxury of Ignorance". ( http://www.catb.org/esr/writin... )

Now, me? On Linux, I build nad use "vtwm" and avoid all the Gnowme and KDE nuttiness. Lightweight, fast, rock stable, and gives an expandable set of multiple virtual screens for organizing my work.

who prescribed another antibiotic which cleared it up almost immediately (like the next day thankfully), and hilariously ginger-ale as apparently even after only a couple of days I was severely dehydrated

The ginger ale isn't in the least bit amusing. It - and variants - are SOP for dealing with significant dehydration where the patient is otherwise not suspected to have gut damage and is unlikely to lose consciousness unattended. Clearly, you want to get fluids into the patient ASAP.

Now, the next bit is going to be heretical for those religiously sucking the nipple of their bottle of Perrier to "stave off dehydration".

Water isn't much good for curing dehydration. Give most people a couple of litres of water and instructions to "drink that as soon as possible", and you're more likely than not to have puke on the floor, and still need to get several litres of water inside the patient. A WOMBAT. Do the same with orange juice, and as like as not you'll get over a litre of water (plus various salts and minerals) into the patients blood stream per hour. your quack prefers ginger ale to orange juice ; "meh".

Of course, if your patient has (e.g.) a perforated gut, then you're making the problem worse. you do need to do your diagnosis first. I encountered this in the mountain rescue context with someone down through hypothermia or exhaustion, but no physical damage. With good patient management you can often get them to walk themselves back to safety. And the OJ is a useful tool in that.

He should add "programmer" to his LARP resume

"We didn't know how good we had it back then. In the 1980s IBM had its own troubles with Microsoft and lost its strategic way, receding from the hacker community's view. Then, in the 1990s, Microsoft became more noxious and omnipresent than IBM had ever been."

-Jargon File: IBM

Not as bas as CUPS. Seel

* http://www.catb.org/esr/writin...

The essay was writen in 2006, and the basic CUPS configuration has not fixed a *single one* of the problems Eric Raymond described.

You need either a monolithic architecture or a performance hit to do certain common user-based operations (what if someone plugs in a USB stick? what if they unplug it while it's being read and something else is waiting?

Motherfucker, read what I linked to which addresses your point. You have no clue what the unix way is, and are an ignorant ass for even talking about it without doing a bit research.

The issue with desktop systems is they need to be responsive in ways which violate The Unix Philosophy or are bogged down by adhering to it.

This is a horrible misunderstanding of the unix way.

If someone with an understanding of the unix way came along, figured out the problems systemd is trying to solve, and implemented them, then you would see a system without all the poor architectural choices of systemd. The reason systemd has trouble is because the developers don't understand the unix way.

The issue with desktop systems is they need to be responsive in ways which violate The Unix Philosophy or are bogged down by adhering to it.

This is a horrible misunderstanding of the unix way.

If someone with an understanding of the unix way came along, figured out the problems systemd is trying to solve, and implemented them, then you would see a system without all the poor architectural choices of systemd. The reason systemd has trouble is because the developers don't understand the unix way.

http://www.catb.org/jargon/htm...

All nouns can be verbed, and all verbs can be nouned.