Watched java. In the x64 system, the Hellowhold window eats up about 20 MB of memory, and this number is growing rapidly when creating new objects. Mono - just look at the Banshee player to understand that the situation there is no better (The music player eats away ~ 100 MB of memory, despite the fact that I always keep the loaded player, I don’t like it).

C ++ / Qt seems to be good, but a lot of effort will have to be spent on studying, though it’s not known whether it will be justified (Generally, as I see now, I don’t see the most stable situation, and people have become more careful with the advantages in new projects)

Python / PyGTK turned out to be surprisingly more modest to memory than java, but the language itself seems to me somehow insane, maybe I just don’t understand dynamic typing. The lack of encapsulation and overloading functions is surprising. Not clearly what value any function returns. The code seemed unreadable just because of the lack of parentheses. Somewhere I stumbled upon a council to use function calls less frequently, especially in cycles, since This is an expensive python operation. Immediately before my eyes, huge methods appeared in 200+ lines.

PS Maybe I'm in something wrong because looked at these languages ​​very superficially. Cross-platform-level compilation would be fine with (with the same code).

Closed due to the fact that it is necessary to reformulate the question so that it was possible to give an objectively correct answer by the participants of Grundy , D-side , aleksandr barakin , fori1ton , Kromster 20 Oct '16 at 4:20 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • one
    "In the x64 system, the HellowWorld eats up about 20 MB of memory, and this number is growing rapidly when creating new objects. Mono - just look at the Banshee player to understand that the situation is no better there" - it's all because of the misuse and configuration of virtual machines . - cy6erGn0m
  • 2
    By the way, how did you determine 20M or more? Where does the number 20 come from? If we are talking about virtual memory, then the virtual machine at 20 meters will not start at all. Because it takes a lot of memory to display dynamic native libraries: in this case, real physical memory is not consumed. PS: I can't even start vim at 20 meters. - cy6erGn0m
  • free - we look at free memory without buffers and caches, then we run free again. Why python eats less is a mystery to me. - orlan
  • And what do you think, why do not they write large applications on python that work longer than the CGI script? Imagine that you would have to write an Eclipse class application or IDEA application on it .. I have no doubt that there will be epic fail. - cy6erGn0m
  • Why will be fail? - Vladimir Gordeev

4 answers 4

What better depends on the selection criteria. In this case, they are: Design time and time for making changes ( the latter may be more important than the first for custom applications ).
The complexity of the application.
Type of application ( "photoshop", "WoW" or "client to twitter" ), drawing or custom.

  1. C ++
    development speed is the lowest

    for complex applications

    for lottery solutions requiring high performance optimization. For weak iron - GPS navigators, ATMs, CNC machines, ...

  2. Java
    development time is less than C ++. Especially while making changes, improvements

    for complex applications

    when program efficiency is required ( memory overruns only worries young programmers. Neither smartphone manufacturers on Android nor business software customers care about this JVM feature. And my wife also doesn’t care how much the music player eats away ) low-level tricks or OS specifics.

  3. Python
    development time is the lowest

    for simple and medium complexity of applications ( for complex ones - only with highly qualified programmers or a formalized development process )

    for non-critical runtime ( examples - Dropbox client, wikidpad ). For customized, short-run applications. ( programs on Google and Yandex servers are "customized" because they are unique )

Young programmers usually do not think about the development time. And often in life - not the best wins, but the first. Especially when working on order.

On dynamic typing.
It requires the development of self-discipline, which is usually not the case for young programmers, and they themselves are “evil Buratinas” who quickly turn the code into complete chaos.
It requires mandatory and rigorous application of TDD or similar techniques.

Interpreter / compiler PL with dynamic typing can never execute / generate code of the same execution efficiency as with static typing.

To the question - like / dislike some programming language.

First, often "not like" this - "did not know, do not know, and do not want to know"

Secondly, when, after several completed and working programs, it remains “not to like”, then it is really worth thinking about changing the programming language. Development in your favorite programming language is a very important motivator for reducing development time and improving its quality.

(About myself - professionally (that is, for money) wrote in plain C, Java, Python)

  • 2
    The only noteworthy answer in the midst of a plethora of topics for holivars - jmu

I will answer about Python.

The lack of encapsulation and overloading functions is surprising.

Encapsulation in python, although very conditional, but there is. If the method starts with __, the interpreter automatically adds the prefix _% current_class% to the name and, accordingly, this method will not be visible in another class. Private Methods :

""" >>> obj = bar() >>> obj.__test() Traceback (most recent call last): ... AttributeError: 'bar' object has no attribute '__test' >>> obj.test2() Traceback (most recent call last): ... AttributeError: 'super' object has no attribute '_bar__test' >>> obj._foo__test() Hello >>> obj._foo__test <bound method bar.__test of < object at 0x...>> """ import doctest class foo(): def __test(self): print('Hello') class bar(foo): def test2(self): super().__test() doctest.testmod(optionflags=doctest.ELLIPSIS) 

Thus, the encapsulation of class attributes is achieved. Of course, you can still refer to this method with the full name. However, for example, in C # you can access private methods through reflection, but this does not mean that these methods are public.

To create abstract classes, a special metaclass with decorators is used .

 """ >>> obj = bar() >>> obj.test() Hello >>> obj = baz() Traceback (most recent call last): ... TypeError: Can't instantiate abstract class baz with abstract methods test """ import abc import doctest class foo(metaclass=abc.ABCMeta): @abc.abstractmethod def test(self): print('Hello') class bar(foo): def test(self): super().test() class baz(foo): pass doctest.testmod() 

Interfaces are implemented in the same way.

