То, что делает Вы желаете, было автоматически на Вашем любимом языке программирования? [закрытый]

Whatever the language can do for me automatically, I will want a way of doing for myself.

.Net:

A warning when manipulating strings with methods such as Replace and not returning the value (new string) to a variable, because if you don't know that a string is immutable this issue will frustrate you.

In Java I would like a keyword that would make the entire class immutable.

E.g.

public immutable class Xyz {
}

And the compiler would warn me if any conditions of immutability were broken.

В Java создайте bean-компоненты менее многословно.

Например:

bean Student
{
    String name;
    int id;
    type1 property1;
    type2 property2;
}

, и это создаст частные поля bean-компонента, методы доступа по умолчанию, toString, hashCode, equals и т. Д.

Параллелизм. Это была моя главная идея, когда я задавал этот вопрос. Со временем это будет становиться все более и более важным, поскольку современные процессоры уже имеют до 8 логических ядер (4 ядра + гиперпоточность), и через несколько месяцев появятся 12 логических ядер. В будущем у нас будет чертовски много ядер в нашем распоряжении, но большинство языков программирования позволяют нам использовать по одному только по одному.

Модель Threads + Synchronization, представленная большинством Языки программирования чрезвычайно низкого уровня, и очень близко к тому, что делает процессор. Для меня текущий уровень поддержки языка параллелизма примерно эквивалентен поддержке управления памятью в C: не интегрирован, но некоторые вещи могут быть делегированы в ОС (malloc, free).

exec("Build a system to keep the customer happy, based on requirements.txt");

Concurrent programming/parallelism that is (semi-)automated, opposed to having to mess around with threads, callbacks, and synchronisation. Being able to parallelise for loops, such as:

Parallel.ForEach(fooList, item =>
{
    item.PerformLongTask();
}

is just made of win.

Certain languages already support such functionality to a degree, however. Notably, F# has asynchronous workflows. Coming with the release of .NET 4.0, the Parallel Extensions library will make concurrency much easier in C# and VB.NET. I believe Python also has some sort of concurrency library, though I personally haven't used it.

What would also be cool is fully automated parallelism in purely functional languages, i.e. not having to change your code even slightly and automatically have it run near optimally across multiple cores. Note that this can only be done with purely functional languages (such as Haskell, but not CAML/F#). Still, constructs such as example given above would be very handy for automating parallelism in object-oriented and other languages.

I would imagine that libraries, design patterns, and even entire programming languages oriented towards simple and high-level support for parallelism will become increasingly widespread in the near future, as desktop computers start to move from 2 cores to 4 and then 8 cores and the advantage of automated concurrency becomes much more evident.

In C++, type inference for variable declarations, so that I don't need to write

for (vector<some_longwinded_type>::const_iterator i = v.begin(); i != v.end(); ++i) {
    ...
}

Luckily this is coming in C++1x in the form of auto:

for (auto i = v.begin(); i != v.end(); ++i) {
    ...
}

Легко: инициализировать переменные в C / C ++, как это делает C #. Это спасло бы меня от нескольких сеансов отладки в чужом коде.

Конечно, было бы ключевое слово, когда вы специально не хотите инициировать переменную.

noinit float myVal; // undefined
float my2ndVal;     // 0.0f

С точки зрения динамических языков, я хотел бы видеть лучшую поддержку инструментов. Стив Йегге имеет отличный пост по этому вопросу. Например, во многих случаях инструмент может заглянуть в различные пути кода и определить, существуют ли методы или функции, и предоставить эквивалент теста дыма компилятора. Очевидно, что если вы используете множество динамического кода, это не сработает, но на самом деле это не так, поэтому было бы неплохо, если бы, например, Python сообщал вам, что .ToLowerCase () не был допустимой функцией во время компиляции, а не ожидал, пока вы не нажмете предложение else .

s = "a Mixed Case String"
if True:
   s = s.lower()
else:
   s = s.ToLowerCase()

For languages that provide operator overloading, provide automatically generated overloads for symmetric operations when only one operation is defined. For example, if the programmer provides an equality operator but not an inequality operator, the language could easily generate one. In C++, the same could be done for copy constructors and assignment operators.

I think that automatically generating one-side of a symmetric operation would be nice. Of course, I would definitely want to be able to explicitly say don't do that when needed. I guess providing the implementation of both sides with one of them being private and empty could do the job.

В среде Visual Studio я хочу, чтобы «Удалить неиспользованные использования» выполнялось для всех файлов в проекте. Я считаю значительной потерей времени необходимость вручную открывать каждый отдельный файл и называть эту операцию файловой базой.

В C ++, enum-to-string.

В Ada язык определяет атрибут image перечисляемого типа как функцию, которая возвращает строка, соответствующая текстовому представлению значения перечисления.

C ++ не предоставляет такой чистой возможности. Чтобы получить грубый эквивалент, требуется несколько строк очень непростой макро-черной магии препроцессора.

Все, что делает LINQ. C # избаловал меня, и теперь мне трудно что-либо делать с коллекциями на любом другом языке. В Python я часто использую списочные выражения, но они не так мощны, как LINQ. Я не нашел ни одного другого языка, который бы облегчал работу с коллекциями, как в C #.

Coffee. Я имею в виду, что язык называется Java - так что он должен уметь делать мой кофе! Ненавижу вставать после программирования, ходить к кофейнику и узнавать, что кто-то из отдела маркетинга взял последнюю чашку и не приготовил еще одну чашку.

Настойчивость, мне кажется, мы пишем слишком много кода, чтобы иметь дело с постоянством, когда это действительно должно быть проблемой конфигурации.