Язык программирования D и Rust. Пробовали? Что можете сказать?

@Casper-SC · Регистрация: 27.03.2010

Студворк — интернет-сервис помощи студентам

Я совсем немного пробовал работать с D, первое впечатление положительно. А по Rust посмотрел доклад, как увидел этот убогий стиль именования всего и вся в стиле: to_string, do_work, bla_bla_bla, что аж тошно стало. Понятно, что это не критерий оценки языка, так, просто, мысли в слух.

Добавлено через 12 часов 4 минуты
Ясно. Никто не пробовал. Я могу сказать, что D чем-то похож на C#, чем мне и понравился.

@korvin_ · 11.01.2018, 21:34

Сообщение от Psilon

А где не так?

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

Сообщение от Psilon

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

В смысле? Разве using не освобождает ресурс при выходе из области видимости?

@ct0r · 11.01.2018, 23:25

Сообщение от Psilon

конечно. Они везде есть

Не вижу на сайте мозиллы ни одной вакансии на раст.

Сообщение от Psilon

Зайдите на канал

Мне не интересен сейчас ни раст, ни блокчейн.

Сообщение от Psilon

По-моему показательно.

Нет. Даже неизвестно, удаленка это или нет, а если нет, то какие города.

Сообщение от Psilon

просто я не люблю

То есть причины все-таки субъективные, я понял.

Сообщение от Psilon

руками управлять ресурсами

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

silent_1991 · 12.01.2018, 04:26

Сообщение от ct0r

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

Нет, именно ресурсами (память - лишь один из видов ресурсов), поскольку поддерживает идиому RAII и деструкторы. А поскольку ресурсы всё равно инкапсулированы в объектах, вы управляете временем жизни ресурсов через время жизни их объектов-обёрток. И если ваша библиотека для работы с БД не закрывает коннект автоматически, в деструкторе - это плохая библиотека. А если вы пишите реализацию некого ресурса и не освобождаете его в деструкторе - у вас будут неосвобождённые ресурсы везде, а не только в одном месте, где вы забыли close, что ловится значительно легче и является багом на уровне реализации объекта, а не на уровне его использования.

@ct0r · 12.01.2018, 10:28

Сообщение от silent_1991

Нет, именно ресурсами (память - лишь один из видов ресурсов), поскольку поддерживает идиому RAII и деструкторы. А поскольку ресурсы всё равно инкапсулированы в объектах, вы управляете временем жизни ресурсов через время жизни их объектов-обёрток. И если ваша библиотека для работы с БД не закрывает коннект автоматически, в деструкторе - это плохая библиотека.

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

silent_1991 · 12.01.2018, 12:07

Сообщение от ct0r

Ну это как-то забавно. RAII используется в С++ уже очень-очень давно, когда раста еще и в планах не было.

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

Сообщение от ct0r

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

Раст ушёл вперёд плюсов касательно гарантий безопасности памяти. Это ключевой момент. В плане управления памятью плюсы (если, конечно, писать современно, без new/delete, юзая смарт поинтеры), в принципе, сейчас вполне сносны, и тут они с растом похожи. Но за безопасностью памяти в плюсах всё равно нужно следить самостоятельно. В расте за этим следит компилятор благодаря организации модели памяти (что, стоит сказать, в некоторых случаях встаёт боком, потому что очевидно безопасные вещи компилятор может не пропустить, но разработчики языка работают над этим). В целом, как мэнэджить память, так и знать, что компилятор следит за валидностью её использования, в расте проще и приятнее, чем в плюсах.
А о RAII я написал к вопросу о вашем с Psilon разговоре о ручном управлении ресурсами. RAII спасает от этого хоть в плюсах, хоть в расте.

Сообщение от ct0r

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

Не очень понял, к чему это. Раст гарантирует безопасность памяти. RAII гарантирует автоматическое освобождение ресурса (будь то память или что бы то ни было ещё). Эти два пункта независимы. Раст крут в плане своей модели памяти. RAII крут в плане отсутствия ручных close'ов. Раст поддерживает RAII. Вот и всё, что я хотел сказать.

@Curry · 12.01.2018, 12:33

Сообщение от silent_1991

В плане управления памятью плюсы (... смарт поинтеры), в принципе, сейчас вполне сносны, и тут они с растом похожи.

Смарт поинтеры дают издержки времени выполнения (скорее всего бОльшие чем GC), а borrowing в Rust, как я понял, нет.

@ct0r · 12.01.2018, 12:45

silent_1991, все это и мне хорошо известно, но до сих пор я не вижу причин его изучать (потому что их нет на данный момент). Для опытных есть куда более интересные, практичные, да и приносящие деньги вещи, чем изучение в сотый раз тех же C++, Haskell, OCaml, только на новый лад, да еще и с заливанием хелловорлдов на гитхаб. А для новичков разные концепции лучше постигать отдельно: низкий уровень, системные вещи, управление памятью - C, C++; функциональное - Haskell, OCaml; модель акторов, распределенные системы - Erlang, Elixir, Scala; ML, Data Science - Python, R; метапрограммирование - Lisp, Elixir; найти работу - Java, C#, Go; и так далее.

