As I understand it, Larry Wall is/was an employee of O'Reilly, but I don't think he had any job duties per se; rather it was more of a patronage for him to keep working on Perl while he was on their payroll. (Think of how the Medici family sponsored artists during the Italian Renaissance -- same idea here.)
With the establishment of this new Perl Foundation, maybe the idea is to formalize these kinds of patronages for key developers. Damien Conway was first because he's such a great teacher & advocate, and Dan Sugalski was second because he needed more time to work on the Parrot engine for Perl6. Now that Larry is joining this, hopefully he'll have more time to work on the high level language specification...
Well I didn't mod me up. I was trying to be as helpful as I can -- no one seemed to be mentioning COM at the time I posted it -- but I didn't have any illusions about it being "insightful".:)
Nonetheless, it does seem like COM is a pretty versatile system for getting applications to intercommunicate & build off one another. My understanding is that, for example, Internet Explorer is nothing but a bundle of COM objects that interoperate well (a network stack, an html renderer, a gui manager, etc), and if you want to you can embed those components in your own applications relatively painlessly. My understanding is that working with MFC puts you pretty close to the core OS, and thus is okay for making things more or less from scratch, but using COM gives you bigger chunks to build applications out of.
I don't see where this guy mentions what sort of Windows programming he has to do, but it seems like if he needs to understand the raw metal (so to speak), then yes MFC is probably the kit he needs to use, but if he's after something higher level like COM might be easier & more productive.
That's my understanding anyway, but like I say I'm not a gui programmer, I do network & database stuff. I'm just trying to summarize what I've been told in the past...
I don't know much about Windows programming myself, but it seems like if you want to really get into the guts of things, you'll have to deal with MFC and COM. I've never dealt with MFC, so I can't tell you anything about it, but from the little bit that I know about COM it seems to be a pretty nice system actually.
Basically COM treats things in a client-server way, so that you can e.g. write a Python client to Excel that will let Excel do all the heavy lifting -- optionally in the background -- and then you get back the results and display them in a GUI or insert into a database or pipe out across the network or what have you. Conversely, you can write a COM server that can have Excel (or whatever, that's just the example I'm using) act as a client, with your Python (or whatever) program doing the work. Moreover, with DCOM (which seems to be the exact same thing but with an amended title), the clients & servers don't have to be on the same machine (as you'd probably expect of anything calling itself client-server). The bridge from this present-day model to the pervasively distributed.NET framework we keep hearing about should be pretty obvious.
When you get into COM, it's much more similar to the Unix "small programs / filters" model than I was expecting, at least in certain abstract ways. Obviously you hear a lot of griping about it, especially here on Slashdot, but COM does seem to be a pretty solid framework for GUI application development, and much better than Motif, GTK, Bonobo, Swing etc, from what little I know about those systems. (I'm not trying to flame or troll, just speaking as a interested observer / non-developer of gui frameworks.)
But again, what are you trying to do exactly? Aside from suggesting digging up some COM (and, presumably, MFC) references, the next question is what problem are you trying to solve, and what tools are you considering using? I've played around with Windows Python, based largely on what I learned about it & COM by reading Python Programming on Win32, and it seems like it isn't too hard (and it's much nicer than Visual Basic for the same tasks). I also read Dave Roth's Win32 Perl Programming: The Standard Extensions and Win32 Perl Scripting: Administrator's Handbook, and the material was good but I'm not convinced that Perl is as good of a fit for the Win32 world -- it's great for short scripts, task automation, sysadmin stuff, etc, but I don't think I'd use it for a user-driven GUI application as I would with Python. (And keep in mind that, in general, I much prefer Perl to Python, and almost always use Perl over Python on other platforms, but I'm trying to match the tool to the role here...).
You might also want to look into Visual Basic & Access -- as a lot of Win32 apps seem to be little more than a VB front end for an Access backend -- as well as VC++, MySQL (works great on Windows, IME), Delphi (never used it but I hear nothing but great things about it), and RealBasic (Mac oriented but can cross-develop to Win32, and again I hear nothing but great things about it).
Why do scientists gravitate to these scripting languages?
For the same reasons that people gravitated to them for internet programming: there is so much ad hoc work do be done that it isn't worth the effort to work "that close to the metal". Perl's text analysis capabilities are so sophistocated that it would be hard to match them with custom written C code -- and if you did manage to pull it off without getting ensnared in infuriating memory leaks and so on, a well designed system will end up approaching Perl anyway. Yeah, Python is well suited towards modularizing systems and reworking bottleneck components in something like C, but Python just isn't as slick at text analysis as Perl is, and this kind of genetic/proteomic work is essentially a text analysis problem.
I mean, look at it the other way around -- Perl isn't actually that hiideous if you avoid all the stupid features, and you can do the development 50 times faster. If it really runs that slowly -- and usually the execution time won't be a problem -- then sure, redo parts in C (or XS), but 99% of the time that really doesn't help very much.
Ok, so you can work out about how much data is coming out of that machine. Now assume that the lab in question has several such machines, and that labs all over the world are churning out this degree of output, and maybe your lab needs to keep a local copy of all the relevant data. Go ahead & make up your own numbers if you'd liike, but keep in mind that this is a huge field these days, so there are probably hundreds or thousands of such groups working on it all, and they're churning out, by your math, 7mb per second per machine per lab.
Now take a step in a different direction, and realize that we don't know what *any* of this stuff means (much less than 1% of it, at a rough estimate). We've got a completed genome project that has produced another mountain of mostly undecoded data.
Or to go to the central issue, we understand that DNA translates trivially to RNA, then to chains of amino acids that fold up into balls of protein, with secondary, tertiary, (etc) levels of structure. Largely this is determined by how the chemical bonds between each amino acid twist together, and how disparate segments of the chain come close together or far apart. And the effect of this protein chain biologically is determined by which segments of the chain end up at which parts of the knot: the same sequence of amino acids can be neutral or active depending on whether it's near the surface, for example. Finally, go a step further and realize that all these proteins in the body are in a constant state of flux, constantly changing each other, catalyzing each other, restricting each other, and so on. The number of active variables very quickly hits a point that becomes incalculable, and we're down to a new version of the travelling salesman problem, which no contemporary computer system can even dent, nevermind solve.
Laugh at the stream of data if you want to, but keep in mind that it's not like we're just talking about a piece of network hardware that needs to be able to shuffle this much data around more or less blindly. Rather, any & all of it could be biologically relevant in any given context, and so each bit of that data stream has to be scrutinized, often more than once in different contexts. It is, simply, a *huge* amount of computational work.
I would say that it's a crash course in two linked fields, targeted at an audience of people lookiing for bioinformatics work who might be familiar with one or the other of these fields, but need to get up to speed on the other one quicky.
And I *do* think it does a good job at this -- I'm a Perl hacker that hasn't taken a biology class since my freshman year of high school (ten years ago, oy vey), but the genomics & proteomics covered in this book did bring me up to speed to the point where I understand the terminology and have a decent grasp of the computational issues involved in doing work in this field, as well as some techniques that can be appled to these issues. After reading this book, I read The Cartoon Guide to Genetics by Larry Gonick -- it's a better introduction to the field than you might expect from a title like that -- and felt satisfied that I had already been exposed to 95% of the material in there, with a significant portion of that coming from this book (and O'Reilly's other bioinformatics book, and skimming over web sites).
No, it isn't a masters degree by a long shot, but it's a solid start at learning the field, and if I choose to follow it that far. And it is enough of a crash course to land you a job, if you feel comfortable with the Perl stuff. You might not be expected to understand all the subtleties of DNA and proteins on your first day on the job, but you will at least come in knowing what your colleagues are talking about, and you'll be able to begin workiing with it immediately.
Give it a chance, it's a good book for starting out with. Yes, there's more to learn -- I understand that James Tisdall is doing a followup that'll be more like a "Perl-Bioinformatics Cookbook" for more advanced users, and there are of course other books out there besides the O'Reilly stuff -- but it's a worthwhile & solid start.
Well of course loading data into an DBMS is the ideal here, it's the loading of the data into one that's the tricky part:)
Generally, a lot of biological data is publically available from sources such as NCBI (US national computational biology lab) and EMBL (European molecular biology lab), but it could be coming in as SQL statements ready for loading into your database, CSV or TSV files, any of several annoyingly flexible standard biological data exchange formats, or worst of all something like an Excel spreadsheet or just scraped from a web page somewhere. There is way too much of this stuff to pump it all into your local storage system by hand, so you need something like Perl that can munge it into an intermediate format that can be loaded properly. Once it's actually in there then yeah, you only revert to some sort of flat file system if you want to redistribute data.
A related but more central problem is in looking for interesting patterns in these huge datasets once you have them locally, whether in flat files or a database or what have you. This is a huge area of research right now, because modern bioloogical lab technques can slurp up data extremely fast, we have the whole genome decoded but uninterpreted, etc, and now we need computational techniques that can chew through this fire hose of information efficiently.
A lot of this seems to be unsolveable at the moment, because the algorithmic complexity is up there with the Travelling Salesman problem (e.g. protein folding), so every little bit that can chip away at the difficulty of it helps. Perl is good at this, and a lot of places are using it heavily right now. Being able to work with flat files is only one aspect of it; it just happens to be a useful one to teach with, which is why it was used so heavily in the book, but in actual use the applications of Perl go way beyond simple file maniipulation.
Oh Media Lab, no question, but it's not always an easy choice. Cambridge is a pretty expensive city to live in, and choosing to take a low paying job can be an indulgence that not everyone can afford.
I mean, I myself am right now trying very hard to get a job at another Boston area university, and while I'm really looking forward to it, it's going to be a pretty significant paycut from the job I got laid off from last fall. I'm choosing to go for it because my fiance also works, and between us we think we'll be able to cover the bills & mortgage, put a little aside, and not have to tighten our belts that badly.
But not everyone can do that. Sometimes it can come to a choice between an intellectually stimulating but low paying job, or a more monotonous one that will be able to pay the bills, and you can't have a say in the matter. (For an example, take a look at the protests over Harvard employees wanting to get a better "living wage" over the past few months.) It's unfortunate that the Media Lab effectively imposes this decision on their employees, and I wouldn't be surprised if their attrition rate is pretty high as a result of it.
The Media Lab had previously paid such positions $8.75 and up in order to remain competitive with industry offers that even not-yet-graduated students were receiving.
It's probably a typo (on Slashdot? Nooo....), but $8.75 an hour is pretty close to the minimum wage here in Massachusetts. Is that actually what was meant here? If so, no wonder they were having staff problems:)
Re:Newbie users. newbie vendors - IMAP is good
on
Quoting in Emails?
·
· Score: 2
As it happened, I was just temping for someone on maternity leave, and I only interacted with a handful of people, all of whom were in the same office. I'm pretty sure that something could have been arranged on Solaris -- Evolution, Pine/imap (ideally), or just find a place to plug the Mac in the same cubicle -- but it wasn't worth the effort.
This is how the organization worked and it wasn't my place to change their ways.
Now if they wanted to hire me permanently, and I had the patience to carve out a niche in which my more oldschool ways would work, that might be one thing. But I lacked the time and I lacked the will, and I would suggest that most people don't have the time or will to change something like this. If that's how the organization has chosen to work, then you really have little choice but to go along with it or work towards slow, stubbornly resisted change. C'est la vie...
This is at least partly the fault of vendors. Last year I had a temp job for a company that had their email system run by an Exchange server, thus everyone had to use Outlook. I was working on a Sun Blade workstation, but since Outlook doesn't seem to have a Solaris version, I had to check my email from an old Mac in an unused office. That was annoying to begin with, but worse was the fact that:
it jeopardyquoted by default, and there was no way to override this setting
it posted as HTML by default, and the only thing you could configure was which font you want to use, not "whether or not there is a defined font in the first place"
Etc. I tried to fight this by cutting & pasting my messages so that they'd be top-quoted -- The Way The Good Lord Intended -- but it was much too much of a pain in the ass, and being the only one in the company doing it just made me look funny. Likewise my selection of a monospace font -- it was like tilting at windmills.
Yes, it's sad that not everyone has been brought into the culture in such a way that old netiquette would be honored, but that's just how it works when a subculture gets promoted to the mainstream. Yes, Microsoft could have made it easier to configure Outlook -- and to be fair, Outlook Express *is* a nice email client on the Mac (I just wasn't allowed to use it), and newer versions than this one ('98?) might be more flexible) -- and there's really no defence for their wholesale scuttling of all but their way of quoting messages. But what's done is done: as long as I can keep using Pine or Mutt, and read most of the mail coming to me, I'm not going to lose any sleep over it. Times have moved on...
This of course points only to the evil cabal of insulation manufacturers, electricity generators, and natural gas producers, all of whom will clearly benefit by the transition from hermetic glass membranes to the newer & not yet proven cd-rom membrane technology.
Thank god I live in America, where you can pry the Windows from my warm, vibrant home over my dead body!
I mean, put it this way: does a psychologist have to understand the electrical & quantum mechanical properties of the brain in order to do their job? No. In fact, it might even make them *less* effective as a counselor, if only because they're so aware of the low level wiring of the brain that they perhaps aren't as familiar with the high level stuff that they usually need to be focusing on.
In my opinion, the value of assembler is vastly overstated these days. It makes you work so close to the metal that it become too difficult to keep track of how a large, complex system has to work. It can be useful for optimizing critical components of important systems, and I'm sure it's invaluable in situations like embedded & realtime systems, but for a sysadmin? No way.
In my opinion, it would be much more valuable to have a good grasp of relatively high level & abstract subjects like networking techniques and protocols, file structures, and most importantly data structures. The last one is particularly important, because knowing how to rewrite a bad algorithm in assembler is sure to be much more painful and much less effective than rethinking the algorithm itself. You're likely to get a better performance gain by implementing systems with optimal algorithms in a "slow", high level language than you are with a naive algorithm in a "fast", low level assembler, and with hardware power increasing as fast as it does, you're better off taking the high road anyway -- *especially* as a sysadmin.
Knowing how the machine works is important, and I'm not trying to dismiss that. But knowing how to manually push the bits around is just going to be an exercise in tedium & frustration. The machines are designed to abstract away that monotonous stuff for you, and you have to be in a pretty specialized situation for it to be worth second guessing the compiler writers. RTOS/embedded type stuff is one of those situations. Sysadmining, either on NT or *NIX, isn't.
You'll get much farther by knowing how to bang out a stream of high level utilities in a language like Perl, Python, Shell, DOS, or Visual Basic, than you ever will by slaving away at little functions in assembler that take forever to gel into useful systems...
Well, yes. All the speed & efficiency of an interpreted language like Perl/Python, coupled with the simple elegance of a low level language like C/C++/Assembler. Brilliant! Where do I sign up?
I heard a nice quip within the last month or so, saying that all the new recruits in a typical IT department want to redo the world from scratch using their new [untested] tools & methodologies, while all the old guys are quite happy with the way things work now and don't want to change anything at all, including their precious old Cobol.
Of course, the real way forward will be a blend of something old & something new, and like all [r]evolutions will ultimately look more like what preceded it than not. I don't think there is anything that will make the issues of software development any fundamentally easier than they already are, which isn't to say that it's not worth trying -- it is -- but that misguided hopes of finding this mythical silver bullet are going to be frustrated, always. *sigh*
...of course, the traditional varieties of mice never had this problem, as the natural fur coating would wick away unwanted moisture. But now that we have them overclocked and pumped full of steroids, we resort to these fancy technological measures and have forgotten about the simple, elegant solutions that nature has provided for us.
Go back and read Fred Brooks' excellent book, The Mythical Man-Month (original copyright, 1975, 20th anniversary edition in 1995), and specifically chapter 16, "No Silver-Bullet -- Essence and Accident in Software Engineering". If you come across the 20th anniversary edition, also check out chapter 17, "No Silver Bullet" Refired, and the following chapter that discusses which of Brooks' predictions did, didn't, and were/are waiting to come to pass. Chapter 16 is captioned, succinctly,
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicitly.
Even though that was written decades ago now, it's every bit as true now as it was then. There are no programming breakthroughs on the horizon. Four programmers never will be able to write a better Photoshop in four months, because Adobe has been pouring dozens or hundreds of very smart programmers on the problem for years now, and they've had access to the very best development tools and methodologies available.
As one very smart and very skilled Perl hacker I know mentioned recently, he *hates* Perl and he *hates* programming, not because Perl is such a bad language -- he doesn't seem to think that it is -- but that even a cleverly idiomatic, high level language like that can't do anything to make the everyday logical issues in programming go away. All it can do is, as much as possible, minimize the burden of having to juggle syntax, implementation details, and high & low level logical issues all at the same time.
No software development breakthrough has been able to eliminate those problems. Not high level languages, not object-oriented tools & methodologies, not artificial intelligence or expert systems or graphical / icon based programming or fancy debuggers or advanced IDEs or more powerful hardware. None of it has made the essential, intractable problems go away, though most of them have made the ancilliary issues less problematic. As Brooks puts it (emphasis his):
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compares to the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
And that about sums it up. You might as well focus on the hardware advances, because Moore's Law is still making it proceed at an incredible clip. But software? It isn't growing any faster than any other human endeavour, which is to say, it's moving slowly and it always will. It's not the software's fault that the hardware is making it look pokey, so please don't ask any more of it [in terms of methodology or technique] than the last fifty years of experience have been demonstrate. Clearly, we're moving ahead as fast as we can, and that means slowly...
...and if all it took to write the greatest book ever was to have an oppressively great setting, then the top one would of course be Dune.
But of course, Dune is not the greatest book ever.
Quite the opposite in fact.
I'm not saying LOTR or Tolkein are bad, because they clearly aren't. As you note, there were certain things that he did very well. My problem is that it feels to me like a lot of other aspects of his work suffered because of the focus on the setting, and for me that makes it impossible to consider anything he wrote as being among history's best ever.
Moreover, time hasn't yet had a chance to cull out the best stuff. Shakespeare, as I understand it, was much less appreciated in his day than Christopher Mallory (thus all the Mallory jokes in "Shakespeare in Love"), but came to be admired later. I think it's too soon to judge whether *any* 20th century work qualifies as "best ever" yet -- even James Joyce's _Ulyssess_, which I'm kicking myself for not mentioning in the original post. At the end of my life, hopefully 50 years or more from now, I might revisit that view, but for now, all this talk about best ever just feels short sighted & naive to me.
...actually, _Silmarillion_ is what convinced me that this author had disappeared up his own sphincter...:)
For a book (series, ugh) that creates an impressive world setting, I've seen no better example than _Dune_. The problem with LOTR, as compared to Dune, is it had the unfortunate diversion of actually being entertaining, whereas Hubert was much more focused on painting a picture of his world and wasn't about to get distracted by keeping the poor reader entertained.
It's all a matter of taste of course, but I can't help but find this relentless focus on world creation to be oppressively boring, mainly suitable for Dungeons & Dragons Gamemasters...but then well there you go. Some people like all that puffery -- probably the same people that find the Bible a ripping good yarn once it gets into all those "$foo begat $bar begat $baz begat $blat" nonsense" -- but I'm much more attuned to William Golding's storytelling style that he used in the framing story for "Princess Bride": The Good Parts Version. I don't care about lineage & ancestry & history & who begat who and on what fertile earth and oh yes what crops that earth was grrowing while we're at it. *Yawn*. Skip ahead a few chapters, thank you...:)
Yeah, no kidding. It's a great book & all, but mainly interesting as a Professor's exercise in finally getting a genre story Right. So many of the old fantasy novels that preceded ("Morte d'Arthur", etc) it were just utter trash, and the same can be said of most of what followed for that matter. Just as George Lucas took a fun but lousy genre -- Flash Gordon, Barbarella, etc -- and made a great epic out of it, so too did Tolkein do with LOTR and the Hobbit. And it is a good story, if tediously long, but let's keep a sense of perspective here.
Tolkein was no Shakespeare, no Chaucer, no Hemingway, no Faulkner, etc. It's impact is a tiny fraction of that of a Bible, Quran, or Tao Te Ching. It's quality isn't nearly that of a Chaucer, Shakespeare, Dickens, or Faulkner -- just to pick a random span of good ones. I'd say that Tolkein was a great storyteller, but no good story should be that damn long ("brevity is the soul of wit" and all that), so let's just call him a good one and leave it at that.
I'm looking forward to seeing these movies, but I'm dreading all the geekish fanboy raving, overstating the magnitude of Tolkein's work. It was good, but lets not get carried away here...
The Java machine designers *knew* that Java itself would change over time.
Yeah, but you're specifically not saying that they knew other languages would be run against their JVM. They might have known that the language would have evolved -- that's obvious -- but they probably assumed that it would continue to have certain runtime properties, so even if the syntax was different it was just a matter of updating the parser, not the execution engine.
According to Dan Sugalski, there are some pretty significant constraints on the JVM and, to a lesser extent, the CLR, that make it [them] harder to port languages to, because they're geared towards static, strongly typed languages. Getting Python to run on it was impressive (in the well-engineered sense), but getting it to run ultra-dynamic Perl is probably beyond it's capabilities. That's not to dismiss it as inferior, but just to indicate that the JVM is designed for Java, and Perl is just too different to get them to run together on that platform. Parrot might be able to run them both someday, but you probably wouldn't want to, as Parrot will be optimized for Perl type dynamic languages, and Java is likely to run sputteringly on it.
I don't doubt that Microsoft wants badly to scuttle Java, and I fully accept that Java and C# are for all purposes the same language, with the latter being a blatant ripoff of the former. But I also feel, in spite of your well argued points, that the CLR on which C# is meant to run *is* being designed from the outset to run a variety of languages, while the JVM was never meant to run anything but Java & Java derivitives. The fact that third parties have managed to shove other languages onto it, *without Sun's blessing*, does not contradict the Microsoft quote you originally posted. To the letter of the word, Microsoft was speaking accurately, even if they had the spirit of things wrong, as you hold.
This isn't actually a lie on Microsoft's part though -- the Java Platform was designed just to run one language. The fact that people managed to get Python running on it was an incredicly cool hack, but it isn't what Sun (or whoever) had in mind when they were working on the JVM.
I hate to say it, but Microsoft's Common Language Runtime is designed to do this sort of thing, with special hooks for VB & VC++ maybe, but also support for Java, Perl, Python, Cobol, or whatever else people want to port to it. From what I can tell, that basically means porting a parser that can digest $foo code and spit out a bytecode that the CLR will know what to do with. Or something to that effect.
More interestingly, the "ha ha only serious" Parrot effort seems like it should be able to one day handle any of a variety of high level dynamic scripting languages, from Perl & Python, to Ruby, PHP, Tcl, Scheme, and beyond. Hopefully, it'll be able to go a step further & be able to emit another CLR compatible bytecode that can run on hypothetical.NET machines of the future.
The important thing though, and the common strand with Parrot and the CLR, is that they were both designed from the start to handle different language interfaces, rather than having support for them hacked in later. Microsoft is only wrong here to the extent that people have surripitously [sp? i.e. without official vendor support or sanction...] pushed the JVM beyond where it was originally meant to go, but again it wasn't designed to do this, and I don't think Sun or any of the other major Java vendors is going out of their way to support these kinds of extension efforts.
Uhh, not to follow you too much further down the rabbit hole here, but I'm not saying the GUI is unassailably better than the CLI. There are good GUIs (BeOS, MacOS9 and earlier -- NOT OSX), and there are bad CLIs (dos,/bin/sh,/bin/csh, etc). There are situations where a CLI is much more useful -- like the hosed system that you describe -- and there are situations where a good GUI is better, and there are situations on both sides where routine, repetitive actions can be automated with scripts.
The best system overall is one that has both a robust GUI *and* a robust CLI -- that's why I like OSX and BeOS, and why Linux, Solaris, Win32, DOS, and most aspects of classic MacOS drive me nuts. All of those are unbalanced, with weak capabilities on at least one of the two interfaces sides, if not both.
"Death to all who apropos us"? Why did I bother replying to such sophistocated trolling? Oh well...
scripts you create can be combined with pipes and sockets and allowed to communicate in various ways.
Right. Hence, AppleScript. Hence, the macros that you can save in fully graphical applications like Photoshop or Office. What you & the parent are describing is indeed a very powerful thing, but it's naive to assume that it's only a property of CLI environments -- well designed GUIs can do it just as well.
And as for your TImothy Leary / Gene Roddenberry styled comments about each ~user directory being it's own universe, err,...I really have no idea what you're talking about and I don't think you do either. You're describing a multi-user system, and that really doesn't have anything to do with CLI or GUI oriented computing. Your dotfiles can configure both the command shell and the graphical environment, both on Unix, Linux, and OSX, and to a large degree this is portable across different environments (I've used some of the same dotfiles on Solaris, SuSE, Redhat, BeOS, and now OSX). To the extent that a multiuser system can be personalized by different users, by *both* the command line *and* the graphical shell, that's a nice thing. But to the extent that these personalized environments stop resembling each other, hindering portability across platforms and confusing different users, it is a detriment. But either way, it really has nothing to do with a CLI vs. GUI debate, so I'm not sure what you're trying to say with these condescending remarks of yours...
Re:Use the Force, or Linux+Unix vs. BeOS/OSX
on
MacOSX Vs BeOS ShootOut
·
· Score: 4, Insightful
...and I will forever think that users like you forget that the Jedi all went extinct in the Star Wars movies. Being an uber-master of the command line is a great thing -- hey, I love it too, I'm typing this on OSX right now and I pretty much always use the Terminal over the Finder, for exactly the reasons you describe. But I also know that my fiance couldn't give a damn about typing into the Terminal all the time -- she is very adept with the mouse and doesn't want to have to learn all the commands and syntax that the CLI demand, and I don't half blame her (or my parents, or our friends, or any of the millions of others that prefer GUIs to CLIs).
When Scot Hacker was talking about how having to carry around a toolbelt, he wasn't dissing the commandline, but rather the lack of point & drool simplicity that, while lacking the finesse of the command shell, also doesn't need years of training to become adept with.
And as for your comments about the CLI of BeOS or OSX not being "the true CLI", well, you're just talking out of your ass on that one. I have never seen a system that better balanced command line & graphical interface functionality better than BeOS did -- for the most part you could use whichever one you felt more comfortable with, and one would be just fine driving the other environment. Lovely. And as for the Mac, it has had AppleScript for generations now and thus could have been automated in the same ways without even having to adpot a shell until now. With OS9 and before, the "real essence of the system" *was* the graphical shell, and none of the available CLI interfaces for it (msh, tclsh, etc) ever felt like anything more than a kludge, and a broken one at that.
You seem to be making the assumption that, like Linux and (old school) Windows, the graphical shell is a crude wrapper around the text interface. That's just not the case. BeOS and MacOS have always booted directly into a graphical mode, and whatever text interface has been available has always been a service provided on top of that graphical shell, not laying underneath it as a foundation.
Your argument is thus a bit like saying that anyone that tries to change channels on their television without knowing how to manyally rewire the circuitry is missing out on the true power of the machine. Not only are you flat out wrong, you just sound silly. Knowing how to perform command line surgery is indeed an elegant trick to know, but it is not the end all & be all of modern computer systems, and hasn't been for going on 20 years now, the admirable rise of Linux notwithstanding.
Slashdot Mirror
With the establishment of this new Perl Foundation, maybe the idea is to formalize these kinds of patronages for key developers. Damien Conway was first because he's such a great teacher & advocate, and Dan Sugalski was second because he needed more time to work on the Parrot engine for Perl6. Now that Larry is joining this, hopefully he'll have more time to work on the high level language specification...
Nonetheless, it does seem like COM is a pretty versatile system for getting applications to intercommunicate & build off one another. My understanding is that, for example, Internet Explorer is nothing but a bundle of COM objects that interoperate well (a network stack, an html renderer, a gui manager, etc), and if you want to you can embed those components in your own applications relatively painlessly. My understanding is that working with MFC puts you pretty close to the core OS, and thus is okay for making things more or less from scratch, but using COM gives you bigger chunks to build applications out of.
I don't see where this guy mentions what sort of Windows programming he has to do, but it seems like if he needs to understand the raw metal (so to speak), then yes MFC is probably the kit he needs to use, but if he's after something higher level like COM might be easier & more productive.
That's my understanding anyway, but like I say I'm not a gui programmer, I do network & database stuff. I'm just trying to summarize what I've been told in the past...
Basically COM treats things in a client-server way, so that you can e.g. write a Python client to Excel that will let Excel do all the heavy lifting -- optionally in the background -- and then you get back the results and display them in a GUI or insert into a database or pipe out across the network or what have you. Conversely, you can write a COM server that can have Excel (or whatever, that's just the example I'm using) act as a client, with your Python (or whatever) program doing the work. Moreover, with DCOM (which seems to be the exact same thing but with an amended title), the clients & servers don't have to be on the same machine (as you'd probably expect of anything calling itself client-server). The bridge from this present-day model to the pervasively distributed .NET framework we keep hearing about should be pretty obvious.
When you get into COM, it's much more similar to the Unix "small programs / filters" model than I was expecting, at least in certain abstract ways. Obviously you hear a lot of griping about it, especially here on Slashdot, but COM does seem to be a pretty solid framework for GUI application development, and much better than Motif, GTK, Bonobo, Swing etc, from what little I know about those systems. (I'm not trying to flame or troll, just speaking as a interested observer / non-developer of gui frameworks.)
But again, what are you trying to do exactly? Aside from suggesting digging up some COM (and, presumably, MFC) references, the next question is what problem are you trying to solve, and what tools are you considering using? I've played around with Windows Python, based largely on what I learned about it & COM by reading Python Programming on Win32, and it seems like it isn't too hard (and it's much nicer than Visual Basic for the same tasks). I also read Dave Roth's Win32 Perl Programming: The Standard Extensions and Win32 Perl Scripting: Administrator's Handbook, and the material was good but I'm not convinced that Perl is as good of a fit for the Win32 world -- it's great for short scripts, task automation, sysadmin stuff, etc, but I don't think I'd use it for a user-driven GUI application as I would with Python. (And keep in mind that, in general, I much prefer Perl to Python, and almost always use Perl over Python on other platforms, but I'm trying to match the tool to the role here...).
You might also want to look into Visual Basic & Access -- as a lot of Win32 apps seem to be little more than a VB front end for an Access backend -- as well as VC++, MySQL (works great on Windows, IME), Delphi (never used it but I hear nothing but great things about it), and RealBasic (Mac oriented but can cross-develop to Win32, and again I hear nothing but great things about it).
For the same reasons that people gravitated to them for internet programming: there is so much ad hoc work do be done that it isn't worth the effort to work "that close to the metal". Perl's text analysis capabilities are so sophistocated that it would be hard to match them with custom written C code -- and if you did manage to pull it off without getting ensnared in infuriating memory leaks and so on, a well designed system will end up approaching Perl anyway. Yeah, Python is well suited towards modularizing systems and reworking bottleneck components in something like C, but Python just isn't as slick at text analysis as Perl is, and this kind of genetic/proteomic work is essentially a text analysis problem.
I mean, look at it the other way around -- Perl isn't actually that hiideous if you avoid all the stupid features, and you can do the development 50 times faster. If it really runs that slowly -- and usually the execution time won't be a problem -- then sure, redo parts in C (or XS), but 99% of the time that really doesn't help very much.
Now take a step in a different direction, and realize that we don't know what *any* of this stuff means (much less than 1% of it, at a rough estimate). We've got a completed genome project that has produced another mountain of mostly undecoded data.
Or to go to the central issue, we understand that DNA translates trivially to RNA, then to chains of amino acids that fold up into balls of protein, with secondary, tertiary, (etc) levels of structure. Largely this is determined by how the chemical bonds between each amino acid twist together, and how disparate segments of the chain come close together or far apart. And the effect of this protein chain biologically is determined by which segments of the chain end up at which parts of the knot: the same sequence of amino acids can be neutral or active depending on whether it's near the surface, for example. Finally, go a step further and realize that all these proteins in the body are in a constant state of flux, constantly changing each other, catalyzing each other, restricting each other, and so on. The number of active variables very quickly hits a point that becomes incalculable, and we're down to a new version of the travelling salesman problem, which no contemporary computer system can even dent, nevermind solve.
Laugh at the stream of data if you want to, but keep in mind that it's not like we're just talking about a piece of network hardware that needs to be able to shuffle this much data around more or less blindly. Rather, any & all of it could be biologically relevant in any given context, and so each bit of that data stream has to be scrutinized, often more than once in different contexts. It is, simply, a *huge* amount of computational work.
And I *do* think it does a good job at this -- I'm a Perl hacker that hasn't taken a biology class since my freshman year of high school (ten years ago, oy vey), but the genomics & proteomics covered in this book did bring me up to speed to the point where I understand the terminology and have a decent grasp of the computational issues involved in doing work in this field, as well as some techniques that can be appled to these issues. After reading this book, I read The Cartoon Guide to Genetics by Larry Gonick -- it's a better introduction to the field than you might expect from a title like that -- and felt satisfied that I had already been exposed to 95% of the material in there, with a significant portion of that coming from this book (and O'Reilly's other bioinformatics book, and skimming over web sites).
No, it isn't a masters degree by a long shot, but it's a solid start at learning the field, and if I choose to follow it that far. And it is enough of a crash course to land you a job, if you feel comfortable with the Perl stuff. You might not be expected to understand all the subtleties of DNA and proteins on your first day on the job, but you will at least come in knowing what your colleagues are talking about, and you'll be able to begin workiing with it immediately.
Give it a chance, it's a good book for starting out with. Yes, there's more to learn -- I understand that James Tisdall is doing a followup that'll be more like a "Perl-Bioinformatics Cookbook" for more advanced users, and there are of course other books out there besides the O'Reilly stuff -- but it's a worthwhile & solid start.
Generally, a lot of biological data is publically available from sources such as NCBI (US national computational biology lab) and EMBL (European molecular biology lab), but it could be coming in as SQL statements ready for loading into your database, CSV or TSV files, any of several annoyingly flexible standard biological data exchange formats, or worst of all something like an Excel spreadsheet or just scraped from a web page somewhere. There is way too much of this stuff to pump it all into your local storage system by hand, so you need something like Perl that can munge it into an intermediate format that can be loaded properly. Once it's actually in there then yeah, you only revert to some sort of flat file system if you want to redistribute data.
A related but more central problem is in looking for interesting patterns in these huge datasets once you have them locally, whether in flat files or a database or what have you. This is a huge area of research right now, because modern bioloogical lab technques can slurp up data extremely fast, we have the whole genome decoded but uninterpreted, etc, and now we need computational techniques that can chew through this fire hose of information efficiently.
A lot of this seems to be unsolveable at the moment, because the algorithmic complexity is up there with the Travelling Salesman problem (e.g. protein folding), so every little bit that can chip away at the difficulty of it helps. Perl is good at this, and a lot of places are using it heavily right now. Being able to work with flat files is only one aspect of it; it just happens to be a useful one to teach with, which is why it was used so heavily in the book, but in actual use the applications of Perl go way beyond simple file maniipulation.
I mean, I myself am right now trying very hard to get a job at another Boston area university, and while I'm really looking forward to it, it's going to be a pretty significant paycut from the job I got laid off from last fall. I'm choosing to go for it because my fiance also works, and between us we think we'll be able to cover the bills & mortgage, put a little aside, and not have to tighten our belts that badly.
But not everyone can do that. Sometimes it can come to a choice between an intellectually stimulating but low paying job, or a more monotonous one that will be able to pay the bills, and you can't have a say in the matter. (For an example, take a look at the protests over Harvard employees wanting to get a better "living wage" over the past few months.) It's unfortunate that the Media Lab effectively imposes this decision on their employees, and I wouldn't be surprised if their attrition rate is pretty high as a result of it.
It's probably a typo (on Slashdot? Nooo....), but $8.75 an hour is pretty close to the minimum wage here in Massachusetts. Is that actually what was meant here? If so, no wonder they were having staff problems :)
This is how the organization worked and it wasn't my place to change their ways.
Now if they wanted to hire me permanently, and I had the patience to carve out a niche in which my more oldschool ways would work, that might be one thing. But I lacked the time and I lacked the will, and I would suggest that most people don't have the time or will to change something like this. If that's how the organization has chosen to work, then you really have little choice but to go along with it or work towards slow, stubbornly resisted change. C'est la vie...
Etc. I tried to fight this by cutting & pasting my messages so that they'd be top-quoted -- The Way The Good Lord Intended -- but it was much too much of a pain in the ass, and being the only one in the company doing it just made me look funny. Likewise my selection of a monospace font -- it was like tilting at windmills.
Yes, it's sad that not everyone has been brought into the culture in such a way that old netiquette would be honored, but that's just how it works when a subculture gets promoted to the mainstream. Yes, Microsoft could have made it easier to configure Outlook -- and to be fair, Outlook Express *is* a nice email client on the Mac (I just wasn't allowed to use it), and newer versions than this one ('98?) might be more flexible) -- and there's really no defence for their wholesale scuttling of all but their way of quoting messages. But what's done is done: as long as I can keep using Pine or Mutt, and read most of the mail coming to me, I'm not going to lose any sleep over it. Times have moved on...
My that'll be drafty.
This of course points only to the evil cabal of insulation manufacturers, electricity generators, and natural gas producers, all of whom will clearly benefit by the transition from hermetic glass membranes to the newer & not yet proven cd-rom membrane technology.
Thank god I live in America, where you can pry the Windows from my warm, vibrant home over my dead body!
:)
<not trying to troll, just cynical about all three branches of the federal government, sorry...>
In my opinion, the value of assembler is vastly overstated these days. It makes you work so close to the metal that it become too difficult to keep track of how a large, complex system has to work. It can be useful for optimizing critical components of important systems, and I'm sure it's invaluable in situations like embedded & realtime systems, but for a sysadmin? No way.
In my opinion, it would be much more valuable to have a good grasp of relatively high level & abstract subjects like networking techniques and protocols, file structures, and most importantly data structures. The last one is particularly important, because knowing how to rewrite a bad algorithm in assembler is sure to be much more painful and much less effective than rethinking the algorithm itself. You're likely to get a better performance gain by implementing systems with optimal algorithms in a "slow", high level language than you are with a naive algorithm in a "fast", low level assembler, and with hardware power increasing as fast as it does, you're better off taking the high road anyway -- *especially* as a sysadmin.
Knowing how the machine works is important, and I'm not trying to dismiss that. But knowing how to manually push the bits around is just going to be an exercise in tedium & frustration. The machines are designed to abstract away that monotonous stuff for you, and you have to be in a pretty specialized situation for it to be worth second guessing the compiler writers. RTOS/embedded type stuff is one of those situations. Sysadmining, either on NT or *NIX, isn't.
You'll get much farther by knowing how to bang out a stream of high level utilities in a language like Perl, Python, Shell, DOS, or Visual Basic, than you ever will by slaving away at little functions in assembler that take forever to gel into useful systems...
I heard a nice quip within the last month or so, saying that all the new recruits in a typical IT department want to redo the world from scratch using their new [untested] tools & methodologies, while all the old guys are quite happy with the way things work now and don't want to change anything at all, including their precious old Cobol.
Of course, the real way forward will be a blend of something old & something new, and like all [r]evolutions will ultimately look more like what preceded it than not. I don't think there is anything that will make the issues of software development any fundamentally easier than they already are, which isn't to say that it's not worth trying -- it is -- but that misguided hopes of finding this mythical silver bullet are going to be frustrated, always. *sigh*
Bring back furry mice!
Go back and read Fred Brooks' excellent book, The Mythical Man-Month (original copyright, 1975, 20th anniversary edition in 1995), and specifically chapter 16, "No Silver-Bullet -- Essence and Accident in Software Engineering". If you come across the 20th anniversary edition, also check out chapter 17, "No Silver Bullet" Refired, and the following chapter that discusses which of Brooks' predictions did, didn't, and were/are waiting to come to pass. Chapter 16 is captioned, succinctly,
Even though that was written decades ago now, it's every bit as true now as it was then. There are no programming breakthroughs on the horizon. Four programmers never will be able to write a better Photoshop in four months, because Adobe has been pouring dozens or hundreds of very smart programmers on the problem for years now, and they've had access to the very best development tools and methodologies available.
As one very smart and very skilled Perl hacker I know mentioned recently, he *hates* Perl and he *hates* programming, not because Perl is such a bad language -- he doesn't seem to think that it is -- but that even a cleverly idiomatic, high level language like that can't do anything to make the everyday logical issues in programming go away. All it can do is, as much as possible, minimize the burden of having to juggle syntax, implementation details, and high & low level logical issues all at the same time.
No software development breakthrough has been able to eliminate those problems. Not high level languages, not object-oriented tools & methodologies, not artificial intelligence or expert systems or graphical / icon based programming or fancy debuggers or advanced IDEs or more powerful hardware. None of it has made the essential, intractable problems go away, though most of them have made the ancilliary issues less problematic. As Brooks puts it (emphasis his):
And that about sums it up. You might as well focus on the hardware advances, because Moore's Law is still making it proceed at an incredible clip. But software? It isn't growing any faster than any other human endeavour, which is to say, it's moving slowly and it always will. It's not the software's fault that the hardware is making it look pokey, so please don't ask any more of it [in terms of methodology or technique] than the last fifty years of experience have been demonstrate. Clearly, we're moving ahead as fast as we can, and that means slowly...
But of course, Dune is not the greatest book ever.
Quite the opposite in fact.
I'm not saying LOTR or Tolkein are bad, because they clearly aren't. As you note, there were certain things that he did very well. My problem is that it feels to me like a lot of other aspects of his work suffered because of the focus on the setting, and for me that makes it impossible to consider anything he wrote as being among history's best ever.
Moreover, time hasn't yet had a chance to cull out the best stuff. Shakespeare, as I understand it, was much less appreciated in his day than Christopher Mallory (thus all the Mallory jokes in "Shakespeare in Love"), but came to be admired later. I think it's too soon to judge whether *any* 20th century work qualifies as "best ever" yet -- even James Joyce's _Ulyssess_, which I'm kicking myself for not mentioning in the original post. At the end of my life, hopefully 50 years or more from now, I might revisit that view, but for now, all this talk about best ever just feels short sighted & naive to me.
But then hey, this is Slashdot, after all... :)
For a book (series, ugh) that creates an impressive world setting, I've seen no better example than _Dune_. The problem with LOTR, as compared to Dune, is it had the unfortunate diversion of actually being entertaining, whereas Hubert was much more focused on painting a picture of his world and wasn't about to get distracted by keeping the poor reader entertained.
It's all a matter of taste of course, but I can't help but find this relentless focus on world creation to be oppressively boring, mainly suitable for Dungeons & Dragons Gamemasters ...but then well there you go. Some people like all that puffery -- probably the same people that find the Bible a ripping good yarn once it gets into all those "$foo begat $bar begat $baz begat $blat" nonsense" -- but I'm much more attuned to William Golding's storytelling style that he used in the framing story for "Princess Bride": The Good Parts Version. I don't care about lineage & ancestry & history & who begat who and on what fertile earth and oh yes what crops that earth was grrowing while we're at it. *Yawn*. Skip ahead a few chapters, thank you... :)
Tolkein was no Shakespeare, no Chaucer, no Hemingway, no Faulkner, etc. It's impact is a tiny fraction of that of a Bible, Quran, or Tao Te Ching. It's quality isn't nearly that of a Chaucer, Shakespeare, Dickens, or Faulkner -- just to pick a random span of good ones. I'd say that Tolkein was a great storyteller, but no good story should be that damn long ("brevity is the soul of wit" and all that), so let's just call him a good one and leave it at that.
I'm looking forward to seeing these movies, but I'm dreading all the geekish fanboy raving, overstating the magnitude of Tolkein's work. It was good, but lets not get carried away here...
Yeah, but you're specifically not saying that they knew other languages would be run against their JVM. They might have known that the language would have evolved -- that's obvious -- but they probably assumed that it would continue to have certain runtime properties, so even if the syntax was different it was just a matter of updating the parser, not the execution engine.
According to Dan Sugalski, there are some pretty significant constraints on the JVM and, to a lesser extent, the CLR, that make it [them] harder to port languages to, because they're geared towards static, strongly typed languages. Getting Python to run on it was impressive (in the well-engineered sense), but getting it to run ultra-dynamic Perl is probably beyond it's capabilities. That's not to dismiss it as inferior, but just to indicate that the JVM is designed for Java, and Perl is just too different to get them to run together on that platform. Parrot might be able to run them both someday, but you probably wouldn't want to, as Parrot will be optimized for Perl type dynamic languages, and Java is likely to run sputteringly on it.
I don't doubt that Microsoft wants badly to scuttle Java, and I fully accept that Java and C# are for all purposes the same language, with the latter being a blatant ripoff of the former. But I also feel, in spite of your well argued points, that the CLR on which C# is meant to run *is* being designed from the outset to run a variety of languages, while the JVM was never meant to run anything but Java & Java derivitives. The fact that third parties have managed to shove other languages onto it, *without Sun's blessing*, does not contradict the Microsoft quote you originally posted. To the letter of the word, Microsoft was speaking accurately, even if they had the spirit of things wrong, as you hold.
I hate to say it, but Microsoft's Common Language Runtime is designed to do this sort of thing, with special hooks for VB & VC++ maybe, but also support for Java, Perl, Python, Cobol, or whatever else people want to port to it. From what I can tell, that basically means porting a parser that can digest $foo code and spit out a bytecode that the CLR will know what to do with. Or something to that effect.
More interestingly, the "ha ha only serious" Parrot effort seems like it should be able to one day handle any of a variety of high level dynamic scripting languages, from Perl & Python, to Ruby, PHP, Tcl, Scheme, and beyond. Hopefully, it'll be able to go a step further & be able to emit another CLR compatible bytecode that can run on hypothetical .NET machines of the future.
The important thing though, and the common strand with Parrot and the CLR, is that they were both designed from the start to handle different language interfaces, rather than having support for them hacked in later. Microsoft is only wrong here to the extent that people have surripitously [sp? i.e. without official vendor support or sanction...] pushed the JVM beyond where it was originally meant to go, but again it wasn't designed to do this, and I don't think Sun or any of the other major Java vendors is going out of their way to support these kinds of extension efforts.
The best system overall is one that has both a robust GUI *and* a robust CLI -- that's why I like OSX and BeOS, and why Linux, Solaris, Win32, DOS, and most aspects of classic MacOS drive me nuts. All of those are unbalanced, with weak capabilities on at least one of the two interfaces sides, if not both.
"Death to all who apropos us"? Why did I bother replying to such sophistocated trolling? Oh well...
Right. Hence, AppleScript. Hence, the macros that you can save in fully graphical applications like Photoshop or Office. What you & the parent are describing is indeed a very powerful thing, but it's naive to assume that it's only a property of CLI environments -- well designed GUIs can do it just as well.
And as for your TImothy Leary / Gene Roddenberry styled comments about each ~user directory being it's own universe, err, ...I really have no idea what you're talking about and I don't think you do either. You're describing a multi-user system, and that really doesn't have anything to do with CLI or GUI oriented computing. Your dotfiles can configure both the command shell and the graphical environment, both on Unix, Linux, and OSX, and to a large degree this is portable across different environments (I've used some of the same dotfiles on Solaris, SuSE, Redhat, BeOS, and now OSX). To the extent that a multiuser system can be personalized by different users, by *both* the command line *and* the graphical shell, that's a nice thing. But to the extent that these personalized environments stop resembling each other, hindering portability across platforms and confusing different users, it is a detriment. But either way, it really has nothing to do with a CLI vs. GUI debate, so I'm not sure what you're trying to say with these condescending remarks of yours...
When Scot Hacker was talking about how having to carry around a toolbelt, he wasn't dissing the commandline, but rather the lack of point & drool simplicity that, while lacking the finesse of the command shell, also doesn't need years of training to become adept with.
And as for your comments about the CLI of BeOS or OSX not being "the true CLI", well, you're just talking out of your ass on that one. I have never seen a system that better balanced command line & graphical interface functionality better than BeOS did -- for the most part you could use whichever one you felt more comfortable with, and one would be just fine driving the other environment. Lovely. And as for the Mac, it has had AppleScript for generations now and thus could have been automated in the same ways without even having to adpot a shell until now. With OS9 and before, the "real essence of the system" *was* the graphical shell, and none of the available CLI interfaces for it (msh, tclsh, etc) ever felt like anything more than a kludge, and a broken one at that.
You seem to be making the assumption that, like Linux and (old school) Windows, the graphical shell is a crude wrapper around the text interface. That's just not the case. BeOS and MacOS have always booted directly into a graphical mode, and whatever text interface has been available has always been a service provided on top of that graphical shell, not laying underneath it as a foundation.
Your argument is thus a bit like saying that anyone that tries to change channels on their television without knowing how to manyally rewire the circuitry is missing out on the true power of the machine. Not only are you flat out wrong, you just sound silly. Knowing how to perform command line surgery is indeed an elegant trick to know, but it is not the end all & be all of modern computer systems, and hasn't been for going on 20 years now, the admirable rise of Linux notwithstanding.