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.
People who've only had experience with Java and Cocktothorpe should not feel qualified to make any pronouncements on the merits and demerits of static versus dynamic typing.
The only realistic languages for web development are Python and Ruby.
>>3
Scala is easy enough to learn if you have experience in Java. Also you can use all your Java codebase in Scala projects.
Haskell is MUCH harder (so hard that i quit when trying to learn it, by lack of real motivation i guess, or maybe was all that time working on Burger King)
>>5 Having a program fail at runtime because of something a compiled language would have caught is not acceptable for anything.
This is what Java users really believe.
Static typing confuses syntax and semantics.
What's the point of being forced to implement java.lang.Comparator and write a compareTo method just so I can if that method can return any int, even if it violates reflexivity, anti-symmetry, or transitivity? What ``safety'' is actually gained?
Fucking nothing. All that you've gained is verbosity and unnecessary hassle. And a lack of flexibility that required the additional creation of java.util.Comparator.
The fact that nearly every ``statically'' typed language feels the need to poorly reinvent dynamic typing through ``generics'' shows what a sham it really is.
Name:
Anonymous2012-04-27 19:29
>>14
Don't care about Java. It doesn't represent the end-all be-all of static typing. Weak typing is better than dynamic typing, but only because dynamic typing is the absolute worst system to ever be invented.
>>17 if that method can return any int, even if it violates reflexivity, anti-symmetry, or transitivity
All data ultimately resolves to a number. That is the nature of information. What ``safety'' is actually gained?
You will have to go out of your way to do work with data that have been defined as different data types as the compiler would normally warn the user about it. All that you've gained is verbosity and unnecessary hassle.
You should design what data you'll use during the system design phase. Writing code should be the easiest part of software development The fact that nearly every ``statically'' typed language feels the need to poorly reinvent dynamic typing through ``generics'' shows what a sham it really is.
Is there anything wrong with making a tool more flexible and more safe at the same time?
compiled Don't confuse ``compiled'' with static manifest typing. Java is about as compiled as JavaScript (many interpreters compile scripts into an internal intermediate code before interpreting it). You hardly ever run what the compiler generates. Instead the output is fed to the JIT which takes on the tedious job of turning the horrible JVM byte code into somthing that a register machine understands (JVM bytecode is pretty easy to implement, but is awful as an intermediate language).
All data ultimately resolves to a number. That is the nature of information. Firstly, you missed the point that >>17 was making. What if you don't obey (by mistake) the rules that are only described in the documentation? There's compile time safety for returning different numbers when comparing two objects twice.
Secondly, all data don't ultimately resolve to a number. What you fail to see is that you can find an isomorphism between any data and natural numbers (and it goes both ways: I can represent numbers with my fingers when I count them, but you wouldn't say that my digits are digits).
All data ultimately resolves to a number. That is the nature of information. /prog/'s philosophy of mathematics:
Everything resolves to a register value of today's word size.
>>24 Secondly, all data don't ultimately resolve to a number. What you fail to see is that you can find an isomorphism between any data and natural numbers
Yo'ure a fucking idiot.
Every possible instance of an object must have a unique encoding in binary, so there needs to be a one to one function f: X -> N, where X is the set of all possible instances of the object, and N is the natural numbers. Or you could define it to map to the set of all finite length bit strings.
But I don't hink this has much bearing on dynamic typing versus static typing. Sure everything running on what we use for computers must have some encoding in binary, but that does not have an impact on the objects themselves, aside from how much memory they consume or how much time it might take to process them and the information they contain. It can be useful to be able to prove that you will only be dealing with a certain type of object at a certain point in your program. That might not be enough, but it is a start at least.
Everything resolves to an object.
Its objects all the way down to my anus.
Name:
Anonymous2012-04-29 3:36
you can run c# on mono. also, >>17 is retarded. dynamic typing is a poor way to address the problem of many data structures manipulating data in similar fashions. static typing is about reasoning through your program more than it is about safety.
>>32
Yes, yes, everybody knows that finite bit strings are countable. This is discussed here only because >>21 didn't understand what >>17 said, shown in his reply
if that method can return any int, even if it violates reflexivity, anti-symmetry, or transitivity
All data ultimately resolves to a number. That is the nature of information.
which had nothing to do with what was argued.
Manifest typing makes the job easier for the compiler, since it might be nearly impossible in some cases for it to prove that a function will only ever be called with data that has an inferred structure. Manifest typing is also sometimes useful to limit the generality of a function so that it won't allow inputs that don't make sense.
Name:
Anonymous2012-04-29 13:06
java on .net rails
Name:
Anonymous2012-04-29 13:46
>>37
>Yes, yes, everybody knows that finite bit strings are countable.
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.
Name:
Anonymous2012-04-29 17:46
>>61
No. Let's get back to discussing why you mix up "your" with "you're".
>>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.
Name:
Anonymous2012-04-29 18:25
The set of all finite length bit strings can be enumerated as folows:
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.
Name:
Anonymous2012-04-29 18:33
static typing is fucking shit. only faggots and queers use it.
Name:
Anonymous2012-04-29 19:03
>>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.
Name:
Anonymous2012-04-29 19:11
>>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
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.
Name:
Anonymous2012-04-30 12:17
>>74
Using ints for return values is like using PHP for web development.
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.
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
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.
Name:
Anonymous2012-05-01 14:05
>>75
You mean it's pretty much the standard way of doing things?
MOTHERFUCKER ONCE U BEEN HIT, U HAVE TO HIT 8 FUCKING KAWAII ASS PEOPLE! IF YOU GET HIT AGAIN YOU’LL KNOW YOUR REALLY SO FUCKING KAWAII IT'S SO FUCKING SUGOI PEOPLE WILL PISS THEIR PANTS AND SHIT BRICKS AND YOU WILL BE THE MOTHERFUCKING LORD OF THE MOTHERFUCKING KAWAII! IF YOU BREAK THIS MOTHERFUCKING CHAIN, YOU'LL BEE CURSED WITH UN*KAWAIINESS AND SHITINESS FOR 9000 YEARS SO PAS EET; HIT WHOEVER YOU THINK IS KAWAII
WE ARE GOING TO HAVE A SUPER FUN TIME! SUPER FUN TIME! WE ARE GOING TO! WE ARE! SUPER FUN! TIME! IAM JUST A LITTLE NIGGERFGAGOT PLEASE SPARE ME SOME TIME GO AHEAD AND CONVERGE YOU CONTROLLING AWESOME
Name:
Anonymous2012-05-02 18:55
YOU CONTROLLING AWESOME !YOU CONTROLLING AWESOME !
ghgshjkGDUDHSADUIHASDuihasUIDHDIUHDSAUIHDAUIshdaUIDHHDIUSHDSAAASADSADSDSDASDSADASDASDASDASdasDSADASDASDASDSDASDASDAS DASI HAVE ANOTHING MORE ELSE GGDUIHFUHDSFUHDSIHFDSFFSFHDHUIHDSFUSS FDLOOK HIDSIUHUSHDASDUIHASD MOUSE FDSHFDSFHSDFHUIDSHUIDSHFUDSF SDSCIRSSORS SHFIODSHFIDOHDSFUIFHSDIUHDSFIHDSFIUFDHSIDHFIUFHD FACE
Name:
Anonymous2012-05-02 18:57
QUITE AN EXPERIENCE TO LIVE IN FEAR IS IT NOT
THAT IS WHAT IT IS TO BE A SLAVE
Name:
Anonymous2012-05-02 18:58
TO HAVE.NOTHING TO FEAR.IS NOHIDE.iS NOtHING FEHId/E
IF YOU HAVE NOTHING.TO.F.ERRRRRRRRRR HId/E
Name:
Anonymous2012-05-02 19:00
I MAY BE YOUR DR4EAM, BUT Y4U ARE MY REALLLLITY
Name:
Anonymous2012-05-02 19:02
CONVERGE MY ANUS
CONVERGE MY SEQUECNE
DESTROY MY TOTAL SPATIAL ORBIT UELLOW
OR-BIT YELL-LOW! CONTROLLING AWESOME! SPARE ME AN ORBIT! SPARE ME TWO! I EXISTENT
>>5
When you start actually building real web applications with proper test coverage you'll realize this is seldom the issue people make it out to be. It's one of those things that you just have to get over when you start using dynamically typed languages. And once you do you'll see why it has more pros than cons.
>>115
Once again: getters and setters guard against the logic behind conceptual variables becoming more complicated in the future. In your example, killing grandma may suddenly require automatically notifying the children, which would be trivial to do in the setter, but would require changing every bit of code that could kill grandma without one.
Like every ``design pattern'', they work around language shortcoming, of which Java has a ton.
FIOC probably solves the problem of computed instance variables best. Ruby stumbles in the right direction, but falls short.
>>115
They're fucking stupid and most of the times encapsulation isn't needed.
In fact encapsulation is more useful in C where you could be doing something dangerous like using untagged unions in a struct array and you want to have some type safety.
Java would just return java.enterpriseLibraries.robust.turnKey.scalable.NullPointerExceptionFactory.