Здравствуйте, ilion, Вы писали:

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

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Очень сильно зависит от конкретной работы. Вот, к примеру, в нашем проекте компилятор кой чего без автогенеренного кода занимает 700К. На первый более менее законченный вариант ушло где то порядка месяца. Но при этом где то половину этого месяца ушло на маленький кусочек 50К размером.

AVK>Не только короткого. Я тебе привел пример, когда за месяц была наработана твоя годовая норма. Значит, как минимум за год уже показатели могут плавать в 2 раза.

700Кб/месяц это результат работы одного разработчика без использования автогенераторов? Из первого поста у меня такого впечатления не сложилось, возможно из-за фразы "в нашем проекте компилятор кой чего без автогенеренного кода занимает 700К". Интересны именно личные показатели.

Здравствуйте, ilion, Вы писали:

I>700Кб/месяц это результат работы одного разработчика без использования автогенераторов?

Exactly

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, ilion, Вы писали:

I>>700Кб/месяц это результат работы одного разработчика без использования автогенераторов?

AVK>Exactly

Говорят, он быстроходен, даже неуловим:

10 * 8 * 3600 = 288000
650000 / 288000 = 2.26 знака/с = 135.4 знака/мин

Хм. VladD2?

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

Здравствуйте, ilion, Вы писали:

I>Собираюсь в отпуск и решили провести заключительный разбор на сколько за год подрос проект — по всем параметрам: функциональность, юзабилити и многое другое, в частности, собственно размер исходников. Выяснилось, что за прошедший год лично я накодил порядка 700 Кб исходников на Java, т.е., грубо говоря, порядка 60 Кб в месяц. Это по основному проекту, всякие мелкие тулзы не рассматриваем. Стало интересно, а сколько в среднем кода пишут коллеги?

А у меня... Один мегабайт исходников. Это весть проект.
Таким он стал 4 года назад. И больше не растет.
А месяц назад похудел на 30КБайт. (смайлик, высовывающий язык)

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Говорят, он быстроходен, даже неуловим:

ГВ>10 * 8 * 3600 = 288000

24 плюс копипейст, надо полагать

Здравствуйте, Геннадий Васильев, Вы писали:

Решарпер и комменты забыл.

Здравствуйте, AndrewVK, Вы писали:

AVK>Решарпер и комменты забыл.

Ну если только с решарпером.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну если только с решарпером.

а что он такого делает?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>а что он такого делает?

Продвинутый автокомплит, автоматический рефакторинг, заготовки реализаций интерфейсов и override методов, создание стабов методов, локальных переменных, полей по месту, автоматическая генерацият equals/gethashcode, сниппеты, автоматическое создание конструкторов, свойств, автоматическое добавление проверок на null и куча другого.

Здравствуйте, AndrewVK, Вы писали:

AVK>Продвинутый автокомплит, автоматический рефакторинг, заготовки реализаций интерфейсов и override методов, создание стабов методов, локальных переменных, полей по месту, автоматическая генерацият equals/gethashcode, сниппеты, автоматическое создание конструкторов, свойств, автоматическое добавление проверок на null и куча другого.

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

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

Здравствуйте, BulatZiganshin, Вы писали:

BZ>понятно. где-то половина из этого в хаскеле не нужна, [...]
BZ>а вот как интересно в плане дальнейшего сопровождения. [...]

Ну всё, начались сравнения линеек...

Здравствуйте, BulatZiganshin, Вы писали:

BZ>понятно. где-то половина из этого в хаскеле не нужна, т.е. выходит что условно говоря 700 кб на C# равны по функциональности 350 кб на хаскеле, но при этом пишутся они за одинаковое время

При чем тут хаскель?

BZ>а вот как интересно в плане дальнейшего сопровождения. к примеру, добавляешь ты поле в класс — все сгенерённые методы автоматом изменяются?

Нет конечно. А почему методы должны меняться от добавления поля?

BZ> или допустим изменяешь тип переменной, которая передаётся в подпрограмму — тип подпрограммы автоматом изменится?

Если через рефакторинг change signature делать — изменится везде, где он используется в солюшене.

Здравствуйте, AndrewVK, Вы писали:

BZ>>понятно. где-то половина из этого в хаскеле не нужна, т.е. выходит что условно говоря 700 кб на C# равны по функциональности 350 кб на хаскеле, но при этом пишутся они за одинаковое время

AVK>При чем тут хаскель?

