Pull to refresh

Comments 284

Интерпретатор бэйсика на PHP?
Почему Вы считаете, что он будет работать со скоростью PHP7?
Компилятор языка — одна функция на 500+ строк
Как минимум медленнее на накладные расходы.

делал тесты. после компиляции в PHP код складывается в кэш и больше не компилируется.
разница в скорости исполнения оказалась незначительная ( не смог даже устойчиво вычислить процент потерь, видимо менее 1% )
Так не в том дело. У вас препроцессор, генерирующий исходный код на другом языке. Как он в принципе может работать быстрее чем код, изначально написанный на этом языке? Ладно бы если бы вы PHP-шный лексер подправили и сделали свой язык поверх PHP-шного рантайма, но препроцессор…
Как он в принципе может работать быстрее чем код, изначально написанный на этом языке?


Простейший код — не может.
А сложный — вполне, если транслятор еще и оптимизатором является.

stackoverflow.com/questions/20929783/how-is-dart2js-code-faster-than-javascript
dart2js is able to perform optimizations that would not normally be manually added in JavaScript code.
UFO just landed and posted this here
По приведенной мною ссылке хорошо разжевано, но если вам влом прочитать всего 3 абзаца или у вас плохой английский, то давайте я еще раз пожую специально для вас:

В абзаце первом сказано, выделю главную мысль:
not normally be manually added


Это английское слово означает «вручную». То есть сверх того, что автоматически способен оптимизировать V8, так что V8 тут вообще постольку-поскольку.

Абзац второй из текста по приведенной мною ссылке:
Of course, you can run automated tools on JavaScript source to generate better JavaScript as well, this is what the Closure compiler does

В этом абзаце говорится про еще один вариант с хорошей оптимизацией (опять таки быстрее обычного «ручного» JavaScript, и речь даже о другом языке и о другой цепочке, которую нужно пройти исходному коду чтобы быть оптимизированным. То есть Dart тут ничего нового не открыл. Возможность получать более оптимизированный JS-код существует и помимо Dart.

Ну и последний третий абзац:
Technically, you can manually achieve the same speed with handwritten JavaScript if you know all the tricks.

Здесь написано, что:
«вы можете и достичь той же (высокой) скорости, написав соответствующий код на JavaScript вручную, если вы знаете (и будете) использовать все трюки (и оптимизации)» — в скобках приведено мое пояснение.

Повторяю еще раз, но уже разжевываю:
Я писал:
Простейший код — не может.

Жую: небольшой объем кода или легко оптимизируется человеком или вы не заметите разницу в производительности по причине небольшого объема кода и небольшого же количества неоптимизированных мест в нем.

Я писал:
А сложный — вполне, если транслятор еще и оптимизатором является.

Жую: человеку не по силам (или попросту лениво) оптимизировать большие объемы кода. Поэтому сложный код как правило не сильно-то и оптимизируется. Более того, напротив, в сложных проектах зачастую применяются фреймворки и библиотеки, которые только дальше абстрагируют нас (что затрудняет ручную оптимизацию) и содержат дополнительные исполняемые инструкции. Уже много лет как дешевле купить более мощный компьютер, чем заплатить программисту за дополнительную оптимизацию. Но, в принципе, вам никто не мешает вручную делать быстрый код такого же качества как выдают автоматические инструменты dart2js и GWT/Closure. Другой вопрос — а согласятся ли это оплачивать ваш заказчик/работодатель, потому как вручную = дорого на сложных проектах.

UFO just landed and posted this here
UFO just landed and posted this here
У меня другой вопрос, почему движок Javascript в браузере не может выполнять те же самые оптимизации с исходным кодом?

Сделайте. Ведь и Chromium и Firefox — открытые проекты.
Вангую:
Требуется довольно длительная подготовки скачиваемого с сайтов JS (компиляции/оптимизации) прежде чем получим готовый результат и сможем отобразить страницу. Время отображения страницы все же критично.

Когда-нибудь и до этого руки дойдут у разработчиков.
UFO just landed and posted this here
Ходят слухи, что в некоторых интерпретаторах есть ленивый оптимизирующий JIT. Т.е. вначале код интерпретируется, а затем уже врубается оптимзирующий компилятор и последующая загрузка из кеша уже запускает готовый и «быстрый» код. Так что да, верно, кеш. И пофигу на скорость оптимизаций, оно там в фоне.

Это не точная информация, «где-то видел, где-то слышал». В любом случае подобная ленивая деоптимизация существует: docs.google.com/document/d/1ELgd71B6iBaU6UmZ_lvwxf_OrYYnv0e4nuzZpK05-pg/edit

P.S. Не могу не подметить иронию на счёт накидывания JS кода на TurboFan (что по ссылке выше) %)
UFO just landed and posted this here
UFO just landed and posted this here
так удобнее в разговоре. компилятор — программа компилируется. препроцессор — программа препроцессорируется.
Неплохо было бы ещё приложить какой-нибудь `example.bas` в репу
в вики на гите много примеров, практически через абзац.
а крупных проектов пока нет, может первым будете?
Мне интересно, без издёвки, а зачем?
Если в целом по проекту зачем я его сделал?
Зачем пишут новые языки программирования? Денег это точно не приносит. Код неприятный и очень сложный. Перспективы туманные, поддержки никакой.

Еще и мизерное количество языков программирования разработанных у нас.

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

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

А вот про обучение кого-либо веб-программированию — это вы лучше забудьте пока. Всё-таки вам самому ещё учиться и учиться, а студентам желательно иметь дело со 100%-работающими инструментами. Ну и про бейсик ниже уже сказали :)
Нет, меня интересовало зачем кому-то делать крупный проект используя то что вы выложили?

Вроде бы в XXI веке парсинг как раз более-менее тривиальная часть (ну кроме излишне заковыристых грамматик), главное – семантика, особенно если она существенно отличается от целевого языка.

что-то у меня в голове не складывается «крупный проект» и «начинающий» и в целом, не страдайте фигней=)
ну пока «крупным» можно считать и приложение на 1000 строк.
UFO just landed and posted this here
пример для index.bas
INPUT "WEB", URL
IF URL = "/help/"
    INCLUDE "/help/index.bas"
ELSEIF URL = "/download/"
    OUTPUT "Location: /download/wbasic-1.1.zip", 302
ELSEIF URL = "/page/"
    INCLUDE "/page/index.bas"
END

Роутинг? Обработчики? Модули? Нет, зачем нам эти глупости, мы будем сразу целевую страницу инклюдить внутри IF по адресу.

Но это же… пример… примитивный, на новом языке.
UFO just landed and posted this here
да, посмотрел по википедии это был PHP
— А почему лицензия ISC?
— Это всё-таки не компилятор, а транслятор подмножества BASIC в PHP. Ещё точнее — шаблонизатор.
— Парсер, токенайзер, регулярные выражения и вот это всё-всё-всё в одной godlike функции — это осознанное решение или просто так получилось?

Честно, я не вижу где это можно применить, кроме уроков информатики вместо знаменитого «исполнитель черепашка»
Немного по технической составляющей. Т.к. с точки зрения предметной логики я не представляю кому и зачем это понадобится =)

То, что у вас получилось — это не компилятор, а процедурный препроцессор. Компилятором можно назвать две вещи:
1) Комплексную систему, которая в конечном варианте возвращает набор команд для процессора. В современном мире компилятор обычно делится на фронтэнд (лексер, парсер, генератор ir) и бекенд (оптимизация ir, генерация конечного кода).
2) Код, который переводит набор грамматических правил в код парсера (но это называется «компилятор компиляторов», а не просто компилятор).
3+) Может ещё какой вариант, который я не учёл. Но в сейчас это не тот случай точно.

По коду:
Он плохой. Писать так в 2018ом году — печально. Если пожелаете, то могу раскрыть эту тему в комментариях подробнее. Сейчас останавливаться на этом не хочется, т.к. ошибок очень много.

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


1) xdebug
2) phpdbg
3) в качестве киллертулзы: vld

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


Это не гибкость «компилятора» всё же, а просто реализация грамматики.

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

Что предлагаю:
1) Вам стоит посмотреть хотя бы в сторону EBNF грамматики. Я, конечно, не супер-пупер программист, но могу в качестве варианта предложить вам воспользоваться моей реализацией (вообще это форк, но если посмотреть на код, то он таким уже давно не является) нисходящей LL(k) грамматики и компилятором оной: github.com/railt/compiler Ну или оригиналом: github.com/hoaproject/Compiler
2) Посмотреть в сторону PSR стандартов (ну и в целом: getjump.github.io/ru-php-the-right-way) и переписать код, учитывая оные (обратите внимание, что в PSR-1 есть пункт с «побочными эффектами», он довольно важен, т.к. ваш проект сильно страдает этой проблемой, что мешает использовать его даже «фор-фан»).
наконец то ответ в стиле ваш код говно, потому что не по стандарту оформлен, см. google.com
Не только в стандартах дело, ещё в качестве. Расскажите как им воспользоваться в консоли?
я еще и классы не использовал, и все в один файл поместил.

Я программировал тогда по фану, и т.к. разработка языка программирования напоминает вязание и нужно было связать вместе целую кучу разных парсеров, поэтому делал так как мне удобно. Была вероятность вначале что у меня ничего не получится, пока не заработал прототип.

Под консоль он пока не запускается, нужна доработка кода приема параметров.
Классы — это не панацея. Можно и в функциональном или процедурном стиле написать хорошо. Более того, заметьте, я не акцентировал на этом внимания, т.к. и без меня найдутся люди, которые подробнее расскажут о том, какие проблемы он содержит.

Но некоторую мысль вы уловили, отсутствие некоторых возможностей, повышенная сложность и ошибки
Вроде таких (т.е. по факту код не работает)


Всё это из-за того, что положили болт на качество и писали в стиле 90х годов.
Никогда бы не подумал что эти переменки могут отсутствовать. Учту в новой версии.
А я просто так говорил о том, что не хотел бы расписывать о проблемах в коде? =) Обратите внимание на правую колонку
на скриншоте (кликабельном)



Каждая жёлтая и красная строчка — это потенциальная или 100%-ая ошибка. Каждая бледно-жёлтая — это неоптимальный или потенциально ошибочный код (ну и грамматические ошибки или ошибки кодстайла). А если прогнать этот код через профилировщик, то вообще можно вешаться можно, подозреваю.
я не перфекционист. считаю что в любом коде есть ошибки. если их там нет, то тогда значит пользователям неприятно работать. все в мире сбалансировано и правит всем закон равновесия.

