Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Eagleon]

There are tradeoffs for both. That's why they're implemented and maintained for Java. Just like you wouldn't use a BSP tree to store a calendar, you're not going to use a LinkedList when you need random access, or access to a specific index, or an ArrayList if you need to insert objects anywhere but at the end of the collection a significant number of times. Stop bickering, it's stupid.

[Max White]

The point is that we have more then just 'my list is better then your list!', we have 'Your stupid because I don't agree with you!' going on. Let's face it, most programming isn't about games or military incription, or writing viruses, or hacking into the pentagon. Most programming, by real programmers in the workforce, is for fat businessmen. UML is more important then maths, and public speaking is more important them logic. Welcome to a world where due to these nice high level compilers we have, a programmer is no longer a programmer, but rather a 'systems analysist'. And when your writing business softwere, the number of times when you should use a linked list is a lot more common then a array list. Especialy if your using java.

Nobody writes encription for the pentagon in java, or any other hollywood programming for that matter.

[Nadaka]

Actually I do write code, including security, for the DoD as a contractor and I mainly use java.  Java is on the approved technology list that has been vetted and cleared for use in secure systems. Fortunately I get to stay in sunny Florida most of the time and only rarely visit Washington. I can't tell you much more, but its mostly the same boring crap as business software.

[Max White]

Glad to see even the security side of things is suffering from the wrath of java. Somebody told somebody that java works on everything, and ever since then it's been the tool of no choise for anybody stuck proving that computers do a better job then accountants.

[Starver]

Calm down, everybody.

Java might (might) be a valid solution for what Nadaka is asked to provide.  With the obligatory caveat of Whateverthatisandifhetoldmehe'dhavetokillme, of course.

I've known deep-sea sensor platforms programmed in Forth, being considered more fit to work with the data inputs and microprocessor setup than anything bar intensively hand-coded assembler.  Modern manned submersibles almost certainly have something else in any programmable systems.

I wouldn't use COBOL for rocket telemetry but for businesses... well, I still wouldn't use COBOL[1], but I can see how numerate but not 'computerate' accountants could appreciate and audit the code, even those that can't write it.

I'm a fan of Perl (I do tend to mention that) because I can rapidly prototype things.  The other day I did something with prime factorisation for which I was happy to have the freedom to create both arbitrary-length arrays and similarly expandable hashes, plus embed arrays within hashes and hashes within arrays for various categorisation and post-processing.  But the overheads are a killer and once I'd tested it running for all the numbers from 1 to 10, from 1 to 100 and 1 to 1,000, the jump to investigating all the numbers up to 1,000,000 gave me some time to spare to do other things.  If I'd done the code in something more compiled (e.g. one or other flavour of C) or possibly even gone the route of the part-compiled Java, I'd have been less quick on the coding and testing[2] but it would have been easily far faster to run the First Million tester, and I might even have been able to get a Thousand Million[3] run within the same time-scale.  (Although I'd have already proven to myself what I'd wanted to prove.)

Ask me what I'd use for manned space-flight (especially if I was atop the rocket!), and I'd not use Java or COBOL or Forth, definitely not Perl, would avoid Pascal, stay away from all OO language implementations[4] yet would also be cautious of assembler-level programming (being too spoilt by the ability to use mid-to-high level coding techniques) as well.  No.  I don't know what I'd use.  Probably not a time to dig out my old FORTRAN notes, either...   Ada was allegedly used to program missiles with, but the rust on my skill with that is currently a foot thick, even if the language itself is still considered notionally fit for purpose.

Tell you what, don't ask me to program a manned space-flight, those guys who already do it are probably very happy with their Assembler or whatavyer and I'd rather not know that they use BASIC or ALGOL (or Lisp or bash scripts or just compile it straight from Z-notation) and just trust them.  More than I'd trust me, if I were on top of the stack, regardless of whatever inflated opinion I might have in my own capabilities.

