Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 126
Вы знаете, чем хороши большинство современных языков программирования? А тем, что если вы знакомы с программированием, знаете хотя бы один язык и чуть чуть английский, то вы можете понять 90% кода языка, который первый раз видите.
Чтобы пользоваться вашим детищем, нужно либо быть его создателем, либо предварительно мучиться пару недель, запоминая все эти сокращения.
Чтобы пользоваться вашим детищем, нужно либо быть его создателем, либо предварительно мучиться пару недель, запоминая все эти сокращения.
Сомневаюсь, что вы правы, возможно, легко поймёте лексику разных языков, почти везде if это if, но грамматика и семантика могут сильно отличаться. Если вы знаете Javascript то через час вы будете шпрехать на Elfu, а вот если вы знаете C++ то вы не скоро сможете писать на Ruby.
if был заменён чисто для эксперимента, посмотреть, «а чего будет если?» язык не стандартизован, всё можно менять в любом направлении. Но если не попробовать, то и не узнаешь, верно? Я же не предлагаю массово переходить на эльфу, а лишь приглашаю к обсуждению минусов и плюсов, буде таковые обнаружатся. Вместо if просился знак вопроса, но он уже используется в языке для архаичной конструкции из С.
В некоторых местах «if else» все равно приходится заменять на не столь понятные "? :".
Точно, можно использовать тернарный оператор вместо if else.
Eще можно так:
И еще несколько идей:
Eще можно так:
//if..else if statement
1==0&&(
console.log(5)||"первое условие"
)||7==8&&(
console.log(9)||1
)||7==7&&(
console.log(100)||"условие по умолчанию"
)
//ternar operator
var x = ['fail','ok'][+isOk];
И еще несколько идей:
//приведение к Integer
0 | x
+x
//перебор свойств объекта
for (var k in items) if (items.hasOwnProperty(k)) {
// do something with items[k]
}
//switch value
['none','first','second','third'][isFirst*1||isSecond*2||isThird*3]
//binary combine flags
['none','first','second','first and second or third'][isFirst+isSecond*2|isThird*3]
Писать и читать — разные вещи.
Он говорил про читать, и в этом я с ним согласен.
Он говорил про читать, и в этом я с ним согласен.
вам про Фому, а Вы про Ерёму.
Вам:
а вы:
Знание синтаксиса языка != умение программировать.
Вам:
если вы умеете программировать и понимаете английский
а вы:
Если вы знаете JS<...>Если вы знаете C++
Знание синтаксиса языка != умение программировать.
С практической точки зрения — всё примерно как вы описали.
Но само по себе это прямо таки кандидат в хаб "ненормальное программирование" (на момент публикации комментария пост не там) :-) Потому что прикольно, странно и ненормально. Но прикольно!
Но само по себе это прямо таки кандидат в хаб "ненормальное программирование" (на момент публикации комментария пост не там) :-) Потому что прикольно, странно и ненормально. Но прикольно!
Это разновидности языков. Нельзя вот так взять и понять пролог с первого взгляда. Или функциональщину, если до этого вся жизнь прошла в написании императивного кода. А вот внутри групп отличие действительно только в синтаксисе и сахаре.
Думаю, язык программирования должен быть максимально приближен к человеческому, дабы понимание языка было простым и чистым как мысли программиста. А писать всякие закорючки и при этом помнить их все все равно что изучить еще японский (грубо говоря), а потом уже на нем начать программировать, то есть два языка учить.
Вы правы и неправы одновременно. Ещё раньше чем мы начали программировать мы брали листок бумаги и рисовали закорючки. Да и сейчас в офисе можно встретить доску на которой идёт брэйнсторм, и там в основном стрелочки и каракули. Это тоже очень по-человечески.
Есть мысли, а есть слова. Так вот стрелочки и каракули — это мысли. А программирование — это слова.
Вы продолжайте продолжайте свою мысль,… зачем нам слова, если мысль была изначальной? не остаться ли нам совсем в мыслях?
p.s. когда читал про мозгоинтерфейс emotiv epoc, первое что я подумал, на сколько реально его интегрировать со средой разработки.
Вся идея топиккастера заключается не в усложнении восприятия, а в предоставлении возможности больше информации охватывать взглядом, и я надеюсь у него все получится.
p.s. когда читал про мозгоинтерфейс emotiv epoc, первое что я подумал, на сколько реально его интегрировать со средой разработки.
Вся идея топиккастера заключается не в усложнении восприятия, а в предоставлении возможности больше информации охватывать взглядом, и я надеюсь у него все получится.
Слова нужны, чтобы передать мысль другим.
У топик стартера уже все получилось, он пользуется этим и доволен.
Мне идея еще одного узкоспециализированного словаря иероглифов не нравится.
Для того, чтобы не не писать this. и так есть специальная конструкция.
У топик стартера уже все получилось, он пользуется этим и доволен.
Мне идея еще одного узкоспециализированного словаря иероглифов не нравится.
Для того, чтобы не не писать this. и так есть специальная конструкция.
Немного оффтопик, но вы что-то странное читали про Emotiv. Он, как и все прочие eeg-контроллеры, работает по принципу измерения мозговой активности. К возможности чтения мыслей он имеет примерно то же отношение, как измерение температуры на разных участках процессора к возможности прочитать исполняемый код — т.е. почти никакого. Управлять с его помощью чем бы то ни было довольно сложно, средний человек с трудом осиливает даже две команды, а чтобы стабильно использовать четыре команды — нужно чуть ли не в медитации сидеть почти все время. Встроенные гироскопы для позиционирования курсора (отслеживают повороты головы) — довольно неудобны для работы с текстом, поскольку им радикально не хватает точности.
*шутка про программирование в 1С*
Естественные языки — ужасны. Уподоблять им язык программирования — только портить.
Полностью согласен, что лучше, если язык программирования будет ближе к человеческому. Если сравнить русский и английский, то русский приближен к литературному и слова длиннее английских и букв в алфавите больше. Не зря, именно среди русских больше писателей и поэтов, чем среди англоязычных людей, да и людей других национальностей, да и литературные произведения на русском языке считаются более талантливыми и это подтверждают многие зарубежные аналитики. Да и русский язык логикой не понять, как и не понять как работает человеческий интеллект, иначе искусственный интеллект уже давно был бы создан. Не удивлюсь, если искусственный интеллект первым создаст именно русский человек.
#define
Поясните, будьте добры.
AndrewN намекает, что вы по сути заменили некоторые конструкции и функции языка на unicode символ, что, в целом, можно сделать с помощью #define
Но, ведь, общеизвестно, что define — это зло. Поэтому в Javascript его нет.
#define — это чудо! Пользоваться языком без #define скучно.
Ну да, зато ваш эльф — чудо
Простите? А как же, допустим, задавать в настройках проекта частоту работы ядра контроллера? Описывать порты для быстрого доступа?
Допустим, кусочек кода будет читаем, если:
А теперь представьте десятки подобных строк, где обраение к портам происходит не по именованным константам, а по их символьным именам. Да в этом заблудиться проще, чем укусить себя за палец.
Опять же
Иначе пересчитывать каждый раз ручками? Ну, нет, мне удобнее так, с дефайнами.
Допустим, кусочек кода будет читаем, если:
#define OW_PORT PORTD
#define OW_PIN (1<<PORTD7)
.....
OW_PORT &= ~OW_PIN; // Эмуляция шины OneWire
...
Или так:
PORTD &= ~(1<<PORTD7); // То же, но без дефайнов
А теперь представьте десятки подобных строк, где обраение к портам происходит не по именованным константам, а по их символьным именам. Да в этом заблудиться проще, чем укусить себя за палец.
Опять же
#define F_CPU 11059200
#define BaudRate (F_CPU/UART_BAUD_RATE)/16-1;
...
UBRR0 = BaudRate; // Baud rate
Иначе пересчитывать каждый раз ручками? Ну, нет, мне удобнее так, с дефайнами.
Поздравляю, вы изобрели APL.
Я понимаю, что это шутка, но вы можете запутать людей, APL изобрёл Кен Иверсон!
Но там есть несколько моментов. Во-первых тогда ещё не было Unicode, сейчас он есть и повсеместно подеживается. Код Эльфу отображается даже на хабре без всякой подготовки, а код APL до сих пор приводится скринами. Ну и кроме символов это был целый пласт семантики, тонкостей реализации, целый мир. А Эльфу это просто транспилер, который даже на синтаксис старается на покушаться лишний раз.
Но там есть несколько моментов. Во-первых тогда ещё не было Unicode, сейчас он есть и повсеместно подеживается. Код Эльфу отображается даже на хабре без всякой подготовки, а код APL до сих пор приводится скринами. Ну и кроме символов это был целый пласт семантики, тонкостей реализации, целый мир. А Эльфу это просто транспилер, который даже на синтаксис старается на покушаться лишний раз.
Ваша неправда, у меня в последней Firefox под Win7 предпоследний пункт опроса не отображается.
отображается даже на хабреохохо… А на гиктаймсе?
Откройте лучше свой пост под виндой, узнаете, как он «отображается».
Винда приходит и уходит, уступая место новой винде. А Unicode это вечные ценности!
Вы вот серьезно щас не понимаете разницы между кодировкой, стандартом и поддержкой символов в тех или иных шрифтах?
По поводу вечных ценностей в юникоде очень рекомендую эту статью: modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-cant-write-my-name
По поводу вечных ценностей в юникоде очень рекомендую эту статью: modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-cant-write-my-name
Вангую, что поддержа юникода в винде будет улучшаться.
Прикольно, статью Адитьи Мукерджи я читал недавно, как мир тесен. Но он говорит о вещах весьма специфических, в основном о том, что делает Harfbuzz в хроме и линуксе и редких буквах хинди. Есть такая вещь как композитный юникод. В эльфу все символы одиночные, никаких комбинаций с налезанием на шею друг другу нет.
Прикольно, статью Адитьи Мукерджи я читал недавно, как мир тесен. Но он говорит о вещах весьма специфических, в основном о том, что делает Harfbuzz в хроме и линуксе и редких буквах хинди. Есть такая вещь как композитный юникод. В эльфу все символы одиночные, никаких комбинаций с налезанием на шею друг другу нет.
Нет, APL изобрели вы! А анимэ изобрела Бритни Спирс, это уж все знают.
>тогда ещё не было Unicode, сейчас он есть и повсеместно подеживается. Код Эльфу отображается даже на хабре без всякой подготовки, а код APL до сих пор приводится скринами
И это печально. :( Потому что APL — мне очень нравится.
И это печально. :( Потому что APL — мне очень нравится.
Сходу можно запомнить только пару-тройку сокращений. Чтобы выучить все — надо постоянно работать с этим пару месяцев.
Насчет того «что глаз за такой синтаксис цепляется»: глаз цепляется за то, к чему привык цепляться. И если он за 10 лет привык цепляться к this и function, то ему будет проще без такого сахара.
Насчет того «что глаз за такой синтаксис цепляется»: глаз цепляется за то, к чему привык цепляться. И если он за 10 лет привык цепляться к this и function, то ему будет проще без такого сахара.
Вам должен понравиться APL.
Быстрая сортировка: qsort←{1≥⍴⍵:⍵ ⋄ e←⍵[?⍴⍵] ⋄ (∇(⍵<e)/⍵), ((⍵=e)/⍵), (∇(⍵>e)/⍵)}
Игра «Жизнь»: life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
Подсчет каждого символа в строке: freq←{(⍪∪⍵),+/(∪⍵)∘.⍷⍵}
Красота!
Быстрая сортировка: qsort←{1≥⍴⍵:⍵ ⋄ e←⍵[?⍴⍵] ⋄ (∇(⍵<e)/⍵), ((⍵=e)/⍵), (∇(⍵>e)/⍵)}
Игра «Жизнь»: life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
Подсчет каждого символа в строке: freq←{(⍪∪⍵),+/(∪⍵)∘.⍷⍵}
Красота!
А где тут новый язык то? Какую новую семантику вносят эти замены?
В статье явно указано, что автор не покушается на семантику, а хочет провести эксперимент, что будет если развивать язык через символьно-лексико-грамматический уровень. В лингвистике есть аналогичные случаи где разделены уровни языкознания, например кое-где с кириллицы перешли на латиницу и наоборот, а в Японии три «алфавита» которыми можно одно и то же записать, а жители Кантона и Пекина совсем не понимают друг друга на слух, но зато при переписке у них оказывается практически идентичный язык.
Поздравляю, вы изобрели APL из 60ых.
У меня многие ваши символы отображаются как квадратики. Это так и должно быть?
Вообще конечно 32 символа для языка программирования — это мало (особенно это понимаешь когда в С++ и подобных языках используются угловые скобки шаблонов). Но преимущество множества символов ASCII перед Unicode в том, что символы ASCII можно ввести с любой клавиатуры мира. В отличие от Unicode, в котором хоть и немало полезных символов, но толку от них без соответствующей клавиатуры или специального софта значительно меньше.
Я в каком-то обсуждении предлагал такую идею — использовать свободные коды 0x01… 0x1F (за исключением POSIX 0x00, 0x07..0a0A, 0x0D) для маппинга наиболее востребованных символов Unicode (вероятно стрелки двух видов, дополнительные пары скобок и еще что-нибудь… можно даже взять первоначальные символы ASCII).
Вообще конечно 32 символа для языка программирования — это мало (особенно это понимаешь когда в С++ и подобных языках используются угловые скобки шаблонов). Но преимущество множества символов ASCII перед Unicode в том, что символы ASCII можно ввести с любой клавиатуры мира. В отличие от Unicode, в котором хоть и немало полезных символов, но толку от них без соответствующей клавиатуры или специального софта значительно меньше.
Я в каком-то обсуждении предлагал такую идею — использовать свободные коды 0x01… 0x1F (за исключением POSIX 0x00, 0x07..0a0A, 0x0D) для маппинга наиболее востребованных символов Unicode (вероятно стрелки двух видов, дополнительные пары скобок и еще что-нибудь… можно даже взять первоначальные символы ASCII).
Ценю ваш юмор. Квадратики конечно не нарочно, но всё равно смешно.
Проблема ввода через «fu|TAB» или «th|TAB» решена легко. А ".1|TAB" даёт ¹.
Насчёт маппинга не понятно, в клавиатуру зашить маппинг или куда?
Проблема ввода через «fu|TAB» или «th|TAB» решена легко. А ".1|TAB" даёт ¹.
Насчёт маппинга не понятно, в клавиатуру зашить маппинг или куда?
В сам стандарт Юникода, в драйверы клавиатур и ОС и физически наносить на клавиши.
Поскольку количество клавиш ограничено, то можно нанести по одному спецсимволу на каждую буквенную клавишу + задействовать какую-нибудь клавишу или сочетание в качестве шифта.
Почему маппинг на однобайтовые коды? Ну все-же я считаю что Юникод не однороден, и базовая однобайтовая кодировка ASCII важнее чем двухбайтовый набор символов USC2, который в свою очередь важнее чем полный Unicode, превращающийся постепенно в помойку.
Поскольку количество клавиш ограничено, то можно нанести по одному спецсимволу на каждую буквенную клавишу + задействовать какую-нибудь клавишу или сочетание в качестве шифта.
Почему маппинг на однобайтовые коды? Ну все-же я считаю что Юникод не однороден, и базовая однобайтовая кодировка ASCII важнее чем двухбайтовый набор символов USC2, который в свою очередь важнее чем полный Unicode, превращающийся постепенно в помойку.
Вы зря выбрали квадратики. По мне так основная идея — возможность оценить взглядом больше информации и не путаться в скобках и словах.
⦿, ⦾, ⏀, ⚫, ⍽, ⚂ — для меня все эти символы сливаются в один и тот же символ. В том смысле что чтобы понять какой из них перед нами надо останавливать взгляд и внимание! Чего категорически нельзя делать при чтении.
⦿, ⦾, ⏀, ⚫, ⍽, ⚂ — для меня все эти символы сливаются в один и тот же символ. В том смысле что чтобы понять какой из них перед нами надо останавливать взгляд и внимание! Чего категорически нельзя делать при чтении.
www.explainxkcd.com/wiki/index.php/1537:_Types
Я как в исходники scalaz попал
Ещё один всё понял.
Выложите примеры кода картинками, а то у меня не все символы показываются =)
Хотя лучше просто пройти по ссылке, там все примеры ридми с репозитория и внедрённый в страничку средствами CSS шрифт elfu.ttf.
exebook.github.io/elfu/article.html
exebook.github.io/elfu/article.html
.bind можно поменять на стрелочку вверх, а запятую в объектах вообще убрать
Кажется я уже в транспилере забил ꘉ для бинд, но это было только на этой неделе и ещё не пользовался. Кстати это показывает, что на эльфу не обязательно использовать эльфу, можно писать на JS и только там где хочется применять эльфу.
Кстати сразу чувствуется человек много пишет на JS, я тоже регулярно задумываюсь как упростить object literal definition. Можно и двоеточие убрать во многих случаях.
object = { a 123 b 'hello' }
object = { a 123 b 'hello' }
У вас последние две строчки нечитаемые совершенно.
извините, жесть.
«Язык гетто» или слабонервным вход воспрещен. Можно смело ставить в одну линейку с BrainFuck и Whitespace. Выглядит отпадно! Но сам бы я на таком писать… увольте. Запишу в историю, с пометкой «Как делать не стоит».
Борюсь с остатками здравого смысла, и прошу разработать язык Орков.
Борюсь с остатками здравого смысла, и прошу разработать язык Орков.
*Отскрёб челюсть от столешницы и пошёл писать на Си под микроконтроллер, бубня про себя что-то про вообще все языки программирования и древние заветы Си*
Иероглифическое программирование. Почему бы и нет, есть же Brainfuck, Malbolge и т.п. экзотика. Спасибо) Я в шоке.
Приходит такой новичек к вам в команду, открывает код и видит пелену всяких смайликов вместо кода. Смотрит календарь — нет там не 1 апреля, дальше та картинка с котиком выше :)
Вместо верхнего индекса для доступа к элементу массива стоит использовать нижний — традиционная математическая нотация. Однако код a[b[c[d[e]]]] станет не читаемым не из за иероглифов, а из за того что шрифт станет слишком мелким.
В статье указано, что в Unicode практически нет нижнего индекса, есть только верхний.
a[b][c][d][e] записывается как aᵇᶜᵈᵉ.
Записать a[b[c[d[e]]]] можно только как a[b[c[d[e]]]] или a[b[c[dᵉ]]], большая вложенность индексов тут невозможна, это же просто символы юникода, а не особый графический редактор как Матлаб или Вольфрам.
a[b][c][d][e] записывается как aᵇᶜᵈᵉ.
Записать a[b[c[d[e]]]] можно только как a[b[c[d[e]]]] или a[b[c[dᵉ]]], большая вложенность индексов тут невозможна, это же просто символы юникода, а не особый графический редактор как Матлаб или Вольфрам.
Стрелочки в push/unshift есть смысл сделать в сторону A (т.к. запихиваем в A),
ну и для pop/shift наоборот — от A.
ну и для pop/shift наоборот — от A.
⬊ is for .push and ⬈ is for .pop.
⬋ is for .shift and ⬉ is for .unshift.
Всего же четыре комманды для работы со стеком в Javascript. Причём shift/unshift это аналог pop/push, только «с другой стороны» массива. Поэтому в любом случае надо использовать все 4 стрелочки. Впрочем есть ещё вертикальные и горизонтальные. А так же несколько десятков всяких других.
Предложенная вами мнемоника «по направлению к идентификатору» мне в голову не приходила, я больше всё воображал стэк как некую пачку чего-то, да ещё с двумя концами, так что, спасибо за ценную мысль!
⬋ is for .shift and ⬉ is for .unshift.
Всего же четыре комманды для работы со стеком в Javascript. Причём shift/unshift это аналог pop/push, только «с другой стороны» массива. Поэтому в любом случае надо использовать все 4 стрелочки. Впрочем есть ещё вертикальные и горизонтальные. А так же несколько десятков всяких других.
Предложенная вами мнемоника «по направлению к идентификатору» мне в голову не приходила, я больше всё воображал стэк как некую пачку чего-то, да ещё с двумя концами, так что, спасибо за ценную мысль!
1. На лекциях «Станки и инструменты» (речь о технологии машиностроения) препод, имея за плечами неслабую практику работы токарем, задавал нам такой вопрос:
— Вот есть станок с четырьмя хитровыделанными ручками переключения передач, комбинацией которых можно выбрать одно из дофига скольки возможных количество оборотов шпинделя в минуту, а есть другой станок, на котором таких ручек 10, и скоростей всего 10, и каждая из этих ручек включает и выключает свою скорость. Который удобнее в работе?
Все дружно так хором отвечали, мол, первый, канешна! Режимов ведь больше!
На что препод, хитрО прищурившись, говорил: А вот фиг вам! Эти 10 ручек ты знаешь на ощупь. Надо переключить — не глядя переключаешь нужную из одного крайнего положения в другое крайнее (а третьего и нет) и точишь дальше. Напротив, работая на первом же станке ты бросаешь всё и идёшь полминуты дёргаешь эти долбаные рукоятки, которые к тому же ещё и включаться как надо не хотят.
2. Балуясь в своё время на Спектруме, сперва поражался и долго ржал над его клавиатурой:
Всего 40 клавиш, на многих нанесены ключевые слова из бейсика и не только. «Нафига?» — недоумевал я, набрать же несложно!
Спустя каких-то полгода неожиданно поймал себя на мысли, что сижу и пишу программу в кромешной тьме, при свете только телевизора. Стемнело, пока сидел. Клавиш почти не видно, видно только их очертания, слепым методом печати не владею даже примерно. Но программу писал. Да, баловство (хотя тогда вроде курсовую какую-то рассчитывал). Спустя много лет с лёгкой грустью периодически вспоминаю то время, в которой слово RANDOMIZE набиралось одним нажатием. Эхххх… Дааа… :)
3. Ну да, если мыслить в рамках эксперимента, проведённого автором, придётся многое запоминать. Эммм… А сейчас как будто запоминать приходится мало. Вот, приходит, мол, джуниор, и видит, мол, такое. Так блин, большинству джуниоров любой код сложнее хелловорда покажется такииим!!!
4. Как давно когда-то читал у кого-то из матёрых касательно интерфейсов — идеальный интерфейс у устройства, которое называется «КАРАНДАШ». Да, да, тот самый, деревянный. Учиться пользоваться им приходится долго, зато, как освоил — его ваще не замечаешь. В буквальном смысле. Возьмите ручку/карандаш, бумажку, попишите чего-нибудь и понаблюдайте за собой — куда вы смотрите в момент письма? Навряд ли удивлю, но — на кончик карандаша. На то место, которое пишет. Но, блин, держите-то вы его не за это место, а за другое! И никого, блин, нифига не парит, что то место, которое пишет на самом деле, держать неудобно, но есть нормальная абстракция, которая позволяет этим делом управлять. Сам карандаш, собсно, за который вы его и держите обычно.
Так же и с кодом. То, что программист обычно пишет, не исполняется никогда. От слова ваще. Исполняется некий другой код, в котором за программиста некое программное решение написанный код перевело в исполняемый, который ваще не код, на самом деле, а хитровыделанная последовательность электрических импульсов и состояний. Которые, в свою очередь… не, глубже не полезу :)
Исходя из всего вышенаписанного, как именно выглядит код — не так уж и важно, на самом деле. Важно, чтобы он был читаемым, писаемым, и, самое главное, исполняемым. :) Правильно исполняемым, да. Ведь, глядите: исторически изначально были номера команд, потом наборы номеров команд, потом мнемоники команд, потом появились первые либы, потом либы интегрировались и переросли в языки… И, заметьте, опаньки: операторы и ключевые слова в языках — есть! А asm-мнемоники и коды команд процессора — ушли. Нет, где-то и они есть, на своих уровнях. Но здесь — их нет. Да и не надо, не место им тут.
То, что мы сейчас наблюдаем на поприще написания кода, похоже на следующий этап. Уже не особо важен сам ЯП, на котором код пишется. Используемая платформа, на которой это всё вертится, фреймворки и прочие либы становится порой гораздо важнее. И тут вылазит ещё один момент касаемо запоминания: если авторы языков часто ограничивают введение новых ключевых слов, то авторы фреймворков обычно вааааще не стесняются — чем больше, тем круче! И запоминать приходится часто не одно новое ключевое слово языка, 100500 функций/состояний/дефферед/префферед/хренещознаетчегофферед из того или иного API, фреймворка, библиотеки. Тыщи их, и имя им — легион… :)
И, здесь я с автором совершенно согласен — пора двигаться дальше. Пора придумывать что-то новое. Но не для того, чтобы добавить к вышеупомянутым 100500 ещё половину, а для того, чтобы родилась какая-то новая концепция, которая объединит в себе хотя бы часть из этих стапицот, и уменьшицца стопицот, и часть изъятая устаканицца, стандартизуецца, уедет в ЯП и будет всем щасье…
Давно уже пора, на самом-то деле. И, если это будет особая стрелочка, которая напишется одной-двумя клавишами, но эффективно заменит собой целую конструкцию как для написания, так и для чтения — так почему нет? Можно покритиковать выбор тех или иных символов для тех или иных задач, а можно подумать и вместе выбрать другой или вообще отказаться от символа в пользу другого слова, например. Или ваще оставить по-старому. Всё это можно и нужно.
Единственное, что для этого на самом деле нужно делать — это просто делать. И сделать.
Автор делает. Спасибо ему.
— Вот есть станок с четырьмя хитровыделанными ручками переключения передач, комбинацией которых можно выбрать одно из дофига скольки возможных количество оборотов шпинделя в минуту, а есть другой станок, на котором таких ручек 10, и скоростей всего 10, и каждая из этих ручек включает и выключает свою скорость. Который удобнее в работе?
Все дружно так хором отвечали, мол, первый, канешна! Режимов ведь больше!
На что препод, хитрО прищурившись, говорил: А вот фиг вам! Эти 10 ручек ты знаешь на ощупь. Надо переключить — не глядя переключаешь нужную из одного крайнего положения в другое крайнее (а третьего и нет) и точишь дальше. Напротив, работая на первом же станке ты бросаешь всё и идёшь полминуты дёргаешь эти долбаные рукоятки, которые к тому же ещё и включаться как надо не хотят.
2. Балуясь в своё время на Спектруме, сперва поражался и долго ржал над его клавиатурой:
Всего 40 клавиш, на многих нанесены ключевые слова из бейсика и не только. «Нафига?» — недоумевал я, набрать же несложно!
Спустя каких-то полгода неожиданно поймал себя на мысли, что сижу и пишу программу в кромешной тьме, при свете только телевизора. Стемнело, пока сидел. Клавиш почти не видно, видно только их очертания, слепым методом печати не владею даже примерно. Но программу писал. Да, баловство (хотя тогда вроде курсовую какую-то рассчитывал). Спустя много лет с лёгкой грустью периодически вспоминаю то время, в которой слово RANDOMIZE набиралось одним нажатием. Эхххх… Дааа… :)
3. Ну да, если мыслить в рамках эксперимента, проведённого автором, придётся многое запоминать. Эммм… А сейчас как будто запоминать приходится мало. Вот, приходит, мол, джуниор, и видит, мол, такое. Так блин, большинству джуниоров любой код сложнее хелловорда покажется такииим!!!
4. Как давно когда-то читал у кого-то из матёрых касательно интерфейсов — идеальный интерфейс у устройства, которое называется «КАРАНДАШ». Да, да, тот самый, деревянный. Учиться пользоваться им приходится долго, зато, как освоил — его ваще не замечаешь. В буквальном смысле. Возьмите ручку/карандаш, бумажку, попишите чего-нибудь и понаблюдайте за собой — куда вы смотрите в момент письма? Навряд ли удивлю, но — на кончик карандаша. На то место, которое пишет. Но, блин, держите-то вы его не за это место, а за другое! И никого, блин, нифига не парит, что то место, которое пишет на самом деле, держать неудобно, но есть нормальная абстракция, которая позволяет этим делом управлять. Сам карандаш, собсно, за который вы его и держите обычно.
Так же и с кодом. То, что программист обычно пишет, не исполняется никогда. От слова ваще. Исполняется некий другой код, в котором за программиста некое программное решение написанный код перевело в исполняемый, который ваще не код, на самом деле, а хитровыделанная последовательность электрических импульсов и состояний. Которые, в свою очередь… не, глубже не полезу :)
Исходя из всего вышенаписанного, как именно выглядит код — не так уж и важно, на самом деле. Важно, чтобы он был читаемым, писаемым, и, самое главное, исполняемым. :) Правильно исполняемым, да. Ведь, глядите: исторически изначально были номера команд, потом наборы номеров команд, потом мнемоники команд, потом появились первые либы, потом либы интегрировались и переросли в языки… И, заметьте, опаньки: операторы и ключевые слова в языках — есть! А asm-мнемоники и коды команд процессора — ушли. Нет, где-то и они есть, на своих уровнях. Но здесь — их нет. Да и не надо, не место им тут.
То, что мы сейчас наблюдаем на поприще написания кода, похоже на следующий этап. Уже не особо важен сам ЯП, на котором код пишется. Используемая платформа, на которой это всё вертится, фреймворки и прочие либы становится порой гораздо важнее. И тут вылазит ещё один момент касаемо запоминания: если авторы языков часто ограничивают введение новых ключевых слов, то авторы фреймворков обычно вааааще не стесняются — чем больше, тем круче! И запоминать приходится часто не одно новое ключевое слово языка, 100500 функций/состояний/дефферед/префферед/хренещознаетчегофферед из того или иного API, фреймворка, библиотеки. Тыщи их, и имя им — легион… :)
И, здесь я с автором совершенно согласен — пора двигаться дальше. Пора придумывать что-то новое. Но не для того, чтобы добавить к вышеупомянутым 100500 ещё половину, а для того, чтобы родилась какая-то новая концепция, которая объединит в себе хотя бы часть из этих стапицот, и уменьшицца стопицот, и часть изъятая устаканицца, стандартизуецца, уедет в ЯП и будет всем щасье…
Давно уже пора, на самом-то деле. И, если это будет особая стрелочка, которая напишется одной-двумя клавишами, но эффективно заменит собой целую конструкцию как для написания, так и для чтения — так почему нет? Можно покритиковать выбор тех или иных символов для тех или иных задач, а можно подумать и вместе выбрать другой или вообще отказаться от символа в пользу другого слова, например. Или ваще оставить по-старому. Всё это можно и нужно.
Единственное, что для этого на самом деле нужно делать — это просто делать. И сделать.
Автор делает. Спасибо ему.
Надо ему как в APL и в Вашем примере создать альтернативную раскладку клавиатуры, чтобы нужный спецсимвол было бы легко набрать.
У APL самой главной проблемой были шрифты, из-за чего на первом попавшемся компьютере этот язык нельзя было запустить. Ведь подавляющее большинство компьютеров имело тогда не графический, а текстовый дисплей с намертво зашитыми символами, не предусматривающими показ на экране спецсимволов APL. Сейчас же есть UNICODE и прежних проблем имевшихся у APL уже давно нет.
Спасибо, вы реально внесли вклад в дискуссию!
С мобильного Chrome почти никакие символы не читаются(
И большей проблемой выглядит не восприятие (да, дело привычки, хотя тут как-то перебор уже), а ввода этого кода.
И большей проблемой выглядит не восприятие (да, дело привычки, хотя тут как-то перебор уже), а ввода этого кода.
Ну, да, самая большая проблема — это ввести эти символы. Потому и нужна спецраскладка клавиатуры как в APL.
Ну, или можно набранные команды автоматом конвертировать символы, как при наборе китайских иероглифов, которые набирают латиницей по произношению в пекинском диалекте.
Ну, или можно набранные команды автоматом конвертировать символы, как при наборе китайских иероглифов, которые набирают латиницей по произношению в пекинском диалекте.
То что вы предлагаете, нам простым смертным не осилить, надо влиять на разработчиков ОС, производителей хардваре, стандартизирующие организации. Поэтому только я и пошёл путём наиболее практичным в данный момент, символы только уже заявленые в Unicode и набор через TAB-completion — уже доступная фича в многих редакторах.
Учитывая, что большинство символов заменяет кейворды от трёх до 10 символов каждый, то даже вместе с кнопкой TAB получается набирать проще. Скажем fu|TAB три клавиши, function — восемь клавиш. Повторюсь, меня поначалу вопрос ввода очень беспокоил, реально ли это, или замучаешся, но практически сразу на практике стало ясно — набирать легко. Почти все снипеты для комплеции двухбуквенные. В общем, хотя я ставил задачу в облегчить чтение, в первую очередь, но и набор оказался облегчён как следствие к некоторому моему удивлению.
Учитывая, что большинство символов заменяет кейворды от трёх до 10 символов каждый, то даже вместе с кнопкой TAB получается набирать проще. Скажем fu|TAB три клавиши, function — восемь клавиш. Повторюсь, меня поначалу вопрос ввода очень беспокоил, реально ли это, или замучаешся, но практически сразу на практике стало ясно — набирать легко. Почти все снипеты для комплеции двухбуквенные. В общем, хотя я ставил задачу в облегчить чтение, в первую очередь, но и набор оказался облегчён как следствие к некоторому моему удивлению.
Все проблемы всегда от плохого нейминга и поряточной структуры кода. Минимально даже ES6 спасет этот код. Типа
(() => {
let b, c, d, x, y, z;
//...
let compare = (a) => {
//...
}
let isSmth = (b + c) && d,
isAnthr = x + y / z,
a = compare(isSmth, isAnthr, () => alert('val'));
//...
})();
Что есть «поряточной»?
Кстати, только на днях в рассылке хром-девелоперов промелькнула инфа что arrow function может считаться «mostly implemented».
В некоторых публикациях пишут, что изначально то, что мы знаем, как Javascript, хотели сделать синтаксически похожим на Lisp, но по маркетинговым соображениям сделали похожим на Java.
Ифкуиль же!
Ждал от заголовка статьи перевод языковых конструкций на синдарин.
Это напоминает старую дискуссию вокруг эсперанто. Автор языка наделал там букв с кружочками и птичками, что оказалось во всех отношениях неудобно — ни во времена линотипов, ни во времена Юникода. В языках-последователях извращаться не стали, необычные символы сделали обычными диграфами.
Здесь то же самое — гораздо быстрее и проще прочитать и осмыслить «if», чем некую непонятную закорючку. А когда этих закорючек много, от них и вовсе рябит в глазах.
Практическое применение имеют только стрелки, потому что это символ, известный всем с детства, и считывающийся автоматически. Но и их смысл не стоит слишком уже раздувать, вводя 100500 их видов.
Здесь то же самое — гораздо быстрее и проще прочитать и осмыслить «if», чем некую непонятную закорючку. А когда этих закорючек много, от них и вовсе рябит в глазах.
Практическое применение имеют только стрелки, потому что это символ, известный всем с детства, и считывающийся автоматически. Но и их смысл не стоит слишком уже раздувать, вводя 100500 их видов.
>гораздо быстрее и проще прочитать и осмыслить «if», чем некую непонятную закорючку
Что мешает стандартные мат.символы как это сделали в APL?
Что мешает стандартные мат.символы как это сделали в APL?
Очевидно, то же самое — проблемы с вводом и выводом.
Кроме того, на мой субъективный взгляд, математические формулы похожи на какой-то очень кривой и плохо читаемый язык программирования, и для человека, пришедшего в программирование не со стороны математики, они не так уж удобны.
Что-то мне подсказывает, что я в этом мнении не одинок, поскольку все попытки внедрить в ЯП математическую нотацию провалились (например, в Алголе-60 тоже с этим баловались). Да и Вольфрам сделал у себя в Математике единый универсальный синтаксис без всяких иероглифов.
Кроме того, на мой субъективный взгляд, математические формулы похожи на какой-то очень кривой и плохо читаемый язык программирования, и для человека, пришедшего в программирование не со стороны математики, они не так уж удобны.
Что-то мне подсказывает, что я в этом мнении не одинок, поскольку все попытки внедрить в ЯП математическую нотацию провалились (например, в Алголе-60 тоже с этим баловались). Да и Вольфрам сделал у себя в Математике единый универсальный синтаксис без всяких иероглифов.
>математические формулы похожи на какой-то очень кривой и плохо читаемый язык программирования, и для человека, пришедшего в программирование не со стороны математики, они не так уж удобны.
У тех кто пришёл не со стороны математики имеются также серьёзные проблемы с функциональными языками с их Лямбда-исчислением. Но, тем не менее те кто пишут на таких языках всё же находятся. (^_^)
У тех кто пришёл не со стороны математики имеются также серьёзные проблемы с функциональными языками с их Лямбда-исчислением. Но, тем не менее те кто пишут на таких языках всё же находятся. (^_^)
Думаю, что вы не правы.
Лямбда-исчисление — это очень специфическая математика, никак не математическая классика. Пришедшие в программирование со стороны математики, особенно прикладной, скорей пишут в стиле Фортрана-66 — сам видел.
Что же касается ФП, то лично я его освоил по прекрасной книге «Higher-Order Perl», подход в которой ничуть не математический, а чисто программистский: вот как красиво можно решить сложные задачи. Следовательно, путь из абстрактной математики — не единственный.
Лямбда-исчисление — это очень специфическая математика, никак не математическая классика. Пришедшие в программирование со стороны математики, особенно прикладной, скорей пишут в стиле Фортрана-66 — сам видел.
Что же касается ФП, то лично я его освоил по прекрасной книге «Higher-Order Perl», подход в которой ничуть не математический, а чисто программистский: вот как красиво можно решить сложные задачи. Следовательно, путь из абстрактной математики — не единственный.
Это как-то так в итоге выглядит функция из первого примера?
Теперь появляется проблема со скобочками…
(➮() { closure = 'val'; $ ➮() { ロ closure } })())
Теперь появляется проблема со скобочками…
У меня тоже вместо ряда символов — квадратики.
Надо было не выпендриваться, а как в APL взять стандартные мат.символы и буквы греческого алфавита, которые благодаря UNICODE — сейчас у всех есть.
(а не как в о времена APL — когда на большинстве компьютеров эти символы просто отсутствовали в charset)
Надо было не выпендриваться, а как в APL взять стандартные мат.символы и буквы греческого алфавита, которые благодаря UNICODE — сейчас у всех есть.
(а не как в о времена APL — когда на большинстве компьютеров эти символы просто отсутствовали в charset)
(➮ { closure = 'val'; $ ➮ { ロ closure; } })()
если нет ни имени ни аргументов то фигурная скобка может сразу следовать за «иероглифом» функции (стрелкой). И в конце выражения выводимого по ロ (console.log()) надо ставить точку с запятой, если не конец строки.
если нет ни имени ни аргументов то фигурная скобка может сразу следовать за «иероглифом» функции (стрелкой). И в конце выражения выводимого по ロ (console.log()) надо ставить точку с запятой, если не конец строки.
По-моему самое замечательное это «по умолчанию объявлены три параметра a, b, c».
У меня, в стековом языке, который я пишу, операция «возврат предыдущего результата» возможна для x, y, z, t, u, v, w — семи аргументов. Ну а на моей предыдущей работе checkstyle ставил warning методам, у которых было больше семи аргументов. Три — мало…
Не очень понял посылы двух предыдущих ораторов (это не ирония, не сарказм, просто факт), поэтому для ясности скажу:
a b c объявляются если полностью опустить блок декларации аргументов:
➮ min { // молча объявлены a,b,c
if (a < b) $ a;
$ b
}
➮ showVersion () { // функция без аргументов
var a = '0', b = '1', c = '25'
ロ 'version: ' +a+ '.' +b+ '.' +c
}
➮ distance (x, y, x2, y2) { // явно объявленые имена
x -= x2
y -= y2
$ √(x*x + y*y)
}
a b c объявляются если полностью опустить блок декларации аргументов:
➮ min { // молча объявлены a,b,c
if (a < b) $ a;
$ b
}
➮ showVersion () { // функция без аргументов
var a = '0', b = '1', c = '25'
ロ 'version: ' +a+ '.' +b+ '.' +c
}
➮ distance (x, y, x2, y2) { // явно объявленые имена
x -= x2
y -= y2
$ √(x*x + y*y)
}
Назад, к природе, к APL!
В жабоскрипе эти бесконечные this и function пишутся от безысходности, — от примитивной объектной модели.
А поскольку они сильно перегружены ролями — это и конструкторы классов, и конструкторы объектов, и продолжения, и замыкания, и изоляция локальных переменных, и просто самые обычные функции, — получается адъ.
Так может, стоило не в сахар играть, а пойти чуть дальше-глубже?
Например, паттерн ((function(x,y,z){.....})(a,b,c)) засахарить в виде ◄x=a,y=b,z=c■.....► (без параметров это будет просто ◄.....►)
В жабоскрипе эти бесконечные this и function пишутся от безысходности, — от примитивной объектной модели.
А поскольку они сильно перегружены ролями — это и конструкторы классов, и конструкторы объектов, и продолжения, и замыкания, и изоляция локальных переменных, и просто самые обычные функции, — получается адъ.
Так может, стоило не в сахар играть, а пойти чуть дальше-глубже?
Например, паттерн ((function(x,y,z){.....})(a,b,c)) засахарить в виде ◄x=a,y=b,z=c■.....► (без параметров это будет просто ◄.....►)
⌥ без ⌘ — деньги на ветер.
В стандартной библиотеке скалы вполне используют стандартные замены
=> и ⇒, <- и ←, -> и →. Они эквивалентны с точки зрения синтаксиса.
Поздравляю, вы изобрели CoffeeScript.
Окончательно созрела мысль, что набирать код и читать/править код лучше на разных языках…
Предлагаю не ставить точку с запятой в конце без необходимости(например, в буркмарклете).
Вместо квадратных скобочек использовать для индекса подчеркивание
Нравится идея идеографического программирования.
Можно использовать китайские иероглифы в качестве идеограм.
Вместо квадратных скобочек использовать для индекса подчеркивание
arr_i -> arr[i]
arr_i_j -> arr[i][j]
const symbol = 0
const prev = 0
const curr = 1
const next = 2
i_symbol_next -> i[0][2]
j_curr_symbol -> j[1][0]
Нравится идея идеографического программирования.
Можно использовать китайские иероглифы в качестве идеограм.
Небольшой неполный список:
巛 — поток
工 — рабочий
王 — король(king) — main
主 — управление(manage)
入 — входить
囗 — импорт
立 — устанавливать
釆 — собирать
罒 — держать
用 — использовать(using)
开 — открывать, начинать
匚 — содержать
儿 — child
厂 — фабрика(factory)
不 — нет, отрицание
是 — быть
有 — иметь
木 — дерево(tree)
支 — ветка(branch)
本 — корень(root)
示 — показывать(show)
风 — стиль
文 — знак
言 — слово
去 — идти
全 — весь(all)
至 — максимум(max)
止 — stop, till
下 — следующий(next)
上 — предыдущий(previous)
这 — это(this)
爻 — влиять, воздействовать
見 — вид(view)
большая часть приведенных иероглифов — радикалы
да простят меня китайцы за столь фривольное толкование иероглифов
工 — рабочий
王 — король(king) — main
主 — управление(manage)
入 — входить
囗 — импорт
立 — устанавливать
釆 — собирать
罒 — держать
用 — использовать(using)
开 — открывать, начинать
匚 — содержать
儿 — child
厂 — фабрика(factory)
不 — нет, отрицание
是 — быть
有 — иметь
木 — дерево(tree)
支 — ветка(branch)
本 — корень(root)
示 — показывать(show)
风 — стиль
文 — знак
言 — слово
去 — идти
全 — весь(all)
至 — максимум(max)
止 — stop, till
下 — следующий(next)
上 — предыдущий(previous)
这 — это(this)
爻 — влиять, воздействовать
見 — вид(view)
большая часть приведенных иероглифов — радикалы
да простят меня китайцы за столь фривольное толкование иероглифов
Радикалы, это класно) заодно подучить можно.
Хотя в данном примере, это всё просто индентификаторы, на сам язык они не влияют. Например, в JavaScript все эти символы валидные составляющие для идентификаторов.
Правда лексер Эльфу на них ругается, надо поправить.
Список, видно, трудозатрантый, спасибо. В копилку.
Хотя в данном примере, это всё просто индентификаторы, на сам язык они не влияют. Например, в JavaScript все эти символы валидные составляющие для идентификаторов.
// обычный JavaScript
function 王 () {
var 这 = this
console.log(这)
}
Правда лексер Эльфу на них ругается, надо поправить.
Список, видно, трудозатрантый, спасибо. В копилку.
ロ ⍽(⚂ * 100)
Тут вот какая-проблема, человек читает эту штуку таким образом:
- Напечатать то что будет дальше.
- Округлить то что будет дальше и напечатать.
- Взять случайное число, что-то сотворить, округлить и напечатать.
- Взять случайное число, умножить на 100, округлить и напечатать.
Долгой тренировкой можно добиться быстрого разбора таких цепочек длиной 5-7. Но при длине 12 они уже требуют чтения то вперёд то назад по очереди. А если пишуший не очень задумывался о том что творит то вообще беспорядочно приходится переключать направление чтения.
Есть несколько попыток эту проблему обойти, например Forth делает как-то так:
⚂
100
*
⍽
ロ
Писать неудобно, в тяжёлых случаях приходится помнить что было там раньше, но хоть читаем в одну сторону.
А вот в bash проблему решили спец. оператором и дисциплиной:
⚂ | * 100 | ⍽ | ロ
Здравствуйте.
ロ — это особенный случай, у меня в редакторе он даже подсвечивается другим, своим цветом. Всё-таки вывод в консоль постоянно используется как некая мета-комманда при отладке в том числе.
В остальном, согласен, граматику идеографического языка (или даже частично идеографического) надо писать с нуля, решая какие-то фундаментальные вопросы.
Но, пока-что имеем, то что имеем — обёртку над JavaScript.
ロ — это особенный случай, у меня в редакторе он даже подсвечивается другим, своим цветом. Всё-таки вывод в консоль постоянно используется как некая мета-комманда при отладке в том числе.
В остальном, согласен, граматику идеографического языка (или даже частично идеографического) надо писать с нуля, решая какие-то фундаментальные вопросы.
Но, пока-что имеем, то что имеем — обёртку над JavaScript.
По-настоящему эльфийский язык программирования - тот, который даст на выходе совершенный машинный код. Более совершенный чем у "неэльфийских". С самым минимальным оверхедом. При том же удобстве кодинга и краткости записи. Вообще, нет плохих и хороших языков, есть плохие и хорошие компиляторы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эльфийский язык программирования