на самом деле все не так уж и плохо работает, как вам кажется. можете вставлять любой код из примеров документации он рабочий.

самая большая проблема у меня не написание кода, а отсутствие поддержки сообществом. пока я не знаю как решить эту проблему.
Наличие ошибок и удобство — это не антонимы. Для ликвидации ошибок пишут тесты и пользуются профилировщиками (и статическим анализом), а для удобства использования проектируют интерфейс взаимодействия (имею ввиду интерфейс с точки зрения инкапсуляции, а не с точки зрения структуры языка).

P.S. Сейчас с вашей стороны это лишь звучит как оправдание. При этом оно довольно слабое, т.к. пользоваться проектом тоже неудобно. Точнее не так. Ей удобно пользоваться только в том варианте, который вы предложили (index.bas и вперёд), а любой другой вариант не предусмотрен и более того — вреден, т.к. может поломать уже существующие решения (см. «побочные эффекты», о чём я упоминал выше).
Тесты были написаны, ошибок не было. У вас только три варнинга было?
Я думал больше будет.
Спасибо за ваши комментарии по коду, но не уверен что смогу его кардинально переписать, у меня будет ломка психики.
Ну я тут потратил час времени, набросал простенький пример с урезанным синтаксисом: github.com/SerafimArts/WBasic/blob/master/example.bas

Вот этот коммит, например, добавляет поддержку оператора PRINT и условных выражений (IF/IF ELSE): github.com/SerafimArts/WBasic/commit/9f2163b84eb3325b5e48f54808bf9001485be6b9 (т.е. расширять всё элементарно)

Возможно это вам поможет.
P.S. На что я хотел обратить внимание этим примером:
1) Всё что надо сделать, чтобы запустить — это написать пару строк: github.com/SerafimArts/WBasic/blob/master/example.php Т.е. для того, чтобы реализовать вашу логику с index.bas достаточно добавить 3 строчки кода с is_file + eval. Причём стоит заметить, что я никаких серьёзных ошибок в коде не допускал. Т.е. можно писать и удобно и вполне примелемого качества.
2) Для того, чтобы реализовать всё это с нуля потребовался час времени (10:26 ваш комментарий и 11:32 мой).
3) Заметьте, что я писал код с полным соответствием PSR-12 и докблоками. Это не тяжело, но зато потом относительно легко читать.
4) Анализ ошибок. Это одна из самых важных вещей в парсинге. В вашем варианте конструкция:
IF A = 23 THEN
    PRINT "YES"
ELSE
    REM ничего не делаем =)


Вернёт:
Parse error: syntax error, unexpected ')' in ...\index.php(85): eval()'d code on line 1

В моём:
Railt\Parser\Exception\UnexpectedTokenException: Unexpected token «ELSE» (T_OP_ELSE) in ...\example.bas on line 4

Подобные подробные ошибки достигаются за счёт анализа грамматики (как и логика самого парсинга). В данном случае IF требует обязательное закрытие своего тела: github.com/SerafimArts/WBasic/blob/master/resources/grammar.pp2#L85-L86 А так, как этого не было сделано, то берётся последняя успешная продукция (т.е. ELSE с необязательным телом) и указывается на то, что с ним что-то не так с ссылкой на линию и файл, в котором обнаружена ошибка.
Очешуеть! Прочитал ваш код. Как хорошо что я у вас не работаю, иначе мне понадобилось бы куча зависимых библиотек, коллектив разработчиков и я бы не уложился в 1 месяц и 1 файл на 1700 строк.

Позвольте не комментировать это заявление, т.к. боюсь, что мои попытки доказать, что час работы — это меньше месяца, а 3 библиотеки для парсера и лексера — это не куча и они необходимы, потерпят неудачу.

Ну, конечно, могу предложить посмотреть на исходники PHP, там для лексера используется re2c, а для парсера bison и отказаться от использования этого языка, т.к. он слишком много зависимостей с собой тащит (там в сумме больше 30+ одно ядро).
UFO just landed and posted this here
не уверен что это помощь. у меня другой подход в разработке и в нем есть преимущества, которые почему то даже не рассматриваются ибо они не по стандарту откомментированы и размечены. с моей точки зрения предложенный стиль программирования через чур громоздкий и некомфортный, он бы меня вымотал на таком проекте.

и я знаю что есть готовые библиотеки лексеров и парсеров, с которыми мне пришлось бы воевать, т.к. я не контролирую их поведение, и как только выйду за их границы мне придется их модифицировать или подстраиваться под них, что меня не устраивает, для чего это? блок компиляции всего 500 строк, и он полностью справляется со всеми конструкциями.
в нем есть преимущества

Это какие же?

для меня — я смог реализовать данный проект от идеи до релиза. у многих это не получается.

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

Это не преимущество вашего подхода, это вы просто иначе не умеете.


у многих это не получается.

А у многих — получается, причем на основе той методики, которую вы отвергаете.


считайте это стилем русской инженерной школы

Нет, не буду. К русской инженерной школе ваше поделие отношения не имеет.


надежно и работает.

Это тоже не про ваш язык.

Извините, «русской инженерной школы»?

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

«Дешёво»?

При просмотре кода становится очевидно, что это что-то не дешёвое. И главная причина — низкое качество самого кода. Например, функция com_compile. Это кошмар на 500+ строк с множеством вложенных ветвлений. Написать такую функцию один раз может быть и «просто и дёшево», в чём я сомневаюсь. Но поддержка подобного кода обойдётся во много раз дороже, чем поддержка любого из предложенных в комментариях «плохого и сложного» решения.

«Надёжно и работает»?

Работает — может быть. Но работает, очевидно, как-то. Явно не надёжно. И причина этого в низком качестве кода, которое было Вам продемонстрировано на примере скриншота, где большая часть кода подсвечена, как содержащая потенциальные ошибки. Профессиональные разработчики стремятся к минимизации количества предупреждений от инструментов анализа, в идеале — к полному отсутствию таких предупреждений.
Чувак, это не русская инженерная школа. Это просто лапша одним гигантским куском. За отсутствие внятной декомпозиции и функции на стопицот экранов меня бы препод линейкой пи*ил. Ну это если за инженерную школу говорить.
я боюсь вам хорошо бы подтянуть теорию по языкам программирования и грамматикам, узнаете много нового, если тема интересна :)
я уже обчитался на самом деле этой литературой до упора. я не теоретик, я практик. мне было это интересно, и поэтому я учил почти все языки программирования включая забытые и заброшенные.

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

Это тот, в котором перемешаны массивы и словари (а про множества я даже спрашивать не буду)?


И чем он лучше, чем работа с коллекциями в Python (не говоря о numpy) или .net? В вашем прекрасном языке можно написать [1, 2, 3] ** 2 и получить [1, 4, 9]? Можно писать итераторы? А как насчет генераторов?

Например посмотрите раздел работы с массивами, он лучше чем сделано во многих языках.

Как в одну строчку получить все элементы (строкового) массива, начинающиеся с qwe и длиной более 5 символов?

UFO just landed and posted this here
и в нем есть преимущества

какие? (UPD: уже ответили выше)

с моей точки зрения предложенный стиль программирования через чур громоздкий и некомфортный


Да ладно? Это вам методы по 3 строчки некомфортны или корутины?

Ещё раз, вот это «легковесный» и «понятный»:
github.com/vindozo/wbasic/blob/master/wbasic.php
А вот это «громоздкий» и «некомфортный»:
github.com/SerafimArts/WBasic/blob/master/src/Builder.php
? Я думаю, что это не так.

и я знаю что есть готовые библиотеки лексеров и парсеров, с которыми мне пришлось бы воевать


Да, прошу заметить, что это самопальная библиотека. Она написана мной для себя же в процессе обучения «написания своих языков», т.е. примерно за год штудирования непосредственной теории и практики. Никто не мешал вам сделать так же. Я просто поделился своим опытом, т.к. через ваш вариант проходил ещё в самом начале «пути».

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


Это только ваш стиль. Пожалуйста, не обобщайте и не приобщайте сюда сообщество.
после того как вы год потратили на штудирование и написание свой библиотеки, в какие языки ее использовали для разработки? У вас остались еще силы на что то?
после того как вы год потратили на штудирование и написание свой библиотеки, в какие языки ее использовали для разработки?


Для GraphQL SDL (диалекта): github.com/railt/railt. Проекту уже полтора года и до сих пор в мастере. Начинал именно для этого языка. Одна из относительно стабильных версий, например, используется в продакшене на некоторых проектах группы компаний Rambler, что, для себя я считаю небольшим достижением для «пет-проекта».

И да, силы ещё остались, хотя до сих пор не могу нормально стабилизировать виртуальную машину. Раз 10 или 15 переписывал.
Это круто! Тем более, всего за час.
> то тогда значит пользователям неприятно работать

А если есть — пользователи не могут работать.

> все в мире сбалансировано и правит всем закон равновесия.

Какими-то высокодуховными девами из фконтакта повеяло. Специально делать такой панк-код (по аналогии с грязным звуком) — это для какой-то особенной тусовки, здесь таким не увлекаются.

> отсутствие поддержки сообществом

Так её и не будет, поддерживать мусорный код никто не захочет — его можно только костылить, но костыли потонут внутри.
Вам выдали целую экранную страницу обоснованной критики, подробно расписанной по пунктам. И даже сказали куда смотреть (не в гугл, а конкретно ссылки). Но чукча не читатель, чукча программист.
выдайте больше, я за!
если в целом реакция на проект будет положительна, то почему бы не исправить их в версии 1.2, ну а если нет, то нет смысла продолжать.
Смотрите, реакция может быть положительная на:
а) идею проекта
б) его реализацию

Вы надеетесь, что идея настолько хороша, что потом можно будет задним числом исправить реализацию. Но это не совсем так, поэтому разумным шагом была бы разработка документации, вычитка и чистка кода, приведение к единому стилю и выпуск версии 1.2 уже не для себя, а для гипотетического сообщества. Вам надо вывести его с уровня «домашний эксперимент» на «интересный проект, может кому-то пригодится».

Мало того, что там куча ошибок, мало того, что код совершенно неподдерживаемый (потому и сообщества нет — сюрприз!), так вы еще и настолько яркая и творческая личность, что стандарты — это не для вас, конечно.
Вперед и с песней! Воспринимайте критику в штыки, занимайтесь производством говнокода, а то мало в PHP кидаются тухлыми помидорами, надо бы еще добавить! Но только не удивляйтесь отсутствию сообщества. С такими подходами работать с вами на добровольных началах никто не захочет.

