Сообщение Re[4]: Эффективность VS Сопровождаемость от 03.03.2017 18:50
Изменено 03.03.2017 18:50 Gattaka
Re[4]: Эффективность VS Сопровождаемость
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Gattaka, Вы писали:
G>>Здравствуйте, Философ, Вы писали:
Ф>>>ЗЫ: я в шоке.
G>>Судя по вашей реакции вас в этой мясорубке изрядно молотило уже. Ну а так как вы приверженец эффективного кода, то набросились на меня с минусами. Ничего мне не привыкать, сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной.
G>>И все же было бы неплохо если бы вы внимательнее читали исходное сообщение.
Ф>Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:
Ф>существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ.
Все верно.
Ф> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ассемблер элементраный и именно поэтому сложный.
Но часто получается не так эффективно если бы мы напряглись на недельку заперлись и налабали на чистом асемблере. Мы приносим в жертву немного эффективности ради сопровождаемости и удобства. На Си вы в несколько раз быстрее напишите то что требуется, а также сможете быстро внести правки в существующий код.
Ф>Файлы вместо БД я уже предлагал — там тоже самое.
Файлы вместо БД это как ассемблер вместо Си. БД ведь базируется на файлах в конечном итоге. Ровно как и Си базируется на ассемблере. Так что в данном случае вы как раз копаете в противоположном направлении.
Ф>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Ну а какая разница почему ХП хуже сопровождаются. IDE или инструментальные средства, важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит. Другой вопрос что здесь возникает лишний трафик между базой и сервером приложений. Ну так на это просто забивают, т.е. приносят в жерту эффективность ради удобства и сопровождаемости.
SQL плохо структурируется, copy paste в нем обычное дело.
Ф>Здравствуйте, Gattaka, Вы писали:
G>>Здравствуйте, Философ, Вы писали:
Ф>>>ЗЫ: я в шоке.
G>>Судя по вашей реакции вас в этой мясорубке изрядно молотило уже. Ну а так как вы приверженец эффективного кода, то набросились на меня с минусами. Ничего мне не привыкать, сейчас меня еще минусанет приверженец сопровождаемого кода и картина будет более полной.
G>>И все же было бы неплохо если бы вы внимательнее читали исходное сообщение.
Ф>Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:
Ф>существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ.
Все верно.
Ф> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ассемблер элементраный и именно поэтому сложный.
Но часто получается не так эффективно если бы мы напряглись на недельку заперлись и налабали на чистом асемблере. Мы приносим в жертву немного эффективности ради сопровождаемости и удобства. На Си вы в несколько раз быстрее напишите то что требуется, а также сможете быстро внести правки в существующий код.
Ф>Файлы вместо БД я уже предлагал — там тоже самое.
Файлы вместо БД это как ассемблер вместо Си. БД ведь базируется на файлах в конечном итоге. Ровно как и Си базируется на ассемблере. Так что в данном случае вы как раз копаете в противоположном направлении.
Ф>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Ну а какая разница почему ХП хуже сопровождаются. IDE или инструментальные средства, важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит. Другой вопрос что здесь возникает лишний трафик между базой и сервером приложений. Ну так на это просто забивают, т.е. приносят в жерту эффективность ради удобства и сопровождаемости.
SQL плохо структурируется, copy paste в нем обычное дело.
Re[4]: Эффективность VS Сопровождаемость
Здравствуйте, Философ, Вы писали:
Ф>Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:
Ф>существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ.
Все верно.
Ф> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ассемблер элементраный и именно поэтому сложный.
Но часто получается не так эффективно если бы мы напряглись на недельку заперлись и налабали на чистом асемблере. Мы приносим в жертву немного эффективности ради сопровождаемости и удобства. На Си вы в несколько раз быстрее напишите то что требуется, а также сможете быстро внести правки в существующий код.
Ф>Файлы вместо БД я уже предлагал — там тоже самое.
Файлы вместо БД это как ассемблер вместо Си. БД ведь базируется на файлах в конечном итоге. Ровно как и Си базируется на ассемблере. Так что в данном случае вы как раз копаете в противоположном направлении.
Ф>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Ну а какая разница почему ХП хуже сопровождаются. IDE или инструментальные средства, важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит. Другой вопрос что здесь возникает лишний трафик между базой и сервером приложений. Ну так на это просто забивают, т.е. приносят в жерту эффективность ради удобства и сопровождаемости.
SQL плохо структурируется, copy paste в нем обычное дело.
Ф>Нет, я просто думаю, что немного лучше понимаю, что такое сопровождаемость кода. Ещё раз попытаюсь донести:
Ф>существует такой суперпростой и примитивный язык "ассемблер": есть только примитивные операции, регистры и ячейчки памяти — никаких функторов, лямбд, ленивых вычислений, никаких видов наследования, никаких шаблонов, нет статических полей/полей инстанса — всё предельно просто "inc ebx; move [eax], ebx" — делает ровно то, что написано и ничего больше. Но людям почему-то на нём писать слолжно — понапридумывали всяких абракадабр, в которые далеко не каждый студент воткнёт, и далеко не каждый программист знает. Ассемблер — идеальный код: минимум нюансов, читать легко, написанное всегда однозначно, работает быстро. И тем не менее ассемблерные программы почему-то хуже сопровождаются нежели программы на ЯВУ.
Все верно.
Ф> Вывод тут такой: простые инструменты и технологии никак не гарантирую сопровождаемости кода.
А вот тут стоп! Простые? У вас программа на Си положим 1000 строк кода превращается в 20000 кода на асемблере. Так что проще 1000 строчек или 20000. Конечно на Си программа проще. Си — простой. Ассемблер элементраный и именно поэтому сложный.
Но часто получается не так эффективно если бы мы напряглись на недельку заперлись и налабали на чистом асемблере. Мы приносим в жертву немного эффективности ради сопровождаемости и удобства. На Си вы в несколько раз быстрее напишите то что требуется, а также сможете быстро внести правки в существующий код.
Ф>Файлы вместо БД я уже предлагал — там тоже самое.
Файлы вместо БД это как ассемблер вместо Си. БД ведь базируется на файлах в конечном итоге. Ровно как и Си базируется на ассемблере. Так что в данном случае вы как раз копаете в противоположном направлении.
Ф>Сопровождаемость — свойство самого кода, его структуризации и изоляции ошибок в нём. И хранимые процедуры хуже сопровождаются не потому что ими пытались увеличить скорость, и не потому что они внутри БД, а потому что языки СУБД имеют мало средств выразительности и плохую поддержку со стороны IDE'шек — те же CTE лет шесть назад всего появилсь.
Ну а какая разница почему ХП хуже сопровождаются. IDE или инструментальные средства, важен сам факт и люди выбирают Linq2DB. Потому что под дебагером могут в тесте смотреть что происходит. Другой вопрос что здесь возникает лишний трафик между базой и сервером приложений. Ну так на это просто забивают, т.е. приносят в жерту эффективность ради удобства и сопровождаемости.
SQL плохо структурируется, copy paste в нем обычное дело.