In "The Evolution of the Unix Time-sharing System" by Dennis Ritchie, he writes:
> Although it was not until well into 1970 that Brian Kernighan suggested the name ‘Unix,’ in a somewhat treacherous pun on ‘Multics,’ the operating system we know today was born.
I like this paper for its thorough description of the very earliest versions of the operating system.
It is both fascinating and amusing to note that significant innovation came from talented peoples' frustration with software-development complexity, bureaucracy, and paralysis.
It's not either/or; many high quality news sources have clickbait rubbish stories to help pay the bills for the more expensive, higher quality reporting. It's either that, or paywalls (or both)
Why not just design for deep sea exploration or nuclear applications directly? It's a heck of a lot cheaper to test prototypes in the ocean than on Venus.
Joking aside, they've snuck up on me more than once when I'm about to cross the street and they're trying to right-on-red. I'm surprised they don't have some artificial noise to improve awareness.
Their market analysis, just like every other discussion of commercial space exploration I've ever seen, is circular. Space solar power, space manufacturing, space mining, space refueling... the only reason to do any of those things is if you have some other reason to be in space in the first place. (And in this case, near the moon!)
Don't we? We push objects from Earth to GEO all the time. If they could get their fuel along the way, it seems like that would reduce the cost of sending a satellite up to GEO.
It would also lighten the load of the launch, meaning we could put much heavier things in orbit.
Getting that fuel to objects in orbit will require a significant infrastructure, and huge up front costs, but someone clearly sees a calculus that results in a net savings over time.
If we can get that infrastructure built, it becomes much more reasonable to start looking at other things near Earth as potential resource sites -- asteroids in particular. All sorts of metals are out there in ahem astronomical quantities.
I see this as an exercise in improving what we're currently doing (let's get some gas stations installed between home and orbit), followed by innovation/new industries.
It could be environmental regulations are what finally push economic activity out into space. At the Recode conference a few weeks back, Jeff Bezos (Amazon, Blue Origin) stated his wish to see heavy industries and manufacturing moved into the celestial realm, beyond our precious atmosphere and land, leaving the earth pristine and less-polluted.
The problem is that moving heavy industry into space has to compete on a cost benefit basis not with doing those things in a dirty way on earth but with doing them cleanly on earth.
It may be more expensive to do manufacturing cleanly, but it's not that much more expensive.
I tend to think there are opportunities up there, but they're primarily in mining and the infrastructure support that. There are opportunities in tourism of course, but those are small compared asteroid mining.
SDL is written in C, and it has a much more pleasant way of dealing with heterogeneous event types. There is a struct called SDL_Event, which you fill by calling SDL_PollEvent() until there are no more events to read. The struct is a (discriminated) union of all the possible event types. (It even wraps the Win32 API, so it is very directly comparable -- it is returning the same events!)
I tried to learn "modern" C++ style, and watched many, many videos from cppcon, but I just don't feel like I understand how to do it. I started a C++ project, #included <vector> and all the rest, and tried to do things the way the experts recommend, but I had no confidence that I was doing any of it right.
I know all the copying and moving and whatnot is supposed to "just work", but as far as I can tell, there's no easy way to verify that your program is doing what you intend. There also aren't any compact guidelines -- "follow these N simple rules and the STL won't explode!". With most other languages, I can at least think through the program to figure out if it is going to do what you intend, but the way that the STL is implemented to support all the modern C++ behavior requires a brain the size of a planet to understand.
I'm sure Stroustrup and the committee can write Modern C++, but I sure can't. Not with any confidence, anyway.
No one said that C++ is easy, you need to teach yourself about pointers even if you will not use them so often, because almost everything under the hood is connected to pointers in some way. You need to learn the language.
Watching video from ccpcon is not the way you will learn C++. Read book from Stroustrup about C++.
I don't have any trouble with pointers. I can understand C programs just fine. But Modern C++, as the evangelists love to point out, is specifically about avoiding raw pointers in favor of smart pointers, value semantics, etc. That's the stuff that I find difficult to use.
I did buy Stroustrup's post-C++11 book, "A Tour of C++", which is supposed to be the compact "how to do Modern C++". It provides tips, but as I mentioned above, I did not find it comprehensive enough. Terse recommendations like "Prefer returning by value" may be great small-scale recommendations, but they don't explain how the big picture is supposed to come together.
You should watch those cppcon again, because Stroustrup and Herb are saying there many times that smart pointers are NOT should be use instead of raw pointers. Use smart pointers where It's about ownership. You should watch this video:
Plan 9 was a research OS that was sort of intended to be a "next generation" Unix. The Golang project is led by at least one person who worked on the Plan 9 OS, and overall it seems to be heavily inspired by Plan 9's design.
Yes, I know that. But I don't understand the implication that Go came magically from Plan 9. I recall reading Kernighan stating that the first Go compiler was written in C++ before bootstrapping.
Sorry, I misunderstood your comment. I think the original poster was referring to the Plan 9 team's strong preference for C over C++. Plan 9 was written with a modified version of C, and the developers seemed to be very interested in evolving the C language. As far as I can tell, they never used C++.
> In the presentation before the awarding of the Japan Prize today, you were quoted on the distinction between research and development. [The former, Thompson stated, was directionless, whereas development had a specific goal in mind.] So in that context, is Go experimental?
> Yes. When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] [1]
It looks like you were half-right about the early Go compiler being partly written in C++: There were two compilers, and "gccgo" had a C++ front-end, while their homemade compiler "gc" was written entirely in C. [2]
I wonder what fraction of male Computer Science majors also come into their first semester with no programming experience. When I was a freshman, it seemed like absolutely everyone in my CS classes had been programming for years, but surely that's not the case for everyone?
Anyway, the bit about (comparatively) experienced programmers intimidating the other students in freshman classes is a real and terrible thing. I thoroughly support shoving all those students into a different class; it is disruptive to have them in an intro course.
I can't speak about today, but when I started college (1995), it was common for students in the intro CS course to have zero experience coding. Some had built basic web pages, some had used *nix machines, but not many with actual coding.
But, this course was also required for ALL engineers, so there were many separate sections/classes, and probably 80% or greater weren't interested in CS as a degree/career.
I suspect, although I don't have the numbers, that there is a huge difference between 1995 and today. Open source was barely on most people's radar screens in 1995 and you're talking about the very early days of widespread Internet access.
I think '95 was the first or second year for campus-wide high-speed internet at UVA. VT was a year ahead and one of the first in the nation, if I remember correctly.
All that said, the approach of splitting the introductory class up by previous experience makes some sense. I can't think of too many other subjects where the experience level would differ by so much at such an entry-level stage.
Well that was 1995. At the time I was still getting beat up for being a computer nerd. Can you imagine someone getting beat up for using a computer today? The way I explain it is that it's almost like the 90s were in another century.
I took a MOOC offered by one of the elite schools that was based on their intro CS programming class. Although I'm not a programming professional, I've done a fair bit and have at least a degree of familiarity with the language the course used--as well as some basic concepts like sort algorithms, etc.
For me, the course wasn't exactly hard but it certainly wasn't trivial and, had I never written a program (or touched a command line), I'm sure I would have been completely and utterly lost. Sign up for any MOOC in this vein and there are obviously lots of people for whom it's a totally bewildering experience.
By comparison, when I took my first computer class in college, it was a truly introductory FORTRAN course that really didn't assume any prior knowledge. I did have a little BASIC in high school but that wasn't very common at the time.
I had the most advanced programming experience my high school offered (Q-Basic baby), but 100 level programming classes were pretty insane. Would have helped to maybe have a few more new to programming type classes with others in the same boat...
In my experience as a CS teacher at a university, probably 20% with no experience, and another 30% with a little experience. About 5% are already mature programmers when they come to university.
> Although it was not until well into 1970 that Brian Kernighan suggested the name ‘Unix,’ in a somewhat treacherous pun on ‘Multics,’ the operating system we know today was born.
I like this paper for its thorough description of the very earliest versions of the operating system.