UFO just landed and posted this here

А как отличить "полезную" концепцию от "вредной" изучая только "полезные"?

UFO just landed and posted this here
Вот смотрите. При вас кто-то обжег руку, схватившись, к примеру, за паяльник. Обязательно ли вам повторять этот неудачный опыт ;)?

В ужасе выброшу паяльники и начну паять исключительно феном :)))
Если уж паять начал то обожжешся рано или поздно. С опытом только вероятность/площадь ожога меньше становится.


Basic был вторым языком, который я учил (в школе еще, после факультативно изученного С). И вы знаете, лучше б я за паяльник схватился… :)

О да, у меня изучение паскаля после асма вызывало аналогичные эмоции. Однако никто ж не заставляет кодить на "неудачных" концепциях, а вот знать их (хотя бы поверхностно) весьма полезно. А как говорится лучший способ изучить ЯП — начать кодить на нем.

Я тоже не считаю Бейсик пределом эволюции. Но надо отдать ему дань. Очень чистый синтаксис кода, мало скобочек, параметры обозначены ключевыми словами а не через запятую.

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

На самом деле я пытался сформулировать язык следующего поколения под русский менталитет, но если я не смогу решить проблему (а нахрена?) на текущем проекте то последующих проектов видимо не будет в этом направлении. И с этим столкнутся все последующие русские разработчики языков программирования.
UFO just landed and posted this here
у меня была идея разработать язык с нуля, но я был не уверен что смогу сделать удачный синтаксис и одновременно реализовать проект сразу в один ход, и предпочел эволюционный подход. к сожалению лучше бейсика ничего не нашел подходящего.
Да Brainf*ck имеет более чистый синтаксис, простите. Эти запятые бесконечные в вызовах, к примеру отрисовки окружности… Как вспомню, так вздрогну.

Пытаюсь вспомнить… что же здесь ужасного? Вспомним, что в приницпе, никто не заставляет использовать встроенные графические библиотеки — верно? Пожалуйста, используйте сторонние, вызывайте их конвенционально через call DrawCircle(.......).

А в простом виде, если не рисовать дуги и пр. ничего там ужасного нет:
CIRCLE (320, 100), 200


UFO just landed and posted this here
Язык для русского менталитета

image

Считаю что изучение разработки Web приложений нужно сразу начинать с применением инструментов, которые на самом деле используются в реальных проектах. Иначе это будет потеря времени, в том числе на переучивание.
т.е. делать языки со ставкой на «это просто для начинающих» нет смысла, это отнимает время у начинающих разработчиков?
Хуже чем просто отнимает время. Это учит их неправильным инструментам, с которыми они потом не найдут работу и не сделают ничего путного. Это будет закладывать у них неправильные представления о том, как делаются коммерческие Web-приложения.
Я думаю что изучение любых приложений нужно всё же начинать с алгоритмов и декомпозиции. А инструментарий изучать после изучения языка.

Одно время была эпоха Rails, когда разработчики писали на нём не зная вообще о языке ничего. Сейчас такая же эпоха с Laravel, где каждый второй не знает даже основ PHP (достаточно открыть тостер и убедиться самому). Эти ребята как раз и начинали с инструментов и добром это не всегда оканчивалось, увы.
Разумеется, прежде всего должно быть высшее образование по профильной области. С чего начинать — это отдельный разговор. Я, например, начинал с программирования для Intel 8080 в машинных кодах, потом ассемблер и да, Basic. Потом пошел Фортран, PL1, Pascal, C, C++, JavaScript, Perl, PHP, Python, Go, может что пропустил. И все это для конкретных проектов, т.к. язык — не более чем инструмент реализации.

Выбор языка (и других инструментов, сервисов и систем) зависит от проекта. И как сделать этот выбор — тоже отдельный разговор.
Разумеется, прежде всего должно быть высшее образование по профильной области.

А вот это отдельный разговор, и я бы даже сказал холивар. Я придерживаюсь позиции «желания учиться», вместо «наличия корочки». И судя по опыту собеседований, вполне себе резонно придерживаюсь.
Ниже написал, что у нас опыт найма сотрудников показывает, что те, кто сумел получить диплом, показывают намного лучшие результаты. Чтобы получить диплом, недостаточно только желания учиться, нужно умение добиваться результата. А это необходимо в любой области.
Смущает уточнение «по профильной области». Уж слишком оно попахивает этаким абстракционизьмом.

Расскажу историю из жизни.

В одной большой-пребольшой, международной-премеждународной компании компании была команда русских разработчиков. Одна из многих, ясен пень. И были в той команде все с высшим образованием, да только не все — с профильным.

А когда проект подошел к концу и стали подбивать бабки, выяснилось, что top performers, которые, собственно, и вытянули весь проект на себе — это почти исключительно люди именно с непрофильным высшим. Плюс единственная в команде девушка (она, как ни странно, с профильным). Остальные в течение нескольких лет радостно били баклуши и писали отчеты, делая только необходимый минимум.

Здесь самое время для возгласа «значит, менеджмент был херовый!». Заранее согласен. Ибо компания, как я уже писал, большая и международная.

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

Знаете, иногда из непрофильных вузов приходят такие на собеседования, которые и азов то не знают. Вот спросишь у них про нормализацию базы данных — молчат. Ставить индекс на поле пол (м/ж) — говорят да, если по этому полю идет поиск. Про составной индекс, конечно, не знают. Ну и так далее.

Ведь далеко не все способны на самообразование, и еще программа нужна, чтобы самое важное не пропустить. Как там у Козьмы Пруткова: " Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." А в профильном вузе все-таки изучают самые необходимые предметы. Другое дело, что не все ВУЗ-ы одинаково полезны, и не все студенты одинаково прилежны.
Знаете, иногда из непрофильных вузов приходят такие на собеседования, которые и азов то не знают.

А иногда и из профильных вузов такие приходят.

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


Но не случается с теми, кто вместо того, чтобы тратить 5 лет непонятно на что получал опыт и дорос до миддла/сеньора (за 5 лет это более чем возможно).

Так что это скорее аргумент в пользу тех, кто 5 лет работал, а не тех, кто закончил ВУЗ имея крайне посредственные знания в актуальных технологиях (а скорее всего их просто не имея).
Хороший ВУЗ дает не только знания, но и кругозор, эрудицию, начальный опыт работы на кафедре, а главное — умение обучаться. Как раз работа на профильной кафедре позволяет быстрее получить нужные знания под руководством опытных сотрудников.

Если же вы обучаетесь на работе, то получаете узкое образование в рамках той работы, которую выполняете.
Разумеется, прежде всего должно быть высшее образование по профильной области.

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

Не знаю насчет крупных, но у себя мы наблюдали, что кандидаты, который закончили ВУЗ, показывали гораздо более высокие результаты. А те, кто не сумел его закончить, не смогли у нас работать.

Я рассматриваю ВУЗ как некий фильтр. Если кандидат его прошел, это говорит о его способности доводить дело до конца, и вообще о его способностях. А если не сумел — это настораживающий признак.
у себя мы наблюдали, что кандидаты, который закончили ВУЗ, показывали гораздо более высокие результаты

Любой ВУЗ или профильный ВУЗ?


(про методику измерения даже спрашивать не буду)


А те, кто не сумел его закончить, не смогли у нас работать.

Вы не делаете разделения между "не смог закончить ВУЗ", "не захотел заканчивать ВУЗ" и "не стал поступать в ВУЗ"?


Если кандидат его прошел, это говорит о его способности доводить дело до конца, и вообще о его способностях

Угу, иногда — способности доводить до конца ненужное дело (иными словами, подверженность sunken costs fallacy).

Вы сами понимаете, что в профильном ВУЗе можно получить более полное образование по теме. Если самообразование, то возможно возникновение зияющих дыр в знаниях.

Различий не делаю, для меня ВУЗ — фильтр. Прошел — хорошо, не прошел — настораживает.

Что же касается доведения до конца ненужного дела, то это на совести руководства, которое выдает задание и контролирует, как оно выполняется.
Если же сам себе дело придумал — то сам и в ответе.
Вы сами понимаете, что в профильном ВУЗе можно получить более полное образование по теме.

Ключевое слово здесь "можно". А можно и не получить. А можно самостоятельно получить "более полное образование по теме". Когда к вам приходит разработчик с десятилетним опытом, возможно, его опыт актуальнее любого ВУЗа.


Так вернемся к вашему "у себя мы наблюдали" — есть статистически значимая разница между людьми с профильным высшим образованием и людьми с любым другим высшим образованием?


Что же касается доведения до конца ненужного дела, то это на совести руководства, которое выдает задание и контролирует, как оно выполняется.

Именно так. И если руководство "выдало" некорректное задание, то все равно будем копать до конца.

У нас есть опыт успешного найма сотрудников с не совсем профильным образованием. Были проблемы со студентами ВМК МГУ. Но нет успеха в попытках работать с людьми без диплома, так уж получилось.
У нас есть опыт успешного найма сотрудников с не совсем профильным образованием.

Значит, утверждение "прежде всего должно быть высшее образование по профильной области" — неверно.


Но нет успеха в попытках работать с людьми без диплома, так уж получилось.

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

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

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

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

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


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

Ха. Это неудивительно, если начинать с позиции "для меня ВУЗ — фильтр. Прошел — хорошо, не прошел — настораживает.". Как эксперимент, это не выдерживает никакой критики, вы же понимаете?


В любом случае я считаю, что кандидату, получившему диплом, особенно профильный, доверия больше.

Ну да, вот и еще одно подтверждение вашего предвзятого отношения.

Я считаю что должно быть так, хотя из всего есть исключения. У нас не эксперимент, реальная работа более 10 лет. Отношение к людям без диплома в плане приема на работу у меня предвзятое, опять же на основании моего опыта.
Я считаю что должно быть так, хотя из всего есть исключения.

Что ж, это хороший повод не идти к вам в компанию.


У нас не эксперимент, реальная работа более 10 лет.

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


Отношение к людям без диплома в плане приема на работу у меня предвзятое, опять же на основании моего опыта.

Самоподдерживающаяся система.

