Who's responsible in case of accident? The car owner or the software developer?
Am I the only one to think that it looks mediocre?
It's clearly not nearly as good as The Lord of the Rings was.
The story isn't the problem, it's the direction.
Decompression time is always real time. That's obvious.
Compression is a whole different beast. Some applications need real-time encoding (such as video-conferencing), but most do not.
Have you even ever written an encoder?
Compression and decompression are different things.
very high compression has limited utility if it takes an extremely long time
I don't see how the utility is limited.
Most content is mastered once and viewed millions of time.
How much time it takes to compress is irrelevant, even if you get diminishing returns the longer you take. What's important is to save space when broadcasting the content.
The front end and the back end are separate.
This one had pretty serious performance problems. 4.7 is one of the best.
The word you're looking for is 'propaganda'.
4.8 was even worse.
That's hardly news.
This is what Nao from Aldebaran is.
Good domain-specific tools are written as command-line utilities, and are even better if you wrote them yourself for your project.
Text editing (which includes syntax highlighting etc.) is also much better with a text editor.
Editors are also more flexible, scale better for large projects, and can do anything you need them to do.
An IDE is extremely constrained and won't work properly whenever you need to do something that wasn't planned by the developer who coded it.
I guess that depends on the market, and possibly on your price.
And finding new clients and negotiating contracts doesn't take time?
Why are you even using an IDE? If you want to be the most productive, use a multi-purpose text editor.
Garbage collection necessarily wastes memory by factor of 1.5 to 2.
The collection itself also slows down the program, and in some languages cannot even happen asynchronously.
Finally, the most important aspect for program performance is locality and memory layout, something you cannot even optimize for in a language where every object is a pointer to some memory on a garbage-collected heap.