Yessiree. The important thing isn't the language, but portability & security. Implementing something equivalent to a jvm for your favorite language is decidedly not a trivial task.
That said, there are over 160 languages apart from java which can be compiled to java bytecode. Jython is quite robust & can be used to create java applets w/ python. There's also a perl->java byte codes compiler under development. (Though maybe it's been abandoned?...)
Software willing, the Earth Simulator will accurately model the earth's oceans and atmosphere by calculating weather data collected by various, land, sea and space-based sensors at 10 kilometre-spaced points around the entire earth.
Perhaps. But my pentium 100 can do the exact same thing in near real time.
It sounds like your biggest complaint is the lack of planning/architecture invested in projects. Do you have clients coming back to you after 6 months asking for modifications which are difficult to implement due to poor planning? Do you find older projects fragile & difficult to maintain?
If so, inform your manager that the reason you're seeing these problems is a lack of initial planning & quality control, and that the only way to avoid these sorts of long-term headaches is to invest more time up-front. Ask to be involved in initial project cost/time estimates, and explain why the extra time you estimate is necessary for creating a product which will be maintainable & stable. Suggest that your company adopt official coding conventions (set by all developers, not just you) and well established development cycles. If management isn't completely clueless, they'll understand the value of these suggestions. They may not be able to implement everything you want immediately -- it takes time to get out of the vicious cycle begat by poor quality software. Still, if they take your comments seriously, it's probably worth your time to stick it out and help make improvements as you go.
If you aren't experiencing the problems described above, you're probably better off finding another job -- you aren't going to convince management that they need to change proven development methods.
The study does show an advantage of lisp over java/c/c++ -- but only for small problems which depend heavily on the types of tasks lisp was designed for. The author recognizes the second problem ("It might be because the benchmark task involved search and managing a complex linked data structure, two jobs for which Lisp happens to be specifically designed and particularly well suited.") but doesn't even mention the first.
While I haven't seen the example programs, I suspect that the reason the java versions performed poorly time-wise was probably directly related to object instantiation. Instantiating an object is a pretty expensive task in java; typical 'by the book' methods would involve instantiating new numbers for every collection of digits, word, digit/character set representation, etc. The performance cut due to instantiation can be minimized dramatically by re-using program wide collections of commonly used objects, but the effect would only be seen on large inputs. Since the example input was much smaller than the actual test case, it seems likely that the programmers may have neglected to include this functianality.
Hypothising about implementation aside, the larger question is one of problem scope. If you're going to claim that language A is better than language B, you probably aren't concerned about tiny (albeit non-trivial) problems like the example. Now, I don't know whether this is true, but it seems possible that a large project implemented in java or c/c++ might be built quicker, be easier to maintain, and be less fragile than its equivilent in lisp. It may even perform better. It's not fair to assume blindly that the advantages of lisp seen in this study will scale up. I'm not claiming that they don't... but still. If we're choosing a language for a task, this should be a primary consideration.
One option I'm surprised I haven't seen voiced -- get a bunch of desks at thrift stores, arrange them in a semi-circle. Not necessarily the slickest option, but definitely the cheapest. At least if yr willing to place the machines & fridge on the floor. I use two desks & the top of a filing cabinet; add desks according to need.
Slashdot Mirror
"Well, they make the trains run on time ..."
That said, there are over 160 languages apart from java which can be compiled to java bytecode. Jython is quite robust & can be used to create java applets w/ python. There's also a perl->java byte codes compiler under development. (Though maybe it's been abandoned? ...)
Software willing, the Earth Simulator will accurately model the earth's oceans and atmosphere by calculating weather data collected by various, land, sea and space-based sensors at 10 kilometre-spaced points around the entire earth.
Perhaps. But my pentium 100 can do the exact same thing in near real time.
It sounds like your biggest complaint is the lack of planning/architecture invested in projects. Do you have clients coming back to you after 6 months asking for modifications which are difficult to implement due to poor planning? Do you find older projects fragile & difficult to maintain?
If so, inform your manager that the reason you're seeing these problems is a lack of initial planning & quality control, and that the only way to avoid these sorts of long-term headaches is to invest more time up-front. Ask to be involved in initial project cost/time estimates, and explain why the extra time you estimate is necessary for creating a product which will be maintainable & stable. Suggest that your company adopt official coding conventions (set by all developers, not just you) and well established development cycles. If management isn't completely clueless, they'll understand the value of these suggestions. They may not be able to implement everything you want immediately -- it takes time to get out of the vicious cycle begat by poor quality software. Still, if they take your comments seriously, it's probably worth your time to stick it out and help make improvements as you go.
If you aren't experiencing the problems described above, you're probably better off finding another job -- you aren't going to convince management that they need to change proven development methods.
The study does show an advantage of lisp over java/c/c++ -- but only for small problems which depend heavily on the types of tasks lisp was designed for. The author recognizes the second problem ("It might be because the benchmark task involved search and managing a complex linked data structure, two jobs for which Lisp happens to be specifically designed and particularly well suited.") but doesn't even mention the first. ... but still. If we're choosing a language for a task, this should be a primary consideration.
While I haven't seen the example programs, I suspect that the reason the java versions performed poorly time-wise was probably directly related to object instantiation. Instantiating an object is a pretty expensive task in java; typical 'by the book' methods would involve instantiating new numbers for every collection of digits, word, digit/character set representation, etc. The performance cut due to instantiation can be minimized dramatically by re-using program wide collections of commonly used objects, but the effect would only be seen on large inputs. Since the example input was much smaller than the actual test case, it seems likely that the programmers may have neglected to include this functianality.
Hypothising about implementation aside, the larger question is one of problem scope. If you're going to claim that language A is better than language B, you probably aren't concerned about tiny (albeit non-trivial) problems like the example. Now, I don't know whether this is true, but it seems possible that a large project implemented in java or c/c++ might be built quicker, be easier to maintain, and be less fragile than its equivilent in lisp. It may even perform better. It's not fair to assume blindly that the advantages of lisp seen in this study will scale up. I'm not claiming that they don't
One option I'm surprised I haven't seen voiced -- get a bunch of desks at thrift stores, arrange them in a semi-circle. Not necessarily the slickest option, but definitely the cheapest. At least if yr willing to place the machines & fridge on the floor. I use two desks & the top of a filing cabinet; add desks according to need.
Finally, if you're going to run a self-sustaining colony which pays its own way, to pay for imports from Earth you need something you can export back.
...like teeth!