Is Java the only practical choice for webdev?

All other languages are either not compiled languages with static typechecking or have too few eligible users.  C# would also be an option if it wasn't Windows-only.

>>38
COBOL ON COGS

http://www.coboloncogs.org/INDEX.HTM

>>9
you get to use javascript

>>39
>>40
And this is why I come to proggles

>>43
For people who don't understand the implications of the things they link to?

>>39
Do you really need a bullet point from a MIT slide, typeset in comic sans, to tell you that finite bit strings are countable?

>>45
Look at >>40 you idiot.

>>46
Look at >>40 yourself. Finite bit strings are countable, and none of the search results refute that.

>>47
No shit. But they are also uncountable.

>>48
Your dumb.

>>48

You are assuming
U=uncountable A=countable.

In fact, U=all possible sets A=countable A`=uncountable.

>>49
Eh? Google refutted your dumbass statement. Now get lost you no talent programming bitch.

>>49
And just for the record, the word is "You're". Man, I swear, your grammar is as dismal as your progamming.

>>48
His dumb.

>>48
Finite bit strings are both countable and uncountable?

Could you please explain what you think a finite bit string is?

>>53
That made no sense. Again, your grammar is as dismal as your programming.

>>54
Tell me what you do for a living because I need a good laugh.

>>47,53-55
YHBTpoorly

Also, XHBT: http://www.formspring.me/Cairnarvon/q/321020146124588091

>>57
Go scrub another toilet bitch.

For a moment it looked like we were on the verge of interesting discussion. Good thing you managed to avert that, >>58-kun.

>>59
Go mix up "your" with "you're" as you continue to make idiotic technical statementss.

>>46,48,51,52,55,56,58,60
Please, I can take no more. You had your fun. IHBT

Let's get back to discussing why static typing won't save you from everything, and why the set of errors you might avoid that dynamic typing don't save you from isn't that big.

>>61
No. Let's get back to discussing why you mix up "your" with "you're".

>>39
comic sans
I can't take this seriously.

>>61
Static typing, assert() and ENTERPRISE GRADE getters and setters are all you need for maximum type safety.

Now fuck off, ``faggot".

>>64
Now, this is more like it.

>>64
Saying you need static typing for type safety is tautological.
Static typing and ``type safety'' go from merely pointless to actively harmful when you interact with code other people (including past you) have written; it offers no real advantages and requires you to spend more time reading documentation and useless type signatures. Duck typing offers great flexibility and all the safety that's actually relevant.

The set of all finite length bit strings can be enumerated as folows:

*the empty string*
0
1
00
01
10
11
000
001
010
011
100
101
110
111
0000
0001
...

So there is a one to one correspondence between the set of all natural numbers and the set of all finite length bit strings.

But the set of all infinite length bit strings is uncountable, and has the same cardinality as the set of all subsets of the set of all natural numbers. The correspondence between an infinite bit string and a subset of the natural numbers can be established as follows:

Suppose < b_n > is an infinite length bit string, where b_i is the ith bit. Then < b_n > corresponds to a subset of the natural numbers, A, where is is defined as:

A natural number n is in A if and only if b_n is 1, and n is not in A if and only if b_n is 0.

The infinite length bit string < b_n > can be thought of as a look up table for membership function of A.

static typing is fucking shit. only faggots and queers use it.

>>66
I agree with you when people use types that promise that the type must store certain fields within itself. There is no way to know that the data types will always contain those fields in the future. Some implementations of the data type might delagate storage of the fields to other data types, and still be able to provide the functionality required for the using code. The only difference is that it might take a different size in memory, or it might require the usage of virtual functions to invoke the interface it provides. So this is a big deal in a language like seeples, but it should never matter in languages like Java. In an environment like that, all methods are virtual and it isn't possible to explicitly allocate an object inside of an array, or on the stack, or in a byte buffer, although you can use encodings and then instantiate the object from the encoding.

But I think static typing of the interfaces is useful for keeping track of what is going on, and what things. By looking at the interface an object implemnts, and looking up the documentation of the interface, you then know what you can do with this object. It is easy to lose track of what is what and what you can do with what in a large project using a dynamically typed langauge, and if there are no comments that indicate what the types actually are.

>>69
why does the entire language need to be dynamically typed? just look at lisp, you can make certain things "staticky" by using an OOP library

And the special olympics of computer science continues...

>>71
Kodak-san, I don't think the special olympics of computer science will ever stop.

>>71
go scrub another undefined behaviour you mental toilet

By looking at the interface an object implemnts, and looking up the documentation of the interface, you then know what you can do with this object.
Yes, it's a good idea to separate the interface from implementation, and only expose a limited set of procedures that can be called. But you don't need manifest typing for that.

A class definition is one way to both minimally document the interface of a module and give its use some restrictions. But if the interface returns an int, and only the documentation specifies which integer values are allowed, then static typing doesn't save you from returning nonsensical values.

>>74
Using ints for return values is like using PHP for web development.

>>75
I'm sure returning an instance of java.util.Posets.RelativeOrdering is better. You could use it like this:

public static Object[] sortTuple(Object o1, Object o2) {
    java.util.Posets.RelativeOrdering ro = java.util.Comparator(o1, o2);
    if (ro == java.util.Posets.RelativeOrderingConstants.Equal) {
        return {o1, o2}; /* Stable sort */
    } else if (ro == java.util.Posets.RelativeOrderingConstants.GreaterThan) {
        return {o2, o1};
    } else if (ro == java.util.Posets.RelativeOrderingConstants.LessThan) {
        return {o1, o2};
    }
}

SO BEAUTIFUL

Returning ints to signify partial order is an established practice and perfectly acceptable. Wrapping it in another type (for ``clarity'') is ENTERPRISE over-engineering, and doesn't even solve the problem mentioned.
Type systems aren't the answer here; what's needed is a powerful way to make arbitrary invariants explicit, but as far as I know, no general-purpose programming language has the ability to do that at this point (SQL constraints come closest, I guess).

The reason for that is that it isn't actually a problem, because programmers (even Java programmers) can be expected to have a vague idea of what they're doing. It's unnecessary for broadly the same reason static typing is: it attempts to solve a non-problem.
The difference with static typing is that it would actually succeed.

>public static void

>>76
A few suggestions for improvements:

1. That probably doesn't emit a warning if you forget to check any of the return values, in GCC you can use switch...case with enums (but those are ints so you might be getting some other return value), and in GHC you can use pattern matching (this is optimal).

2. Names are too Enterprise, they should be shortened.  In GHC you have just data Ordering = LT | EQ | GT.

>>78
OH GOD, I-I'M CUMMING, UGGGNNN PREMATURE OPTIMIZATION!!!

>>78
Not just GHC, but Haskell in general. The great thing about it is that the type system can just replace those names with arbitrary ints or whatever the fastest way of doing it on any particular platform is.