Most people are saying the same things, but I figured I'd get my opinions out anyway.
Multiple Inheritance: Great for RAD, such as perl's "use CGI ':standard'" where you import functionality / globals directly. It's NOT good for readible code, however.. Good architecture best utilizes common base-objects. I'm inclined to believe that has-a relationships are best for MI. Ideally a language would allow optional mapping contracts; this takes care of readibility, while providing flexibility.
Garbage Collection: I've researched this topic somewhat, and still don't have a real opinion. I've always liked reference counting (which requires an abstraction layer and added work / assignment) and implicit deallocations (e.g. auto-catch blocks that deallocate non-global/ non-returned data). The thing I like about ref-counting is that your performance is very consistent (even deallocation of long nested structures can be made incremental and thus non pausing). Unfortunately the "state-of-the-art" really pushes towards copying-collectors, hybrid mark-sweep, or generational bla bla bla. Quickly, this are all part of the out-of-sigh, out-of-mind category. You allocate and forget, and magic cleans up after you. Problem is that you're prone to higher overall CPU usage for cleanups. If youre unlucky, then your GC will pause periodically. I think a language that can dynamically select an allocation-scheme run-time model is best. (though most of these require no explicit "free" function)
Portability: No such word.:) Or rather, the emphasis is on the "port" part. I know of no "portable" language. Instead, you require things like "large support base", or lack of tying to platforms. In general you're talking a high level language (e.g. byte-code / scripted instead of assembly). If you use C++ with qt, then you're limiting your platforms (but that might be sufficient for your install-base). If you limit the number of fundamental features in the language, then any C-derived language is half decent (e.g. no UNIX-select, fork, explicit threading operations, etc.). Obviously most systems break into win/unix[/mac][/vms] development platforms, and others when there's [commercial] interest. Ideally, the language would be able to compile down to assembly for a popular platform, but can still transparently fall back to byte-code / scripting / src-code for not-yet-optimized platforms. JITs are ok, but the initial overhead is not generally desirable (say for command-line tools like grep).
Event Handling: This is a nice feature that I don't see too often. In most languages you have to code explicit event-loops, which require a completely different paradigm. You could use interrupts (hurts portability), or have the VM periodically check for outstanding conditions in the background (such as asynchronous file operations). Note that this isn't the same as having a separate thread run it's own event loop, since it still needs a way of passing event information to the main control-flow. gw basic use to have a command called "on key {key} gosub {func}". Back in high school, I found that very useful. That's typically the sort of thing I think of when referring to event-handling ideality. If you could define arbitrary virtual-interrupts, then register call-back handlers for them, you might be able to accomplish this. Further, a powerful related programming feature would be virtual threading based on events. For example, an instant messenger server usually has two paradigms: thread-per-client, or multiplexing IO (via UNIX-select or other types of asynchronous IO). thread-per-client is easy to code for, but not very scalable (resource intensive; i.e. mem/thread, cache-contention, swapping-overhead). IO-selection is efficient but hard to code; you need to maintain a state-machine. If you had a super-light threading (software) architecture which is considered to be useful for such event-based context-switching (where the context switch is purely at the IO-selection or other such event-multiplexing), then you'd have the best of both worlds.
Exception Handling: I often find myself in generic catch(...) like code, mostly because of the RAD constraints. If the editor could supply me with a list of possible exceptions, where I could identify particular special cases, then I might find this more valuable. In perl, exceptions are really strings, so I can apply pattern-matches against the strings to extract those special cases. Given my involvement with databases, what I've really grown fond of is roll-back support. I value the ability to recover from state modification more than specifying excatly what went wrong (except for logging purposes). In general this involves saving the global-environment / passed-object-state which is non-trivial. Hardware support might be necessary to implement this efficiently (e.g. copy-on-write), and this violates the above portability desirability.
IDE: The only good IDE's are integrated with the language IMHO. For RAD, you should be able to write the language in the language environment itself (lisp, perl, tk, python, etc), and thereby incrementally build the application. The language should be completely understood inside and out by the IDE (code-time error syntax, symmantic checking), should provide you options at each step of the way (manual auto-completion, quick function-parameter-lookups, etc). Currently the only IDE I know that does this is Visual VB (bleah). You can type test code in a VB interpretor window, plus you have all the fancy-pantsy GUI-IDE stuff (though I don't like the Visual Studio editor). Interpolability into any extensible editor is probably desirable (I tend to like things that run inside {,x,gnu}emacs), thereby taking the best of both worlds (a non crippled text edtior like V. studio, coupled with studio-like app-awareness)). The only way something like this would be possible for a compile-only language like java, C++ is if there was an alternate interpreted version of the source-code (a language is a language is a language, no matter what you do with it).
Simplified GUI design: Haha. Where is word "simple" in the "fast","cheap","good" mutually exclusive option list? Simplicity comes at a great cost. Usually in functionality, but also in performance. Look at Java 1.0's GUI model. Slow as a dog, but relatively simple. They later had to complexify it with Observers (e.g. registering the call-backs). But much like HTML, authors wanted more control, so more complex GUI-management schemes were introduced. Later they added Swing, which is not really all that trivial to use (much to learn initially), and is pretty much a cookie-cutter. Creative deviation relegates you back to lower-level operations. Personally, I don't like doing any non-HTML + style-sheet based GUI designs. Unfortunately unless the rendering is performed on a remote client, this isn't very efficient. Hense most of my perferred work utilizes the web model. Incidently, to my understanding the best portability model to date is the web. Browsers have been written for almost everything. With DOM, SAX (and sadly XSLT) it's becomming more and more possible to generate modularized GUI's for the web. HTTP / HTML standards still are no where near ready to replace traditional GUI's (poor interactive response time and state-awareness), but I personally am only intersted in technologies in this field. In Java, you have a set of API's which provide widgets which are relegated to each implementation. There are methods of generating these widgets on most any [desktop] platform with varying degrees of efficiency (Xt, non-MFC windows API, etc. verses MFC and Qt). If this is all Java wishes to provide, then how is this different from requiring graphical widgets represented by XHTML tags, and "magically supported" by the browsers in each platform? XHTML is the ultimate in portable graphics (assuming detailed authoring is not critical), and so on.
Abstract Classes: I have a very strong opinion about this. I believe that a computer's purpose is to bring efficiency to mankind. And as such, long-drawn-out-processes should be elimenated where-possible. e.g. repetitious tasks... shouldn't exist. A human should only have to solve something once, then re-apply it whenever possible.. Ideally, the open-source initiative provides all these wheel inventions for the betterment of all mankind except for sophmore computer-scientists (who need to learn the underlying algorithms from scratch). To paradigm which includes Abstract classes are fundamental to this. When writing a generic widget which does a dozen things, but 5 of those things are complex and unlikely to vary, then damnit, that code should be shared. Further, a language should make it as easy to reuse code as possible. python does a nice job, since most code is considered reusable/extensible objects, but I'm still not satisfied with any existing language in terms of efficient reutilization of code. I can't imagine anything beyond a database sitting behind an artificially intelligent agent which can customize previously registered code to a particular task. hyper-lisp anyone?? I don't believe enough attention has been given to this particular topic, so I'm mostly speaking out of my hat here. I'd love to initiate a discussion on this topic alone to see what's already available.
If AOL offers enough money, RedHat is obliged to accept, even if they believe that being bought by AOL will mean the end of the RedHat distribution.
That's not the point.. Most of us aren't discussing "whether this should happen".. We know that it isn't up to us or even them.. It's about the ramifications.. It's about whether those of us that actually like Red Hat today have anything to worry about.
Others have said nicely that Netscape is a perfect example of their interest in Linux... A bargaining chip that only needs to be developed just enough to negotiate with MS.
There is no reason at all to "leave the MS platform". Too many users still need to write term papers in word-compatible-format; not to mention the video games. But now the AOL corporate heads don't have to take ultimatums from MS; on paper they have a backup plan.
If netscape isn't enough, then just look at winamp.. Sure they loved being bought.. But then what happened when they came up with gnutella.. Corporate headquarters issued a MEMO, and all work seized. Can you imagine grass root efforts being stifled because of the fear from distant branches of a megolopolous corporation who must save face... Can't have any association with virus writers or *gasp* other terrorists.
Further, and most importantly. To my knowledge Red Hat's employees contribute dramatically to the general open-source movement. In addition to packaging, they take active parts in important projects. What will their work-priorities be under such an anteriorly-motivated organization? Will Samba, postgres, etc. lose vital resources because the AOL port is priority one?
Pessimism? Not likely, given the probabilities.
Further, I can not see any probable positive outcomes. Macifying a Linux distro will simply make another Mac-clone; something increasingly incompatible with existing UNIX-flavors (not that Red Hat is really all that compatible). The simpler something is, the less dynamic it can be. If AOL wanted to compete against MS directly, why not merge with apple? An already established, easy-to-use base. Dual booting? Maybe, but is that really a selling point? Here, buy TWO oses for the price of 3. You can do all the stuff and more in windows that you can do in Linux, but.. err.. Linux is more stable? Which do I boot into today?
Best case, Mozilla + (potentially)Gnome + non-invasive thin-AOL-apps in a cross platform middle-layer (MS's biggest fear according the Findings of Fact). AOL has options.. They offer a whole lotta-product for some phenomina per-month subscription.. They don't alienate the grass-roots Linux people, nor their development team.. They can fun RH indefinately.. Linux and Windows merge seamlessly as apps slowly run cross platform (wine, DirectX-clones, robust cross-platofrm office, etc), and OS's compete on merit alone. Course I also have some land for sale (got real cheap via snail mail).
They know it? AOL/Time Warner is looking towards that $2xx / month subscription service.. The all encompasing consumer entertainment tax. Why get your laughs, tears, and love from anywhere else.. Now you have the AOL-in-a-box. The rumors of their direction are anything but fearful of stepping over the line.
I'm personally unimpressed with HD"TV", but have been a DVD finatic for as long as the media has been out. I'm a busy tech head, and the last thing I want to do at the end of the day is watch commercials (anxiety building, just like stop lights). Every now and again I get HBO for their original programming, but most of the time, I'm perfectly happy just buying/renting every DVD in sight.
Given that I'm from the computer world, the interlaced v.s. non-interlaced debate is very religious with me. I refuse to watch anything interlaced, no matter what the resolution. Sadly 480p is all that is left for me.
Rather coincidently, this is the DVD resolution. Add one to the DVD-only usage of HDTV.
There's an interesting point to be made about wide-screen. Half my family is hard of hearing, so I've become very accustomed to utilizing closed-captioning. Now I know that a majority of people out there are distracted by the feature, but even the strongest opponents have "missed subtle dialog that has so sheepishly requested that I backup and enable CC". Having a wide-screen TV means that there is no lower black-bar to hide the captioning off to. I know that there are different dimensions that can cause black bars even on 16:9, but in general CC is going to take up a greater percentage of the visible area. Since I've learned to ignore the black bars, I've found that you can get a larger TV in 4:3 than 16:9 for you dollars. Not to mention you won't have those annoying black-side bars while watching Frasier.
Either way, the BIG difference that is going to make your life happy is a line-doubled TV set... err.. progressive-scan (non-interlaced). I say line doubled because that's what most of them are going to wind up doing.. If you get a 960 line (or 1080 line) set, then it's going to have to perform image duplication, no matter what. Some sets have the ability to perform interpolation, but as I hear, that has horrid quality. No matter how bad the line-doubler is, the loss of shimmer is a God-send.
A little more on DVD pro-scan. I've done a lot of research into the pro-scanning of DVDs and it's not a pretty picture (pun). Apparently 60fps is the minimum that you'll want to see to avoid visial distinguishing of the strobe-effect.. NTSC uses 60fps at half the resolution (240 for traditional DVD-capable 4:3 sets). A pro-scan DVD outputs 30fps at a full 480p, and the pro-scan TV prints the full picture twice (to minimize the strobing). Thus, all you really need is a TV that's capable of accepting the pro-scan input and ideally rendering 480 distinct lines. Being 4:3 or 16:9 is merely a matter of preference.. You're not going to get that much extra detail (though there is horizontal compression for "anamorphic wide-screen 1.666" downsampled to 4:3 (1.33)). Lastly, if you're very unlucky, then the 16:9 -> 4:3 conversion is going to consume some of your 480 lines for use with the black-bars, thereby also having vertical compression. If your 4:3 pro-scan TV can accept a wide-screen input and has excess vertical resolution, then it can generate its own black-bars, thereby fully reproducing the vertical component. Note that many TV's have excess vertical resolution (i.e. for Picture in Picture).
Unfortunately, no matter what you do here, there are many DVD's that aren't properly designed with pro-scan in mind, and inappropriately set the pro-scan flags. The player has to compensate (or won't properly render the picture), and the more money you spend, the better the results (usually).
Still, unless you're in that upper income bracket, I'd say that anything below $2,000 that's pro scan, coupled with a half decent DVD player (such as the Toshiba 4700 for $225). Tweeter carries $1,100 pro-scan TVs in 4:3.
Lastly, for those that have a size complex, there is no differnce between having a TV that's twice as large verses sitting twice as close to the TV.. It's all about field of view.. In fact, a larger set is probably going to have poorer quality (due to convergence issues on said large projection sets). I personally would rather a picture tube and a properly engineered living room over said projection sets.
But with VMWare you have to buy/own a Windows license, which kind of nullifies the price advantage.
Not if you take into account the cost of the hardware which usually superceeds the cost of the OS.
It's TCO that you have to worry about. For home users, yes, the relative cost is higher and thus vmware isn't really an advantage (unless you're into creative interpretations of licences), but for businesses that have to contend with down time (i.e. dual booting), there's definately net benifits.
Respect for creativity and self reliance over profit is esential for invention, self respect and true inovation. Liberty or death.
While I agree with you, I feel the need to at least put in the plug for capitalism.. When you acquire an MBA, econ degree, marketing degree, or any general business degree you are a highly specialized human being. Your focus is to squeeze profit out of a market better than your competitor. If you can't, then you are replaced by the board. If the board can't dictate policy effectively, then the share-holders replace the board. If the share-holders don't choose an appropriate board, then profits linger, P/E ratios drop, and investment firms lower their rating. If the rating drops, the share-price is sure to drop. Thus the investment firms sell stock, and the individual share-owners are dramatically encouraged to replace the board. Furhter, if investment firms that don't react harshly to harsh financial environments won't be invested in by individuals. Assuming Investment firms are mostly collections of lay-people's "retirement" money (401Ks, pensions, individual stocks, etc), then the entire drive to perfect the art of squeezing every last penny is largely propelled by sweet ole mom and pop. Isn't it ironic?
The main advantage to this system is economic efficiency (which has little to do with money). We distribute scarce resources to that which desires it most (or at least is willing to trade the most of another scarce resource). There's very little waste in capitalistic societies. The main sad part is that since you can acquire tradable goods (fiat money) more easily when you already have tradable goods (equity), then the value of a fixed quantity of money to a wealthy person is orders of magnitude less than that of a poor person.. Thus when bidding for a scarce resource, the most needy usually can not compete. But I've never seen a system that avoids this problem without just trading it for other just-as-serious problems.
Given the above, the US constitution is not in the most efficient form (nor could it be without adapting over time). Usually it any modifications to law and or constitutional rights lag behind the currently desired equilibrium (which is usually a compromise which doesn't fully meet anyone's desires, as it should be). But the mechanisms for enforcing these changes are by far not in line with economic principles. Democracy is at least closer than communism to an market-sensative adaptable system. Like the board, we remove the administration when it falls out of favor. But unlike a company, there is no clear direction (as with profit), so it's impossible to gaguge someone's resume' and determine if they stand a chance at better administration.
The general point, however is that we can't blame the MPAA or RIAA for their direction. They are the product of evolution. Anything they'd be replaced with would come to similar decisions. We can only competed with them for legislative efficacy. But like the wealthy and poor competing for a scarse resource, the money favors the large organization in enacting new laws.
The only out I can consider is to define a set of measurements by which a congresman's value can be weighed. How much like "measuring the worth of poety" [dead poet society] this sounds, but this is, indeed in the name of reaching a political equilibrium.
love Perl, but think the language syntax still has a lot to be desired. First of all, maintaining other people's Perl code is difficult...
Unfortunately you seem to want to have your cake and eat it too (don't you hate that phrase?). You praise perl for rapid design, and how features were added without compromising existing paradigms, then criticize the concept of TMTOWTDI. One of Larry's chief design goals has always been intuitive programming.. If you think something should work one way, then darn it, it should work that way. The problem is that Larry has to violate all sorts of consistencies:
if ( $x ) { doSomething() }
---
doSomething() if $x;
Granted, some syntaxes are only "intuitive" because that's how it use to work in perl4, so we'd expect something similar (albeit magic) in perl5 in another context. But that's the price you pay for having a history.
As with the switch statement, I never understood why Larry didn't include one. Even bash has:
case $x in
*.txt) # do stuff
;;
*.pl|*.pm) # do stuff
;;
*) # do stuff for default
;;
esac
which was incredibly useful. My take is that Larry has finally found the huffman coding he's doing to the language compatible with this approach.
Remember, perl shares more with (k|ba)sh than c. (Need you look any further than the variable names?) So having nameing convenions different than "switch(x) case nine:.. break" is no straw off the camel's back *cough*.
As for streamlining the syntax-base. This could only hurt perl, since it would cripple the utility that we attribute to it. Larry is (hopefully) being very careful with what gets cut (such as formats which serve a highly specialized role or "?reg-ex?"). But notice even the teneray operator didn't stay alive. Larry determined that the ":" symbol was waaay too useful to waste on "var = cond ? true : false". So he mutated it to a parser friendly "con ?? true:: false", which is harder for the novice to read, but is a token sacrifice to the name of efficiency. As opposed to streamlining, we've added "$x//= 5" which is a default assignment, not at all possible in c-languages since there is no equivalent to "undef" or "null". In theory java could apply such an operator, but nullability is only valid for objects, which doesn't make sence to "initialize" in the first place.
Lastly, as for "everything is an object". This is purely from a parsing stand-point. In Ruby, you could theoretically do "1.print;" which would instantiate a new object. From the VM's point of view, a 1 is even more fundamental of a data-type than in perl5 since there was no concept of an integer, just a scalar. So unless you go around actually saying "1.method_name()", then you're not going to have any OO overhead.
As for OO being more cumbersome, I'd beg to differ. How about file-stat. Currently you use:
$stat = stat $filename; (notice the lack of OO syntax thus far)
$uid = $stat.uid;
notice the perl6 syntax which avoids the "->". If you wanted compaction, then you wouldn't be able to avoid OO as follows:
$uid = stat($file_name).uid;
or
$uid = $file_name.stat().uid;
or just
$uid = $file_name.stat.uid;
But notice how OO producing LESS syntax instead of more. And that's the whole point.. If a technology / paradigm makes things more efficient, then why reject it.
In the perl6-internals mailing list, you hear a lot of discussion about theoretical white-papers. Many developers perform complete implementations of these white-papers and are submitted as patches to the source tree.. From this, we can balance a multitude of variations on a theme, and pick the one we like best.
But most importantly, the system is being built heirarchicly, like an OS. Each layer builds apon it's foundation layers. Thus the "robustness" should not be a problem. The main problems are going to be dealing with particulars of the syntax implementations (since they're non-trivial languages).
As for Perl5 reuse. It's strange but very little has been reused. Suggestions to do so are quickly quelched. Perl5 was non-thread-safe, non signal-safe, non-extensible. Thus the new core's paradigm (which includes layers) doesn't fit much of the old core routine. I believe one of the old code were the scalars, which are now 100% different. The monolithic functions of old are now tiny optimized multi-indirected functions. One thing that I think "might" survive is complete rewrite is the reg-ex engine, and other such monolith single-purpose devices. But that's too far in advance.
You miss the point. Perl6's syntactic redesign is mostly sugar. Likewise Ruby was mostly a syntactic redesign of perl5. Thus Ruby is not (nor will it be anytime soon) what perl6 attempts to accomplish.
You can think of perl as the x86. It's an aging legacy product that just never seems to die.. More-over, it's ever gaining market share (well, don't know about today with the recession and the migration to ASP). Why? because it did what was needed for a very wide audience. More-over this wide audience (coupled with open-source) afforded the sharing of code (mostly through modules) which avoided the constant reinventing of the wheel.
Sure there are viable alternatives to x86 (alpha, IA64, x86-64, etc), but they involve re-inventing at least part of the wheel, and many don't have the time. Someday python will have at least as much of a code base as perl5, but until it dwarfs perl5, it's not an "obvious choice". Ruby is just too new to really be compared on this level. What's more, so long as the inside is a black-box, who cares how it works; so long as it gets the job done in a cost effective manner (meaning either performance and or available code to reuse).
But this is exactly what parrot gives you. The ability (in theory at least) to use all of ruby, python, perl5, perl6, java, etc. Unlike JVM, which is early bound and thus can't "fully" utilize perl5 and friends, parrot should be able to run both java and perl5. In theory, the open-source platform could handly any language (albeit with missing optimizations here and there). So unless Ruby runs faster than parrot, there is nothing that it's black-box has over perl6 (and likewise the x86).
Does Parrot have JIT compilation? Does it have 4+ years of optimisation? The JVM's have a come a long way in the last few years. I'd be suprised if Parrot could match it for a long while.
Yup, and nope. We're new, but we have the benifit of hind-sight. Since we're open source, we can build upon any existing implementation of open-source jits/VMs. So lifetime is a red-hering.
We currently have a preliminary jit-compiler. Works pretty fast too. Currently it's 50% as fast as java's jit for a simplistic synthetic benchmark (considering the core isn't anywhere near finished). In theory parrot's jit can be faster than java's since we're using a register set instead of a stack-machine. Additionally, excluding java's grahpics library, perl has a larger collection of core c-routines for it's op-codes(Basically everything perl5 had). I'm curious to see if we can ultimately match java jit-speed; since we've already matched java VM-speeds. We also have a wider collection of fundamental types than java. Since strings in java are mostly handled by the String class. Then there's of course our ever-powerful scalar type with many useful low-level routines. In general, object orientation is at a higher level in parrot than within the java-VM.
-Michael
Re:perl motto summararizes its fatal weakness
on
Perl6 for Mortals
·
· Score: 3, Insightful
In my ideal programming language, there is exactly one program that solves each problem. That limits my search space while I'm trying to find it.
This already exists.. It's called CPAN.:) All kidding aside, I disagree that perl's crypticly compacted syntax is a search-space problem. What you are instead searching for is to update someone else's solution-space. Imagine, for a moment that you're company decided to use some 3'rd party java module (such as a logger). Now what if one day you found that it had a bug.. Or worse yet, you needed a new feature that wasn't implemented. Well, if it's closed source, you contact the vendor and keep your fingers crossed. Unfortunately if it's a bug, you might have a headache trying to find out what happened, where the bug originated, and even if the 3'rd party module was at fault.
In open-source (as with almost all perl), or when the 3'rd party was via another developer within the company, you at least have the option to trace through the code. Now most developers have to make some assumptions. These assumptions SHOULD be documented somewhere, but even when they are, the location of that documentation isn't always known. Perl again comes to the rescue with pod-documentation (similar to javadoc inlined documentation). You can put the description right next to the relavent regions, and at least in the relevant files. But, as we all know, developers are lazy and thus the added work of thourough documentation (in both java and perl) is lacking.
Now if you're proficient with the perl-code basics, then you have all the tools that you need to trace through a perl-module (or executable). Perl is highly context-sensative (name-spaces can be dynamically changed), arguably you have your work cut out for you (when it happens that sufficient documentation on such subtlties were not noted). The same can be said about java and package-spaces. There are tricks and tweaks a developer can do to perform efficient "magic" which is incomprehensible to an outsider (at least at first glance).
But to alleviate your problems, we have the debugger, which allows not only real-time inspection of the context, but thanks to the magic of late-binding, you can modify the context on the fly (importing new symbols, redefining old ones, etc, adding ad-hoc test routines). Java / C can't do this.
So yes, it is "harder" to debug / update someone else's code when they programmed above your level of proficiency. But if they were indeed more sophisticated developers they'd document their "magic". And if you weren't proficient enough to at least utilize the analitical tools at your disposal, then what are you doing modifying someone else's code?
I do know about the FileHandle module. This module is proof that regular filehandles are too ugly. You shouldn't need the FileHandle module to be able to do basic filehandle stuff.
Well, I think you'll be dissapointed then. I don't think file-IO is going to be part of the core. Meaning I think you might have to include at least one module to get any IO to work.
Given that, FileHandle is outdated. Use
my $fh = new IO::File "...", ".."
Even if you hate OO, its the most feature complete of the file-types.. Not to mention it's the only one that evolves with file-enhancements.
TypeGlobs are going away I think, so *FH won't be applicable anymore (though perl5 compatabilty mode will deal with it properly). Likewise with the global symbols which aren't thread-safe I don't think.
Anyhow - OO in Perl sucks. It's inelegant and not terribly efficient. End of discussion.
No public, private, protected variables. Poor performance on inheritance and polymorphism. Should I go on? Sure, the modules use OO programming, but only a very simple subset of all the powerful concepts a real OO implementation will provide.
OO in Perl was a bolt-on, so it's not surprising that many of the features you claim it lacks were later bolted on. "use fields", for example allows you to have private member variables (just prefix the variable with an underscore). Likewise there are ways to produce private functions: declare an anonymous sub with my; it's even faster than OO.
Polymorphism in Perl5 is O(n) with respect to the inheritance tree depth, so it has the potential of being slow, agreed. None the less, I've never found OO-constructs to be the bottle-neck. (Ever use Devel::DProf?)
Furthermore, perl has virtually no typing.
Once again, the bolting on approach.
my FooObj $obj = new FooObj...;
When used with the "use fields" and "use base" directives is fully type-case. In fact, I find myself using this for non-oo methods to enforce type-casing on hashtables (such as from database requests which would otherwise have NO type-casting in ANY language). It is the idea that you can use your knowledge of how the device works to minimize programming time (Such as w/ database queries), that perl's power shines.
The code is rarely readable, escpecially the code written by the so-called perl gurus which use all kinds of funky constructs and features that don't translate over to another language.
Yes, it makes for more cryptic code on occasion. But that's just part of the learning curve. Did you ever get confused by:
struct my_struct_t (*my_func_ptr[20])(struct my_arg1_t arg1, int arg2);
When you work out the context it makes sence. The complexity is just a by-product of the adopted parsing conventions. Java tried to alleviate much of these syntactic line-noise, but it had the benifit of hind-sight. Java already has this garbage "bolted on" in subsequent versions:
BaseObj obj = new BaseObj() {
public run() {... }
};
Now C# has the advantage of hind-sight. But guess what, the next great feature will make even C# look occasionally awkward in version 3.0. That's what's great about evolution - you have all these wierd things like an appendix lingering around, and get to fuddle over what their original uses were.:)
In any case, one of perl's design goals has always been (and continues to be in perl6) huffman encoding of the syntax. Meaning easy things shouldn't require a whole hell of a lot of typing.. Java NEVER valued that. You can't just type a one line program. Even a simple (and VERY common) for loop requires:
Enumeration list = obj.createEnum();
try {
while ( list.hasMoreElements() ) {
MyFooType obj = (MyFooType)list.nextElement();
...
}
} catch ( InvalidIteratorException e ) {.. }
But here's the catch... If you don't like the obscurity of say:
for my $idx ( 1.. 20 ) {... }
Then you can write:
for ( my $idx = 1; $idx The $_ variable itself is a good reason to boycott perl.
Granted, this was another legacy feature, but is still around because of the huffman encoding. If you're creating a new app and don't like cryptic stuff.. Or better yet, if you're a department and want to make it easy for new developers to join, then you simply utilize "use English" and viola, you have
"$ARG". No fuss, no fetter. (Though this doesn't work well in MT environments as I've found). But if you're not squeamish, then you can go the opposite route.. $_ was designed as the "default", and thus can be excluded in most uses. Thus
#!/usr/bin/perl
use IO::File;
$fh = new IO::File $ARGV[0];
while( $ARG = $fh->getline() ) {
$ARG =~ s/x/y/g;
print $ARGV;
}
can be replaced by:
#!/usr/bin/perl
use IO::File;
$fh = new IO::File $ARGV[0];
while( $_ = $fh->getline() ) {
s/x/y/g; # default $_
print;
}
can be replaced by:
while() { s/x/y/g; print; }
can be replaced by:
%> perl -n -e 's/x/y/g; print;'
can be replaced by:
%> perl -p -e 'tr/x/y/'
can be replaced by:
%> perl -p -e 'y/x/y/'
If you find yourself typing the first entry thousands of times for simple shell-scripts, you too would understand the power of the last statement. Once you've used the last statement enough times to memorize it, it's very hard NOT to use these features in your larger programs. Therein lies the problem. Most developers don't "use English" because they don't have to. Much like most java developers don't use javadoc comments (even though it's trivial to do so). Programmers are inherently lazy.. And that's a good thing (tm).
Overall, can you do stuff like "synchronized int counter" in perl? Even the threading is not production quality. (That would have made non-blocking sockets much easier)
Not sure what you mean by sync int counter. In the highly volitile MT library you can just lock any variable to synchronize it.. That's the equivalent of:
synchronized (foo) {... }
in java. So no loss there. Additionally if you want non-blocking sockets in java, forget it.. It's not even an option. In perl, on the other hand, you have the full use of the non-portable ioctl and fcntl. What's more, you have "unix-select". Which is an awsome power to behold within servers.
A java-threaded instant messenger (via IBM benchmarks) crawled to a halt after some number of users had connected. The extra memory requirements for each thread were insane for such a simple task as IO multiplexing. select-based servers, on the other hand only have the overhead of one additional file handle. Granted threading approaches are insanely easy to understand and maintain, but they're not benifitial to performance (since the unix-select model could simply have multiple workers bidding for the same collection of file-handles). In perl, you have the choice to do either. In java, you don't.
However, perl has one gem. A true gem, that is a super-gun that will annihilate almost everything - it is the eval. Eval used correctly will save you hundreds of line of code. Used badly, it will slow your application to a crawl.
More generally, this is a feature of any late-bound application. Ironically even Visual Basic (and hense most ASP) is early-bound. Python, Ruby, Lisp, and many others fall into this category. There are many unfortunate consequences of this design scheme, however. Most notably much compile-time-checking and provability of code. Further most concepts of object-oriented optimizations go out the window. Even perl6 which will be compiled will still be late-bound (It's just too useful).
Bah. From what I could make of Larry's "Apocalypse", perl6 is going to be the next fsckin' Java. Bloated, slow and useless.
For raw for loops, java is currently faster than Perl5; especially with a JIT. Perl5's biggest strength is in it's complex op-codes (grep, map, reg-ex, etc). This has the effect of JIT optimizing various high-use functions, but leaves basic flow-control to the mercy of performance.
Perl6 keeps the same complex and optimized functions of perl5 (though extracting them to external libraries to make the core clean), but utilizes the optimized byte-code and jit-able features of a java VM. Thereby getting the best of both worlds. In java, a reg-ex engine is most likely written in pure java. In perlX, reg-ex is optimized-c. Since their basic flow-control is now similar they should be comparible baseline.. Thus perl6 can only be faster than java (with equivalent code maturity). There is, however one additional MAJOR difference. Non jitted java is stack based, while perl6 is register-set based (I'm currently pushing Knuth's VM-register set for highly efficient subroutine calls).
Perl6 will NOT be an OO language, dispite many beliefs to the contrary. perl5 programs should be executable AS IS, and perl6 programs will look remarkably similar to those of perl5. There will be a higher performance OO support structure in perl6 than was in perl5 (which used recursive symbolic lookups on each method invocation), but this is completely optional, just as in perl5.
By the way, preliminary benchmarks show that non-JIT compilations of perl6 are faster than both perl5 AND java. We do have a JIT, but it's too rough to trust. But for our current trite benchmark, we're 50% of the performance of even the java JIT (and we avoid the overhead of a per-execution jit-compile).
So along with other posts, I believe that every element of your complaint has now been addressed.
perl6 focuses on speed, and compatability. While trying to reconsile convolution and complexity associated with perl5. Heck we're even supposed to be fully MT capable. Thus in all respects we should be able to compete directly against java and C#(including type-safety). So what exactly is your beef again?
-Michael
Re:Ternary has been known to be efficient...
on
Ternary Computing
·
· Score: 2
What about MOSFETs? As I understand it, there is a channel which is either opened or closed (depending on how it is created). A third state would be neither. In this case, you can either fully shut the channel, fully open the channel, or leave it in a half-open state.
"neither" is vague. It's close to saying it's either light, dark or neighter. Transistors have two basic modes of operation (that I'm aware of) that fits a garden hose analogy; You either step on the hose (blocking current) or physically remove the foot (to allow current). You have to physically attach the gate to either a positive source or a negative drain, otherwise static charge will keep it in what-ever state it was previously. The output of a MOSFET is usually the gate of another mostfet. Moreover, the gate of a MOSFET is like a capacitor, so the role of the gate-controller logic is to charge or discharge the gate-capacitor. Thus having some "dim" state that is neither blindingly bright nor pitch dark only slows the process of opening or closing (charging/discharing) the targeted gate.
You might hear about a third "Z" state (cheater latches), but that's just when you don't connect the source of the FET to power or ground, but instead to the output of some other combinational logic. The idea is that when the FET is pinched off, you've electrically isolated one logic component from another. This is good for multiplexing (like memory arrays), where you'll have the output of multiple logic devices connected to a single input of another logic device, and you "activate" only one output device at a time. (The alternative would be to risk having the output of one device +5V, and the output of another device 0V, thereby short-circuiting).
Bipolar transistors are even worse since they never truely pinch-off, and even leak current into the control. But they have more efficient current characterisitcs (higher current swings) and thus work well to amplify the charging/discharing of the FET capacitors. Hence the buzword BiCMOS.
These are the basic uses of FETs that I've encountered in my undergraduate EE cariculum. End result, there's no free lunch with trinary logic systems and current transistors.
you're almost always better off using CSS for presentation tweaks
Tweak being the keyword. Tweaking fonts / colors is completely different than structure. The goal of an web art designer is to "structure" the web site in an erogonic and visually pleasing manner. Being a pure-hacker, I find distaste for such tweaks. I focus on just getting the data in and out of the users's head. I long for the ability of our graphic's designer to be able to take the data generated by my "business logic" and format it properly.
ASP/PHP/JSP/CGI generation of tables / forms does not easily lend to "tweaking" of format (only primative CSS tweaks). Instead what we want is a "winamp" style skinnability where each widget can be relocated at the graphic's designers whim, completely independant of how those widgets work.
There are only two technologies today that I can imagine that do this.. One is XSL, and the other is *gack* component-based programming. From this the components generate zero HTML, but instead internal data-structures which the front-end designer attaches to various HTML widgets (and can thus choose between drop-downs, check-boxes, tables, etc).
In another post, I suggest that if future browsers are XSL compliant, then we can offload all formatting to the browser and just render raw XML. The CSS and XSL would be static pages mapped to the XML data, which thus augments performance incredibly.
we already have technology that separates the design and the data: ASP, PHP, Cold Fusion, etc
Hello! I whole-heartedly disagree that ASP / PHP / JSP performs any separation (though not familiar enough with Cold Fusion). Instead they perform the exact opposite.. They interlace content, presentation and even security. They do not natively allow for the separation of work a hacker, an artist, and a DBA performs, since they all require arbitrarily aggreed apon artificial APIs.
Presentation is only separateable when function calls to "header", "footer", URIs are made. A new developer wouldn't necessarily know which file(s) to use for such linkage. Login authentication / authorization are often relegated to the individual web pages, which makes the vulnerability dependent on the bug-free-ness of each page (weakest link is weakest/buggiest URI). Granted, there are propritary means within each system to enforce authen/authz.
Though I'm not a great fan on XML, XSL allows a 100% separation of style (beyond even that of style-sheets). Even the use of head/foot within PHP/ASP doesn't allow external formatting of the individual tables as XSL does. What's more, theoretically future XML / XSL compliant browsers can off-load the server overhead of the presentation layer completely. Thus there is zero "extra layers" of work for the server. You generate XML however you please (just as you would HTML), then associate static style sheets / XSL sheets from which the future browser renders the image.
For the time being, all this technology is in flux. As I said, I'm no big fan of XML, but I've had to produce proprietary solutions to the data/format separation problem, since no existing "ASP-style" architecture solved it to my company's satisfaction.
The obvious answer is because first you have the hit of decompressing
You're thinking LZ or huffman. But you could very easily perform utilize tag-id,data-length,data.
If tag-id and data-length are binary integers, then you reduce any tag combination to 8 bytes (which, except for single character tag-names is shorter). It most definately produces faster read-times, since you read entire chunks without lexical comparisons.
For 1-level-deep data-structures, this is pretty good.. You can even reduce the tag-size down to 1 Byte (thus have only 5 bytes overhead per CDATA). This is especially good for protocols between web-server apps, and the like. For multi-levels data-structures, you have the choice of either combining all the levels into new tag-types (though this doesn't allow for recursion), or have the reader keep track of state.
Since this can easily be converted back and forth between XML, what this could mean is that externally XML is used, internally compressed XML is used.
Note that even this has limited usefulness; only at all useful when interacting with 3'rd party apps, or when being saved to disk (to allow vi-modification).
Well, simply it makes for faster CPUs. (unless most of the time you're physically interchanging from GPR to Address Registers). The Digital Alpha, for example, went even further and utilized two completely separate register sets for GPRs. I don't remember if the programmer was required to not perform operations that would pull from both register sets or not (e.g. was it just a caching localization, or was the bottom half and top half of the register address space physically separate).
The main advantage is a minimazation of ports on the register set and a reduction in the number of buses. Each execution unit typically requires one write port for each register. If you have 6 integer execution units, then that's 6 write ports (and probabably something like 6 read ports, but in theory 12 read ports). Each port requires an address decoder and extra levels of probagation in the register fetch stage.
Back in the old days, where we didnt see heavy pipelining (especially in first generation 68K), this was expensive and slow. The 68K was clean in many ways, which included separation of dissimilar functionality to segregated addresses and buses (and possibly execution units). Since there's no contention between addressing and general ALU operation, it's closer to true divide and conquor. Mix in the fact that the 68K CISC core could utilize op [Mem] = [Mem], [Mem], the load on address registers and logic was pretty heavy (at least in comparison to RISC architectures).
I once did a simple CPU design project which unified the FP regs and the int regs. The focus was on interchangability of data-types, and simplicy of design.. But what I quickly found was that in almost all cases (except register exchange) things were worse off.. The large register set had to have exteraneous fields to handle the various datatypes (even if they weren't used 99% of the time). That logic took extra probagation layers. Additionally, the number of address bits in the assembly code was upped (since fp ops couldn't assume a separate address space than int ops). Plus I found that the number of ports I had was horrendous.
Arguably, address calculation more regularly requires utilization of integer units, and thus there will be a significantly higher percentage of swapping betwen GRP and AR than between FPR and GRP. None the less, Motorola found it advantageous to do it that way.
Once Load/Store become popular (as with the PowerPC), the benifits of separate addressing fell off. (Number of mem accesses / instruction was now well below one).
(1) What percentage of people ran (still run) DOS 1.0 exe's on a Pentium or even a 486?... Obviously not many, so it's there as more of a "just in case" feature. (I'm not arguing with you, your point is well taken, just pointing out something that I think the x86 market *should* do eventually)
Probably 90% of all consumers. Ever hear of windows millenium? That new fangled OS that I don't yet need to upgrade to? It still supports all those ugly 16-bit DOS features.. Sure they did away with the DOS boot-process. But DOS is most certainly there.. And until DOS is gone (a la NT / XP), CPU manufacturers still have to support it.
Never mind the fact that even Linux is based on an initial x86 boot-process. (Though obviously it's not tied to it given it's multi-platform support). But out-of-the-box x86 Linux wan't 16-bit x86 supports.
Sure win 9x is "mostly" 32 bit if not all. But it most assuredly supports the sort of legacy x86 features that both software and HARDWARE developers take advantage of.
The AH,AL 8 bit registers you see are essential to call the CPU an x86 anything. If for no other reason than IO support (don't remember the exact instructions.. it's been a while since I've read an 8086 assembly book). Note that IO is pretty much unchanged in the Athlon (since so little actually uses it anymore; relegating to windows drivers and shared memory regions).. Interrupts are also used by these 8-bit registers. In fact, pretty much anything relating to the hardware drivers (minus AGP) depends on it.
I think the loss of the ISA slots should help ease the transition.. PCI with plug and play shouldn't be too hard to port to which-ever technology superceeds. But my point is that there isn't an absence of current-market vendors that still depend on these legacy features.
Aside from hardware, x86 had lots of macro-instructions, such as using CX as a 16 bit counter, and SP, BP for string comparisons. I'm sure these are micro-op vectors in the Penium on, but they still need to be emulated and debugged somehow, thus the register set still needs to be in tact. The real question is whether they make 64bit the fast-path (requring an extra logic probagation for 32bit), or if 64bit is considered the exception.
Aside from that, I agree with you that "staging out" is the way to go. XP should help (sadly) most consumers get rid of any remaining ties to the hardware (via hardware abstraction layers; assuming that's still there). But MS has no vested interest in making the same OS for servers as for consumers. They'd love to have a win3k that only runs on expensive hardware (where they can charge a premium), with their win4Suckers running on a legacy platform that allows them to boast over 1 trillion apps served. You can't buy that sort of marketing.
Heck their current strategy is to not even acknowledge that other OS's exist. When was the last time you saw an MS commercial advocate themselves over someone else. (Like AOL still has to do. "No wonder we're number 1").
Sure Linux'll support what-ever and when-ever.. That's one of it's trademarks. But 64bit has a couple down-sides (including memory / cache requirements), and having a 64bit time-stamp or file-descriptor just isn't going to impress the other 99% of the code enough to run faster - the key is going to be end-user benchmarks and or raw MHZ. That's what draws peoples attention. And people's attention is what draws MicroSoft. And as we all know.. MicroSoft rules the world. (well, it's own world at any rate).
I thought McKinley was just the.13 micron version of Itanium, perhaps with more cache. Does it have an enhanced ability to do IA32?
McKinley is a whole mess of add-ons.. Not least of which is the idea that it can issue more EPIC instruction / clock than the Itanium. The original idea was that Itanium would chapion the instruction set, but would be an unwieldy beast with all it's new features.. But it would be enough to transition the market place (too bad it's practical performance sucked). McKinley would then be the knock-out punch that fully utilized it's potential (though at greater cost due to increased numbers of components). From this Itanium would be a low end that allowed "entry-level servers". Then they'd have time to go redesign new features for their next [incremental] generation... Their EPIC instruction set has templates so that adding whole new classes of functionality "should" be trivial.
Course I don't think they expected having to relegate Itanium as a "pilot" CPU with embarrasingly low frequency ratings (but MHZ is all that matters, right Intel?). Doesn't sound like the P4 guys are under the same marketing department as the Itanium guys (GM in the making?)
honestly people, hardware compatibility is not that big of an issue. witness alpha. emulated x86 just fine in software, rather quickly too, probably because the chip was able to be kept smaller and more streamlined by keeping the emulation out.
Initially, the ALPHA's speed was due to "leaving complexities out"; it's minimalist approach to assembly (including a fuzzy FPU which was very fast if you didn't need ieee precision). But it definately didn't leave the emulation out cold. If I'm not mistaken, the ALPHA had a huge side ROMish type of thing that allowed VAX complex instruction translation lookups.
Fx86 worked fast because it incrementally translated x86 to native ALPHA. Drivers and OS libraries were already native. Thus only a moderate fraction of your code ever ran under emulation (given a long enough lifetime).
The reason hardware compatability is an issue is that if you don't have the R&D to port to multiple platforms, you choose the one that'll make the most money.. It's rarely your problem that things run too slowly; especially if the uppitiest customer will be willing to shell out for a maxed out current-state-of-the-art x86. (with proprietary motherboards that use faster memory, etc).
But even the ALPHA has legacy problems, as they're violating their "minamlist" approach by introducing out of order execution in their latest processors...
Oh how Alpha is missed.. I cheered the K7 because if I saved up enough money, I could get the Alpha version
-Michael
Re:How about a competition? (was Re:Proof, please)
on
MySQL 4.0 Released
·
· Score: 2
My only problem with comparing MySQL to Postgres is that you can't really use the same SQL code for both. Any sufficiently advanced database is going to have to make use of the non-portable feature-sets (such as auto-increments (sequence v.s. auto_increment)). Datetimes differ (as do maintanance of "last_modified" columns). Database creation scripts differ.
The above really only means that you can't just drop one database inplace of another (In fact, I've never seen this possible on a sufficiently advanced system. I've gone from Sybase to MySQL to Postgres to Oracle, and at best I could write a low-level portable API in perl to do most of the features IF you used the API instead of SQL).
But there's a more important point. Different databases have different ways of attacking the problem, and so you'd have to do a complete redesign to properly utilize a given system (and achieve those oh-so important benchmarks). I'm writing an app that's supposed to work on both MS SQL AND MySQL (one for development, and the other for production), but I have to program for the least common denominator (which is mysql). The lack of subquries causes me to rethink the design and write non-optimal code for either system.
My main point was that Slashcode isn't suited for anything other than a minimalist database, since most other non minimalist databases have proprietary ways of speeding things up (Oracle nested tables, postgres OO selects, Mysql mini auto_increment retrival, etc).
This isn't to say that slashcode was poorly designed because of it's minimalist approach. That's no different than saying anything that uses berkley file hashes is primative. It does it's job. Fullly SQL-capable just wasn't one of it's requirements. And for some, tape-backed up appended data-sets don't need full data-integrity requirements.
Slashdot Mirror
-Michael
How could MS be beaten to the punch? They already admit that Mono is roughly a year behind .NET's release schedule.
Not to mention,if you read the article, Miquel's got nothing but love for much of the windows-esque API. UNIX-ish API's will be emulated.
To me, it sounds like they've found something that meets their goals more efficiently, and they're running with it. Sounds like a consession to me.
-Michael
If AOL offers enough money, RedHat is obliged to accept, even if they believe that being bought by AOL will mean the end of the RedHat distribution.
That's not the point.. Most of us aren't discussing "whether this should happen".. We know that it isn't up to us or even them.. It's about the ramifications.. It's about whether those of us that actually like Red Hat today have anything to worry about.
-Michael
Others have said nicely that Netscape is a perfect example of their interest in Linux... A bargaining chip that only needs to be developed just enough to negotiate with MS.
There is no reason at all to "leave the MS platform". Too many users still need to write term papers in word-compatible-format; not to mention the video games. But now the AOL corporate heads don't have to take ultimatums from MS; on paper they have a backup plan.
If netscape isn't enough, then just look at winamp.. Sure they loved being bought.. But then what happened when they came up with gnutella.. Corporate headquarters issued a MEMO, and all work seized. Can you imagine grass root efforts being stifled because of the fear from distant branches of a megolopolous corporation who must save face... Can't have any association with virus writers or *gasp* other terrorists.
Further, and most importantly. To my knowledge Red Hat's employees contribute dramatically to the general open-source movement. In addition to packaging, they take active parts in important projects. What will their work-priorities be under such an anteriorly-motivated organization? Will Samba, postgres, etc. lose vital resources because the AOL port is priority one?
Pessimism? Not likely, given the probabilities.
Further, I can not see any probable positive outcomes. Macifying a Linux distro will simply make another Mac-clone; something increasingly incompatible with existing UNIX-flavors (not that Red Hat is really all that compatible). The simpler something is, the less dynamic it can be. If AOL wanted to compete against MS directly, why not merge with apple? An already established, easy-to-use base. Dual booting? Maybe, but is that really a selling point? Here, buy TWO oses for the price of 3. You can do all the stuff and more in windows that you can do in Linux, but.. err.. Linux is more stable? Which do I boot into today?
Best case, Mozilla + (potentially)Gnome + non-invasive thin-AOL-apps in a cross platform middle-layer (MS's biggest fear according the Findings of Fact). AOL has options.. They offer a whole lotta-product for some phenomina per-month subscription.. They don't alienate the grass-roots Linux people, nor their development team.. They can fun RH indefinately.. Linux and Windows merge seamlessly as apps slowly run cross platform (wine, DirectX-clones, robust cross-platofrm office, etc), and OS's compete on merit alone. Course I also have some land for sale (got real cheap via snail mail).
-Michael
Control doesn't really work, and they know it.
They know it? AOL/Time Warner is looking towards that $2xx / month subscription service.. The all encompasing consumer entertainment tax. Why get your laughs, tears, and love from anywhere else.. Now you have the AOL-in-a-box. The rumors of their direction are anything but fearful of stepping over the line.
-Michael
I'm personally unimpressed with HD"TV", but have been a DVD finatic for as long as the media has been out. I'm a busy tech head, and the last thing I want to do at the end of the day is watch commercials (anxiety building, just like stop lights). Every now and again I get HBO for their original programming, but most of the time, I'm perfectly happy just buying/renting every DVD in sight.
Given that I'm from the computer world, the interlaced v.s. non-interlaced debate is very religious with me. I refuse to watch anything interlaced, no matter what the resolution. Sadly 480p is all that is left for me.
Rather coincidently, this is the DVD resolution. Add one to the DVD-only usage of HDTV.
There's an interesting point to be made about wide-screen. Half my family is hard of hearing, so I've become very accustomed to utilizing closed-captioning. Now I know that a majority of people out there are distracted by the feature, but even the strongest opponents have "missed subtle dialog that has so sheepishly requested that I backup and enable CC". Having a wide-screen TV means that there is no lower black-bar to hide the captioning off to. I know that there are different dimensions that can cause black bars even on 16:9, but in general CC is going to take up a greater percentage of the visible area. Since I've learned to ignore the black bars, I've found that you can get a larger TV in 4:3 than 16:9 for you dollars. Not to mention you won't have those annoying black-side bars while watching Frasier.
Either way, the BIG difference that is going to make your life happy is a line-doubled TV set... err.. progressive-scan (non-interlaced). I say line doubled because that's what most of them are going to wind up doing.. If you get a 960 line (or 1080 line) set, then it's going to have to perform image duplication, no matter what. Some sets have the ability to perform interpolation, but as I hear, that has horrid quality. No matter how bad the line-doubler is, the loss of shimmer is a God-send.
A little more on DVD pro-scan. I've done a lot of research into the pro-scanning of DVDs and it's not a pretty picture (pun). Apparently 60fps is the minimum that you'll want to see to avoid visial distinguishing of the strobe-effect.. NTSC uses 60fps at half the resolution (240 for traditional DVD-capable 4:3 sets). A pro-scan DVD outputs 30fps at a full 480p, and the pro-scan TV prints the full picture twice (to minimize the strobing). Thus, all you really need is a TV that's capable of accepting the pro-scan input and ideally rendering 480 distinct lines. Being 4:3 or 16:9 is merely a matter of preference.. You're not going to get that much extra detail (though there is horizontal compression for "anamorphic wide-screen 1.666" downsampled to 4:3 (1.33)). Lastly, if you're very unlucky, then the 16:9 -> 4:3 conversion is going to consume some of your 480 lines for use with the black-bars, thereby also having vertical compression. If your 4:3 pro-scan TV can accept a wide-screen input and has excess vertical resolution, then it can generate its own black-bars, thereby fully reproducing the vertical component. Note that many TV's have excess vertical resolution (i.e. for Picture in Picture). Unfortunately, no matter what you do here, there are many DVD's that aren't properly designed with pro-scan in mind, and inappropriately set the pro-scan flags. The player has to compensate (or won't properly render the picture), and the more money you spend, the better the results (usually).
Still, unless you're in that upper income bracket, I'd say that anything below $2,000 that's pro scan, coupled with a half decent DVD player (such as the Toshiba 4700 for $225). Tweeter carries $1,100 pro-scan TVs in 4:3.
Lastly, for those that have a size complex, there is no differnce between having a TV that's twice as large verses sitting twice as close to the TV.. It's all about field of view.. In fact, a larger set is probably going to have poorer quality (due to convergence issues on said large projection sets). I personally would rather a picture tube and a properly engineered living room over said projection sets.
-Michael
Not if you take into account the cost of the hardware which usually superceeds the cost of the OS.
It's TCO that you have to worry about. For home users, yes, the relative cost is higher and thus vmware isn't really an advantage (unless you're into creative interpretations of licences), but for businesses that have to contend with down time (i.e. dual booting), there's definately net benifits.
-Michael
While I agree with you, I feel the need to at least put in the plug for capitalism.. When you acquire an MBA, econ degree, marketing degree, or any general business degree you are a highly specialized human being. Your focus is to squeeze profit out of a market better than your competitor. If you can't, then you are replaced by the board. If the board can't dictate policy effectively, then the share-holders replace the board. If the share-holders don't choose an appropriate board, then profits linger, P/E ratios drop, and investment firms lower their rating. If the rating drops, the share-price is sure to drop. Thus the investment firms sell stock, and the individual share-owners are dramatically encouraged to replace the board. Furhter, if investment firms that don't react harshly to harsh financial environments won't be invested in by individuals. Assuming Investment firms are mostly collections of lay-people's "retirement" money (401Ks, pensions, individual stocks, etc), then the entire drive to perfect the art of squeezing every last penny is largely propelled by sweet ole mom and pop. Isn't it ironic?
The main advantage to this system is economic efficiency (which has little to do with money). We distribute scarce resources to that which desires it most (or at least is willing to trade the most of another scarce resource). There's very little waste in capitalistic societies. The main sad part is that since you can acquire tradable goods (fiat money) more easily when you already have tradable goods (equity), then the value of a fixed quantity of money to a wealthy person is orders of magnitude less than that of a poor person.. Thus when bidding for a scarce resource, the most needy usually can not compete. But I've never seen a system that avoids this problem without just trading it for other just-as-serious problems.
Given the above, the US constitution is not in the most efficient form (nor could it be without adapting over time). Usually it any modifications to law and or constitutional rights lag behind the currently desired equilibrium (which is usually a compromise which doesn't fully meet anyone's desires, as it should be). But the mechanisms for enforcing these changes are by far not in line with economic principles. Democracy is at least closer than communism to an market-sensative adaptable system. Like the board, we remove the administration when it falls out of favor. But unlike a company, there is no clear direction (as with profit), so it's impossible to gaguge someone's resume' and determine if they stand a chance at better administration.
The general point, however is that we can't blame the MPAA or RIAA for their direction. They are the product of evolution. Anything they'd be replaced with would come to similar decisions. We can only competed with them for legislative efficacy. But like the wealthy and poor competing for a scarse resource, the money favors the large organization in enacting new laws.
The only out I can consider is to define a set of measurements by which a congresman's value can be weighed. How much like "measuring the worth of poety" [dead poet society] this sounds, but this is, indeed in the name of reaching a political equilibrium.
-Michael
Unfortunately you seem to want to have your cake and eat it too (don't you hate that phrase?). You praise perl for rapid design, and how features were added without compromising existing paradigms, then criticize the concept of TMTOWTDI. One of Larry's chief design goals has always been intuitive programming.. If you think something should work one way, then darn it, it should work that way. The problem is that Larry has to violate all sorts of consistencies:
if ( $x ) { doSomething() }
---
doSomething() if $x;
@file_list = ;
---
open FH,
@contents = ;
print MyObject @arguments;
---
print FH @arguments;
---
MyObject->print( @arguments );
---
$obj->print( @arguments );
And so on.
Granted, some syntaxes are only "intuitive" because that's how it use to work in perl4, so we'd expect something similar (albeit magic) in perl5 in another context. But that's the price you pay for having a history.
As with the switch statement, I never understood why Larry didn't include one. Even bash has:
case $x in
*.txt) # do stuff
*.pl|*.pm) # do stuff
*) # do stuff for default
esac
which was incredibly useful. My take is that Larry has finally found the huffman coding he's doing to the language compatible with this approach.
Remember, perl shares more with (k|ba)sh than c. (Need you look any further than the variable names?) So having nameing convenions different than "switch(x) case nine:.. break" is no straw off the camel's back *cough*.
As for streamlining the syntax-base. This could only hurt perl, since it would cripple the utility that we attribute to it. Larry is (hopefully) being very careful with what gets cut (such as formats which serve a highly specialized role or "?reg-ex?"). But notice even the teneray operator didn't stay alive. Larry determined that the ":" symbol was waaay too useful to waste on "var = cond ? true : false". So he mutated it to a parser friendly "con ?? true
Lastly, as for "everything is an object". This is purely from a parsing stand-point. In Ruby, you could theoretically do "1.print;" which would instantiate a new object. From the VM's point of view, a 1 is even more fundamental of a data-type than in perl5 since there was no concept of an integer, just a scalar. So unless you go around actually saying "1.method_name()", then you're not going to have any OO overhead.
As for OO being more cumbersome, I'd beg to differ. How about file-stat. Currently you use:
($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
$atime,$mtime,$ctime,$blksize,$blocks)
= stat($filename);
Or:
$uid = (stat($filename))[4];
Which is very cumbersome. Now how about:
$stat = stat $filename; (notice the lack of OO syntax thus far)
$uid = $stat.uid;
notice the perl6 syntax which avoids the "->". If you wanted compaction, then you wouldn't be able to avoid OO as follows:
$uid = stat($file_name).uid;
or
$uid = $file_name.stat().uid;
or just
$uid = $file_name.stat.uid;
But notice how OO producing LESS syntax instead of more. And that's the whole point.. If a technology / paradigm makes things more efficient, then why reject it.
-Michael
In the perl6-internals mailing list, you hear a lot of discussion about theoretical white-papers. Many developers perform complete implementations of these white-papers and are submitted as patches to the source tree.. From this, we can balance a multitude of variations on a theme, and pick the one we like best.
But most importantly, the system is being built heirarchicly, like an OS. Each layer builds apon it's foundation layers. Thus the "robustness" should not be a problem. The main problems are going to be dealing with particulars of the syntax implementations (since they're non-trivial languages).
As for Perl5 reuse. It's strange but very little has been reused. Suggestions to do so are quickly quelched. Perl5 was non-thread-safe, non signal-safe, non-extensible. Thus the new core's paradigm (which includes layers) doesn't fit much of the old core routine. I believe one of the old code were the scalars, which are now 100% different. The monolithic functions of old are now tiny optimized multi-indirected functions. One thing that I think "might" survive is complete rewrite is the reg-ex engine, and other such monolith single-purpose devices. But that's too far in advance.
-Michael
I already use Perl 6. It's called RUBY.
You miss the point. Perl6's syntactic redesign is mostly sugar. Likewise Ruby was mostly a syntactic redesign of perl5. Thus Ruby is not (nor will it be anytime soon) what perl6 attempts to accomplish.
You can think of perl as the x86. It's an aging legacy product that just never seems to die.. More-over, it's ever gaining market share (well, don't know about today with the recession and the migration to ASP). Why? because it did what was needed for a very wide audience. More-over this wide audience (coupled with open-source) afforded the sharing of code (mostly through modules) which avoided the constant reinventing of the wheel.
Sure there are viable alternatives to x86 (alpha, IA64, x86-64, etc), but they involve re-inventing at least part of the wheel, and many don't have the time. Someday python will have at least as much of a code base as perl5, but until it dwarfs perl5, it's not an "obvious choice". Ruby is just too new to really be compared on this level. What's more, so long as the inside is a black-box, who cares how it works; so long as it gets the job done in a cost effective manner (meaning either performance and or available code to reuse).
But this is exactly what parrot gives you. The ability (in theory at least) to use all of ruby, python, perl5, perl6, java, etc. Unlike JVM, which is early bound and thus can't "fully" utilize perl5 and friends, parrot should be able to run both java and perl5. In theory, the open-source platform could handly any language (albeit with missing optimizations here and there). So unless Ruby runs faster than parrot, there is nothing that it's black-box has over perl6 (and likewise the x86).
-Michael
Yup, and nope. We're new, but we have the benifit of hind-sight. Since we're open source, we can build upon any existing implementation of open-source jits/VMs. So lifetime is a red-hering.
We currently have a preliminary jit-compiler. Works pretty fast too. Currently it's 50% as fast as java's jit for a simplistic synthetic benchmark (considering the core isn't anywhere near finished). In theory parrot's jit can be faster than java's since we're using a register set instead of a stack-machine. Additionally, excluding java's grahpics library, perl has a larger collection of core c-routines for it's op-codes(Basically everything perl5 had). I'm curious to see if we can ultimately match java jit-speed; since we've already matched java VM-speeds. We also have a wider collection of fundamental types than java. Since strings in java are mostly handled by the String class. Then there's of course our ever-powerful scalar type with many useful low-level routines. In general, object orientation is at a higher level in parrot than within the java-VM.
-Michael
This already exists.. It's called CPAN.
In open-source (as with almost all perl), or when the 3'rd party was via another developer within the company, you at least have the option to trace through the code. Now most developers have to make some assumptions. These assumptions SHOULD be documented somewhere, but even when they are, the location of that documentation isn't always known. Perl again comes to the rescue with pod-documentation (similar to javadoc inlined documentation). You can put the description right next to the relavent regions, and at least in the relevant files. But, as we all know, developers are lazy and thus the added work of thourough documentation (in both java and perl) is lacking.
Now if you're proficient with the perl-code basics, then you have all the tools that you need to trace through a perl-module (or executable). Perl is highly context-sensative (name-spaces can be dynamically changed), arguably you have your work cut out for you (when it happens that sufficient documentation on such subtlties were not noted). The same can be said about java and package-spaces. There are tricks and tweaks a developer can do to perform efficient "magic" which is incomprehensible to an outsider (at least at first glance).
But to alleviate your problems, we have the debugger, which allows not only real-time inspection of the context, but thanks to the magic of late-binding, you can modify the context on the fly (importing new symbols, redefining old ones, etc, adding ad-hoc test routines). Java / C can't do this.
So yes, it is "harder" to debug / update someone else's code when they programmed above your level of proficiency. But if they were indeed more sophisticated developers they'd document their "magic". And if you weren't proficient enough to at least utilize the analitical tools at your disposal, then what are you doing modifying someone else's code?
-Michael
I do know about the FileHandle module. This module is proof that regular filehandles are too ugly. You shouldn't need the FileHandle module to be able to do basic filehandle stuff.
Well, I think you'll be dissapointed then. I don't think file-IO is going to be part of the core. Meaning I think you might have to include at least one module to get any IO to work.
Given that, FileHandle is outdated. Use
my $fh = new IO::File "...", ".."
Even if you hate OO, its the most feature complete of the file-types.. Not to mention it's the only one that evolves with file-enhancements.
TypeGlobs are going away I think, so *FH won't be applicable anymore (though perl5 compatabilty mode will deal with it properly). Likewise with the global symbols which aren't thread-safe I don't think.
-Michael
OO in Perl was a bolt-on, so it's not surprising that many of the features you claim it lacks were later bolted on. "use fields", for example allows you to have private member variables (just prefix the variable with an underscore). Likewise there are ways to produce private functions: declare an anonymous sub with my; it's even faster than OO.
Polymorphism in Perl5 is O(n) with respect to the inheritance tree depth, so it has the potential of being slow, agreed. None the less, I've never found OO-constructs to be the bottle-neck. (Ever use Devel::DProf?)
Once again, the bolting on approach.
my FooObj $obj = new FooObj...;
When used with the "use fields" and "use base" directives is fully type-case. In fact, I find myself using this for non-oo methods to enforce type-casing on hashtables (such as from database requests which would otherwise have NO type-casting in ANY language). It is the idea that you can use your knowledge of how the device works to minimize programming time (Such as w/ database queries), that perl's power shines.
Yes, it makes for more cryptic code on occasion. But that's just part of the learning curve. Did you ever get confused by:
struct my_struct_t (*my_func_ptr[20])(struct my_arg1_t arg1, int arg2);
When you work out the context it makes sence. The complexity is just a by-product of the adopted parsing conventions. Java tried to alleviate much of these syntactic line-noise, but it had the benifit of hind-sight. Java already has this garbage "bolted on" in subsequent versions:
BaseObj obj = new BaseObj() {
public run() {
};
Now C# has the advantage of hind-sight. But guess what, the next great feature will make even C# look occasionally awkward in version 3.0. That's what's great about evolution - you have all these wierd things like an appendix lingering around, and get to fuddle over what their original uses were.
In any case, one of perl's design goals has always been (and continues to be in perl6) huffman encoding of the syntax. Meaning easy things shouldn't require a whole hell of a lot of typing.. Java NEVER valued that. You can't just type a one line program. Even a simple (and VERY common) for loop requires:
Enumeration list = obj.createEnum();
try {
while ( list.hasMoreElements() ) {
MyFooType obj = (MyFooType)list.nextElement();
}
} catch ( InvalidIteratorException e ) {
But here's the catch... If you don't like the obscurity of say:
for my $idx ( 1
Then you can write:
for ( my $idx = 1; $idx The $_ variable itself is a good reason to boycott perl.
Granted, this was another legacy feature, but is still around because of the huffman encoding. If you're creating a new app and don't like cryptic stuff.. Or better yet, if you're a department and want to make it easy for new developers to join, then you simply utilize "use English" and viola, you have
"$ARG". No fuss, no fetter. (Though this doesn't work well in MT environments as I've found). But if you're not squeamish, then you can go the opposite route.. $_ was designed as the "default", and thus can be excluded in most uses. Thus
#!/usr/bin/perl
use IO::File;
$fh = new IO::File $ARGV[0];
while( $ARG = $fh->getline() ) {
$ARG =~ s/x/y/g;
print $ARGV;
}
can be replaced by:
#!/usr/bin/perl
use IO::File;
$fh = new IO::File $ARGV[0];
while( $_ = $fh->getline() ) {
s/x/y/g; # default $_
print;
}
can be replaced by:
while() { s/x/y/g; print; }
can be replaced by:
%> perl -n -e 's/x/y/g; print;'
can be replaced by:
%> perl -p -e 'tr/x/y/'
can be replaced by:
%> perl -p -e 'y/x/y/'
If you find yourself typing the first entry thousands of times for simple shell-scripts, you too would understand the power of the last statement. Once you've used the last statement enough times to memorize it, it's very hard NOT to use these features in your larger programs. Therein lies the problem. Most developers don't "use English" because they don't have to. Much like most java developers don't use javadoc comments (even though it's trivial to do so). Programmers are inherently lazy.. And that's a good thing (tm).
Not sure what you mean by sync int counter. In the highly volitile MT library you can just lock any variable to synchronize it.. That's the equivalent of:
synchronized (foo) {
in java. So no loss there. Additionally if you want non-blocking sockets in java, forget it.. It's not even an option. In perl, on the other hand, you have the full use of the non-portable ioctl and fcntl. What's more, you have "unix-select". Which is an awsome power to behold within servers.
A java-threaded instant messenger (via IBM benchmarks) crawled to a halt after some number of users had connected. The extra memory requirements for each thread were insane for such a simple task as IO multiplexing. select-based servers, on the other hand only have the overhead of one additional file handle. Granted threading approaches are insanely easy to understand and maintain, but they're not benifitial to performance (since the unix-select model could simply have multiple workers bidding for the same collection of file-handles). In perl, you have the choice to do either. In java, you don't.
More generally, this is a feature of any late-bound application. Ironically even Visual Basic (and hense most ASP) is early-bound. Python, Ruby, Lisp, and many others fall into this category. There are many unfortunate consequences of this design scheme, however. Most notably much compile-time-checking and provability of code. Further most concepts of object-oriented optimizations go out the window. Even perl6 which will be compiled will still be late-bound (It's just too useful).
For raw for loops, java is currently faster than Perl5; especially with a JIT. Perl5's biggest strength is in it's complex op-codes (grep, map, reg-ex, etc). This has the effect of JIT optimizing various high-use functions, but leaves basic flow-control to the mercy of performance.
Perl6 keeps the same complex and optimized functions of perl5 (though extracting them to external libraries to make the core clean), but utilizes the optimized byte-code and jit-able features of a java VM. Thereby getting the best of both worlds. In java, a reg-ex engine is most likely written in pure java. In perlX, reg-ex is optimized-c. Since their basic flow-control is now similar they should be comparible baseline.. Thus perl6 can only be faster than java (with equivalent code maturity). There is, however one additional MAJOR difference. Non jitted java is stack based, while perl6 is register-set based (I'm currently pushing Knuth's VM-register set for highly efficient subroutine calls).
Perl6 will NOT be an OO language, dispite many beliefs to the contrary. perl5 programs should be executable AS IS, and perl6 programs will look remarkably similar to those of perl5. There will be a higher performance OO support structure in perl6 than was in perl5 (which used recursive symbolic lookups on each method invocation), but this is completely optional, just as in perl5.
By the way, preliminary benchmarks show that non-JIT compilations of perl6 are faster than both perl5 AND java. We do have a JIT, but it's too rough to trust. But for our current trite benchmark, we're 50% of the performance of even the java JIT (and we avoid the overhead of a per-execution jit-compile).
So along with other posts, I believe that every element of your complaint has now been addressed.
perl6 focuses on speed, and compatability. While trying to reconsile convolution and complexity associated with perl5. Heck we're even supposed to be fully MT capable. Thus in all respects we should be able to compete directly against java and C#(including type-safety). So what exactly is your beef again?
-Michael
"neither" is vague. It's close to saying it's either light, dark or neighter. Transistors have two basic modes of operation (that I'm aware of) that fits a garden hose analogy; You either step on the hose (blocking current) or physically remove the foot (to allow current). You have to physically attach the gate to either a positive source or a negative drain, otherwise static charge will keep it in what-ever state it was previously. The output of a MOSFET is usually the gate of another mostfet. Moreover, the gate of a MOSFET is like a capacitor, so the role of the gate-controller logic is to charge or discharge the gate-capacitor. Thus having some "dim" state that is neither blindingly bright nor pitch dark only slows the process of opening or closing (charging/discharing) the targeted gate.
You might hear about a third "Z" state (cheater latches), but that's just when you don't connect the source of the FET to power or ground, but instead to the output of some other combinational logic. The idea is that when the FET is pinched off, you've electrically isolated one logic component from another. This is good for multiplexing (like memory arrays), where you'll have the output of multiple logic devices connected to a single input of another logic device, and you "activate" only one output device at a time. (The alternative would be to risk having the output of one device +5V, and the output of another device 0V, thereby short-circuiting).
Bipolar transistors are even worse since they never truely pinch-off, and even leak current into the control. But they have more efficient current characterisitcs (higher current swings) and thus work well to amplify the charging
These are the basic uses of FETs that I've encountered in my undergraduate EE cariculum. End result, there's no free lunch with trinary logic systems and current transistors.
-Michael
Tweak being the keyword. Tweaking fonts / colors is completely different than structure. The goal of an web art designer is to "structure" the web site in an erogonic and visually pleasing manner. Being a pure-hacker, I find distaste for such tweaks. I focus on just getting the data in and out of the users's head. I long for the ability of our graphic's designer to be able to take the data generated by my "business logic" and format it properly.
ASP/PHP/JSP/CGI generation of tables / forms does not easily lend to "tweaking" of format (only primative CSS tweaks). Instead what we want is a "winamp" style skinnability where each widget can be relocated at the graphic's designers whim, completely independant of how those widgets work.
There are only two technologies today that I can imagine that do this.. One is XSL, and the other is *gack* component-based programming. From this the components generate zero HTML, but instead internal data-structures which the front-end designer attaches to various HTML widgets (and can thus choose between drop-downs, check-boxes, tables, etc).
In another post, I suggest that if future browsers are XSL compliant, then we can offload all formatting to the browser and just render raw XML. The CSS and XSL would be static pages mapped to the XML data, which thus augments performance incredibly.
-Michael
Hello! I whole-heartedly disagree that ASP / PHP / JSP performs any separation (though not familiar enough with Cold Fusion). Instead they perform the exact opposite.. They interlace content, presentation and even security. They do not natively allow for the separation of work a hacker, an artist, and a DBA performs, since they all require arbitrarily aggreed apon artificial APIs.
Presentation is only separateable when function calls to "header", "footer", URIs are made. A new developer wouldn't necessarily know which file(s) to use for such linkage. Login authentication / authorization are often relegated to the individual web pages, which makes the vulnerability dependent on the bug-free-ness of each page (weakest link is weakest/buggiest URI). Granted, there are propritary means within each system to enforce authen/authz.
Though I'm not a great fan on XML, XSL allows a 100% separation of style (beyond even that of style-sheets). Even the use of head/foot within PHP/ASP doesn't allow external formatting of the individual tables as XSL does. What's more, theoretically future XML / XSL compliant browsers can off-load the server overhead of the presentation layer completely. Thus there is zero "extra layers" of work for the server. You generate XML however you please (just as you would HTML), then associate static style sheets / XSL sheets from which the future browser renders the image.
For the time being, all this technology is in flux. As I said, I'm no big fan of XML, but I've had to produce proprietary solutions to the data/format separation problem, since no existing "ASP-style" architecture solved it to my company's satisfaction.
-Michael
The obvious answer is because first you have the hit of decompressing
You're thinking LZ or huffman. But you could very easily perform utilize tag-id,data-length,data.
If tag-id and data-length are binary integers, then you reduce any tag combination to 8 bytes (which, except for single character tag-names is shorter). It most definately produces faster read-times, since you read entire chunks without lexical comparisons.
For 1-level-deep data-structures, this is pretty good.. You can even reduce the tag-size down to 1 Byte (thus have only 5 bytes overhead per CDATA). This is especially good for protocols between web-server apps, and the like. For multi-levels data-structures, you have the choice of either combining all the levels into new tag-types (though this doesn't allow for recursion), or have the reader keep track of state.
Since this can easily be converted back and forth between XML, what this could mean is that externally XML is used, internally compressed XML is used.
Note that even this has limited usefulness; only at all useful when interacting with 3'rd party apps, or when being saved to disk (to allow vi-modification).
-Michael
(Why partition registers by functionality?)
Well, simply it makes for faster CPUs. (unless most of the time you're physically interchanging from GPR to Address Registers). The Digital Alpha, for example, went even further and utilized two completely separate register sets for GPRs. I don't remember if the programmer was required to not perform operations that would pull from both register sets or not (e.g. was it just a caching localization, or was the bottom half and top half of the register address space physically separate).
The main advantage is a minimazation of ports on the register set and a reduction in the number of buses. Each execution unit typically requires one write port for each register. If you have 6 integer execution units, then that's 6 write ports (and probabably something like 6 read ports, but in theory 12 read ports). Each port requires an address decoder and extra levels of probagation in the register fetch stage.
Back in the old days, where we didnt see heavy pipelining (especially in first generation 68K), this was expensive and slow. The 68K was clean in many ways, which included separation of dissimilar functionality to segregated addresses and buses (and possibly execution units). Since there's no contention between addressing and general ALU operation, it's closer to true divide and conquor. Mix in the fact that the 68K CISC core could utilize op [Mem] = [Mem], [Mem], the load on address registers and logic was pretty heavy (at least in comparison to RISC architectures).
I once did a simple CPU design project which unified the FP regs and the int regs. The focus was on interchangability of data-types, and simplicy of design.. But what I quickly found was that in almost all cases (except register exchange) things were worse off.. The large register set had to have exteraneous fields to handle the various datatypes (even if they weren't used 99% of the time). That logic took extra probagation layers. Additionally, the number of address bits in the assembly code was upped (since fp ops couldn't assume a separate address space than int ops). Plus I found that the number of ports I had was horrendous.
Arguably, address calculation more regularly requires utilization of integer units, and thus there will be a significantly higher percentage of swapping betwen GRP and AR than between FPR and GRP. None the less, Motorola found it advantageous to do it that way.
Once Load/Store become popular (as with the PowerPC), the benifits of separate addressing fell off. (Number of mem accesses / instruction was now well below one).
Probably 90% of all consumers. Ever hear of windows millenium? That new fangled OS that I don't yet need to upgrade to? It still supports all those ugly 16-bit DOS features.. Sure they did away with the DOS boot-process. But DOS is most certainly there.. And until DOS is gone (a la NT / XP), CPU manufacturers still have to support it. Never mind the fact that even Linux is based on an initial x86 boot-process. (Though obviously it's not tied to it given it's multi-platform support). But out-of-the-box x86 Linux wan't 16-bit x86 supports.
Sure win 9x is "mostly" 32 bit if not all. But it most assuredly supports the sort of legacy x86 features that both software and HARDWARE developers take advantage of.
The AH,AL 8 bit registers you see are essential to call the CPU an x86 anything. If for no other reason than IO support (don't remember the exact instructions.. it's been a while since I've read an 8086 assembly book). Note that IO is pretty much unchanged in the Athlon (since so little actually uses it anymore; relegating to windows drivers and shared memory regions).. Interrupts are also used by these 8-bit registers. In fact, pretty much anything relating to the hardware drivers (minus AGP) depends on it.
I think the loss of the ISA slots should help ease the transition.. PCI with plug and play shouldn't be too hard to port to which-ever technology superceeds. But my point is that there isn't an absence of current-market vendors that still depend on these legacy features.
Aside from hardware, x86 had lots of macro-instructions, such as using CX as a 16 bit counter, and SP, BP for string comparisons. I'm sure these are micro-op vectors in the Penium on, but they still need to be emulated and debugged somehow, thus the register set still needs to be in tact. The real question is whether they make 64bit the fast-path (requring an extra logic probagation for 32bit), or if 64bit is considered the exception.
Aside from that, I agree with you that "staging out" is the way to go. XP should help (sadly) most consumers get rid of any remaining ties to the hardware (via hardware abstraction layers; assuming that's still there). But MS has no vested interest in making the same OS for servers as for consumers. They'd love to have a win3k that only runs on expensive hardware (where they can charge a premium), with their win4Suckers running on a legacy platform that allows them to boast over 1 trillion apps served. You can't buy that sort of marketing. Heck their current strategy is to not even acknowledge that other OS's exist. When was the last time you saw an MS commercial advocate themselves over someone else. (Like AOL still has to do. "No wonder we're number 1").
Sure Linux'll support what-ever and when-ever.. That's one of it's trademarks. But 64bit has a couple down-sides (including memory / cache requirements), and having a 64bit time-stamp or file-descriptor just isn't going to impress the other 99% of the code enough to run faster - the key is going to be end-user benchmarks and or raw MHZ. That's what draws peoples attention. And people's attention is what draws MicroSoft. And as we all know.. MicroSoft rules the world. (well, it's own world at any rate).
-Michael
McKinley is a whole mess of add-ons.. Not least of which is the idea that it can issue more EPIC instruction / clock than the Itanium. The original idea was that Itanium would chapion the instruction set, but would be an unwieldy beast with all it's new features.. But it would be enough to transition the market place (too bad it's practical performance sucked). McKinley would then be the knock-out punch that fully utilized it's potential (though at greater cost due to increased numbers of components). From this Itanium would be a low end that allowed "entry-level servers". Then they'd have time to go redesign new features for their next [incremental] generation... Their EPIC instruction set has templates so that adding whole new classes of functionality "should" be trivial.
Course I don't think they expected having to relegate Itanium as a "pilot" CPU with embarrasingly low frequency ratings (but MHZ is all that matters, right Intel?). Doesn't sound like the P4 guys are under the same marketing department as the Itanium guys (GM in the making?)
-Michael
Initially, the ALPHA's speed was due to "leaving complexities out"; it's minimalist approach to assembly (including a fuzzy FPU which was very fast if you didn't need ieee precision). But it definately didn't leave the emulation out cold. If I'm not mistaken, the ALPHA had a huge side ROMish type of thing that allowed VAX complex instruction translation lookups.
Fx86 worked fast because it incrementally translated x86 to native ALPHA. Drivers and OS libraries were already native. Thus only a moderate fraction of your code ever ran under emulation (given a long enough lifetime).
The reason hardware compatability is an issue is that if you don't have the R&D to port to multiple platforms, you choose the one that'll make the most money.. It's rarely your problem that things run too slowly; especially if the uppitiest customer will be willing to shell out for a maxed out current-state-of-the-art x86. (with proprietary motherboards that use faster memory, etc).
But even the ALPHA has legacy problems, as they're violating their "minamlist" approach by introducing out of order execution in their latest processors...
Oh how Alpha is missed.. I cheered the K7 because if I saved up enough money, I could get the Alpha version
-Michael
My only problem with comparing MySQL to Postgres is that you can't really use the same SQL code for both. Any sufficiently advanced database is going to have to make use of the non-portable feature-sets (such as auto-increments (sequence v.s. auto_increment)). Datetimes differ (as do maintanance of "last_modified" columns). Database creation scripts differ.
The above really only means that you can't just drop one database inplace of another (In fact, I've never seen this possible on a sufficiently advanced system. I've gone from Sybase to MySQL to Postgres to Oracle, and at best I could write a low-level portable API in perl to do most of the features IF you used the API instead of SQL).
But there's a more important point. Different databases have different ways of attacking the problem, and so you'd have to do a complete redesign to properly utilize a given system (and achieve those oh-so important benchmarks). I'm writing an app that's supposed to work on both MS SQL AND MySQL (one for development, and the other for production), but I have to program for the least common denominator (which is mysql). The lack of subquries causes me to rethink the design and write non-optimal code for either system.
My main point was that Slashcode isn't suited for anything other than a minimalist database, since most other non minimalist databases have proprietary ways of speeding things up (Oracle nested tables, postgres OO selects, Mysql mini auto_increment retrival, etc).
This isn't to say that slashcode was poorly designed because of it's minimalist approach. That's no different than saying anything that uses berkley file hashes is primative. It does it's job. Fullly SQL-capable just wasn't one of it's requirements. And for some, tape-backed up appended data-sets don't need full data-integrity requirements.
-Michael