...cause Linux ain't personal yet. Microsoft already has a monopoly on the desktop; it's not like Linux will be losing marketshare.
With that in mind, it's probably better that Joe Sixpack doesn't get exposed to Linux at this point. Right now, it is likely that he will be turned off to it and hate it. When replaced with WinXP, Linux on the desktop, from a newbie point of view, will look horrible from a usability point of view.
Better to wait until it actually is easy to use without looking at half a dozen HOWTOs before unleashing on the masses.
For example: how does one install a new program on RedHat? Assuming it's an RPM, the user opens a command prompt and *bzzzt!* Linux just lost. On Debian, assuming you have a deb file, the user opens a command prompt and *bzzzt!* Linux just lost again. Are there GUIs for this? Sure. Are they sufficiently easy to use for a newbie (Are they easily accessible from the system menu or an icon)? Not yet.
Sure there's apt and Red Carpet, but those are for specific channels -- mainly Ximian and RedHat. The vast majority of Windows users use programs that are not in the standard Windows install. As such, installing programs on Linux that are not part of a standard distribution seems logical to me and necessary.
Browse to software site and download (or insert CD), double-click on file, and have it installed and ready to run without ever opening a command prompt or needed to read a manual or a HOWTO. You want Joe Sixpack who doesn't "get" computers and has no desire to "get" computers? This is the entrance fee.
After all, how many of you drive a car, but don't know how an engine works (or even what kind of airbag it has)? Knowing how it works should not be a prerequisite to using it.
First you have to choose the "standard." Right now everyone is bickering about their pet implemention (myself included). Unfortuantely, different programs have different needs. And rather than simply accept the obvious choice of the format that handles all configuration types (flat, hierarchical, etc. -- smells like XML to me, can you tell I am biased?) people still cling to their "my program only needs three config parameters so I'm going with my own custom, unique, weird-delimiter format" ideals.
And now you've combined data and logic which should be kept separate whenever possible.
Your solution is akin to writing a config file that consists of Perl hashs and arrays for inclusion via "require." You're locking into a single language and a wrong keystroke will crash your program (as opposed to simply having the config file parser report an error so that you can gracefully exit and, most important, tell the user what they did wrong.
And don't forget feature creep. If you were to add a parameter to your config file, will it break your scripts? Very likely if they have delimited values such as found in/etc/passwd. And I challenge anyone who has worked in Linux for more than two years to tell me with a straight face that config file structures never change. Or, even worse, you don't add what you need to the config file because it will break all of the scripts and utilities out there.
Parsing XML means that you can write out all parameters verbatim that you don't care about, but add new items easily as my parent post mentioned.
The thing this article screamed was not "XML" but "API". Define the application programming interface for a library, and stop thinking that each application must directly access the native data
Yes, and the discussion went to the next step and started talking about possible APIs. The parsing of XML (DOM and SAX -- DOM for in-memory data structure and SAX for streaming access) are well understood and, most important, already done with innumerable tools already written.
XML Schema could not, for example, include primitive types for IP addresses (very common in config files), or validation constraints for integer values.
Wrong! Wrong! Wrong! You haven't read the spec and are obviously making assumptions based on what you've heard from others who haven't read the spec either. XML Schema allows not only the specification of integer, string, float, date, etc. values, but integer subsets (greater than and less than) and string patterns (through regular expressions). And RELAX-NG can use XML Schema's datatype support as well.
Do you have something that does validate IP addresses for example or were you just complaining about how one thing doesn't (even though it does) without showing anything that will solve the problem. If you say regular expressions, I must remind you that XML Schema supports regex matching of attributes and element data.
To date there are no (zero, zip, nada, nothing) fully compliant XML parsers.
Could you please enumerate these non-compliance issues? An encoding issue? Bugs in DOM or SAX support? What? I wonder about the vitrol of your argument without any specifics. Especially since I been using both parser that you mention (and a few others) without any noticeable issues associated with the standard. Any problem were usual to do with parser extensions to the standard which are fairly simple to avoid.
A vast number of parsers out there ignore the DTD, which means they cannot handle entities (which is a big issue).
You're right! That is a big issue. Unfortunately for your argument, it is not an issue with the leading parsers that you mentioned yourself: Xerces and MSXML. The default parser for Java (Crimson through JAXP), the default parser for Windows (MSXML), the default parser for Perl (XML::Parser I think...haven't used it yet) to name a few ALL handle entities. This is like saying that there are many web servers out there that don't support CGIs with the obvious intent of dissuading use of web servers.
A simple.ini-style line delimited key=value is the most readable and understandable (from a psychological viewpoint) configuration format.
I agree, but you're missing an important aspect here. INI files are usually one and at most two levels deep. They do not handle hierchical structures well at all! Let's look at a snippet from a default Apache configuration file.
# The following lines prevent.htaccess files from being viewed by
# Web clients. Since.htaccess files often contain authorization
# information, access is disallowed for security reasons. Comment
# these lines out if you want Web visitors to see the contents of
#.htaccess files. If you change the AccessFileName directive above,
# be sure to make the corresponding changes here.
#
# Also, folks tend to use names such as.htpasswd for password
# files, so this will protect those as well.
#
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
What do we see? Hmmm... Because the key/value pair format doesn't allow hierarchy, they fell back to something that looks a bit...er...XML-like. And it isn't key=value, it's key[whitespace]value. Yet another issue: one file has the equal sign and others don't. I thought we were aiming for consistency? And what if the parameter is a message and that message has a newline character? A '\' at the end of each line? A '\n' where appropriate? These are problems that XML has solved.
And let's not forget Unicode support. We English speakers may have a hard-on for English, but can't you imagine a case where a program intended for a non-English speaking audience would want -- if not the names of the parameters themselves -- parameter values in alternate character sets than ISO-8859-1 (Latin1)? And before you rebut with UTF-8, do you want to write the UTF-8 translator? What about the other codesets? Are you strictly limiting to UTF-8? This is another area of XML parser that keep it simpler for the programmer. Transcoding is done for you and is most likely better implemented and supported than what you or I would come up with.
And when you have multiple "Files" definitions? Well, multiple blocks right? The "Order," "Deny," and "Satisfy" parameters are associated with the "Files" definition, yes? So why aren't you associating a group of "Files" definitions together? Because that would require further hierarchy? Would you end up with something like this?
<FilesDefinitions>
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
...other Files definitions...
<FilesDefinitions>
Set up a relatively complex configuration where you have virtual hosts and those virtual hosts have behavior different from the default. What's that? You include them in tags by host? Tags that look somewhat like XML anyway you say? Imagine that!
And what about the comments? For some formats, the comment is the ';' character. For others it is the '#'. And none of which I am aware differentiate between implementation comments and actual directive comments. For example. the comment above describes the configuration directive so that any configuration editor could conceivably read in that info and display as help to the user (assuming that all comments were kept correctly before the directive and not after or on the same line). But what if you wanted to make comments about your specific installation. You are making comments so that others in your working group can see why you made certain changes to the config file, right? So how are they differentiated from the primary directive comments. This is the type of problem that XML namespaces are intended to solve -- a way of giving demarcation points to distinct pieces of (sometimes) unrelated data or simply the clean combination of multiple schemas so that your schema definition doe not bloat to immeasurable levels and different schemas can easily share with one another.
Something keeping back Linux/BSD/UNIX is the stubborn, 1337 coders who spent all day figuring out a config file that some joker on the net thought would be a keen config format but forgot to comment it. Let's face it, Apache is not the norm. Config parsers are a known problem with known solutions. Writing a config file parser is not the primary focus for most programmers out there. The config file is a necessary evil to them. Let's make it easier and just say, here's your DOM interface. It's well documented, works well for the limited dataset with which you a working (config files are usually less than 50K), will handle any configuration organizational type you want (hierarchical, flat, etc.) and will save you the time of writing a parser yourself.
While I have my issues with XML Schema, it was never intended to replace or compete with something like ANTLR or BNF. The latter were meant to describe an entire language down to the nitty gritty. XML Schema is only intended to describe the format of a document within the confines of well-formed XML syntax.
Might I suggest taking a look at RELAX NG.
It has the much simpler syntax for which you may be looking. But it is still a well-formed XML document and can therefore be parsed with the same tools as the instance documents.
Don't forget that a primary reason XML Schema came to be was that it is a pain in the ass to make both an XML parser and a DTD parser (let alone the validation logic). I've done it. While not as hard as many other things out there, it's made a lot easier with having unified parsing code. And it allows for one schema syntax to be converted to another with an XSL-T stylesheet. Or for conversion to a group of schemas (think one stylesheet for generating the database schema and others to make your programming header files). Need to make some changes? A stylesheet is easier to update than classic source code especially when that source code requires a compiler which may not be handy on the box in question.
And let's not forget documentation! Another stylesheet to convert to XHTML (or whatever).
I assume by your affection for XSL-T that you are a web designer -- transforming XML data to XHTML, WML, etc. for presentation.
If you haven't already, I would suggest checking out SVG and XSL:FO. As an XML-saavy web developer, I assume you are familiar with client-side DOM programming in a modern web browser.
Well imagine being able to manipulate graphics in much the same way (think Flash-style graphics without the plugin). Creating pages that are aesthetically pleasing without having all of those GIFs and PNGs flitting about. Imagine being able to embed contextual information in this graphical data so that the visually impaired (or lynx/links users) can still use your site -- "alt" attribute on steroids.
With regard to XSL:FO, imagine being able to write a stylesheet that represented exactly the appearance of the document. Whereas XHTML is intended for a wide variety of clients where height, width, and color depth are all variable, XSL:FO is perfect for generating PDF (think online software documentation as an atomic unit of data instead of a bunch of distinct pages in a tarball/zipfile). It's perfect for generating PostScript for consistent layout going to a printer. Or RTF, MS Word, or TEX/LaTEX for those who like to use a word processor (or emacs;-)) to view their content.
...just some food for thought. I agree, the "chameleon-like qualities" are nice too.:)
Ummm... eXtensible Markup Language. The meta language (the description of a language) would be DTD, XML Schema, or RELAX/RELAX-ng.
After all, you can't just throw any old bunch of tags together and expect something useful to come of it. Only a particular set of tags defined either explicitly or implicitly by a schema can work for a task at hand.
This is a analogous to C being a programming language with BNF being a common meta language for it. Or more appropriately, CORBA's IDL is closer to the concept of a schema than an XML document. XML by itself is analogous to the marshalled data that CORBA uses for it's serialization between ORBs.
Although a particular instance document or class of documents (according to a schema) can be used as a meta language (Mozilla's XBL comes to mind although that blurs the line somewhat), it is primarily a data/content markup language.
You forgot to mention that with strcat, you are responsible for buffer allocation/deallocation.
For C++ you can write
--------
std::string a="hello", b=", ", c="world", d=".";
std::string e;
e.reserve( a.size() + b.size() + c.size() + d.size() );
// or e.reserve( SOME_APPROPRIATE_CONSTANT_VALUE );
e = a;
e += b;
e += c;
e += d;
std::cout e std::endl;
--------
Modern C++ implementations wouldn't create a temporary in this case because the target buffer has already been made large enough for the source data. The only reason you don't have to worry about it (and strcat seems faster in your mind) is that you have already made the multiple calls to strlen to make sure that the target buffer is large enough or you have chosen what you consider a large enough target buffer (which is subject to buffer overrun errors in some circumstances).
And it's still easier to use than strcat. AND this probably isn't your program's hotspot anyway. Premature optimization and all that.
Jython is out for Python, the Rhino library is available for JavaScript, Apache Cocoon is recently implementing a Java-based Scheme interpreter.
I've heard of a Perl port from a while ago, but can't think of who did it. I think it was a research assignment and didn't go very far.
I know there is a REXX implementation out there too.
Moving on, if you want to count the "native" compilers, gcj from the GNU Compiler Collection has close integration with C++ to the point that they seem to mesh well. It's called CNI.
The long term plans for Java include items such as tail-recursion and templates but they came up too late in the dev cycle to include in 1.4 without pushing the release date out too far. 1.5 is slated to have an updated bytecode format (although presumably backwards compatible in much the same way that 1.02-era applets still run for the most part in JDK 1.3)
Don't presume that Java isn't a moving target for.NET
It's not like Sun and IBM are planning on standing still and waiting for Microsoft to catch up.
Has Sun sued Apple over Cocoa written in Java? Has Sun sued any of the large number of companies that have implemented a native compiler for Java?
The lawsuit was specifically over JNI and RMI. Sun had no problems with strict supersets of the Java language (COM integration for example). However the native interface was replaced with RNI(?) and RMI was simply ommitted.
This means that if people coded to the spec for native integration with portable C, it wouldn't work from one target to the next. And in the case of RMI, MS simply didn't want a competitor to DCOM within DevStudio. RMI is a big deal. On a "pure" Java platform, RMI was how distributed computing was done. You take that away and suddenly you're right back with C and C++ and their myriad of options for distributed programming but lack of any consistent single API that you can use anywhere.
You'll note that MS whined that RMI was just too time consuming to be bothered with. Then after the judgement, an RMI implementation was produced in less than a month!
THIS is the reason Sun has not submitted Java to a standards body. If Java is messed with, Sun would have no legal recourse while suffering significant liabilities in keeping Java's APIs consistent. Add that to the fact that no standards body has sufficient clout to do more than look at Microsoft (or anyone else) sternly.
Do I trust Sun completely. Of course not. It is a large, public company with all of the benefits and drawbacks of a large, public company. But I trust them *enough* (with their current track record) to keep Java relatively clean and consistent -- especially in light of folks like IBM making compatible and very fast JVM implementations.
Sun isn't as closed off as people would suggest. The Java API for XML Parsing was heavily influenced from outside contributors -- especially the 1.1 version with TRAX.
Where are the cross-platform, standard C and C++ libraries for networking, threading, graphics, distributed programming, database access, XML parsing, object serialization, directory (LDAP, X.500, etc.) lookup, authorization, authentication, i18n and l10n? I'll tell you where: in the standards bodies who cannot enforce what people use nor can they do anything about people who ignore the spec.
Where would Java be if it were submitted to ISO five years ago? Right where C++ is today with Microsoft providing the only viable development platform. Woohoo.
I liked the comparison of technologies, but it misses a main point. Or rather, I believe its primary audience misses a main point.
.NET is not perfect. The JVM is not perfect. But I strongly believe that they are a step in the right direction. For example, the current choice(?) on UNIX systems is to have C-compatible exports for libraries.
While.NET and the JVM may be limited, let's not loose track of the fact that extern "C" {} and its ilk are far more limited. Instead of limiting languages to objects without templates and continuations, the current scheme of exporting function symbols and structs is downright embarrasing.
What would be really nice is using.NET as a library/component interface and leave each language relatively intact. For example, implement your library/component in the language of choice, but export the functionality (what is currently "handled" by library symbols) in a language-neutral but far more feature-rich manner.
Doesn't "Managed C++" allow for advanced C++ features that simply are not exported for use outside the codeblock? C# has "unsafe" blocks for its own bit-twiddling.
We're on the right track here. Let's not throw the baby out with the bathwater!
C++ just doesn't cut it, and it's tough trying to write this kind of code in C (but not impossible, it just takes a little discipline).
What exactly can C do that C++ can't? C++'s std:string ends up comparable to C and char* in speed. C++'s standard quicksort algorithm is faster than C's (not as fast -- faster).
Instead of taking "a little discipline" with C, why not spend some effort with a more advanced language?
Kind of like "Flipper," but best used only for websites because, like dolphins, they can go down out of sight from time to time without warning.
Canthandlehighvolumeupdateswithoutcorruption
Kind of rolls off the tongue doesn't it?
And yes, I have used MySQL and yes, I have seen what happens to a MySQL database from time to time even with proper maintenance and yes, transactions are not optional.
Best wishes to them on naming their dolphin though.
* ACID stands for Atomicity, Consistency, Isolation, and Durability
See this link for more info.
I really does, and not just online. I worked for a company that did websites for radio stations. We were reading results from a poll as part of an on-air contest where people could call in or use the web to vote for their favorite band. After a snafu with the data, we contacted the station to apologize for losing about a quarter of the results of the first few hours of the contest. We were expecting to be (quite rightly) reamed for it even though the contest had the rest of the week to run its course.
As it turned out, they didn't mind at all. They had already decided who the top two choices would be and only cared which of the two came out on top. In short, Limp Bizkit was popular, but not THAT popular.
I won't name names, but perhaps folks who listen to popular radio in the Chicago area (and other major venues) should keep this in mind the next time your radio station claims to give you what *YOU* want.
I feel like clearing the air of half-baked comments and know-nothing OO detractors.
First of all, for those individuals who refer to C++ as an OO language, please stop. You're wrong. C++ can be used for an OO project, but it is a multi-paradigm language. At least that's what Bjarne Stroustrup calls it. But what does he know about C++?
Second, use of C++'s STL does not equate to OO programming. It is an example of generic programming. Here's a hint: the STL has very little inheritance except for iterators and iostreams -- most evaluation is handled at compile-time. And even iterators and iostreams are just as much generic as OO.
Finally, please dispel the rumor that C is automatically faster than C++ because of C++'s excessive overhead. Need proof? Please read this article about treating C++ as its own language and not a variation of C. Yes, it's a PDF. Get over it.
Think the article is FUD? Prove it! Take the examples from the article and tune them better than he did. Compile them with trusty ol' gcc and g++ on your box. Measure the results. After you do so, can show that C is faster, does not contain any potential buffer-overflow bugs, handles error conditions, and wasn't at least five times more code to do it, then reply back with your results. I have a feeling I won't be getting any replies from people who actually try it.
That said, use whatever language you like best. Studies have shown that people will always perform better in languages they know intimately well than languages in which they have a general familiarity.
I generally take comments as a sign that the code they comment needs simplification, and then refactor it until the comments are redundant.
Heh... so much work and vitrol to avoid a few measly comments. As was stated by my first post, having a few extra comments would rather likely not hurt anyone. Skipping a few extra comments (more often the case) can definitely hurt.
Look at IE versions 1.x and 2.x. They were pretty much a Microsoft-branded Mosaic.
And what did Microsoft do? They rewrote it.
A well-designed project can easily have many modules re-written over and over again and suffer no problems as long as interfaces are adhered to. You're talking about throwing the baby out with the bath water.
Let me restate my intentions. I acknowledge that I wasn't very clear on this. My criticism was of the recurring issue of macro viruses and worms through certain email programs and web servers. I didn't mean to suggest that they dump the whole kit and kaboodle.
I believe that COM and COM+ were good ideas. Sure they could be made better, and at each version, they are better. The ActiveScripting engine, when not exposing massive security holes, is a fine piece of interface and language interaction design.
But no, they haven't been fixed already. Those specific exploits are stopped, but many of the underlying reasons why the holes are present are still there. Microsoft tends to treat the wounds and ignores the cause of the disease.
But who am I to argue? I am neither a software tycoon nor a user of Microsoft software. I just have to work with people who are software tycoons and/or use Microsoft software.
At least all of the people in the anti-virus software industry are kept busy and paid...
I wish I had remembered to switch that out (I had actually thought of it when I started the post). It goes to the point that comments should make the implicit intent of a particular piece of code, explicit.
I have to admit, my rant wasn't intended to target you specifically. It was more of a general rant. Maybe I'm just cranky because k5 is still down.
And I agree that comments aren't a substitute for documentation. Use cases and UML don't lend themselves to source code comments. However, my comments about "Cliff's Notes" still stands. Comments judiciously sprinkled within code helps casual scanning for meaning much faster and easier no matter your coding skill. Coding skill simply speeds the case where comments are not present.
In answer to your question, while certain logical constructs are best expressed in code, overall concepts are usually just as easy if not easier to express in a natural language.
Unless you are writing programs and libraries that are only going to be used from end to end by other programmers, the outside world is dictating needs, requirements, and problems. That outside world speaks a natural language. If you cannot map the problem set and the solution set to a natural language, I submit that you do not have an adequate knowledge of the problem.
However in this case, comments would be a side effect.
Programming languages describe and work with the nuts and bolts. No programming language that I am aware of is sufficiently abstract to directly map to complex real world problems; no creative use of partial template specialization in C++, dynamic classloading in Java, dynamic function definition in Scheme, etc. can do this.
Conversely, no natural language that I am aware of can adequately describe a truly logical, deterministic domain either (just check out legal documents for proof). There needs to be more translation between the two.
For now, those bridges are comments and documentation.
-----
For a less abstract argument, let's leave computers out of it for a second. Two people from Indianapolis can communicate with each other better than either can communicate with someone from Sydney. They all speak English, but the dialects, the idioms, and the inside jokes may not translate. So when we write for general distribution, we try to keep those local colloquialisms to a minimum (and no, I admit that I haven't been a perfect example of this in my posts:-/).
Now keeping this analogy in mind, a programmer has an intimate relationship with a computer/compiler/system libraries/whatever. Together they have many inside jokes, goofy idioms, and function prototypes that mean absolutely nothing to someone else who, not being necessarily stupid, simply has a different focus or area of expertise.
While it may be more effort, and it may reduce some of the free-wheeling fun you would have had if you were alone with your CRT, doesn't it seem appropriate to make it more comprehensible if for no other reason that to allow others that specifically don't know as much as you to learn from a good example? Wouldn't that help to encourage others to continue using your code instead of scrapping it just as the interview topic suggests? Wouldn't it help to keep a few less wheels from being reinvented?
Maybe I'm too idealistic. Maybe I'm just not jaded enough. But for me, part of being a lead software developer or a senior software engineer or a project lead is not simply to crank out a mountain of code while others look on and a select few help out. We don't code forever. Some of us get sick of it before too long. Some go into management. Doesn't it make sense to try and *teach* the ones coming up to do what we do? For me, it does. But, again, I am lazy sometimes. A few extra comments means that more than half of the time, I don't need to be asked what something I wrote was intending to do regardless of whether or not they are as good a coder as I am. They just read the comments.
The Java "fixation" started in one of the betas for Netscape 2.0. You criticize Java for its immaturity when Netscape itself was just as immature and IE was still called Spry Mosaic.
Netscape4 was/is crap. Netscape 3 was faster, but simply avoids the "crap" label due to its immaturity. IE "ate Netscape's lunch" because it was component-based and people could embed it into their own applications easily, reducing their development time. Netscape4 would never be able to do this. Neither would have the Netscape3 codebase. Componentization/modularization must be done relatively ground-up to be used effectively.
A new codebase was the only real answer at that point. The only better answer (20/20 hindsight and all that) would have been if they made it more modular to start with instead of stopping at the "plugin" model. Netscape focused on pluging other things into the browser. IE focused on letting the browser get plugged in to other things.
At least with the rewrite, those who want something better like recent builds of Mozilla have that option. I'm not convinced that would have happened if the codebase had continued unmolested and bristling with thorns.
It's taken a few years, but more than a browser is bearing fruit from the Mozilla vine, and I for one am glad they did the rewrite.
Slashdot Mirror
...cause Linux ain't personal yet. Microsoft already has a monopoly on the desktop; it's not like Linux will be losing marketshare.
With that in mind, it's probably better that Joe Sixpack doesn't get exposed to Linux at this point. Right now, it is likely that he will be turned off to it and hate it. When replaced with WinXP, Linux on the desktop, from a newbie point of view, will look horrible from a usability point of view.
Better to wait until it actually is easy to use without looking at half a dozen HOWTOs before unleashing on the masses.
For example: how does one install a new program on RedHat? Assuming it's an RPM, the user opens a command prompt and *bzzzt!* Linux just lost. On Debian, assuming you have a deb file, the user opens a command prompt and *bzzzt!* Linux just lost again. Are there GUIs for this? Sure. Are they sufficiently easy to use for a newbie (Are they easily accessible from the system menu or an icon)? Not yet.
Sure there's apt and Red Carpet, but those are for specific channels -- mainly Ximian and RedHat. The vast majority of Windows users use programs that are not in the standard Windows install. As such, installing programs on Linux that are not part of a standard distribution seems logical to me and necessary.
Browse to software site and download (or insert CD), double-click on file, and have it installed and ready to run without ever opening a command prompt or needed to read a manual or a HOWTO. You want Joe Sixpack who doesn't "get" computers and has no desire to "get" computers? This is the entrance fee.
After all, how many of you drive a car, but don't know how an engine works (or even what kind of airbag it has)? Knowing how it works should not be a prerequisite to using it.
First you have to choose the "standard." Right now everyone is bickering about their pet implemention (myself included). Unfortuantely, different programs have different needs. And rather than simply accept the obvious choice of the format that handles all configuration types (flat, hierarchical, etc. -- smells like XML to me, can you tell I am biased?) people still cling to their "my program only needs three config parameters so I'm going with my own custom, unique, weird-delimiter format" ideals.
Sendmail rulesets are your example of something that is already human-readable?
Bad example dude.
And now you've combined data and logic which should be kept separate whenever possible.
Your solution is akin to writing a config file that consists of Perl hashs and arrays for inclusion via "require." You're locking into a single language and a wrong keystroke will crash your program (as opposed to simply having the config file parser report an error so that you can gracefully exit and, most important, tell the user what they did wrong.
And don't forget feature creep. If you were to add a parameter to your config file, will it break your scripts? Very likely if they have delimited values such as found in /etc/passwd. And I challenge anyone who has worked in Linux for more than two years to tell me with a straight face that config file structures never change. Or, even worse, you don't add what you need to the config file because it will break all of the scripts and utilities out there.
Parsing XML means that you can write out all parameters verbatim that you don't care about, but add new items easily as my parent post mentioned.
Yes, and the discussion went to the next step and started talking about possible APIs. The parsing of XML (DOM and SAX -- DOM for in-memory data structure and SAX for streaming access) are well understood and, most important, already done with innumerable tools already written.
Wrong! Wrong! Wrong! You haven't read the spec and are obviously making assumptions based on what you've heard from others who haven't read the spec either. XML Schema allows not only the specification of integer, string, float, date, etc. values, but integer subsets (greater than and less than) and string patterns (through regular expressions). And RELAX-NG can use XML Schema's datatype support as well.
Do you have something that does validate IP addresses for example or were you just complaining about how one thing doesn't (even though it does) without showing anything that will solve the problem. If you say regular expressions, I must remind you that XML Schema supports regex matching of attributes and element data.
Could you please enumerate these non-compliance issues? An encoding issue? Bugs in DOM or SAX support? What? I wonder about the vitrol of your argument without any specifics. Especially since I been using both parser that you mention (and a few others) without any noticeable issues associated with the standard. Any problem were usual to do with parser extensions to the standard which are fairly simple to avoid.
You're right! That is a big issue. Unfortunately for your argument, it is not an issue with the leading parsers that you mentioned yourself: Xerces and MSXML. The default parser for Java (Crimson through JAXP), the default parser for Windows (MSXML), the default parser for Perl (XML::Parser I think...haven't used it yet) to name a few ALL handle entities. This is like saying that there are many web servers out there that don't support CGIs with the obvious intent of dissuading use of web servers.
I agree, but you're missing an important aspect here. INI files are usually one and at most two levels deep. They do not handle hierchical structures well at all! Let's look at a snippet from a default Apache configuration file.
What do we see? Hmmm... Because the key/value pair format doesn't allow hierarchy, they fell back to something that looks a bit...er...XML-like. And it isn't key=value, it's key[whitespace]value. Yet another issue: one file has the equal sign and others don't. I thought we were aiming for consistency? And what if the parameter is a message and that message has a newline character? A '\' at the end of each line? A '\n' where appropriate? These are problems that XML has solved.
And let's not forget Unicode support. We English speakers may have a hard-on for English, but can't you imagine a case where a program intended for a non-English speaking audience would want -- if not the names of the parameters themselves -- parameter values in alternate character sets than ISO-8859-1 (Latin1)? And before you rebut with UTF-8, do you want to write the UTF-8 translator? What about the other codesets? Are you strictly limiting to UTF-8? This is another area of XML parser that keep it simpler for the programmer. Transcoding is done for you and is most likely better implemented and supported than what you or I would come up with.
And when you have multiple "Files" definitions? Well, multiple blocks right? The "Order," "Deny," and "Satisfy" parameters are associated with the "Files" definition, yes? So why aren't you associating a group of "Files" definitions together? Because that would require further hierarchy? Would you end up with something like this?
Set up a relatively complex configuration where you have virtual hosts and those virtual hosts have behavior different from the default. What's that? You include them in tags by host? Tags that look somewhat like XML anyway you say? Imagine that!
And what about the comments? For some formats, the comment is the ';' character. For others it is the '#'. And none of which I am aware differentiate between implementation comments and actual directive comments. For example. the comment above describes the configuration directive so that any configuration editor could conceivably read in that info and display as help to the user (assuming that all comments were kept correctly before the directive and not after or on the same line). But what if you wanted to make comments about your specific installation. You are making comments so that others in your working group can see why you made certain changes to the config file, right? So how are they differentiated from the primary directive comments. This is the type of problem that XML namespaces are intended to solve -- a way of giving demarcation points to distinct pieces of (sometimes) unrelated data or simply the clean combination of multiple schemas so that your schema definition doe not bloat to immeasurable levels and different schemas can easily share with one another.
Something keeping back Linux/BSD/UNIX is the stubborn, 1337 coders who spent all day figuring out a config file that some joker on the net thought would be a keen config format but forgot to comment it. Let's face it, Apache is not the norm. Config parsers are a known problem with known solutions. Writing a config file parser is not the primary focus for most programmers out there. The config file is a necessary evil to them. Let's make it easier and just say, here's your DOM interface. It's well documented, works well for the limited dataset with which you a working (config files are usually less than 50K), will handle any configuration organizational type you want (hierarchical, flat, etc.) and will save you the time of writing a parser yourself.
Have a nice day.
While I have my issues with XML Schema, it was never intended to replace or compete with something like ANTLR or BNF. The latter were meant to describe an entire language down to the nitty gritty. XML Schema is only intended to describe the format of a document within the confines of well-formed XML syntax.
Might I suggest taking a look at RELAX NG.
It has the much simpler syntax for which you may be looking. But it is still a well-formed XML document and can therefore be parsed with the same tools as the instance documents.
Don't forget that a primary reason XML Schema came to be was that it is a pain in the ass to make both an XML parser and a DTD parser (let alone the validation logic). I've done it. While not as hard as many other things out there, it's made a lot easier with having unified parsing code. And it allows for one schema syntax to be converted to another with an XSL-T stylesheet. Or for conversion to a group of schemas (think one stylesheet for generating the database schema and others to make your programming header files). Need to make some changes? A stylesheet is easier to update than classic source code especially when that source code requires a compiler which may not be handy on the box in question.
And let's not forget documentation! Another stylesheet to convert to XHTML (or whatever).
I assume by your affection for XSL-T that you are a web designer -- transforming XML data to XHTML, WML, etc. for presentation.
;-)) to view their content.
:)
If you haven't already, I would suggest checking out SVG and XSL:FO. As an XML-saavy web developer, I assume you are familiar with client-side DOM programming in a modern web browser.
Well imagine being able to manipulate graphics in much the same way (think Flash-style graphics without the plugin). Creating pages that are aesthetically pleasing without having all of those GIFs and PNGs flitting about. Imagine being able to embed contextual information in this graphical data so that the visually impaired (or lynx/links users) can still use your site -- "alt" attribute on steroids.
With regard to XSL:FO, imagine being able to write a stylesheet that represented exactly the appearance of the document. Whereas XHTML is intended for a wide variety of clients where height, width, and color depth are all variable, XSL:FO is perfect for generating PDF (think online software documentation as an atomic unit of data instead of a bunch of distinct pages in a tarball/zipfile). It's perfect for generating PostScript for consistent layout going to a printer. Or RTF, MS Word, or TEX/LaTEX for those who like to use a word processor (or emacs
...just some food for thought. I agree, the "chameleon-like qualities" are nice too.
This is a analogous to C being a programming language with BNF being a common meta language for it. Or more appropriately, CORBA's IDL is closer to the concept of a schema than an XML document. XML by itself is analogous to the marshalled data that CORBA uses for it's serialization between ORBs.
Although a particular instance document or class of documents (according to a schema) can be used as a meta language (Mozilla's XBL comes to mind although that blurs the line somewhat), it is primarily a data/content markup language.
You forgot to mention that with strcat, you are responsible for buffer allocation/deallocation.
For C++ you can write
--------
std::string a="hello", b=", ", c="world", d=".";
std::string e;
e.reserve( a.size() + b.size() + c.size() + d.size() );
// or e.reserve( SOME_APPROPRIATE_CONSTANT_VALUE );
e = a;
e += b;
e += c;
e += d;
std::cout e std::endl;
--------
Modern C++ implementations wouldn't create a temporary in this case because the target buffer has already been made large enough for the source data. The only reason you don't have to worry about it (and strcat seems faster in your mind) is that you have already made the multiple calls to strlen to make sure that the target buffer is large enough or you have chosen what you consider a large enough target buffer (which is subject to buffer overrun errors in some circumstances).
And it's still easier to use than strcat. AND this probably isn't your program's hotspot anyway. Premature optimization and all that.
Jython is out for Python, the Rhino library is available for JavaScript, Apache Cocoon is recently implementing a Java-based Scheme interpreter.
I've heard of a Perl port from a while ago, but can't think of who did it. I think it was a research assignment and didn't go very far.
I know there is a REXX implementation out there too.
Moving on, if you want to count the "native" compilers, gcj from the GNU Compiler Collection has close integration with C++ to the point that they seem to mesh well. It's called CNI.
The long term plans for Java include items such as tail-recursion and templates but they came up too late in the dev cycle to include in 1.4 without pushing the release date out too far. 1.5 is slated to have an updated bytecode format (although presumably backwards compatible in much the same way that 1.02-era applets still run for the most part in JDK 1.3)
.NET
Don't presume that Java isn't a moving target for
It's not like Sun and IBM are planning on standing still and waiting for Microsoft to catch up.
Has Sun sued Apple over Cocoa written in Java? Has Sun sued any of the large number of companies that have implemented a native compiler for Java?
The lawsuit was specifically over JNI and RMI. Sun had no problems with strict supersets of the Java language (COM integration for example). However the native interface was replaced with RNI(?) and RMI was simply ommitted.
This means that if people coded to the spec for native integration with portable C, it wouldn't work from one target to the next. And in the case of RMI, MS simply didn't want a competitor to DCOM within DevStudio. RMI is a big deal. On a "pure" Java platform, RMI was how distributed computing was done. You take that away and suddenly you're right back with C and C++ and their myriad of options for distributed programming but lack of any consistent single API that you can use anywhere.
You'll note that MS whined that RMI was just too time consuming to be bothered with. Then after the judgement, an RMI implementation was produced in less than a month!
THIS is the reason Sun has not submitted Java to a standards body. If Java is messed with, Sun would have no legal recourse while suffering significant liabilities in keeping Java's APIs consistent. Add that to the fact that no standards body has sufficient clout to do more than look at Microsoft (or anyone else) sternly.
Do I trust Sun completely. Of course not. It is a large, public company with all of the benefits and drawbacks of a large, public company. But I trust them *enough* (with their current track record) to keep Java relatively clean and consistent -- especially in light of folks like IBM making compatible and very fast JVM implementations.
Sun isn't as closed off as people would suggest. The Java API for XML Parsing was heavily influenced from outside contributors -- especially the 1.1 version with TRAX.
Where are the cross-platform, standard C and C++ libraries for networking, threading, graphics, distributed programming, database access, XML parsing, object serialization, directory (LDAP, X.500, etc.) lookup, authorization, authentication, i18n and l10n? I'll tell you where: in the standards bodies who cannot enforce what people use nor can they do anything about people who ignore the spec.
Where would Java be if it were submitted to ISO five years ago? Right where C++ is today with Microsoft providing the only viable development platform. Woohoo.
I liked the comparison of technologies, but it misses a main point. Or rather, I believe its primary audience misses a main point.
.NET and the JVM may be limited, let's not loose track of the fact that extern "C" {} and its ilk are far more limited. Instead of limiting languages to objects without templates and continuations, the current scheme of exporting function symbols and structs is downright embarrasing.
.NET as a library/component interface and leave each language relatively intact. For example, implement your library/component in the language of choice, but export the functionality (what is currently "handled" by library symbols) in a language-neutral but far more feature-rich manner.
.NET is not perfect. The JVM is not perfect. But I strongly believe that they are a step in the right direction. For example, the current choice(?) on UNIX systems is to have C-compatible exports for libraries.
While
What would be really nice is using
Doesn't "Managed C++" allow for advanced C++ features that simply are not exported for use outside the codeblock? C# has "unsafe" blocks for its own bit-twiddling.
We're on the right track here. Let's not throw the baby out with the bathwater!
What exactly can C do that C++ can't? C++'s std:string ends up comparable to C and char* in speed. C++'s standard quicksort algorithm is faster than C's (not as fast -- faster).
Instead of taking "a little discipline" with C, why not spend some effort with a more advanced language?
And, for convenience, a rundown by the players involved (both for the Linux kernel and AMD) is here.
In short, for the reading-impaired, it's not an Athlon bug.
ACIDfree*
Or maybe
Webber
Kind of like "Flipper," but best used only for websites because, like dolphins, they can go down out of sight from time to time without warning.
Canthandlehighvolumeupdateswithoutcorruption
Kind of rolls off the tongue doesn't it?
And yes, I have used MySQL and yes, I have seen what happens to a MySQL database from time to time even with proper maintenance and yes, transactions are not optional.
Best wishes to them on naming their dolphin though.
* ACID stands for Atomicity, Consistency, Isolation, and Durability
See this link for more info.
I really does, and not just online. I worked for a company that did websites for radio stations. We were reading results from a poll as part of an on-air contest where people could call in or use the web to vote for their favorite band. After a snafu with the data, we contacted the station to apologize for losing about a quarter of the results of the first few hours of the contest. We were expecting to be (quite rightly) reamed for it even though the contest had the rest of the week to run its course.
As it turned out, they didn't mind at all. They had already decided who the top two choices would be and only cared which of the two came out on top. In short, Limp Bizkit was popular, but not THAT popular.
I won't name names, but perhaps folks who listen to popular radio in the Chicago area (and other major venues) should keep this in mind the next time your radio station claims to give you what *YOU* want.
It's not just online...
First of all, for those individuals who refer to C++ as an OO language, please stop. You're wrong. C++ can be used for an OO project, but it is a multi-paradigm language. At least that's what Bjarne Stroustrup calls it. But what does he know about C++?
Second, use of C++'s STL does not equate to OO programming. It is an example of generic programming. Here's a hint: the STL has very little inheritance except for iterators and iostreams -- most evaluation is handled at compile-time. And even iterators and iostreams are just as much generic as OO.
Finally, please dispel the rumor that C is automatically faster than C++ because of C++'s excessive overhead. Need proof? Please read this article about treating C++ as its own language and not a variation of C. Yes, it's a PDF. Get over it.
Think the article is FUD? Prove it! Take the examples from the article and tune them better than he did. Compile them with trusty ol' gcc and g++ on your box. Measure the results. After you do so, can show that C is faster, does not contain any potential buffer-overflow bugs, handles error conditions, and wasn't at least five times more code to do it, then reply back with your results. I have a feeling I won't be getting any replies from people who actually try it.
That said, use whatever language you like best. Studies have shown that people will always perform better in languages they know intimately well than languages in which they have a general familiarity.
But if you want to use OO and C++, check out this numeric library
Have a nice day
Heh... so much work and vitrol to avoid a few measly comments. As was stated by my first post, having a few extra comments would rather likely not hurt anyone. Skipping a few extra comments (more often the case) can definitely hurt.
See my other post regarding this thread.
If a code beautifier can't deal with the input, you've got bigger fish to fry than the comments...
And what did Microsoft do? They rewrote it.
Let me restate my intentions. I acknowledge that I wasn't very clear on this. My criticism was of the recurring issue of macro viruses and worms through certain email programs and web servers. I didn't mean to suggest that they dump the whole kit and kaboodle.
I believe that COM and COM+ were good ideas. Sure they could be made better, and at each version, they are better. The ActiveScripting engine, when not exposing massive security holes, is a fine piece of interface and language interaction design.
But no, they haven't been fixed already. Those specific exploits are stopped, but many of the underlying reasons why the holes are present are still there. Microsoft tends to treat the wounds and ignores the cause of the disease.
But who am I to argue? I am neither a software tycoon nor a user of Microsoft software. I just have to work with people who are software tycoons and/or use Microsoft software.
At least all of the people in the anti-virus software industry are kept busy and paid...
I wish I had remembered to switch that out (I had actually thought of it when I started the post). It goes to the point that comments should make the implicit intent of a particular piece of code, explicit.
You're right of course.
I have to admit, my rant wasn't intended to target you specifically. It was more of a general rant. Maybe I'm just cranky because k5 is still down.
:-/).
;-)
And I agree that comments aren't a substitute for documentation. Use cases and UML don't lend themselves to source code comments. However, my comments about "Cliff's Notes" still stands. Comments judiciously sprinkled within code helps casual scanning for meaning much faster and easier no matter your coding skill. Coding skill simply speeds the case where comments are not present.
In answer to your question, while certain logical constructs are best expressed in code, overall concepts are usually just as easy if not easier to express in a natural language.
Unless you are writing programs and libraries that are only going to be used from end to end by other programmers, the outside world is dictating needs, requirements, and problems. That outside world speaks a natural language. If you cannot map the problem set and the solution set to a natural language, I submit that you do not have an adequate knowledge of the problem.
However in this case, comments would be a side effect.
Programming languages describe and work with the nuts and bolts. No programming language that I am aware of is sufficiently abstract to directly map to complex real world problems; no creative use of partial template specialization in C++, dynamic classloading in Java, dynamic function definition in Scheme, etc. can do this.
Conversely, no natural language that I am aware of can adequately describe a truly logical, deterministic domain either (just check out legal documents for proof). There needs to be more translation between the two.
For now, those bridges are comments and documentation.
-----
For a less abstract argument, let's leave computers out of it for a second. Two people from Indianapolis can communicate with each other better than either can communicate with someone from Sydney. They all speak English, but the dialects, the idioms, and the inside jokes may not translate. So when we write for general distribution, we try to keep those local colloquialisms to a minimum (and no, I admit that I haven't been a perfect example of this in my posts
Now keeping this analogy in mind, a programmer has an intimate relationship with a computer/compiler/system libraries/whatever. Together they have many inside jokes, goofy idioms, and function prototypes that mean absolutely nothing to someone else who, not being necessarily stupid, simply has a different focus or area of expertise.
While it may be more effort, and it may reduce some of the free-wheeling fun you would have had if you were alone with your CRT, doesn't it seem appropriate to make it more comprehensible if for no other reason that to allow others that specifically don't know as much as you to learn from a good example? Wouldn't that help to encourage others to continue using your code instead of scrapping it just as the interview topic suggests? Wouldn't it help to keep a few less wheels from being reinvented?
Maybe I'm too idealistic. Maybe I'm just not jaded enough. But for me, part of being a lead software developer or a senior software engineer or a project lead is not simply to crank out a mountain of code while others look on and a select few help out. We don't code forever. Some of us get sick of it before too long. Some go into management. Doesn't it make sense to try and *teach* the ones coming up to do what we do? For me, it does. But, again, I am lazy sometimes. A few extra comments means that more than half of the time, I don't need to be asked what something I wrote was intending to do regardless of whether or not they are as good a coder as I am. They just read the comments.
...I'm also prone to being long-winded.
The Java "fixation" started in one of the betas for Netscape 2.0. You criticize Java for its immaturity when Netscape itself was just as immature and IE was still called Spry Mosaic.
Netscape4 was/is crap. Netscape 3 was faster, but simply avoids the "crap" label due to its immaturity. IE "ate Netscape's lunch" because it was component-based and people could embed it into their own applications easily, reducing their development time. Netscape4 would never be able to do this. Neither would have the Netscape3 codebase. Componentization/modularization must be done relatively ground-up to be used effectively.
A new codebase was the only real answer at that point. The only better answer (20/20 hindsight and all that) would have been if they made it more modular to start with instead of stopping at the "plugin" model. Netscape focused on pluging other things into the browser. IE focused on letting the browser get plugged in to other things.
At least with the rewrite, those who want something better like recent builds of Mozilla have that option. I'm not convinced that would have happened if the codebase had continued unmolested and bristling with thorns.
It's taken a few years, but more than a browser is bearing fruit from the Mozilla vine, and I for one am glad they did the rewrite.