Я бы сказал так, что наш опыт найма сотрудников подходит не всем компаниям. Кто-то может позволить себе обучать новичков базовым знаниям (мы так пробовали в самом начале), а кому-то нужен сразу результат. Сейчас, например, мы вообще перестали нанимать новичков, работаем только с опытными сотрудниками.

… и незаметно приравниваете "опытных сотрудников" к "сотрудникам с дипломом", игнорируя опытных людей без диплома.

Но нет успеха в попытках работать с людьми без диплома, так уж получилось.

У вас — нет. У Гугля — есть: " “proportion of people without any college education at Google has increased over time” — now as high as 14 percent on some teams".

Очень хорошо, я говорю только про то, что знаю сам.
… стиль разработки такой же как на PHP – правите файлы на сервере, открываете страничку, смотрите результат…

Простите, но нет. Это не стиль разработки на php (или любом другом языке программирования).
Кроме того, при разработке бизнес-приложений нужно использовать такие языки и средства, которые проверены временем, имеют обширные сообщества, большие библиотеки классов и модулей, для которых написано много книг и документации. Новый язык как надстройка над PHP, на мой взгляд, очень спорный выбор по многим причинам.
т.е. это замкнутый круг — новых языков программирования в россии появиться не может, т.к. сообщество небольшое и вряд ли наберется, будем на веки вечные пользоваться языками разработанными на западе, с чисто английским синтаксисом?

Может стоит пойти по пути наибольшего сопротивления и посмотреть на результат?

Английский универсален все таки.
Вот представьте как будет выглядеть тот же бейсик например на китайском :))

> Вот представьте как будет выглядеть тот же бейсик например на китайском :))

А вот примерно так и будет выглядеть:
en.wikipedia.org/wiki/Chinese_BASIC
Конечно можно, но на мой взгляд, тут нужно делать акцент не на язык синтаксиса (русский или английский), а на полезность языка по сравнению с теми, что уже есть.

Реально для создания Web-приложений не нужны языки с кириллицей (опять же по моему мнению). Этот процесс включает в себя много различных технологий, а не только языки программирования (базы данных, Web-серверы, клиентские скрипты и т.п.). Считаю что у тех программистов, которые не владеют английским свободно, нет шансов сделать что-нибудь стоящее в этой области.

Российские разработчики не должны вариться в собственном соку на кириллице, а должны создавать продукты мирового качества и распространять их по всему миру. Пример — почтовый сервер CommunigatePro, созданный Владимиром Бутенко, который, к великому сожалению, недавно скончался: www.cnews.ru/news/top/2018-08-30_umer_osnovatel_communigate_vladimir_butenko.

Можно сказать, я учился в студенческие годы на исходных текстах ядра ОС MISS, созданной Бутенко. И его почтовый сервер — сильная разработка действительно отечественного программиста.
ну я считаю что сам английский язык в корне влияет на синтаксис высокоуровневого языка программирования. вернитесь мысленно в 1964 год когда разрабатывался Бейсик.

На самом деле я считаю что мы много потеряли, сделав ставку на англоязычные языки программирования и не развивая собственные.

возможно, наши бы программы смогли перейти на новый уровень если бы избавились от костлявой грамматики английского. С бейсика тянутся все эти жесткие конструкции типа IF… THEN… ELSE…
А как бы выглядела русская концепция экспертной системы?
наши бы программы смогли перейти на новый уровень если бы избавились от костлявой грамматики английского

А конкретный пример?


А как бы выглядела русская концепция экспертной системы?

А точно так же. Если что, if-then-else — это если-то-иначе, совершенно естественная для русского языка конструкция.

Как на счет команды ВОЗМОЖНО? ПРИБЛИЗИТЕЛЬНО?
ну или ДА НЕТ НАВЕРНОЕ?
к тому же IF мне напоминает больше недоразвитый цикл на одну или ноль итераций. и на нем основана вся логика программ? как то примитивненько.

Так же, как и в английском — probably, approximately и don't mind if I do.

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

Если вы про что-то не слышали, еще рано думать, что этого не существует: nondeterministic programming, probabilistic programming languages.


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

А напомните мне еще раз, что конкретно в английском языке мешает представить другие конструкции проверки условий?

Что должны делать эти конструкции? Рандомные баги добавлять?
И какая механика под этим «наверное»? На английском так тоже можно писать, только в этом просто нет смысла. Язык-бредогенератор имеет ещё меньше применения, чем brainfuck.

У вас тут фундаментальная ошибка в определении причины и следствия. Это не IF является недоразвитым циклом, а цикл — это синтаксический сахар над IF GOTO

к тому же IF мне напоминает больше недоразвитый цикл на одну или ноль итераций. и на нем основана вся логика программ?

Мало ли что кому напоминает. "Если-то" — это одна из базовых моделей мышления.


Ну и да, это снова не зависит от языка, что в русском, что в английском это будет выражено более-менее одинаково.

Здесь надо сделать ремарку, что ваши утверждения (оба) не самоочевидны, а сильно опираются на теорию Хомского.

Возможно, я с этой теорией не знаком.

Считаю что языки на кириллице не имеют перспектив (особенно в мировом масштабе), поэтому все попытки внедрить кириллицу в программирование сейчас вредны.

Еще раз, разработка программ и приложений не сводится к языкам, процесс сложный и включает в себя множество уже разработанных систем и компонент. Реальность такова, что без знания английского языка сейчас сделать ничего невозможно. А главное — незачем.

В мировом масштабе не имеют, в российском у 1с 90% рынка учетных программ не в последнюю очередь благодаря русскому синтаксису языка, уменьшающему порог входа и вообще облегчающему восприятие кода.

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

В области разработки программ, считаю, вообще не имеет смысл говорить о российских масштабах. Эти разработки уже давно стали международными. Вот, например, поисковый сервер Sphinx, созданный русским разработчиком Андреем Аксеновым. Или всемирно известный прокси nginx — разработчик Игорь Сысоев.

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


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

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


Есть огромное количество разработок, которые не просто не являются международными, но и вообще не выходят за пределы компании, для которой разрабатываются и составляют ее коммерческую тайну. На мой взгляд все утверждения о том, что писать программы нужно только на анлийском — это въевшийся стереотип. Как уже писал выше — глобализация подняла бы общий уровень разработки, потому что по своему опыту могу сказать, как человек, свободно разговаривающий на английском и поработавший как с 1С, так и с англоязычными средствами разработки — код на русском мозгом воспринимается значительно проще, хотя конечно по началу будет непривычно.
На мой взгляд все утверждения о том, что писать программы нужно только на анлийском — это въевшийся стереотип.

Программы нужно писать не "на английском", а на понятном языке программирования. Вот с комментариями сложнее.


Но тут ведь вопрос простой: вы готовы к тому, что весь ваш код будет ограничен в рамках только русскоязычной аудитории? Что вы сам не можете использовать не-русскоязычные наработки?

Здесь несколько моментов:
а) Я писал выше, что огромное количество программ не являются продуктами для массовой продажи вообще, не говоря уж о международном рынке, например разработка сайта или корпоративной системы для конкретной компании, которая останется только в компании и вообще может составлять коммерческую тайну. Это редкий случай? Нет
б) Я смогу использовать нерусскоязычные наработки. Это же просто код. Вы можете написать if, вы можете написать если, компилятор будет воспринимать и то и то. Также функции, вы можете оставить их на английском и вызывать в своем коде (например 1С так делает со сторонними библиотеками и проблемы нет), а можете перевести на русский, и здесь возникает следующий пункт…
в) Не вижу большой сложности создать инструмент, который будет переводить наработки с одного языка на другой. С ключевыми словами вообще проблем нет, а какой-то словарь ru-en для названий функций и переменных создать не вижу проблемы, например автоматический перевод с возможностью редактирования.
Я писал выше, что огромное количество программ не являются продуктами для массовой продажи вообще, не говоря уж о международном рынке

А при чем тут продажа? Я говорю об OSS и просто последующем использовании.


разработка сайта или корпоративной системы для конкретной компании, которая останется только в компании и вообще может составлять коммерческую тайну. Это редкий случай? Нет

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


Также функции, вы можете оставить их на английском и вызывать в своем коде

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


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

А вы просто попробуйте.


С ключевыми словами вообще проблем нет

Правда? Переведите ключевое слово let или var.


какой-то словарь ru-en для названий функций и переменных создать не вижу проблемы

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

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


И в чем же могут быть проблемы? Какие-то сложности выцепить из кода ключевые слова и названия идентификаторов и перевести их в соответствии со словарем? Это задача для тестового задания на позицию джуниора =)

Правда? Переведите ключевое слово let или var.


перем — точный перевод для var

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


Вы просто посчитайте, сколько новых, ранее не использованных в проекте слов, вы используете для именования переменных в задании, разработка которого занимает один день, вычтите из них те, которые какой-нибудь автоматический переводчик сможет перевести корректно, и то что останется — это даже не работа программиста, это работа аутсорсового копеечного переводчика. Локализация пользовательской части сайтов отнимает намного больше времени.
Какие-то сложности выцепить из кода ключевые слова и названия идентификаторов и перевести их в соответствии со словарем?

Потому что именование — одна из самых сложных задач в программировании. Словаря недостаточно, нужен контекст.


В качестве упражнения можете попробовать корректно перевести API.ContractBased.SystemContract.


перем — точный перевод для var

Точный, но неудачный. Я не готов читать "перем симвСчт".


Вы просто посчитайте, сколько новых, ранее не использованных в проекте слов, вы используете для именования переменных в задании

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


работа аутсорсового копеечного переводчика

В том-то и дело, что нельзя отдавать перевод аутсорсинговому переводчику (про копеечных я и вовсе молчу, им ничего нельзя отдавать), потому что он не знает, что было в моей голове, когда я придумывал именование. Он не в предметной области. Он не профессионал в разработке.

Точный, но неудачный. Я не готов читать «перем симвСчт».


А тысячи американцев и англичан не готовы читать var symbCnt, но они читают. Как и десятки тысяч разработчиков под 1С, которые читают Перем и не видят в этом никаких проблем.

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


Не думаю что это частая проблема, и даже не смог навскидку придумать русские слова в разработке, которые в рамках одного проекта будут иметь необходимость по разному их перевести( с аутсорсом ок, забудем про эту идею). В любом случае вы хозяин, переменных не так много и это не будет критично. В конце концов что, всегда во всех проектах переменные названы корректно? Нет.
А тысячи американцев и англичан не готовы читать var symbCnt, но они читают.

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


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

Слово "запись", например. Или "строка". Продолжать?


