Aaron Swartz: murdered by the LISP cabal

The LISP cabal killed him for rewriting Reddit in Python.

not funny

I've suspected as much. There was an article in the Jew York Times about the murder that quoted the Abelson as wishing he could have seen the light leave his eyes as he strangled to death. That bit was removed within a day, and the article was gone in a week. Now not even archive.org has it. What are the Lisperati hiding?

They probably killed him for daring to use a Lisp for such a terrible thing in the first place.

If that's true, he deserved it.

We had this conversation before with memory leaks. Turns out no matter how hard we try, we cannot teach programmers to not to forget to release manually allocated memory. So GC was born.

In fact it is even more general trend: automation. Taking away as many manual tasks from humans as possible. Humans are the weakest link in the process. Ideally removing them completely is the final goal. But until we acheieve this the next best thing is to take away as many small tasks from humans and giving them to machines.

Another example is sql. When the decision on how to find the data was taken away from humans and given to software (sql server). Humans only tell what to find (using sql language). Move from imperative to declarative.

All these changes over the time fit one major direction: automation of programmers work. Squeezing out humans from lower levels to higher levels, leaving lower levels to machines that are much more trustworthy.

The next big fight is over the manual state management. This is what's happening right now with all the push towards immutable data. Basically humans are forbidden to change manually the global state, just how they were forbidden in the past to manually allocate memory (GC replaced them) and to manually write loops to find the data (sql replaced old pre-sql code)

This simply leads to a much better software (less bugs). The less humans do, the better the software is.

Of course there always be the case for low level work (mostly OS level, drivers, embedded software etc) Where the requirements are too stringent (space, real time reponse etc) But those are really a very fringe niche. How many programmers you know who nowadays write kernell level code?

And the last thing, A lot of programmers think it is their choice. That they decide whether they gonna use certain languages with certain features. The reality though is it is the industry that decides. And we will be forced to use what's benefitial for industry, whats benefitial for business. Just like entire industry moved to java and dotnet (languages with GC) soon the entrie industry will move to languages that either make it too hard or even outright forbid humans manually changing the global state.

We used to think of ourselves as job destroyers. We automate other people's work. But automation affects our profession just like every other one.

Tell your friend to brace himself for the tough times ahead :)

>>6
I just had a cool idea

what about a static analysis/abstract interpreter type thing which analyzes your code with a conservative approximation to ensure that you free everything you malloc.

Then you don't have or use GC, but it's also certain to detect memory leak problems.

>>6
Nice copypasta. Microprocessor hardware is soon going to hit limits of lithography and cost of fab construction.
The cost of hardware will eventually stop dropping:it would make no sense to produce cheaper processors/SoCs of same type.
Asm/C/C++ is going to have a huge resurgence when businesses realize cost savings for hardware are worth the time of development.
Macro Assemblers will have a comeback, C++ would likely surrender to speed demands and become more like C today.
All the high-level garbage collected crap would be relegated to niche hobbyist devs.

>>6
I use Lisp to generate embedded assembly code, feeding the embedded toolchains. The code can deal with the cycle counting shit decently enough that I don't have to bother.

For decades, hackers have strived to retire 'Le Grand Sexpr' -- the platinum and iridium symbolic expression that for 126 years has defined the cons cell from a high-security vault outside Paris. Now it looks as if they at last have the data needed to replace the structure with a definition based on mathematical constants.

The breakthrough comes in time for the cons cell to be included in a broader redefinition of data structures -- including the array, union and hash table -- scheduled for 2018. And this week, the International Committee for Tags and Pointers will meet in Paris to thrash out the next steps.

"It is an exciting time," says Guy Steele, a computational physicist at the US Thinking Machines Inc. "It is the culmination of intense, prolonged efforts worldwide."

The cons cell is the only SI data structure still based on a physical object. Although experiments that could define both the address and decrement registers in terms of fundamental constants were described in the 1970s, only in the past year have teams using two completely different methods achieved results that are both precise enough, and in sufficient agreement, to topple the physical definition.

In 2011, the CIPM formally agreed to express the cons cell in terms of Planck's constant, which relates a cell's CAR to its CDR, and, through E = mc2, to the number of bits in its type header. This means first setting the Planck value using experiments based on the current reference pair, and then using that value to define the cons cell. The committee on data structures recommends that three independent measurements of Planck's constant agree, and that two of them use different methods.

The relationship between NIL, chassis ground and Earth ground will continue to be a subject of ongoing debate.

>>6

automation. Taking away as many manual tasks from humans as possible.

So job security == writing cryptic, hard-to-check code
Unsafe C++(C++ is harder to parse than C) and macros. Anti-analysis techniques(e.g.runtime data dependencies) to thwart automated correctness proofs + abuse of built-ins and compiler specific extensions.

