The Daily WTF: Curious Perversions in Information Technology

xtremezone · 2009-05-15 Reply Admin

Rob:
Java isn't interpreted. There is no interpreter. Java is compiled to bytecode and then compiled to machine code dynamically by the JIT part of the VM. So it gets compiled twice.

The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.

2009-05-15 Reply Admin

[quote user=xtremezone]The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.[/quote]

What a tool. You don't even know an interpreter is.

xtremezone · 2009-05-15 Reply Admin

133tz0n3:
xtremezone:
The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.

What a tool. You don't even know an interpreter is.

You fail at pwning. You also fail at typing.

2009-05-15 Reply Admin

xtremezone:
The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.

Well, JIT-ed bytecode needs to be interpreted in order to be compiled in the sense that it needs to be "understood" and processed. But in that sense, C and assembly need to be "interpreted" too. In the more specific sense of "interpreted" we use in talking about program execution, an interpreter performs the instructions specified by the program. A JIT doesn't involve that kind of interpretation; if it did, a JIT would run the program while interpreting it, and then run the compiled version; but, obviously, a JIT doesn't require that you run every program twice.

xtremezone · 2009-05-15 Reply Admin

voyou:
xtremezone:
The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.

Well, JIT-ed bytecode needs to be interpreted in order to be compiled in the sense that it needs to be "understood" and processed. But in that sense, C and assembly need to be "interpreted" too. In the more specific sense of "interpreted" we use in talking about program execution, an interpreter performs the instructions specified by the program. A JIT doesn't involve that kind of interpretation; if it did, a JIT would run the program while interpreting it, and then run the compiled version; but, obviously, a JIT doesn't require that you run every program twice.

When the terminology for interpreters first came into play the game was very different. Java and other similar strategies have greatly blurred the lines.

Anyway, the difference is that a C/C++ program is "interpreted" and compiled once whereas Java byte-code is (AFAIK) interpreted and JIT compiled every time you run the program (on top of the original time by the developer). There's a performance penalty there at run-time, whereas for a C/C++ program, for example, that penalty is felt by the developers building it; usually not the end-user, and even if it is the end-user, it's a one time expense.

2009-05-16 Reply Admin

xtremezone:
voyou:
xtremezone:
The byte-code needs to be interpreted in order to be JIT compiled. ;) Unless the JVM just waves a magic wand? o_O It's obviously much faster than interpreting source code, but it still requires that interpretation step.

Well, JIT-ed bytecode needs to be interpreted in order to be compiled in the sense that it needs to be "understood" and processed. But in that sense, C and assembly need to be "interpreted" too. In the more specific sense of "interpreted" we use in talking about program execution, an interpreter performs the instructions specified by the program. A JIT doesn't involve that kind of interpretation; if it did, a JIT would run the program while interpreting it, and then run the compiled version; but, obviously, a JIT doesn't require that you run every program twice.
When the terminology for interpreters first came into play the game was very different. Java and other similar strategies have greatly blurred the lines.

Anyway, the difference is that a C/C++ program is "interpreted" and compiled once whereas Java byte-code is (AFAIK) interpreted and JIT compiled every time you run the program (on top of the original time by the developer). There's a performance penalty there at run-time, whereas for a C/C++ program, for example, that penalty is felt by the developers building it; usually not the end-user, and even if it is the end-user, it's a one time expense.

You're wrong, there is no interpreter. The terminology for what an interpreter is has been consistent for the best part of half a century. Interpreted programs are executed as the source - normally textual but also including other forms - is loaded. That's what an interpreter does: you wishing it was something else, so you could avoid being wrong, won't make it so.

Java byte-code is not interpreted. Beyond that there are a number of compilers that will render Java down to native executables - but nobody uses them because ... Java performance is indistinguishable from ASM/C/C++ performance in most cases because most applications involve much slower technologies such as disks, networks and databases; CPU and/or memory limitations are only the bottlenecks in a sub-set of applications, a subset that is shrinking every year.

2009-05-16 Reply Admin

Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.
The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.

What a bunch of tripe. It's motherfucking idiots like you that give programmers a bad name.

tgape · 2009-05-17 Reply Admin

Severity One:
Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

I too started programming in the early eighties. The only times I hung/crashed the first platform I really learned, I was POKEing around haphazardly. But, then the C64 had no protected memory, so that was kind of a hardware problem. Later on, I got access to Unix boxes and mainframes, and they were all rock-solid. Despite the fact I was then programming in C - the highly dangerous language you're complaining about - I never crashed the system on those. Out of hundreds of students sharing those systems, we generally only had one student-triggered OS crash per year.