В любом случае вы хозяин, переменных не так много и это не будет критично.

Идентификаторов много. Мне лень лезть в метрики проекта, но там тысячи code units.


В конце концов что, всегда во всех проектах переменные названы корректно? Нет.

Поэтому давайте сделаем еще хуже? Спасибо, нет, мне существующих проблем хватает.

Потому что порядок слов в русском и английском разный

Ну как сказать.
Критичен порядок слов только в английском.
В русском — можно и подстроиться.

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

Вы не видите разницы между «порядок слов» и «слов порядок»?


В английском — изменение порядка слов меняет весь смысл на корню.

В русском — порядок слов влияет всего лишь на стилистику/оттенки.

Это ровно до тех пор, пока у вас есть падежи. "Число символов" и "символов число" — все еще более-менее понятно (хотя, конечно, второе уже вызывает вопросы, потому что любое отклонение от нормы вызывает вопросы), но вот "числ симв" и "симв числ" — уже нет.

но это дополнительное когнитивное усилие

но вот «числ симв» и «симв числ» — уже нет.


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

например, приложите правила венгерской нотации к вашему примеру.

в английском кроме порядка слов есть много еще чего, что помогает понимать смысл сказанного, но что зачастую упускают в именовании идентификаторов (артикли, be/do, размещение предлога у фразовых глаголов), и в результате с точки зрения английского языка код превращается в бред…

например, в вашем примере — чем является первое слово? сказуемым? подлежащим? а в названии функции? а в названии переменной? определенные соглашения (скажем что в названиях функции первое слово — сказуемое) и есть те соглашения, что помогают понять смысл.

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

и ничуть не связанная с правилами языка человеческого

У кого как. У вас не связаны? Поздравляю вас.


в английском кроме порядка слов есть много еще чего, что помогает понимать смысл сказанного, но что зачастую упускают в именовании идентификаторов

Люди, которых волнует читабельность кода — и у которых есть возможность этим управлять — не опускают те слова, которые влияют на читабельность.


например, в вашем примере — чем является первое слово? сказуемым? подлежащим? а в названии функции? а в названии переменной?

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


определенные соглашения (скажем что в названиях функции первое слово — сказуемое)

Обычно в названиях функции первое слово — глагол.

Обычно в названиях функции первое слово — глагол.


Вот именно!
Все дело в соглашениях программистов!
А не в правилах человеческого языка.
Язык программистов, который они используют для идентификаторов — это волапюк, составленный из слов какого-то языка — не более того.

Это никак не отменяет того факта, что из каких-то языков этот волапюк составлять проще, чем из других.

Это никак не отменяет того факта, что из каких-то языков этот волапюк составлять проще, чем из других.


По сравнению с чем проще?

С тем, к чему вы уже привыкли?

А у вас была практика с программированием на русском языке, ну хотя бы с полгода плотно каждый рабочий день, чтобы вы к нему привыкли и уже смогли бы оценивать объективно?

У меня — была такая практика.

Меня, помнится, колбасило, когда довелось вникать в 1С: Предприятие. Все пытался англоязычных идентификаторы писать. Более того, 1С: Предприятие позволяет легко в коде переходить на русские или на английские операторы без каких-либо переключений в системе. То есть можно писать сплошной англоязычный программистский волапюк.

Так же поступали все программисты, которых я наблюдал в момент их знакомства с 1С.

Потом подавляющее большинство переходят на русский — так гораздо удобнее. Для конкретной этой ситуации с 1С.

Дело в том, что 1С предполагает глубокое погружение в прежде всего в предметную область. А термин «вычет на ребенка с налога на доходы физических лиц» куда как проще написать на русском.

В 1С мне удобно пользоваться русским.
Для написания сайтов мне удобно пользоваться английским.

С учетом имеющегося опыта с разных сторон — вообще не вижу никаких проблем в том, на каком языке писать идентификаторы.

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

Пока работаешь в одного — это не важно. Вот при работе в коллективе все эти неоднозначности твоего перевода уже плохо.

Так правильнее термины которые используешь ты и твой пользователь/твой заказчик. А то мало ли чего ты там напереведешь.

По сравнению с чем проще?

По сравнению с другими языками.


А у вас была практика с программированием на русском языке, ну хотя бы с полгода плотно каждый рабочий день, чтобы вы к нему привыкли и уже смогли бы оценивать объективно?

У меня была практика попробовать один раз перевести одну программу. Мне хватило.


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

Угу. Когда большая часть твоей предметной области — это платформы, API и тому подобная разработка ядер, приходится пользоваться английским.


А термин «вычет на ребенка с налога на доходы физических лиц» куда как проще написать на русском.

А потом, значит, ты пишешь 'SerializeToJson(документОВычетеНаРебенка)`. Потому что рядом две предметных области.


Вот при работе в коллективе все эти неоднозначности твоего перевода уже плохо.

При работе в коллективе плохо даже иметь разный выбор слов без перевода. См. ubiquitous dictionary.

У меня была практика попробовать один раз перевести одну программу. Мне хватило.


То есть опыта у вас нет.
До свидания, больше ваше мнение не интересует.
UFO just landed and posted this here
Самый лучший комментарий, phailo про практику на 1с, ради которого только и стоило здесь публиковаться. Спасибо!
UFO just landed and posted this here
И в чем же могут быть проблемы? Какие-то сложности выцепить из кода ключевые слова и названия идентификаторов и перевести их в соответствии со словарем? Это задача для тестового задания на позицию джуниора =)


Боюсь ваш джуниор чуть-чуть помрёт над этой задачей. Ну или поседеет до миддла-сеньора.

А вы сможете нормально перевести обычный кейворд «let»?
let let = 23; // Представим, что в этом языке можно использовать кейворды в качестве имён переменных
let a = "${let} \"a\""; // И даже есть интерполяция в стиле PHP

1С для объявления использует ключевое слово перем, это точный перевод для var, подойдет и для let… А имя переменной вы можете перевести как угодно…
1С для объявления использует ключевое слово перем, это точный перевод для var, подойдет и для let…

Вы упустили из внимания тот факт, что var и let надо переводить по-разному.

UFO just landed and posted this here
Если имеется ввиду js, то это связано исключительно со спецификой истории развития языка. Какой смысл в слове let? Просто взяли что-то, знакомое по другим языкам, но отличающееся от var. Это просто локальный var, вы можете его перевести как угодно. Если вы переведете его как локал или лок, в нем будет больше смысла чем в let. Даже если перевод будет странным, вы очень быстро к этому привыкнете. Это все мелочи, которые мне кажется бессмысленно обсуждать. Если вы не хотите писать на русском — тогда вы во всем увидите проблему. Если же такое желание есть — то проблемы с переводом не станет.
Если имеется ввиду js, то это связано исключительно со спецификой истории развития языка.

Ну так у каждого языка будет такая специфика, которую вам тоже придется учитывать. Есть вот милые языки, в которых различается var и val.


Какой смысл в слове let?

"Let x-one be our initial approach". Какой в ней смысл в слове "let"? Тот же и здесь.


Если вы переведете его как локал или лок

… и получить конфликт со словом lock? Спасибо, снова нет.


Даже если перевод будет странным, вы очень быстро к этому привыкнете.

Нет. Я не привыкаю к "странным переводам" — вплоть до того, что я не читаю переводную литературу, если могу читать оригинал.


Если вы не хотите писать на русском — тогда вы во всем увидите проблему.

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

Здесь не о чем спорить. Не у всех есть английские коллеги, которые анализируют ваш код и не у всех программные конструкции на русском противоречат вашему чувству языка. То что русский язык может использоваться в разработке говорит сверхуспешный опыт 1С, все остальное частности, привычки и т.д.

То что русский язык может использоваться в разработке говорит сверхуспешный опыт 1С

Сверхуспешный опыт внутри одной страны. Я сразу сказал: если вас это устраивает, если вам не интересен мировой опыт — окей, так можно.

Сверхуспешный опыт внутри одной страны. Я сразу сказал: если вас это устраивает, если вам не интересен мировой опыт — окей, так можно.


Если вы собираетесь работать/работаете на международном рынке — то использование для идентификаторов стандарта де-факто для общения — английского языка — логично.

А в остальном — у вас подменена понятий.

Или вы утверждаете, что программы успешны только благодаря неким волшебным свойствам языка, на котором пишутся идентификаторы? Что английский это какое-то чудо повышающее производительность труда программиста?

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

Уверяю вас — использование родного языка для них вполне себе нормальная ситуация. Тем более что они используют латиницу, которую поддерживают для использования в идентификаторах все языки программирования
Если вы собираетесь работать/работаете на международном рынке

Я с этого и начал, если что — что русский можно использовать только если никогда не собираешься взаимодействовать с внешним миром.


Что английский это какое-то чудо повышающее производительность труда программиста?

Ну да, потому что использование английского позволяет интегрировать существующие решения вне зависимости от того, кем и где они разработаны.


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

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


Уверяю вас — использование родного языка для них вполне себе нормальная ситуация.

Ага, нормальная. С описанными выше последствиями.


Тем более что они используют латиницу, которую поддерживают для использования в идентификаторах все языки программирования

Вы не в курсе, что ни французский, ни испанский в "общепринятую латиницу" не влезают? И между peña и pena есть фундаментальная разница?

Я с этого и начал, если что — что русский можно использовать только если никогда не собираешься взаимодействовать с внешним миром

А че тут обсуждать-то?

Разумеется, если речь идет о выходе на международный уровень — нужен английский.

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

Вы не в курсе, что ни французский, ни испанский в «общепринятую латиницу» не влезают? И между peña и pena есть фундаментальная разница?

Все в пределах уже обсужденного нами с вами тут в комментариях программистского волапюка.
А че тут обсуждать-то?

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


Это настолько очевидно, что вообще никто это и не оспаривал в комментариях тут.

https://habr.com/post/423713/#comment_19132465


"все утверждения о том, что писать программы нужно только на анлийском — это въевшийся стереотип. Как уже писал выше — глобализация подняла бы общий уровень разработки"


https://habr.com/post/423713/#comment_19132551


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

UFO just landed and posted this here
ERP-системы это не только и не столько бухучет, это комплексное управление предприятием — склады, финансы, производство, бюджетирование, CRM, персонал, торговля… Они безусловно были активны в свое время, но нишу они заняли с выходом 8й версии, которая была на голову выше всех конкурентов по всем параметрам, в том числе и Microsoft Axapta, которая в начале 2000х пришла на российский рынок с намерением потеснить 1С. В итоге поиск по Москве «программист Axapta» выдает 30 вакансий, а «программист 1С» — 850. И напомню, что Axapta это не какая-то левая подделка, это майкрософтовский продукт.
И напомню, что Axapta это не какая-то левая подделка, это майкрософтовский продукт.