Сообщение от silent_1991

Раст крут в плане своей модели памяти

Как часто перед вами стоят задачи, которые не могут быть решены с использованием GC?

Добавлено через 6 минут

Сообщение от KolodeznyDiver

Смарт поинтеры дают издержки времени выполнения (скорее всего бОльшие чем GC), а borrowing в Rust, как я понял, нет.

Откуда вся эта инфа?

@Curry · 12.01.2018, 12:49

Сообщение от ct0r

Откуда вся эта инфа?

Может быть я в чём то ошибаюсь.
Насчёт того что borrowing не даёт издержек при выполнении, то я так понял читая про Rust N лет назад. Типа, так и задумано.

Psilon · 12.01.2018, 14:24

Сообщение от korvin_

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

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

Сообщение от korvin_

В смысле? Разве using не освобождает ресурс при выходе из области видимости?

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

Сообщение от ct0r

Мне не интересен сейчас ни раст, ни блокчейн.

Сообщение от ct0r

То есть причины все-таки субъективные, я понял.

И этот человек мне про субъективность пишет

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

Сообщение от ct0r

И каким образом раст от этого спасает? Он может закрыть файлы, которые я забыл закрыть?

да

Сообщение от ct0r

Может закрыть коннекты к базам, которые я забыл закрыть?

да

Сообщение от ct0r

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

Нет, тогда бы он не был ничем лучше GC

Добавлено через 1 минуту

Сообщение от silent_1991

Не очень понял, к чему это. Раст гарантирует безопасность памяти. RAII гарантирует автоматическое освобождение ресурса (будь то память или что бы то ни было ещё). Эти два пункта независимы. Раст крут в плане своей модели памяти. RAII крут в плане отсутствия ручных close'ов. Раст поддерживает RAII. Вот и всё, что я хотел сказать.

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

Добавлено через 1 минуту

Сообщение от ct0r

Как часто перед вами стоят задачи, которые не могут быть решены с использованием GC?

Я выше написал. Кроме памяти есть еще ресурсы: сеть, файлы, пайпы... А GC помогает же только с ней.