The system instability you're complaining about is more appropriately attributed to Microsoft, for the most part. While they've mostly fixed their stability issues, they're still causing problems in other areas. According to court records, they've intentionally created platform incompatibilities for the specific purpose of having platform incompatibilities. That's the whole origin of C#, if I'm not mistaken.

Severity One:
Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?

Back in the beginning of this decade, I was maintaining an application which was performing poorly. I estimated to management that fixing the problem would take about 3 months of my time. They chose to upgrade the hardware, doubling the server cluster size, as it was cheaper. A year later, the workload had increased, and the system was again having performance problems. They quadrupled the size of the hardware - we had a fairly decent size server farm of Solaris boxes, so that was definitely more expensive, but they felt my time was better spent on other areas. Two years later, the hardware cost for upgrading to meet the expected needs of the next two years was over $1,000,000 US, and they approved my time to fix the application.

In two months (I'd had time to think about the exact implementation), I'd fixed the application performance issues, reducing the program run time from O(n^2) to O(nlogn), and thus decreased the load to the point where the original hardware would have still had enough capacity - despite the fact that two of those old servers had since died. (We didn't throw out the old hardware; we repurposed it.)

Scalability is still very important on the backend, as doubling the server size every time your 'n' increases by one is a losing game - eventually, the cost to double your server is prohibitive.

tgape · 2009-05-17 Reply Admin

Shakje:
What does compilation have to do with this? People are used to seeing slowish Java apps, I think some of that is perceived because Swing apps generally look dog [slow].

Agreed. Although, to be honest, I consider NetBeans to be one of the slow java apps I deal with. Sure, it can generally keep up with my typing and flipping between windows and stuff just fine. However, these are me bound, and as such, the last computer/software combo I've used which couldn't handle that was a Commodore 64 running GEOS. But when you get to things like performing CVS operations on the whole project, setting up the project, running tests, and especially starting up, it's crap. Give me vim and a command-line any day - vim's esoteric, but I've learned it already.

Shakje:
At the end of the day it's not how fast the language is but, as you rightly say, if it is "fast enough".

We seem to forget this far too much around here.

Shakje:
On the other hand if you have one stupid developer, he's less likely to do harm in your Java app.

If you only have one 'stupid developer', and you have at least one other developer, fire your 'stupid developer'. He will do more damage in any language than his pay is worth.

Of course, before one does this, it's probably worthwhile to do some checking on the amount of time the rest of the team spends fixing, kludging, or working around problems the 'stupid developer' creates, and just how productive the 'stupid developer' is. I've seen people who were described as "stupid developer"s have an effective work index, relative to the average group member, anywhere from about -20 hours/day to 12 hours/day. While you clearly want to get rid of the left end of that range, you also clearly want to keep the right end. However, you might want to send said developer to code legibility training...

(The preceding paragraph depends upon having an accurate method to measure it. This can be very difficult; we only managed to measure the worst case scenario after we got rid of the guy - but it was pretty clear he was an issue. Since then we learned a bit, but it's still never easy.)

tgape · 2009-05-17 Reply Admin

SomeCoder:
I guess it depends on what the system is supposed to do. If you are writing something that is to run on a Windows machine and mostly likely have to share resources with other programs being open at the same time, I'd rather you work a little slower and use the RAM more efficiently so I can still have some left over for other programs that I may be running at the same time.
On the other hand, if you are writing a system that is going to run in Unix and needs to crunch a lot of data very quickly, I see no reason to try and be efficient with memory.

WTFlyingF? Historically, I've seen a lot more dedicated-purpose Windows boxes than I have dedicated-purpose Unix boxes - despite the fact I'm a Unix admin, not a Windows admin.

In any event, I typically find that either system allocates new memory much quicker than it swaps in old memory. I also find the free-pool reuse capabilities of every program I've encountered to be pathetic - I believe this is inherently true, but I do not have a proof for it.

So, if you can guarantee that a program will entirely fit within memory, and there won't be other large-memory programs competing with it, you may get better performance without worrying about memory usage. That having been said, I've seen a lot of large-memory algorithms which like to move their large data pools around, and this fundamentally scales horribly.

For example, I've seen quite a few programs which read in an entire file into memory - say, for example, a 2M file. They then process the first line of the file, and then shift the rest of the file forward in memory, to clear off the first line. Repeat. If one rewrote the algorithm to read in a single line at a time, so it didn't have to shift the memory, assuming that the file is not just two lines long, it'll run faster. If the lines average less than 160 characters, it'll run a lot faster. Note that the programs that behave as I've described here are generally written in pointer-free languages, so they can't just simply shift the char pointer forward.

Severity One · 2009-05-18 Reply Admin

xtremezone:
I've heard Java zealots claim that in practice Java often needs to be tailored to a specific machine too. Write once, run everywhere isn't quite so clear cut in practice.

In that case, you've been listening to people who know crap about programming. Bear in mind that this site is dedicated to people who make stupid mistakes when writing programs, and this happens in all languages, including Java.

We've had exactly one case where an application behaved slightly differently between Windows and Solaris, and this was when we were load-testing a web service proxy/auditing tool that I'd written. We're still not clear whether it was a bug in the JVM, or a setting in the operating system. For the rest, there have been no cases of applications not working on another platform, other than silly mistakes like hard-coded paths or path separators.

You can, however, take C++ from one machine to another without much extra work if your team is aware of platform specifics and everybody writes platform independent code (and all libraries used are either platform independent or equivalent functionality is pulled from platform specific libraries for all supported platforms). It isn't like C++ needs to be completely rewritten in order to work on another machine. There's nothing platform specific about C++, the language. It's the compiler implementations and operating systems that bring the specifics. And that stuff can easily be wrapped up just like Java wraps it. Reusing stable and powerful platform independent frameworks can really save you a lot of work.

Begging your pardon, but what sort of frameworks are we talking about that will easily take an application that uses databases from, say, Windows to Linux? Let alone graphical applications; I've tried getting Qt applications to work on Solaris, and given up.

If you just do standard I/O and maybe CGI, you can write code that easily compiles on both Windows and Unix. Many years ago, I've written a PHP-like interpreter that did just that. But as soon as you want to do more (say, network sockets), you're out of luck.

In practice it usually isn't as convenient as Java, sure, but then again the end result is hopefully software that greatly outperforms the equivalent Java software and is that much more user-friendly for it. I hate waiting for computers to do things and therefore expect applications to perform as quickly as possible. Especially applications that I use a lot. Perhaps the way we use computers differs.

'Hopefully' indeed. But would you say that using a toolkit like Qt (because otherwise you'd have to totally rewrite your user interface code) is much more user-friendly than a Swing application? That's a novel way of looking at things.

The right tool for my jorb right now is ASP.NET. I never said to use C/C++ (or other native alternatives) for everything.

Hang on a second. You write applications that run in the CLR, and you are complaining about the JVM? WTF are you on about then? Happy happy that you can spend 'six months on an application' so it may run a bit faster, but in reality you're writing contact forms on web sites?

Oh my (insert favourite deity here).

I wonder what your machine specs are. I haven't used NetBeans in about a year or two, but when I used it it was nearly unusable on decent hardware (albeit, it ran MUCH better in Linux than Windows). I spent much of my Java classes in college wishing it had been written in a native language.

A Dell D620 laptop, with a T2300 Core Duo (not Core 2 Duo) CPU running at 1.66 GHz, and 2 GB of RAM, driving a screen in 1680x1050 resolution.

It's common knowledge that Java is slow. I don't need to prove it. Anybody that doesn't believe me can install it and find themselves a nice Java application to use. Obviously a zealot will deny this. And maybe the Java applications that you use aren't slow. I don't know. The ones I've used have been.

From all the comments I've seen on this site, this must be a contender for the most uninformed one. It used to be common knowledge that the sun revolved around earth, and that you tell somebody's character from the shape of his head.

'It is common knowledge' doesn't cut it. You'll have to come up with something better.

Slow is a relative term anyway. As somebody said earlier (maybe you, maybe not), on the backend you can throw hardware at it to make it perform adequately. Most users don't know what's happening in the backend and only experience the Java running on their own hardware. Even if the backend is fast because of lots of hardware, there are usually many many frontends that you don't have control over (and couldn't afford to anyway) that need to interface with the backend. If those are all written in Java, hardware might not be available to solve the problem.
By all means, if you can afford to make your Java applications perform well with hardware on the backend, go for Java. I don't care what you use on the backend as long as it performs well and works correctly. However, unless you're going to buy me an uber powerful gaming rig to use your frontend, write it in something less wasteful so it doesn't hog all my system's resources.

But I've never said that Java would be the solution for everything, and it obviously isn't. However, you, on the other hand, have pretty much claimed that Java is useless, purely based on the speed argument.

And even that I have my sincere doubts about. You've looked at old versions of Netbeans, you've written code in college on even older Java versions... things have moved ahead over the years.

I was pretty sceptical about Java, too, after my first experiences. But then I wrote my first application (using EJB, Java WebStart, Swing and what else), and I've never looked back since. It allows me to write better code.

I develop Web applications at j0rb (and don't use C++ for it). As I said, we develop with ASP.NET (and still maintain legacy code in ASP).

In which case, your argument about running time being more important than development time can pretty well be chucked in the rubbish bin, because the company you work for will have to make a profit, just like everybody else.

I never said to use C/C++/D/etc. for everything. However, there is absolutely a time to use it and IMHO the use for Java is a relatively small niche. Again, that's based on my personal experience running Java applications which obviously isn't like yours because you love it.

It gets the job done, and with less hassle than everything else I've tried. If it has to be big, multi-tiered, interfacing with a lot of systems, Java is (for me at least) the way to go. If it is simple and can be done quickly, I use Perl. And if I need to decode a binary file such as BER, I use C. It just so happens that most things I do involve talking to databases and multiple systems, and Java is just very good at that.

IMHO, the vague description the article gives doesn't give us enough information to make a technology decision. By the sound of it, the system will handle lots of data for an entire country and won't change much once written. To me, that sounds like a good candidate for native programs. I don't know that obviously. I know next to nothing about what this particular contracted company was being considered for. You don't know that Java was the right tool either though.

Somebody made the choice for Java, though. Given that it would run the public transport for an entire country, we're probably talking about a lot of nodes (in which case Windows boxes would mean a lot of licences), a lot of inter-node communications, interfacing with legacy systems, and a lot of databases. These are all things that Java is very good at. All the things it needs to be doing are limited by network and database speeds.

But given that you've probably never written an application that is seriously big, or constitutes an infrastructure, you probably cannot appreciate the advantages that a platform like Java (rather than a language like C++) has to offer under these circumstances.

2009-05-18 Reply Admin

What a dick.

xtremezone · 2009-05-19 Reply Admin

Severity One:
But as soon as you want to do more (say, network sockets), you're out of luck.

Actually, WinSock is basically Berkeley Sockets with a new name and a few minor differences (at least, from what I've heard and what I've done). It's very easy to wrap it up if you know you plan to be doing it. For example, in Windows, you have closesocket instead of close. You can probably use a simple macro to fix that problem,...

#ifndef WINDOWS
    #define closesocket close
#endif

...but even if you can't, it isn't all that complicated to get around it with the preprocessor.

Beej's Guide To Network Programming (arguably the best socket guide available on the Web) has a section explaining the minor differences.

GUI programming is surely one place where things get much more complicated to port (hell, even just writing a GUI application for a single platform can be a pain), but unfortunately some of those applications are the ones that benefit most from being native builds because workstation users like to use many of them all at the same time for extended periods of time (the exception being short utility programs which are fine written in interpreted or JIT compiled languages because you probably only use it for a minute now and then anyway).

X Windows has been ported to Windows, but I don't have any experience writing X software so I can't say what the porting concerns are. Obviously it's nice to keep a native look/feel, but that's something that Java frameworks don't seem to like to do by default anyway.

Severity One:
Hang on a second. You write applications that run in the CLR, and you are complaining about the JVM? WTF are you on about then? Happy happy that you can spend 'six months on an application' so it may run a bit faster, but in reality you're writing contact forms on web sites?
Oh my (insert favourite deity here).

I didn't get to choose the technology. :P In my experience, though, .NET applications (on Windows, at least) perform better than Java applications (though you must have missed it earlier where I said that ASP.NET has been performing poorly IMHO, so either we're doing something wrong or it suffers the same problems, even on Windows).

Severity One:
But given that you've probably never written an application that is seriously big, or constitutes an infrastructure, you probably cannot appreciate the advantages that a platform like Java (rather than a language like C++) has to offer under these circumstances.

You are correct. Maybe when I do my appreciation will change. :P Maybe not. Speed is really only one of my problems with Java. I'm also not a fan of the language (probably just because I'm too used to C/C++, and they are quite different) and I'm also not a fan of Java formatting styles, which makes pretty much any code not written by me illegible (which can honestly be said for most languages, as most people don't care too much about style, but I digress...).

2009-05-19 Reply Admin

xtremezone:
Speed is really only one of my problems with Java.

And it really is not a problem. Yes, most of the time Java is slower than native code produced by a good compiler, and if you need hard performance guarantees, you write C or Assembly anyway. But for the vast majority of apps, the speed difference doesn't matter, since most of the time they're waiting for some I/O to happen, so you can write them in Java, C#, Python, Erlang, Haskell, C, Ruby, whatever is the best compromise between your taste and the problem's demands.

I'm also not a fan of the language (probably just because I'm too used to C/C++, and they are quite different)

