Идея #1

Порой я спрашиваю себя - какого черта из всех проектов я выбрал тот, который выбрал.
В мире есть масса актуальных идей для приложений. В этой заметочке, я бы хотел начать эту тему, какие на мой взгляд идеи были бы просто "ах какие замечательные". Если вам понравится - могу продолжить.
Самому мне видимо никогда не придется уделить подобному достаточное время, а на что-то - порой и просто не хватит знаний.
Все эти идеи просты и сложны одновременно. Они не дарят нам счастливое будущее, но упрощают наше сегодня.
Итак, поехали, сегодня я хочу рассказать про идею программной среды.

Вот как бы не была замечательна студия и существующие ООП языки - им жутко не хватает возможности скомпоновать участок кода во что-то более емкое.
И не важно, какого языка тут коснуться - всегда есть часто повторяемые операции.
Вот, например, частая операция кеширования:

private MyClass _field;
public MyClass field 
{
	get 
	{ 
		if (_field == null)
			_field = new MyClass();
		return _field
	}
}

А согласитесь, было бы существенно удобней писать что-то покороче. Например:

public cash MyClass field { return new MyClass(); }

С такой программной средой мы бы могли создать шаблон, описанный в отдельном файле. Например вот такой:

//Write:
$INCAPSULATE$ ?KEYWORDS? cash $TYPE$ $FIELDNAME$ { $CONTEXT$ }
//Read:
private ?KEYWORDS? $TYPE$ _$FIELDNAME$;
$TYPE_PROPS$ ?KEYWORDS? $TYPE$ $FIELDNAME$
{
	get 
	{
		return _Hide$FIELDNAME$Get();
	}
}
private ?KEYWORDS? _Hide$FIELDNAME$Get()
{
	$CONTEXT$
}

Такой бы шаблонизатор в достаточной мере позволял реализовывать самые разные операции. Самая суть была бы в том, что код который мы видим это не тот же самый код, который есть на самом деле - на этапе проверки синтаксиса и компиляции существовал бы обычный код, полученный вот такими как тут правилами.

Я даже знаю проекты, которые пытаются сделать такой функционал. Один из них - проект Roslyn, но у проекта на самом деле целый ряд минусов:

• это ТОЛЬКО для .NET - а не для всех языков в целом
• надо хорошо знать IL - вроде пытаешься всё упростить, а зачем то лезешь в тяжелый хардкод
• это обработка на стадии компиляции - не все используют именно этот компилятор, скажем билд под IOS имеет свою реализацию.

Да и в целом, среда способная адаптировать языки под свои собственные нужды - это один огромный плюс.
Минус такой разработки только 1 - отсутствие хорошего плагина проверки ошибок, аналогичного всяким решарперам. А писать его долго, нудно, и не каждый еще и знает язык в достаточной для этого мере. Я например - не знаю. А без этих удобств вряд ли кто-то будет отказываться от гиганта-студии.
Хотя может есть и способ сделать такой плагин под саму студию - ей богу не секу, что там за геморрой.

Да и не только в подмене слов дело.
На самом деле можно в целом реализовать среду, которая будет прогибаться под вас. Скажем кажется вам создание нового контекста "отступом" выразительней чем фигурные скобки - пожалуйста, получите. Среда сама сделает потом как надо на ваш язык N.
Хотите сделать статические классы наследуемыми? Удобно опишите этот функционал и пользуйтесь.
Надоели вечные GetInstance() в синглтонах - пожалуйста.
Хотите инкапсуляцию с областью видимости в конкретный класс - в рамках этой среды можно, почему бы и нет.
Да хоть иерархически зависимые друг от друга алгоритмы - вот скажем используете для функции M рекурсивную функцию N - не беда.
Или картиночкой код сопроводить, на - рисуй.
Новый оператор добавить? Да на что только хватит вашей фантазии - как бы кто не противился такому "сахару", "моднявостям", в конце концов удобство побеждает, если оно реализовано грамотно.

Бывают тонкие места, аля протоколов, описывая которые мы вынуждены повторять одинакового типажа классы - вот есть десять полей, вот операция сериализации, вот десериализации, вот конструктор и все эти методы тривиальны, но на вашем языке их приходится заполнять вручную или "писать код который скомпилирует файлы в папке в еще один код"

Бывает, что нам нужно рассмотреть какие то классы глядя на схемку из наследования
На схемку по пространствам имен

Между теми же векторами есть куча операций, которые можно было бы реализовать не как функции, а как придуманные нами знаки. "Приблизительно равно" для таких типов как float, Vector(2/3/4/10..и т.д.) очень бы пригодилось, просто визуально красиво.
Или скажем выражения в духе a < x < b, которые на вашем языке описываются как (a < x И x < b)

А кому не хочется быстро уметь чекать переменные на null как в монаде maybe?

Опять же - тут можно рассуждать о том, в какую сторону расширяться вечно. Но все это на самом деле усугубит ситуацию если не возможность и код написать "обычным стилем" и посмотреть этот код "как есть", без наших придуманных фиговин. И самое главное - чтобы код сохранялся "как надо", чтобы наши выкрутасы не влияли на остальных программистов, существовали чисто для нас самих.
Как и любой сахар в определенной степени это может стать вредным, можно бесконечно спорить о том что это может порождать многозначные ситуации, но если знать меру - будет вполне себе ок.

Возможно с чем-то из сказанного переборщил - не ругайтесь, я на самом деле за эстетичность. Просто хочу показать, сколько всего на самом деле можно было бы сделать.