Whenever I have to register at some bullshit forum, I typically take the name RichardStallman. If it's taken, I use RMSMatthewStallman. Sometimes I wonder how many people think that they are talking to the real rimmisu.
>>10
If you're going to reply to a post, at least quote it. Otherwise your replies are meaningless and quite passive-aggressive.
Name:
Anonymous2010-07-28 9:05
Scalability:7/10; //I interpreted this as in relation to as inbuilt language constructs for concurrency?
Performance:7/10;
Ease of use:10/10;
verbosity:8/10;
void trimCodans(void)
{
int found = 0;
for (;;)
{
int i;
for (i = 0; i < codans.rows; i++)
{
if (codans.table[(i * codans.cols) + codans.emptyLeft] != CODAN_EMPTY)
{
found = 1;
break;
}
}
if (found) break;
else codans.emptyLeft++;
}
//TODO: check right
}
Scalability: 10/10
Performance: 10/10
Ease of use: 3/10
Verbosity: 2/10
C++
Scalability: 7/10
Performance: 9/10
Ease of use: 1/10
Verbosity: 4/10
Java
Scalability: 8/10
Performance: 7/10
Ease of use: 7/10
Verbosity: 5/10
Python
Scalability: 0/10
Performance: 0/10
Ease of use: 10/10
verbosity: 5/10
Is there a language out there with worse performance than CPython? Serious question. It's still my language of choice for all non-performance-critical scripts :(
>>17 nothing performs better than C
Meaningless statement.
Aside: For some reason a lot of C++ programs tend to show better performance than equivalent C programs. I am still trying to work out why that is. The claim is often that C++ can express more efficient algorithms for these cases more naturally than C can, but every time I see a comparison made the C source is not what I would write (and not as fast.)
Name:
Anonymous2010-07-28 14:36
>>19
Make a benchmark:
1. C++ code
2. C code
3. C code which directly emulates C++
4. C code compiled as C++ code.
>>19
That claim is usually made by people who don't really know C.
Name:
Anonymous2010-07-28 14:39
>>19
The vast majority of the time, this is because of function pointers. Compilers aren't smart enough to statically link or inline a call of a function pointer argument. The equivalent C++ code uses a template parameter instead, forcing the compiler to statically link or inline it.
This isn't because it's not possible to do this in C; it's just because it's easier and safer in C++ than in C, so people are more likely to do it. The usual example is qsort() vs std::sort(). This fails of course as an argument for C++, because it's relatively easy to write a macro version of qsort() that does the same thing. For example: http://www.corpit.ru/mjt/qsort.html
What we really need is a language that can do this automatically. You just take a function pointer like normal, and if profile data determines that the function indirection is a bottleneck, the compiler can just duplicate the function for each value of the argument and statically link and inline each version. Unfortunately, modern languages are heading in the opposite direction in terms of performance and optimization, so we might never see this happen :(
Name:
Anonymous2010-07-28 14:50
im not a expert, but isnt typecasting much faster, safer and wastes less memory then templates?
Scalability: able to deliver scalable, modern turnkey implementations to rise to user demand
Performance: provides real-time results for round-the-clock mission critical solutions
Ease of use: patented accessibility platform ensures ease of integration between static computer and dynamic human inputs
Verbosity: colour-coded CamelCase engine creates a platform designed to hold the most information in the least amount of space while still being extensible to meet developer needs
>>43
It's better than in python, because It doesn't have to be a special case in the parser and it works for most, if not all ,transitive binary relations
>>45
What's your point? That's like saying you can't write anything sizeable in python without using indentation.
I prefer not to have to remember some arbitrary precedence rules, you on the other hand do.
Besides, I'm not even sure what your intended use case for that example is
>>43 a <= b is not c in d
Checking with the precedence table at http://docs.python.org/reference/expressions.html, I'd argue that such a statement is ambiguous and therefore Scheme is better as it isn't able to express such a statement
>>48
So it does, my bad.
Although, while I'm bitching about python > 3 < {"bar" : "baz" } < "foo"
True
"Strongly" dynamic typed my ass. I don't care what you're view are on operator precedence, but surely that should be a type error
>>51
I'm disappointed that they didn't make comparison between vectors and scalars more useful. It's great for being expressive and readable, even in a language where it's mostly useless.
>>42
I see. So in a scale topping out at 10, giving something a rating of 10 does not actually mean nothing can be better than 10, even though, within that system, nothing can be better than 10?
>>43-48
For all the complaining people do about Lisp's parens, at least you don't have to refer to a goddamn precedence table to figure out what an expression does.
>>71
Because no one has any idea that multiplication is supposed to happen prior to addition, etc.
Most of the stuff in that table is entirely logical, the rest being obscure operators that you're usually unlikely to combine with others, and in any case you would use parentheses anyway, so that's a moot point.
In Lisp, you need the parentheses even in simple cases where algebraic notation would be entirely sufficient (e.g. equations like 3*x**2 + 4*x + y + 4 are extremely annoying and unwieldy), but personally I'm not really bothered by that in the average case - generally, C code will be just as punctuated as Lisp, just sometimes in different places. My complaint about Lisp is the lack of infix notation which makes many expressions much harder to read and comprehend.
You say "3 times x squared", not "times 3 squared x" -- any more than you would say "ate I a hamburger". Infix is natural and sensible.
>>72
Infix appears natural and simple because that's what you've been thought in school. What is simpler (+ 1 2 3 4 5 6 7 8 9) or 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9?
As for 3*x**2 + 4*x + y + 4, (+ (* 3 x x) (* x 4) y 4) is pretty readable to me. It's only confusing the first few days/week of looking at it. It becomes as natural as infix after you've used it for a week or so, moreso if you use a structured editing package like Paredit.
>>73 Infix appears natural and simple because that's what you've been thought in school.
I can still remember the look of disgust on my face when we were first introduced to BODMAS.
>>79
Simple enough (* 3 x x) becomes (* 3 (expt x 9)).
Please keep in mind that I usually break down into many lines and read by indentation instead of actually counting or matching parens, here's one of the most verbose ways to ident it(automatically of course):
(+ (* 3
(expt x 9))
(* x 4)
y
4)
I find this quite readable, however it is more verbose. As verbose as it may look, typing/indenting/editing/transforming this code around (with key chords or automatically) is very easy and effortless with a good editor. It's also easy on the eyes if you spend at a week or so writing Lisp and getting used to it. Just like order of precedence took a bit to get used to during elementary school for some people.
>>80
You can find it as readable as you want; that doesn't change the fact that anyone who has had any schooling at all will recognize standard operator precedence.
Lisp is not a mathematician's language, by any means. There's a good reason for that.
>>81 that doesn't change the fact that anyone who has had any schooling at all will recognize standard operator precedence.
You're joking right?
Find a random adult and give them a sample calculation, say "3+4/2*8-1" and I'd bet a good third of them will group left to right
>>81 Lisp is not a mathematician's language, by any means. There's a good reason for that.
Yes, because they have Computer Algebra packages that not only have infix arithmetic, but proper superscripting/subscripting, actual 2D matrices, that recognise the stupid way that 'x' composes when used for the cartesian product of more than 2 sets and all the other syntactic monstrosities that mathematicians have inflicted upon themselves over the centuries.
Name:
Anonymous2010-07-30 0:40
Lisp/Forth try to modify something as basic as order of operators.
C doesn't try such cryptic bullshit and uses sane, normal and easily readable syntax(C++ templates excluded).
>>85 Lisp/Forth try to modify something as basic as order of operators.
Is this the part where I point out that Lisp doesn't have operators C doesn't try such cryptic bullshit
lol
To all the folks talking about precedence of math operators: no fucking shit. We all know what they are.
Remember this all started with the following python expression:
a <= b is not c in d or e
What fucking math operators are in there? None. There is one equality operator there, except it has different precedence than in math (where it would generally have the highest precedence.)
And I've worked with python for years in industry, and many folks from many different libraries and frameworks really do write lines of code like that. Unnecessary parens are considered anti-zen-of-python. It's fucking bullshit.