So you don't like the language because it's different? You must really love your work with ASP.Net then. Or is it rather that you don't like Java because it's not different enough?

and I'm also not a fan of Java formatting styles, which makes pretty much any code not written by me illegible

What styles are you referring to? Will we have another flamewar about the one true brace style? Or don't you like upper case class names and lower case method names? camelCase? Long variable names?

(which can honestly be said for most languages, as most people don't care too much about style, but I digress...).

Now that makes me suspect that others may find code written by you illegible. I may err, but "everybody but me does it horribly wrong" is usually a good indicator.

antred · 2009-05-20 Reply Admin

xtremezone:
For example, in Windows, you have closesocket instead of close. You can probably use a simple macro to fix that problem,...
#ifndef WINDOWS
    #define closesocket close
#endif
...but even if you can't, it isn't all that complicated to get around it with the preprocessor.

Mucking around with the preprocessor to solve this is probably the worst solution you could possibly come up with. Just hide the WINSOCK/Berkely sockets API underneath a wrapper and have that wrapper call either the Windows or the UNIX variant of the function based on whether you're compiling on Windows or UNIX. In C++, the preprocessor is best left alone unless there's a very good reason to use it.

xtremezone · 2009-05-20 Reply Admin

antred:
Mucking around with the preprocessor to solve this is probably the worst solution you could possibly come up with. Just hide the WINSOCK/Berkely sockets API underneath a wrapper and have that wrapper call either the Windows or the UNIX variant of the function based on whether you're compiling on Windows or UNIX. In C++, the preprocessor is best left alone unless there's a very good reason to use it.

One way or another you need the preprocessor to do it (even if you hide it in a wrapper). You don't need to define a macro for it, which is what I was getting at with "...but even if you can't, it isn't all that complicated to get around it with the preprocessor." You could just simply call the appropriate routine for each given platform. Still need the preprocessor though. ;) The processor is good. It's macros that can be bad.

void my_close_socket(int s)
{
#ifdef WINDOWS
    closesocket(s);
#else
    close(s);
#endif
}

xtremezone · 2009-05-20 Reply Admin

Single User:
But for the vast majority of apps, the speed difference doesn't matter, since most of the time they're waiting for some I/O to happen, so you can write them in Java, C#, Python, Erlang, Haskell, C, Ruby, whatever is the best compromise between your taste and the problem's demands.

Most of them are doing many things at once, one of them being waiting for I/O, but others being responding to I/O and other tasks that the application does. Few applications these days are single-task applications. There is usually something being done, even when waiting for I/O, except for single-task applications (and I don't use many of those outside of the command-line).

Single User:
So you don't like the language because it's different? You must really love your work with ASP.Net then. Or is it rather that you don't like Java because it's not different enough?

C# isn't as different as Java is. It even supports more syntactic sugar than C++ does, making the code cleaner at times. Java for the most part supports less, making the code more verbose, at least IMHO. Obviously, Visual Basic is way worse than Java...

Single User:
What styles are you referring to? Will we have another flamewar about the one true brace style?

That's my main gripe.

Single User:
Now that makes me suspect that others may find code written by you illegible. I may err, but "everybody but me does it horribly wrong" is usually a good indicator.

/*
 * Double lines are single lines emphasized by Alex... >_>
 */
#include <cstdlib>
#include <iostream>
void func1(void);
void func2(int);
int main(int argc, char *argv[])
{
if(argc > 1)
{
std::cout << "Args: " << argv[1];
    <span style="color:blue;">for</span>(<span style="color:blue;">int</span> i=2; i<argc; i++)
        std::cout << ' ' << argc[i];

    std::cout << std::endl;
}

func1();
func2(argc - 1);

<span style="color:blue;">return</span> EXIT_SUCCESS;

}
void func1(void)
{
std::cout << "This program will measure your personality based on "
"how demanding you are." << std::endl;
}
void func2(const int argc)
{
if(argc == 0)
std::cout << "Pushover." << std::endl;
else if(argc < 3)
std::cout << "We can work with that." << std::endl;
else if(argc < 5)
std::cout << "Little pushy, aren't we..." << std::endl;
else
std::cout << "Fuck. That. Shit. Do it yourself." << std::endl;
}

Tabs to indent (I usually use spaces on the Web because of the default behavior of the tab key and the uncertainty for how a particular Web site will handle them), spaces to line up.

2009-05-20 Reply Admin

xtremezone:
Obviously, Visual Basic is way worse than Java...

:D

Single User:
What styles are you referring to? Will we have another flamewar about the one true brace style?
That's my main gripe.
Single User:
Now that makes me suspect that others may find code written by you illegible. I may err, but "everybody but me does it horribly wrong" is usually a good indicator.
[snip code] Tabs to indent (I usually use spaces on the Web because of the default behavior of the tab key and the uncertainty for how a particular Web site will handle them), spaces to line up.

Okay, if that's your usual coding style, the indicator misfired :) I prefer the other brace style, but I'm not religious about it. I like braces around if-branches even if they're a single statement, but I can bear their absence. Tabs, however, are pure, unadulterated evil.

antred · 2009-05-21 Reply Admin

Single User:
Tabs, however, are pure, unadulterated evil.

No, tabs are the only correct way to indent. Let the space fools rot in hell. :p

xtremezone · 2009-05-21 Reply Admin

Single User:
Tabs, however, are pure, unadulterated evil.

What tabs do is allow the user to configure their editor to display indentation however they want. You can set them to 2, 3, 4, 8, 32, etc., spaces and all properly indented code should look right (to you, at least...). With spaces, everybody is stuck with the original programmer's preference, which may be OK or might be horrible.

The only problem with tabs is that they don't line up well with single-space character data. Therefore, tabs are best for indentation, but spaces are best for lining things up.

For example, with [--] representing a tab character and spaces representing spaces, this is how func1 and func2 from the above code would be intended:

void func1(void)
{
[--]std::cout << "This program will measure your personality based on "
[--]             "how demanding you are." << std::endl;
}

void func2(const int argc)
{
[--]if(argc == 0)
[--][--]std::cout << "Pushover." << std::endl;
[--]else if(argc < 3)
[--][--]std::cout << "We can work with that." << std::endl;
[--]else if(argc < 5)
[--][--]std::cout << "Little pushy, aren't we..." << std::endl;
[--]else
[--][--]std::cout << "Fuck. That. Shit. Do it yourself." << std::endl;
}

That should look right no matter how you have tabs configured in your editor.

I find that using spaces for indentation makes me crazy. I never know when I'm going to skip one character or 4 and need to pay extra attention and it slows me down. Tabs are also better supported (you might not be able to configure how many spaces wide they are, but they'll work in pretty much any text editor whereas spaces require a ton of extra typing in editors that don't support smart indentation).

2009-05-21 Reply Admin

xtremezone:
Single User:
Tabs, however, are pure, unadulterated evil.
What tabs do is allow the user to configure their editor to display indentation however they want. You can set them to 2, 3, 4, 8, 32, etc., spaces and all properly indented code should look right (to you, at least...).

Unfortunately, many people don't indent properly, but mix tabs and spaces. That doesn't look right if your tab setting is different from theirs.

The only problem with tabs is that they don't line up well with single-space character data. Therefore, tabs are best for indentation, but spaces are best for lining things up.

You've never programmed in Haskell or Python, have you? Tabs can do worse things than make the code look funny there.

That being said, the above remark may not have been made in absolute earnest.

xtremezone · 2009-05-22 Reply Admin

Single User:
Unfortunately, many people don't indent properly, but mix tabs and spaces. That doesn't look right if your tab setting is different from theirs.

If a guy can't even handle proper indentation then you better get him the fsck away from teh c0d3z! :P

Single User:
You've never programmed in Haskell or Python, have you? Tabs can do worse things than make the code look funny there.
That being said, the above remark may not have been made in absolute earnest.

Don't you have to indent with tabs in Python? :P (I've never actually learned it before... Maybe I will now... :P)

2009-05-22 Reply Admin

xtremezone:
Single User:
Unfortunately, many people don't indent properly, but mix tabs and spaces. That doesn't look right if your tab setting is different from theirs.
If a guy can't even handle proper indentation then you better get him the fsck away from teh c0d3z! :P

If only I could...

Don't you have to indent with tabs in Python? :P (I've never actually learned it before... Maybe I will now... :P)

