Концепты: 3. Плавный переход от динамической к статической типизации
Попробовать сделать гибридный язык программирования, который поддерживает одновременно как динамическую типизацию, так и статическую.
Use-case такой: начинаем писать маленькую незатейливую программку типа на JavaScript’е, разработка «на коленке», пишем быстро и легко. Предполжим, программа всем нравится, и дела у нас идут хорошо. Размер исходников растет, разбираться в них уже не просто. Тогда несколько основных классов наконец объявляются явно, как в Java'е. Их методы все еще можно вызывать динамически, но уже больше не хочется. Программу приходится начать компилировать (исходники начинают зависить друг от друга), но это не страшно, все равно какой-то release-процесс к этому времени уже налажен (тесты там какие-никакие). Дальше рост числа программистов и стихийный процесс перевода сложных мест на статическую типизацию. Один из разработчиков ядра просит больше не использовать его классы динамически, потому что он будет их рефакторить скоро, а вручную искать и исправлять всех клиентов он не собирается. Возникающее публичное API уже полностью пишется только статически. К третьему релизу в главных модулях динамическая типизация запрещена, код компилируются с ключом --static-only как обычный код на Java’е. ...
А если в самом начале программа не пошла в рост, она так и остается написанной типа на JavaScript’е.
Интересно в этом отношении в самом деле взглянуть на Java’у.
Во-первых, когда они добавляли в язык generic’и, они сделали в точности так: сначала все коллекции были без указания типов; потом стало можно типы указывать, но осталась свобода этого не делать; наконец, у компилятора есть ключ, который требует, чтобы типы были указаны везде, гарантируя при этом, что все коллекции станут строго типизированны.
Во-вторых, любопытно, сложно ли сделать такой язык из Java'ы? Мне кажется, что не очень. Уже сейчас можно работать без типов переменных и натурально вызывать каждый метод через reflection:
Object message = "Hello, world!";
Object systemOut = System.out; // нет зависимости от java.io.PrintStream
// Подразумевается короткий синтаксис: systemOut->println(message);
systemOut.getClass().getMethod("println", String.class).invoke(systemOut, message);
Был бы интересный эксперимент. Конечно, тут есть много технических проблем, но все они должны легко обходиться.
Use-case такой: начинаем писать маленькую незатейливую программку типа на JavaScript’е, разработка «на коленке», пишем быстро и легко. Предполжим, программа всем нравится, и дела у нас идут хорошо. Размер исходников растет, разбираться в них уже не просто. Тогда несколько основных классов наконец объявляются явно, как в Java'е. Их методы все еще можно вызывать динамически, но уже больше не хочется. Программу приходится начать компилировать (исходники начинают зависить друг от друга), но это не страшно, все равно какой-то release-процесс к этому времени уже налажен (тесты там какие-никакие). Дальше рост числа программистов и стихийный процесс перевода сложных мест на статическую типизацию. Один из разработчиков ядра просит больше не использовать его классы динамически, потому что он будет их рефакторить скоро, а вручную искать и исправлять всех клиентов он не собирается. Возникающее публичное API уже полностью пишется только статически. К третьему релизу в главных модулях динамическая типизация запрещена, код компилируются с ключом --static-only как обычный код на Java’е. ...
А если в самом начале программа не пошла в рост, она так и остается написанной типа на JavaScript’е.
Интересно в этом отношении в самом деле взглянуть на Java’у.
Во-первых, когда они добавляли в язык generic’и, они сделали в точности так: сначала все коллекции были без указания типов; потом стало можно типы указывать, но осталась свобода этого не делать; наконец, у компилятора есть ключ, который требует, чтобы типы были указаны везде, гарантируя при этом, что все коллекции станут строго типизированны.
Во-вторых, любопытно, сложно ли сделать такой язык из Java'ы? Мне кажется, что не очень. Уже сейчас можно работать без типов переменных и натурально вызывать каждый метод через reflection:
Object message = "Hello, world!";
Object systemOut = System.out; // нет зависимости от java.io.PrintStream
// Подразумевается короткий синтаксис: systemOut->println(message);
systemOut.getClass().getMethod("println", String.class).invoke(systemOut, message);
Был бы интересный эксперимент. Конечно, тут есть много технических проблем, но все они должны легко обходиться.