Related
In many languages, for me specifically, Java and C++, there is an massive standard library. Many classic problems in computer science, search, sorting, hashing etc etc... are implemented in this library. My question is, are there any benefits of say implementing one's own algorithm versus simply using the library's version? Are there any particular instances were this would be true?
I only ask because in school a huge deal of time is spent on say sorting, however in my actual code I have found no reason to utilize this knowledge when people have already implemented and optimized a sorting algorithm in both Java and C++.
EDIT: I discussed this at length with a professor I know and I posted his response, can anyone think of more to add to it?
Most of the time, the stock library functions will be more performant than anything you'll custom code.
If you have a highly specific (as opposed to a generic) problem, you may find a performance gain by coding a specialized function, but as a developer you should make a conscious effort to not "reinvent the wheel."
Sorting is a good example to consider. If you know nothing whatsoever about the data to be sorted, except how to compare elements, then the standard sort algorithms fare well. In this situation, in C++, the STL sort will do fine.
But sometimes you know more about your data. For example, if your data consists of uniformly distributed numbers, a radix sort can be much faster. But radix sort is 'invasive' in the sense that it needs to know more about your data than simply whether one number is bigger than another. That makes it harder to write a generic interface that can be shared by everyone. So STL lacks radix sort and for this case you can do better by writing your own code.
In general, standard libraries contain very fast code for very general problems. If you have a specific problem, you can in many cases do better than the library. Of course, you may eventually come across a complex problem which is not solved by a library, in which case the knowledge you have gained from studying solutions to solved problems could prove invaluable.
In college, or school, or if learning as a recreational programmer, you will be (or in my strident opinion, you should be) encouraged to implement a subset of these things yourself. Why? To learn. Tackling the implementation of an important already invented wheel (the B-Tree) for me was one of the most formative experiences of my time in college.
Sure I would agree that as a developer you should make an effort not to reinvent the wheel, but when learning through formative experiences, different rules apply. I read somewhere else on this forum that to use something at abstraction level N, it is a very good idea to have a working knowledge of abstraction level N-1, and be familiar with level N-2. I would agree. In addition to being formative, it prepares you for the day when you do encounter a problem when the stock libraries are not a good fit. Believe me this can happen in your 50 year career. If you are learning fundamentals such as data structures, where the end goal is not the completeness of your finished product but, instead, self improvement, it is time well spent to "re-invent the wheel".
Is pre-algebra/algebra/trigonometry/calculus worth learning?
I can't tell if this is a "am I wasting my time/money in school" aimed question or if this is a sincere question of if your own version is going to be better.
As for wasting your time/money in school: If all you want to do is take pot shots at developing a useful application, then you're absolutely wasting your time by learning about these already-implemented algorithms -- you just need to kludge something together that works good 'nuff.
On the other hand if you're trying to make something that really matters, needs to be fast, and needs to be the right tool for the right job -- well, then it often doesn't exist already and you'll be back at some site like Stack Overflow asking first or second year computer science questions because you're not familiar enough with existing techniques to roll your own variations.
Depending on my job, I've been on both sides. Do I need to develop it fast, or does it have to work well? For fast application programming, it's stock functions galore unless there's a performance or functionality hindrance I absolutely must resolve. For professional game programming it has to run blazing fast. That's when the real knowledge kicks into memory management, IO access optimization, computational geometry, low level and algorithmic optimization, and all sorts of clever fun. And it's rarely ever a stock implementation that gets the job done.
And did I learn most of that in school? No, because already knew most of it, but the degrees helped without a doubt. On the other hand you don't know most of it (otherwise you wouldn't be asking), so yes, in short: It is worthwhile.
Some specific examples:
If you ever want to make truly amazing games, live and breath algorithms so you can code what other people can't. If you want to make fun games that aren't particularly amazing, use stock code and focus on design. It's limiting, but it's faster development.
If you want to program embedded devices (a rather large market), often stock code just won't do. Often there's a code or data memory constraint that the library implementations won't satisfy.
If you need serious server performance from modest hardware, stock code won't do. (See this Slashdot entry.)
If you ever want to do any interesting phone development the resource crunch requires you to get clever, even often for "boring" applications. (User experience is everything, and the stock sort function on a large section of data is often just too slow.)
Often the libraries you're restricted to using don't do what you need. (For example, C# doesn't have a "stable" sort method. I run into this annoyance all the time and have since written my own solution.)
If you're dealing with large amounts of data (most businesses have it these days) you'll end up running into situations where an interface is too slow and needs some clever workarounds, often involving good use of custom data structures.
Those libraries offer you tested implementations that work well, so the rule of thumb is to use those implementations. If you have a very particular/complex problem where you can use some domain knowledge you have a case were you will need to implement your own version of an algorithm.
I remember an example Bill Pugh gave in his programming languages class where they analyzed the performance of a complex application and they realized a faulty custom implementation of a sorting algorithm by a programmer (that code was used many times in the real runs of the application) was responsible for 90% performance decrease!
After discussing this at length with professor of Computer Science, here were his opinions:
Reasons to Use Libraries
1. You are writing code with a deadline.
There is no sense in hampering your ability to complete a project in a quick and timely manner. That's why libraries are written after all, to save time and avoid "reinventing the wheel"
2. If you want to optimize your code fully.
Chances are the team of incredibly talented people who wrote the algorithm in Java or C++'s or whoever's library did a far better job at optimizing their algorithm for that language in however long it took them than you can possibly do in an hour or two. Or four.
3. You've already done previously solved this problem.
If you have already solved this problem and have a good complete understanding of how it is designed you don't need to labor over a complex solution as you don't stand to gain much benefit.
That being said, there are still many reasons to make your own solution.
Reasons to Do It Yourself
1. A fundamental understanding of problem solving techniques and algorithms are completely necessary once you reach a problem that is better optimized by a non-library solution.
If you have a highly specified problem, such things often come up when working with networking or gaming or such. It becomes invaluable to be able to spot situations in which a specific algorithm will outperform the libraries version.
2. Having a very good understanding of algorithms and their design and use makes you much more valuable in the work place.
Any halfway decent programmer can write a function to compare two objects and then toss them into a library function, however the one that is able to spot a situation and ultimately improve the programs functionality and speed is going to be looked upon well by management.
3. Having the concept of how to do something is often just as, if not more so, valuable than being able to do it.
With an outstanding knowledge of Java's libraries and how to use them, chances are you can field any problem in java with reasonable success. However when you get hired to work in erlang you're going to have some rough times ahead. Where if you had known how and not merely what Java's libraries did, you could move those ideas to any language.
4. We as programmers are never truly satisfied with merely having something "work".
Chances are that you have an itch to understand why things work. It was this curiosity that probably drove you to this area of study. Don't deny this curiosity! Encourage it and learn to your hearts content.
5. Finally, there is a huge feeling of success and accomplishment that comes with creating your own personal way of sorting or hashing etc.
Just imagine how cool your friends will see you when you proclaim that you can find the shortest path between 2 vertices in n log(n) time! On a serious note, it is very rewarding to know that you are completely capable of understanding and choosing an optimum solution based on knowledge. Not what some library gives you.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to write a backend system for a web site (it'll be a custom search-style service). It needs to be highly concurrent and fast. Given my wish for concurrency, I was planning on using a functional language such as Haskell or Scala.
However, speed is also a priority. http://benchmarksgame.alioth.debian.org results appear to show that Java is almost as fast as C/C++, Scala is generally pretty good, but Haskell ranges from slower to a lot slower for most tasks.
Does anyone have any performance benchmarks/experience of using Haskell vs Scala vs Java for performing highly concurrent tasks?
Some sites I've seen suggest that Scala has memory leaks which could be terrible for long running services such as this one.
What should I write my service in, or what should I take into account before choosing (performance and concurrency being the highest priorities)?
Thanks
This question is superficially about performance of code compiled with GHC vs code running on the JVM. But there are a lot of other factors that come into play.
People
Is there a team working on this, or just you?
How familiar/comfortable is that team with these languages?
Is this a language you (all) want to invest time in learning?
Who will maintain it?
Behavior
How long is this project expected to live?
When, if ever, is downtime acceptable?
What kind of processing will this program do?
Are there well-known libraries that can aid you in this?
Are you willing to roll your own library? How difficult would this be in that language?
Community
How much do you plan to draw from open source?
How much do you plan to contribute to open source?
How lively and helpful is the community
on StackOverflow
on irc
on Reddit
working on open source components that you might make use of
Tools
Do you need an IDE?
Do you need code profiling?
What kind of testing do you want to do?
How helpful is the language's documentation? And for the libraries you will use?
Are there tools to fill needs you didn't even know you had yet?
There are a million and one other factors that you should consider. Whether you choose Scala, Java, or Haskell, I can almost guarantee that you will be able to meet your performance requirements (meaning, it probably requires approximately the same amount of intelligence to meet your performance requirements in any of those languages). The Haskell community is notoriously helpful, and my limited experience with the Scala community has been much the same as with Haskell. Personally I am starting to find Java rather icky compared to languages that at least have first-class functions. Also, there are a lot more Java programmers out there, causing a proliferation of information on the internet about Java, for better (more likely what you need to know is out there) or worse (lots of noise to sift through).
tl;dr I'm pretty sure performance is roughly the same. Consider other criteria.
You should pick the language that you know the best and which has the best library support for what you are trying to accomplish (note that Scala can use Java libraries). Haskell is very likely adequate for your needs, if you learn enough to use it efficiently, and the same for Scala. If you don't know the language reasonably well, it can be hard to write high-performance code.
My observation has been that one can write moderately faster and more compact high-performance parallel code in Scala than in Haskell. You can't just use whatever most obviously comes to mind in either language, however, and expect it to be blazing fast.
Scala doesn't have actor-related memory leaks any more except if you use the default actors in a case where either you're CPU-limited so messages get created faster than they're consumed, or you forget to process all your messages. This is a design choice rather than a bug, but can be the wrong design choice for certain types of fault-tolerant applications. Akka overcomes these problems by using a different implementation of actors.
Take a look at the head-to-head comparison. For some problems ghc and java7-server are very close. For equally many, there's a 2x difference, and for only one there's a 5x difference. That problem is k-nucleotide for which the GHC version uses a hand-rolled mutable hashtable since there isn't a good one in the stdlibs. I'd be willing to bet that some of the new datastructures work provides better hashtables than that one now.
In any case, if your problem is more like the first set of problems (pure computation) then there's not a big performance difference and if its more like the second (typically making essential use of mutation) then even with mutation you'll probably notice somewhat of a performance difference.
But again, it really depends on what you're doing. If you're searching over a large data set, you'll tend to be IO bound. If you're optimizing traversal of an immutable structure, haskell will be fine. If you're mutating a complex structure, then you may (depending) pay somewhat more.
Additionally, GHC's lightweight green threads can make certain types of server applications extremely efficient. So if the serving/switching itself would tend to be a bottleneck, then GHC may have the leg up.
Speed is well and good to care about, but the real difference is between using any compiled language and any scripting language. Beyond that, only in certain HPC situations are the sorts of differences we're talking about really going to matter.
The shootout benchmark assumes the same algorithm is used in all implementations. This gives the most advantage to C/C++ (which is the reference implementation in most cases) and languages like it. If you were to use a different approach which suited a different language, this is disqualified.
If you start with a problem which more naturally described in Haskell it will perform best in that language (or one very much like it)
Often when people talk about using concurrency they forget the reason they are doing it is to make the application faster. There are plenty of examples where using multiple threads is not much faster or much much slower. I would start with an efficient single threaded implementation, as profiled/tuned as you can make it and then consider what could be performed concurrently. If its not faster this more than one CPU, don't make it concurrent.
IMHO: Performance is your highest priority (behind correctness), concurrency is only a priority in homework exercise.
Does anyone have any performance benchmarks/experience of using
Haskell vs Scala vs Java for performing highly concurrent tasks?
Your specific solution architecture matters - it matters a lot.
I would say Scala, but then I have been experimenting with Scala so my preference would definitely be Scala. Any how, I have seen quite a few high performance multi-threaded applications written in Java, so I am not sure why this nature of an application would mandate going for FP. I would suggest you write a very small module based on what your application would need in both scala and haskell and measure the performance on your set up. And, may I also add clojure to the mix ? :-) I suspect you may want to stay with java, unless you are looking at benefiting from any other feature of the language you choose.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I know embedded C is used for micro-controllers along with other languages. but what if the control was from a PC, well I had two possible candidates (java and c++)
Java is simple and easy also Developer friendly when it comes to threading or GUI, but of course C++ is so much better performance (I know computers getting faster, and performance depend on good Algorithms ) but the compilation makefiles, shared-library and cross compiling wastes lots of time caring about technicalities when I should be working on other Important issues.
But still I've faced something like Const references which java doesn't support and force you to use clone() or copying and when that came to arrays it was a giant mess,
NOTE: I'm going to use reverse kinematics and maybe Neural network for pattern recognition. which requires tons of Calculations. but as I said I care also about the whole life cycle of the project (speed of development, performance , user friendliness and quick deployment)
I'm swinging between languages and i'm planning for long term learning process so I don't want to waste that in the wrong language or let's say (without asking) so please help and I hope this question won't be considered subjective but a reference.
cheers
Why you eliminated C?
Why do you think java has worse performances then c++? Some things are as good as c++, and it is easy to use java program on different platforms without much hassle.
Just pick the language you feel comfortable and you have most experience with, and go with it.
Personally I would lean toward C++. Java has a garbage collector, which can put your app to sleep at random. In C++ I have to collect my own garbage, which gives me an incentive to generate less of it. Also C++ allows macros, which I know have been declared a bad thing by Java-nistas, but I use as a way of shortening the code and making it more like a DSL. Making the code more like a DSL is the main way I shorten development effort and minimize introducing bugs.
I wouldn't assume that Java is inherently slower than either C++ or C. IME slowness (and bigness) comes not from how well they spin cycles, but from the design practices that they encourage you to follow. The nice things they give you, like collection classes, are usually well-built, but that doesn't stop you from over-using them because they are so convenient.
IME, the secret of good performance is to have as little data structure as possible (i.e. minimal garbage), and keep it as normalized as possible. That way, you minimize the need to keep it consistent via message-waves. To the extent the data has to be unnormalized, it is better to be able to tolerate temporary inconsistency, that you periodically patch up, than to try to keep it always consistent through notifications (which OO languages encourage you to do). Unless carefully monitored, those make it extremely easy to introduce performance bugs.
Here's an example of some of these points.
I wouldnt worry too much about performance at first - write the code in whatever language you feel comfortable in and then refactor as necessary.
You can always use something like JNI to call out to c/c++ if needed, although the performance gap between Java and c/c++ is nowhere near what it was...
Depending upon your circumstance, Java is no more quick to deploy than is C++. This mainly boils down to: are you guaranteed the same environment in your testbed that you are in production? With all of the modern additions to C++, there is little cause to suggest that Java is easier on the developer unless you are still new to the C++ language.
That aside, you have performance concerns. Unless it is a real-time system, there's no reason to eliminate any language just yet. If you code your Java intelligently (for instance, do your best to avoid copying objects and creating garbage in the most-used sections), the performance differences won't be seriously noticeable for a compute-bound process.
All told, I think you are focusing too much on textbook definitions of these two languages rather than actual use. You haven't really given any overriding reason to choose one over the other.
Java is a bit more portable, but as far as I know the only real factor for something like this is personal preference.
It would really help if You described Your problem in greater detail.
You are willing to use IK, that might suggest some robotic arm manipulation. What it doesn't say are your real time requirements. If it's going on a class-A production line it'll be hard to get away with garbage collected language.
Java is great. There are some very mature NN libraries (Neuroph, Encog) which could save You a lot of coding time. I don't know of any IK library, but I'm sure there also are at least good matrix manipulation libraries to help.
The Garbage Collection in Java is getting better and better. The latest one (G1) is a lot better than anything else, but even with it the best You can get is soft real time. So You can't expect pause-free run.
On the other hand You also might want to look at some dedicated environments - Matlab toolboxes for robotics and artificial intelligence. I think that would yield fastest prototypes.
If it's going on production than You are pretty much stuck with C or C++.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am a competent C++ developer. I understand and use polymorphism, templates, the STL, and I have a solid grasp of how streams work. For all practical purposes, I've done no Java development. I'm sure some of you were in a similar situation at one point when you had to learn Java. How long did it take you to become a competent Java programmer?
I think that learning the language is not difficult. In fact, I used to be a full time C++ developer, and at some point I started writing Java code. But the thing is that I don't remember ever learning Java, so I guess I just figured it as I went. I've been doing full time Java for a long time now.
If you are well familiar with C++, you may want to read a list of the major differences (e.g., everything is dynamically-bound) and then start practicing on an environment (just download Eclipse). The small differences are the main thing you would have to get adjusted to.
Now that Java supports generics, one of the major switching pains is gone. Multiple inheritance, while not supported, is not a big deal if you get used to interfaces, and in fact having interfaces rather than abstract classes with pure virtual functions (PVFs) improves readability.
To me Java is a nice and friendly and relaxing sandboxed version of C++. I don't have to worry about general protection faults (GPFs), I don't have to worry about memory leaks, I don't have to worry about messing with pointers. However, don't let that confuse you, there are still plenty of opportunities to screw up royally, and they're sometimes even nastier to detect.
Just take the leap. If you have the instinct, it shouldn't be a problem.
I went the opposite way. Started with Java, then moved to C and C++. For my own personal experience, it was much easier to learn Java than C/C++ (C++ especially).
Java in many ways is meant to be C++ with many of the undefined and unnecessarily complicated portions removed or simplified. IMHO, it had great success with that goal. As a result it's a very easy language to learn and use. Especially for someone who is familiar with C++.
The actual time it will take is very dependent upon the person learning the language. However, I think it's safe to say it will take less time to become competent in Java than it did in C++.
Shouldn't be too bad. The syntax and classes should be very easy for you to grasp. There are some differences but none of it is too challenging.
The hardest part is more about learning the packages, since those will be different. The built in Java classes and functions, and then to use Java in a practical manner, you'll need to learn J2EE or whatever you might be actually using it for. The latter part will probably take more of your time than the language itself.
If you're already a competent programmer (especially in C++) then Java doesn't take long to learn at all. The books I would recommend (in order) for anyone who wants to learn Java are:
Head First Java
Thinking in Java
Effective Java
You may find that you zip through Head First Java rather quickly, given your experience. For that reason I suggest you check it out of the library and skim it before moving on to Thinking in Java.
Also check out Sun's Java Tutorials.
C++ to Java: 1 week.
Java to C++: 1 month.
As Tom Hawtin wrote, the key issue is how you define competent.
You'll be able to pick-up the language fairly easily, but it's the idioms and the libraries that you will have to learn. And there are quite a few differences between niches you work in (e.g. embedded or enterprise), and between libraries that supposedly solve the same problems. Here are a few examples:
In business/enterprise apps, you generally work with databases. There you can have:
plain JDBC
SQL mapper (iBatis), wrapper around verbose and repetitive JDBC
ORM solution (Hibernate), with a philosophy of it's own
With desktop UIs, you have two competing platforms:
Swing, a part of JRE
SWT/JFace, from Eclispe foundation, originated by IBM, with native UI support
Web frameworks are too many to mention, with different ideas of representing the UI, configuration, folder/package structure etc.
DI (dependency injection) is common in business apps, either by 3rd party frameworks like Spring, or as a part of EJB3 standard. But, I don't think it is ever used in embedded set-up.
It would be fair to say this is just a tip of the iceberg.
Back in 1995 when I did it, it took me about half a day to get comfortable with the tools and basic ideas, a day or two to get the language, a week to get the more obscure parts of the language (there were less of them at the time) and a month to get the libraries (there were WAY less of them at that time).
Now I would guess that the tools and basic language will take as much time, a couple of weeks to a month for the obscure parts of the language (depends on what parts you hit, and when). The basic libraries will be a month to two months (java.lang, java.util, and a few others). The remaining class libraries 6 months to forever depending on what you need to learn and how often the keep updating them :-)
I know C++, and had to work with Java once and picked it up in 2 weeks. Of course there were quite a few surprises but it's easy.
I have C++ background. Picking up Java took me few days - the language seems really simple - at least its basis. I still consult my Java guru - google quite a bit, but it's usually a matter of exploring API and standard libraries. Java has some annoyances, but you should spot most of them them easily and quickly.
I was recommended Thinking in Java (there's an ebook for free), but was never persistent enough to read through it. I don't write rocket-science code in Java and to do it, my skills are sufficient.
Having said that, it would be good to have better formal knowledge of the language. At the moment I'm thinking about studying for SCJP, which seems a sensible way of learning, plus you will get well-recoginized programming certificate once you pass it (I've heard it's not worth much, but still it may be a motivation...).
You can also try Java Black Belt - the answers frequenty surprises me. After taking few tests I wonder how my programs even compile, which suggests I'm probably not the most competent Java programmer around :)
How would you define competent? For my money, most professional (as in they do it for money) Java programmers never manage to reach competent.
These days, a programming language derives much of its power from its libraries and accepted idioms.
While it takes relatively short time to learn the Java language, learning to use the available libraries (collections, io, etc.) effectively will probably take significantly more time.
I think there are two approaches to meaning of term "competent Java programmer".
If it is about lexems, syntax and terms of OOP I began to completly understand Java before 2 (two) days of learning.
But firstly you will be charmed by impossibility to shoot your own leg ;)
But if it is case of embeded class system (i.e. packages), APIs references, tips-and-tricks and etc., it takes about half-year to feel yourself friendly with Java. I think.
I too learnt C++ first and then Java. It took very less time as I was already familiar with OOPS concepts. In the initial phase of learning I was really happy with new concepts in Jave like garbage collector. I referred The Complete Reference by Herbert Schildt and it did help me to get the syntax quickly.
I started from C++ and learned C#/.NET. That didn't take long.
As C#/.NET is developed very near to Java (they used many of Java's base techniques such as GC, reference classes, JIT, ...) I think it is not that hard to learn Java.
I would go with six to eight weeks.
Shouldn't take you more than a day or two to learn the language, but you might have to spend a few weeks on the class library: how to use collections, the concurreny package, reflection, logging, swing/awt, dynamic proxies, MBeans etc.
i learned c++ at a small age of 15 and became a professional software programmer. But when i searched for job there was only job available for java developers.I thought it was hard to change my language.So just for trial i Downloaded java compiler and just for fun typed some code and i found it is not much different than c++. and only after 6 hours of research and learning i became a java developer .so it is very easy to switch between c++ to java.
I was reading the following question - How safe would it be to use functional-java to add closures to a Java production project? and I had been thinking of using the Functional Java project as well in my current project. I was wondering what are Stack Overflow's users experiences with using the Functional Java project? In particular, I'm curious about some of these specifics:
Did it increase code quality or clarity?
Improve productivity?
Reduce potential points of failure?
Impact performance?
I've been on a team that uses the FJ library, and I know of others. On one team it was used as a replacement for a home-grown library that was less polished, on another it replaced Google Collections. I also know some folks that copycat the source code from FJ to roll their own implementation.
In my opinion, if you must use Java, you should be using something like Functional Java to make your life easier.
Did it increase code quality or clarity?
Code written in a functional style is more concise, hence more clear. The library comes with, and encourages the use of, immutable data structures, which improves quality. The library also encourages composition over inheritance, which improves the reusability of your code.
Improve productivity?
Definitely. Developers with more powerful tools are more productive. In my experience developers feel that first-class functions make programming easier and more enjoyable. Happy programmers are productive programmers.
Reduce potential points of failure?
A more functional style of programming discourages mutable state, which eliminates a large class of bugs. Also, more powerful abstractions lead to less repetition, which reduces the number of places where something is wrong.
Impact performance?
There's no reason to believe that performance would be impacted one way or the other. The provided datastructures are designed for ease of use and expressiveness rather than performance, but they're written optimally for what they are. As with anything else, how you drive is more important than what you're driving. For example, fj.data.List is a linked list, so it has O(n) random access and concatenation, therefore you avoid it for those purposes. fj.data.Stream has O(1) concatenation, by comparison.