There is nothing ignorant, stupid, or insecure in the comments made by Malachi. 1) Eclipse is not intuitive to newbies, and 2) Eclipse itself uses SWT and while SWT is not required (heck, you can use Eclipse as a text editor), SWT is somewhat less portable than Swing, which raises questions about which way to go. Tell me that there isn't anything factual or informative about either of those statements.
For example, you could say, "your statement is non-factual because there is this excellent tutorial about Eclipse and newbies need to go to that tutorial." Saying "I tried Eclipse and didn't have any problem with it" doesn't qualify because I don't have your resume, training, experience and life experience. And if as an evangelist of a product, even a product that takes sophistication on the part of the user such as a development tool, you suggest that people who have difficulties with that product are stupid, missinformed, or otherwise need to shut the heck up or keep their opinions to themselves, you are going to anger, discourage, or turn away potential users, and then you are going to wonder why that product does not catch on.
The choice of a development environment and GUI toolkit combination (such as Eclipse together with SWT) is a very important matter from the issues of ease of learning, ease of use, productivity, portability vs platform tie-down, features, capabilities and performance of the applications you develop. I spend whatever time I can spare looking over my shoulder at other platforms than what I am using to see if there is anything better out there. I also spend a fair amount of time on Slashdot because I can quickly get a feel for what is out there: from testimonials, from criticisms, and from the arrogant pose of some evangelists.
I am currently using C#/.NET because 1) I get to reuse all of the Delphi software I have developed for signal processing as ActiveX controls, 2) it has a C-like, Java-like syntax, and 3) the runtime performance and GUI responsiveness of this combination is very, very good. This setup has very bad vendor tie-in. Java is attractive because 1) it has C-style syntax and it is being taught in every CS department, 2) it is highly portable and is not Microsoft, 3) improvements are constantly made in its runtime performance. Eclipse/SWT is attractive because SWT tries to use more native GUI capabilities and not be as sluggish as Swing. On the other hand, it may have more Windows tie-in than you think. These issues need to be discussed and debated.
I develop engineering applications software, teach, and conduct engineering research, and in between all of that I try to evaluate development systems other than the ones I am using to see if it is worth making the switch, for myself and for my EE students. I found Eclipse non-intuitive, and I am certain I can figure it out, but then I have to teach it to electrical engineering students without taking up half the semester in a DSP class.
I find that Eclipse proponents, instead of trying to explain what Eclipse is about go around telling people who have difficulty with it that they are ignorant weenies, and I say I don't have time to waste on this. I think I will take a wait-and-see attitude -- if the thing is that good and gets enough mind share, I will invest the effort required to integrate it into my DSP class, but if its proponents are arrogant so-an-so's, I only need to wait for it to whither on the vine and I won't have wasted much time on it.
Malachi, I have had the same experience with Eclipse as you. It may be the most powerful development editor on the planet, but the menus and dialogs are non-standard relative to the pattern established by other IDE's. Is it powerful enough to be worth the "learning curve"? I guess you will have to go with other's recommendations.
I have also had the same experience that if you criticize something that has its defenders on these pages, you get moderated down as "troll." It is the famous "if you don't know how to use it you must be stupid" attitude that places a persons preferences ahead of how user interfaces play out in the real world (while developers are perhaps a more sophisticated set of users than many, a developer's tool is basically a user interface).
Also, why can't such matters be debated with reason. Do I see replies to your post "Yes, it is counterintuitive, but they did it this way because . .."
While saying "SWT library is a complete joke" may provoke a hostile response, your concerns are valid in that SWT is not the official SUN party line regarding multiplatform, and SWT looks suspiciously more complete on Windows than other platforms. This is an issue that merits some legitimate debate.
The BSOD problem is usually in the application inasmuch as Windows doesn't just die on its own. An application makes a call on a NULL object pointer inside a thread . . . and well, you get the idea. I know, I run apps like this -- my own, when they are being debugged. Of course one has the darndest time fixing such a bug because the program always crashes inside one or another Windows call where a debugger or trace statements do not go, and if you do this enough times, Windows BSOD's.
I run Windows 98 for weeks on end (Web surfing, compiling programs, testing compiled programs) with hardly a BSOD, and when I do get BSOD's they are mostly attributable to something I did to an application during development, which I can track down with a lot of gnashing of teeth.
If you are BSODing 3 times a day, it is some or another software you are running. Yeah, yeah, it is Windows' fault because there is very little defensive programming (validation of parameters of API calls) inside Windows, but it has to be some application that is doing it.
ActiveX is this brand name from Microsoft for whole bunch of things, but what most of us mean by ActiveX is those GUI widgets you can use in a Visual Basic program. Turns out you can use such a GUI widget (an ActiveX control) in almost any of the major programming languages for Windows and you can use it in a Web browser provided that browser is IE.
An ActiveX control (widget) is nothing more than a software module that implements a raft of crufty interfaces (the interfaces are ugly on account of the legacy aspects, and few programmer know what they even are because they use the wizards in whatever development tools they are using to automatically barf out code) based on the COM specification, and an ActiveX container (such as a Visual Basic app or an IE page) is nothing more than a program that supports that raft of interfaces.
An ActiveX control is a Good Thing because it is the closest thing to a "software IC" in the Windows GUI world -- it is amazingly cross-language in the Windows world. The new.NET languages consume and produce ActiveX controls with ease. It is not such a good thing because an ActiveX control kinda assumes it has access to the entire Windows API, so it is really locked in to Windows.
Also, an ActiveX control on a Web page is typically a client-side thing, think Java applet only without the sandboxing, so besides MS-lockin, you completely blow security, and the MS answer to security is this lame signing business (Scouts honor, this control is secure!). But since it lacks sandboxing, it is really quite capable and powerful -- it is like running little Windows apps inside your browser.
Part of Miguel de Icaza's deal with his Mono initiative is that he would like to see the Open Source world have something as software IC-like as the ActiveX control, and he things that his clone of.NET is the way to do it with some degree of sandboxing by using.NET widgets as the standard instead of ActiveX.
While the film Road Warrior was science-fiction fantasy, it was rather heavy in its emphasis of things automotive, and I always thought that it provided a glimpse of the Australian "motor-head" culture, similar in many ways to U.S car culture but with its own Australian flavor.
So in the plot to Road Warrior, this is supposed to be a post-nuclear war society where gasoline is very scarce apart from quantities stashed away by various tribal groups. So tell me, if gasoline is such a precious commodity, why are people driving around the Outback with big-block V-8 engines, superchargers, NOS systems and the like?
I use Delphi for API-level Windows programming, for developing VCL controls, and for developing COM and ActiveX controls. I find it much easier to deal with low-level Windows stuff in Delphi than C++ because if they needed a feature to support something in Windows, Borland just added it to Delphi while a lot of Windows support in C++ (take MFC, please!) is this ugly hodgepodge of classes, templates, macros, and straight API calls.
I admit Pascal is somewhat of a dinosaur in the syntax department, but then I started out on FORTRAN and Cobol. I think that Visual Basic and Modula have the right idea with if-then-endif style syntax instead of the clunky if-then-begin-end-else-begin-end only begin-end not needed if it is a single statement which you better not follow with a semicolon if it is in the then clause, but you had better be darned careful not to nest if's without guard begin-end's unless you really know what your doing. Yes, Pascal has clunky syntax, and no one seems to agree on where to stuff those begin-end's (I prefer Kernigan and Plauger's style of treating them like C braces and sticking then off to the sides of then and els), but then people still use VI, now don't they.
But Modula-Oberon-Component Pascal haven't really caught fire, and the switch to case-sensitive and making IF THEN BEGIN END all in caps makes programs really ugly, and Component Pascal is so far off in left field that I can't make sense of it -- I think it is the Objective C of the Pascal family (I program in C++ and Objective C object notation looks like hierloglyphics).
The Pascal-zealot idea that C and C++ are too dangerous and then you need a restricted, sandboxed language has gotten traction in the form of Java and C#. Not everyone agrees with this idea, but there are enough Java programmers to confirm that the Pascal zealots had a point. On the other hand, C syntax has won, although if you look at the wordiness of C# console I/O, you will see that some Pascal got snuck in through the back door. There is a lot of C# that is Delphi-in-reality; think of C# as pretty much Delphi with C syntax.
Why am I still using Delphi? 1) The Pascal language was designed in a restrictive way, not just for the student in CS but for the compiler writer. It parses in one pass, and Delphi is the darned fasted thing on the planet -- it compiles 50,000 lines in a blink of an eye. I type fast, so the fast edit-compile-execute cycle is more important than avoiding the typing of a few begin-end's. 2) I can publish my source codes without fear of revealing any trade secrets because the sort of people replying to your post with nasty things to say about Pascal won't strain their eyes to look at them.
I ran the AT&T synthesis through my trusty spectrum analyser and glottal pulse inverse filter analyser (http://www.medsch.wisc.edu/~milenkvc/tools.html) to see what they are up to.
It looks like they are using glottal pulses as you say, and they are doing the female voice (Crystal) by boosting the first two harmonics and by filtering out the range past 4 kHz and replacing it with noise to give it that breathy sound that is characteristic of female voices in American culture (this varies with culture -- the "Dame Edna" effect, yeah, I know Dame Edna is a dude in drag, but different cultures have different norms on how women are supposed to talk). I think they are doing some other tricks, like varying the formant damping pitch synchronously to fake the effect of a coupled voice source and vocal tract acoustic load.
At the segmental level the synthesis is kind of clunky, but at the voice quality level it sound remarkably good, especially Crystal. Mike (the male voice) sounds kind of buzzy at the voice level, but Crystal sounds quite female and quite natural.
Lets say that flying the shuttle is something that you do once in a lifetime -- to run a scientific experiment, as a former astronaut or a current politician pulling rank to get a ride, or because you are lucky enough to come through the astronaut program -- you do this once and then you step aside to let someone else have a ride.
Doing this means you have a 1 in 50 chance of dying by Shuttle.
The car has a 1 in 10^8 miles fatality rate. Suppose I drive (or ride) 12,000 miles a year for 70 years. That means I drive or ride close to a million miles in a lifetime, or have a 1 in 100 chance of dying by automobile.
Is the utility of a once-in-a-lifetime ride on the Shuttle similar to the utility of the use of automotive transport over the course of a lifetime?
So a sortie on the Shuttle has the same odds as a B-52 crew during Nixon's 1972 Christmas bombing of Hanoi? That is of course with North Viet Nam firing every SAM they had in their direction but the BUFFs having really good radar jamming but with the North catching on that when a B-52 made its "nuclear turn" over the target its jammer antennas went out of horizontal and the radar could pick them up for about a minute but then the B-52 crews switching to coming at Hanoi from every compass direction and the B-52's stopped getting shot down. The B-52 crews were not happy campers for being sent over Hanoi while it seems people are still lined up to fly the Shuttle if it ever goes again. But then a combat crew has to go back for seconds and thirds and more, each trip a chance to get shot down, while a single Shuttle crew member maybe flies once, perhaps no more than 3 or 4 times.
House is 1800 ft^2 above grade plus 600 ft^2 finished basement, gas hot water and heat, electric everything else (stove, washer, dryer, lights, TV, computers, forced-air heat, central air, dehumidifier), 2 occupants. The 19 ft^3 fridge uses 170 W running -- it averages 1 kWHr per day (from a power meter) (Amana top-freezer model with a $48/year power sticker, mid 1990's vintage). The furnace blower and forced draft motor together use 100 W running (Carrier Infinity with PM DC motors, microprocessor control, dip switches on motherboard selected for low-fire setting - 56,000 BTU per hour). The AC uses 2500 W running, but I have the blinds drawn during the day. I adjust AC and basement dehumidifier runtime for avg 75 degrees, 50 percent RH.
Electric usage (kWHr) Fb 185, Mr 174, Ap 161, My 191, Ju 438, Jy 361, Au 388, Sp 315, Oc 157, No 169, De 229, Ja 222 -- total is 2990 kWHr/year or 341 watts average load.
With the right appliances and lights (compact fluorescents mainly and some motion detectors), a house doesn't have to use as much electricity as you think.
Scientific visualization software can benefit from game API's -- I can think of uses for ScrollWindowEx() (hardware screen scrolls for maps, chart recorders, voice prints like the Kay 5500 hardware spectrum analyser used in forensic work), CreateDIBSection() (writing directly to bitmap pixels for blits), and IDirectDraw:WaitForVerticalRetrace() (to reduce flicker and tear).
How come none of this stuff made it over to.NET? (OK there is the image class LockBits() method, but things get ugly with unsafe code and pointers.) But there is no hardware scroll or vertical retrace synch available in.NET except for PInvoke down to Windows. How come Microsoft's fancy-shmancy new system is less capable than Windows?
When is.NET going to get access to stuff that even overlapping-windows based Windows API's have had for producing graphics and animation, not just for games but for all other kinds of software (maps, charts, recorders, spectrum analysers)? Or is.NET an orphan from the standpoint of gaming API's?
Does Microsoft (and many others) think that everything that is not a game is satisfied with a few buttons, menus, dialogs, and edit boxes? Don't applications other than games do serious graphics? How does.NET fit into this picture?
Lets see. I run my home on 3000 kWHr/year. For lights, electric stove, fridge, this computer, dehumidifier and central air in summer, for the furnace blower of a gas-fired furnace in winter, for everything. That is 347 watts 24/7. Divide 347 into the 150 kilowatts 24/7 gives over 400 homes. That is 2 cows per home.
If you could somehow build a SSTO spacecraft, that would also solve the problem of low-cost space access by offering airliner-like operations. No, it won't be as cheap as the Space Elevator, but it would be cheap enough to build those space solar power stations. Yes, the SSTO spacecraft only goes to LEO, but you could launch one to LEO, refuel it using a buddy system, and shuttle to geosynchronous orbit and back.
The questions is would SSTO even work? How much would it cost. Well, graphite-fiber composite was supposed to give such a boost in increased mass fraction that a SSTO was supposed to be feasible. We are only talking graphite, not carbon nanotubes here. It turns out the graphite composite cracked when cycled through with cryogenic propellant. And then they gave up on X-33 after spending a billion dollars.
If that carbon nanotube stuff has such great strength and is just within reach, you should have SSTO spaceships build out of it long before you build that Space Elevator.
Europe traditionally taxes engine displacement, hence all those little-bitty motors. Detroit traditionally didn't have that constraint, and "Detroit Iron", i.e. large displacement V-8 engines is a cheap way to get powerful, smooth-running, long-lasting engines.
As far as fuel economy, there is nothing that says that you can't, within limits, gear a large displacement engine really tall to get comparable fuel economy to a much smaller displacement engine. Perhaps the smaller displacement engine weighs less and takes up somewhat less space, allowing for a lighter vehicle, and the reduced mass of the smaller engine may produce faster engine warmups. Also, fewer cylinders can produce some economy gain from friction and heat loss considerations.
Also, these highly tuned small displacement engines have much peakier torque curves, so it is not clear how much the high horsepower contributes to having a quick, fun-to-drive car (unless listening to a tiny engine spool up is fun).
So, I think the notion of high horsepower per cc is overblown.
Isn't there a joke out there about how some "top-secret" Department of Defense code got accidently released to the public? It was only the last 10 pages of the source that got out, and it turns out the thing was written in Lisp, and that snippet of source was revealed to be only close parens . . .
If you hand over cash money to buy software, or a book, or any other copyrighted material, I think it stands that you own the particular pieces of media. As to any software "license", to the extend that copyright law applies, you can't take your book form B&N and start running off a 1000 copies to give to friends. To the extent that the unsigned-at-purchase EULA is stricter than copyright protection, I suppose it is bogus.
Microsoft seems to think everyone using Windows is too intellectually-challenged to use a file system. Do Files Open in Notepad and it starts up in My Documents, which is a kind of la-la land folder that maps into some or another fully-qualified path name by your reckoning. I never stick anything in My Documents -- I want to go to c:\user\docs\project1, thank you very much! OK, I drill down to c:\user\docs\project1 to open report1.txt. I now do Files Open in order to bring up c:\user\docs\project1\report2.txt. The freakin program plops me back in My Documents.
I could throttle whoever at Microsoft did this. Do you think that I could create directories docs\project1 under My Documents? No! Microsoft plops you back in My Documents -- My Documents is supposed to be this big freakin flat-file folder to hold every text document you ever work with. It is kind of like Microsoft wants tree-structure directories to go away, and be a good kid and put your documents in My Documents, put your.bmp files in My Pictures . . . I could scream!
I read the Web link article you listed and Googled to find Part 2 of that article.
Let me see if I have this straight. I have this object, this thing, that has the employee salary attribute. I am not supposed to touch that object to know what the salary is, and I am not supposed to know if salary is a float or perhaps a string because that is too implementation dependent. If I want to display salary on a form, the display capability for salary has to be wired into the employee object -- the employee object has to be able to output salary to a widget or perhaps dynamically create a widget capable of displaying salary?
You know, I don't care how pure OO one is, a person still has to get data from point A to point B. Some THING that represents salary has to be transmitted to some other THING that displays some pixels.
So I guess you are telling me that it it not OK to export an attribute as a float or even as something as universal as a string. I am supposed to transmit attributes as a bunch of calls to AWT (of all things in light of the discussion on this topic) to blt stuff across? And that directly poking at AWT is a purer abstraction than passing a string out of a data object and into a viewer widget?
The original Turbo Pascal (through Version 3) has to go down in history of one of the most amazing little products of its time.
Besides being the pioneering IDE (text editor, compiler, debugging runtime, runtime library), the whole freaking thing was a less than 40 kilobyte (yep kilobyte) image. My guess is that the runtime library was the first 10-12 kilobytes because that is what got grafted on to your apps. The rest was text editor (I still use the WordStar idioms with Borland editors to this day) and compiler. The belief is that the whole thing was written in assembly language, but my guess is that only the runtime library (largely Int 21 and Int 10 function calls -- remember those?) was in assembler -- no big deal as it was largely hooks into DOS -- and the rest was in my guess written in Turbo Pascal itself -- probably initially hand translated to bootstrap itself.
And you could peek and poke both memory and IO ports and make any DOS Int 21 or BIOS Int 10 or whatever calls you wanted that weren't in the runtime library -- who need assembly language, I used it to control everything from video cards to A/D boards.
And that runtime environment caught runtime errors and put you in the editor at that line number -- what a concept. Too bad something like that doesn't work today. I find that no current Borland product these days produces a useful runtime error line number anymore, mainly because the bombs I get these days are from supplying wrong parameters to the Windows API (as an old Turbo Pascal hacker I have no need for this Delphi VCL stuff, I program to the API), and Delphi throws up its hands because it can't trace crashes into the bowels of Windows.
I know, I know, people have their LCD's and love em, and I am in fact sitting in front of a Viewsonic 15 incher which is just perfect for writing, Web surfing, coding, and so on.
But for motion, LCD's will always have some ghosting, no matter how high performance they are. My theory is that a CRT is stroboscopic -- with the common phosphors it flashes an image, goes blank, flashes another image, goes blank. An LCD changes the image in steps -- it shows an image and keeps in on the screen, shows the next image and keeps that on the screen. With the right kind of panned image there is a clear difference, even at 60 fps or higher refresh rates.
In my opinion, LCDs are never going to be the equivalent of CRTs for motion images, but I guess people will call me a crank or I will be like one of those dudes who swears by tube amps. You can haul me before the video Inquisition, but I will mutter under my breath, "But it does blur!"
I guess the secret is out: while the explosive flash of a normal explosive causes burns, the microwave bomb will heat its target unevenly and leave it soggy in the middle.
The central problem of GUI programming is how to transmit that an event has occurred in once object (such as a button being clicked) to another object (of a class representing a containing form). It is not about objects but about relations among and connections between objects.
The low-level Windows API solution is the each object has a window handle and the interface that goes with that -- a WinProc. That means every window object has to expose the same, complex interface with a zillion Windows messages to every other window object it can come in contact with. This leads to (what some people) consider ugly -- the Giant Switch Statement in C implementations or those even uglier message map macros for C++ MFC (I believe wxWindows uses message maps too).
The Grand Quest is some simple mechanism for making direct signalling connections between objects without breaking encapsulation -- exposing the inner workings of every object to every other object: kind of like how to be on the Internet and disclosing your e-mail address without losing your privacy or worse.
The solution is to create some bridge class -- a courier with a personal knowledge of the recipient but a courier which publishes only a very generic interface to those seeking to contact the recipient. In Delphi that courier is an event type, in Java, it is an inner class with an ActionListener interface, in C# it is a delegate.
Qt has this mechanism called signals and slots, and to pull it off they had to extend the C++ language with this macro processor called MOC, and this has the BVDs bunched of C++ purists because they are in effect extending the language.
Slashdot Mirror
For example, you could say, "your statement is non-factual because there is this excellent tutorial about Eclipse and newbies need to go to that tutorial." Saying "I tried Eclipse and didn't have any problem with it" doesn't qualify because I don't have your resume, training, experience and life experience. And if as an evangelist of a product, even a product that takes sophistication on the part of the user such as a development tool, you suggest that people who have difficulties with that product are stupid, missinformed, or otherwise need to shut the heck up or keep their opinions to themselves, you are going to anger, discourage, or turn away potential users, and then you are going to wonder why that product does not catch on.
The choice of a development environment and GUI toolkit combination (such as Eclipse together with SWT) is a very important matter from the issues of ease of learning, ease of use, productivity, portability vs platform tie-down, features, capabilities and performance of the applications you develop. I spend whatever time I can spare looking over my shoulder at other platforms than what I am using to see if there is anything better out there. I also spend a fair amount of time on Slashdot because I can quickly get a feel for what is out there: from testimonials, from criticisms, and from the arrogant pose of some evangelists.
I am currently using C#/.NET because 1) I get to reuse all of the Delphi software I have developed for signal processing as ActiveX controls, 2) it has a C-like, Java-like syntax, and 3) the runtime performance and GUI responsiveness of this combination is very, very good. This setup has very bad vendor tie-in. Java is attractive because 1) it has C-style syntax and it is being taught in every CS department, 2) it is highly portable and is not Microsoft, 3) improvements are constantly made in its runtime performance. Eclipse/SWT is attractive because SWT tries to use more native GUI capabilities and not be as sluggish as Swing. On the other hand, it may have more Windows tie-in than you think. These issues need to be discussed and debated.
I develop engineering applications software, teach, and conduct engineering research, and in between all of that I try to evaluate development systems other than the ones I am using to see if it is worth making the switch, for myself and for my EE students. I found Eclipse non-intuitive, and I am certain I can figure it out, but then I have to teach it to electrical engineering students without taking up half the semester in a DSP class.
I find that Eclipse proponents, instead of trying to explain what Eclipse is about go around telling people who have difficulty with it that they are ignorant weenies, and I say I don't have time to waste on this. I think I will take a wait-and-see attitude -- if the thing is that good and gets enough mind share, I will invest the effort required to integrate it into my DSP class, but if its proponents are arrogant so-an-so's, I only need to wait for it to whither on the vine and I won't have wasted much time on it.
I have also had the same experience that if you criticize something that has its defenders on these pages, you get moderated down as "troll." It is the famous "if you don't know how to use it you must be stupid" attitude that places a persons preferences ahead of how user interfaces play out in the real world (while developers are perhaps a more sophisticated set of users than many, a developer's tool is basically a user interface).
Also, why can't such matters be debated with reason. Do I see replies to your post "Yes, it is counterintuitive, but they did it this way because . . ."
While saying "SWT library is a complete joke" may provoke a hostile response, your concerns are valid in that SWT is not the official SUN party line regarding multiplatform, and SWT looks suspiciously more complete on Windows than other platforms. This is an issue that merits some legitimate debate.
I run Windows 98 for weeks on end (Web surfing, compiling programs, testing compiled programs) with hardly a BSOD, and when I do get BSOD's they are mostly attributable to something I did to an application during development, which I can track down with a lot of gnashing of teeth.
If you are BSODing 3 times a day, it is some or another software you are running. Yeah, yeah, it is Windows' fault because there is very little defensive programming (validation of parameters of API calls) inside Windows, but it has to be some application that is doing it.
An ActiveX control (widget) is nothing more than a software module that implements a raft of crufty interfaces (the interfaces are ugly on account of the legacy aspects, and few programmer know what they even are because they use the wizards in whatever development tools they are using to automatically barf out code) based on the COM specification, and an ActiveX container (such as a Visual Basic app or an IE page) is nothing more than a program that supports that raft of interfaces.
An ActiveX control is a Good Thing because it is the closest thing to a "software IC" in the Windows GUI world -- it is amazingly cross-language in the Windows world. The new .NET languages consume and produce ActiveX controls with ease. It is not such a good thing because an ActiveX control kinda assumes it has access to the entire Windows API, so it is really locked in to Windows.
Also, an ActiveX control on a Web page is typically a client-side thing, think Java applet only without the sandboxing, so besides MS-lockin, you completely blow security, and the MS answer to security is this lame signing business (Scouts honor, this control is secure!). But since it lacks sandboxing, it is really quite capable and powerful -- it is like running little Windows apps inside your browser.
Part of Miguel de Icaza's deal with his Mono initiative is that he would like to see the Open Source world have something as software IC-like as the ActiveX control, and he things that his clone of .NET is the way to do it with some degree of sandboxing by using .NET widgets as the standard instead of ActiveX.
So in the plot to Road Warrior, this is supposed to be a post-nuclear war society where gasoline is very scarce apart from quantities stashed away by various tribal groups. So tell me, if gasoline is such a precious commodity, why are people driving around the Outback with big-block V-8 engines, superchargers, NOS systems and the like?
I admit Pascal is somewhat of a dinosaur in the syntax department, but then I started out on FORTRAN and Cobol. I think that Visual Basic and Modula have the right idea with if-then-endif style syntax instead of the clunky if-then-begin-end-else-begin-end only begin-end not needed if it is a single statement which you better not follow with a semicolon if it is in the then clause, but you had better be darned careful not to nest if's without guard begin-end's unless you really know what your doing. Yes, Pascal has clunky syntax, and no one seems to agree on where to stuff those begin-end's (I prefer Kernigan and Plauger's style of treating them like C braces and sticking then off to the sides of then and els), but then people still use VI, now don't they.
But Modula-Oberon-Component Pascal haven't really caught fire, and the switch to case-sensitive and making IF THEN BEGIN END all in caps makes programs really ugly, and Component Pascal is so far off in left field that I can't make sense of it -- I think it is the Objective C of the Pascal family (I program in C++ and Objective C object notation looks like hierloglyphics).
The Pascal-zealot idea that C and C++ are too dangerous and then you need a restricted, sandboxed language has gotten traction in the form of Java and C#. Not everyone agrees with this idea, but there are enough Java programmers to confirm that the Pascal zealots had a point. On the other hand, C syntax has won, although if you look at the wordiness of C# console I/O, you will see that some Pascal got snuck in through the back door. There is a lot of C# that is Delphi-in-reality; think of C# as pretty much Delphi with C syntax.
Why am I still using Delphi? 1) The Pascal language was designed in a restrictive way, not just for the student in CS but for the compiler writer. It parses in one pass, and Delphi is the darned fasted thing on the planet -- it compiles 50,000 lines in a blink of an eye. I type fast, so the fast edit-compile-execute cycle is more important than avoiding the typing of a few begin-end's. 2) I can publish my source codes without fear of revealing any trade secrets because the sort of people replying to your post with nasty things to say about Pascal won't strain their eyes to look at them.
It looks like they are using glottal pulses as you say, and they are doing the female voice (Crystal) by boosting the first two harmonics and by filtering out the range past 4 kHz and replacing it with noise to give it that breathy sound that is characteristic of female voices in American culture (this varies with culture -- the "Dame Edna" effect, yeah, I know Dame Edna is a dude in drag, but different cultures have different norms on how women are supposed to talk). I think they are doing some other tricks, like varying the formant damping pitch synchronously to fake the effect of a coupled voice source and vocal tract acoustic load.
At the segmental level the synthesis is kind of clunky, but at the voice quality level it sound remarkably good, especially Crystal. Mike (the male voice) sounds kind of buzzy at the voice level, but Crystal sounds quite female and quite natural.
Doing this means you have a 1 in 50 chance of dying by Shuttle.
The car has a 1 in 10^8 miles fatality rate. Suppose I drive (or ride) 12,000 miles a year for 70 years. That means I drive or ride close to a million miles in a lifetime, or have a 1 in 100 chance of dying by automobile.
Is the utility of a once-in-a-lifetime ride on the Shuttle similar to the utility of the use of automotive transport over the course of a lifetime?
So a sortie on the Shuttle has the same odds as a B-52 crew during Nixon's 1972 Christmas bombing of Hanoi? That is of course with North Viet Nam firing every SAM they had in their direction but the BUFFs having really good radar jamming but with the North catching on that when a B-52 made its "nuclear turn" over the target its jammer antennas went out of horizontal and the radar could pick them up for about a minute but then the B-52 crews switching to coming at Hanoi from every compass direction and the B-52's stopped getting shot down. The B-52 crews were not happy campers for being sent over Hanoi while it seems people are still lined up to fly the Shuttle if it ever goes again. But then a combat crew has to go back for seconds and thirds and more, each trip a chance to get shot down, while a single Shuttle crew member maybe flies once, perhaps no more than 3 or 4 times.
Electric usage (kWHr) Fb 185, Mr 174, Ap 161, My 191, Ju 438, Jy 361, Au 388, Sp 315, Oc 157, No 169, De 229, Ja 222 -- total is 2990 kWHr/year or 341 watts average load.
With the right appliances and lights (compact fluorescents mainly and some motion detectors), a house doesn't have to use as much electricity as you think.
How come none of this stuff made it over to .NET? (OK there is the image class LockBits() method, but things get ugly with unsafe code and pointers.) But there is no hardware scroll or vertical retrace synch available in .NET except for PInvoke down to Windows. How come Microsoft's fancy-shmancy new system is less capable than Windows?
When is .NET going to get access to stuff that even overlapping-windows based Windows API's have had for producing graphics and animation, not just for games but for all other kinds of software (maps, charts, recorders, spectrum analysers)? Or is .NET an orphan from the standpoint of gaming API's?
Does Microsoft (and many others) think that everything that is not a game is satisfied with a few buttons, menus, dialogs, and edit boxes? Don't applications other than games do serious graphics? How does .NET fit into this picture?
Lets see. I run my home on 3000 kWHr/year. For lights, electric stove, fridge, this computer, dehumidifier and central air in summer, for the furnace blower of a gas-fired furnace in winter, for everything. That is 347 watts 24/7. Divide 347 into the 150 kilowatts 24/7 gives over 400 homes. That is 2 cows per home.
The questions is would SSTO even work? How much would it cost. Well, graphite-fiber composite was supposed to give such a boost in increased mass fraction that a SSTO was supposed to be feasible. We are only talking graphite, not carbon nanotubes here. It turns out the graphite composite cracked when cycled through with cryogenic propellant. And then they gave up on X-33 after spending a billion dollars.
If that carbon nanotube stuff has such great strength and is just within reach, you should have SSTO spaceships build out of it long before you build that Space Elevator.
Europe traditionally taxes engine displacement, hence all those little-bitty motors. Detroit traditionally didn't have that constraint, and "Detroit Iron", i.e. large displacement V-8 engines is a cheap way to get powerful, smooth-running, long-lasting engines. As far as fuel economy, there is nothing that says that you can't, within limits, gear a large displacement engine really tall to get comparable fuel economy to a much smaller displacement engine. Perhaps the smaller displacement engine weighs less and takes up somewhat less space, allowing for a lighter vehicle, and the reduced mass of the smaller engine may produce faster engine warmups. Also, fewer cylinders can produce some economy gain from friction and heat loss considerations. Also, these highly tuned small displacement engines have much peakier torque curves, so it is not clear how much the high horsepower contributes to having a quick, fun-to-drive car (unless listening to a tiny engine spool up is fun). So, I think the notion of high horsepower per cc is overblown.
Isn't there a joke out there about how some "top-secret" Department of Defense code got accidently released to the public? It was only the last 10 pages of the source that got out, and it turns out the thing was written in Lisp, and that snippet of source was revealed to be only close parens . . .
Wings by British Aerospace
Fuselage by Messerschmidt
Assembly and system integration by Aerospatiale
Engines by (God help us) . . . Fiat
I guess jokes about the Iraqi army dudes speaking in Arabic that gets translated into cartoon English haven't gone mainstream yet.
G: There are bugs in Windows?
B: Yes, bugs!
G: Many bugs?
B: Yes, many, many bugs! Very terrible stuff.
G: What about Office?
B: Yes, bugs there too?
G: What about Justice Department?
B: Don't worry, Justice Department will blame drivers . . .
If you hand over cash money to buy software, or a book, or any other copyrighted material, I think it stands that you own the particular pieces of media. As to any software "license", to the extend that copyright law applies, you can't take your book form B&N and start running off a 1000 copies to give to friends. To the extent that the unsigned-at-purchase EULA is stricter than copyright protection, I suppose it is bogus.
I could throttle whoever at Microsoft did this. Do you think that I could create directories docs\project1 under My Documents? No! Microsoft plops you back in My Documents -- My Documents is supposed to be this big freakin flat-file folder to hold every text document you ever work with. It is kind of like Microsoft wants tree-structure directories to go away, and be a good kid and put your documents in My Documents, put your .bmp files in My Pictures . . . I could scream!
Let me see if I have this straight. I have this object, this thing, that has the employee salary attribute. I am not supposed to touch that object to know what the salary is, and I am not supposed to know if salary is a float or perhaps a string because that is too implementation dependent. If I want to display salary on a form, the display capability for salary has to be wired into the employee object -- the employee object has to be able to output salary to a widget or perhaps dynamically create a widget capable of displaying salary?
You know, I don't care how pure OO one is, a person still has to get data from point A to point B. Some THING that represents salary has to be transmitted to some other THING that displays some pixels.
So I guess you are telling me that it it not OK to export an attribute as a float or even as something as universal as a string. I am supposed to transmit attributes as a bunch of calls to AWT (of all things in light of the discussion on this topic) to blt stuff across? And that directly poking at AWT is a purer abstraction than passing a string out of a data object and into a viewer widget?
Besides being the pioneering IDE (text editor, compiler, debugging runtime, runtime library), the whole freaking thing was a less than 40 kilobyte (yep kilobyte) image. My guess is that the runtime library was the first 10-12 kilobytes because that is what got grafted on to your apps. The rest was text editor (I still use the WordStar idioms with Borland editors to this day) and compiler. The belief is that the whole thing was written in assembly language, but my guess is that only the runtime library (largely Int 21 and Int 10 function calls -- remember those?) was in assembler -- no big deal as it was largely hooks into DOS -- and the rest was in my guess written in Turbo Pascal itself -- probably initially hand translated to bootstrap itself.
And you could peek and poke both memory and IO ports and make any DOS Int 21 or BIOS Int 10 or whatever calls you wanted that weren't in the runtime library -- who need assembly language, I used it to control everything from video cards to A/D boards.
And that runtime environment caught runtime errors and put you in the editor at that line number -- what a concept. Too bad something like that doesn't work today. I find that no current Borland product these days produces a useful runtime error line number anymore, mainly because the bombs I get these days are from supplying wrong parameters to the Windows API (as an old Turbo Pascal hacker I have no need for this Delphi VCL stuff, I program to the API), and Delphi throws up its hands because it can't trace crashes into the bowels of Windows.
But for motion, LCD's will always have some ghosting, no matter how high performance they are. My theory is that a CRT is stroboscopic -- with the common phosphors it flashes an image, goes blank, flashes another image, goes blank. An LCD changes the image in steps -- it shows an image and keeps in on the screen, shows the next image and keeps that on the screen. With the right kind of panned image there is a clear difference, even at 60 fps or higher refresh rates.
In my opinion, LCDs are never going to be the equivalent of CRTs for motion images, but I guess people will call me a crank or I will be like one of those dudes who swears by tube amps. You can haul me before the video Inquisition, but I will mutter under my breath, "But it does blur!"
I guess the secret is out: while the explosive flash of a normal explosive causes burns, the microwave bomb will heat its target unevenly and leave it soggy in the middle.
The low-level Windows API solution is the each object has a window handle and the interface that goes with that -- a WinProc. That means every window object has to expose the same, complex interface with a zillion Windows messages to every other window object it can come in contact with. This leads to (what some people) consider ugly -- the Giant Switch Statement in C implementations or those even uglier message map macros for C++ MFC (I believe wxWindows uses message maps too).
The Grand Quest is some simple mechanism for making direct signalling connections between objects without breaking encapsulation -- exposing the inner workings of every object to every other object: kind of like how to be on the Internet and disclosing your e-mail address without losing your privacy or worse.
The solution is to create some bridge class -- a courier with a personal knowledge of the recipient but a courier which publishes only a very generic interface to those seeking to contact the recipient. In Delphi that courier is an event type, in Java, it is an inner class with an ActionListener interface, in C# it is a delegate.
Qt has this mechanism called signals and slots, and to pull it off they had to extend the C++ language with this macro processor called MOC, and this has the BVDs bunched of C++ purists because they are in effect extending the language.