Nobody (in their right mind) bashes the W3C because they are a bunch of evil corporate drones. People bash it because the W3C has created too much overengineered, half-working, overly complex and generally crappy specs recently, without listening to valid complaints from their actual users.
XSD is one example that is particularly nasty because the W3C seems to plan forcing it in every other spec they create (for example XSLT 2.0, XQuery, RDF/OWL), making them very hard to implement (how many conformant XSD implementations are there? For languages other than Java?)
I'm wondering why they changed their name from Berlin to Fresco.
Ever been in Berlin recently? It's fucking cold there in winter, the natives talk a horrible dialect, public transport is expensive, there are way too much schmocks who love living in the Reichshauptstadt because they could meet Benjamin von Stuckrad-Barre or some other aesthetically challengend famous "artist" in some lousy yuppie bar, and the beer sucks.
Nobody wants to have his toy project associated with it anymore. It was cool in the 90s, but the times, they are changing...
It's been a while scince I used Debian, but here I go:
Even with apt and deb, it's still all binary packages. I like the source-based approach better. (and yes, I know about src-debs. But honestly, what do you use more often?)
Building a port yourself is trivial (it's just a Makefile and a list of files that get installed, basically), way easier than building your own debs. I find that on my FreeBSD system, there is way less software installed without being under control of the package management system than on every Linux system I used.
FreeBSD doesn't try to be clever unless I tell it to, unlike, for example, Debians "alternatives". If I type "vi", I get vi, and not an end- and useless mess of symlinks pointing to whatever editor. The packages just work like the original authors intended, not like the packagers thought it would be better.
Debian has more kinds of dependency. Ports just depend on something, or they don't (of course, what they depend on may depend on some options you choose), but they don't "suggest" anything. I never understood why this fine-grained dependencies are useful, I like the KISS approach better.
Of course, YMMV. More important than the differences are the similarities, however, especially that both systems "just work". Both Debian and FreeBSD are fine systems, and there really isn't such a great difference between them from a users point of view. Certainly not enough to justify holy wars.
Because for the most part, the GPL ensures the code stays truly free and out in the open
Uh, wasn't it that the GPL ensures that new code written by others than the one who chose to use the GPL has to be "truly free and out in the open"? You know, just because Apple used FreeBSD code, this code didn't just go away, it is still as freely available as it was before.
BTW, Apple (and NeXT before) does use and modify GPL code (GCC, for example), and they don't seem to have a problem with playing after the GPL rules, so maybe the license wasn't the only reason for not choosing Linux after all.
There's a simple solution to both the problem of hight level languages being "just a convinent
ways to write C" (and I don't see why one should exclude Java here, but I don't think that this argument is valid anyway) and them being slow. Use high level languages that don't run in a C-based interpreter. Duh.
For example, try Common Lisp, Objective Caml or Ada (not that high-level, but not the worst idea if you care about security).
If you're curious, yes, there was a B, but there was not actually an A (or rather, there was, but it was called ALGOL).
Between ALGOL and B, there was BCPL (and CPL before that). Hence there was a dispute whether the language following C should be called D or P (and AFAIK, for each name there were several experimental languages that all didn't succeed), until C++ became popular.
I would not give much credit to someone with a bit of paper from a purely online 'university' course.
I study CS at a german online-mostly university (without quotes, see http://www.fernuni-hagen.de. It's a regular uni, but only does distance learning),
and people there like to think that some employers think otherwise. The main reason is simple: Most of the students have lots of problems with motivating themselves to keep on studying without anyone forcing them to (and a lot of them have real day-jobs, too), and a lot of them fail. If you suceed, people can be fairly sure that you don't have problems with discipline or lazyness. Of course, that may be wishful thinking:-)
On the other hand, they can also be sure that people know Usenet, because that's the most important way for students to cooperate, and every Usenetter knows what kind of timesink that can be (and every/.er can make an educated guess).;-)
No, that's just fluff, and list evaluation is the be-all & end-all of programming.
Yawn. No, list processing is not the be-all and end-all in programming. That's why Lisp, for example, has arrays, hashtables, structs and a powerful object system.
I don't care so much about Java, but with Python, it's just that a lot of its cool features are also in Lisp, like functions-as-data, classes with metaclasses and the ability to define and change them at runtime, dynamic typing, docstrings, the REPL/interactive prompt, keyword and "rest" arguments to functions, ability to fix bugs without having to stop the running program,... However, it lacks, for example, macros (don't even try to compare the power and beauty of Lisp macros to the C preprocessor!) and good native code compilers, optional type checking and a variety of free and proprietary implementations all adhering to the same standard.
As for syntax: Both Lisp and Python have the problem that people, esp. newbies, hate their syntax (the parentheses in Lisp and the significant whitespace in Python). Most people eventually get over it and even get to like it. Just because a language doesn't look like C doesn't make it bad.
You are right about the lack of easy-to-find, ready-to-use libraries for common tasks, however (not about the "standardized" part, however. Last I looked there was no Python standard.) There are some projects to change that, for example CLOCC, but there's still a long way to go.
IMHO, the single greatest problem Lisp has is non-technical. It is the (wrong) perception that the only data type in Lisp are lists, that there is no OO, or even iteration, that it is interpreted and slow, and generally dead. I'm not interested in forcing anyone to use Lisp, but I for one do like it, and if you are looking for a cool language to learn next, I'd say you definitely should have a look at it.
Along with GCC for cross-platform compatibility, look at using GLIBC to make sure the functions you expect to be there, are there for all of the platforms.
Huh? Using buggy, bloated, embrace-and-extend libraries is now considered useful for crossplatform development?
For the newbies: If you are amazed how well Emacs can emulate lesser editors, note how easy it is to implement. If viper-mode wasn't predefined, making available all the power and expressiveness of vi in Emacs would be as easy as putting the following in your ~/.emacs:
(defun viper-mode (while (read-char) (ding)))
(Note to parent poster: The Emacs Lambda Forces are informed. The black helicopters will arrive soon. Resistance is futile.)
So maybe the initial predominant quota of German/European (don't know about other European languages) in the project was the reason, that nobody cared about the 'k'.
"That nobody cared"? It's not as if the K was a typo initially or something. KDE originally was the "Kool Desktop Environment", as opposed to the "Common" one. Kool obviously is not a german word, and I strongly doubt that you'll find anyone who would spell it that way by mistake.
Simple. They should stop hiding behind insisting to be non-technical users. If they care, all the information needed is out there for free, otherwise chances are their bug reports won't be too helpful anyway.
Why can't all these IDE makers just use Vim (or even Emacs, or how about either?) as their code editor?
If they would use Emacs, how much of an IDE would they have to build themselves? Emacs already does about everything modern IDEs do, it just is less color- and more powerful.
The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue.
You really think people upgrade their hardware so that lazy programmers can get away with sloppy inefficient coding? Not for me, thanks anyway.
By the way, there is nothing wrong with high-level languages, au contraire. Just use those with efficientnative-codecompilers. (Objective C in its half-smalltalkness may be nice as well, but personally, I don't really like it.)
Slashdot Mirror
XSD is one example that is particularly nasty because the W3C seems to plan forcing it in every other spec they create (for example XSLT 2.0, XQuery, RDF/OWL), making them very hard to implement (how many conformant XSD implementations are there? For languages other than Java?)
Bah, PHP? Try awk, Bash or Postscript for a thrill!
Nobody wants to have his toy project associated with it anymore. It was cool in the 90s, but the times, they are changing...
- Even with apt and deb, it's still all binary packages. I like the source-based approach better. (and yes, I know about src-debs. But honestly, what do you use more often?)
- Building a port yourself is trivial (it's just a Makefile and a list of files that get installed, basically), way easier than building your own debs. I find that on my FreeBSD system, there is way less software installed without being under control of the package management system than on every Linux system I used.
- FreeBSD doesn't try to be clever unless I tell it to, unlike, for example, Debians "alternatives". If I type "vi", I get vi, and not an end- and useless mess of symlinks pointing to whatever editor. The packages just work like the original authors intended, not like the packagers thought it would be better.
- Debian has more kinds of dependency. Ports just depend on something, or they don't (of course, what they depend on may depend on some options you choose), but they don't "suggest" anything. I never understood why this fine-grained dependencies are useful, I like the KISS approach better.
Of course, YMMV. More important than the differences are the similarities, however, especially that both systems "just work". Both Debian and FreeBSD are fine systems, and there really isn't such a great difference between them from a users point of view. Certainly not enough to justify holy wars.BTW, Apple (and NeXT before) does use and modify GPL code (GCC, for example), and they don't seem to have a problem with playing after the GPL rules, so maybe the license wasn't the only reason for not choosing Linux after all.
For example, try Common Lisp, Objective Caml or Ada (not that high-level, but not the worst idea if you care about security).
On the other hand, they can also be sure that people know Usenet, because that's the most important way for students to cooperate, and every Usenetter knows what kind of timesink that can be (and every /.er can make an educated guess). ;-)
Preface
The X-Windows Disaster
Some quotes
The Unix Hater's Mailinglist archive
Additional Unix-Hater's information
ObLink:
Teach Yourself Programming in Ten Years
I don't care so much about Java, but with Python, it's just that a lot of its cool features are also in Lisp, like functions-as-data, classes with metaclasses and the ability to define and change them at runtime, dynamic typing, docstrings, the REPL/interactive prompt, keyword and "rest" arguments to functions, ability to fix bugs without having to stop the running program, ... However, it lacks, for example, macros (don't even try to compare the power and beauty of Lisp macros to the C preprocessor!) and good native code compilers, optional type checking and a variety of free and proprietary implementations all adhering to the same standard.
As for syntax: Both Lisp and Python have the problem that people, esp. newbies, hate their syntax (the parentheses in Lisp and the significant whitespace in Python). Most people eventually get over it and even get to like it. Just because a language doesn't look like C doesn't make it bad.
You are right about the lack of easy-to-find, ready-to-use libraries for common tasks, however (not about the "standardized" part, however. Last I looked there was no Python standard.) There are some projects to change that, for example CLOCC, but there's still a long way to go.
IMHO, the single greatest problem Lisp has is non-technical. It is the (wrong) perception that the only data type in Lisp are lists, that there is no OO, or even iteration, that it is interpreted and slow, and generally dead. I'm not interested in forcing anyone to use Lisp, but I for one do like it, and if you are looking for a cool language to learn next, I'd say you definitely should have a look at it.
Heathen.
They could, of course, also just have installed a standards-compliant non-bloated shell in /bin/sh, where $DEITY wanted it, but noo..
(defun viper-mode (while (read-char) (ding)))
(Note to parent poster: The Emacs Lambda Forces are informed. The black helicopters will arrive soon. Resistance is futile.)
BTW, what the heck does "Kopete" mean?
>> What are you waiting for? >SMP Support. Native Java.
A good place to start (without having to get a CS degree) would be reading How to Report Bugs Effectively, and of course How To Ask Questions The Smart Way.
By the way, there is nothing wrong with high-level languages, au contraire. Just use those with efficient native-code compilers. (Objective C in its half-smalltalkness may be nice as well, but personally, I don't really like it.)