Здравствуйте, vsb, Вы писали:
G>>>>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?
vsb>>>Какие? Я таких не знаю.
S>>Ada, Eiffel, Rust, D.
vsb>Про первые два ничего не знаю
Тем не менее, это универсальные языки высокого уровня.
vsb>вторые два — низкоуровневые.
По поводу Rust-а еще можно было бы поспорить, но назвать низкоуровневым D -- это сильно, внушаить.
vsb>Высокоуровневые это, например, JS, Python. И там постоянно пакеты ставишь и оно что-то сишное компилировать начинает.
Сишное там не из-за высокоуровневости, а из-за динамической природы этих языков, за что и приходится платить накладными расходами в run-time.
vsb>Не знаю, что там с окамлями, но хаскель — адский тормоз. Думаю, его спасает только то, что на нём никто не пишет.
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Serginio1, Вы писали:
vsb>>Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут. S> Проблема не только в языке, но и области применения. Для Андроида родной Java плюс долго но уверенно набирает популярность Котлин. А большинство программистов находятся в мобильном сегменте и Вэб фронт где JS и TS
Котлин набирает популярность на андроиде только потому, что Гугл его объявит языком номер один на своей платформе. На сервере Котлин особую популярность не снискал, к примеру.
При этом тот же JS популярность имеет бешеную, и на сервере, и в мобильных телефонах и где только его не встретишь. Не удивлюсь, если для ядра уже модули где-нибудь на нём пишут. И ему область применения расширять ничего не мешает.
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, vsb, Вы писали:
vsb>>>Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут. S>> Проблема не только в языке, но и области применения. Для Андроида родной Java плюс долго но уверенно набирает популярность Котлин. А большинство программистов находятся в мобильном сегменте и Вэб фронт где JS и TS
vsb>Котлин набирает популярность на андроиде только потому, что Гугл его объявит языком номер один на своей платформе. На сервере Котлин особую популярность не снискал, к примеру.
vsb>При этом тот же JS популярность имеет бешеную, и на сервере, и в мобильных телефонах и где только его не встретишь. Не удивлюсь, если для ядра уже модули где-нибудь на нём пишут. И ему область применения расширять ничего не мешает.
Ну если ты заметил, то и TS набирает силу. Xamarin для Android тоже немного прибавляет. А так же Блазор для фронта.
Ну писать то конечно можно где угодно. Суть в том, что JS программистов много и дешевле. Для многих задач это не критично.
Если, же писать что то монструозное, то выбор JS как языка это ...
А как у JS с многопоточностью?
и солнце б утром не вставало, когда бы не было меня
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Я это уже понял, что дальше, как это помогает в генерации sql, например? НС>Для генерации, например, в системе типов необходима явная связь между геттером и сеттером.
Не совсем понял, почему явная связь? Разве не может быть только одного геттера или сеттера?
НС>>>Я выделил жирным в цитате, что ты не заметил при первом прочтении. Дело не в писанине. S>>Я это видел. А почему это так важно НС>Почему важен дополнительный контроль со стороны компилятора? Ты правда не знаешь ответа?
Надо уточнить, что он контролирует. Он не контролирует необходимость этих методов в паре, например.
(см. выше). Он контролирует, что если есть записть в св-во, то где-то должен быть метод set_.
S>>Для меня они сахар НС>First class citizen в системе типов не может быть сахаром по определению. Сахар это то, что может быть выражено другими средствами языка. Свойства, очевидно, не могут, это уникальная сущность, по другому не выражаемая.
Не просто другими, а существенно меньшим кол-ом кода. Св-ва многое упрощают, но не делают что-то концептуально возможным.
Пример -- ява. С ними однозначно лучше чем без них, спору нет.
Кодом людям нужно помогать!
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Serginio1, Вы писали:
S>Ну если ты заметил, то и TS набирает силу.
Я TS от JS особо не отличаю, они можно сказать в тандеме работают.
S>Ну писать то конечно можно где угодно. Суть в том, что JS программистов много и дешевле. Для многих задач это не критично.
А точно — дешевле? По-моему все примерно одинаково стоят.
S>А как у JS с многопоточностью?
Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.
Здравствуйте, vsb, Вы писали:
S>>Ну если ты заметил, то и TS набирает силу.
vsb>Я TS от JS особо не отличаю, они можно сказать в тандеме работают.
Угу это по сути 2 разных языка. Даже код. S>>Ну писать то конечно можно где угодно. Суть в том, что JS программистов много и дешевле. Для многих задач это не критично.
vsb>А точно — дешевле? По-моему все примерно одинаково стоят.
S>>А как у JS с многопоточностью?
vsb>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.
Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.
Если их в языке нет нет понятия потока?
Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
и солнце б утром не вставало, когда бы не было меня
Re[14]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Serginio1, Вы писали:
S>>>Ну если ты заметил, то и TS набирает силу.
vsb>>Я TS от JS особо не отличаю, они можно сказать в тандеме работают. S> Угу это по сути 2 разных языка. Даже код.
Чего это разных? Любой код на JS является валидным кодом на TS. Более того, преобразователь из TS в JS пишется вообще тривиально — вырезаем типы и всё, остаётся валидный JS. В принципе компилятор tsc примерно так и работает (ну помимо проверки типов на этапе компиляции).
vsb>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней. S> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры. S> Если их в языке нет нет понятия потока? S> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
Почему костыли-то? По-мне это все эти мьютексы — костыли. А нормальные потоки должны обмениваться сообщениями и никак иначе. Всё по заветам товарища Армстронга.
Re[15]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, vsb, Вы писали:
S>>>>Ну если ты заметил, то и TS набирает силу.
vsb>>>Я TS от JS особо не отличаю, они можно сказать в тандеме работают. S>> Угу это по сути 2 разных языка. Даже код.
vsb>Чего это разных? Любой код на JS является валидным кодом на TS. Более того, преобразователь из TS в JS пишется вообще тривиально — вырезаем типы и всё, остаётся валидный JS. В принципе компилятор tsc примерно так и работает (ну помимо проверки типов на этапе компиляции).
Во во. Еще там приведение типов,дженерики, интерфейсы итд.
В C# то же есть динамики
vsb>>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней. S>> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры. S>> Если их в языке нет нет понятия потока? S>> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
vsb>Почему костыли-то? По-мне это все эти мьютексы — костыли. А нормальные потоки должны обмениваться сообщениями и никак иначе. Всё по заветам товарища Армстронга.
Угу, а как блокировать доступ к переменным?
Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?
и солнце б утром не вставало, когда бы не было меня
Re[16]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Serginio1, Вы писали:
vsb>>>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней. S>>> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры. S>>> Если их в языке нет нет понятия потока? S>>> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
vsb>>Почему костыли-то? По-мне это все эти мьютексы — костыли. А нормальные потоки должны обмениваться сообщениями и никак иначе. Всё по заветам товарища Армстронга.
S>Угу, а как блокировать доступ к переменным?
не должно быть никакого доступа к переменным.
S> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?
Сообщениями. Вон тут в теме разработчик sobjectizer-а, думаю, расскажет, почему акторы лучше общих переменных.
Re[17]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, vsb, Вы писали:
S>>Угу, а как блокировать доступ к переменным?
vsb>не должно быть никакого доступа к переменным.
S>> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?
vsb>Сообщениями. Вон тут в теме разработчик sobjectizer-а, думаю, расскажет, почему акторы лучше общих переменных.
Для примера возьмем ту же БД. Там есть и версионность. Но что делать, если ты читаешь после начавшейся транзакции которая изменяет данные?
Кстати вот и еще один объект синхронизации c# ReaderWriterLockSlim
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
S>>Но что это меняет? Все равно будут вызываться методы. Т.е. пропертя это своего рода синтаксический сахар, S>>довольно удачный. Но почему без них невозможно в sql не понятно? G>Ну предложите вариант как сделать произвольную проекцию типизированной (проверяемой при компиляции) без свойств.
Если речь про анонимные типы, то да, св-ва помогают, но можно ведь и public fields. Иначе
на каждый чих заводить соотв. тип\класс.
S>>У меня будут вместо св-в генерироваться, допустим ORM, соотв. методы типа get_X. Дергать их. S>>Т.е. там, где исп. св-ва, что мешает исп. сгенерированные методы? G>А как их потом перевести в sql?
Блин, также, только там где стоит св-во, исп. соотв. метод. Как в яве-то это делается?
S>>>>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е. G>>>в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом? G>>>Bind в обе стороны работает. S>>Да, упустил. Ну опять же, кто-то это дело будет интерпритировать и у соотв. объекты вызывать соотв. методы get\set. G>И снова вопрос типизации и проверки при компиляции.
Не знаток Blazor, но в winforms если я исп. класс binding, он может во время исп. стрельнуть, что
нету какого-нибудь сеттера.
S>>Т.е. я согласен, что св-ва многое упрощают и т.д. Я не пониманию, почему св-ва делют что-то концептуально S>>возможным. Блин, это же сахар, в конце концов. G>"не верю, докажите мне" не очень разумная позиция.
Я не понял приписываемую магию св-ам в c#, типа без них невозможно создавать sql запросы и т.п. Когда как
пусть неудачный, но пример явы показывет, что все можно. Но св-ва действительно многое упрощают. Особенно биндинг.
Но там генерится соотв. код и если что-то где-то пропустили, то дадут знать на этапе компиляции. Это огромный плюс.
Кодом людям нужно помогать!
Re[18]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Serginio1, Вы писали:
S> Для примера возьмем ту же БД. Там есть и версионность. Но что делать, если ты читаешь после начавшейся транзакции которая изменяет данные?
Что-то я запутался, какое отношение БД имеет к этой дискуссии. Если отвечать на этот вопрос — то что делать, зависит от БД, от уровня изоляции транзакций, от особенностей реализации этой БД и тд. Можно попасть в блокировку, можно читать "старые" данные, можно читать "свежие" данные, которые даже не были ещё закоммичены.
Re[19]: Синтаксический сахар vs реально полезные вещи в ЯП
S>> Для примера возьмем ту же БД. Там есть и версионность. Но что делать, если ты читаешь после начавшейся транзакции которая изменяет данные?
vsb>Что-то я запутался, какое отношение БД имеет к этой дискуссии. Если отвечать на этот вопрос — то что делать, зависит от БД, от уровня изоляции транзакций, от особенностей реализации этой БД и тд. Можно попасть в блокировку, можно читать "старые" данные, можно читать "свежие" данные, которые даже не были ещё закоммичены.
А БД это пример доступа к данным и их изменениям из разных потоков. Там все равно применяют блокировки и получают взаимные блокировкаи.
Если все так просто как ты говоришь, почему же до сих пор в БД этого не сделали?
Как правило есть общие данные и они должны изменяться. И как прочитать реальные данные, а не изменяющиеся?
Не всегда оптимально держать такие данные в БД.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
vsb>>Что-то я запутался, какое отношение БД имеет к этой дискуссии. Если отвечать на этот вопрос — то что делать, зависит от БД, от уровня изоляции транзакций, от особенностей реализации этой БД и тд. Можно попасть в блокировку, можно читать "старые" данные, можно читать "свежие" данные, которые даже не были ещё закоммичены. S> А БД это пример доступа к данным и их изменениям из разных потоков. Там все равно применяют блокировки и получают взаимные блокировкаи.
В БД доступ к данным вообще из разных компьютеров в общем случае.
S>Если все так просто как ты говоришь, почему же до сих пор в БД этого не сделали?
Я не знаю, как сделали в БД, хотя давно хочу исходники постгреса почитать, но как-то случая не представляется.
Насколько я знаю, в постгресе каждое соединение это отдельный процесс. Как они там синхронизируют доступ между собой — я не знаю.
В любом случае пользовательский код и БД это сильно разные сущности. Не думаю, что есть какие-то принципиальные проблемы сделать эксклюзивный доступ к ресурсу через обмен сообщениями.
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, gandjustas, Вы писали:
vsb>>Если это вопрос жизни и смерти — ну напиши на C этот кусок программы. G>При таком раскладе лучше сразу в C++ пойти. зачем два языка надо? G>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?
Питон, например.
Кодом людям нужно помогать!
Re[21]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, vsb, Вы писали:
vsb>В любом случае пользовательский код и БД это сильно разные сущности. Не думаю, что есть какие-то принципиальные проблемы сделать эксклюзивный доступ к ресурсу через обмен сообщениями.
В большинстве случаев одинаковы. Ну вот твой подход это создание очереди и ожидание ответа.
Но в большинстве случаев не надо ничего посылать. Для этого прекрасно работают ReaderWriterLockSlim. Когда много читателей и редко писатель.
Опять ожидать ответа как будешь? Через постоянный опрос очереди?
Можно конечно еще и через пайпы или Tcp/ip!
Можно конечно через async await TaskCompletionSource<T> c TrySetResult(item);
Если не хочешь использовать эвенты.
Но это нехилые расходы ReaderWriterLockSlim намного экономнее.
Даже обычный lock!
Поэтому выбирают более эффективные объекты синхронизации
и солнце б утром не вставало, когда бы не было меня
