Yup, that is true. And it was intended. Functional languages are also sorely underrepresented in the real world. Luckily, I don't have too much experience with it (the real world), but it seems like they use the weirdest, clunkiest, and most inelegant languages there (VB being one of the nicer, in fact).
Also, web-technologies are important in the real-world. To the point where I am almost surely convinced that one day, 90% of us will all work on web-infrastructure for each other, while the remaining 10% will take care of the rest of society.
Also, I was not trying to put together a list of useful languages. If a was, then my list would look entirely different. I was trying to list "popular" languages, for a suitable definition of "popular". I am very aware of the fact that just because something is "popular" and "much used" doesn't make it useful. And I am aware of functional languages, and do consider some of them to be useful. That doesn't make them "popular" though.
It might be that I was trying too much to remove my own bias from academia, and smart, well-educated programmers, but I don't really think so. Much of the real world revolves around the silliest programming languages.
This must be some of the worst bullshit I've heard about programming languages in quite some time.
Did you even read the article. I'll challenge you to find languages with much more different syntax from C/Perl than Befunge-98 and Brainfuck!
There used to be PASCAL for scientists, FORTRAN for mathematicians, BASIC for hobbyists or new programmers...
Actually, Pascal was for education, (and systems-programming (once you added some much-needed non-standard extensions)). Fortran was for scientists (mathmaticians would probably be happier with Lisp, or something like Mathematica, only scientists needs actual numbers).
Obj C, C, and C++ are very similar
No, they are not. Well, ObjC and C are the most similar of the three, but modern C++ has little in common with idiomatic C. Java looks very similar to Objective C (which pretty much tells you how different C and Objective C are).
...and most of the new 'Basic' environments like REALBasic and VisualBasic are near clones as well.
Maybe. My experience with VB didn't leave me thinking it was anything close to Java (or any other of the above mentioned languages). However, VB.NET is supposed to be so.
All of today's popular coding environments could be condensed to Java, Objective C, Perl, and some form of BASIC.
Well, if by popularity, you mean lots of users, or lots of jobs available, I am very confused why Objective C is on the list (although OS X should give it a boost). On the other hand, if you mean liked by it's users, you will hardly find any language not fitting that description. By any account, you need C++ on the list.
But yes, I agree that such a list can be made, and mine would be: C, C++, Java, VB, Perl, COBOL, PL/SQL, HTML/XML, ASP/JSP/PHP, SAS, Python, Matlab, Fortran, Common Lisp, mostly in that order, but maybe COBOL even more to the front of the list.
Anyway, there is no way to avoid C, C++ and or Java on the top of the list. (Which maybe was your point, but anyone taking more than a cursory glance at those languages will find that they are in fact very different from each other. They look similar on the surface, but are just as different as Pascal, Fortran and Basic).
It's the source code representation of C and C++ that guarantees that a 0 in the source code will be read as a pointer literal of the appropriate type instead of as a literal integer. The actual representation of that literal is machine specific (but could be a word-sized bitstring of zeros, as is quite common).
The reason "#define NULL ((void*)0)" is popular in C is because it helps detect stylistic misuse of NULL, since NULL is intended to represent a null pointer. It also makes it clear in some contexts (such as varargs functions, and old-style functions without a prototype) that a pointer value is intended, and not an integer.
The reason that doesn't work in C++ is because C++ has a different type-system. In C, one can convert freely both ways between any pointer type and "void*", without a cast. In C++ one needs a cast to convert from "void*". Thus "((void*)0)" defeats it's own purpose there, since anywhere you used it, you would require an explicit cast back to the pointer type you intended, so a literal "0" would have been easier, and by continuing to use the NULL macro, you make your own life a lot harder.
So, with these rules "double *foo = (void*) 0" is not valid C++, and the compiler should reject it. But "double *foo = (double*) (void*) 0" is valid. Now, I've been playing games with casts, and that is what would be happening if you defined NULL as "((void*)0)", and initialized it with "double *foo = (double*) NULL".
It is possible that the C++ standard allows an implementation to fuck up in this case, but an implementation that didn't recognize "(double*)(void*)0" as a literal pointer to null would be very strange (even among those extremely rare and weird compilers having different pointer representations for different pointer types, non-zero nullpointer representations, and different nullpointer representations for different types).
Well, if NULL is not 0, then it is ((void *)0). Otherwise, it's just not C. (Well, it can also be defined in some compiler-specific way, but when you cast NULL to a long, it should have numeric value 0).
Well, that's kind of being overly harsh on DRI, isn't it.
At least it's good for games, and other stuff were you
need fast graphics.
But so far, my experience with DRI has led me to disable
it as well. And it will be, untill I can at least safely run
simple things such as glxgears without guaranteed lockdown of my X-server.
Actually, the instability of Xfree86 is a big pain in the
ass for new users, and for people helping them convert.
People come to linux for increased stability, and the first
thing that happens after they randomly try some stuff on the
foot-menu, is that their X-server locks up, rendering their
keyboard, monitor and mouse unusable. Yay for stability!
Ok, enough ranting. I should probably be contributing something instead.
I really hope you are joking and pretending to be misunderstanding things. I can't for the life of me understand how you can achieve this catastrophical level of confusion, and still think you can understand it enough to comment on it on slashdot. Oh wait, this is slashdot, well, I guess it's quite normal then...
Actually, I see now that I was wrong. It's about a year or so since last time I used java, and that java doesn't have a typedef I had forgotten a long time ago. So basically, if BullionDiceMasterPackagingAssistant is a class-name (which it should be, not a variable, as there can of course be zero or many BullionDiceMasterPackaginAssistant's), and Mike just happens to be one of them. So if your code mainly revolved around organizing BullionDiceMasterPackagingAssistant's, then you really had to write BullionDiceMasterPackagingAssistant a lot, as it would be likely to pop up as arguments and return-values in every method dealing with BullionDiceMasterPackagingAssistant's.
So what would really be the correct choice, should you call it megacorp.employee.food_division.buillon.packaging. MasterAssistant, and just import that namespace when needed? Personally, I find that even more offensive, because you would then rely on package prefixes to differentiate different kind of employes. The inability of java to introduce a local shortcut for an extraordinarily long name (and long names is sometimes needed, just as shortcuts to them are), is definitely at fault.
I give up. Ok, let's admit it, java sucks in quite a few places, and this is definitely one of them.
I'm surprised. Do you really find it hard to make Ocaml code fast?
I would agree about Erlang (whose main implementation actually is quite slow), and Haskell (which it is really really hard to compile efficiently, and even harder to optimize unless you wrote the compiler). But Ocaml?
Ocaml's native compilers are actually really fast, at least comparable to gcc (but maybe not to even more optimizing compilers). If you get much worse than 50% of gcc's speed you must be doing something really wrong!
Aren't C's functions "regional" in scope? (My C is rusty) IOW, you have to explicitly export them. Most procedural languages are like this more or less. A local function/routine "overrides" a global one.
Actually, it's the other way around. They can be "static", meaning they are only accesible from the same source-file, but you have to explicitly make them "static". "extern" is the default. And that is unfortunately the only separatiorn you get, there are no namespaces, classes, modules, packages, nested functions, or any other means to keep things out of the global namespace, except for the concept of a source file with static functions.
But on to java... Since java has the concept of
packages, it wouldn't be that bad to allow functions lying inside a package. But it's not really such a nuisance to prefix with a class-name either. The difference between Quaternion.add(a,b) (Java), and quaternion_add(a,b) (C) isn't really that bad. On the other hand, with overloading on arguments, you could simply end up with add(a, b) in Java (if it supported functions), and a+b in C++ (since you can overload operators as well).
I guess some people like it a bit more explicit. Personally, I'm a bit schizophrenic about the issue. I like brevity, of course, but it can also make it really hard to understand other people's code (and in the case of C++, even my own). I think this last objection could be removed with the help of better tools, but currently I know of no such thing as a compile-time debugger for C++ templates, or a slower-but-smarter typechecker for languages using Hindley-Milner type-systems (ML) that can tell me what's really going on, or at least give me somewhat reasonable error-messages when something goes wrong, so I can screw things up on purpose to find out what's really happening.
I don't know what to do about "BufferedImageMediaStreamWatcherHandlerFactory", though. If it's really an abstract factory for creating handlers to watchers to buffered mediastreams of images, then it's really a well-chosen name, but I don't think that's a pretty common abstraction that would end up all over your code (and if it was, I'm sure you would come up with a shorter name). It's just like "assistant for the the chief packaging master of buillon dice" (or translated into norwegian: overbuljongterningpakkemesterassistent, (a well known song by Øystein Sunde))), is actually a very good descriptive job-title, but if you were working with him a lot, you would just end up calling him the packaging assistant.
And, not to forget, there are pure OO languages, such as Smalltalk, Self, and CLOS. And there are good OO-languages (albeit not completely "pure" in the sense of you not being able to subclass an integer), such as Java, Eiffel, Sather, Beta, Python, and even C++ (and not to forget: a whole lot of other languages).
The OOP-buzz started with SmallTalk (although Simula was the first programming language supporting OOP (and yes, that was before 1970)). Everything OO, but not OOP (OOD, OOA, OODB, etc) originated with OOP.
Classifying reality is only relevant in class-based models of OO-programming. And many people does not tout that as the main reason for using OO (myself included). And the reason for most programming languages not being purely OO, is because most programming language designers also have other goals (otherwise, we would all be programming in SmallTalk or Self).
OOP is for clean ways of reducing coupling, managing change, and allowing reuse in and between software projects. If you want to classify reality, you need a richer modelling language, such as e.g. logic, (or mathematics, depending on your viewpoint).
Whether EXPRESS falls into this role I don't know (never heard about it), but if it is designed for modelling, and not for execution, it isn't completely unlikely (although most currently existing modelling languages trade off generality somewhere, because their ultimate goal is to produce software, not model reality).
Thanks for the link, but unfortunately it didn't clear much up. I think we both knew that a class was a (ill-behaved) extension of set. Now, what I was wondering about was for what reason they existed in the first place. If they only have historical value, then it seems kind of stupid to keep them around. ZF-theory doesn't seem to need them, and almost all of mathematics can be reformulated in ZF-theory.
To say that sets can be constructed from classes is just a reformulation of saying that they can be formulated from other sets, and a property. So to me, it doesn't add any value. But I am not a set-theorist, and maybe classes really add something useful. Or maybe they are just a convenient notational device. Or maybe neither.
No: B is already defined. P\S is already defined, it contains all the elements of P except those that are in S. Saying that the two sets are equal is not a set, it is an equation. An equation is a statement of logic, and can be either true or false.
The current popular reformulation of sets (ZF-axioms) doesn't involve classes. I don't know what real mathematicians need classes for, but it's most likely something, otherwise they wouldn't be needed.
Subtracting sets (e.g) P\S doesn't involve any big problems. The problems shows only up if you involve negations of sets without a clearly defined universe of discourse. If you allow this universe to be the set of all sets, then you are in trouble. Because it could include such sets itself, and so on. It might be the case that classes were introduced just for this purpose, to allow people to do it anyway, but without destroying the foundation of mathematics, which is built on top of sets.
Yes, I don't like your definition of I. I agree that it is troublesome. The easy way out is to declare it meaningless (since you cannot define something in terms of itself (circular definitions)), or to reformulate it as an inductive definition. And in a typical formal system of notation (logic), you would be forced to do this choice.
Either way, the proof that all naturals are interesting, revolves around the non-formal definition of I. You can define it in a completely informal way (my way), in a way that is not meaningful (your way), in a way that is questionable (my reinterpretation of your way), and so on...
I don't think there is anything deep or fishy here. Circular definitions are certainly meaningless, but my reinterpretation clearly shows one of the deficiensies of the human brain. In an attempt to try to understand something that didn't make sense, I reformulated it in another way that perhaps could make sense (although highly doubtful), instead of pointing out the obvious fault that it was a circular definition. (And as most circular definitions of this kind, when trying to interpret it anyway, you would either reach everything N, or nothing (bottom)).
Don't design a plugin-architecture. It is a static and unchangeable abomination that must be stopped, that people keep adding incompatible plugin architectures to every program.
A much better alternative is to offer a standard extension language, such as Python, Tcl, ELK, SIOD, Guile, lua, or even (the horrors) Perl. Now, most anyone of these languages have a plugin architecture, so if for any reason, you need native code speed, it can be done by writing a WHATEVERLANGUAGE-plugin.
The difficulty of creating a plugin architecture yourself over dlopen, is that you will most likely do it wrong at first try. A little bit less wrong on the second try, and so on... But each minor change you make to the plugin-architecture will probably break almost everything. So it's better to hand the problem off to the scripting-language-implementors...
Fifteen months is a long time. You don't tell your emplyer that if you are already emplyed either. It would certainly not harm your resyme. If you've been working there for fifteen months, and decide to take a years vacation, or quit, you've certainly worked there long enough to get a good reference.
I am certainly no set-theorist either, so you should probably ask
Dr. Konvolina again about these things if it becomes unclear (or the
horror: I've been wrong). But I have worked for at least a year with
logic and formal systems, and mostly found out that those people who
actually make progress there, are way smarter than me...
But just to clear up: B=P\S is not a definition of a set. It
is a statement in logic, it can be either true or false.
The old definition of set's were equal to todays classes. I don't
know why we need classes, but I'm sure real mathematicians use them
for some sort of thing (real mathematicians don't worry much about
foundations, only logicians (and thus computer scientists) do).
The meaning of a self-referential set involves a set with itself as
a member. Such as "the set of all sets", "the set only having itself
as member", or anything in between. Of course, "the set of all sets
except itself" is equally troublesome, since the complement would be
self-referential. (And in those days, the complement of a set really
meant that, it was not taken with respect to another well-defined set,
but to a universal set including every set).
Your definition of the set I (either a prime, or the
smallest number not in I is however legal, as the property of
being prime or being the smallest number not (already) in I), is
certainly expressible in a formal system. It is almost comparable to a
standard recursive definition, e.g. where you define a binary tree to
be either an empty tree, or a node with two subtrees named "left" and
"right". If you reformulate that definition as one defining the set of
all binary trees it looks almost (but maybe not completely) as
"weird". And upon inspection this definition of I is certainly
simple enough. If you are used to inductive proofs, it is immediately
obvious that I=N.
Except that this set of interesting numbers is not self-referential. It is a proper subset of the naturals, and therefore cannot include itself. And the same can be said about the barber paradox.
I will not delve deeply into set-theory here. But what you remember from your classes about a class versus a set is true. A class C is defined as: C = {x | x has property P }
On the other hand, with the use of Zermelo-Fraenkels axiom number 4 from standard ZF-set-theory, the following is a completely ok way to define a set: S = {x | (x is element of T) and (x has property P) }, whenever T is a well-defined set.
In both definitions above, it is of course important that the property P is something we can express in a formal language, otherwise it is impossible to even in theory tell wether something is part of a set (note that it is ok for P to be very hard to compute, but it should at least be possible to express P in a formal language).
In the barber paradox, you have the set of all people: P. Populations are usually finite, so this set can be listed by enumeration, and is thus well-defined. Then you have the set of all people shaving themselves: S. And the set of all people not shaving themselves P\S. And we have the set B of all people shaved by the barber. All of those sets are well-defined. Now, you introduce the assumption that B=P\S. This leads to a contradiction, thus the assumption is wrong, the barber cannot possibly shave everyone who doesn't shave themselves. It is not a paradox, it is a simple proof (reductio ad absurdum), and there is no need to involve heavy set-theoretic stuff.
On the other hand, in the "interesting numbers" theorem, we have the set N of naturals. We define a subset I of "interesting" numbers. The trouble with I is that the "interesting"-property is not something we can express in a formal language. Thus I is not a well-defined set. Wrongly, we continue developing the proof under the false assumption that I is well-defined. Since our intention is to prove that I=N, it is natural to assume the opposite (not I=N), and in this case the well-ordering property of N gives us that there is a least number n in N, but not in I. Given our completely unformal definition of "interesting" above, it seems perfectly ok to say that n is "interesting". But if n is "interesting" then it must be in I. This is again a contradictory result, and thus we must conclude that not not I=N, which most people who aren't anal intuitionists, agree to mean the same thing as I=N.
Your publishers want it. That's probably because they can sell the book for a higher price. You should ask them what your piece of the cake will be, and determine if it's worth it.
The download would be excessively large for the expected bandwith of your readers. I.e. if you are writing a book for a relatively broad audience, who typically use modems, anything more than a few megabytes is too much. For most geeks, who already have broadband connection, a few hundred megabytes is usually tolerable, but some would probably like a CD as well.
You are writing something that would be useful as a reference book, and want to have the whole text available in easily searchable multiple formats on the cd-rom. And because you still want to earn some money, you are not going to put this up at your website (although a bunch of HTML files making it hard to print out, is probably great both for marketing and as copy-protection).
(Highly unlikely:) You, or your publishing agency has made a special deal with some software vendor to include a demo version of some product, which they for some reason don't want to distribute on the Internet.
Another alternative is to offer to send a CD for a few bucks more, and let the rest of the readers use your website. That's probably the best for the readers.
No, the proof as it is stated is valid. While self-referential sets can be troublesome, that is not the problem here. The problem is of course the loosely defined notion of "interesting numbers". And in that regard, the conclusion that all naturals are "interesting" is not really surprising. I'm sure a real mathematician like Ramanujan would quickly find an interesting property to any natural, such as: 478394739274019283740192837409128376354342
Well let's hope otherwise. There already exists several good open source systems for various sub-fields, but we also need an uber-system that does everything (albeit not necessarily as good as the specialized systems), but is friendly enough to be used by people who could never write it themselves (i.e: mathematica, maple, derive, mathcad, etc).
Today we have muPAD (generally the smartest, pretty friendly, but only somewhat free), maxima (which is usable, but hardly polished), yacas (which I know nothing about), and emacs calc (which is very user-friendly but also the dumbest). None of them (well, maybe muPAD) are close to becoming rivals to the above-mentioned systems in terms of either user-friendlyness or features.
(Of course, this is not special for computer algebra systems. We also need better DMBS (and related tools, such as form-generators, report-generators, etc...), office productivity apps, cad, gis, groupware, financial stuff, graphics, dtp, music, etc...)
It'd better be. For almost any situation, it is better to rely on your own sorting routine, than C's standard librarys qsort.
Case in point:
the algorithm qsort uses is undocumented (it's said to be "quicker sort", which nobody seems to really know what is, but most people tend to assume is quicksort).
It relies on function pointers to do comparison, etc. That has to be slow.
Because of it's need to be overly general, the interface is too complex to remember, and just writing your own sorting routine is probably more maintainable.
On the other hand: STL's sort is:
Well, still somewhat undocumented in what it does, but at least it offers you the choice between a simple sort and a stable_sort.
Fast, because it relies on templates, and not function pointers.
Relatively easy to understand, considering you have a basic understanding of STL.
Does STL sort bloat your program? Yes, if you use it lot's of places for lot's of different kinds of arguments. Is this bad? No, you would get that kind of bloat anyway, if you had to write each sort-routine individually. For most tasks, moderately bloated binaries are a better tradeoff than overly complex interfaces or slower code due to generality through function-pointers, boxing of values, etc...
Writing systems software in a high-level language? High-level languages will never be used for writing systems software. It is not fast enough. It will never be fast enough for systems software. OS developers, library writers, etc.. code in hex, directly to the hardware to get extra speed, and the rest of their code is in assembler.
Sure, well-written java is usually a little bit slower than well-written C, which is usually a little bit slower than well-written assembler. That doesn't mean that one should forever try to use assembler (or C). Just as important as speed for game-development is:
Time to market
That it actually works
That it is has interesting gameplay, and not just impressive graphics
In all these three cases, Java will be able to help. The only thing that speaks agains java here, is it's lack of raw speed. But that isn't really true anymore. Java, by itself is already quite respecably fast. It is not as fast as C (unless you count some weird benchmarks probably written just to show that), but it's not too far below either.
Secondly, you don't need to optimize everything, only the time-critical pieces of your code. And for most gaming purpoces, the speed-critical parts are the drawing routines. Making that as fast as in C is pretty simple. You build a wrapper around openGL or some other graphics library, and use that from java. There you go...
And that is exactly what a java gaming platform would look like. It would be a collection of well-defined API's for accessing your hardware in a controlled, but efficient manner.
Is it really going to happen? Nobody knows just yet, but I wouldn't dismiss it right away. The idea is good, the question remains to be seen whether the API's will be equally good, and developers adopt them.
Slashdot Mirror
Also, web-technologies are important in the real-world. To the point where I am almost surely convinced that one day, 90% of us will all work on web-infrastructure for each other, while the remaining 10% will take care of the rest of society.
Also, I was not trying to put together a list of useful languages. If a was, then my list would look entirely different. I was trying to list "popular" languages, for a suitable definition of "popular". I am very aware of the fact that just because something is "popular" and "much used" doesn't make it useful. And I am aware of functional languages, and do consider some of them to be useful. That doesn't make them "popular" though.
It might be that I was trying too much to remove my own bias from academia, and smart, well-educated programmers, but I don't really think so. Much of the real world revolves around the silliest programming languages.
Did you even read the article. I'll challenge you to find languages with much more different syntax from C/Perl than Befunge-98 and Brainfuck!
There used to be PASCAL for scientists, FORTRAN for mathematicians, BASIC for hobbyists or new programmers...
Actually, Pascal was for education, (and systems-programming (once you added some much-needed non-standard extensions)). Fortran was for scientists (mathmaticians would probably be happier with Lisp, or something like Mathematica, only scientists needs actual numbers).
Obj C, C, and C++ are very similar
No, they are not. Well, ObjC and C are the most similar of the three, but modern C++ has little in common with idiomatic C. Java looks very similar to Objective C (which pretty much tells you how different C and Objective C are).
Maybe. My experience with VB didn't leave me thinking it was anything close to Java (or any other of the above mentioned languages). However, VB.NET is supposed to be so.
All of today's popular coding environments could be condensed to Java, Objective C, Perl, and some form of BASIC.
Well, if by popularity, you mean lots of users, or lots of jobs available, I am very confused why Objective C is on the list (although OS X should give it a boost). On the other hand, if you mean liked by it's users, you will hardly find any language not fitting that description. By any account, you need C++ on the list.
But yes, I agree that such a list can be made, and mine would be: C, C++, Java, VB, Perl, COBOL, PL/SQL, HTML/XML, ASP/JSP/PHP, SAS, Python, Matlab, Fortran, Common Lisp, mostly in that order, but maybe COBOL even more to the front of the list.
Anyway, there is no way to avoid C, C++ and or Java on the top of the list. (Which maybe was your point, but anyone taking more than a cursory glance at those languages will find that they are in fact very different from each other. They look similar on the surface, but are just as different as Pascal, Fortran and Basic).
It's the source code representation of C and C++ that guarantees that a 0 in the source code will be read as a pointer literal of the appropriate type instead of as a literal integer. The actual representation of that literal is machine specific (but could be a word-sized bitstring of zeros, as is quite common).
The reason "#define NULL ((void*)0)" is popular in C is because it helps detect stylistic misuse of NULL, since NULL is intended to represent a null pointer. It also makes it clear in some contexts (such as varargs functions, and old-style functions without a prototype) that a pointer value is intended, and not an integer.
The reason that doesn't work in C++ is because C++ has a different type-system. In C, one can convert freely both ways between any pointer type and "void*", without a cast. In C++ one needs a cast to convert from "void*". Thus "((void*)0)" defeats it's own purpose there, since anywhere you used it, you would require an explicit cast back to the pointer type you intended, so a literal "0" would have been easier, and by continuing to use the NULL macro, you make your own life a lot harder.
So, with these rules "double *foo = (void*) 0" is not valid C++, and the compiler should reject it. But "double *foo = (double*) (void*) 0" is valid. Now, I've been playing games with casts, and that is what would be happening if you defined NULL as "((void*)0)", and initialized it with "double *foo = (double*) NULL".
It is possible that the C++ standard allows an implementation to fuck up in this case, but an implementation that didn't recognize "(double*)(void*)0" as a literal pointer to null would be very strange (even among those extremely rare and weird compilers having different pointer representations for different pointer types, non-zero nullpointer representations, and different nullpointer representations for different types).
Well, if NULL is not 0, then it is ((void *)0). Otherwise, it's just not C. (Well, it can also be defined in some compiler-specific way, but when you cast NULL to a long, it should have numeric value 0).
But so far, my experience with DRI has led me to disable it as well. And it will be, untill I can at least safely run simple things such as glxgears without guaranteed lockdown of my X-server.
Actually, the instability of Xfree86 is a big pain in the ass for new users, and for people helping them convert. People come to linux for increased stability, and the first thing that happens after they randomly try some stuff on the foot-menu, is that their X-server locks up, rendering their keyboard, monitor and mouse unusable. Yay for stability!
Ok, enough ranting. I should probably be contributing something instead.
I really hope you are joking and pretending to be misunderstanding things. I can't for the life of me understand how you can achieve this catastrophical level of confusion, and still think you can understand it enough to comment on it on slashdot. Oh wait, this is slashdot, well, I guess it's quite normal then...
True, it was intended as a hypothetical example.
So what would really be the correct choice, should you call it megacorp.employee.food_division.buillon.packaging. MasterAssistant, and just import that namespace when needed? Personally, I find that even more offensive, because you would then rely on package prefixes to differentiate different kind of employes. The inability of java to introduce a local shortcut for an extraordinarily long name (and long names is sometimes needed, just as shortcuts to them are), is definitely at fault.
I give up. Ok, let's admit it, java sucks in quite a few places, and this is definitely one of them.
I would agree about Erlang (whose main implementation actually is quite slow), and Haskell (which it is really really hard to compile efficiently, and even harder to optimize unless you wrote the compiler). But Ocaml?
Ocaml's native compilers are actually really fast, at least comparable to gcc (but maybe not to even more optimizing compilers). If you get much worse than 50% of gcc's speed you must be doing something really wrong!
Actually, it's the other way around. They can be "static", meaning they are only accesible from the same source-file, but you have to explicitly make them "static". "extern" is the default. And that is unfortunately the only separatiorn you get, there are no namespaces, classes, modules, packages, nested functions, or any other means to keep things out of the global namespace, except for the concept of a source file with static functions.
But on to java... Since java has the concept of packages, it wouldn't be that bad to allow functions lying inside a package. But it's not really such a nuisance to prefix with a class-name either. The difference between Quaternion.add(a,b) (Java), and quaternion_add(a,b) (C) isn't really that bad. On the other hand, with overloading on arguments, you could simply end up with add(a, b) in Java (if it supported functions), and a+b in C++ (since you can overload operators as well).
I guess some people like it a bit more explicit. Personally, I'm a bit schizophrenic about the issue. I like brevity, of course, but it can also make it really hard to understand other people's code (and in the case of C++, even my own). I think this last objection could be removed with the help of better tools, but currently I know of no such thing as a compile-time debugger for C++ templates, or a slower-but-smarter typechecker for languages using Hindley-Milner type-systems (ML) that can tell me what's really going on, or at least give me somewhat reasonable error-messages when something goes wrong, so I can screw things up on purpose to find out what's really happening.
I don't know what to do about "BufferedImageMediaStreamWatcherHandlerFactory", though. If it's really an abstract factory for creating handlers to watchers to buffered mediastreams of images, then it's really a well-chosen name, but I don't think that's a pretty common abstraction that would end up all over your code (and if it was, I'm sure you would come up with a shorter name). It's just like "assistant for the the chief packaging master of buillon dice" (or translated into norwegian: overbuljongterningpakkemesterassistent, (a well known song by Øystein Sunde))), is actually a very good descriptive job-title, but if you were working with him a lot, you would just end up calling him the packaging assistant.
The OOP-buzz started with SmallTalk (although Simula was the first programming language supporting OOP (and yes, that was before 1970)). Everything OO, but not OOP (OOD, OOA, OODB, etc) originated with OOP.
Classifying reality is only relevant in class-based models of OO-programming. And many people does not tout that as the main reason for using OO (myself included). And the reason for most programming languages not being purely OO, is because most programming language designers also have other goals (otherwise, we would all be programming in SmallTalk or Self).
OOP is for clean ways of reducing coupling, managing change, and allowing reuse in and between software projects. If you want to classify reality, you need a richer modelling language, such as e.g. logic, (or mathematics, depending on your viewpoint).
Whether EXPRESS falls into this role I don't know (never heard about it), but if it is designed for modelling, and not for execution, it isn't completely unlikely (although most currently existing modelling languages trade off generality somewhere, because their ultimate goal is to produce software, not model reality).
Sometimes the world is a strange place!
To say that sets can be constructed from classes is just a reformulation of saying that they can be formulated from other sets, and a property. So to me, it doesn't add any value. But I am not a set-theorist, and maybe classes really add something useful. Or maybe they are just a convenient notational device. Or maybe neither.
The current popular reformulation of sets (ZF-axioms) doesn't involve classes. I don't know what real mathematicians need classes for, but it's most likely something, otherwise they wouldn't be needed.
Subtracting sets (e.g) P\S doesn't involve any big problems. The problems shows only up if you involve negations of sets without a clearly defined universe of discourse. If you allow this universe to be the set of all sets, then you are in trouble. Because it could include such sets itself, and so on. It might be the case that classes were introduced just for this purpose, to allow people to do it anyway, but without destroying the foundation of mathematics, which is built on top of sets.
Yes, I don't like your definition of I. I agree that it is troublesome. The easy way out is to declare it meaningless (since you cannot define something in terms of itself (circular definitions)), or to reformulate it as an inductive definition. And in a typical formal system of notation (logic), you would be forced to do this choice.
Either way, the proof that all naturals are interesting, revolves around the non-formal definition of I. You can define it in a completely informal way (my way), in a way that is not meaningful (your way), in a way that is questionable (my reinterpretation of your way), and so on...
I don't think there is anything deep or fishy here. Circular definitions are certainly meaningless, but my reinterpretation clearly shows one of the deficiensies of the human brain. In an attempt to try to understand something that didn't make sense, I reformulated it in another way that perhaps could make sense (although highly doubtful), instead of pointing out the obvious fault that it was a circular definition. (And as most circular definitions of this kind, when trying to interpret it anyway, you would either reach everything N, or nothing (bottom)).
A much better alternative is to offer a standard extension language, such as Python, Tcl, ELK, SIOD, Guile, lua, or even (the horrors) Perl. Now, most anyone of these languages have a plugin architecture, so if for any reason, you need native code speed, it can be done by writing a WHATEVERLANGUAGE-plugin.
The difficulty of creating a plugin architecture yourself over dlopen, is that you will most likely do it wrong at first try. A little bit less wrong on the second try, and so on... But each minor change you make to the plugin-architecture will probably break almost everything. So it's better to hand the problem off to the scripting-language-implementors...
Fifteen months is a long time. You don't tell your emplyer that if you are already emplyed either. It would certainly not harm your resyme. If you've been working there for fifteen months, and decide to take a years vacation, or quit, you've certainly worked there long enough to get a good reference.
But just to clear up: B=P\S is not a definition of a set. It is a statement in logic, it can be either true or false.
The old definition of set's were equal to todays classes. I don't know why we need classes, but I'm sure real mathematicians use them for some sort of thing (real mathematicians don't worry much about foundations, only logicians (and thus computer scientists) do).
The meaning of a self-referential set involves a set with itself as a member. Such as "the set of all sets", "the set only having itself as member", or anything in between. Of course, "the set of all sets except itself" is equally troublesome, since the complement would be self-referential. (And in those days, the complement of a set really meant that, it was not taken with respect to another well-defined set, but to a universal set including every set).
Your definition of the set I (either a prime, or the smallest number not in I is however legal, as the property of being prime or being the smallest number not (already) in I), is certainly expressible in a formal system. It is almost comparable to a standard recursive definition, e.g. where you define a binary tree to be either an empty tree, or a node with two subtrees named "left" and "right". If you reformulate that definition as one defining the set of all binary trees it looks almost (but maybe not completely) as "weird". And upon inspection this definition of I is certainly simple enough. If you are used to inductive proofs, it is immediately obvious that I=N.
I will not delve deeply into set-theory here. But what you remember from your classes about a class versus a set is true. A class C is defined as: C = {x | x has property P }
On the other hand, with the use of Zermelo-Fraenkels axiom number 4 from standard ZF-set-theory, the following is a completely ok way to define a set: S = {x | (x is element of T) and (x has property P) }, whenever T is a well-defined set.
In both definitions above, it is of course important that the property P is something we can express in a formal language, otherwise it is impossible to even in theory tell wether something is part of a set (note that it is ok for P to be very hard to compute, but it should at least be possible to express P in a formal language).
In the barber paradox, you have the set of all people: P. Populations are usually finite, so this set can be listed by enumeration, and is thus well-defined. Then you have the set of all people shaving themselves: S. And the set of all people not shaving themselves P\S. And we have the set B of all people shaved by the barber. All of those sets are well-defined. Now, you introduce the assumption that B=P\S. This leads to a contradiction, thus the assumption is wrong, the barber cannot possibly shave everyone who doesn't shave themselves. It is not a paradox, it is a simple proof (reductio ad absurdum), and there is no need to involve heavy set-theoretic stuff.
On the other hand, in the "interesting numbers" theorem, we have the set N of naturals. We define a subset I of "interesting" numbers. The trouble with I is that the "interesting"-property is not something we can express in a formal language. Thus I is not a well-defined set. Wrongly, we continue developing the proof under the false assumption that I is well-defined. Since our intention is to prove that I=N, it is natural to assume the opposite (not I=N), and in this case the well-ordering property of N gives us that there is a least number n in N, but not in I. Given our completely unformal definition of "interesting" above, it seems perfectly ok to say that n is "interesting". But if n is "interesting" then it must be in I. This is again a contradictory result, and thus we must conclude that not not I=N, which most people who aren't anal intuitionists, agree to mean the same thing as I=N.
Another alternative is to offer to send a CD for a few bucks more, and let the rest of the readers use your website. That's probably the best for the readers.
On the other hand, I can't...
Yes, me too. But I am wondering if you mean that in the literal sense or not :-)
Today we have muPAD (generally the smartest, pretty friendly, but only somewhat free), maxima (which is usable, but hardly polished), yacas (which I know nothing about), and emacs calc (which is very user-friendly but also the dumbest). None of them (well, maybe muPAD) are close to becoming rivals to the above-mentioned systems in terms of either user-friendlyness or features.
(Of course, this is not special for computer algebra systems. We also need better DMBS (and related tools, such as form-generators, report-generators, etc...), office productivity apps, cad, gis, groupware, financial stuff, graphics, dtp, music, etc...)
Case in point:
On the other hand: STL's sort is:
Does STL sort bloat your program? Yes, if you use it lot's of places for lot's of different kinds of arguments. Is this bad? No, you would get that kind of bloat anyway, if you had to write each sort-routine individually. For most tasks, moderately bloated binaries are a better tradeoff than overly complex interfaces or slower code due to generality through function-pointers, boxing of values, etc...
Sure, well-written java is usually a little bit slower than well-written C, which is usually a little bit slower than well-written assembler. That doesn't mean that one should forever try to use assembler (or C). Just as important as speed for game-development is:
In all these three cases, Java will be able to help. The only thing that speaks agains java here, is it's lack of raw speed. But that isn't really true anymore. Java, by itself is already quite respecably fast. It is not as fast as C (unless you count some weird benchmarks probably written just to show that), but it's not too far below either.
Secondly, you don't need to optimize everything, only the time-critical pieces of your code. And for most gaming purpoces, the speed-critical parts are the drawing routines. Making that as fast as in C is pretty simple. You build a wrapper around openGL or some other graphics library, and use that from java. There you go...
And that is exactly what a java gaming platform would look like. It would be a collection of well-defined API's for accessing your hardware in a controlled, but efficient manner.
Is it really going to happen? Nobody knows just yet, but I wouldn't dismiss it right away. The idea is good, the question remains to be seen whether the API's will be equally good, and developers adopt them.
lines_of_code_added + 2 * lines_of_code_deleted + 0.9 * lines_of_code_changed -10 * needless_changes_or_additions+number_of_minutes_ex plaining_difficult_stuff_to_coworkers_needing_help + some_constant * amount_of_great_ideas_improving_the_design_of_the_ product + some_really_high_number * solving_some_really_tough_problems + some_reasonably_large_number * solving_some_moderately_hard_problems + some_pretty_low_number * solving_relatively_trivial_problems + some_large_constant * obscure_knowledge_of_esoteric_topics_helping_impro ve_the_design_of_domain_specific_code + some_other_large_constant * ability_to_write_clean_and_efficient_code_for_both _trivial_and_complex_programming_tasks + some_moderately_large_constant * not_having_a_gigantic_ego_and_be_willing_to_accept _other_peoples_solutions_when_they_are_better + another_large_constant * ability_to_understand_business_objectives_and_espe cially_the_needs_of_clients_and_apply_that_to_the_ task_at_hand + lots_of_other_factors_i_probably_have_forgotten