But I could rustle up that same Prime Number script in most of the languages I've mentioned (and others besides).  Inefficiently, probably, but it'd work until it finished.  Or hit the memory limits of the system.  (As famously happened with my Rubics Cube simulator for the BBC Micro...  Which couldn't have been a more early '80s things to have attempted unless I'd also been sitting on a space-hopper whilst to Spandau Ballet through a Sony Walkman. )


Erm... the original point was that Java's good for some things (mostly, dare I say, webapp-like implementations where cross-platform functionality is king), so don't bash it.  It doesn't mesh particularly well with my current coding style and needs, of course.

[1] Godawful language with its ENVIRONMENT DIVISION stuff and compiler-mandatory indenting scheme, bearing in mind it's been around 20 years since I last typed any of it in...

[2] Partly because I flit around programming languages according to demand, and I definitely get 'skill-rust' when I've not actually used a language for a while.  Usually I start trying to do something that's actually only possible in a language which is a cousin of the one I'm trying to use...  Unfaithful me.  Jack Of All Trades, Master Of None.

[3] Billion to some of the world, a Milliard to the others.  For the record I personally prefer long-scale measures (finding the alternative akin to institutionalised exaggeration) but avoid the '-ard's in favour of "Thousand Million", etc.  Or stick with 10^N notation.

[4] Although I acknowledge there's always good compile-time sanity checking for class compatibility, I don't trust the degree of overheads.  But that rules out Java, all the C++/C#/.NET etc stuff, and (if not already ruled out) the likes of Delphi and similar OO developments of various older languages.

[Blank Expression]

You shouldn't give advice if you don't understand what you're talking about. You do not.

I will be sure to use an array list next time I have a list countless clients and i need to be able to add, subtract and sort them at a moments notice. Because the space saved from not having nodes is so worth it when your waiting for a large array to rewrite itself.

Your example of a client list is actually one of the only places I can think of where a linked list does make some sort of sense--but, then, there are still better ways to do that (event-driven models and message buses come to mind).


The reason linked lists are not generally used has nothing whatsoever to do with "nodes" (hint: there is an internal 'node' concept to the ArrayList/vector concept, most runtimes have a wrapper around the element) and everything to do with the linked list's unsuitability for most real-world actions. The linked list is suitable only for a case where you will never in general practice require random access. "Adding" and "subtracting" items from a vector is vastly less computationally expensive than you seem to think as well: you're talking microseconds until you hit values of n on the order of 10^5--and if you have a list that's that long, the traversal costs of a linked list (indirection node-to-node) are going to be on the same order as the amortized O(1) recopy of a vector.

As far as sorting goes, your claim just heads right off into the weeds. You do realize that the cost of any decent sort is multiplied by O(n) when you use a linked list due to accessor costs...right? Quicksort's practical best-case times become O(n^2 log n) instead of O(n log n) due to the inefficiency of the linked list for random access. (You can write an n log n mergesort for a linked list, but there are drawbacks--AFAIK you can't make a stable mergesort with the in-place sort and is likely slower than a mergesort or quicksort on a random-access container.)

About the only point to be made here is "well, if you create a vector with default capacity, and then add 100,000 items to it, it'll be slow!"...at which point the reasonable explanation is "sure, now go read the API documentation so you don't do that."

Let's face it, most programming isn't about games or military incription, or writing viruses, or hacking into the pentagon. Most programming, by real programmers in the workforce, is for fat businessmen. UML is more important then maths, and public speaking is more important them logic. Welcome to a world where due to these nice high level compilers we have, a programmer is no longer a programmer, but rather a 'systems analysist'. And when your writing business softwere, the number of times when you should use a linked list is a lot more common then a array list. Especialy if your using java.

Virtually all of this is completely and utterly untrue. You clearly do not have a grasp of data structures or algorithms. Which is fine--everybody has to learn sometime. But you made the mistake of attempting to act authoritative when your claims are factually incorrect. Sorry, but them's the breaks.

Using Java has nothing to do with what is the proper data structure for accomplishing a goal. Data structures are data structures, and their common traits persist from language to language. And given your fanboyish sneering toward what is arguably the most advanced modern software infrastructure in general use (you could make a compelling case for .NET), I'm guessing your wannabe-worldly professional experience from which you wax about "UML" (I've never even seen it outside of a classroom, FWIW) and "systems analysts" (my business cards would say otherwise!) is nil.

