"A stream oriented method of encoding multiple simultaneous connections". Hrmm, I'm sorry. I think I heard of one once, in fact 2 or 3 of them, PPP or SLIP anyone?
Despite the moaning and groaning on the forum here about XML, I happen to like it. Its all well and good for keeping information in human readable form, and makes writing extractors fairly painless.
The main strength that it has is it could provide a mechanism to exchange freeform XML metainformation about the channels to the applications without requiring the applications to reinvent the wheel each time. I like this aspect of the protocol, but I think it could be done with less baggage, by leveraging the existing lower level protocols more.
The main barrier it has to adoption is that it is yet another protocol that will have to be micromanaged by firewalling software. I do like the fact that this could probably be run raw over any serial link, but again, you could just use PPP.
I mean, it doesn't go far enough. There are no templates or constrained generics, no support for design by contract, but its not bad.
I like the 'unsafe' keyword, reminds me of Modula-3, being able to section off code that you aren't sure won't crash the system, yet still letting someone write efficient code in a crunch. (Java's lets-force-them-to-offload-it-via-JNI approach doesn't work, JNI has too much overhead for many cases)
I like the return of operator overloading. In fact, the lack of overloading was one of the primary concerns which prevents me from using java in my day to day work. (I do a lot of matrix arithmetic, and it gets tedious and confusing entering this as function calls) I can understand why Java doesn't support overloading (no clear location for where it will reside, the programmer has to check both objects, etc...) but nevertheless I find it a tool that is useful when properly applied. It is just misapplied too often. However, I'm not going to prevent a trained professional from cleaning my deck with a powerwasher and force him to use a toothbrush instead simply because some yutz once hurt himself.
Its almost painfully familiar looking to anyone who has spent enough time in java and c++, which is both good and bad in a way, given that you'll tend to make mistakes, simply because you'll backslide into the behavior from one or the other that doesn't apply.
I did not see inner classes or anonymous classes, which is a shame as those are two Java constructs that I found useful. I know that they aren't original to Java, no flames please.
I don't like the return of the struct keyword, it is superfluous in a language of this type, and leads to recoding later. I can see its merits in the way they have applied it, to provide pass-by-value semantics, however I feel that this approach will cause confusion in practice, especially in a large project as you can't know if you are passing by value or reference without actually looking at the definition of the type of the parameter you are passing in (which is probably in another file). Simply looking at the function in question will not provide you with enough information.
All in all, if they had implemented some form of templates, I would have seriously considered using the language, as the rest of the design would allow me to leverage both my existing c++ and java programmers on a single project. However, without templates, I still have performance concerns for the types of applications on which I work . These qualms shouldn't really affect its target audience however, as templates aren't often required in the microsoft cut-and-paste templated mini-application development environment, and with built-in, fairly clean, COM support, it should be able to do rather well in its target market, judging simply on technical merits.
Unacceptable publications include, but are not limited to:
Material that is ruled unlawful in the jurisdiction of the originating server (Such as child pornography, in the case of our flagship Sealand datacenter)
Since you will be taking over the operations of the government of Sealand, will Prince Roy and family retain any form of executive power?
Secondly, has any decree been made limiting Sealand's abilities to add something to this list when it becomes inconvenient to host it any longer? If I was planning on hosting content in Sealand, and had gone through all the trouble of colocating, paying for bandwidth, and dealing with all of the requisite hassles of the arrangement, I would still have no guarantee that my site would remain 'legal' in the eyes of Sealand.
The data haven concept worked in Neal Stephenson's Neuromancer because the government had declared that it would make no laws impeding the flow of information. In the absence of something similar I am in fact, more leary about undesirable content being pulled in Sealand than I would be hosting in a jurisdiction where what is allowed and what is not allowed is well defined and harder to change.
What is being done to assure would-be content providers whom wish to host in Sealand?
The originating server in this case (from the line right after what you quoted obeys the laws of Sealand because this particular (and the only existant) site is in Sealand.
Sealand's laws prohibit child pornography.
They are not referring to the country of origin for the data. They are referring to the laws of the location of the Haven.
I do find it awkward that in trying to establish a Haven with freedom from arbitrary governmental controls, that they's still put in the disclaimer that 'Unacceptable publications include, but are not limited to' - which gives them the means to exercise control arbitrarily at the company level. Furthermore, it makes me leery of colocating there even if I was considering it to start. It lets them buckle to outside pressure and leave the company/individual who'd invested the time and money in colocation and hosting holding the bag when, for instance, they add MP3's to the list.
So really what are you gaining my moving your data to Sealand? In Cryptonomicon, the Data Haven works because the government in question had made a decree that they would not make any laws controlling the flow of information. With Sealand you do not have that assurance, and in fact with the disclaimer in the acceptable use policy you have to worry about either arbitrary royal decree or the HavenCo buckling under pressure.
Remote terminal, yes. X-terminal, no. VT-100's are just 80x25 or 132x25 text all the way. I've got a half dozen of them sitting around. No they are not for sale. They setup pretty easily on a serial line to a linux box. man getty for more info.
Anyone who has written an app that has to run on multiple platforms has bothered with it. And the solution is downright trivial. Add a macro or function for swapping when saving/loading a structure to/form disk or to/from something that doesn't use your native format. Its NOT that big of a deal. Sorry, pet peeve. 40 lines of code later you can be endian-safe with a little bit of discipline to use it.
what I'd really like is a little PCI card which took in a 10 baseT ethernet jack and had a little processor on it, enough to do DHCP to get an address, and run a telnet connection in lieu of the serial connection detailed here, maybe some other functionality would be handy if you've already got that much in place, but it shouldn't cost much. a 68EN360 should be able to serve as both processor and ethernet controller. Should be cheap enough to implement. It would be even more useful if it ran on a separate power channel from the power supply so that it could actually reboot the system in question. It could show up as an MDA to the system, queue up boot info. you might even get fancy and throw a little webserver on it with a VNC server or something.
I would like to point out that my posting of the fictitious interview was meant to inject a some levity into the discussion, and not to mislead people into believing that Bjarne's motives in introducing C++ were anything but altruistic.
I do appreciate the link to the real interview though.
Is there any hope for the introduction of constrained templates? Right now using templates is an exercise in willpower for the programmer. I know that constrained genericity went before the committee when templates were first introduced, but has there been any thought to revisiting that decision?
Another item that has gained a lot of momentum in the Eiffel community is Design by Contract, for which I would love to see a standardized approach in C++, but I doubt I'll ever see it.
Lastly, Bjarne, you were quoted once as saying 'When (not if) reference counting becomes available in C++ that it would be optional' (in a book on object oriented programming languages of which I cannot find on amazon at the moment to post the ISBN). Has much progress been made on the front of making reference counted objects available? Or has your thinking changed since you were quoted?
Actually, seeing this brings to mind another 'Interview' with Bjarne that I saw a while back....
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..
Interviewer: Well, at this point, I usually say 'thank you very much' but it hardly seems adequate..
Stroustrup: Promise me you'll publish this. My conscience is getting the better of me these days..
Interviewer: I'll let you know, but I think I know what my editor will say..
Stroustrup: Who'd believe it anyway? Although, can you send me a copy of that tape?
If you like the thought of foldable screens, watch out for eink. (www.eink.com) they have been doing some work in that direction, although their current products are a but too um, macroscopic, for such a use as of yet.
I'd just like to amend a couple of your points: In partial rebuff to your first statement, I agree that Python is a hell of a lot slower than Java. JPython in my experience is about half the speed of CPython (Stackless or not). I had previously hoped that being able to leverage the JIT under JPython would gain me speed, but it proved not to. JPython is slower than CPython because it still has to do many dictionary lookups and it has to do those in java (well java bytecode).
Python gets compiled down to bytecode just like java in both CPython and JPython. So does Perl for that matter. It can be JIT'd but no one has done so as of yet with pure python, and jpython w/ JIT is a bit unreliable as of yet. (The java bytecode comes out like a java compiler on drugs, and some JITs don't seem to like it all that well)
JPython's speed hit over Java comes from the fact that it does name binding of everything at runtime, there is no concept of a final method, and everything has to come through a dictionary. Java can cache many of these things, but Python gives too much Smalltalk like message method handling controls for many of these facilities to work.
And all of your endorsements for java double as endorsements for JPython. I can just as easily import the java library into my JPython app.
Python makes a very good scripting language when you get beyond munging text. I choose to use Python in the contexts that I do because of what the language gives me, it compiles to bytecode, the interpreter is easily embeddable, SWIG gives me shadow classes for all my C++ classes, which I can then extend in python and actually call into the python code through the extended interfaces. The ability to distribute code in bytecode form means you don't have to open your source if you don't want to, and it has a security module, much like java so you can lock script-writers into a sandbox when you are embedding in a game environment.
The downside of python (and jpython) is the speed of execution. Perl runs circles around Python in all my tests.
JPython compiles to Java bytecode which lets me leverage java technologies (the security api, servlets, etc) whereas Stackless Python gives support for first class continuations (coroutines).
At this stage, JPython is winning for me, because even though my execution slows down I can move to java where speed becomes an issue and to C++ where it becomes critical.
I can't run Perl in a sandbox if I don't trust the perl developer. I can clamp down pretty hard on Python however, which is important to me for openWar. (I think you can guess the gist of the project)
Also, when using a lot of objects Python's syntax is less quirky than Perl's, which makes me feel safer bringing in other developers with limited knowledge of the language.
If you bring in a newbie Perl programmer, Perl object syntax usually seems incredibly arbitrary (until they've gone through how hash's work and blessings, etc) If you bring in a newbie Python programmer, the object syntax is pretty intuitive, no worries about when to use {} and ->{}, etc.
I use both languages, but I find Perl to be effective when I'm writing highly text oriented code, or scripts, and Python when I need the sandbox and heavy access to C++ objects and an oop framework.
There was a study done a while back on integrating voice and mouse controls. Using voice to issue the commands and the mouse to point to what they affect. As I recall there were appreciable performance gains in the tasks tested (like 30%) but I cannot remember the group who did the study.
I agree that voice control alone is a dead end, but it has potential when integrated with other techniques for target designation.
.* will catch.. as well as your . files, which could be a bad thing, watch out, usually you'll want something like chmod permission.[^.]*..?* to catch all your dot files other than.. (only if you're being really anal retentive) =)
This book is one of the best written programming books that I have found in a long time.
The subtitle 'From Journeyman to Master' almost put me off of buying it (as I found it rather condescending), but after flipping through I decided the authors had enough to say to justify the purchase.
Much of the premise reads like a Design Patterns book, if you like Design Patterns, most of their material will jive with your thinking.
The rest revolves around scalability and maintainability of code, much like Jon Lakos's Large Scale Programming in C++. I just can't stress enough how well this book clicks with my thinking on large scale programming projects. Reading it was a continual series of 'Yeah, I do that' and 'Hey, thats a pretty good idea'.
The section on active and passive code generators is a worthy read, and its one of the few books which stress refactoring solutions, which do not bash the occasional one-shot quick-and-dirty hack in perl.
The section on tracer code vs. prototyping provides some good ways to manage expectation levels. (the 'ship the prototype' problem)
The section on orthogonality and Design by Contract contained some very good material on regression testing and controlling assumptions. Design by Contract introduced some ideas that I haven't seen expressed before in a programming text that are definitely worth reading.
All in all, I found this book a welcome addition to my bookshelf, which already contains a good amount of design and programming material for which I would not give this same endorsement.
In my haste i screwed up the typedefs they should be
typedef TextureTemplate<GLTextureImpl, GLRendererImpl> GLTexture; typedef RendererTemplate<GLRendererImpl, GLTextureImpl> GLRenderer; thats why i get for writing this stuff off the top of my head.
Yes, it is. My favorite pattern for implementing the 'virtual classes' concept follows. (Then again because it relies on langua ge specific features like templates, isn't it really an idiom? oh well, one of these days I'll get anal retentively correct in my pattern-speak)
class Texture { public: virtual ~Texture() {} virtual void makeCurrent()=0; }; and implementing the linking back behind the scenes for each one, or getting fancy and making a couple of templates used to bui ld boilerplate links. (I seem to recall that being used in the FSM example in C++ Gems) I.E. if you're too lazy to write linkin g code for each new implementation (not to mention want to avoid repetitive strain injury and bugs from duplicated code you can then go ahead and write a couple of templates like
template <class Baseclass, class TextureBase> class RendererTemplate : public Baseclass { public: typedef TextureTemplate<TextureBase> MyTexture; Texture * loadTexture(const char * name, blah blah blah) { return new MyTexture(this,name, blah blah blah) } }; then for each class you want to use the public interface for and templated implementations of the behind the scenes ties you ca n do something like
class GLRendererImpl : public Renderer { public: void makeCurrent(GLTextureImpl & texture) { ... do gl texture stuff here... } };
class GLTextureImpl : public Texture { public: GLTextureImpl(const char * name, blah blah blah) { load up texture using opengl... } virtual ~GLTextureImpl() {} }; typedef TextureTemplate<GLTextureImpl> GLTexture; typedef RendererTemplate<GLRendererImpl> GLRenderer;
the templates are initially a fair chunk of work, and the pattern density of the above code is pretty dense, but the approach c an be amazingly versatile and cuts down considerably on duplicated code, note that the derived classes only have to focus on their specific implementation, the generalities are taken care of by the template implementations and no typecasting is required anywhere in the system, so there is no worries about accidentally passing say a Directx7Texture object to the GlideRenderer.
The gains don't really start to show until you've got 5-6 implementations in place however.
All of the above code has been slapped together off the cuff and is probably laden with errors and formatting problems from try ing to type it into a slashdot comment box so try to follow my intent vs. my syntax.
P.S. Formatting this was a BITCH, is there a reason why Slashdot doesn't allow the tag? I.E. kept munging my & type chars back into real chars so i had to switch browsers, paste back and forth to vi to regexp things into html-munged form. Hrmmf.
Slashdot Mirror
Despite the moaning and groaning on the forum here about XML, I happen to like it. Its all well and good for keeping information in human readable form, and makes writing extractors fairly painless.
The main strength that it has is it could provide a mechanism to exchange freeform XML metainformation about the channels to the applications without requiring the applications to reinvent the wheel each time. I like this aspect of the protocol, but I think it could be done with less baggage, by leveraging the existing lower level protocols more.
The main barrier it has to adoption is that it is yet another protocol that will have to be micromanaged by firewalling software. I do like the fact that this could probably be run raw over any serial link, but again, you could just use PPP.
Its not bad. Really.
I mean, it doesn't go far enough. There are no templates or constrained generics, no support for design by contract, but its not bad.
I like the 'unsafe' keyword, reminds me of Modula-3, being able to section off code that you aren't sure won't crash the system, yet still letting someone write efficient code in a crunch. (Java's lets-force-them-to-offload-it-via-JNI approach doesn't work, JNI has too much overhead for many cases)
I like the return of operator overloading. In fact, the lack of overloading was one of the primary concerns which prevents me from using java in my day to day work. (I do a lot of matrix arithmetic, and it gets tedious and confusing entering this as function calls) I can understand why Java doesn't support overloading (no clear location for where it will reside, the programmer has to check both objects, etc...) but nevertheless I find it a tool that is useful when properly applied. It is just misapplied too often. However, I'm not going to prevent a trained professional from cleaning my deck with a powerwasher and force him to use a toothbrush instead simply because some yutz once hurt himself.
Its almost painfully familiar looking to anyone who has spent enough time in java and c++, which is both good and bad in a way, given that you'll tend to make mistakes, simply because you'll backslide into the behavior from one or the other that doesn't apply.
I did not see inner classes or anonymous classes, which is a shame as those are two Java constructs that I found useful. I know that they aren't original to Java, no flames please.
I don't like the return of the struct keyword, it is superfluous in a language of this type, and leads to recoding later. I can see its merits in the way they have applied it, to provide pass-by-value semantics, however I feel that this approach will cause confusion in practice, especially in a large project as you can't know if you are passing by value or reference without actually looking at the definition of the type of the parameter you are passing in (which is probably in another file). Simply looking at the function in question will not provide you with enough information.
All in all, if they had implemented some form of templates, I would have seriously considered using the language, as the rest of the design would allow me to leverage both my existing c++ and java programmers on a single project. However, without templates, I still have performance concerns for the types of applications on which I work . These qualms shouldn't really affect its target audience however, as templates aren't often required in the microsoft cut-and-paste templated mini-application development environment, and with built-in, fairly clean, COM support, it should be able to do rather well in its target market, judging simply on technical merits.
heh I mean't Cryptonomicon, not Neuromancer. Wrong author for the book even, whoops.
Secondly, has any decree been made limiting Sealand's abilities to add something to this list when it becomes inconvenient to host it any longer? If I was planning on hosting content in Sealand, and had gone through all the trouble of colocating, paying for bandwidth, and dealing with all of the requisite hassles of the arrangement, I would still have no guarantee that my site would remain 'legal' in the eyes of Sealand.
The data haven concept worked in Neal Stephenson's Neuromancer because the government had declared that it would make no laws impeding the flow of information. In the absence of something similar I am in fact, more leary about undesirable content being pulled in Sealand than I would be hosting in a jurisdiction where what is allowed and what is not allowed is well defined and harder to change.
What is being done to assure would-be content providers whom wish to host in Sealand?
The originating server in this case (from the line right after what you quoted obeys the laws of Sealand because this particular (and the only existant) site is in Sealand.
Sealand's laws prohibit child pornography.
They are not referring to the country of origin for the data. They are referring to the laws of the location of the Haven.
I do find it awkward that in trying to establish a Haven with freedom from arbitrary governmental controls, that they's still put in the disclaimer that 'Unacceptable publications include, but are not limited to' - which gives them the means to exercise control arbitrarily at the company level. Furthermore, it makes me leery of colocating there even if I was considering it to start. It lets them buckle to outside pressure and leave the company/individual who'd invested the time and money in colocation and hosting holding the bag when, for instance, they add MP3's to the list.
So really what are you gaining my moving your data to Sealand? In Cryptonomicon, the Data Haven works because the government in question had made a decree that they would not make any laws controlling the flow of information. With Sealand you do not have that assurance, and in fact with the disclaimer in the acceptable use policy you have to worry about either arbitrary royal decree or the HavenCo buckling under pressure.
If you read their Acceptable Use Policy, HavenCo disallows mail spamming and child pornography on servers colocated in Sealand.
Remote terminal, yes. X-terminal, no. VT-100's are just 80x25 or 132x25 text all the way. I've got a half dozen of them sitting around. No they are not for sale. They setup pretty easily on a serial line to a linux box. man getty for more info.
Anyone who has written an app that has to run on multiple platforms has bothered with it. And the solution is downright trivial. Add a macro or function for swapping when saving/loading a structure to/form disk or to/from something that doesn't use your native format. Its NOT that big of a deal. Sorry, pet peeve. 40 lines of code later you can be endian-safe with a little bit of discipline to use it.
Now people know, it would probably work.
I'd pay $350 for one that had a harddrive mounting bracket off the shelf.
Before the hack no one had even heard of the company.
Now every geek has.
Hopefully they'll release it on DVD. Anyone know if they are planning on opening it in the US anywhere?
Ten people out of how many?
what I'd really like is a little PCI card which took in a 10 baseT ethernet jack and had a little processor on it, enough to do DHCP to get an address, and run a telnet connection in lieu of the serial connection detailed here, maybe some other functionality would be handy if you've already got that much in place, but it shouldn't cost much. a 68EN360 should be able to serve as both processor and ethernet controller. Should be cheap enough to implement. It would be even more useful if it ran on a separate power channel from the power supply so that it could actually reboot the system in question. It could show up as an MDA to the system, queue up boot info. you might even get fancy and throw a little webserver on it with a VNC server or something.
(C++)++ won't do the second increment.
++C++ might though, because the prefix would get applied first, which would return a valid object for the postfix ++ to operate on.
I do appreciate the link to the real interview though.
Another item that has gained a lot of momentum in the Eiffel community is Design by Contract, for which I would love to see a standardized approach in C++, but I doubt I'll ever see it.
Lastly, Bjarne, you were quoted once as saying 'When (not if) reference counting becomes available in C++ that it would be optional' (in a book on object oriented programming languages of which I cannot find on amazon at the moment to post the ISBN). Has much progress been made on the front of making reference counted objects available? Or has your thinking changed since you were quoted?
Actually, seeing this brings to mind another 'Interview' with Bjarne that I saw a while back....
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..
Interviewer: Well, at this point, I usually say 'thank you very
much' but it hardly seems adequate..
Stroustrup: Promise me you'll publish this. My conscience is
getting the better of me these days..
Interviewer: I'll let you know, but I think I know what my editor
will say..
Stroustrup: Who'd believe it anyway? Although, can you send me a
copy of that tape?
Interviewer: I can do that..
If you like the thought of foldable screens, watch out for eink. (www.eink.com) they have been doing some work in that direction, although their current products are a but too um, macroscopic, for such a use as of yet.
Python gets compiled down to bytecode just like java in both CPython and JPython. So does Perl for that matter. It can be JIT'd but no one has done so as of yet with pure python, and jpython w/ JIT is a bit unreliable as of yet. (The java bytecode comes out like a java compiler on drugs, and some JITs don't seem to like it all that well)
JPython's speed hit over Java comes from the fact that it does name binding of everything at runtime, there is no concept of a final method, and everything has to come through a dictionary. Java can cache many of these things, but Python gives too much Smalltalk like message method handling controls for many of these facilities to work.
And all of your endorsements for java double as endorsements for JPython. I can just as easily import the java library into my JPython app.
The downside of python (and jpython) is the speed of execution. Perl runs circles around Python in all my tests.
JPython compiles to Java bytecode which lets me leverage java technologies (the security api, servlets, etc) whereas Stackless Python gives support for first class continuations (coroutines).
At this stage, JPython is winning for me, because even though my execution slows down I can move to java where speed becomes an issue and to C++ where it becomes critical.
I can't run Perl in a sandbox if I don't trust the perl developer. I can clamp down pretty hard on Python however, which is important to me for openWar. (I think you can guess the gist of the project)
Also, when using a lot of objects Python's syntax is less quirky than Perl's, which makes me feel safer bringing in other developers with limited knowledge of the language.
If you bring in a newbie Perl programmer, Perl object syntax usually seems incredibly arbitrary (until they've gone through how hash's work and blessings, etc) If you bring in a newbie Python programmer, the object syntax is pretty intuitive, no worries about when to use {} and ->{}, etc.
I use both languages, but I find Perl to be effective when I'm writing highly text oriented code, or scripts, and Python when I need the sandbox and heavy access to C++ objects and an oop framework.
Regarding the python zealot thing, then what does that say about the existance of Python server pages? PSPs already exist.
I agree that voice control alone is a dead end, but it has potential when integrated with other techniques for target designation.
.* will catch .. as well as your . files, which could be a bad thing, watch out, usually you'll want something like chmod permission .[^.]* ..?* to catch all your dot files other than .. (only if you're being really anal retentive) =)
The subtitle 'From Journeyman to Master' almost put me off of buying it (as I found it rather condescending), but after flipping through I decided the authors had enough to say to justify the purchase.
Much of the premise reads like a Design Patterns book, if you like Design Patterns, most of their material will jive with your thinking.
The rest revolves around scalability and maintainability of code, much like Jon Lakos's Large Scale Programming in C++. I just can't stress enough how well this book clicks with my thinking on large scale programming projects. Reading it was a continual series of 'Yeah, I do that' and 'Hey, thats a pretty good idea'.
The section on active and passive code generators is a worthy read, and its one of the few books which stress refactoring solutions, which do not bash the occasional one-shot quick-and-dirty hack in perl.
The section on tracer code vs. prototyping provides some good ways to manage expectation levels. (the 'ship the prototype' problem)
The section on orthogonality and Design by Contract contained some very good material on regression testing and controlling assumptions. Design by Contract introduced some ideas that I haven't seen expressed before in a programming text that are definitely worth reading.
All in all, I found this book a welcome addition to my bookshelf, which already contains a good amount of design and programming material for which I would not give this same endorsement.
typedef TextureTemplate<GLTextureImpl, GLRendererImpl> GLTexture;
typedef RendererTemplate<GLRendererImpl, GLTextureImpl> GLRenderer;
thats why i get for writing this stuff off the top of my head.
class Renderer {
public:
virtual Texture * loadTexture(const char * name, blah blah blah);
};
class Texture {
public:
virtual ~Texture() {}
virtual void makeCurrent()=0;
};
and implementing the linking back behind the scenes for each one, or getting fancy and making a couple of templates used to bui ld boilerplate links. (I seem to recall that being used in the FSM example in C++ Gems) I.E. if you're too lazy to write linkin g code for each new implementation (not to mention want to avoid repetitive strain injury and bugs from duplicated code you can then go ahead and write a couple of templates like
template <class Baseclass, class Renderer> class TextureTemplate : public Baseclass {
private:
Renderer * m_renderer;
public:
TextureTemplate(Renderer & rend, const char * name, blah blah blah) : m_ren derer(&rend), Baseclass(name,blah,blah,blah) { }
~TextureTemplate() {
m_renderer->unr egisterTexture(this);
}
void makeCurrent() {
m_renderer->mak eCurrent(this);
}
};
template <class Baseclass, class TextureBase> class RendererTemplate : public Baseclass {
public:
typedef TextureTemplate<TextureBase> MyTexture;
Texture * loadTexture(const char * name, blah blah blah) {
return new MyTexture(this,name, blah blah blah)
}
};
then for each class you want to use the public interface for and templated implementations of the behind the scenes ties you ca n do something like
class GLRendererImpl : public Renderer {
... do gl texture stuff here ...
public: void makeCurrent(GLTextureImpl & texture) {
}
};
class GLTextureImpl : public Texture {
public: GLTextureImpl(const char * name, blah blah blah) {
load up texture using opengl...
}
virtual ~GLTextureImpl() {}
};
typedef TextureTemplate<GLTextureImpl> GLTexture;
typedef RendererTemplate<GLRendererImpl> GLRenderer;
the templates are initially a fair chunk of work, and the pattern density of the above code is pretty dense, but the approach c an be amazingly versatile and cuts down considerably on duplicated code, note that the derived classes only have to focus on their specific implementation, the generalities are taken care of by the template implementations and no typecasting is required anywhere in the system, so there is no worries about accidentally passing say a Directx7Texture object to the GlideRenderer.
The gains don't really start to show until you've got 5-6 implementations in place however.
All of the above code has been slapped together off the cuff and is probably laden with errors and formatting problems from try ing to type it into a slashdot comment box so try to follow my intent vs. my syntax.
P.S. Formatting this was a BITCH, is there a reason why Slashdot doesn't allow the tag? I.E. kept munging my & type chars back into real chars so i had to switch browsers, paste back and forth to vi to regexp things into html-munged form. Hrmmf.