Lisp-style macros are, in a sense, all about syntactic sugar. They let you write stuff easily and predicably that would be possible, but inconvenient by hand, to the extent that it becomes natural to implement domain-specific languages with them.
Java, and about every non-Lisp language, lacks syntactic extensibility. Yet, Java programmers obviously consider Java syntax to be not usable for a lot of everyday tasks - hence the ever-growing number of special mini-languages around Java, like Ant-XML, XDoclets, JXPath, to a degree even XSLT.
Of course it is possible to implement such DSLs in Java, but you typically end up writing an interpreter, and that usually means that, if you want to use the DSL in your program (say, evaluating expressions built at runtime), you end up manipulating strings and feeding them to a huge, opaque interpreter machinery - which is error prone and the hell to debug. And, by the way, one of the things people often call one of the biggest problems of macros, when they only know C-style ones.
Basically, much of what macros allow you to do is already done in the Java world, just without the language supporting it, and hence in slow, buggy and hard-to-debug, often ill-specified ways.
xmllint should work on Windows, at least the rest of libxml does. The best way to get it is probably with Cygwin, so you have a lot of other useful tools for text processing, too.
Of course this is useful. That's why Emacs has menus, multiple windows and stuff, after all:-)
Seriously, Emacs is obviously limited by its history. Elisp, for example, is a really shitty, old-fashioned, slow Lisp dialect, and you understand why this is bad when you start running two Emacs sessions in parallel because otherwise Gnus would prevent you from doing any work while downloading mails and doing all kinds of stuff to them, slowly.
However, even if too limited, the foundation is still stronger than what Gnome, KDE etc. came up with yet. More importantly, refactoring Emacs from scratch, or starting something completly new, is simply not economical - the power of Emacs is not only because it has some good ideas at its core, but because people have invested hundreds of man-years applying these ideas. Throwing that all away is plain stupid. So I guess we are stuck at the moment with several unsatisfying options.:-/
What I'm talking about would be a revolunionary change for Gnome, not for the world of the GUI. As I said, even Emacs comes surprisingly close. Other past and present systems are far ahead, for example Genera or Squeak.
Yes, I did. I didn't talk about "integration" in the sense of "apps look similar and have the same menu structure", but as in "apps use a common set of data, flowing freely from one app to the other, thereby making one app a natural extension of the other".
Ximian might be better there than vanilla gnome, but I didn't see anything revolutionary. (And I cannot test it myself scince they happen to not support my OS of choice.) Still a bunch of monolithic, uncooperative apps, even if a polished bunch.
Re:Inferno or "Why I don't care about Java"
on
No Java JRE on Pocket PC
·
· Score: 4, Insightful
what more could you ask for?
Third-party libs? An installed base? Competition between multiple implementations? Qualified programmers a dime a dozen? Not having to pay for it? Mindless hype?
I like the look of Gnome too, but after trying Gnome2.2 for a while now, I have to say it's probably not for me. And no, KDE is not the alternative.
What I miss most is integration of the loads of programs available for Gnome. Wouldn't it be nice if MrProject and the Evo calendar were linked in some way? Or if I could use the same filters for mail and news? Or look up people I meet in IRC in a global address book, and send them a mail or something?
Not to mention extensibility. How the f**k do I register spam mails with bogofilter from Evo? (I don't really know if it's impossible. The documentation doesn't mention it, but then, it thinks that using multiple mail accounts is "advanced", so scripting is probably beyond the scope of it (or Evolution). Well, at least it has documentation, unlike half of the other appps I use.)
Funny thing is, the best integrated environment I found yet is Emacs. Granted, it isn't that visually pleasing, and not exactly quick to learn, but once you get the hang of it, everything just works like it should. Gnus handles mail, news and other data sources transparently (including slashdot, btw), the erc IRC client integrates the BBDB contact database, I can listen to MP3s from the directory editor etc. pp. In short, a complete, well-integrated, productive desktop environment that even happens to work without X, for those SSH moments.
The only things I miss are a useable web browser (w3 sucks), an ICQ client and, more than anything, multithreaded Elisp. Or rather, drop Elisp and use a modern Common Lisp as the backend - CLISP, while not the best CL implementation of the world, would be appropriate, scince it's GPL and very portable. Writing an Elisp compat layer in CL seems possible, if not trivial. But of course, this is never going to happen.
It's not as if anyone asked him to do all that. Certainly not the original authors.
Personally, I'd be happier if he just would stop stuffing pseudo-scientific hogwash in there to make himself look like the anthropologic self-consiousness of the "geek tribe". Then again, given his other interests, it is probably safer to let him spend time this way.
Sure, sure. But what about innovative products like MS Bob, Clippy or a web server that can be instantly used for global file sharing and remote desktop access?
I'm talking about 100% keyboard control using only ONE keyboard command.
Doesn't this imply that there is only one function to control in the whole OS + apps?
Seriously, as every Emacs user will tell you, the problem with finding usable keyboard shortcuts is the that current keyboards just have way to few keys. To keep with that example, in my not-too-heavily-used Emacs session in that other window over there, there are 3881 functions I can interactivly invoke (would be more if I used some additional modes after the last restart). I'm to lazy right now to figure out how many unique keyboard commands (defined as "collection of bucky bits + one regular key) there are on my keyboard, but even if it would suffice, I strongly doubt usability engineers would be too impressed.
You can't have "100% keyboard control using only ONE keyboard command" unless you are OK with crippling apps. That's not to say that "Alt+Space x" is a particularly bright choice for one of the most frequent functions, of course (I bet that guy who came up with that isn't a touch-typist). Usable defaults is the key.
Hell, if you could integrate Mozilla in an Emacs buffer (like w3m now), I could finally get rid of that other window. Or if Emacs/w3 would actually be useful. I do basically everything in emacs; using only one window is a great way to solve the window management problem.
You honestly think that
for (int i = 0; i < C.length; ++i) {/*... */}
is more complex than for (int i : C) {/*... */}?
In a way, yes. The first uses the (little) possibilities the core language offers. The second uses a language feature that depends on a specific part of the class library.
So, even if the resulting code itself is easier to read, if conflates two layers of the language that should better be cleanly separated, IMNSHO. It basically boils down to the fact that you cannot change the class library anymore without possibly breaking the core language.
There's still X-Smiles, an all-Java browser with support for many XML-related "standards". It's admittedly kinda "special", but people are definitely still working on it.
I happen to be a Lispnik. My Lisp compiler of choice is written in (grasp!) Lisp, as are most others. Yes, that includes a native code compiler, assembler etc. for multiple OSes and architectures. (Parts of the runtime are written in C, admittedly, scince Unix eshews what it can't understand) Go have a look, it's free: http://sbcl.sourceforge.net
I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.
I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format,
while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.
Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.
I challenge you: Where are the good C coders that write working code, without critical bugs, in any reasonable amount of time? If you fail to find some, give me a simple example of how I can emulate stuff like update-instance-for-redefined-class,
restarts, method combinations or even trivial stuff like proper support for rational numbers in C, and claim that C is "a sharp tool" again.
I am really amazed about this self-justification of C hackers. Do you really believe this? That C++ and C of all languages are somehow more powerfull tools than high-level languages?
If I have the choice between the ability to modify arbitrary memory locations in an unchecked way or using a language that supports building abstractions, type-safety, changing running programs in well-defined ways, an escape from the "edit wait-for-the-compiler wait-for-the-linker try to debug with inferior tools" cycle etc., I don't have to think twice.
On the other hand, I have no problem will all the C luddites around. It's always good if you can point to your competition and show how they only managed to get a half-ready, buggy, crashing, inflexible system in more time than your working one took to write.
Slashdot Mirror
It is, however, POSIX-certified.
Java, and about every non-Lisp language, lacks syntactic extensibility. Yet, Java programmers obviously consider Java syntax to be not usable for a lot of everyday tasks - hence the ever-growing number of special mini-languages around Java, like Ant-XML, XDoclets, JXPath, to a degree even XSLT.
Of course it is possible to implement such DSLs in Java, but you typically end up writing an interpreter, and that usually means that, if you want to use the DSL in your program (say, evaluating expressions built at runtime), you end up manipulating strings and feeding them to a huge, opaque interpreter machinery - which is error prone and the hell to debug. And, by the way, one of the things people often call one of the biggest problems of macros, when they only know C-style ones.
Basically, much of what macros allow you to do is already done in the Java world, just without the language supporting it, and hence in slow, buggy and hard-to-debug, often ill-specified ways.
xmllint should work on Windows, at least the rest of libxml does. The best way to get it is probably with Cygwin, so you have a lot of other useful tools for text processing, too.
Nah, for real enterprise computing, you'll have to find something like this in red.
Of course this is useful. That's why Emacs has menus, multiple windows and stuff, after all :-)
Seriously, Emacs is obviously limited by its history. Elisp, for example, is a really shitty, old-fashioned, slow Lisp dialect, and you understand why this is bad when you start running two Emacs sessions in parallel because otherwise Gnus would prevent you from doing any work while downloading mails and doing all kinds of stuff to them, slowly.However, even if too limited, the foundation is still stronger than what Gnome, KDE etc. came up with yet. More importantly, refactoring Emacs from scratch, or starting something completly new, is simply not economical - the power of Emacs is not only because it has some good ideas at its core, but because people have invested hundreds of man-years applying these ideas. Throwing that all away is plain stupid. So I guess we are stuck at the moment with several unsatisfying options. :-/
What I'm talking about would be a revolunionary change for Gnome, not for the world of the GUI. As I said, even Emacs comes surprisingly close. Other past and present systems are far ahead, for example Genera or Squeak.
Ximian might be better there than vanilla gnome, but I didn't see anything revolutionary. (And I cannot test it myself scince they happen to not support my OS of choice.) Still a bunch of monolithic, uncooperative apps, even if a polished bunch.
What I miss most is integration of the loads of programs available for Gnome. Wouldn't it be nice if MrProject and the Evo calendar were linked in some way? Or if I could use the same filters for mail and news? Or look up people I meet in IRC in a global address book, and send them a mail or something?
Not to mention extensibility. How the f**k do I register spam mails with bogofilter from Evo? (I don't really know if it's impossible. The documentation doesn't mention it, but then, it thinks that using multiple mail accounts is "advanced", so scripting is probably beyond the scope of it (or Evolution). Well, at least it has documentation, unlike half of the other appps I use.)
Funny thing is, the best integrated environment I found yet is Emacs. Granted, it isn't that visually pleasing, and not exactly quick to learn, but once you get the hang of it, everything just works like it should. Gnus handles mail, news and other data sources transparently (including slashdot, btw), the erc IRC client integrates the BBDB contact database, I can listen to MP3s from the directory editor etc. pp. In short, a complete, well-integrated, productive desktop environment that even happens to work without X, for those SSH moments.
The only things I miss are a useable web browser (w3 sucks), an ICQ client and, more than anything, multithreaded Elisp. Or rather, drop Elisp and use a modern Common Lisp as the backend - CLISP, while not the best CL implementation of the world, would be appropriate, scince it's GPL and very portable. Writing an Elisp compat layer in CL seems possible, if not trivial. But of course, this is never going to happen.
bail_nonrpm () {
echo
echo "The Ximian Installer currently only supports RPM-based systems."
Hardly a good replacement for .debs.
Some people don't think so.
It's a new web programming language, brought to you by the same team that developed C/C++.
Personally, I'd be happier if he just would stop stuffing pseudo-scientific hogwash in there to make himself look like the anthropologic self-consiousness of the "geek tribe". Then again, given his other interests, it is probably safer to let him spend time this way.
Most of us, anyway.
Sure, sure. But what about innovative products like MS Bob, Clippy or a web server that can be instantly used for global file sharing and remote desktop access?
I have, and Boost is great. Makes adhering to Greenspun's tenth law of programming a piece of cake.
If someone would find a proof that C++ is a practical language for anything else but lowest-level programming, then I'd be impressed.
Seriously, as every Emacs user will tell you, the problem with finding usable keyboard shortcuts is the that current keyboards just have way to few keys. To keep with that example, in my not-too-heavily-used Emacs session in that other window over there, there are 3881 functions I can interactivly invoke (would be more if I used some additional modes after the last restart). I'm to lazy right now to figure out how many unique keyboard commands (defined as "collection of bucky bits + one regular key) there are on my keyboard, but even if it would suffice, I strongly doubt usability engineers would be too impressed.
You can't have "100% keyboard control using only ONE keyboard command" unless you are OK with crippling apps. That's not to say that "Alt+Space x" is a particularly bright choice for one of the most frequent functions, of course (I bet that guy who came up with that isn't a touch-typist). Usable defaults is the key.
Hell, if you could integrate Mozilla in an Emacs buffer (like w3m now), I could finally get rid of that other window. Or if Emacs/w3 would actually be useful. I do basically everything in emacs; using only one window is a great way to solve the window management problem.
So, even if the resulting code itself is easier to read, if conflates two layers of the language that should better be cleanly separated, IMNSHO. It basically boils down to the fact that you cannot change the class library anymore without possibly breaking the core language.
"San Jose"? Yer sure that you telecommute in the UK?
Calling a BBS a "database" seems like overstatement to me.
There's still X-Smiles, an all-Java browser with support for many XML-related "standards". It's admittedly kinda "special", but people are definitely still working on it.
I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.
I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format, while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.
Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.
I challenge you: Where are the good C coders that write working code, without critical bugs, in any reasonable amount of time? If you fail to find some, give me a simple example of how I can emulate stuff like update-instance-for-redefined-class, restarts, method combinations or even trivial stuff like proper support for rational numbers in C, and claim that C is "a sharp tool" again.If I have the choice between the ability to modify arbitrary memory locations in an unchecked way or using a language that supports building abstractions, type-safety, changing running programs in well-defined ways, an escape from the "edit wait-for-the-compiler wait-for-the-linker try to debug with inferior tools" cycle etc., I don't have to think twice.
On the other hand, I have no problem will all the C luddites around. It's always good if you can point to your competition and show how they only managed to get a half-ready, buggy, crashing, inflexible system in more time than your working one took to write.