Зарплата обсуждается с кандидатом индивидуально.
Это довольно распространенная практика.
Это не вопрос (не)уважения.
На hh.ru, например, много (на мой взгляд — большинство) интересных вакансий без указания зп.
И это, на мой взгляд, во многих случаях правильно и оправданно.
"отказаться от корявого велосипеда под названием «язык 1С»."
Пока не вижу причин отказываться от Domain-Specific Language — он позволяет решать задачи выбранного домена на порядки быстрее классических языков программирования.
В пользу чего предлагаете отказываться?
Что взамен?
Добрый день!
Я сейчас не в офисе, с разработчиками проконсультироваться не могу. Но, насколько помню, если отбросить все вами перечисленное — С++ занимает 97%-99%. Несколько визуальных контролов (точно помню про планировщик и форматированный документ) написаны с применением JavaScript.
Java, насколько помню, применяется только в EDT и Сервере Взаимодействия. Возможно еще где-то в утилитах администрирования, но 100% не уверен.
В случае XDTO это, скорее, побочный эффект (причем, насколько помню, недокументированный).
Осознанного решения по введению рег. выражений мы, повторюсь, пока не приняли.
А то я в последнее время приобрёл привычку сжимать исходник
Ну тут дело вкуса.
Что до меня — я готов увеличить размер исходника, но получить лучше читаемый код, мне открывающие фигурные скобки на новой строке глаз радуют :)
У нас нет разделения на серверные бинарники и не серверные. Есть разделение на 32-битные и 64-битные.
Высокая частота и новые инструкции в процессорах не должны коррелировать.
64-битные бинарники собираются с generic x64 инструкциями, включающими в себя, например, sse2 и cmov. AVX не используется, да и мест в платформе таких практически нет, где бы от них был явный выигрыш.
Для преимущественно англоязычных данных UTF-8 имеет смысл, в нашем случае профит будет небольшой.
И потом, переход на UTF-8 может оказаться несравнимо тяжелее, нежели переход на новый стандарт, ситуацию нужно тщательно анализировать, учесть все возможные выигрыши и потери.
задействовать стандартную библиотеку особого труда не составит.
А какую считать стандартной?
Далее, после выбора стандарта, надо документировать, обучать, поддерживать работу на разных ОС и т.д. и т.п.
Т.е. все это — весьма серьезная активность. Плюсы реализации которой, как я уже говорил, неочевидны. А не просто задействовать стандартную библиотеку.
В нашем коде много мест, где происходит явное копирование строк и семантика перемещения там не сработает. Только COW. Но в других случаях, при работе с контейнерами, перемещение здорово помогает.
9:15 — 18:00.
Это довольно распространенная практика.
Это не вопрос (не)уважения.
На hh.ru, например, много (на мой взгляд — большинство) интересных вакансий без указания зп.
И это, на мой взгляд, во многих случаях правильно и оправданно.
Если вы про то, как набирают разработчиков прикладных решений — про это в одной из следующих статей.
"отказаться от корявого велосипеда под названием «язык 1С»."
Пока не вижу причин отказываться от Domain-Specific Language — он позволяет решать задачи выбранного домена на порядки быстрее классических языков программирования.
В пользу чего предлагаете отказываться?
Что взамен?
AppStore довольно долго проверяет приложения, иногда доходит до 2 недель.
Я сейчас не в офисе, с разработчиками проконсультироваться не могу. Но, насколько помню, если отбросить все вами перечисленное — С++ занимает 97%-99%. Несколько визуальных контролов (точно помню про планировщик и форматированный документ) написаны с применением JavaScript.
Java, насколько помню, применяется только в EDT и Сервере Взаимодействия. Возможно еще где-то в утилитах администрирования, но 100% не уверен.
Осознанного решения по введению рег. выражений мы, повторюсь, пока не приняли.
> 600 Мб
Ну тут дело вкуса.
Что до меня — я готов увеличить размер исходника, но получить лучше читаемый код, мне открывающие фигурные скобки на новой строке глаз радуют :)
Высокая частота и новые инструкции в процессорах не должны коррелировать.
64-битные бинарники собираются с generic x64 инструкциями, включающими в себя, например, sse2 и cmov. AVX не используется, да и мест в платформе таких практически нет, где бы от них был явный выигрыш.
И потом, переход на UTF-8 может оказаться несравнимо тяжелее, нежели переход на новый стандарт, ситуацию нужно тщательно анализировать, учесть все возможные выигрыши и потери.
А какую считать стандартной?
Далее, после выбора стандарта, надо документировать, обучать, поддерживать работу на разных ОС и т.д. и т.п.
Т.е. все это — весьма серьезная активность. Плюсы реализации которой, как я уже говорил, неочевидны. А не просто задействовать стандартную библиотеку.
8.4 не готов сейчас публично обсуждать.
Детали реализации разгласить пока не можем, к сожалению.
А с ML работаем, конечно, куда сейчас без него.
Хм, а ссылку можно?
Да.