Why is it that the C threading library (pthreads) not as popular as the java one when it comes to application development?
Is it just the memory management issue or are there other major advantages involved?
pthreads are not implemented natively on all OSes, such as Windows (there is a Win32 API for that). In fact, C as a language has no concept of threads.
Java was built with threads integrated into the language. C was not.
It's not entirely portable -- pthreads is parts of POSIX, and not normally provided under (for one obvious example) Windows.
C++ 0x adds threading primitives to the standard library (and they're mostly quite similar to pthreads) which is what most new code is likely to start using fairly soon (and some already does).
pthreads are also fairly low-level and kind of a pain to use well; many application programs will probably be better off using futures (roughly similar to the Java objects of the same name) for many of the relatively simple threading situations.
It depends completely on which type of application you have in mind writing. Perhaps the applications you're referring to are more convenient to write in a high level language such as Java.
In addition to the matter of (non-)portability mentioned by others, systems that implement pthreads often also implement cheap and easy multi-process programming, and that was how parallel unix programs were written for a very long time.
I'd say threading is too popular in Java, for example because it is hard to do asynchronous I/O. It looks to me like libraries in Java are designed with the attitude that threads are good. Library designers using C simply have the opposite attitude :)
The Qt framework offers a platform independent implementation for threads in C++.
It has borrowed extensively from java and is a lot newer than some the libraries mentioned earlier so its still gaining in popularity.
Surely this is a question about the popularity of Java vs C rather than one library over the other. I imagine most developers select the development language not the threading library. Once the language is selected this constrains the library choice; after all you cannot use pthreads in Java.
Another point is that in C there is no standard threading library, although pthreads is commonly available on many platforms.
I also doubt the premise; if we assume that you really mean that Java is more popular than C (since that is perhaps the implication), then I doubt it is true generally. In certain application domains maybe, but it is not an easy thing to measure. Depending on how you measure it, you can make Java, C, C++, PHP, JavaScript, Python, and even D look like the world's most popular programming language.
It is possible I suppose that if you choose to use multi-threading, this may lead to a decision to prefer Java (though I doubt that too), but that is a different decision process than choosing pthreads over Java threads.
Java is mainly application programming language so more people and companies are on to it, whereas c is more of a system level programming and core programming which is less popular compared to application programming.
Related
I am about to get involved in a NLP-related project and I need to use various libraries. Some are in java, others in C/C++ (for tasks that require more speed) and finally some are in Python. I was thinking of using Python as the "glue" and create wrapper-classes for every task that I want to do that relies on a different language. In order to do that, the wrapper class, for example, would execute the java program and communicate with it using pipes.
My questions are:
Do you think that would work for cpu-demanding and highly repetitive tasks? Or would the overhead added by the pipe-communication be too heavy?
Is there any other (preferably simple) architecture that you would suggest?
I would simply advise not doing this.
Don't implement stuff in C/C++ "for speed". The performance benefit is not likely to be as great as you expect; e.g. compared with implementing in Java using "best practice" design and performance techniques.
Don't try and glue lots of languages together. You are setting yourself up for lots of portability issues, difficulties in debugging, and reliability issues; e.g. due to C / C++ bugs crashing the JVM. In addition, there are performance overheads in bridging between languages, and there can be unexpected bottlenecks. (For instance, you may find that your C/C++ has to be run single-threaded due to threading issues, and that you therefore can't get the benefit of Java multi-threading on a typically multi-core system.)
Instead, I advise you to look for libraries that allow you to implement the entire application in one language. If that is not possible, design it so that the different language components are different executables / processes, communicating via some kind of RPC, messaging, or whatever.
Whether or not you'd have problems communicating over pipes / sockets has nothing to do with how CPU intensive the tasks are, but how frequently you'd need to send information between the processes and how much data they need to send. Setting up threads to do your communication will have little processing overhead.
You can probably automatically wrap the C/C++ code with Python (SWIG, ctypesgen, Boost.Python), so the only glue you'll have to write yourself would then be talking to Java.
You could also do it the other way -- run the Python code in the JVM with Jython so the Python and Java code are together, then talk to the C/C++ from there.
You should take a look at Apache UIMA. It is designed exactly for this. From the project website:
The Frameworks run the components, and are available for both Java and C++. The Java Framework supports running both Java and non-Java components (using the C++ framework). The C++ framework, besides supporting annotators written in C/C++, also supports Perl, Python, and TCL annotators.
UIMA can manage pipes and annotators and is built to scale.
I would look at Jepp or JPype instead of using IPC for this. I would avoid Jython since loading the C/C++ libraries into Java would probably be harder than into CPython.
1) Do you think that would work for cpu-demanding and highly repetitive tasks? Or would the overhead added by the pipe-communication be too heavy?
Depends on your task. If this is a typical NLP app where you have a large model loaded in memory and you only communicate relatively small pieces of data (strings in, label sequences/parse trees out), it may work. Pipe communication is hard to get right, though, since there's a lot of buffering and synchronization issues you have to tackle. Python is a very good glue language, but it doesn't solve everything.
2) Is there any other (preferably simple) architecture that you would suggest?
Make your NLP components services and connect to them via REST interfaces. There are off-the-shelf tools that do this, e.g. CLAM. Pyro and SPIRO make communication between Java and Python even more direct and might be easier to use than HTTP/REST (but YMMV).
The parts that are written in C/C++ can also be integrated with CPython using Cython. Don't start implementing things in C or C++ because you think they'll be faster, though; you can also implement them in Python first, then see if you can get the desired performance with NumPy and/or Cython.
I have a question to ask: suppose I create a extensible software application with a plug in architecture, so that new applications can be integrated in this tool. If a new application is written in a different language and needs to be integrated in this application of mine, do I need to use tools such as SWIG and the Java Native Interface (depending of the languages used of course)? If not, what do I need?
suppose I create a extensible software application with a plug in architecture
Okay. You've written some code. I'll pretend it's in Java because you mention SWIG and JNI.
If a new application is written in a different language
How did this happen?
You planned for it. In which case, your application had an API that supported at least one additional language. "different language" doesn't mean much because you -- as developer -- need to decide what languages you'll tolerate. New languages aren't a random event. They're something you designed for.
You didn't plan for it. In which case, someone else -- contrary to your design -- is demanding another language. A language you did not design for.
Choice 1 is the most common. You planned for specific languages, and wrote specific API libraries for those languages. You wrote -- in those other languages -- the necessary API library that would make those languages work with your application.
You probably don't use tools such as SWIG and the Java Native Interface to create this API. If you want to support Python, you'd use a bunch of Python tools to permit Python programmers to use your application.
Choice 2 is less common. Either you didn't plan, or you have someone who insists on writing their own API library based on their choice of language.
You probably don't use tools such as SWIG and the Java Native Interface to create this API. If someone else wants to support Python, they'll use a bunch of Python tools to use your application.
The real question is not "do I need to use tools such as SWIG and the Java Native Interface (depending of the languages used of course)?" Or anything like it.
The real questions are
How do I choose an additional language to support above and beyond the implementation language? You appear to be using Java. You want to support more languages than Java. [Just guessing -- your question is incomplete.]
Answer: Toss a coin. Whatever languages you think the marketplace will demand. C is popular. So is C#. So is Python. Pascal not so popular.
How to I write my framework to permit "foreign" languages?
Answer: This is challenging.
To write application which allows multiple language interfaces you have to do a bunch of things.
Know a bunch of languages well enough to know their limitations.
Write your application so that the API can be successfully used by all your various languages.
Have very, very clear use cases and unit tests to prove that the application really works that way.
Avoid language-specific features. Avoid hardware-specific features. This means avoid all "native" or "primitive" data types in the API, and use real standard types. Often Unicode strings represented in UTF-8. The kind of thing that is universal and ubiquitous.
Avoid quirky non-standard protocols. HTTP, FTP and the like are so widely adopted that you can't go too far wrong with these as an interface. They can be slow. For better speed, you'll can create named pipes between the "foreign" code and your application. If you want the foreign code to have "direct" access to your framework, think twice.
Or, do what many API's do and embrace C as the "lingua franca" of interfaces. Design everything to be callable from C programs. Use C conventions and C-friendly data types. This has limitations, but many people do it.
I'm interested in programming languages well suited for embedded programming.
In particular:
Is it possible to program embedded systems in C++?
Or is it better to use pure C?
Or is C++ OK only if some features of the language (e.g. RTTI, exceptions and templates) are excluded?
What about Java in this domain?
Thanks.
Is it possible to program embedded
systems in C++?
Yes, of course, even on 8bit systems. C++ only has a slightly different run-time initialisation requirements than C, that being that before main() is invoked constructors for any static objects must be called. The overhead (not including the constructors themselves which is within your control) for that is tiny, though you do have to be careful since the order of construction is not defined.
With C++ you only pay for what you use (and much that is useful may be free). That is to say for example, a piece of C code that is also C++ compilable will generally require no more memory and execute no slower when compiled as C++ than when compiled as C. There are some elements of C++ that you may need to be careful with, but much of the most useful features come at little or no cost, and great benefit.
Or is it better to use
pure C?
Possibly, in some cases. Some smaller 8 and even 16 bit targets have no C++ compiler (or at least not one of any repute), using C code will give greater portability should that be an issue. Moreover on severely resource constrained targets with small applications, the benefits that C++ can bring over C are minimal. The extra features in C++ (primarily those that enable OOP) make it suited to relatively large and complex software construction.
Or is C++ OK only if some
features of the language (e.g. RTTI,
exceptions and templates) are
excluded?
The language features that may be acceptable depend entirely on the target and the application. If you are memory constrained, you might avoid expensive features or libraries, and even then it may depend on whether it is code or data space you are short of (on targets where these are separate). If the application is hard real-time, you would avoid those features and library classes that are non-deterministic.
In general, I suggest that if your target will be 32bit, always use C++ in preference to C, then cut your C++ to suit the memory and performance constraints. For smaller parts be a little more circumspect when choosing C++, though do not discount it altogether; it can make life easier.
If you do choose to use C++, make sure you have decent debugger hardware/software that is C++ aware. The relative ease with which complex software can be constructed in C++, make a decent debugger even more valuable. Not all tools in the embedded arena are C++ aware or capable.
I always recommend digging in the archives at Embedded.com on any embedded subject, it has a wealth of articles, including a number of just this question, including:
Poor reasons for rejecting C++
Real men program in C
Dive in to C++ and survive
Guidelines for using C++ as an alternative to C in embedded designs
Why C++ is a viable alternative to C in embedded systems design
Better even at the lowest levels
Regarding Java, I am no expert, but it has significant run-time requirements that make it unsuited to resource constrained systems. You will probably constrain yourself to relatively expensive hardware using Java. Its primary benefit is platform independence, but that portability does not extend to platforms that cannot support Java (of which there are many), so it is arguably less portable than a well designed C or C++ implementation with an abstracted hardware interface.
[edit] Concidentally I just received this in the TechOnline newsletter: Using C++ Efficiently in Embedded Applications
More often than not in embedded systems, the language you're programming in is determined by which compiler is actually available.
If you're hardware only has a C compiler, that's what you're going to use. IF it has a decent C++ compiler than there is really no reason to prefer C over C++.
I would dare say that Java isn't a very popular choice in embedded systems.
Embedded programming these days spans a large range of applications.
Roughly, it goes from sensors/switches up to complete security systems.
You should base your language on the complexity and the hardware resources.
It is 1 of the choices next to HW (CPU,...), OS, protocols,...
possible choices:
switches: assembler
router-like devices: C and/or C++
handhelds: Java or QT/C++
complete systems: combinations C and/or C++ with python
Or is C++ OK only if some features of the language (e.g. RTTI, exceptions and templates) are excluded?
It's good to be thinking along these lines. Compile-time complexity is not a big deal, but runtime complexity has a resource cost.
C++ facilitates class/namespace modularity (e.g. method foo() in more than one context) and instance modularity (member field bar belonging to more than one object), both of which are a big advantage in software design. There are also features like const, references, static casts, and templates, which can help enforce constraints and have little or no runtime cost.
I would not exclude templates. They're complex to think about and you need a compiler that handles them well, but the resource cost is almost all compile time -- what's going to "cost" you is the fact that each time you use a template with different class parameters, you produce a new set of code to instantiate member functions. But you would almost certainly have to do the same thing without templates. Furthermore, templates allow you to design and test libraries for general circumstances, in separate files that are instantiated at compile time rather than link time. Just to clarify that: templates allow you to have a file A.h that you test. Then you use it with file B.h or B.c to instantiate it at compile time. (A library would be linked in rather than compiled, and this makes it less flexible -- template methods can be optimized out so they do not incur a function call.) I've used templates in embedded systems to implement CRC code and fixed-point math: I can test the general code, put it in version control, and then reuse it multiple times by writing a simple class that derives from a template or has a template member field. The classic example of course is STL.
RTTI and exceptions: these add run-time complexity. I don't have a good idea of the resource cost but I expect RTTI would be fairly simple (just adds a type tag, costing extra space) whereas exceptions are probably beastly, involving stack unwinding.
virtual functions: I used to rule these out because of the memory + executiontime costs (minimal but still there), as well as the complexity of debugging, but they allow you to decouple objects from each other. If you don't use virtual functions, when an instance of one class (e.g. Foo) needs to execute code associated with an instance of another class (e.g. Bar), then the first class needs to know everything about the second (to compile Foo you need to have static linkage to all the methods in Bar) -- this adds a lot of tight coupling.
dynamic memory allocation: this is another big thing (that is in C as well), which we avoid like the plague at my company -- not only are there all sorts of errors that can arise, but the big runtime cost is the allocator/deallocator, and you've got to be willing and able to know what that cost is and accept it.
edit: I would love to use Java instead of C++ in the embedded world. Unfortunately my choices are limited and the runtime resource costs (code size, memory size, garbage-collecting time constraints) are too high in the space that I work in. My reason for using Java is less because of its runtime goodies and more for the fact that its software design is much cleaner, and the tools are much better (OMG! refactoring! woohoo!)... the key to me seems to lie with two things, which make C/C++ feel very clunky in comparison:
that everything is an object and all the methods are virtual, so you can lean heavily on the abstractions of interfaces.
the interface/implementation separation in Java is not this clunky ugly .c/.h file splitting thing that makes compilers so slow. In constrast, I use Java in Eclipse and it automatically compiles the code right as I edit it. This is huge! I find most of my errors right away. In C/C++ I have to wait for a whole compile cycle.
Someday I hope there will be a language between C/C++ and Java that provides the advantages of Java for software development, without requiring the bells and whistles that make Java so attractive for desktop/server applications but unattractive in most of the embedded world.
Both C and C++ can be used on embedded systems. If you do limit the features of C++ that you use, then it is going to use roughly the same speed and space as C. As for using these additional features, it really depends on your constraints. For example, if you are making a real-time system, then exceptions might not be a good idea, simply because considering the propagation time for exceptions and all the paths through which exceptions can possibly propagate can make hard real-time guarantees quite tough (although, then again, the ACE / Tao real-time CORBA implementation uses exceptions). While templates and RTTI can lead to larger programs, there is a lot of variability in embedded systems, and so depending on your resource constraints, this could be perfectly fine or unacceptable. The same goes for Java. Java (well, technically, the Java programming language with a subset of the Java API) is running on Android, for example, using the Dalvik VM. J2ME runs on a variety of embedded devices. Whether it will or will not work for your application, depends on your particular constraints.
c is the most common language used in embedded systems.
However, I think C++'s future lies in the embedded system domain. I think the C++0x standards will help in that resepect. So I wouldn't be surprised to see C++ used a lot more in this field.
I think you already have a great answer by Clifford, but I'll add my experience to it. As was pointed out, the type of embedded system is the main driver. In Defense/Aerospace, C and Ada are the most popular embedded languages I encounter. Although as time goes on, I am seeing more C++ as the model based development becomes popular with the tools such as Rhapsody. In the jobs listing, seeing requirements for Object Oriented Design experience also leads me to believe that the market is slowly shifting to follow the trends of mainstream development.
If you're really interested in embedded development, I would start with C. It is pretty universal. Almost every OS, including real time OS's like Integrity, Nucleus, VxWorks, and embedded Linux, has a compiler and tools for it. The things you'll learn about pointers, memory management, etc... will translate into C++ development well in the embedded world at least.
As for Java, if you're interested in development for mobile platforms like smart phones, this is a solid choice (Android comes to mind). But in the world of Real Time Operating Systems, I haven't seen it.
On that note, that brings me to my last point and advice. If I wanted to jump into embedded programming (which I did just 4 years ago), I would focus on learning C from a low level point of view as mentioned above. Then, I would also learn what makes real time programming so difficult/different. I found the book below quite good at teaching you to think like an embedded programmer vs. an application developer. Good luck!
An Embedded Software Primer
It really boils down to what hardware platform you're operating on and hence what software platforms are open to you. For a lot of recent embedded kit - designed around a system-on-chip, a megabyte or two of RAM, a few devices - you really want a small operating system to manage the low level hardware while you concentrate on your application. Your choice of OS then constrains your available language set.
It's certainly possible to use C++ in the embedded space, but the full feature set of the language takes a lot of work to port correctly. For example, eCos is implemented in a mixture of C and what you might call the structural aspects of C++; support for RTTI, exceptions and the STL are lacking in the free version, though there are people working on this (and a commercial port available).
Similarly, it's possible to use Java - I know, I've ported a JVM to an embedded environment; it wasn't fun - though you usually get a cut-down Java language configuration, often something based on J2ME.
I have been developing applications based on C# (.net) and Java (J2EE) for the last 3 years.
But now I feel, Java, C# makes you lame (from learning point of view) and you can develop your apps quickly but you fail to understand the basic underlying concepts of programming.
So, I am trying to learn C++, but I find it a little "confusing" due to pointer, multiple inheritance, some conventions and other concepts of C++ which don't exist in Java. So, what do you guys suggest? How should I feel about it?
Thanks
PS: I am a student, so have all the time in the world and actually shift.
In my opinion, you should learn C first in order to properly understand the base upon which C++ is built. Pick up a copy of "The C Programming Language" by Kernighan and Ritchie, widely considered the best reference on the language, and start reading through it. Once you fully understand C, you'll have the low-level base you need.
C++ is no more "basic and underlying" than any other modern programming language. It has a model of a computer (a flat memory address space), but the OS and CPU merely simulates that model using many layers of caching and paging, so it's not "real". The result is that the same operation may sometimes take 1000s of times longer to complete than at other times.
Also modern C++ has lots of powerful abstractions that have no more direct relationship with how a computer works than do the abstractions provided in Java and C#. The OP mentions multiple inheritance - clearly no more elemental than inheritance in other OO languages. Many other features of C++ omitted from Java are high-level abstractions (or allow you to build them) and so in some ways Java is the more low-level language. In Java the meaning of operator symbols is always the same, whereas in C++ a simple == might build an object that will later be used to generate a SQL expression instead of being executed in-process.
The JVM and CLR runtimes are (almost certainly) written in C and/or C++, so in that sense obviously they happen to form layers today. But at the C/C++ layer you will still be working in an abstraction that is not "how the machine really works", so you'll really just be learning a different set of abstractions, rather than "reality". And an OS (or indeed a hardware chip) can be designed specifically so that JVM or CLR like runtimes are the native low-level layer of the system; on such a system it would be the C/C++ runtime that would require a "high-level" (expensive) emulation layer in order to work.
So it is probably not worth trying to learn how to program in "reality". No one really does that these days; it's a waste of time. You're better off learning about how programming abstractions help you to write correct programs. If a language makes life difficult for you, that doesn't prove you're doing the "real thing". It just means you picked the wrong language for what you're trying to do.
I disagree with the sentiment that you need to learn C or assembly language first. C++ and C may be similar in theory but are very different in terms of practical use. One gains little to nothing in the way of C++ idioms by using only C, and while it is good to have practical experience in multiple languages, it's an exercise in futility to specify prerequisites in language learning. I think the best way to learn the concepts of programming is to sit down with someone who understands them well and just talk about it, be that on StackOverflow, in forums, or, if you're lucky, in person.
At the end of the day, I think programming really isn't all that hard, and you may need someone to explain it right just one time to have everything click. It's all about rehashing the same simple concepts over and over to build complex and beautiful machines.
For learning c++ I reccommend reading C++ for Java Programmers by Mark Allen Weiss. It helped me alot when moving from Java to C++ as it is very good at highlighting the differences between the languages.
But, now I feel, Java, C# makes you lame (from learning point of view) and you can develop your apps quickly but you fail to understand the basic underlying concepts of programming.
If you're trying to learn the concepts of programming, rather than machine architecture, there's not much benefit to learning C++. I would suggest going with something different from Java all together. A Lisp variant, perhaps.
How To Design Programs is a pretty good book.
If you want to understand the underlying concepts of programming languages, I would suggest a book such as John Mitchell's Concepts in Programming Languages. Follow this up by writing a few parsers/interpreters for simple languages. Another good resources is SICP, which is specific to Scheme (a LISP dialect), and available in full here. Once you've learned a few languages, it doesn't take too long to pick up the syntax and semantics of a new one (the core libraries on the other hand, can take quite a while to be familiarized with).
If you want to learn about how today's computers work, I'd recommend learning C and reading books such as Tanenbaum's Modern Operating Systems. C is useful in this context mostly for reading systems level code. Implementing a (very) simple operating system can be incredibly educational. However, something as simple as implementing a basic shell (like bourne shell, except simpler) is probably a better place to start. I'd also recommend learning about how networking works specifically, since it's such an integral part of modern computer systems.
C and C++ make some basic underlying programming concepts more evident, but they weren't designed by God. I'd second the suggestion to study the actual low-level systems behind your low-level code: operating systems, compilers/runtimes (try "Essentials of Programming Languages"), and machine architecture.
P.S. In general it may be better to study C++ on its own, rather than starting with C, but for your particular purpose -- getting more intimate with low-level, unsafe constructs such as pointers, after already learning Java -- I think it's better to start with C (and K&R) where these are front and center.
I would suggest learning assembly language first. This will give you a very solid foundation in what is happening at a low level. This will also help to reinforce the idea that "everything is really just an address".
Taking a class which focuses on assembly language is advisable since it will "force" you to learn it (personally, I don't think ASM is /that/ fun, but it was worthwhile [and a requirement for graduation] for me to take the class).
After you know assembly, go on to C and C++.
Have a lot of fun!
It sounds like you're avoiding the first mistake most people make, which is assuming the new language is the same as the old one. C++ is different and should be learned as a neww(-ish) language.
A reference I would suggest would be C++ How to Program which is used at my University for the introductory C++ classes.
After that, then look at previous Java software that you have written and seeing how you would translate them to C++. The syntax can easily be referenced from CPlusPlus.com. While doing this, it is important to keep in mind what all the different syntax represents, and how it changes what is going on in the software (i.e. The differences between the two languages). This has the added benefit of allowing you to see how the underlying architecture is represented for both languages (and for programming languages in general). I don't know of a good book that explains how programming languages work under the covers, or I'd recommend that.
If you are, however, interested in learning how programming works, then Assembly language would be a good place to start. Assembly language for Intel-Based Computers is what I used to learn assembly language and it was very useful.
Assembly Language.
Start with the Z-80. Then add 'x86. Then try 68000. Then the TI 320 series of DSP. You might also wish to add the Z-8. Just to see how different machines do it.
If you really want to know more about low level programming I would recommend learning C and Assembly. C++ is much more complex than C but really doesn't give you much more insight into low level concerns. It might be interesting if you want to learn about what type of concepts and constructs a programming language can be made up of though, since C++ has a lot of them.
There is also a lower level of your VM you don't seem to know yet and which you might want to explore. To learn about the internals of Java I would recommend learning how to program the JVM in (Java) Assembly language. Jasmin (http://jasmin.sourceforge.net/) is the reference assembler/syntax for this kind of programming. Another great resource is the Java Language specification (http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html) which contains a lot of Java internals. When you have learned C you can also use some lower level APIs the JVM provides (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/) that allow you to retrieve low level information about a running JVM and write interesting things like debuggers.
If you learn this stuff and do some hacking on your own you will learn how the JVM works and what the compiler actually puts into your class files. It's also very likely that you discover some new things about the Java programming language itself you didn't know before even if you think you know everything about it.
You can also program the .Net VM in assembly by the way.
I think you should start with C, but not as a necessary preamble for learning C++. Rather, for learning C. In other words, while you learn C put your efforts into learning the language, feeling the philosophy of the language and focusing on letting it sip into your skin. Be a good C programmer and you will be a good programmer, period. Not just a good C++ programmer -- this has nothing to do with learning C -- but a good programmer.
There's another reason for learning C first. It's easier than C++, much easier than C++, and it bridges well to C++ (in contrast to Java, which doesn't in all aspects but the most superficial object-oriented ones). I'm not talking about the syntax similarities: I'm talking about low-level programming. I'm talking about the concepts of pointers, which exist as themselves and in the form of iterators in C++. You can pass around functions in C, and you can pass around function objects in C++. C is fast to learn, and it will warm you up very effectively.
Learning C will also eliminate the fear of free functions some pure OO programmers tend to have. C++ is a hybrid language, and C truly is a subset of C++, not just by syntax but by philosophy as well.
Start by getting yourself the K&R book and drinking it through. You won't regret this.
Whatever you start off with, my suggestion would be dump the full fledged IDE's. Use good text editors (vim/emacs)
The learning curve is better when using text editors since everything needs to be written on your own. No prompts and no pre-written code.
You have all the best answers above, in anycase. :)
Ivar
Set up a performant C++ compiling environment such as Microsoft Visual C++ 2008 Express and go through all links in Bjarne Strousrup's The C++ Programming Language site, beginning with C++ Style and Technique FAQ.
If you are experimented in any other language you don't need more :-)
Learn C and C++ at the same time, I'm talking from experience here. Very often I come across code that mixes C and C++, so it's better to know both and their differences. Pick up K&R for C (understand pointers, header files and manual memory allocation and cleaning...which are not used by Java!) and any decent C++ beginner book (I picked Prata, but whatever you are more comfortable with). Practice the same examples doing versions of C, C++ in a sequential fashion, object-oriented (OO) fashion, generic/template fashion etc. C++ has a larger standard library than C: templates, STL containers (no need for pointers, but you can do pointer fine tuning writing your own container), threads (since C++11). You can always use C if you have no choice (or Boost libraries), any C++ compiler will allow it.
If you come from Java you should already know OO concepts for C++, and, perhaps, some generic programming as in C++ templates. C++ is mistakenly regarded as an OO language, but it's more than that. BTW, objects are a dynamic concept (runtime), whereas templates are static (compilation time), so learn the language CONCEPTS, not just the syntax! Once you learn the concepts read Stroustrup's book (he created C++) to learn his philosophy for the best design rules for C++ code.
Learn the latest C++ standard (C++11) as it adds many new things to the language (auto, nullptr, threads, lambda functions, new containers, etc.). Last but not least, please use Doxygen in C/C++ the same way you used Javadoc....there is nothing worse than undocumented, unreadable code no matter what language you're using.
Learn Forth. It has better Objects. And it is a virtual machine. Unless you want a real machine see Green Arrays or Sandpiper/John Rible for that.
Free threaded interpreted versions are all over the 'net. For practice. When you understand it write your own Direct Threaded version. Or see Forth Inc and buy one for your machine or use their free windows version.
Java is a Forth/C hybrid so if you want to go Java you will have some of the stuff under your belt.
Education:
Starting Forth - Brodie
Thinking Forth - Brodie
The second is excellent for any language because it is the best book on factoring I know. Free Versions of both on the net.
If you want to do a hardware/FPGA Forth Stack Machines: The New Wave by Koopman
All the above books are free on the 'net.
Do you know of a runtime written in Java/J2ME, that is capable of reading and executing a script/binary file?
Wikipedia has a complete list. However, you sound like you're probably interested in Jython and JRuby.
I wrote just such a language designed to be small enough for J2ME, and to not use reflection/code generation/etc...
http://www.hecl.org
It's open source under a liberal license, so you're welcome to take it, study it, include it in your own programs, or hack it to make it behave like you want.
For 'regular' Java, there are other languages that do more and are faster and more complete.
I know of an x86 emulator written in Java, JPC
Many JVM Languages - Clojure, for example. There are pretty much hundreds of JVM languages floating around, most of which were implemented in Java - Scala, Rhino, etc.
In terms of unique languages, the major ones are Clojure and Scala. Additionally, there are ports of many major languages to the JVM platform, mostly high-level languages. These include Ruby -> JRuby, Python -> Jython, and JavaScript -> Rhino. A more complete list is here.
This is an impressive list of programming languages for the Java virtual machine :
Programming languages for the Java Virtual Machine JVM
The problem is that j2me can be too limited in its use of reflection to enable this, so you need to investigate your specific target.
In terms of java in general, there are many, such as JRuby, Beanshell, Jython, etc.
I just listened to a Software Engineering Radio podcast where a Sun developer talked about Maxine which is a JVM that is mostly implemented in Java itself. It was a very interesting interview and technology.
So it's feasible that someday Java itself (meaning the standard JVM) will be implemented in Java much like C compilers are written in C (after a bit of bootstrapping).