Добавлено через 10 минут
Ну вот в качестве примера (он на C#, но в джаве полагаю будет так же):

C#
1
2
3
4
5
6
7
8
9
10
11
12
using System;
using System.IO;
 
public class Test
{
    public static void Main()
    {
        var fs = new FileStream("myfile.txt", FileMode.Create);
        fs.Close();
        fs.Write("hello world!")
    }
}

Поймаем эксешпн, что файл был закрыт, и писать в закрытый файл низя. Пишем то же в расте:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
use std::io::Write;
use std::fs::File;
 
fn main() {
    let mut file = File::create("myfile.txt").unwrap();
    drop(file);
    file.write_all("Hello world!".as_bytes()).unwrap();
}
 
fn drop<T>(_: T)
{
    
}

Получаем ошибку:

C++
1
2
3
4
5
6
7
8
9
10
11
error[E0382]: use of moved value: `file`
 --> src/main.rs:7:5
  |
6 |     drop(file);
  |          ---- value moved here
7 |     file.write_all("Hello world!".as_bytes()).unwrap();
  |     ^^^^ value used here after move
  |
  = note: move occurs because `file` has type `std::fs::File`, which does not implement the `Copy` trait
 
error: aborting due to previous error

Если еще точнее, то в расте drop руками вообще не вызвать, поэтому такой класс ошибок вообще исключен.

@korvin_ · 12.01.2018, 19:19

Сообщение от Psilon

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

Чего-чего?

Сообщение от Psilon

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

Извини, но это намеренная стрельба себе в ногу.

Psilon · 12.01.2018, 22:44

korvin_,

Извини, но это намеренная стрельба себе в ногу.

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

@korvin_ · 12.01.2018, 23:33

Сообщение от Psilon

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

Вызвать read/write у файла, который перед этим сам же закрыл, это надо быть не неиделаьным программистом, а редкостным чудаком.

Сообщение от Psilon

Это пример, как это обычно бывает.

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

Сообщение от Psilon

Последний случай например у меня случался, когда я отдавал с веб-сервера стрим с данными. Т.к. стрим не закрывался, клиент висел на TCP соединении и ждал сигнала об окончании передачи, а его всё не было. Конечно, потом разобрались, но ловить такие ошибки в рантайме не хочется.

Что ж using не использовал? Да и таймауты для лузеров, да?

Psilon · 13.01.2018, 00:14

korvin_, это называется пример

Сообщение от korvin_

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

Вот из реального кода:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
public SqlReferral.UserReferral GetUserReferralByUserIdAndCondition(string userId, Expression<Func<SqlReferral.UserReferral, bool>> condition)
{
    using (var context = new ApplicationDbContext())
    {
        return context.UserReferrals
            .Include(e => e.Referral)
            .Include(e => e.Referral.Partner)
            .Where(ur => ur.UserId == userId)
            .Where(condition)
            .OrderBy(ur => ur.CreatedDate)
            .FirstOrDefault();
    }
}

Здесь use after free имеется. Удачи его найти.

@pycture · 13.01.2018, 07:50

Сообщение от Psilon

Вот из реального кода:

это такая же шняга, что и с файлом. никто DbContext в методе не создает. это делается в конструкторе класса.

silent_1991 · 13.01.2018, 09:04

Сообщение от ct0r

но до сих пор я не вижу причин его изучать (потому что их нет на данный момент)

Что для вас является хорошей причиной изучения нового инструмента? Только коммерческий интерес?

Сообщение от ct0r

Как часто перед вами стоят задачи, которые не могут быть решены с использованием GC?

Постоянно. Я работаю в организации, которая занимается производством коммуникационного оборудования.

Сообщение от Psilon

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

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

Сообщение от korvin_

Вызвать read/write у файла, который перед этим сам же закрыл, это надо быть не неиделаьным программистом, а редкостным чудаком.

Сообщение от korvin_

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

Вы, кажется, не учитываете, что между задумкой проекта и его отправкой в релиз есть ещё процесс его разработки. И если один инструмент позволяет даже не задумываться о каком-то из видов ошибок, а во втором "ты мчудак, так никто не делает", то первый, очевидно, предпочтительнее, потому что очень неприятно оказаться таким чудаком после трёх дней поиска ошибки, которая была не в hello world, а в реальном коде, и, как и сказал Psilon, могла быть размазана по куче методов, а то и потоков. Подход "накосячить невозможно" лучше подхода "сам накосячил - сам дурак", не правда ли?

ct0r, судя по вашим высказываниям в пользу GC, вы даже не хотите рассматривать целый пласт задач, где его использовать нельзя. А это практически всё системное программирование (в изначальном понимании, этого термина, до того, как туда добавились браузеры и прочие пользовательские инструменты). Так зачем вы тогда пытаетесь доказать, что раст не нужен и бесполезен, если в вашу область интересов не входят те вещи, для которых он изначально и предназначен? Да, вам он не нужен и для вас он бесполезен, насколько бы крут и удобен он ни был. А вот я бы с удовольствием на работе на него перелез, он бы ускорил процесс разработки и уберёг от большого количества ошибок. Но пока приходится дальше торчать на плюсах, а чаще на сях.

Psilon · 13.01.2018, 12:27

Сообщение от pycture

это такая же шняга, что и с файлом. никто DbContext в методе не создает. это делается в конструкторе класса.

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

Добавлено через 4 минуты

Сообщение от silent_1991

Вы, кажется, не учитываете, что между задумкой проекта и его отправкой в релиз есть ещё процесс его разработки. И если один инструмент позволяет даже не задумываться о каком-то из видов ошибок, а во втором "ты мчудак, так никто не делает", то первый, очевидно, предпочтительнее, потому что очень неприятно оказаться таким чудаком после трёх дней поиска ошибки, которая была не в hello world, а в реальном коде, и, как и сказал Psilon, могла быть размазана по куче методов, а то и потоков. Подход "накосячить невозможно" лучше подхода "сам накосячил - сам дурак", не правда ли?

Да это же типичные ненастоящие шотландцы, если они косячат

@pycture · 13.01.2018, 14:40

Сообщение от Psilon

... единственном экземпляре. И тут либо мы передаем DbContext как зависимость и он висит вечно открытый...

передается опять таки в конструктор. и?

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

ну-ну...

Psilon · 13.01.2018, 15:18

pycture, в любом случае, DI тут никак не поможет, вместо `using DbContext` там будет `using MySmartDbContextWrapper`

Добавлено через 4 минуты
Энивей, это кусок из кода, который поправили буквально неделю назад. Если у вас так нитко не пишет и вы всегда правильно закрываете ресурсы - рад за вас, вам лучше вообще на скриптовых языках писать, которые никаких ограничений не накладывают. А я вот постоянно сталкиваюсь с незакрытми ресурсами, перлами вроде `await Task.FromResult(Ok()))`, которые пишут ребята с трехлетним опытом в яндексе... Лохи да и только.

Короче, не вижу смысла тратить время. Язык для тех, кто не безгрешен, вроде меня. Поможет правильно закрыть ресурсы, причем неявно, а не требуя явных юзингов-неюзингов. Говорить "никто так не делает" - beside the point. Я привел пример, что так делают, причем постоянно и не в шарашкиных конторах. Мне лично важнее, чтобы работа была сделана, а не обвинять разработчика, что он криворукий.

@korvin_ · 13.01.2018, 16:38

Сообщение от Psilon

Здесь use after free имеется. Удачи его найти.

Видио какие-то (шарпо|EF-)проблемы?

Сообщение от silent_1991

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

Да неужели?

Сообщение от silent_1991

И если один инструмент позволяет даже не задумываться о каком-то из видов ошибок, а во втором "ты мчудак, так никто не делает", то первый, очевидно, предпочтительнее, потому что очень неприятно оказаться таким чудаком после трёх дней поиска ошибки, которая была не в hello world, а в реальном коде, и, как и сказал Psilon, могла быть размазана по куче методов, а то и потоков. Подход "накосячить невозможно" лучше подхода "сам накосячил - сам дурак", не правда ли?

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

Сообщение от silent_1991

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

Ну вот GC, например, позволяет не задумываться о каком-то виде ошибок.
RAII позволяет не задумываться о каком-то другом виде ошибок.
Зависимые типы позволяют не задумываться о ещё более каких-то других видах ошибок.
Функциональное программирование позволяет не задумываться о ещё всяких каких-то других видов ошибок.

Так какой инструмен предпочтительней остальных?

@ct0r · 13.01.2018, 16:40

Сообщение от Psilon

да

Сообщение от Psilon

да

Каким образом, если я забуду drop реализовать?

Сообщение от Psilon

Кроме памяти есть еще ресурсы: сеть, файлы, пайпы... А GC помогает же только с ней.

Для памяти есть GC, для всего остального есть RAII. Что не так?

Сообщение от silent_1991

Только коммерческий интерес?

Если он интересен и может облегчить мне жизнь.

Сообщение от Psilon

Конечно, потом разобрались, но ловить такие ошибки в рантайме не хочется

Отлично, в итоге поймали на один баг больше, - потому что отсутствие таймаута - это баг.

Сообщение от silent_1991

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

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

Сообщение от Psilon

ребята с трехлетним опытом в яндексе

О, это да, чего они только не пишут. Сам там быдлокодил.

Новые блоги и статьи Все статьи Все блоги /
Лето уходит kumehtar 17.08.2026	Мысли в слух kumehtar 17.08.2026 Забавно, насколько сейчас стала доступна информация. Например о магии, духовном развитии, медитациях, и других подобных направлениях, ранее зачастую тайных, передаваемых от учителя к ученику. Хотя. . .	Перемещение строк из ТЧ в другой документ с учетом текущего пробега Maks 17.08.2026 Реализация из решения ниже выполнена на примере нетипового документа "Автозапчасти", с ТЧ "Шины". За основу взят алгоритм отсюда: https:/ / www. cyberforum. ru/ blogs/ 359708/ 10838. html Задача: . . .	Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .
Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .

@Casper-SC 4434 / 2094 / 404 Регистрация: 27.03.2010 Сообщений: 5,657 Записей в блоге: 1

	Язык программирования D и Rust. Пробовали? Что можете сказать? 03.02.2016, 09:17. Показов 7831. Ответов 88 Метки dlang, rust (Все метки) Я совсем немного пробовал работать с D, первое впечатление положительно. А по Rust посмотрел доклад, как увидел этот убогий стиль именования всего и вся в стиле: to_string, do_work, bla_bla_bla, что аж тошно стало. Понятно, что это не критерий оценки языка, так, просто, мысли в слух. Добавлено через 12 часов 4 минуты Ясно. Никто не пробовал. Я могу сказать, что D чем-то похож на C#, чем мне и понравился. 1

Psilon Master of Orion 6102 / 4958 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	13.01.2018, 15:18
	pycture, в любом случае, DI тут никак не поможет, вместо `using DbContext` там будет `using MySmartDbContextWrapper` Добавлено через 4 минуты Энивей, это кусок из кода, который поправили буквально неделю назад. Если у вас так нитко не пишет и вы всегда правильно закрываете ресурсы - рад за вас, вам лучше вообще на скриптовых языках писать, которые никаких ограничений не накладывают. А я вот постоянно сталкиваюсь с незакрытми ресурсами, перлами вроде `await Task.FromResult(Ok()))`, которые пишут ребята с трехлетним опытом в яндексе... Лохи да и только. Короче, не вижу смысла тратить время. Язык для тех, кто не безгрешен, вроде меня. Поможет правильно закрыть ресурсы, причем неявно, а не требуя явных юзингов-неюзингов. Говорить "никто так не делает" - beside the point. Я привел пример, что так делают, причем постоянно и не в шарашкиных конторах. Мне лично важнее, чтобы работа была сделана, а не обвинять разработчика, что он криворукий. 0