Вообще-то, IBM-овский, а затем (и в основном) — Navision. А майкрософтовский — это Dynamics AX, и у него сейчас весьма занятная жизнь. Кстати, если искать с учетом этого ребрендинга, цифры уже другие.

Что нужно забить в поиск hh.ru вместо «программист Axapta», чтобы получить по Москве другие цифры?

Вчера на запрос "программист Dynamics AX" давало порядка 60. Сегодня — 28 (на просто аксапту — 32). Видимо, я не умею пользоваться hh.

UFO just landed and posted this here
Вы даже CRM пишите не переводя

Угу. И ERP вместо ПРП. Удивительно.

Под вопросом «сможете нормально перевести» я имел ввиду «сможете ли вы реализовать сами этот код, который переведёт». Процитировал даже специально.

P.S. Я намекаю на то, что str_replace тут не подойдёт (т.к. заменит сразу все вхождения). И даже обычный лексер не будет работать (т.к. проигнорирует то, что имя переменной переводить нельзя, хоть токены и одинаковые).
Я просто удивился вопросу. Да, я могу написать алгоритм, который отличит ключевые слова и языковые конструкции от идентификаторов. И если бы по каким-то причинам я бы этого не смог, это смог бы сделать кто-то еще, создав один раз этот парсер-переводчик. Не понимаю в чем смысл вопроса…
Не понимаю в чем смысл вопроса…


И что, у вас действительно все джуниоры могут это с «пол пинка», как вы заверяете?
Во-первых я выразился фигурально, во вторых я все же считаю что отличие джуниора от миддла в опыте работы, а не в умении писать алгоритмы. Я думаю что если человек не может написать простейший парсер кода, отделив ключевые слова и языковые конструкции от переменных, то он и сеньором это сделать не сможет. Но к чему этот разговор? Достаточно одного гения на несчастную планету, чтобы написать этот сверхсложный парсер =)

А в чем, простите, выражается опыт работы, если не в "умении писать алгоритмы"?

Ну по-моему dimoff66 всё же прав. Опыт работы != писать алгоритмы.

Давайте «на пальцах»: Написание парсера довольно трудоёмкая задача, если делать всё с нуля. Именно это и реализовал в некотором виде автор сего поста, где мы все вместе развели демагогию в комментариях. Готовы ли вы взять его к себе в команду на должность сеньора? Может миддла? Умение писать алгоритмы автор уже изобразил вполне (и это без сарказма, человек действительно постарался в этом плане).
Ну по-моему dimoff66 всё же прав. Опыт работы != писать алгоритмы.

Опыт работы — больше, чем писать алгоритмы. Но написание алгоритмов тоже приходит с опытом.


Готовы ли вы взять его к себе в команду на должность сеньора? Может миддла?

Нет. Именно потому, что я считаю, что он не умеет писать алгоритмы. Выбор стратегии реализации — тоже часть навыка "писать алгоритмы". Знание, где можно взять регексп, а где надо брать полный парсер — тоже часть этого навыка.

Выбор стратегии реализации — тоже часть навыка «писать алгоритмы».


О, а это по-моему уже проектирование, декомпозиция и архитектура. Что-то из. Всё же «алгоритмы» это императивная часть программирования, а описанные мною термины — декларативная. Выбор стратегии реализации — это есть проектирование декларативной части. Не?

Знание, где можно взять регексп, а где надо брать полный парсер — тоже часть этого навыка.

А это уже знание экосистемы и количество знаний. Умение найти формочку на просторах стековерфлоу тостера — это умение оперировать знаниями и опытом (как минимум гуглежа), а оптимизировать эффективность её рендера через какие-нибудь диффы или обсерверы — это уже алгоритмы.

Ниже DimOFF с языка снял тезис:
Я занимаюсь программированием 25 лет, последние 17 профессионально, но если я захочу изучить C# и пойти работать, то я буду таки джуниором.


У меня ровно такое же мнение и только потому, что я знаю, что знание языка или умение написать сортировку Шелла — это далеко не главное в современной разработке. Есть ещё и знание экосистемы. Без знания какого-нибудь Vue или React дальше джуна/миддла в JS не уехать, например.
Всё же «алгоритмы» это императивная часть программирования [...] Выбор стратегии реализации — это есть проектирование декларативной части. Не?

Это до тех пор, пока вы не начинаете писать алгоритмы на функциональных языках, где их запись внезапно оказывается неимперативной.


А это уже знание экосистемы и количество знаний.

Нет, это знание того, что html нельзя разобрать регэкспом безотносительно того, в какой экосистеме вы находитесь. Знание того, что хэштаблица — это (ожидаемое) O(1), а связанный список — O(n) (на чтение).


У меня ровно такое же мнение и только потому, что я знаю, что знание языка или умение написать сортировку Шелла — это далеко не главное в современной разработке

А у меня вот знакомый недавно из senior C# ушел в senior Java.


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


Без знания какого-нибудь Vue или React дальше джуна/миддла в JS не уехать, например.

… или можно писать сервер-сайд и никогда не слышать этих слов.

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

А откуда взять ту алгоритмическую логику, которую надо реализовывать?

Я не знаю откуда в человеческой голове берется умение составлять алгоритмы для решения поставленной задачи. У меня это умение было всегда, и мне кажется люди, способные заниматься программированием и отличаются от всех прочих этим умением, которое либо есть, либо его нет. К джуниору-миддлу это не имеет никакого отношения.

Ну то есть тот факт, что в Стэнфорде (и не в нем одном) есть курс по написанию алгоритмов, вас ни на какие мысли не наталкивает?

UFO just landed and posted this here

… равно как и терминологию в музыке — на английский.

UFO just landed and posted this here
Разработка Web-приложений выходит далеко за рамки серверного языка программирования. Уже писал, что туда входит множество технологий, и все описания там на английском. Чтобы овладеть современными технологиями, необходимо свободно читать на английском. А чтобы задавать вопросы сообществам, которые смогут вам ответить, то и писать.

Англоязычность языков программирования никак не затрудняет разработку программ, особенно если учесть, что практически все описания технологий и инструментов на английском языке. А переводы отстают по времени, искажены и неполны. Такова реальность.

Если читать только переводные книги трехлетней давности, то будете всегда отставать от передового уровня средств разработки и эксплуатации.

Если вы будете брать на работу Web-программистов, не знающих английского языка, они не смогут сделать ничего путного. Просто посмотрите на весь стек технологий Web-приложений. Он выходит далеко за PHP, Perl или Python.

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

Конечно, можно потратить много сил на создание такого языка, но уверяю вас, настоящие специалисты не будут им пользоваться — просто незачем. В их руках уже есть удобные готовые инструменты необходимой мощности, которые работают и позволяют решать все текущие задачи.
В оборонке, кстати, может взлететь.
Тут прежде всего нужно по-настоящему свое железо, а не собранное из импортных комплектующих. Не только свой процессор, который вроде как есть, но и все остальное свое железо, включая память, микросхемы, резисторы, конденсаторы, разъемы и т.п. Вообще все, чтобы там не оказалось аппаратных закладок.

Что касается софта, то его разработка стоит безумных денег. Поэтому обычно все сводится к сертификации какой-нибудь версии Линукса. Думаю, что реальнее также сертифицировать уже имеющиеся инструменты и средства, а не разрабатывать свои «с нуля». Если речь, конечно, идет про разработку Web-приложений и приложений аналогичной сложности. Сомневаюсь, правда, что это требуется в оборонке.

Раньше на ВДНХ в павильоне Космос стояли бортовые компьютеры, на отечественной аппаратной базе и со своими ассемблерами. Вот на этом уровне можно, а Web-приложения — там все сложно. И снова, для хорошего специалиста в области ИТ английский язык — необходимое, а не опциональное знание.
Если вы будете брать на работу Web-программистов, не знающих английского языка, они не смогут сделать ничего путного.


Это очень большое и ничем не оправданное преувеличение, тут бессмысленно дальше дискутировать. И опять же, вопрос не в создании нового языка. Речь лишь о переводе либо того, что сделал автор, либо любого существующего. В чем проблема компилятора или препроцессора помимо IF THEN и FUNCTION обрабатывать также ЕСЛИ, ТОГДА, ФУНКЦИЯ. Нет никакой проблемы, а имена на кириллице многие продукты Майкрософт к примеру позволяют писать сколько я себя помню… Разве что в С++ нельзя использовать кириллицу.
Вот упал у вас сайт от нагрузки, в логах MySQL какое-то непонятное сообщение на английском языке, а вы только на русском можете. Вот нужно вам задействовать memcached чтобы снизить нагрузку на базу, а там описание на английском. И опять какие-то непонятные сообщения не на русском про размеры блоков. Что делать? Как будете оптимизировать настройки MySQL? Позовете кого-нибудь?

Если вы опытный разработчик и читаете на английском, то сможете разобраться с этими ошибками самостоятельно или с помощью Stack Overflow. И не нужны вам никакие имена на кириллице и операторы, это будет вас только путать. Ничего ровным счетом они не упрощают.

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

По поводу «И не нужны вам никакие имена на кириллице и операторы, это будет вас только путать.» это ваше личное мнение и может не иметь никакого отношения к действительности. В моем случае — точно не имеет. Я писал на русском под 1С, я пишу последние три года на английском вэб-проекты. И русский код легко читается мною без комментариев, в то время как английский приходится сразу комментировать, чтобы легко воспринимать, при том, что я свободно разговариваю и читаю на английском.
Не на курсы, а изучать английский в ВУЗ-е нужно, вместе с ИТ-предметами, вот как я считаю. Конечно, это мой опыт, у вас свой.

Код 1С на мой взгляд выглядит ужасно, но этот продукт вообще не имеет отношения к Web-разработке. Что же касается языков для создания Web-проектов, думаю, не случайно там нет ничего с кириллицей. Было бы востребовано — давно бы сделали.
Код 1С на мой взгляд выглядит ужасно


Абсолютно так же, как для англоговорящих выглядит любой язык программирования.

но этот продукт вообще не имеет отношения к Web-разработке


