I don't see the issue as being modular programming vs Big Ball of Mud. And there is no reason any particular shell script cannot be entirely written in C -- it is all the same Unix utilities and libraries that are function calls in C.
Why don't we write the whole thing in C? Well, the shell allows us to write quickly and hack around while the C approach has an edit-compile-link-test loop. Why don't we write the whole thing in shell or Perl or whatever? Because we need to optimize the slow parts.
So a given application has high-level parts that benefit from the flexibility of dynamic data types, access to a library of functions, running a line at a time to see what happens. It also has low-level parts to express looping algorithms in an efficient manner.
The big question is not whether you separate your application into high and low level parts; it is whether the high and level level parts are all written in the same language or in two languages.
The one-language approach has the advantage of having to be skilled in only one language and of easier piecing together of the high and low level parts. The one-language approach as the disadvantage that unless your OS is set up for that one language, there will always be something, some OS call or feature that will require interfacing to a C-style function.
The two-language approach has the advantage of a high-level language tailored for the high level, a low-level language tailored for the low level. The two-language approach can have the problem of impedance mismatch between the two languages, requiring a lot of adaptor plumbing, especially at the low-level language end.
The adapter plumbing in Unix consists of function calls to C-style plumbing along with pipes, accomplished with some more function calls. The adapter plumbing in Windows is COM, which is straightforward enough until you get into the full complexity of the barely-documented raft of interfaces required to implement an ActiveX control along with the ham-handed Microsoft approach to C++, where they throw classes, macros, templates, and machine-generated code at the problem, all at once. Python with its dictionary-dispatch of object methods is somewhere in the middle.
I think that the people doing a given dynamic language need to make a choice. If they are committed to the two-language approach, they need to work on having a streamlined approach to low-level extensions. There is a tendency to wall off the low level extensions into libraries and tell people "here are the (numeric, graphics, audio) libraries) -- they do everything you need and you don't need to write your own extensions, but if you need to write your own extensions, here are the C header files, and good luck." Well, the library-coded extensions cover a lot of cases, but sooner or later you are going to need to write extensions, and writing C extensions is often harder than writing straight C programs on account of the impedance mismatch of object models and data types between the high and low levels.
If you are going to the "One language to rule them all" approach, that language is going to have to be efficient on the low level in the manner of Common Lisp or related high-level one-language approaches.
If Greenspun's 10th Law is that every large program contains within it a custom implementation of Common Lisp, done badly, I propose that Greenpun's 11th Law should be that every dynamic language that strives to have general application will converge to the feature set of Common Lisp.
Lisp started out like a dynamic language -- interpreted, no data typing, everything is a list -- but it evolved to having a compiler, having arrays as well as lists, and way to specify data type or for the compiler to make a data type inference from the context. When it acquired those features, people could make the statement that "Lisp is as fast as C", an arguable point now but not even arguable back in the early days.
The parent post speaks to reading and understanding code with and without static data types, and I suppose data type along with (the horror, the horror) Hungarian notation have their pros and cons with regard to reading and maintaining code. But there is also a use for static data types in getting efficiency.
A dynamic data type means that data needs tags on it to determine the type and the meaning of operations performed on the data, and testing the tags means slower execution. Doesn't matter too much on how these tests are implemented -- test and branch, function pointers in a virtual method table -- you still have some form of tags and some form of tests. People will say "what about Moore's Law" and I will say "yes, what about it?" Moore's Law talks about growth in gates apart from speed, but the gates made available by Moore's Law have been used effectively to speed up programs based on static data types. Not only do static-data programs keep getting executed faster, the speedup of static-typed over dynamic-typed programs also keeps increasing. Yes, dynamic-typed programs execute faster on new hardware, but not anywhere near the speedup afforded to static-typed programs, and the gap keeps getting wider. It does not matter that a Python program is 100 times slower than a C program -- we are told to wait X years until hardware gets 100 times faster -- 100 times faster for a C program, but maybe only 10 times faster for a Python program, and we still have a factor of 10 shortfall.
Why is this? The current generation of processors utilize various forms of pipeline parallism, which benefits from tests and branches being sparse rather than at every instruction. With static typing, not only do we lose the overhead of the tests, the absence of the tests means that we can keep our pipelines full.
A static data type, whether spelled out with a type declaration or "discovered" by the compiler is a big efficiency win. An array type (basically a static list) is also a big help for efficiency, especially with the lists making up waveform samples for audio or bitmap images for raster displays.
All data does not have to be static-types, but if you have the provision for static scalar and array types along with sections of code that operates on those types with arithmetic ops, assignments, and indexed loops, you can translate those operations into fast-running code. You can even have array bounds checking of the looping statements are such that the bounds checks can be done on the first and last index values without having to do tests on every index in between. Things like Numeric or NumArray in Python don't count because not only are the implemented as C extension modules, you have to write your algorithms that do looping on those structures as C extension modules as well or give up on efficiency.
I can write a C extension module, you say. Back in the day of Fortran or even Turbo Pascal, one could write inline assembly language for speed-critical parts, but when optimizing compilers came along we gladly said goodbye to such tweaking and patching.
Once a dynamic language gets a way of specifying static-typed scalars and arrays, there is nothing standing in the way of optimization to achieve performance in the ballpark of C for things like audio, images, and looped numerical algorithms, all without C-language extensions, and at that point one will have duplicated what distinguished Common Lisp and other Lisp dialects of that generation from first-generation Lisp.
That new salesperson you hired. Everytime I talk to him about anything, he tells me to go "jump in the lake." And when I told him I would report him to you, he said you could also go "jump in the lake."
I see. Lets take a look at his sales records. Oh, last month he sold over a 5 million dollars of our product . . . I don't know about you, but if it comes to it, I can always get a new suit.
In the ECE department here, we have a course for doing "computer control" using LabView. The idea is to take a desktop computer and use it to "interface to the outside world", to input from sensors and control a robot or a miniature pumping station or whatever. There is also an embedded systems course, but this is using a PC as an embedded system. If you are building a million of something, you want to go with some kind of embedded system, but if you are building a one-of (classical thing is instrumenting an engine dynamometer test cell vs an engine controller for a production car), you may want to use a PC instead of going to the trouble of an embedded system.
Anyway, I think the idea of using a PC as a one-of embedded system, or perhaps using the PC as a console to an embedded processor development kit, is not such a bad way to go, but when you combine Windows and then layer LabView on top of it, you start to have long latencies that are a problem for closing a loop, but then the College upgraded all the computers used for those kinds of labs to P-4's and that is supposed to be fast enough.
I also have issues with using LabView instead of a more "to the metal" approach from a learning perspective. But I was in the hall when the a group of students on a project team had an RC model dune buggy with some kind of circuit boards as a payload and a cable connection to a laptop running a LabView setup. It was apparent that the system wasn't working because the students looked earnestly-anxious and were furiously scrolling through screens of "G" code (LabView fanboys talk about "G" the way others talk about "C", and "G" is that graphics spaghetti bowl of trying to represent loops and function calls with boxes and lines).
I guess this project team was getting the full computer-controller learning experience of trying to debug a program interfaced to hardware, and do so under time pressure of their project demo appointment. The LabView thing is not only supposed to be visual, it is supposed to appeal to EE hardware types because the displays are like circuit schematics, which they like, instead of like Java/C/C++ code, which they could care less about. On the other hand, once code grows in complexity beyond the simple demos the National Instruments dude gives, programming is programming and debugging is debugging, and these guys were getting the full measure of it.
As to the real hardcore hardware types, they use stuff like Verilog or VHDL for systems that are too complex for schematics, and hey, these things look much like programming languages.
Sometimes upgrading breaks applications. I had to upgrade to XP to upgrade a software development package I use, but it broke an old version of Acrobat Distiller, my CD labeling software, and a not-that-old version of LaTeX (for some lame reason I can't get a less then or equal sign anymore).
I guess I had to buy a new Acrobat Distiller, download a patch to the CD labeler, and I try to avoid less than or equal in my LaTeX documents until I can upgrade that -- nothing that can't be fixed with time any money, but the point is there is a whole lot of futzing around after an OS upgrade, just to find everything that is broken, and it takes so freakin' much of your time.
The only compensation is that during software development and debugging, errors that would lock up the machine can be dealt with through Task Manager to shut down a rogue app.
When you take this ecology-woodland home-compost outside too far, you achieve a certain harmony with the woodland creatures -- the tree squirrel, the raccoon, the skunk -- and they will come to your house and invite themselves inside your house by chewing through the attic vents.
While they say you are OK if you don't have fats, meat scraps, or bones, I wonder if coffee grounds, orange and banana peels, and other compost standbys create oders that welcome these creatures. Indoor composting may be the thing to help protect your house (or a dog).
I see a lot of example programs illustrated with nonsense variable names like foo and foobar.
My understanding is the the words snafu and foobar (orginally fubar) are acronyms, generated by soldiers during WW-II trying to assert their sanity and individuality within the impersonal bureacracy that is the military.
Snafu and fubar along with BUFF (the official military designation of the B-52 Stratofortress bomber aircraft) make use of a certain word. Since I am a civilian, I will use the civilian transliteration of the "f" as "fouled", although real military people don't use the civilian transliteration.
Snafu means "situation normal, all fouled up" and fubar means "fouled-up beyond all repair", while BUFF (a Vietnam-war neologism -- no one called it that in its Cold War role) means "big, ugly, fat, fellow" (OK, a variant on the f-usage.) From my aesthetics of things aviation, the B-52 is large, yes, but I think it is a rather sleek looking aircraft. The "ugly fat fellow" probably refered to the perspective of the enemy at the receiving end of the bomb pattern.
I had heard of fubar coming to computer usage when the run-time error message on some early FORTRAN systems for divide-by-zero was FUBAR -- the person writing the error message thought that was witty and probably didn't have any supervisor telling them to "clean that up" and "use something more explanatory and professional", and the geek FORTRAN programmers of that day were clean-shaven innocents with pocket pencil protectors who didn't know what fubar means.
The worst of this is Java example programs with
FooBar foobar = new FooBar();
My eyes glaze over when I see nonsense variables, especially in what is meant to be an illustrative example. The variable names can be short, but they should mean something, and is it possible to use Java examples where the class name and the object variable name are differentiated by more than change in case? Could we do
Is the B-Ark the first ship, which is actually a ruse because there is no A-Ark or C-Ark? How is it that the B-Ark gets sent first?
Or was there really an A-Ark and a C-Ark, but they never got launched in time?
Why Delphi needed to be in an "academic language"
on
Delphi Turns 10
·
· Score: 5, Interesting
Leave out that Borland's claim to fame and in-house expertise was with Pascal -- the whole Turbo Pascal lineup through the Turbo Object Pascal Windows that immediately preceded Delphi.
Things that are written in a "weaker" language, such as Visual Basic, tend to have the top level or the parts you are having your newbie app developer write in the "weaker" language, and they tend to have an "industrial-strength" language (such as C++) "under the hood." Visual Basic consumes ActiveX controls that are written by specialist developers in C++. Now in later versions of Visual Basic you could write ActiveX controls in VB, but am I correct in saying that using an ActiveX is considered "easy", but generating an ActiveX is considered pretty hard core, even with all of the VC++ "wizards" to generate the program skeletons?
You have this type of dichotomy in the "scripting" languages -- you write the app in Python but you write C/C++ extension modules to do the hardcore, time-critical, low-level stuff. The other extreme is Common Lisp, Smalltalk, and Java. While these are considered "easy" languages (not saying Lisp is "easy", but Paul Graham claims he can do much more stuff more quickly with it) -- you are encouraged to do everything in Lisp if you are using Lisp, everything in Java if you are using Java, and while Java has the JNI, its use is discouraged by the official Sun party line. I see Python working on growing from "just being a scripting language" to an attempt, with the right libraries, to make Python another Common Lisp, Smalltalk, or a Java.
I think that Borland went for the unified approach -- the Visual Form Designer allowed programming with drag and drop, it automatically wrote the Pascal, and you weren't really supposed to touch the Pascal very much. In fact, the generated Pascal was so parsimonious, I was afraid of it because I didn't know what was going on -- a lot of what was going on was that objects were initializing themselves and connecting themselves in the form/control hierarchy by reading in state information from the.DFM files (which you can view as ASCII text -- this forms the "second Delphi" language which is a kind of Pascal-syntax XML).
Then you had component development, which was supposed to be done by object inheritance and by writing some hard-core Pascal code -- there were (at least a first) no wizards to guide this, and extending a class by inheritance is a much tougher programming job and the code writer-driven composition of a top-level Delphi app.
Of course, the component developers were supposed to be the hard core programmers, and they could be fewer in number because they would publish their components for reuse for the vast army of Delphi Form Designer weenies. But if the Form Designer weenies were to use dBase Basic, there would have to be a Pascal/C++ other product (at least in the first iteration) to do component developement.
The argument for a single-language universe is its uniformity. The argument for multiple languages (VB.NET/C#.NET doesn't count as those are simply syntax "skins", but Managed C++ may count) is that different languages are suited for the different levels of an app.
Delphi, how I love thee, let me count the ways
on
Delphi Turns 10
·
· Score: 3, Informative
1. Alternative toolset to Microsoft -- if you didn't like the Microsoft way, you had an alternative.
2. Blazing-fast compiles -- there is nothing out there like it, not even the IBM Jikes Java compiler comes close.
3. Great string handling. They even extended their dynamically-allocated string idiom to arrays of primitive types.
4. Made Pascal more C-like -- the PChar C-like null-terminated string (they had to introduce it to be compatible with Windows, but now that they have "gone.NET", they are deprecating it). While it made Pascal less safe, the "I can write a 2-line C program that takes pages of Pascal" kind of went away. You can cast types, pointers, etc, to "remove the safety locks" if need be.
5. You don't have to use the VCL -- you can program to the Windows API if you are so inclined.
6. Good debugger, {$APPTYPE CONSOLE} compiler pragma allows opening a console Window in a
Windows app for logging traces, etc.
7. While the support for COM and ActiveX not nearly as seemless as the VCL, a lot better than MFC/ATL.
What don't I like? I am old Pascal hand, but all that typing is getting a little tiresome after doing work in Java and C++. Also, an ActiveX control is this single.OCX file, and it works across Windows versions. To distribute.VCL controls, you have to have a freakin differnt version for each version of Delphi (Delphi version upgrades break more stuff than Windows upgrades).
My favorite reference on the JNI is at
http://tns-www.lcs.mit.edu/manuals/java-api-1.1bet a2/guide/nativemethod/jniTOC.doc.html. As to C++ calling Java, I have two pieces of advice -- one is to call the function to check if you already have a VM before trying to create a VM -- this is needed when running from the Matlab or other environments or sandboxes that fire up VMs. The other piece of advice is that if you keep a handle to a Java object as a data field inside a C++ object, you gotta, gotta have a global lock on it otherwise it will bite you in the butt at an unexpected time (it won't fail 100% and create a lot of debugging) -- this is true whether you call Java from C++ or C++ from Java.
The C++/Java interface goes both directions -- C++ calls Java or Java calls C++. The usual way is that you write a program in Java, and you use the JNI to call down to C++ to get at some low-level/system-level function -- SWT does their native widgets this way.
I have in mind writing the application in C++ using the Windows API (the application is already written that way) and using Java for plug-ins, extensions, numerical processing modules and saving GUI migration for last. One, this is a way of incrementally migrating to Java. Two, it is doing the non-GUI code first, and identifies as much of the app as non-GUI and portable that can be split off. Three, the Java class and JAR files seem like a better kind of DLL -- think of them as platform-portable DLL's that are much less bulky than C++-generated DLL's under Windows.
As to being able to do this in C#/C++, if you write the main app in C#, calling C++ DLL's, COM objects, or ActiveX controls is a piece of cake. Calling C# from C++ is clunky. The C# object has to publish itself as a COM object/ActiveX control and you have to go through some song and dance to register it to make it available that way. Bet it is no big deal having done it once, but every time I get the feeling to do this, I read the long instruction list and decide to lie down until the feeling passes.
As to comments by others that unmanaged C++ calling C# is, I don't know, evil or something, if that is evil than every unmanaged Windows app that doesn't use.NET is equally evil. But if you accept a place for unmanaged Windows apps, there is no difference between calling an unmanaged DLL and calling a managed DLL -- there is no added security lapse for doing this.
By the way, what got me started on this is that you can pretty easily call Java from Matlab -- I think Matlab is a pretty good scripting environment for Matlab because you can create instances of any Java class and invoke any of their methods without needing a static main() method as a Java program entry point. Well what Matlab can do, any C++ program can do the same through JNI.
BeOS had a reputation for not only being fast, but being very realtime and very low latency, and well suited for multi-media.
Windows has always been a dog in the latency department, and the *nix's never had a great reputation there either. The argument "this is a desktop operating system and they are trying to maximize throughput on the kind of tasks users do rather than realtime", but the time slices given especially to disk reads seem kind of high. The only thing that has made Windows a contender in any kind of multi-media/video game/flicker-free video is Moores law -- computers run so fast that the unswitchable tasks complete that much faster.
What is the take on OS-X? What are the latencies? Are there any in the tens of milliseconds or more like Windows? I know none of these systems are hard realtime, but if you have typical latencies in the small numbers of ms, there is less interference with screen updates at video rates.
What is it like for the application developer? What kind of screen refresh rates are possible? Can you synch screen writes with vertical retrace? Is there acceleration for 2-D scrolling?
From my perspective, Swing is not the real stumbling block.
Sun has this whole take-it-or-leave it notion about Java, but I have been interested in migrating to Java by rewriting parts of my apps. The JNI allows Java to call C++, but it also allows C++ to call Java, and while parts of it are a little cumbersome, it is well-documented and you can wrap the plumbing in a set of C++ and Java classes. My notion is that I can start with the non-GUI parts of the program, and perhaps even some of the GUI parts by using the MVC and strategy design patterns to uncouple code from the Windows API code, and over time develop something that is easier to migrate away from Windows. Oh, don't worry Chairman Bill, I am probably not leaving Windows anytime soon, it is just that Java has good features and libraries and I am interested in using it.
For mixed Windows API-managed code programming, I like C++/Java better than C++/C# because to access C# modules from Windows API C++, you have to go through a lot of Windows jive with the GAC and other bits of Klingon language. Connecting C++ and Java through the JNI seems easier to me than connecting unmanaged C++ to C#.
The hassle is that I am really reluctant to make any program I distribute dependent on a Java install on a Windows computer because there is so much to go wrong -- not setting up the PATH, CLASSPATH considerations, and so on. It is not insurmountable to get Java going under Windows, but it is something for users of one's software to not get right.
If MS and Sun were to truly make nice, I would like to see the Java runtime integrated with Windows so you could count on it being there if you distribute apps under Windows. Heck, I would settle for the.NET runtime being part of Windows, but even that you have to download and there is a futz factor setting it up.
I thought the whole point about Buck Rogers (thinking the old version, not the Erin Gray/Gil Gerard version), was that spaceships landed tail first with their engines firing for braking thrust and landed on their tail fins.
When I heard about the DC-X approach to reusable spacecraft reentry and landing, my reaction was "that is so Buck Rogers" meaning that I didn't think that landing on rocket thrust made sense.
But the Soyuz lands tail first on rocket thrust (it has braking rockets for the final ground contact to supplement the parachute), and that has advantages over wings and wheels.
So saying Buck Rogers should mean a solution without wings and wheels.
Gee, what about the Newton? Was that such a big flop that people don't even remember it to make the list?
The Newton was a Palm Pilot before there was a Palm Pilot, and it was supposed to have handwriting recognition, but it didn't live up to expectations. The breakthrough of the Palm was that you had to relearn your handwriting in this gestures thing the computer could understand.
Borland Delphi uses the.dfm file to work pretty much the same way as you describe the.nib file.
When Anders Hejlsberg crossed over to the Dark Side,.NET didn't use that approach -- they use the code-generation approach instead of the object-property serialization approach.
Don't know if there is a way to hack the.dfm files to change and app with source -- I believe the.dfm's stick around during compile and their info is folded into the.exe file so you don't distribute the.dfm's with the binary app.
I am in the incrementalist school and agree with you, and agree with Joel Spolsky's take on "clean-sheet of paper rewrites."
On of the classic big software projects gone bad was the failure of the revamp of the air traffic control system, which was stiched together with creaking mainframes and had old CRT terminals. The rewrite/redo/new system was a classic "Bridge too Far" (Operation Market Garden from WW-II a classic "massive rewrite" instead of an incremental approach. They were going to use paratroopers to capture a whole lot of bridges in Holland, and then the main body of the army was going to come motoring through all of those bridges and straight into Germany to end the war. The main army got bogged down at the first bridge and the British 2nd Airborne Division got hung out to dry at the last bridge, and a British general offered up British understatement as to why the whole plan failed as "it was simply a bridge too far."
In the case of the ATC rewrite, they concentrated on the ATC controller workstation -- the thing with the big CRT where all the flights show up on radar but with alphanumeric info added -- but it was going to be the ATC workstation to end all workstations, and it got caught up in a mire of specs.
I surmise that it was supposed to be a massive bitmap graphic CRT back in the day when megapixel bitmap graphics was bleeding edge, and it was supposed to customized, both for the preferences of the controller as well as the geography it was to cover using some kind of configurable software, back in the day when people hadn't heard of OO and GUI frameworks.
I always thought they should have done something incremental, but I guess I never understood their problem domain well enough to know what incremental would be.
But what ever happened to ATC? Are they still using battleship CRT monitors driven by creaking mainframes? Did they come up with something that works using newer technology?
What level of alcohol can cause dementia? Is it the direct effect of the alcohol on the brain, or is it the effect of malnutrition related to alcohol consumption.
My experience with a family member and more recently with a friend suggests that alcohol consumption and related health and cognitive problems may be a be more of a problem than people let on. Is consumption of 10 ounces of vodka a day problematic? I observed this level of consumption in an 80 year old not long before that person had to enter an assisted-living home for memory problems. Is this kind of alcohol consumption a cause of dementia or a symptom of it?
And I don't think the AA 12-step program traditional approach to alcoholism really addresses the problem because that school of thought addresses people who "hit rock bottom" and need a fresh start on life. I am talking about old people who are thoroughly habituated to high levels of alcohol and you wouldn't know a person drank that much unless you went through their bottle recycling and counted the bottles that went in each week.
I guess the reason I am seconding your point of view and getting all excited about "alcohol wards off dementia" is that alcohol is hard to restrict to that one drink per day, especially in elderly people who feel they have diminished levels of responsibility in retirement and feel they can handle their drinking.
Delphi has separated out the object class and procedural methods part (the.pas file) from the object hierarchy and configuration through property settings part (the.dfm file). The.pas files are operated on largely through the text editor and in a more limited way through the visual interface while the.dfm files are operated on almost entirely through the Form Designer and Object Inspector and their direct textual manipulation is discouraged through obscurity of the documentation on this.
The.dfm file is binary, but it has a textual representation which is in Pascal syntax -- I guess they have a Pascal parser (while not Lisp, I hear that Pascal is pretty easy to parse) that they use to that purpose.
If I were in charge, I would be a little less coy about the.dfm file and its textual representation. I may also consider a standardized Pascal syntax for describing graphs and data -- there is this thing called VHDL that has an IEEE standard and is used for hardware design, but it seems perfectly suited for a Pascal-syntax answer to XML. And for you C-syntax proponents, there is this thing called Verilog.
Clarke had the Discovery originally going to Saturn with the Big Monolith placed on Iapetus while in the movie, the Big Monolith was floating around in Jupiter orbit, but then in sequel books he moved the action back to Jupter as well.
If Clarke is free to change his story around between Saturn and Jupiter to suit his fancy, I think we can let our jokes float around the same.
The Unix/workstation (SUN, Silicon Graphics) people have dabbled in Linux, not because it is FOSS but simply because it runs on cheap hardware. They are *nix people because that is what they do, not because they are Linux evangalists.
They are all going to go out and buy Macs because 1) they have decided that Macs are cool, 2) that Macs are BSD under the hood means it runs all of their stuff, and they prefer BSD to Linux given the choice, 3) they have funds to pay for it and always wanted a Mac anyway.
I suppose there could be two aspects to the Biosphere II experiment. One is to understand in microcosm how life allows Earth to have an atmosphere with 21 percent O2. The other is to develop a self-sustaining ecology to provide food and oxygen for a space colony or a Mars expedition.
Nick Lane's book Oxygen argues that the Earth's oxygen is not a tightly-regulated homeostatic system -- the old saw about the Amazon being the lungs of the Earth. The oxygen in the atmosphere is the result of the small excess of carbon fixed by plants that doesn't get consumed or decayed by animals and bacteria, with volcanoes supplying the makeup CO2 to drive the process. Just as the fossil fuels are the relic of this process, O2 is the fossil gas relic of the process. The only reason we are not burning up all the oxygen by burning coal is that most fossil fuel is very low grade shales and sandstones while coal, gas, and oil are only a small quantity of concentrated carbon.
The claim is that contrary to the Gaia Hypothesis which would argue for tighter homeostatic control of O2 and other gasses, O2 reached 35 percent during the Age of Coal (Carboniforous) while some tens of millions of years later in the Permian, O2 crashed to 15 percent. Scientists are supposed to know this from isotope ratios in rocks from those strata.
So the Earth is a poor model for a closed ecological system in that the processes controlling O2 operate over geologic time and are perhaps less tightly regulated than once thought.
About those "platform-specific" SWT libraries
on
NetBeans 4.0 Release
·
· Score: 1
SWT is multi-platform in the same way Swing/AWT is multi-platform. There is a software layer, somewhere, that does JNI calls to get access to the display. That SWT tends to use more the native widgets and Swing tends to use only a blit call from the native graphics to roll its own widgets and then do this "look and feel" dance to try to look like the native widgets on your system in the first place is just a difference in design and implementation.
The deal is that SWT does not have the official stamp of approval from SUN, so you have to load a separate "SWT driver" (some.dll's or.so's) for your specific system, or if you distribute software, you have to bundle all those different drivers or tell people they have to download the one for their system themselves. Swing has the SUN seal of approval, so it is bundled with the Java runtime, and if you were able to download the Java runtime on your system, you got Swing. There is a different Swing "driver" for each different system, but you had to download a different Java runtime depending on whether you are running Windows, Linux, OS-X, etc, so you got the correct version of Swing when you did that.
Slashdot Mirror
Why don't we write the whole thing in C? Well, the shell allows us to write quickly and hack around while the C approach has an edit-compile-link-test loop. Why don't we write the whole thing in shell or Perl or whatever? Because we need to optimize the slow parts.
So a given application has high-level parts that benefit from the flexibility of dynamic data types, access to a library of functions, running a line at a time to see what happens. It also has low-level parts to express looping algorithms in an efficient manner.
The big question is not whether you separate your application into high and low level parts; it is whether the high and level level parts are all written in the same language or in two languages.
The one-language approach has the advantage of having to be skilled in only one language and of easier piecing together of the high and low level parts. The one-language approach as the disadvantage that unless your OS is set up for that one language, there will always be something, some OS call or feature that will require interfacing to a C-style function.
The two-language approach has the advantage of a high-level language tailored for the high level, a low-level language tailored for the low level. The two-language approach can have the problem of impedance mismatch between the two languages, requiring a lot of adaptor plumbing, especially at the low-level language end.
The adapter plumbing in Unix consists of function calls to C-style plumbing along with pipes, accomplished with some more function calls. The adapter plumbing in Windows is COM, which is straightforward enough until you get into the full complexity of the barely-documented raft of interfaces required to implement an ActiveX control along with the ham-handed Microsoft approach to C++, where they throw classes, macros, templates, and machine-generated code at the problem, all at once. Python with its dictionary-dispatch of object methods is somewhere in the middle.
I think that the people doing a given dynamic language need to make a choice. If they are committed to the two-language approach, they need to work on having a streamlined approach to low-level extensions. There is a tendency to wall off the low level extensions into libraries and tell people "here are the (numeric, graphics, audio) libraries) -- they do everything you need and you don't need to write your own extensions, but if you need to write your own extensions, here are the C header files, and good luck." Well, the library-coded extensions cover a lot of cases, but sooner or later you are going to need to write extensions, and writing C extensions is often harder than writing straight C programs on account of the impedance mismatch of object models and data types between the high and low levels.
If you are going to the "One language to rule them all" approach, that language is going to have to be efficient on the low level in the manner of Common Lisp or related high-level one-language approaches.
Lisp started out like a dynamic language -- interpreted, no data typing, everything is a list -- but it evolved to having a compiler, having arrays as well as lists, and way to specify data type or for the compiler to make a data type inference from the context. When it acquired those features, people could make the statement that "Lisp is as fast as C", an arguable point now but not even arguable back in the early days.
The parent post speaks to reading and understanding code with and without static data types, and I suppose data type along with (the horror, the horror) Hungarian notation have their pros and cons with regard to reading and maintaining code. But there is also a use for static data types in getting efficiency.
A dynamic data type means that data needs tags on it to determine the type and the meaning of operations performed on the data, and testing the tags means slower execution. Doesn't matter too much on how these tests are implemented -- test and branch, function pointers in a virtual method table -- you still have some form of tags and some form of tests. People will say "what about Moore's Law" and I will say "yes, what about it?" Moore's Law talks about growth in gates apart from speed, but the gates made available by Moore's Law have been used effectively to speed up programs based on static data types. Not only do static-data programs keep getting executed faster, the speedup of static-typed over dynamic-typed programs also keeps increasing. Yes, dynamic-typed programs execute faster on new hardware, but not anywhere near the speedup afforded to static-typed programs, and the gap keeps getting wider. It does not matter that a Python program is 100 times slower than a C program -- we are told to wait X years until hardware gets 100 times faster -- 100 times faster for a C program, but maybe only 10 times faster for a Python program, and we still have a factor of 10 shortfall.
Why is this? The current generation of processors utilize various forms of pipeline parallism, which benefits from tests and branches being sparse rather than at every instruction. With static typing, not only do we lose the overhead of the tests, the absence of the tests means that we can keep our pipelines full.
A static data type, whether spelled out with a type declaration or "discovered" by the compiler is a big efficiency win. An array type (basically a static list) is also a big help for efficiency, especially with the lists making up waveform samples for audio or bitmap images for raster displays.
All data does not have to be static-types, but if you have the provision for static scalar and array types along with sections of code that operates on those types with arithmetic ops, assignments, and indexed loops, you can translate those operations into fast-running code. You can even have array bounds checking of the looping statements are such that the bounds checks can be done on the first and last index values without having to do tests on every index in between. Things like Numeric or NumArray in Python don't count because not only are the implemented as C extension modules, you have to write your algorithms that do looping on those structures as C extension modules as well or give up on efficiency.
I can write a C extension module, you say. Back in the day of Fortran or even Turbo Pascal, one could write inline assembly language for speed-critical parts, but when optimizing compilers came along we gladly said goodbye to such tweaking and patching.
Once a dynamic language gets a way of specifying static-typed scalars and arrays, there is nothing standing in the way of optimization to achieve performance in the ballpark of C for things like audio, images, and looped numerical algorithms, all without C-language extensions, and at that point one will have duplicated what distinguished Common Lisp and other Lisp dialects of that generation from first-generation Lisp.
I see. Lets take a look at his sales records. Oh, last month he sold over a 5 million dollars of our product . . . I don't know about you, but if it comes to it, I can always get a new suit.
Anyway, I think the idea of using a PC as a one-of embedded system, or perhaps using the PC as a console to an embedded processor development kit, is not such a bad way to go, but when you combine Windows and then layer LabView on top of it, you start to have long latencies that are a problem for closing a loop, but then the College upgraded all the computers used for those kinds of labs to P-4's and that is supposed to be fast enough.
I also have issues with using LabView instead of a more "to the metal" approach from a learning perspective. But I was in the hall when the a group of students on a project team had an RC model dune buggy with some kind of circuit boards as a payload and a cable connection to a laptop running a LabView setup. It was apparent that the system wasn't working because the students looked earnestly-anxious and were furiously scrolling through screens of "G" code (LabView fanboys talk about "G" the way others talk about "C", and "G" is that graphics spaghetti bowl of trying to represent loops and function calls with boxes and lines).
I guess this project team was getting the full computer-controller learning experience of trying to debug a program interfaced to hardware, and do so under time pressure of their project demo appointment. The LabView thing is not only supposed to be visual, it is supposed to appeal to EE hardware types because the displays are like circuit schematics, which they like, instead of like Java/C/C++ code, which they could care less about. On the other hand, once code grows in complexity beyond the simple demos the National Instruments dude gives, programming is programming and debugging is debugging, and these guys were getting the full measure of it.
As to the real hardcore hardware types, they use stuff like Verilog or VHDL for systems that are too complex for schematics, and hey, these things look much like programming languages.
Sometimes upgrading breaks applications. I had to upgrade to XP to upgrade a software development package I use, but it broke an old version of Acrobat Distiller, my CD labeling software, and a not-that-old version of LaTeX (for some lame reason I can't get a less then or equal sign anymore). I guess I had to buy a new Acrobat Distiller, download a patch to the CD labeler, and I try to avoid less than or equal in my LaTeX documents until I can upgrade that -- nothing that can't be fixed with time any money, but the point is there is a whole lot of futzing around after an OS upgrade, just to find everything that is broken, and it takes so freakin' much of your time. The only compensation is that during software development and debugging, errors that would lock up the machine can be dealt with through Task Manager to shut down a rogue app.
While they say you are OK if you don't have fats, meat scraps, or bones, I wonder if coffee grounds, orange and banana peels, and other compost standbys create oders that welcome these creatures. Indoor composting may be the thing to help protect your house (or a dog).
My understanding is the the words snafu and foobar (orginally fubar) are acronyms, generated by soldiers during WW-II trying to assert their sanity and individuality within the impersonal bureacracy that is the military.
Snafu and fubar along with BUFF (the official military designation of the B-52 Stratofortress bomber aircraft) make use of a certain word. Since I am a civilian, I will use the civilian transliteration of the "f" as "fouled", although real military people don't use the civilian transliteration.
Snafu means "situation normal, all fouled up" and fubar means "fouled-up beyond all repair", while BUFF (a Vietnam-war neologism -- no one called it that in its Cold War role) means "big, ugly, fat, fellow" (OK, a variant on the f-usage.) From my aesthetics of things aviation, the B-52 is large, yes, but I think it is a rather sleek looking aircraft. The "ugly fat fellow" probably refered to the perspective of the enemy at the receiving end of the bomb pattern.
I had heard of fubar coming to computer usage when the run-time error message on some early FORTRAN systems for divide-by-zero was FUBAR -- the person writing the error message thought that was witty and probably didn't have any supervisor telling them to "clean that up" and "use something more explanatory and professional", and the geek FORTRAN programmers of that day were clean-shaven innocents with pocket pencil protectors who didn't know what fubar means.
The worst of this is Java example programs with
FooBar foobar = new FooBar();
My eyes glaze over when I see nonsense variables, especially in what is meant to be an illustrative example. The variable names can be short, but they should mean something, and is it possible to use Java examples where the class name and the object variable name are differentiated by more than change in case? Could we do
SampleClass sample_class_inst = new SampleClass()
Or was there really an A-Ark and a C-Ark, but they never got launched in time?
Things that are written in a "weaker" language, such as Visual Basic, tend to have the top level or the parts you are having your newbie app developer write in the "weaker" language, and they tend to have an "industrial-strength" language (such as C++) "under the hood." Visual Basic consumes ActiveX controls that are written by specialist developers in C++. Now in later versions of Visual Basic you could write ActiveX controls in VB, but am I correct in saying that using an ActiveX is considered "easy", but generating an ActiveX is considered pretty hard core, even with all of the VC++ "wizards" to generate the program skeletons?
You have this type of dichotomy in the "scripting" languages -- you write the app in Python but you write C/C++ extension modules to do the hardcore, time-critical, low-level stuff. The other extreme is Common Lisp, Smalltalk, and Java. While these are considered "easy" languages (not saying Lisp is "easy", but Paul Graham claims he can do much more stuff more quickly with it) -- you are encouraged to do everything in Lisp if you are using Lisp, everything in Java if you are using Java, and while Java has the JNI, its use is discouraged by the official Sun party line. I see Python working on growing from "just being a scripting language" to an attempt, with the right libraries, to make Python another Common Lisp, Smalltalk, or a Java.
I think that Borland went for the unified approach -- the Visual Form Designer allowed programming with drag and drop, it automatically wrote the Pascal, and you weren't really supposed to touch the Pascal very much. In fact, the generated Pascal was so parsimonious, I was afraid of it because I didn't know what was going on -- a lot of what was going on was that objects were initializing themselves and connecting themselves in the form/control hierarchy by reading in state information from the .DFM files (which you can view as ASCII text -- this forms the "second Delphi" language which is a kind of Pascal-syntax XML).
Then you had component development, which was supposed to be done by object inheritance and by writing some hard-core Pascal code -- there were (at least a first) no wizards to guide this, and extending a class by inheritance is a much tougher programming job and the code writer-driven composition of a top-level Delphi app.
Of course, the component developers were supposed to be the hard core programmers, and they could be fewer in number because they would publish their components for reuse for the vast army of Delphi Form Designer weenies. But if the Form Designer weenies were to use dBase Basic, there would have to be a Pascal/C++ other product (at least in the first iteration) to do component developement.
The argument for a single-language universe is its uniformity. The argument for multiple languages (VB.NET /C#.NET doesn't count as those are simply syntax "skins", but Managed C++ may count) is that different languages are suited for the different levels of an app.
2. Blazing-fast compiles -- there is nothing out there like it, not even the IBM Jikes Java compiler comes close.
3. Great string handling. They even extended their dynamically-allocated string idiom to arrays of primitive types.
4. Made Pascal more C-like -- the PChar C-like null-terminated string (they had to introduce it to be compatible with Windows, but now that they have "gone .NET", they are deprecating it). While it made Pascal less safe, the "I can write a 2-line C program that takes pages of Pascal" kind of went away. You can cast types, pointers, etc, to "remove the safety locks" if need be.
5. You don't have to use the VCL -- you can program to the Windows API if you are so inclined.
6. Good debugger, {$APPTYPE CONSOLE} compiler pragma allows opening a console Window in a Windows app for logging traces, etc.
7. While the support for COM and ActiveX not nearly as seemless as the VCL, a lot better than MFC/ATL.
What don't I like? I am old Pascal hand, but all that typing is getting a little tiresome after doing work in Java and C++. Also, an ActiveX control is this single .OCX file, and it works across Windows versions. To distribute .VCL controls, you have to have a freakin differnt version for each version of Delphi (Delphi version upgrades break more stuff than Windows upgrades).
The C++/Java interface goes both directions -- C++ calls Java or Java calls C++. The usual way is that you write a program in Java, and you use the JNI to call down to C++ to get at some low-level/system-level function -- SWT does their native widgets this way.
I have in mind writing the application in C++ using the Windows API (the application is already written that way) and using Java for plug-ins, extensions, numerical processing modules and saving GUI migration for last. One, this is a way of incrementally migrating to Java. Two, it is doing the non-GUI code first, and identifies as much of the app as non-GUI and portable that can be split off. Three, the Java class and JAR files seem like a better kind of DLL -- think of them as platform-portable DLL's that are much less bulky than C++-generated DLL's under Windows.
As to being able to do this in C#/C++, if you write the main app in C#, calling C++ DLL's, COM objects, or ActiveX controls is a piece of cake. Calling C# from C++ is clunky. The C# object has to publish itself as a COM object/ActiveX control and you have to go through some song and dance to register it to make it available that way. Bet it is no big deal having done it once, but every time I get the feeling to do this, I read the long instruction list and decide to lie down until the feeling passes.
As to comments by others that unmanaged C++ calling C# is, I don't know, evil or something, if that is evil than every unmanaged Windows app that doesn't use .NET is equally evil. But if you accept a place for unmanaged Windows apps, there is no difference between calling an unmanaged DLL and calling a managed DLL -- there is no added security lapse for doing this.
By the way, what got me started on this is that you can pretty easily call Java from Matlab -- I think Matlab is a pretty good scripting environment for Matlab because you can create instances of any Java class and invoke any of their methods without needing a static main() method as a Java program entry point. Well what Matlab can do, any C++ program can do the same through JNI.
Windows has always been a dog in the latency department, and the *nix's never had a great reputation there either. The argument "this is a desktop operating system and they are trying to maximize throughput on the kind of tasks users do rather than realtime", but the time slices given especially to disk reads seem kind of high. The only thing that has made Windows a contender in any kind of multi-media/video game/flicker-free video is Moores law -- computers run so fast that the unswitchable tasks complete that much faster.
What is the take on OS-X? What are the latencies? Are there any in the tens of milliseconds or more like Windows? I know none of these systems are hard realtime, but if you have typical latencies in the small numbers of ms, there is less interference with screen updates at video rates.
What is it like for the application developer? What kind of screen refresh rates are possible? Can you synch screen writes with vertical retrace? Is there acceleration for 2-D scrolling?
Sun has this whole take-it-or-leave it notion about Java, but I have been interested in migrating to Java by rewriting parts of my apps. The JNI allows Java to call C++, but it also allows C++ to call Java, and while parts of it are a little cumbersome, it is well-documented and you can wrap the plumbing in a set of C++ and Java classes. My notion is that I can start with the non-GUI parts of the program, and perhaps even some of the GUI parts by using the MVC and strategy design patterns to uncouple code from the Windows API code, and over time develop something that is easier to migrate away from Windows. Oh, don't worry Chairman Bill, I am probably not leaving Windows anytime soon, it is just that Java has good features and libraries and I am interested in using it.
For mixed Windows API-managed code programming, I like C++/Java better than C++/C# because to access C# modules from Windows API C++, you have to go through a lot of Windows jive with the GAC and other bits of Klingon language. Connecting C++ and Java through the JNI seems easier to me than connecting unmanaged C++ to C#.
The hassle is that I am really reluctant to make any program I distribute dependent on a Java install on a Windows computer because there is so much to go wrong -- not setting up the PATH, CLASSPATH considerations, and so on. It is not insurmountable to get Java going under Windows, but it is something for users of one's software to not get right.
If MS and Sun were to truly make nice, I would like to see the Java runtime integrated with Windows so you could count on it being there if you distribute apps under Windows. Heck, I would settle for the .NET runtime being part of Windows, but even that you have to download and there is a futz factor setting it up.
When I heard about the DC-X approach to reusable spacecraft reentry and landing, my reaction was "that is so Buck Rogers" meaning that I didn't think that landing on rocket thrust made sense.
But the Soyuz lands tail first on rocket thrust (it has braking rockets for the final ground contact to supplement the parachute), and that has advantages over wings and wheels.
So saying Buck Rogers should mean a solution without wings and wheels.
The Newton was a Palm Pilot before there was a Palm Pilot, and it was supposed to have handwriting recognition, but it didn't live up to expectations. The breakthrough of the Palm was that you had to relearn your handwriting in this gestures thing the computer could understand.
When Anders Hejlsberg crossed over to the Dark Side, .NET didn't use that approach -- they use the code-generation approach instead of the object-property serialization approach.
Don't know if there is a way to hack the .dfm files to change and app with source -- I believe the .dfm's stick around during compile and their info is folded into the .exe file so you don't distribute the .dfm's with the binary app.
For an example of a major shrink wrap app, consider Matlab. Don't think all of it is written in Java, but major parts of it are.
Well, score one for the incremental approach!
On of the classic big software projects gone bad was the failure of the revamp of the air traffic control system, which was stiched together with creaking mainframes and had old CRT terminals. The rewrite/redo/new system was a classic "Bridge too Far" (Operation Market Garden from WW-II a classic "massive rewrite" instead of an incremental approach. They were going to use paratroopers to capture a whole lot of bridges in Holland, and then the main body of the army was going to come motoring through all of those bridges and straight into Germany to end the war. The main army got bogged down at the first bridge and the British 2nd Airborne Division got hung out to dry at the last bridge, and a British general offered up British understatement as to why the whole plan failed as "it was simply a bridge too far."
In the case of the ATC rewrite, they concentrated on the ATC controller workstation -- the thing with the big CRT where all the flights show up on radar but with alphanumeric info added -- but it was going to be the ATC workstation to end all workstations, and it got caught up in a mire of specs.
I surmise that it was supposed to be a massive bitmap graphic CRT back in the day when megapixel bitmap graphics was bleeding edge, and it was supposed to customized, both for the preferences of the controller as well as the geography it was to cover using some kind of configurable software, back in the day when people hadn't heard of OO and GUI frameworks.
I always thought they should have done something incremental, but I guess I never understood their problem domain well enough to know what incremental would be.
But what ever happened to ATC? Are they still using battleship CRT monitors driven by creaking mainframes? Did they come up with something that works using newer technology?
My experience with a family member and more recently with a friend suggests that alcohol consumption and related health and cognitive problems may be a be more of a problem than people let on. Is consumption of 10 ounces of vodka a day problematic? I observed this level of consumption in an 80 year old not long before that person had to enter an assisted-living home for memory problems. Is this kind of alcohol consumption a cause of dementia or a symptom of it?
And I don't think the AA 12-step program traditional approach to alcoholism really addresses the problem because that school of thought addresses people who "hit rock bottom" and need a fresh start on life. I am talking about old people who are thoroughly habituated to high levels of alcohol and you wouldn't know a person drank that much unless you went through their bottle recycling and counted the bottles that went in each week.
I guess the reason I am seconding your point of view and getting all excited about "alcohol wards off dementia" is that alcohol is hard to restrict to that one drink per day, especially in elderly people who feel they have diminished levels of responsibility in retirement and feel they can handle their drinking.
The .dfm file is binary, but it has a textual representation which is in Pascal syntax -- I guess they have a Pascal parser (while not Lisp, I hear that Pascal is pretty easy to parse) that they use to that purpose.
If I were in charge, I would be a little less coy about the .dfm file and its textual representation. I may also consider a standardized Pascal syntax for describing graphs and data -- there is this thing called VHDL that has an IEEE standard and is used for hardware design, but it seems perfectly suited for a Pascal-syntax answer to XML. And for you C-syntax proponents, there is this thing called Verilog.
If Clarke is free to change his story around between Saturn and Jupiter to suit his fancy, I think we can let our jokes float around the same.
They are all going to go out and buy Macs because 1) they have decided that Macs are cool, 2) that Macs are BSD under the hood means it runs all of their stuff, and they prefer BSD to Linux given the choice, 3) they have funds to pay for it and always wanted a Mac anyway.
Nick Lane's book Oxygen argues that the Earth's oxygen is not a tightly-regulated homeostatic system -- the old saw about the Amazon being the lungs of the Earth. The oxygen in the atmosphere is the result of the small excess of carbon fixed by plants that doesn't get consumed or decayed by animals and bacteria, with volcanoes supplying the makeup CO2 to drive the process. Just as the fossil fuels are the relic of this process, O2 is the fossil gas relic of the process. The only reason we are not burning up all the oxygen by burning coal is that most fossil fuel is very low grade shales and sandstones while coal, gas, and oil are only a small quantity of concentrated carbon.
The claim is that contrary to the Gaia Hypothesis which would argue for tighter homeostatic control of O2 and other gasses, O2 reached 35 percent during the Age of Coal (Carboniforous) while some tens of millions of years later in the Permian, O2 crashed to 15 percent. Scientists are supposed to know this from isotope ratios in rocks from those strata.
So the Earth is a poor model for a closed ecological system in that the processes controlling O2 operate over geologic time and are perhaps less tightly regulated than once thought.
The deal is that SWT does not have the official stamp of approval from SUN, so you have to load a separate "SWT driver" (some .dll's or .so's) for your specific system, or if you distribute software, you have to bundle all those different drivers or tell people they have to download the one for their system themselves. Swing has the SUN seal of approval, so it is bundled with the Java runtime, and if you were able to download the Java runtime on your system, you got Swing. There is a different Swing "driver" for each different system, but you had to download a different Java runtime depending on whether you are running Windows, Linux, OS-X, etc, so you got the correct version of Swing when you did that.