No, the preferred way is spaces:

Guido van Rossum:

Indentation

Use 4 spaces per indentation level.

For really old code that you don't want to mess up, you can continue to
use 8-space tabs.

Tabs or Spaces?

Never mix tabs and spaces.

The most popular way of indenting Python is with spaces only.  The
second-most popular way is with tabs only.  Code indented with a mixture
of tabs and spaces should be converted to using spaces exclusively.  When
invoking the Python command line interpreter with the -t option, it issues
warnings about code that illegally mixes tabs and spaces.  When using -tt
these warnings become errors.  These options are highly recommended!

For new projects, spaces-only are strongly recommended over tabs.  Most
editors have features that make this easy to do.

antred · 2009-06-01 Reply Admin

Single User:
You've never programmed in Haskell or Python, have you? Tabs can do worse things than make the code look funny there.

I code in Python quite a bit, and tabs for indenting work JUST FINE in Python. :)

antred · 2009-06-01 Reply Admin

Advising against the use of tabs for indenting on the grounds that you might end up mixing them with spaces is akin to advising against the use of pointers because you might end up trying to dereference a null pointer.

Anyone who mixes spaces and tabs is a fool. Use tabs the RIGHT WAY (i.e. tabs to indent, spaces to align ... if you absolutely must align things), and tabs beat spaces hands down because that way you're not forcing your personal tab-width preference on everybody else.

