SKY / ROOTS / LANG /
FOR1

Следуя принципу простоты и наименьшего числа стереотипов, думаю, разнообразие операторов цикла не есть хорошая идея. Если быть точным, требуется тщательное исследование, насколько сильно разнообразие операторов цикла, помогает избегать ошибки. Или их обилие аргументируется еще другими причинами? В SKYLANG, вероятно достаточно обойтись только оператором @ ?

001
002
003
004
005
006
007
008
009
010
011
012
# булевые версии
@($i = 0; $i < $cnt; $i++) { ... } # for он и в африке for, и в C и в PHP, и в SKYLANG
@($i < $cnt) { ... } # в такой форме for это традиционный "while"
@{ ... } # бесконечный цикл с выходом по break или другим
{ ... } @($i < $cnt); # традиционный do-while
label: { ... } # просто блок с меткой
 
# итерационные
@($ary as $val) { ... } # в такой форме for это foreach (php syntax)
@($ary as $key, $val) { ... } # то-же
@($key in $ary) { ... } # перебор только ключей, как в javascript
@($ary as $key,) { ... } # или лучше так, а "in" исключить

Любому блоку кода { ... } и одному выражению, может предшествовать метка, а break, continue, return и yield заменить на унифицированное go.
001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
  # пример 1
@($i < $cnt) {
    # код
    go; # эквивалентно break;
    # код
}
  # пример 2
@($i < $cnt) {
    # код
    go @; # эквивалентно continue;
    # код
}
  # пример 3
label: # код
# код
@($i < $cnt) {
    # код
    go label; # эквивалентно оператору goto;
    # код
}
 

Ключевые слова function class extended interface можно также упразднить, например:
001
002
003
004
005
006
007
myclass myparent { # аналог class myclass extended myparent
    privat $var;
    mymethod() { #аналог public function mymethod ()
      # код
    }
}
 

Следует иметь ввиду, что нет объективных логичных причин разрабатывать ситаксис языка SKYLANG без привязки к текстовому редактору, который будет иметь традиционную подсветку синтаксиса и on_the_fly автоисправления кода, в соответствии со стандартом кодирования. При этом, упразднение фундаментальных ключевых слов языка C и его наследников, не уменьшит способность кода быть легко читаемым (действительно ли это так?). Но в сравнении с PHP код будет быстрее набираться программистами, занимать меньше места в памяти.

Если это не вредит "читаемости" языка, нет смысла жать на клавиатуре 8 кнопок, чтобы набрать слово "function" (тем более, в то время, когда оно означает метод класса), тогда когда это слово можно вообще не писать. Нет смысла писать myclass extended myparent, тогда, когда на месте "extended" ничего не может быть другого кроме "extended".

Вышеуказанный пример синтаксиса языка SKYLANG "вытекает" из фундаментальных принципов проекта SKY: ультимативный анализ всех факторов и следование стереотипу тривиальной простоты. Наиболее частое должно быть наиболее коротким.

Для идеального, единого языка программирования, подразумевающего гармоничную связь с специальным редактором текста, когда программист набирает в редакторе, к примеру такой текст:
001
002
003
004
005
006
007
008
myclass myparent {
    privat $var;
    mymethod(&$x) {
      $x = 1;
      go $x;
    }
    mymethod2();
 
... нет причин, сразу же после набора символа "точка с запятой", не выдать сообщение, к примеру:

`myclass` cannot be CLASS and INTERFACE at the same time

Несмотря на то что ключевые слова "class" и "interface" отсутствуют в SKYLANG, это не означает что отсутствуют такие понятия языка. Гармоничный (с самим языком) редактор текста, может "на лету", после набора каждого символа, осуществлять определенную подсветку синтаксиса, а также делать многие другие вещи, которые для человека будут восполнять ясность кода, потерянную в сравнении с C++ или PHP, из-за упразднения фундаментальных ключевых слов. Например, кроме подсветки синтаксиса, справа от текста, указывать что идет определение класса, пассивный код, предоставлять контекстный выбор кода, как часто делается в редакторах HTML. В случае создания экземпляра класса:

$x = new myclass;

указывать этот факт словами для человека. Думаю несложно, разработать компромиссный вариант действий и свойств активного редактора, когда программистам будет намного меньше необходимо нажимать клавиши клавиатуры, по сравнению, например, с написанием эквивалентного кода на C++ или PHP. И при этом, код будет даже лучше восприниматься людьми, чем код, содержащий фундаментальные ключевые слова "class" и "interface" и другие, когда редактор не активный.

По факту, практически все профессиональные программисты, используют сейчас активные редакторы (как минимум с подсветкой синтаксиса), в этом нет ничего плохого и однозначно приветствуется всеми (и менеджерами компаний и топ программистами), как положительный навык и даже всегда рекомендуется. Думаю нет ничего плохого и в том, если идеальный язык программирования, практически не будет рассматриваться без контекста активного идеального редактора.

Хочу заметить, что все идеальное, в некотором роде "виртуальное" понятие и подразумевает бесконечное (или нацеленное в бесконечность) развитие. Нельзя написать редактор или язык программирования, сказать, что он идеален и поставить точку. Но можно сказать, что редактор имеет идеальную цель. Это значит, что делается все возможное, чтобы редактор был идеален и итерации по улучшению редактора никогда не будут заканчиваться. Например, можно разработать прекрасный язык SKYLANG и редактор к нему. В этом симбиозе, программистам будет намного быстрее работать чем в C++, редактор будет делать подсветку синтаксиса, классифицировать участки кода, предлагать контекстный выбор операторов. И все это в индивидуальной манере для каждого программиста (настраиваемой манере), так как, то что для начинающего программиста может быть ценной информацией, для опытного может быть тофтологией. После выпуска такого редактора, всегда могут появиться идеи, чтобы улучшить редактор или симбиоз, например может появиться способ идеального глобального переименования идентификаторов самим редактором. Топ технологией, на этом пути, следует считать одну единственную технологию, когда человек голосом разъяснил компьютеру какую программу нужно создать, а компьютер создал ее за считанные секунды. Или человек подумал что нужно сделать, мысли считались с рецепторов, автоматически составилась программа, организовала управление материей. Мысль стала явью. Можно ставить огромные сомнения в целесообразности этой цели, вероятно у нее есть много противников. Это вопрос философский, когда следует "остановиться" и тема для отдельной философской статьи. Но во-первых, неизвестно, вообще реально ли достижение топ цели и сколько требуется времени. Звезды ведь тоже горят не вечно, а лишь некоторое число миллиардов лет. Во вторых идеальное стремление, подразумевает и возможность изменения и самой топ цели, врядли разумно опасаться подобных стремлений. Ведь с другой стороны, не разумно что-то делать "кое-как" осознанно, но разумно "будь-что" делать идеально. Нет смысла многократно (в то время когда это можно не делать) бесполезно нажимать на клавиатуре 8 раз клавиши, набирая слово "function".
опубликовано ENERGY - 5 Nov 2015 12:27 GMT
последнее редактирование - 6 Nov 2015 12:15 GMT
комментировать