Though I like Emacs and currently use it, I find the standard syntax highlighting of Vim superior.
Maybe it is because I mostly use Perl.
Two things stand out.
emacs only highlights variables in Perl when they are declared, and does not to highlighting on @ and % variables. In Vim all variables are highlighted anywhere.
The other thing is POD documentation. In Emacs one has to reload the file for POD sections to be highlighted, when in Vim they are highlighted from the moment you start a '=pod' section.
Nicolay77 is right. I have used assembly, C, C++, Cobol, but also Perl, Python, Ruby, Scheme and Common Lisp.
It is not so much a line from purely declarative to functional, it is that Common Lisp has a whole lot of features from which subsets are implemented in other languages. Common Lisp overlaps them all.
The only language that is really close in possibilities is Perl. Pity about the (Perl) syntax though.
I think that in this case reference counter mechanism can be used.
Start with adding a new version of the device driver, new requests should go to the new device driver, while old requests being busy will decrement the reference counter when they stop.
Maybe you need redundant hardware, but in such a scenario as outlined by you, this will already be the case.
Granted, but I like some desktop functionality for accessing USB Mass Storage, and the whole chain udev/inotify/hald/hotplug only works with kernels > 2.6.12.
So I have now settled on a vanilla kernel 2.6.16.11, because the Debian kernels > 2.6.12 always freeze on my AMD Athlon 2000+ system (that is the only one affected, I have several other systems running Debian 2.6.15 which are not affected). It runs stable and does not freeze after 24 hrs.
I have even only touched Java a little bit, I find LISP much more interesting.
Right now, I am doing mostly benchmarks in Common Lisp, to test the performance of the SBCL and CMUCL compilers, against C (and sometimes other compiled languages).
Thus far those are only small things, but it seems that SBCL and CMUCL (depending upon the right type declarations for an (optimize (speed 3) (compile-speed 0))) (too much parentheses, you say ?) compare very favorably against C (-O3), a certain implementation compiled by CMUCL is even faster than the equivalent in C.
What I am really looking for now are some things a little bit more complex, but not too much, which can be easily written in Common Lisp, but also easily ported to C.
The only current downside I have with Common Lisp implementations, is the lack of POSIX process control primitives, and a good documented binding against Qt/KDE.
And of all languages, I find that Perl comes most close to Common Lisp in possibilities.
When I started out on Common Lisp about a year ago, I was shocked at the width of language constructs available in it, but also about all the things that I knew partially from other languages that where already present in Common Lisp in 1984 and probably even earlier.
And about things I can do in Perl : functional programming, object-oriented programming, closures, even macros, maybe not as powerful as in Common Lisp, but certainly usable (BEGIN {} anyone).
When I write the same functionality in Common Lisp and run it using clisp, it is a script ?
When I compile it with CMUCL or SBCL, then it suddenly becomes a program ?
I hate this bloody artificial division between 'programs' and 'scripts'. They are all a way of automating things, be it for embedded applications or data processing, and I use Perl daily for data processing, from starting up external applications, gathering data, process results, store and retrieve data from a database and generate reports.
A couple of years ago I was part of a migration from WANG VS to HP/UX + Oracle + Acucobol.
When we started compiling applications, I was shocked by their size, over 80 MB. After some browsing through the manuals I found out where the libraries were located and and how to use them with HP/UX ld.
The COBOL runtime dynamic library was almost 80 MB in size. By creating a makefile which which did the linking always dynamically, we ended up with executables between 100kB and 500 kB, which of course also started much faster (especially when using the preload option, which resolved library entry points without running the program).
In short, dynamic libraries optimise several things :
They can reduce the size of your programs greatly, programs take up less space and load faster.
Once a dynamic library is in memory, there is no need for disk access anymore, thus also faster loading times on programs.
Should all our COBOL programs have to run with a statically linked runtime of 80 MB, when running different programs, you exhaust your memory with code which is not very efficient.
10 programs x 80 MB = 800 MB, however, 10 programs with an average size of 300kB = 3 MB + 80 MB runtime, is 83 MB, this means that the first system has only 10% the efficiency of the second system.
Slashdot Mirror
And emacs misses folding.
Once there was an elisp folding package, but last time I searched, it was nowhere to be found.
Though I like Emacs and currently use it, I find the standard syntax highlighting of Vim superior.
Maybe it is because I mostly use Perl.
Two things stand out.
emacs only highlights variables in Perl when they are declared, and does not to highlighting on @ and % variables. In Vim all variables are highlighted anywhere.
The other thing is POD documentation. In Emacs one has to reload the file for POD sections to be highlighted, when in Vim they are highlighted from the moment you start a '=pod' section.
This word tyme that you use, it is neither time nor thyme.
Do you think major corporations are just going to hand over source code? Can you imagine the leaks?
Yeah, I think that The Daily WTF will have its hands full.
West-Vlaming ?
Nicolay77 is right. I have used assembly, C, C++, Cobol, but also Perl, Python, Ruby, Scheme and Common Lisp.
It is not so much a line from purely declarative to functional, it is that Common Lisp has a whole lot of features from which subsets are implemented in other languages. Common Lisp overlaps them all.
The only language that is really close in possibilities is Perl. Pity about the (Perl) syntax though.
COMPUTE C = C + 1.
I think that in this case reference counter mechanism can be used.
Start with adding a new version of the device driver, new requests should go to the new device driver, while old requests being busy will decrement the reference counter when they stop.
Maybe you need redundant hardware, but in such a scenario as outlined by you, this will already be the case.
Or a Debian junkie; apt-mirror; apt-get update;apt-get upgrade -y on unstable.
There are things which cannot be proven : See this article in Scientific American.
Granted, but I like some desktop functionality for accessing USB Mass Storage, and the whole chain udev/inotify/hald/hotplug only works with kernels > 2.6.12.
So I have now settled on a vanilla kernel 2.6.16.11, because the Debian kernels > 2.6.12 always freeze on my AMD Athlon 2000+ system (that is the only one affected, I have several other systems running Debian 2.6.15 which are not affected). It runs stable and does not freeze after 24 hrs.
I have even only touched Java a little bit, I find LISP much more interesting.
Right now, I am doing mostly benchmarks in Common Lisp, to test the performance of the SBCL and CMUCL compilers, against C (and sometimes other compiled languages).
Thus far those are only small things, but it seems that SBCL and CMUCL (depending upon the right type declarations for an (optimize (speed 3) (compile-speed 0))) (too much parentheses, you say ?) compare very favorably against C (-O3), a certain implementation compiled by CMUCL is even faster than the equivalent in C.
What I am really looking for now are some things a little bit more complex, but not too much, which can be easily written in Common Lisp, but also easily ported to C.
The only current downside I have with Common Lisp implementations, is the lack of POSIX process control primitives, and a good documented binding against Qt/KDE.
or KlayDough ?
A "pre-civilisation" is called a "culture", ie. a bunch of people from which artifacts and remains can be found, but no writings.
Don't forget to checkout CLISP, SBCL and CMUCL, which can be run inside Emacs with SLIME or ILISP.
I have the impression that the last couple of months I see more people on Slashdot mentioning Common Lisp as a replacement for Java.
And also, if you have a 20000 line Perl system, its also not a script.
And of all languages, I find that Perl comes most close to Common Lisp in possibilities.
When I started out on Common Lisp about a year ago, I was shocked at the width of language constructs available in it, but also about all the things that I knew partially from other languages that where already present in Common Lisp in 1984 and probably even earlier.
And about things I can do in Perl : functional programming, object-oriented programming, closures, even macros, maybe not as powerful as in Common Lisp, but certainly usable (BEGIN {} anyone).
So if I write something in Perl it is a script ?
When I write the same functionality in Common Lisp and run it using clisp, it is a script ?
When I compile it with CMUCL or SBCL, then it suddenly becomes a program ?
I hate this bloody artificial division between 'programs' and 'scripts'. They are all a way of automating things, be it for embedded applications or data processing, and I use Perl daily for data processing, from starting up external applications, gathering data, process results, store and retrieve data from a database and generate reports.
Just do :
perl -de 1
And you are in the debugger where you can do interactive stuff.
This reminds me of Acucobol on HP/UX.
A couple of years ago I was part of a migration from WANG VS to HP/UX + Oracle + Acucobol.
When we started compiling applications, I was shocked by their size, over 80 MB. After some browsing through the manuals I found out where the libraries were located and and how to use them with HP/UX ld.
The COBOL runtime dynamic library was almost 80 MB in size. By creating a makefile which which did the linking always dynamically, we ended up with executables between 100kB and 500 kB, which of course also started much faster (especially when using the preload option, which resolved library entry points without running the program).
In short, dynamic libraries optimise several things :
Should all our COBOL programs have to run with a statically linked runtime of 80 MB, when running different programs, you exhaust your memory with code which is not very efficient.
10 programs x 80 MB = 800 MB, however, 10 programs with an average size of 300kB = 3 MB + 80 MB runtime, is 83 MB, this means that the first system has only 10% the efficiency of the second system.
I do not think the GP is refering to libraries.
This weekend I was setting up a workstation as an X server, but I also needed the xbase-clients package (from Debian), to have xkb installed.
In addition to this package, it reinstalled the complete gcc, as a mandatory dependency.
This is what is meant by unexpected dependencies.
WANG VS (now probably Getronics VS)
We have also horrible time lags on our corporate Lotus Notes system, but I suspect it is because the administrators know f*ck about their systems.
The thing is that the more stuff you build into kernel space, the less context switching needs to occur, which helps performance.
Yeah, well, the first versions of Minix also ran on 8086, where you do not have any context switches at all.