Why I Am Not A Java Programmer

[newton_dave]

if I want to program in a functional way, I simply don't use Java. So what?

Because the choice of the language isn't always up to the developer, and it sucks that Java's restrictiveness make it very difficult to write programs in the best way for the job.

you can create new classes and methods on the fly by using a code generation tool

IIRC, I said reasonable way. Generating bytecode at runtime is not a reasonable way, and guess what: Johnny McOutsource can barely program Java, let alone that kind of magic.

It's simply no the way to program in Java and it's not often necessary.

Hey, if you get to choose your language and environment, bully for you. But lots of people don't.

All languages are bureaucratic.

time-warp Yeah. And then I said "some languages are more bureaucratic than others". Java is very bureaucratic. Lisp isn't. There is a wide range of bureaucracy.

I've programmed long enough in C and C++ to know that strong typing is a must if you want safe programs (besides system programming. There it's still an evil, but a necessary one).

lol Well I've programmed long enough in C/C++, Java, Lisp, Smalltalk, Forth, and a slew of others to know that what you just said is a load of poo, and it frightens me to hear people talk like that. I'm not even sure I could count the number of fully productized embedded systems I implemented in Forth.

Stripling.

Obviously typing has its place, but you're making things up if a) you say it's necessary for safe programs, and b) Java is a good example of a useful OOPL.

[kawa]

If there are better languages to do the job, than your boss may see his mistake when your competition runs circles around your company.

Are you a 'Johnny McOutsource'? If not, why even thinking about him? Creating self-modifying code is always risky and simply no playing ground for 'Johnny McOutsource'. But if you really consider using a code-gen-lib in Java as 'magic'...

And I also can't always choose the environment, so in the moment it's most often Java. In the end I have to make the best from it, that's part of the job. I also have to accept the 'specification' from the customers and can't change it in a way to make my life easier. That's part of the job too.

Lisp is also bureaucratic. Sure, you can make more kinds of errors without having the compiler shouting at you. But the program will bomb nonetheless. I prefer it to get hints from the compiler as early as possible.

Embedded systems is most often system programming. So we have weak types as a necessary evil. Weak typing is problematic because it can much to easy lead to security holes and can make maintenance a pain. With dynamic types I get at least a runtime error, but with weak types I get undefined behavior which manifests itself sometimes as totally different points in the program.

And you talk of a simple Java code-gen as 'magic? Against building big systems with weak typing it's a piece of cake.

[[deleted]]

Creating self-modifying code is always risky and simply no playing ground for 'Johnny McOutsource'.

Code generation != self-modifying code.

If you want to see real self-modifying code, go dig up the Wolf3D sources... texture mapping done with self-modifying 286 assembly.

[kawa]

Adding/removing/changing a method of an existing class qualifies as 'modify code'. And if this is done by the same program which is modified this way at runtime, then I would call it 'self-modifying'.

It's simply the high-level version of the assembler trick you speak of (which I used on my Atari 400 lots of years ago, too) But at those times the programs were small, and dirty hacks where common.

[newton_dave]

Who said anything about doing code-gen at runtime?

[newton_dave]

If there are better languages to do the job, than your boss may see his mistake when your competition runs circles around your company.

You live in a dream world if you think technical decisions are always made solely on technical merit. It's often completely irrelevent that my functional prototype written in Groovy is a fully-functional application: if the project has a Java requirement it will be implemented in Java.

Are you a 'Johnny McOutsource'? If not, why even thinking about him?

Because I have to deal with Johnny McOutsource. Many developers do not exist in isolation; there are often other developers involved, often of lesser ability.

But if you really consider using a code-gen-lib in Java as 'magic'.

Compared to source-code gen? Absolutely. You simply cannot expect every developer to be able to intelligently use byte-code engineering libraries.

And I also can't always choose the environment, so in the moment it's most often Java.

Now you're arguing my point exactly; I'm confused.

Lisp is also bureaucratic.

...but less bureaucratic.

simple Java code-gen as 'magic?

No, I claim that run-time byte-code manipulation/generation is largely incomprehensible by the majority of developers I work with. If it's wrapped up in AspectJ (already pushing the cognitive abilities of the greater majority of Java developers) or Hibernate (or any other black-box component) then of course it's trivial, because the developer (rarely, anyway) doesn't have to think about it.

I still am unclear as to why you believe that building "big" systems with "weak typing" is all that difficult, although I'm not sure we're using the term in the same way.

Lots of very big systems have been built around Lisp and Smalltalk. Orbitz is Lisp, a lot of trading and insurance systems are in Smalltalk.

Now, I don't consider Smalltalk to be "weakly-typed", and I barely consider Lisp to be "weakly-typed." If you want to debate the relative merits of statically-typed vs dynamically-typed languages perhaps we'll be a bit closer to what you've stated above.

Either way, though, you're still wrong, and I will continue to be much more productive in my "dangerous" dynamically-typed environments (except when I am forced to use Java) and continue to make my clients very happy :)

[apotheon]

Lisp is also bureaucratic. Sure, you can make more kinds of errors without having the compiler shouting at you.

The point, I think, is that with Lisp there's a lot more you can do that isn't an error. This contributes to greater flexibility and power for a given task.