The fact that some crappy editors do not handle tabs correctly is NOT a reason to be a space-indenting fascist scumbag. :P

Ilya Ehrenburg · 2009-06-01 Reply Admin

antred:
Single User:
You've never programmed in Haskell or Python, have you? Tabs can do worse things than make the code look funny there.

I code in Python quite a bit, and tabs for indenting work JUST FINE in Python. :)

Sure, just don't mix tabs and spaces. If you're maintaining space-indented code, don't use any tabs; if you're maintaining tab-indented code, don't indent with spaces. If you're maintaining mixed-indented code, isn't there such a thing as justifiable homicide?

2009-09-24 Reply Admin

That is odd because memory allocation and deallocation is 5-10 times faster than C or C++ and a good chunk of nearly any programs execution time is spent in these two tasks.

2009-09-24 Reply Admin

[quote] I'm not sure where you would want to pass by value in Java... [/bold]

Are you serious?

Java uses pass by value and only pass by value.

What Java call references are nothing more than implicit pointers, and once more, they are only passed by value.

The ignorance on this thread is astounding.

2009-09-24 Reply Admin

Franz Kafka:
Jim S.:
That would be jake.
And for the comments about pass by reference vs. pass by value:

Java passes everything by value. End of story.

Explanation in mind-numbing detail can be found here