Во-первых пока не имеет. 1С уже реализовывает вэб-сервисы и создание мобильных приложений. Могут и полноценный вэб-сервер сделать рано или поздно. А во вторых какая разница — вэб или не вэб? Методы написания языковых конструкций от этого не отличаются.

а изучать английский в ВУЗ-е нужно, вместе с ИТ-предметами, вот как я считаю. Конечно, это мой опыт, у вас свой.


Для чтения документаций недостаточно английского, нужен технический английский. Его проще изучить работая с программой, чем на курсах.
А во вторых какая разница — вэб или не вэб?

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


Для чтения документаций недостаточно английского, нужен технический английский.

… который нарабатывается в процессе чтения документации. Вот чтобы писать документацию по-английски, нужно уже прилагать усилия.

Во-первых пока не имеет. 1С уже реализовывает вэб-сервисы и создание мобильных приложений. Могут и полноценный вэб-сервер сделать рано или поздно


1С: Предприятие уже 15 лет как умеет веб-интерфейс (разумеется специализированный).

Еще с версии 7.7 (если кто не в курсе — сейчас актуальная 8.3, ну а 8.0 вышла в 2003 году). Бэкенд тогда был 1С, но фронтенд — на ASP.

Ну а где-то с версии 8.2 (2009 год) — реализация фронтенда уже на встроенных средствах 1С. С версией и годом могу ошибаться.

Ну имеется ввиду не вэб-интерфейс с ограниченным набором элементов, а возможность принимать запросы по http и отдавать полноценный html… Я последние годы с 1С не работаю, если это реализовано, вобщем не удвилен. Вообще думаю, что тот системный подход, который они используют, рано или поздно выведет их на лидирующие позиции в мировой разработке.
Вообще думаю, что тот системный подход, который они используют, рано или поздно выведет их на лидирующие позиции в мировой разработке.

Для этого нужно, чтобы этот "системный подход" был лидирующим среди прочих, а этого что-то не наблюдается.

Насколько я знаю, 1С приходится использовать по необходимости, как стандарт де-факто в подготовке отчетности для налоговой. При этом уже давно имеются CRM и ERP, гораздо более удобные и созданные с использованием нормальных средств проектирования.

Мы, например, открываем интернет-магазины, которым 1С нужен только для формирования документации в налоговую. Все остальное можно делать средствами магазина или подключаемых внешних сервисов. Но обсуждение 1С — тема отдельного разговора.
Насколько я знаю, 1С приходится использовать по необходимости, как стандарт де-факто в подготовке отчетности для налоговой.


Это заявление лишено смысла. У 1С нет монополии на сдачу бухгалтерской отчетности, есть множество других программ для сдачи отчетности. К тому же 1С: Бухгалтерия — лишь одна из конфигураций, на 1С крупные и очень крупные компании ведут производство, управленческий учет, торговлю, поскольку по гибкости и скорости доработки им нет равных. Все, что касается учета, доработать на 1С в разы быстрее, чем на любом из известных мне фреймворков вэб-разработки.

Но обсуждение 1С — тема отдельного разговора.


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

Некоторые исторически используют 1С Предприятие для ведения учета, но только исторически. Сейчас есть уже более удобные и современные сервисы CRM и ERP, сервисы фулфилмента.

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

Потому что не надо сравнивать 1C с фреймворками веб-разработки (а если сравнивать, то в формате "за сколько на 1С можно разработать веб-сервис для xxx, и, поверьте мне, мы один раз делали такую интеграцию лет пять назад, все прокляли). Сравнивайте с ERP-платформами.

Поддерживаю. К нам обращаются по поводу встроенной поддержки учета именно из-за сложности и дороговизны сопровождения 1С.

1С до сих пор не сумела сделать нормальный облачный сервис с API. То, что они называют облаком, это виртуалки Windows, на которых работает обычная 1С. И дальше опять загрузки-выгрузки файлов, либо сложная интеграция.
С ERP-платформами будет не в разы а в десятки раз:
SAP — Доработки в разы дороже за счет высокой стоимости специалистов и в 10 раз больше времени на аналогичные изменения функционала
AXAPTA — Разработка занимает намного больше времени
ПАРУС — Нет открытого кода
ГАЛАКТИКА — Нет открытого кода

Поэтому у 1С 90% рынка
С ERP-платформами будет не в разы а в десятки раз:

Где NetSuite? Где SalesForce? Где Sage? Вы вообще в квадрат Гартнер заглядывали?


Поэтому у 1С 90% рынка

В России.

Я и говорю о России, я не могу знать обо всех мировых системах. Если вы о них знаете — пожалуйста проведите сравнительный анализ с 1С.

При этом вы делаете утверждения типа "Вообще думаю, что тот системный подход, который они [1С] используют, рано или поздно выведет их на лидирующие позиции в мировой разработке."

Да, и при этом я делаю такие утверждения исходя из сравнения с ведущими мировыми системами, представленными на рынке России, и вообще исходя из качества продукта как такового.
Да, и при этом я делаю такие утверждения исходя из сравнения с ведущими мировыми системами, представленными на рынке России,

Вы видели место этих "ведущих мировых систем" в том же магическом квадрате?


исходя из качества продукта как такового.

В каких конкретно цифрах вы меряете "качество продукта", и почему вы считаете, что это "качество" у 1С выше, чем у конкурентов на мировом рынке?

и почему вы считаете, что это «качество» у 1С выше, чем у конкурентов на мировом рынке?


Я не писал этого. Вы приписываете мне то, что я не говорил. Это затрудняет общение. Еще раз: если вы можете сравнить лидирующие западные системы — пожалуйста приведите сравнение с 1С, если нет — то благодарю за беседу.
вы можете сравнить лидирующие западные системы — пожалуйста приведите сравнение с 1С

А вы можете привести такое сравнение?

Нет, про названные вами системы мне ничего неизвестно. Я нигде не утверждал, что 1С лучше всех существующих в мире систем от Гибралтара до Новой Зеландии. Но одной из лучших по моему ощущению будет, потому что качество, системный подход, логичность, масштабируемость, простота и скорость доработки превышает все, мне известное.

И конечно если вы ссылаетесь на квадрат Гартнера было бы исключительно любезно дать на него ссылку для ERP систем.
Но одной из лучших по моему ощущению будет.

Но подтвердить это ощущение вы ничем не можете, потому что вы, собственно, не знакомы с тем множеством, к которому предлагаете отнести 1С. Просто "я так вижу".

Равно как вы не можете этого опровергнуть, поскольку не знакомы как минимум с 1С. Подтвердить или опровергнуть мои ощущения может лишь время.

(вы, я так понимаю, тоже не знакомы с чайником Рассела)


Бремя доказательства лежит на утверждающем.

Еще раз цитирую себя:

«Я нигде не утверждал, что 1С лучше всех существующих в мире систем от Гибралтара до Новой Зеландии.»

Вы утверждали, что "рано или поздно [системный подход] выведет их на лидирующие позиции в мировой разработке".

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

https://habr.com/post/423713/#comment_19132955


Ничего невозможно утверждать про будущее.

Вполне возможно. Это называется "прогноз".


была какая-то система на три головы выше САП, Оракл или Аксапты — она заняла бы их место на российском рынке

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


Это предположение, конечно, неверно, потому что есть ERP-системы, которые просто не заинтересованы в продвижении на российском рынке.


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


В качестве иллюстрации можно инвертировать эту фразу: если бы 1С была на три головы выше САП и Аксапты — как вы, как мне кажется, утверждаете — она бы заняла их место на, скажем, рынке США. Раз этого не произошло, значит...

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


Могу добавить. На последнем месте работы связанном с 1С в одной из страховых компаний для учета использовался оракл. Все то же самое — раздутый штат программистов с сомнительным КПД по причине того, что все что делается на 1С за час, в Оракле требует день.

Если это одна из ведущих ерп систем, то мой «прогноз» обрел еще больше основательности.
раздутый штат программистов с сомнительным КПД по причине того, что все что делается на 1С за час, в Оракле требует день.

..."делается" или "программисты делали"?


Если это одна из ведущих ерп систем

Одна из ведущих ERP-систем — это Oracle ERP Cloud, еще одна — Oracle NetSuite. А с какой вы работали?

...«делается» или «программисты делали»?


Спасибо конечно за предположение, что это именно я гений, который все делал в разы быстрее посредственностей из Оракл, но полагаю что все таки «делается». Но все равно очень тронут вашим предположением, почти до слез.

А с какой вы работали?


Только в предыдущем комментарии вы написали, что оракл и есть нет сьют, а теперь спрашиваете меня нет сьют оракл или что-то еще? Не знаю, вам виднее.

полагаю что все таки «делается».

Снова безосновательно, потому что выборки нет, да?


Не знаю, вам виднее.

Мне никак не виднее, с чем вы работали. Но судя по всему, данных для корректного сравнения 1C на мировом рынке у вас нет.

Вы вольны делать из нашей беседы любые выводы.
UFO just landed and posted this here
С моего заявления, что я полагаю, что 1С рано или поздно сможет занять одну из лидирующих позиций на мировом рынке ERP-систем. После чего опп решил что посвятит следующие 10 лет своей жизни докзательству обратного. Я решил не тратить впустую жизнь оппа и согласился. Ему это правда не понравилось и даже мое согласие он по привычке сминусовал. Это полная история состоявшегося диалога =)
UFO just landed and posted this here
Ну как бы я еще студентом пытался изучать венгерский по листингу программы. Слева был код, справа комментарии на венгерском. Код бы намного понятнее.

Скажу так — если не получилось изучить английский в ВУЗ-е, то лучше идти на курсы)
Если вы прежде чем изучать программирование предлагаете идти на курсы английского языка

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


Программирование как профессиональную дисциплину в непрофильных школах пока не преподают (и, надеюсь, не будут).


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

Чтение кода — это нарабатываемый навык. Я читаю код, содержащий английские идентификаторы, намного легче, чем код, содержащий русские.

Мне помогли изучить технический английский ВУЗ и доп. занятия на курсах при вузе. Конечно, чтение тематической литературы в большом объеме и, собственно, программирование и все что с ним связано.
Здравствуйте!