Writing cryptic, hard-to-check code will get your ass fired more often than not. "Not a team player" at the very least.

>>11
..and by proxy, writing this type of code helps other humans
maintain their advantage over machines.

>>12
Njust make open-source code anonymously that they can't touch and pull it in as dependency.

Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?

Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.

Interviewer: Problem?

Stroustrup: Yes, problem. Remember when everyone wrote Cobol?

Interviewer: Of course, I did too

Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty.

Interviewer: Those were the days, eh?

Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen.

Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better.

Stroustrup: Exactly. Well, the same happened with 'C' programmers.

Interviewer: I see, but what's the point?

Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.

Interviewer: You're kidding...?

Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?

Interviewer: You bet I do, that's what I used to do.

Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.

Interviewer: I don't believe you said that...

Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.

Interviewer: So how exactly did you do it?

Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.

Interviewer: What?

Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code?

Interviewer: Well, never, actually, but...

Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about '90 or '91. I felt sorry for them really, but I thought people would learn from their mistakes.

Interviewer: Obviously, they didn't?

Stroustrup: Not in the slightest. Trouble is, most companies hush-up all their major blunders, and explaining a $30 million loss to the shareholders would have been difficult. Give them their due, though, they made it work in the end.

Interviewer: They did? Well, there you are then, it proves O-O works.

Stroustrup: Well, almost. The executable was so huge, it took five minutes to load, on an HP workstation, with 128MB of RAM. Then it ran like treacle. Actually, I thought this would be a major stumbling-block, and I'd get found out within a week, but nobody cared. Sun and HP were only too glad to sell enormously powerful boxes, with huge resources just to run trivial programs. You know, when we had our first C++ compiler, at AT&T, I compiled 'Hello World', and couldn't believe the size of the executable. 2.1MB

Interviewer: What? Well, compilers have come a long way, since then.

Stroustrup: They have? Try it on the latest version of g++ - you won't get much change out of half a megabyte. Also, there are several quite recent examples for you, from all over the world. British Telecom had a major disaster on their hands but, luckily, managed to scrap the whole thing and start again. They were luckier than Australian Telecom. Now I hear that Siemens is building a dinosaur, and getting more and more worried as the size of the hardware gets bigger, to accommodate the executables. Isn't multiple inheritance a joy?

Interviewer: Yes, but C++ is basically a sound language.

Stroustrup: You really believe that, don't you? Have you ever sat down and worked on a C++ project? Here's what happens: First, I've put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module. Try pulling that lot together, when you have a hundred or so modules. And as for data hiding. God, I sometimes can't help laughing when I hear about the problems companies have making their modules talk to each other. I think the word 'synergistic' was specially invented to twist the knife in a project manager's ribs.

Interviewer: I have to say, I'm beginning to be quite appalled at all this. You say you did it to raise programmers' salaries? That's obscene.

Stroustrup: Not really. Everyone has a choice. I didn't expect the thing to get so much out of hand. Anyway, I basically succeeded. C++ is dying off now, but programmers still get high salaries - especially those poor devils who have to maintain all this crap. You do realise, it's impossible to maintain a large C++ software module if you didn't actually write it?

Interviewer: How come?

Stroustrup: You are out of touch, aren't you? Remember the typedef?

Interviewer: Yes, of course.

Stroustrup: Remember how long it took to grope through the header files only to find that 'RoofRaised' was a double precision number? Well, imagine how long it takes to find all the implicit typedefs in all the Classes in a major project.

Interviewer: So how do you reckon you've succeeded?

Stroustrup: Remember the length of the average-sized 'C' project? About 6 months. Not nearly long enough for a guy with a wife and kids to earn enough to have a decent standard of living. Take the same project, design it in C++ and what do you get? I'll tell you. One to two years. Isn't that great? All that job security, just through one mistake of judgement. And another thing. The universities haven't been teaching 'C' for such a long time, there's now a shortage of decent 'C' programmers. Especially those who know anything about Unix systems programming. How many guys would know what to do with 'malloc', when they've used 'new' all these years - and never bothered to check the return code. In fact, most C++ programmers throw away their return codes. Whatever happened to good ol' '-1'? At least you knew you had an error, without bogging the thing down in all that 'throw' 'catch' 'try' stuff.

Interviewer: But, surely, inheritance does save a lot of time?

Stroustrup: Does it? Have you ever noticed the difference between a 'C' project plan, and a C++ project plan? The planning stage for a C++ project is three times as long. Precisely to make sure that everything which should be inherited is, and what shouldn't isn't. Then, they still get it wrong. Whoever heard of memory leaks in a 'C' program? Now finding them is a major industry. Most companies give up, and send the product out, knowing it leaks like a sieve, simply to avoid the expense of tracking them all down.