потому, что многословность C# компенсируется средствами автогенерации кода, разве непонятно?

BZ>>а вот как интересно в плане дальнейшего сопровождения. к примеру, добавляешь ты поле в класс — все сгенерённые методы автоматом изменяются?

AVK>Нет конечно. А почему методы должны меняться от добавления поля?

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

BZ>> или допустим изменяешь тип переменной, которая передаётся в подпрограмму — тип подпрограммы автоматом изменится?

AVK>Если через рефакторинг change signature делать — изменится везде, где он используется в солюшене.

смотри:

int a;
f(a)

f(int x) {
 g(x);
}

g(int y) {
}

теперь ты меняешь тип a на double. изменятся автоматом типы функций?

Здравствуйте, BulatZiganshin, Вы писали:

AVK>>При чем тут хаскель?

BZ>потому, что многословность C# компенсируется средствами автогенерации кода, разве непонятно?

Непонятно, какое отношение к разговору имеет многословность шарпа по отношению к хаскелю.

AVK>>Нет конечно. А почему методы должны меняться от добавления поля?

BZ>к примеру автосгенерённый метод equal сравнивает *все* поля на момент генерации. что делать после добавления нового поля?

Equals надо перегенерять.

AVK>>Если через рефакторинг change signature делать — изменится везде, где он используется в солюшене.

BZ>смотри:
BZ>

BZ>int a;
BZ>f(a)

BZ>f(int x) {
BZ> g(x);
BZ>}

BZ>g(int y) {
BZ>}
BZ>

BZ>теперь ты меняешь тип a на double. изменятся автоматом типы функций?

Такого рефакторинга у решарпера нет. Есть наоборот — меняешь сигнатуру метода, меняется исползование.

Здравствуйте, AndrewVK, Вы писали:

AVK>Непонятно, какое отношение к разговору имеет многословность шарпа по отношению к хаскелю.

потому что производиетльность труда оценивается в конечном счёте не в строчках, а в фичах

BZ>>смотри:
BZ>>

BZ>>int a;
BZ>>f(a)

BZ>>f(int x) {
BZ>> g(x);
BZ>>}

BZ>>g(int y) {
BZ>>}
BZ>>

BZ>>теперь ты меняешь тип a на double. изменятся автоматом типы функций?

AVK>Такого рефакторинга у решарпера нет. Есть наоборот — меняешь сигнатуру метода, меняется исползование.

ну а тип через несколько вложенных вызовов оно протащит? т.е. один из "рефакторингов" состоит в том, что в g нужно изменить тип y — сделать из него tuple или ещё что. меняется тело g. в соответствии с этим меняется и вызов верзнего уровня, f(a), который теперь должен передавать больше данных. проблема в том, что теперь должны измениться и сигнатуры всех промежуточных метордов, через которые эти данные протаскиваются. при выводе типов это проихсодит автоматом. может ли как-то решить эту проблему решарпер?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>потому что производиетльность труда оценивается в конечном счёте не в строчках, а в фичах

Это к автору топика.

AVK>>Такого рефакторинга у решарпера нет. Есть наоборот — меняешь сигнатуру метода, меняется исползование.

BZ>ну а тип через несколько вложенных вызовов оно протащит?

Скорее всего нет — слишком чревата подобная автоматика. Я бы такое сразу отключил.

Здравствуйте, AndrewVK, Вы писали:

BZ>>потому что производиетльность труда оценивается в конечном счёте не в строчках, а в фичах
AVK>Это к автору топика.

а он тут при чём? меня заинтересовал решарпер vs haskell

AVK>>>Такого рефакторинга у решарпера нет. Есть наоборот — меняешь сигнатуру метода, меняется исползование.

BZ>>ну а тип через несколько вложенных вызовов оно протащит?

AVK>Скорее всего нет — слишком чревата подобная автоматика. Я бы такое сразу отключил.

люди всегда боятся нового

Здравствуйте, BulatZiganshin, Вы писали:

BZ>а он тут при чём? меня заинтересовал решарпер vs haskell

Тогда заводи отдельный топик, причем не в этом форуме.

AVK>>Скорее всего нет — слишком чревата подобная автоматика. Я бы такое сразу отключил.

BZ>люди всегда боятся нового

Это не новое. Примерно по той же причине в Nemerle, к примеру, нет вывода типов к контрактах. Контракты должны формироваться человеком, а не плавать, иначе большая часть смысла в них теряется.