As for function overloads, in a dynamic language, where methods can take a variable number of parameters and default values, this is not possible, and it is absolutely not necessary. Example:

 """ >>> foo(1, 2, 3, 4, 5, arg1=1, arg2=2, bar=False) (1, 2, (3, 4, 5), False, {'arg1': 1, 'arg2': 2}) """ import doctest def foo(first, second, *args, bar=True, **kwargs): print( (first, second, args, bar, kwargs) ) doctest.testmod() 

It is not clear what value any function returns.

Yes, this drawback is inherent, probably, in all dynamic languages. However, to justify the python, I can say that this problem is partially solved with the help of annotations , a full-fledged IDE, and good documentation of the functions.

Moreover, using annotations, metaclasses and decorators is not difficult to implement and static typing :) Ie about the following:

 """ >>> foo().bar([1, 2, 3]) Traceback (most recent call last): ... TypeError: 'param' is 'list', but the expected type is 'int' >>> foo().bar(1) Traceback (most recent call last): ... TypeError: function return is 'str', but the expected type is 'bool' """ class foo(metaclass=StrongTyping): def bar(param: int) -> bool: return 'some text' 

Of course, in order for the example to work, you also need to implement the metaclass StrongTyping.

The code seemed unreadable just because of the lack of parentheses.

This is probably a matter of habit. The absence of parentheses obliges the programmer to follow the indents and use a single tab character, which, in my opinion, is not enough. As for the visual separation of methods, then I am helping the IDE, which separates them with horizontal lines.

Somewhere I stumbled upon a council to use function calls less frequently, especially in cycles, since This is an expensive python operation. Immediately before my eyes, huge methods appeared in 200+ lines.

In my opinion, the flexibility of python and such features as expression generators, on the contrary, allow writing very compact and concise constructions. Where a lot of cycles and conditional constructions are required for strongly-typed languages, in python it is solved by a single line.

UPD. What are the advantages of dynamic typing? IMHO, it is in the dynamics. Where else can you write something like this:

 """ >>> op = ImportantClass() >>> >>> ImportantClass.debug(True) >>> Called <function foo at 0x...> (<__main__.ImportantClass object at 0x...>, 2) {} None """ import doctest import functools def logging(func): """ Декоратор функции, который логирует все вызовы """ @functools.wraps(func) def wrapper(*args, **kwargs): ret = func(*args, **kwargs) print('Called ', func, args, kwargs, ret) return ret # одна из особенностей питона - это то, что все является объектами # добавляем атрибут к функции wrapper.original = func return wrapper def debugging(cls): """ Декоратор класса, добавляет метод debug(enable) """ @classmethod def debug(cls, enable=True): attr = '__call__' if enable else 'original' call = lambda f: logging(f) if enable else f.original # в цикле подменяются все функции на logging(f), либо на оригинальные, # которые хранятся в декораторе for func in [call(f) for f in cls.__dict__.values() if hasattr(f, attr)]: setattr(cls, func.__name__, func) # добавляем новый метод для декорируемого класс # именно для класса, декоратор вызывается только один раз cls.debug = debug return cls @debugging class ImportantClass(): def foo(self, *args, **kwargs): pass # do something important def bar(self, *args, **kwargs): pass # also do something doctest.testmod(optionflags=doctest.ELLIPSIS) 

Decorators logging and debugging can be placed in a separate module and used for any classes. Moreover, with debugging turned off, there will be practically no overhead, since methods are replaced by other methods, and do not turn around.

On the other hand, it is this dynamism that can serve as a source of errors, so you have to use it carefully and do not forget about testing.

By the way, in fact, it is considered that the python has both strict and dynamic typing . T.N. code "1" + 1 throw a TypeError exception.

  • 2
    I will add that for python there is a library PyQt - Ilya Pirogov
  • Thank you for such a detailed answer. And which IDE do you use for python? And what are the nice sides of dynamic typing? (If we take into account that declaring variables, and if necessary, it is clear that the types are not a problem) - orlan
  • one
    I use [PyCharm] [1] from the JetBrains team. Very satisfied, this IDE also has auto completion rather well, and the debugger, and it is very active. About dynamic typing added to the answer, did not fit here =) [1]: - Ilya Pirogov
  • do you write on py3k in PyCharm? - rnd_d
  • Yes. But frankly, in combat projects, our python is only used as postgresql triggers. - Ilya Pirogov

Qt itself is not so complicated if you are familiar with C ++. But the possibilities are powerful. Cross-platform total! I also appreciate Qt for the fact that the layout of the appearance of objects is almost automatic - it does not work out curly window curves (as programmers like to do often). For any OS, the appearance of the application will be identical - without fear of writing under Windows, an application that will then be compiled under Linux, and it will look the same here and there. The most powerful set of classes for all occasions - multimedia, graphics, text editors, databases, etc. Stability and support by a very large company. Regular releases. Availability of a free version and a version for mobile devices.

The complexity of learning the language and the very set of libraries pays off many times.

    • Its own super-high-level DSL (Domain Specific Language, sharpened for your tasks) +
    • code autogeneration for (fifty) target platforms
      • x (PC * 2 / win, lin / * 2 (x32, x64), Mac, Android * 2 /4.x, backport-plugs 2.x /, iPhone, smart watches, clouds
      • x number of DBMS / data warehouses each with their own problems
      • x Java, C #, JavaScript and a dozen other trailing PLs because you needed some kind of unique library or application to work in a specific environment, or the customer limited it. He has specialists to support knowing one thing.

    By versatility / efficiency and accessibility are straightforward: a bunch of Python and C ++, and native GUI libraries, an interface to a database, etc., wrapped in classes with one interface (for each type - GUI, database, ..).