This is true, however the value is an object ref, so it behaves much like pass by ref.

Only if the object is mutable! Geez, it is always jackasses without the first clue about Java that rail against it.

2009-09-24 Reply Admin

ell0bo:
Anon:
Fedaykin:
What "special servers" and "special software" do you think is required to run Java?

Well, the Java Runtime Environment and Java Virtual Machine come to mind as special software. C++ applications don't require either of those to run.

The reality is that Java remains to this day far slower than an application that gets compiled to native code. Whether or not that matters depends on the specific case - generally the additional memory usage and startup time don't matter in long-running environments where memory is plentiful.

But suggesting that Java is lighter weight or faster than a well-written native application is ludicrous at best.

This reminds me of a project from college. I had to design an AI to trade stocks. I wrote the beta in C++, but then so my team could more easily work with me I rewrote the code in Java. It wasn't running very fast, so and I realized I could speed it up if I ran multiple threads. Well, this would be true if Java didn't go from a slight memory hog to a devourer of all memory as soon as you start forking off processes. My prof told me no one ever managed to kill the server before, I was kinda proud (and I had the spawn limit set to only 4 threads. When we got the proof of concept working, I rewrote it in C++, and it brought a tear to my eye.

Java threads do not fork processes.

2009-09-24 Reply Admin

xtremezone:
Severity One:
Now I know you're trolling, but that doesn't give you a right to become downright offensive. So I'm a lazy programmer because I prefer not to waste time hunting obscure bugs that have to do with the fact that applications that do not run in a virtual machine have a tendency not to have all the bounds checking and security that a virtual machine offers?
Let me put it differently. When I started programming, which would have been in the early eighties, it wasn't just easy to completely hang/crash your computer whilst programming, it was in fact expected. You'd have to switch off your computer, switch it on again (which luckily took mere seconds) and reload your program from cassette tape.

Between then and now I've worked with Z80 assembler, 8088 assembler, 68000 assembler, several flavours of BASIC, (Turbo) Pascal, C on MS/DOS, C on the Amiga, C on Unix, C++ on Unix, Perl, Bourne Shell and a bunch of others that aren't worth mentioning. And Java, of course.

There's no way that I'll ever go back to an environment where I have to spend time on things that a computer could do for me, like all the things a JVM does for me. I've got better things to do.
I prefer to know what I'm doing when I'm programming as opposed to just throwing code at a compiler/run-time until it works. However, it's completely possible to implement bounds-checked types in C++.

I don't find myself getting caught by those kinds of bugs very often. I find it's relatively easy to track them down. I'm sure you're aware that debuggers and stack traces exist for native programs...

As for security, I'm not sure if you mean system security or application security, but operating systems are fully capable of handling system security (i.e., what memory addresses and/or resources your program can access) and I don't really see a difference between application security in C++ and Java applications (with the possible exception of buffer overruns, etc., in poorly written native code).

Severity One:
And abstraction, yes, that's important too. Try writing an application on a Windows system that you test with a MySQL database, and then port it to Solaris with Oracle. If you're using something like Hibernate to abstract the database engine, you don't even need to change your SQL queries and recompile.
Absolutely. Abstraction is a good thing. There's nothing preventing abstraction from being written into C++ though. The reason C++'s standard library is so lacking is mostly because of its age. There are libraries and frameworks to fill in the gaps. Boost has a ton of functionality, though I'm not sure what exists for data layer abstraction.
Severity One:
Your point keeps coming back that CPU time is more important than the time you spend developing. In other words, the computer is more expensive than you are. It's not something I would be particularly proud of, but then again I get paid rather well for programming in Java, so what do I know?
No, the time I spend USING is more important than the time I spend developing and it's related to CPU time. I don't care if it takes me 6 months to develop an application if it does what I need efficiently for the next 3 years.
Time adds up quickly. I don't know about you, but if I could somehow count the time wasted on slow Java applications it would probably amount to a lot of wasted time.

And development time is directly affected by CPU time as well. You can only test an application's functionality as quickly as it can run. So if it takes more time to run then it will take you more time to test.

Maybe you need Java to hold your hand, but I don't. There is absolutely a time to use RAD tools and interpreted programs can be useful to get something simple done quickly, but personally for something that myself or others will be using a lot, I think it's worth the development time to build an efficient native program (even if you decide to prototype it in Java first).

You are funny, I guess you didn't know that memory allocation and deallocation is considerably faster in Java.

There are many java programs that beat the living snot out of C and C++, and vice versa. Your ignorance does not change that.

2009-09-24 Reply Admin

antred:
Advising against the use of tabs for indenting on the grounds that you might end up mixing them with spaces is akin to advising against the use of pointers because you might end up trying to dereference a null pointer.
Anyone who mixes spaces and tabs is a fool. Use tabs the RIGHT WAY (i.e. tabs to indent, spaces to align ... if you absolutely must align things), and tabs beat spaces hands down because that way you're not forcing your personal tab-width preference on everybody else.

The fact that some crappy editors do not handle tabs correctly is NOT a reason to be a space-indenting fascist scumbag. :P

You must not know Python. Mixing spaces and tabs will cause your program to crash. Whitespace matters a lot in Python.

2009-10-10 Reply Admin

If you think javas slow or hard to maintain, it means your not competent in it.

2024-01-28 Reply Admin

Забота о недвижимости - это забота о спокойствии. Утепление наружных стен - это не только стильный внешний вид, но и обеспечение тепла в вашем удобном уголке. Наша бригада, группа специалистов, предлагаем вам переделать ваш дом в идеальное жилище. Наши дизайнерские решения - это не просто утепление, это творческий процесс с каждым строительны

2024-01-30

Comment held for moderation.

Garold Rafa · 2024-08-12 Reply Admin

thanks for info

Addendum 2024-08-12 03:40: Navigating the vast array of casinos and slot games in Australia can be overwhelming, but website simplifies the process with its well-organized listings. This site offers a thorough guide to the best casinos across the country, including their most engaging slot games. From high-stakes tables to casual play, the site covers all types of gaming preferences and provides valuable information about bonuses and promotions. If you're looking for a reliable resource to help you discover premier gambling options, this site is definitely worth checking out.

Java is Slow!

Leave a comment on “Java is Slow!”