(As Nadaka noted, Java is cleared and vetted for secured systems. You don't get that kind of clearance by being shit.)

Ask me what I'd use for manned space-flight (especially if I was atop the rocket!), and I'd not use Java or COBOL or Forth, definitely not Perl, would avoid Pascal, stay away from all OO language implementations[4] yet would also be cautious of assembler-level programming (being too spoilt by the ability to use mid-to-high level coding techniques) as well.  No.  I don't know what I'd use.  Probably not a time to dig out my old FORTRAN notes, either...   Ada was allegedly used to program missiles with, but the rust on my skill with that is currently a foot thick, even if the language itself is still considered notionally fit for purpose.

[4] Although I acknowledge there's always good compile-time sanity checking for class compatibility, I don't trust the degree of overheads.  But that rules out Java, all the C++/C#/.NET etc stuff, and (if not already ruled out) the likes of Delphi and similar OO developments of various older languages.

This is actually a really tricky question, IMO. Overhead is not inherently "bad." The value you get out of the "overhead" in something like .NET or Java is fairly significant. Whether it's valuable in a situation like this is debatable, due to the skill level of the developers who would have to be involved, but I don't think it'd be a problem.

The more I think about it, the more it seems that something like a hardened, proofed version of Java or .NET actually wouldn't be a terribly bad choice, with the caveat that I don't know that one of them exists that would be sufficiently bulletproofed for my satisfaction. The technical requirements (summed up best as "don't fail") are being put to the hypothetical test in a nonstandard environment, but the uptime and reliability rules aren't really very different from HFT setups or the like. (Some of which use C++ or C, but Java and .NET have a strong following.) I don't actually think it'd be as difficult, from an architecture standpoint, as you're thinking. We've gotten pretty good at this stuff.

[Rysith]

You shouldn't give advice if you don't understand what you're talking about. You do not.

I will be sure to use an array list next time I have a list countless clients and i need to be able to add, subtract and sort them at a moments notice. Because the space saved from not having nodes is so worth it when your waiting for a large array to rewrite itself.

At the risk of violating Starver's request to calm down, I'm not sure why you're claiming that linked lists are better than arraylists at add, subtract and (especially) sort. Since Java LinkedLists are doubly linked, you'll see better performance for adds/removes near the beginning and end of the list, but since inserts/removes near the end of an AL are fast too (assuming that you don't hit a resize) it's really only the beginning of the list where the LL performs better than the AL. Even there, you're matching bulk memory copy to list traversal, which means that at reasonable N you'll see better performance with the AL. Similarly, the random-access nature of ALs means it's much easier to sort them (Java does a decent job on non-random-access structures, but I believe that random-access sorting is still faster).

It's true that resizing operations are slow (and have an annoying tendency to use much more memory than you thought they would), but that's a fairly rare operation unless you're habitually calling trimToSize() - certainly rare enough that if you're frequently sorting your lists, any throughput that you lose to array copies will be made up by not traversing the list.

I agree that Java isn't the best choice for all tasks, but I'd rather see people criticizing it from a position of knowledge (slow to warm up, verbose, slower at math operations, etc.) than one of ignorance (LL more common than AL[1], lack of serious programming in it, etc.)

[1] It occurred to me as I was writing this that what might be going on is the use of the generic List<Foo>, which is the common interface for both ArrayList and LinkedList (and Vector, which nobody uses anymore). I'm not sure, though.

Pre-post edit: Ninja'd by Blank Expression

Ask me what I'd use for manned space-flight (especially if I was atop the rocket!), and I'd not use Java or COBOL or Forth, definitely not Perl, would avoid Pascal, stay away from all OO language implementations[4] yet would also be cautious of assembler-level programming (being too spoilt by the ability to use mid-to-high level coding techniques) as well.  No.  I don't know what I'd use.  Probably not a time to dig out my old FORTRAN notes, either...   Ada was allegedly used to program missiles with, but the rust on my skill with that is currently a foot thick, even if the language itself is still considered notionally fit for purpose.

[4] Although I acknowledge there's always good compile-time sanity checking for class compatibility, I don't trust the degree of overheads.  But that rules out Java, all the C++/C#/.NET etc stuff, and (if not already ruled out) the likes of Delphi and similar OO developments of various older languages.

This is actually a really tricky question, IMO. Overhead is not inherently "bad." The value you get out of the "overhead" in something like .NET or Java is fairly significant. Whether it's valuable in a situation like this is debatable, due to the skill level of the developers who would have to be involved, but I don't think it'd be a problem.

The more I think about it, the more it seems that something like a hardened, proofed version of Java or .NET actually wouldn't be a terribly bad choice, with the caveat that I don't know that one of them exists that would be sufficiently bulletproofed for my satisfaction. The technical requirements (summed up best as "don't fail") are being put to the hypothetical test in a nonstandard environment, but the uptime and reliability rules aren't really very different from HFT setups or the like. (Some of which use C++ or C, but Java and .NET have a strong following.) I don't actually think it'd be as difficult, from an architecture standpoint, as you're thinking. We've gotten pretty good at this stuff.

I wouldn't use standard Java (or .NET, or any other managed language) in a rocket, because the thing that you want in a rocket is determinism and predictability, and any sort of system housekeeping that the runtime can kick off 'when it feels like it' can potentially disrupt that. Java Realtime (not sure if there is an equivalent .NET variant) was moving toward dealing with that, though even there I'm not sure if they have the timing tolerances down to what you need in rockets (as opposed to things like industrial robots).