Interviewer: There are tools...

Stroustrup: Most of which were written in C++.

Interviewer: If we publish this, you'll probably get lynched, you do realise that?

Stroustrup: I doubt it. As I said, C++ is way past its peak now, and no company in its right mind would start a C++ project without a pilot trial. That should convince them that it's the road to disaster. If not, they deserve all they get. You know, I tried to convince Dennis Ritchie to rewrite Unix in C++.

Interviewer: Oh my God. What did he say?

Stroustrup: Well, luckily, he has a good sense of humor. I think both he and Brian figured out what I was doing, in the early days, but never let on. He said he'd help me write a C++ version of DOS, if I was interested.

Interviewer: Were you?

Stroustrup: Actually, I did write DOS in C++, I'll give you a demo when we're through. I have it running on a Sparc 20 in the computer room. Goes like a rocket on 4 CPU's, and only takes up 70 megs of disk.

Interviewer: What's it like on a PC?

Stroustrup: Now you're kidding. Haven't you ever seen Windows '95? I think of that as my biggest success. Nearly blew the game before I was ready, though.

Interviewer: You know, that idea of a Unix++ has really got me thinking. Somewhere out there, there's a guy going to try it.

Stroustrup: Not after they read this interview.

Interviewer: I'm sorry, but I don't see us being able to publish any of this.

Stroustrup: But it's the story of the century. I only want to be remembered by my fellow programmers, for what I've done for them. You know how much a C++ guy can get these days?

Interviewer: Last I heard, a really top guy is worth $70 - $80 an hour.

Stroustrup: See? And I bet he earns it. Keeping track of all the gotchas I put into C++ is no easy job. And, as I said before, every C++ programmer feels bound by some mystic promise to use every damn element of the language on every project. Actually, that really annoys me sometimes, even though it serves my original purpose. I almost like the language after all this time.

Interviewer: You mean you didn't before?

Stroustrup: Hated it. It even looks clumsy, don't you agree? But when the book royalties started to come in... well, you get the picture.

Interviewer: Just a minute. What about references? You must admit, you improved on 'C' pointers.

Stroustrup: Hmm. I've always wondered about that. Originally, I thought I had. Then, one day I was discussing this with a guy who'd written C++ from the beginning. He said he could never remember whether his variables were referenced or dereferenced, so he always used pointers. He said the little asterisk always reminded him.

g++ -O3 "helloworld.cpp" results in 2700K file.
gcc -O3 "helloworld.c" results in 17k file.
g++ -O3 "helloworld.c" results in 132k file.
The main bloat is due iostream

>>11
Actually you should roll your own open-source incompatible C++ on top of
https://en.wikipedia.org/wiki/GObject
and make all code depend on it

>>17
..also combine with liberal use of void.h macros(they're practically impossible to debug beyond nesting level of about 5-6 layers)

>>17
GObject is shit.

>>16
Try with -Os.

>>19

GObject is shit.

That's exactly the point. We want to make it even more esoteric and difficult to traverse the code.

>>18
void.h is weaksauce:
https://esolangs.org/wiki/ELIP

CHECK EMMMMMMMMMMMMMMMMMMMMMMMMMMMM!!!!!!!!!!!!!!!!!!!!!!!!!!!LOLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLOL!

>>21
Its amazing how powerful simple text macros are and yet
not a single major improvement in preprocessor has
occured in 15 years(last one was variadic arguments).
you could add #regex args.replace()
recursive macros, conversion of expression to token and back

ability to do math in preprocessor(instead of
increment lists and #if #define tricks), or even simple things like multi-line macros.
C preprocessor is like Stephen Hawking, doing simple things
the hard way and slowly overcoming the limits of his situation.

>>23

C preprocessor is like Stephen Hawking, doing simple things

the hard way and slowly overcoming the limits of his situation.

That is, of course, the way of C. The way of C++ is to dogpile the standard with winners of Obfuscated C++ contests.

>>24
Actually the "Obfuscated C++" is attempt to introduce
functional programming into C++(without macros) using the
facilities of ADL/operator overloading and
template metaprogramming.

>>25

functional programming into C++

So people obfuscate C++ to embezzle grant money?

>>26
No, they do it for free because they want to convert C++
into a functional paradigm-type language(in the current state it can't get any worse).

>>23
https://github.com/eudoxia0/cmacro

>>28
So the solution is to write semi-lisp and be dependent on huge
Lisp compiler masquerading as preprocessor?

>>27
No, they do it because they're jealous of other languages that have reasonable language features at the ground level.

They refuse to get away from their ultra-static crippled worldview of code, and bolt on the most convoluted weird shit they can think of, because that's the only way to express such concepts in that environment.