Slashdot Mirror
Cairo 2D Graphics May Become Part of ISO C++
An anonymous reader sends this news from Phoronix:
"The C++ standards committee is looking at adopting a Cairo C++ interface as part of a future revision to the ISO C++ standard to provide 2D drawing. Herb Sutter, the chair of the ISO C++ standards committee, sent out a message to the Cairo developers this week about their pursuit to potentially standardize a basic 2D drawing library for ISO C++. The committee right now is looking at using a C++-ified version of Cairo. Sutter wrote, 'we are currently investigating the direction of proposing a mechanically C++-ified version of Cairo. Specifically, "mechanically C++-ified" means taking Cairo as-is and transforming it with a one-page list of mechanical changes such as turning _create functions into constructors, (mystruct*, int length) function parameters to vector<struct>& parameters, that sort of thing — the design and abstractions and functions are unchanged.'"
C++ stopped being a fully-humanly comprehensible language a long time ago. Might as well just add more crap to it like it's going out of style.
This is redundant. High level concepts like drawing graphics are always going to be system dependent, and today's operating systems come with them already. I don't see why having this as part of the C++ base library benefits..
Cairo is a great library, I've used it and found it very easy, but it's not remotely approaching a standards-quality design. The closest I've seen would be Anti-Grain Geometry, which makes phenomenal use of templates.
The second link goes to the wrong article.
Here is the correct link
i sincerely hope cairo itself remains 1. pure c and 2. as a project, entirely unconstrained by complaince to whatever 'standard' these c++/microsofty goons want. if they want to take a snapshot of cairo's api as a model for some c++ api, fine, whatever, couldn't even stop 'em if we tried. though the effort would be better spent finding more active maintainers for cairomm.
but cairo underlies current versions of major linux gui toolkits. i can't help but view this as some sort of convoluted gambit on microsoft's part to infest it with bureaucracy and c++ architecture astronautism and eventually seize control of the direction or just kill it.
Link 2 is for a different story.
I can see the desire to have common UI/graphics/etc capabilities in a standardized form, but why mash this into C++ itself - why not make a new C++ library of some kind that contains these higher level features.
The way I see it, this is a push to bring C++'s standard library to be more feature aligned with say, the .NET CLR or the standard java classpath - but that's just it, the CLR is not part of the .NET runtime library (mscorlib), it's an additional library - same in Java land.
This should be part of a "Standard C++ Graphics library" or something, just like the STL isn't part of the standard runtime.
One of the hallmark problems of design-by-committee is that they extend languages for the sake of doing fun things, not because people need it.
While everyone needs containers (like vector/hashmap), nobody needs a simple graphics library. There is practically no hardware out there that doesn't have some sort of hardware accelerated graphics and simple operations just make no sense there.
So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.
"[Cairo] is written in C and has bindings available for many programming languages, including C++, [...]"
Haha, the irony. :)
Ugh. While these are useful features for an API, why do they belong in a standard library of a general purpose programming language?
Graphics libraries and their APIs are Here Today, Gone Tomorrow. The hot thing today will most likely be superseded and irrelevant in 10-15 years time.
the "sent out a message to the Cairo developers this week" link above points to the knight's landing page from another story...
Is there anything it cannot do?
The old C++ looks better and better as they nail every bit of crap they can find to her wretched offspring.
Hey let's get a standardized vector and 2D drawing library going! Fuck the hardware or implementation details which indicate you'd be better off not limiting the dimensions to 2. Never mind the fact that we'll be filling triangles on a GPU for any sort of efficiency at all. Nope. Fuck starting at the actual primitives present and working up from there, let's do the top-down approach yet again -- When the performance conscious folks include messed up limitations, like the Diamond Inheritance pattern (Which has no reason to exist, variable placement should be virtual too, dimwits).
Yeah, I'll stick with C. At least it doesn't pretend to do anything but present the Von Neumann architectural constructs to me and let me build my OOP, etc atop them. It's still not optimal because it has the moronic assumption that functions should be on the stack and not the heap -- thus hindering or outright preventing closures, co-routines, and arbitrarily limiting recursion despite the system's available RAM -- but it's miles beyond C++ in terms of idealic design splattering all over the hard brick wall of reality's implementations. I mean really, if you can't use method overloading properly with templates and polymorphism then the language is broken by design, and there are no complete implementations.
Hey! I got an idea. You know what would be nice in C++? How about a standardized ANSI terminal interface, like VT100 -- Get ncurses into the spec. Oh! And you know what else? How about RMI! Yeah! Oh oh oh!! I got one I got one! INTER-fucking-FACES for IPC! Yeah! So you could query a program's interface and pass data between processes transparently in a language independent way -- and the doc comments could be lexical tokens too, so that if the .dat file was present even a terminal mode program could query a program's usage without needing a manually constructed manpage, and other programs could implement the same interfaces allowing us to assemble programs from sets of features. You know, something smarter than STDIN and STDOUT and a char**? Something actually fucking useful for a damn change?
Cairo graphics? Why tie C++ to Windows 95?
Cairo graphics? Why tie C++ to Windows 95?
Java, C#, and JavaScript all have graphics and canvas component libraries. All these libraries render graphics differently on different systems. In the C++ universe, programmers have had to use 3rd-party libs like Qt, so a C++ standard library for graphics is long overdue.
Obviously this is early stages, and I am not outright opposed to the concept of having a standard vector graphics library. The creation of formatted documents (pdf) and images is a low level and common task. The productivity of many programmers could be increased by having a standard library which can be easily linked against.
However I do feel like this opens up a can of worms. Will they also include a FreeType interface to support text output? What backends will be included by default?
A vector graphics library without the ability to handle text seems seriously crippled. On the other hand choices for including text output basically come down to:
Graphics libraries and their APIs are Here Today, Gone Tomorrow. The hot thing today will most likely be superseded and irrelevant in 10-15 years time.
Glass-TTY interfaces, like the implementations of stdin and stdout in C++ compilers targeting PCs when not redirected to a file or pipe, have for the most part been superseded by GUIs. At least Cairo would provide a starting point toward a bare-minimum image manipulation and GUI component that a C++ program can expect, much as Tkinter does for Python.
One can implement coroutines in C.
Create a standard interface and leave the actual implementation to be platform dependent. In this case rendering results will differ depending on platform.
C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.
I for one welcome our new 2d graphics overlords
the STL isn't part of the standard runtime
I thought apart from <iostream> and friends, the STL was the C++ standard library. Are you by any chance referring to the difference between a "freestanding" implementation and a "hosted" one, where a "freestanding" implementation is permitted to leave out standard libraries?
Is there anything it cannot do?
Garbage collection.
It can, tho. It's not yet in the standard but there are actual garbage collectors for C++.
Skip to 1:15:00 and watch Herb Sutter explain why they're doing this stuff.
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond
I hate reading the comments on Slashdot.
Conservative ones, yes.
But accurate ones? Multithreaded? Without "stopping-the-world"?
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Some people see the design of the C and C++ libraries, where file IO is standard and everything else is system dependent, and then start defending it as if it were some kind of blessed design that shouldn't be changed.
It's great that they are finally considering adding more capabilities to the standard library. That will greatly help portability.
If you need to program a microcontroller, C++'s standard library is already too big (files, dynamic memory allocation, etc.), but if you want to make an PC app for end-users, it's too small. I don't see why it coulndn't be expanded.
As someone who learnt C then C++ as my first languages, I agree. If there's such a thing as too high level, we're reaching it.
I'm self-taugh but I know how the metal works and made my own toy OS. Then learning other languages was a piece of cake.
Languages like C#, Python,etc are so easy it almost feels like cheating.
C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.
Right. Except that is complexity exposed to the programmer and easily dealt with via int32_t, uint32_t .etc. This is inconsistency exposed to the user.
HOAX
The implementation-defined precision of floating-point types (float, double, and long double) is inconsistency that could end up exposed to the user if the last significant figure is displayed or if a rounding difference causes an if statement to go one way or the other.
For me garbage collection is more annoying than its worth.
Any programmer worth his salt is going to make sure his objects are properly cleaned up anyway regardless of garbage collection, but unfortunately most "programmers" these days don't seem to be worth their salt and consequently high-level languages have to compensate for bad programming practices.
This is the most asinine idea I hace ever heard of. 2D graphics belongs in a separate library, not part of the language standard. Seriously, I want some of the crazy weed the proposer is smoking.
Since when do libraries become the "standard"?
Since ANSI C89 standardized things like fopen()?
There was a paper in committee that would make it possible (authored by Boehm, no less). It didn't live to see C++11, though.
Most modern GC based languages can be faster and reduce memory fragmentation with heavy allocate and deallocate work loads, compared to C/C++. The trade off is less control and more jitter, but the benefit is potentially higher throughput. Without heavy micro-optimizations and essentially your own GC, C/C++ cannot compete.
.Net with ASync and tasks will give most other languages a run for their money, it has better scaling than most others. It heavily focuses on reducing context switching and increasing data locality.
What it comes down to is the GC keeps working memory highly compacted in a very efficient way, such that it allows memory allocations to be nothing more than incrementing a pointer. No searching for free space involved. It can also do background compaction while your program is running, and on different threads. These things are less efficient than micromanaging this stuff yourself in C/C++, but the amount of work involved makes it an expensive optimization, which is virtually free in a GC language.
I'm not trying to say that GC languages are faster in general, but in many common work loads, the GC compensates enough to make a GC language near C/C++ speeds. If I can write a program 5x faster, have fewer bugs, and have it running 80% the speed, that's a win.
Most of the time, programs are not CPU or memory limited, just limited by bugs and development speed. The more popular programs are actually heavily IO bound.
Many C/C++ programs have negative scaling with lots of IO. Once you've hit peak performance, it actually gets slower instead of maintaining current rates.
Is there also a GUI toolkit such as GTK on its way into ISO C++?
I think it takes more than 4 years to turn someone with no experience into a mediocre programmer. Some of that time, best spent away from profs. A bunch of the people going to CS have experience prior college, and it gives them an edge.
I think he's referring to signed integer overflow conditions, which don't behave as most people would probably expect and aren't trivial to handle correctly.
but how do I interact with the program? Will the new standard include anything like mouse input?
Industrial space for lease in Flatlandia.
Most modern GC based languages can be faster and reduce memory fragmentation with heavy allocate and deallocate work loads, compared to C/C++.
Suspicious sounding statement. Such things are ususally based on writing C++ like java (i.e. new everything). C++ uses stack allocation for very much stuff, and that is free (the pointer increment is already done on function entry) and 100% guaranteed fragmentation free.
If I can write a program 5x faster, have fewer bugs, and have it running 80% the speed, that's a win.
Why would C++ be slower to develop? You're confusing garbage collection with "memory management". C++ does memory management very well. I can't recall the last time I had a leak and that's not because I'm super awesome.
Most mm is just plain invisible in C++, since stuff is deallocated on scope exit. For everything else (nearly) there's reference counting. Reference counting doesn't work if you have general (i.e. cyclic) mutable graphs. I'm not sure I've ever had one of those.
SJW n. One who posts facts.
It's just a joke. Isn't it? ...
C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.
Right. Except that is complexity exposed to the programmer and easily dealt with via int32_t, uint32_t .etc.
He said signed integers, not integers in general.
He's referring to the fact that the following code:
#include <limits.h>
int main() {
int abc = INT_MAX;
abc++;
return 0;
}
will start World War 3 by launching everyone's nuclear warheads simultaneously.
The C standard's "undefined behavior" is a load of bullshit on toast that does not even try to restrain the possible results. Does it cause a platform specific interrupt, does it work but produce a garbage value, does it wraparound to negative numbers, does it do any of these three things as defined by the platform hardware? Doesn't even bother to try and restrict the outcomes, at all.
Why would C++ be slower to develop?
Header/Source duplication? Long compile times (pulling thousands of headers each cpp file)? Hard to debug memory corruption issues? Good library design requires that you at least think about ctor, dtor, copy-ctor, operator=,std::move, etc. for every class and mutability/const-correctness for every method - C++ is a very complex language and getting everything right takes time.
Such things are ususally based on writing C++ like java (i.e. new everything). C++ uses stack allocation for very much stuff, and that is free (the pointer increment is already done on function entry) and 100% guaranteed fragmentation free.
std::string manages a pointer to the heap (unless your string is "small"), iostreams have a pointer to a buffer object also on the heap, vectors, lists, sets, maps, all have pointers to the heap. We might continue with things like std::function,thread,etc. but you might get the point that taking the c++ standard library as an example of C++ style code quite a bit of your objects reserve memory on the heap - it just ends up managed behind the scenes (RAII) and avoids a single indirection and an increment compared to a good garbage collected language where new is implemented to use a pointer increment.
C++ code can be optimized quite a bit to have a great speed advantage and you can define classes that do not use heap memory (you can even use custom allocators with a lot of classes) but that is not handed to you on a silver platter unless you only work with simple struct like zero inheritance, fixed sized objects.
There's an ISO standard for 2D graphics already called GKS. All that's needed is a C++ binding.
The link does not point to the mailing list, but to something completely different.
Rather than make C++ appeal to people who probably should stay in their high level languages, I think they should be putting their time into productivity. As much as I liked to spend time in C++ not writing any actual code playing with macros, templates, etc. in addition to finding new ways to hang myself; I don't find myself doing C++ anymore - I just don't like fooling around enough (yet I still do perl for fun; does that make sense?)
I think all the man power needs to be put into technical development not fluffy graphics libraries. I'm not as big on portable compiling as I am for some kind of binary format and linking system that would make it easier for an old program to run on a newer OS without needing all these virtual machines. Not exactly Google's NaCl (or whatever it's called) or a byte code but an attempt to address such issues. Not for java style portability, but something so legacy software can run without easily breaking (which it can do even with Java over time) and yes, it would get into OS turf... just like many other languages do as far as how library code is linked and loaded.
It's been a long time away for me... I've not looked at C++11 but here is a wishlist:
Text output needs improvement more than we need graphics. More debugging, logging, dummy functions, test case related standardization - more dynamic binding, runtime introspection features and other things that go against the initial design goals but ONLY in limited contexts, such as debugging and testing; thereby, retaining the intent of C++ but unleashing it for development purposes (such as a console or recompiling running code and replacing it.) This would fit in with their trend to be all things to everybody without changing/breaking the past decisions. It would be difficult to implement in some cases; but it's a debug mode.
I've always wanted named parameters; which could have been handled completely on the compiler side without run time penalty. ADA style typing was always appealing, for some things. How about something like JSON object literals? Native RegExp literals? A built-in parser generator (grammar definitions that produce parsing code you don't need to mess with.) Easier internationalization.... forget drawing lines, give me a great way to print "hello world" in many languages; or localize time and dates. A Money class to avoid common errors (use of float.) Configuration API. Apache's memory pool system seemed cool to me (APR,) garbage collecting not so much. Parallel processing features (if not already some, work on more-- again thinking of productivity and debugging.) We still don't have a multiple level break yet, correct? (like an exception but more limited in scope and as fast as a goto. Don't freak out, I didn't endorse goto.) I wouldn't mind a way to define a graph literal... I assume we must have a String object that handles unicode issues... we didn't last time I touched C++. Unicode source files... that allowed use of math operators like root... which have unicode characters...
Just ideas... to help bloat the compiler.
Democracy Now! - uncensored, anti-establishment news
I've noticed that regardless of all claims about how Java can be faster than C++, I've never seen Java desktop applications beat C++ at the most important thing - startup time. I'll give you an example with JDownloader - that application takes 10-15 seconds to start.
Speed perception from the user's point of view is based on startup time and latency. I still haven't seen a Java desktop application that feels responsive.
its not the GC that allows you to develop faster, its the surrounding infrstructure that does that. Imagien writing your C# code in notepad - you just wouldn't do it, it'd be painfully slow. That's where the development productivity comes from.
GC can be a huge burden though, not only does it encourage sloppy 'the GC will take care of that' style attitude that hurts performance badly (as prime example consider why there is a StringBuilder class at all, if the GC is so fantastic and fast at memory management). If you need to manage something that is not memory, whatever that is, you start to have to worry quite alot about how to trap and free the resource correctly.
I recall an old WCF program I wrote, I implemented IDispose correctly in the handler object, yet if anything thew an exception (which I wanted, to pass to the client as a SOAPFault) it wouldn't clean up the server-side state correctly, and the next call would contain a little bit (of logging state in my case) from the previous call. Bummer. Worse bummer - figuring out how to force the GC to correctly finalise my object when I wanted it done. Ended up having to manage all that object lifecycle manually. Manually! It ended up like coding C again and remembering where to put the delete() call.
So no, GC in the real world is handy, but doesn't increase developer productivity, or code performance (except for benchmarks or simple stuff that don't use it like the real world). Fewer bugs - hardly, you just shift them elsewhere.
FYI, take a look at Microsoft's SafeHandle class. That shows exactly the problem with GC systems. If you have to create a low-level reference counting class to work around the GC, but the creators of the entire VM, then you know GC is not a silver bullet.
C++ is better off without it, stick to RAII and be happy.
I also never seen a Java application have a snappy user interface. Almost always you click and only after a second has passed a menu appears, or the button animation clicks.
Herb Sutter is a retard with no skills? Right...
StringBuilder exists because the string data type is immutable. It has nothing to do with GC. String concatenation without StringBuilder is a painter's algorithm as it has to keep re-copying the working version of the string for every piece added.
As for proper clean up with exceptions -- that's what using() and finally{} are for. If you're using an object that implements IDisposable and not properly disposing of it when it goes out of scope (for any reason) then you're doing it wrong.
Finalizers are also usually the wrong thing to do in C#. The very definition of the language states that they will be called whenever the hell the GC feels like and you definitely should never rely on them being called in a timely fashion. Generally speaking, you can leave managed objects to take care of themselves and unmanaged objects taken care of in a Dispose() method. 99% of the time, the only thing you should use the finalizer for is forcing a call to Dispose() in case whoever is using your class doesn't bother properly disposing of it.
Yes, Dispose() smells a lot like C++'s delete. That's the way of life -- if you want a guaranteed cleanup then you're going to have do it yourself. There's only so much guessing the GC is capable of. But most of the time you're dealing with regular managed objects and the GC does its job just fine, leaving you to worry about the logic of your program rather than whether or not its leaking memory.
And yes, there are of course situations where the GC outright doesn't suffice. And the language designers gave us utilities for dealing with those situations when they occur. But I have yet to run into one that didn't turn out to be me just doing something dumb (I came from a C/C++ background myself.)
You're right -- GC isn't a silver bullet. But its still a hell of a lot easier to write safe code when you only have to worry about object destruction 10-20% of the time. And if you're really stuck, you can force the GC to collect whenever you feel like (of course you take a performance hit for doing that so its generally not recommended.)
(I suppose the C# team could implement a class attribute to force finalization when an object goes out of scope but I have no idea if that would be a huge performance hit or they just never thought of it or they thought of it and decided they didn't like it or what. Still only solves one small part of the problem in any case though.)
What's the point of this? cairo is a C library. I guess you could standardize it as part of C2014 or something but just converting its interface to C++ as they say is just pointless. It would result in as much work as would be to make a proper C++ api from scratch and wouldn't necessarily result in as good C++ api as cairo is for C.
Please remember C was designed as a system language (on PDPs as well so not exactly lightning fast or with large memory space). I certainly wouldn't want the overhead of limit checking in my OS, not to mention what it should then do if there is an error in the kernel. Incidently if you are that worried you could parse the file and insert assert statements but this would unsurprisingly slow the code.
My problem with this is how do you build a compiler from sources for a faceless embedded platform. I'm currently seeing this play out in the Qt environment. There are a lot of nice non-GUI features to it but I have yet to be able to cross-compile v5.x of the thing for an embedded ARM platform that has no display, keyboard, or mouse. 4.8.5 works fine but Digia changed a bunch of stuff in 5.x and now I'm SOL.
IMHO, something like drawing should be compartmentalized into a library.
.Net doesn't really have this issue. I was a fan of Java when it came out, but it turned out to be a huge bloated security hole. At least it really is "compile" once, run almost anywhere compared to .Net.
competent c++ programmers are quite capable of selecting and/or building the graphics APIs we wish to use.
higher level languages/environments provide built in graphics support where deemed appropriate.
c++ is metal. we're not pop. please don't bloat.
- steve.
When I start a Java application it usually runs for weeks if not months (until a system update requires a reboot).
I don't really care if it takes 5, 10 or 120 seconds to start up.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The resulting incomprehensible, overengineered library ought to be worth a laugh, if it ever gets standardized. Will they use their own bloated language to draw graphics at compile time using template metaprogramming? Will they use their own bloated I/O framework to create I/O streams for 2D matrices? Ought to be good!
The code will probably look something like:
#include"std2d" // can't use angle brackets as input
#include"std2dio"
#include"std2dxfrm"
2dout matrix2 != std2dxfrm::brgtn(20) = std2d::clrblack + display3;
I kinda' missed these flame wars..
That's a strawman.
If self-documenting code is so important, then why do people not use Ada instead of C++?
Undefined behavior doesn't mean implementation-defined behavior!! Don't use them interchangeably!
A successful API design takes a mixture of software design and pedagogy.
Most mm is just plain invisible in C++, since stuff is deallocated on scope exit. For everything else (nearly) there's reference counting. Reference counting doesn't work if you have general (i.e. cyclic) mutable graphs. I'm not sure I've ever had one of those.
Many people say GCs free you from thinking about memory management, but it doesn't. It just makes it slightly simpler to handle your common case, but it also gives you a great tool to blow your foot off with when you're trying to figure out how your GC language is "leaking" memory. Another great example besides your circular references is referencing an object in the body of an anonymous method that is assigned to an event handler. += event handlers and adding more anonymous methods is a great way to keep objects referenced.
Speaking about mm, I semi-recently got to work on a program that was allocating and deallocating about 3GB/s. They were doing a lot of string concatenation and not using string.builder or their own buffer. uhggg.
I recall an old WCF program I wrote, I implemented IDispose correctly in the handler object, yet if anything thew an exception (which I wanted, to pass to the client as a SOAPFault) it wouldn't clean up the server-side state correctly, and the next call would contain a little bit (of logging state in my case) from the previous call. Bummer. Worse bummer - figuring out how to force the GC to correctly finalise my object when I wanted it done. Ended up having to manage all that object lifecycle manually. Manually! It ended up like coding C again and remembering where to put the delete() call.
Sounds like you were not follow best practices. IDispose should never do anything that can cause exceptions and is meant to be used to allow managed code to interface with unmanaged, so it makes sense that it's a lot like C. While you can call IDispose directly, you can't always guarantee that IDispose will be called, if ever. The primary use case for IDispose is to let the GC decide when to call it, but you can call it directly if you want to speed up some of the process. The finaliser is not guarenteed to ever be called during the life time of the program, except during shutdown.
No. Good library design means that you do not have to think about dtor, operator=, std::move etc. for 99.9% of your classes, because the compiler generated ones do the right thing. If they don't, unless it's a class specifically written for resource management, it just is a sign that there's something wrong with your class design.
And any halfway competent C++ programmer doesn't generally need to think about const; it's almost always obvious where to put it. There are some very rare corner cases, and there's the problem of interfacing with libraries which are not const-correct (but the latter is just a matter of putting const_cast on the right places).
Reference counting has a performance penalty over tracing GC. Modern GC implementations like C4, Collie and Immix are really, really fast although they still need up to twice the memory of the theoretical perfect allocation strategy. You can code around it by, e.g. using stack allocation but typical C++ does a lot of copies that would be unnecessary in a GC language. The biggest issues with GC are the reduction in locality of access (the GC threads need to walk the heap to find garbage) and the less predictable pause times. Overall it's program dependent and if you put enough time into it you can always do better than the machine.
There's reference-counting garbage collection in the standard now. You're just not allowed to call it "garbage collection" around C++ weenies, because it offends their unearned sense of superiority. This leads to them making hilarious statements like "we don't need garbage collection because we have shared_ptr".
Well, that's not what I do. I never keep an application open after I'm done with it - mostly because it clutters my taskbar. Btw, are you talking about desktop applications, or server applications?
Desktop in this case ...
I have only a Jenkins as "server" on my laptop.
I keep most apps pinned to the taskbar anyway, so it looks very similar regardless if the applications are running or not.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
This is the link that inspired my comment btw - http://programmers.stackexchange.com/a/409/31462
Yes, Java programs often have a slow start up.
But often there is a reason, which is not Javas fault but the programmers.
E.g. Eclipse, a wildly used Java IDE.
The first thing eclipse does when started is opening a workspace, a directory holding lots of projects, opening those projects and figuring if "they are up to date".
Other IDEs simply show the GUI and then use a background thread to "investigate" the projects.
It is not Javas fault that reading gazilion of megabytes of source code slows down the start up of Eclipse.
It is the braindead philosophy how Eclipse works. It would be similar slow in any other language.
Imagine Microsoft Developer Studio would not start showing its GUI until it has compiled/built all projects. That would be nonsense, too.
Hence, I rarely close my Eclipse. I just keep it running, after it started it is a well behaving citizen eating zero CPU.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
No searching for free space involved. It can also do background compaction while your program is running, and on different threads.
For this to be possible, in any language, The language has to insert some kind of barrier before every dereference to block the thread if a reference is currently being compacted. This sort of thing is possible in C (if it's possible in Von Neumann, it's possible in C, if it's not, it's not possible in any language), but you need to have a very efficient way for eliding dereference barriers when a memory compaction is not in progress. I haven't seen such an efficient eliding barrier in any language or GC implementation, they usually just impose a penalty on EVERY access to a dynamic storage object, or, and this is far more common, they "stop the clock" and pause every other thread while the compaction is running.
Yes, I've wondered if part of the problem is that the Java community is taught that productivity trumps performance. I mean the language advertises that its goal is to make it easier to write code by not thinking about speed.
... will appreciate readable programming languages. Only pseudo competent programmes too full of them self to see there own weaknesses want to use unreadable languages. And those pseudo competent programmes are an even bigger disaster then then JAVA/.NET generation because they brought us all the buffer overruns malware uses to attack our computers.
BTW: Java is not all that readable either.
Has there even been a full featured PL/1 with all optional features in place? I don't think so. And most C / C++ are not full featured either.
This is not something that is taught to "the Java community", it is in general taught to every CS student.
The reason is simple:
a) you can always optimize a finished solution, but if there is nothing finished you have nothing to work with
b) development time is expensive
c) hardware is cheap
All this are no reasons to actively build inferior solutions.
However: :D
in the time a Java programmer has done his first window and its first menu a SmallTalk programmer already has a visual prototype and the C programmer is still fixing typos after his second "make run", Yeah, I'm exaggerating, but you get the idea
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.