Не забывайте, что использование «англоязычных» языков программирования, а также использование английского языка для именования переменных и комментариев позволяют в случае необходимости аутсорсить разработку в другие страны, если это экономически оправданно. Никто не любит так называемый «индусский код», аутсорсить в другие страны не патриотично, т.к. не создаёт рабочих мест в «родной» стране компании, но зачастую это экономически выгодно. При этом, насколько я понимаю, может происходить и с продуктами, которые не выходят за пределы использующей их компании.
Даже для закрытых разработок можно нанимать опытных специалистов, которые выберут для реализации то, с чем они уже имели дело. И так разработка будет завершена быстрее, и обойдется дешевле. Думаю, они выберут что-нибудь, что уже зарекомендовало себя на рынке Web-разработок.
Мне кажется, что на самом деле лёгкого ничего нет. Фактически, Вы предлагаете потратить огромное количество времени на разработку никому не нужных инструментов, которые не позволяют получать большую прибыль с меньшим вложением средств, но требуют вложения средств в поддержку этих самых инструментов. При этом проблемы возникнут не только у разработчиков данных инструментов, но и у всех разработчиков прикладных библиотек: если раньше можно было написать документацию один раз и, максимум, перевести тексты описаний на другие языки, то теперь требуется ещё и код переводить. Да, часть кода будет переведена автоматически, но дальше перевода ключевых слов вы этого сделать не можете. Следовательно, требуются специалисты, говорящие на целевом языке, чтобы перевод идентификаторов и наименований функций был осмысленным. И это очень много работы, причём непрерывной и подверженной ошибкам.
UFO just landed and posted this here

Это же форум русских разработчиков? Или о ком вы еще переживаете?

UFO just landed and posted this here
Русский как дополнительный, английский никуда не девается. То есть вы можете писать IF THEN или ЕСЛИ ТОГДА, и это будет интерпретироваться одинаково.
Потеряли возможность получить усечённое комьюнити с меньшим опытом? На самом деле такие попытки были, вы просто о них не знаете по очевидным причинам (не взлетели). Разве что 1С, но там язык занял свою нишу, решает свою задачу, но вместе с тем имеет меньшее распространение, чем те же C-подобные (из-за узости ниши).
На правах сарказма:
Там у 1с есть язык на кириллице. Обратите внимание. Зачем английские ключевые слова?!

Ладно 1С, вон даже такой гигант как Microsoft не гнушается использовать кириллицу в именах функций! Пруф


КУБЧИСЛОЭЛМНОЖ вместо CUBESETCOUNT, как вам таке?!

Одно дело имена, другое — ключевые слова. Так-то и в PHP можно имена на кириллице.

Однажды много лет назад, я не использовал нормальную IDE, и провел несколько «занимательных» часов дебага print_r-ми, когда опечатался в имени функции вместо «c» кириллическое «с». Так и открыл для себя эту возможность языка.
Для того, кто разместил русскую С там же, где расположена латинская C, заготовлен отдельный котел в аду.
UFO just landed and posted this here

Если разработано для России, было бы интересно для всех функций и конструкций иметь русские аналоги, как это организовано в 1С — ЕСЛИ ИНАЧЕ и т.п.

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

Кроме того, возможно отказаться в базовых командах вообще от какого либо языка.
например
SUB A( X, Y)
  IF A>B THEN A=B
END A


заменить на
A(X,Y) -> {
  ? A>B { A=B }
} (A)

Ха.


a(x, y) = x > y ? x : y


Реально существующий язык, и не один. Зачем еще?

Скобочно стрелочный вид не так интересен, фишка же вашего проекта в том что вы хотите бейсик сделать

вторым вариантом было написание его на nodejs для увеличения скорости. но PHP7 все таки довольно быстр оказался.

Все новые языки пишут так или иначе на других языках программирования.
Все новые языки пишут так или иначе на других языках программирования.


С чего вы решили? Языки общего назначения, да. Но декларативные или DSL вполне распространены, начиная с доктриновских аннотаций, заканчивая GraphQL/SDL и Yaml. И вполне себе живут на продакшене.
В целом- плюс. Так или иначе такие попытки имеют место быть!
Берем не отечественый БЕЙСИК, скрещиваем с не отечественным PHP — получаем «Сделано в России» — отечественный язык для веб-разработки.
и так избавимся от засилья иностранных БЕЙСИК и прочих PHP.

Какую задачу кроме самообразования вы решали своим новым языком?

платформа для отладки решения языка нового поколения с другим менталитетом и не англоязычном построением команд с жесткой логикой и порядком следования — команда -> аргументы

Что такое "язык нового поколения"? О каком "другом менталитете" идет речь? Как вы можете говорить о "неанглоязычном построении команд", если у вас все команды на английском?

Импортозамещение и скрепыЪ. Бессмысленное и беспощадное.
работа с графикой была в бейсике изначально. почему бы нет?

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


В вашем языке, как вы говорите — 200 команд. В C# — 79 ключевых слов, в Python — 33, и при этом возможности обоих этих языков несравнимо шире.


Вообще, разделение на команду и подпрограмму — бессмысленно, чего уж.

все гораздо хуже чем вы думаете. вы в курсе что было утрачено? я не только старый бейсик изучал, я смотрел синтаксисы многих языков, в том числе забытых вместе с ссср.

Например, были не только команды и функции, утрачено понятие «Теорема» и доказательство теорем, поиск подходящей теоремы. Вы удивились, что работа с базой часть языка, а как вам например запросы на поиск подходящих теорем?
все гораздо хуже чем вы думаете. вы в курсе что было утрачено?

Расскажите же нам.


Например, были не только команды и функции, утрачено понятие «Теорема» и доказательство теорем, поиск подходящей теоремы.

Утрачено, ага.


Вы удивились, что работа с базой часть языка, а как вам например запросы на поиск подходящих теорем?

… а зачем это в языке программирования для разработки серверных веб-приложений?

UFO just landed and posted this here
не, у меня есть гораздо хуже пример этот на 10 не тянет, там вообще непонятно как работает.
Чем-то этот язык мне неуловимо напоминает язык «Барсик», про который когда-то читал в «Науке и жизни».
Нашёл упоминание.
Пример программы (во второй строке уже есть ошибка ¯\_(ツ)_/¯ ):
SWITCH ON COMPUTER ' Включаем компьютер,
SWITCH OFF SWET V KOMNATE ' включаем свет в комнате
' Программа поиска простых чисел
' по алгоритму DO-DO-DO (давай-давай-давай)
' на языке BArSIC (r - Рачительный)
K=10000: DIM P%(K): P%(1)=2: N=1: I=1
DO ' давай
DO ' давай
N = N + 2
S = INT(SQR(N))
J = 0
DO ' давай
J = J + 1
P = P%(J)
LOOP UNTIL P >= S OR N / P=INT(N/P)
LOOP UNTIL N / P > INT(N / P)
I = I + 1
P%(I) = N
LOOP UNTIL I = K
SWITCH ON PRINTER ' включаем принтер
FOR I = 1 TO K: LPRINT I, P%(I): NEXT
SWITCH OFF PRINTER ' выключаем принтер
SWITCH ON DISK ' включаем дисковод
OPEN "DATA" FOR OUTPUT AS #1 ' открываем файл
FOR I = 1 TO K: PRINT #1, I, P%(I): NEXT
CLOSE ' закрываем файл
SWITCH OFF DISK ' выключаем дисковод
SWITCH OFF SWET V KOMNATE ' гасим свет в комнате
SWITCH OFF COMPUTER ' выключаем компьютер

У вас баг — свет дважды выключили.
У вас баг — свет дважды выключили.
Да, об этом я и написал в заголовке спойлера.
А то, что программа включает компьютер, на котором собирается выполняться, вас не смутило?
(Самое смешное, что язык BARSIC тоже есть.)
Конечно, нет — компьютер сначала включается, а потом выключается, всё логично. Заголовок спойлера упустил.

Судя по статье и комментариям, сегодня должно быть 1-е апреля. Посмотрел на календарь: нет, вторая половина сентября.


Автору: дерзайте! Перепишите ядро Linux (или Windows) на PHP. Они тоже пишутся на языках программирования. А еще лучше на вашем WBasic. Будет у нас отечественный Linux. Чтобы каждый смог разобраться и пропатчить ядро под WBasic.

У меня сложилось впечатление, что автор — либо школьник, либо начинающий программист, который вместо того, чтобы учиться и принимать советы, реагирует агрессией и отрицанием. Как правило, когда мало опыта, хочется сделать большое и амбициозное, но естесс-но выходит как и печаль. И только с опытом понимаешь/представляешь, насколько сложна может быть разработка того или иного продукта(про ЯП и компиляторы я умолчу пожалуй). Мой совет автору: будьте более снисходительны к советам и критике, ваша психика и устоявшиеся правила разработки не предел, есть куда расти. Удачи!
Хотя пока что это смотрится достаточно странно и страшно, но удачи вам. В любом случае лучше делать, чем не делать.
UFO just landed and posted this here
UFO just landed and posted this here
Врач — это тот, кто уже научился. Ну и если доводить пример с аппендицитом до полного абсурда, то когда до ближайшей больнички два дня пути, а ласты уже намазаны клеем, то таки лучше делать, чем не делать, какая бы квалификация не была у «хирурга»
Хотя, пожалуй, я был не прав. Сперва показалось, что это восторженный юноша, у которого все впереди. Для которого слова поддержки помогут не опустить руки и развиваться. Но, после прочтения развернувшийся выше дискуссии… Уж лучше никак, чем так.
UFO just landed and posted this here

Проект вызывает смешанные чувства.
Вызывают уважение энтузиазм и предполагаемая цель (обучение школьников, если я правильно понимаю).
Всё остальное, начиная с технических аспектов реализации — очень плохо.


Риторика "Сделано в России" явно осталась от репортажа в районной многотиражке, где она смотрелась уместно, но выглядит дико при публикации на техническом ресурсе.


Логика при оценке собственного продукта у автора отказывает начисто


есть шанс, что вы можете создать популярный продукт, поскольку продуктовая конкуренция отсутствует

— это что вообще? Как связаны востребованность продукта и самопальность инструмента разработки?

предполагаемая цель (обучение школьников, если я правильно понимаю)

Я не знаю, откуда вы это взяли, автор в ответ на прямой вопрос о задачах такого не говорил.

Я просто ничего другого вообще предположить не могу :)

Я, к сожалению, могу.

О, новорожденная на свет появилась, мама — одноглазая из бара «Последний приют»:-)
Кажется немного забавным что обсуждают цели «проекта», и поддержку «сообществом» куска кода уровня курсача первого курса как максимум.
Примерная реакция сообщества СПО на исходный код нового российского языка WBASIC

Sign up to leave a comment.

Articles

Change theme settings