Re[8]: Swift
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.06.14 19:43
Оценка:
Здравствуйте, Mamut, Вы писали:

M>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)


Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[10]: Swift
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.06.14 19:43
Оценка:
Здравствуйте, Mamut, Вы писали:

M>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а


Конечно конечно. Я вот проект уже несколько месяцев пишу, а в нем, прикинь, ни одного мейна.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[9]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 19:46
Оценка:
M>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)
AVK>Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.

Еще один.


dmitriid.comGitHubLinkedIn
Re[11]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 19:47
Оценка:
M>>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а
AVK>Конечно конечно. Я вот проект уже несколько месяцев пишу, а в нем, прикинь, ни одного мейна.

Поздравляю


dmitriid.comGitHubLinkedIn
Re[10]: LinqPad
От: Qbit86 Кипр
Дата: 03.06.14 20:01
Оценка:
Здравствуйте, Mamut, Вы писали:

M>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а :xz:


Для C# есть LinqPad.
Глаза у меня добрые, но рубашка — смирительная!
Re[11]: LinqPad
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 20:03
Оценка:
M>>В C/C++/Java/C# ты даже строчку кода не можешь запустить без main'а

Q>Для C# есть LinqPad.


Для C# еще и PowerShell есть


dmitriid.comGitHubLinkedIn
Re[10]: Разовью мысль
От: Mamut Швеция http://dmitriid.com
Дата: 03.06.14 20:08
Оценка: 20 (2) +3
M>>>2. Для большинства языков, чтобы что-то выполнить, нужно написать толпу обвязки вокруг (все эти main'ы, вызовы и прочее)
AVK>>Большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.

M>Еще один.


Вы с Владом придумали себе два тезиса:

1. REPL не нужен, вместо него нужны более серьёзные средства отладки и управления проектами.
2. REPL не нужен, большинство языков давно обзавелись фреймворками для юнит-тестирования и тест-раннерами в составе IDE.

Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования. Но вы эти два тезиса придумали и пытаетесь с ними бороться


dmitriid.comGitHubLinkedIn
Re[7]: Swift
От: novitk США  
Дата: 03.06.14 20:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну то есть, как замена удобному отладчику.


Репл ортоганален отладчику. Выставляешь брейки, потом приходишь к ним из репла.
Re[8]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 20:36
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Немерл. И на практике. И «большие приложения». Извини, но количество взаимоисключений тут слишком велико.


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

Мы пишем довольно большой проект на Немерле. И не один. Репл у нас был еще 6 лет назад. По мере развития компилятора его поломали. Но так как на практике от него нет толку, его никто не восстанавливает.

Это реальность. А то что ты там себе придумал — это твоя виртуальная реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Swift
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.06.14 20:49
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>ставишь бряк куда надо, а там тупо вызываешь функции как хочешь.


Это и функциями отладчика делается прекрасно. Репл тут не нужен.

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


В студии даже можно исправить код в C# и продолжить выполнение. Причем тут репл?

I>скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.


Это домыслы.

Я вот не видел еще репла с отладчиком связанного. Обычно это отдельная утилита. А функцию вызвать — это сколько угодно и без него.

I>Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.


Очевидно ты мало понимаешь в предмете обсуждения. Вот погляди что народ делает в области того же веба http://nemerleweb.com
Как и очевидно, что сотф не сходится к серверному или мобильному.

I>Прикинь, как круто — на каждый мелкий бажок создаешь инсталяционный пекадж, инсталируешь, запускаешь, ждёшь, прогоняешь всю цепочку и все это для того, что бы выяснить ,что в путях потерялся один из компонетов.


Это все вещи не связанные с наличием или отсутствием репла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.06.14 20:55
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


VD>В студии даже можно исправить код в C# и продолжить выполнение. Причем тут репл?


Исправление кода на многих системах недоступно, ты не знал про это ?

I>>скажем, рестарт сервера занимает несколько минут. проверить вырианты одной функции, это на пару секунд на каждый. Без репл это превращается в часы отладки.


VD>Это домыслы.


Это факты.

VD>Я вот не видел еще репла с отладчиком связанного. Обычно это отдельная утилита. А функцию вызвать — это сколько угодно и без него.


I>>Вероятно оттого, что всё кругом на макросах а ни серверных приложений, ни мобильных не пишется.


VD>Очевидно ты мало понимаешь в предмете обсуждения. Вот погляди что народ делает в области того же веба http://nemerleweb.com


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

Сколько лет этим примерам ? Чем они лучше N+1 других фремворков ? Похоже, ничем, только требуют намного больше кода.

Серверные это не всегда веб, кстати говоря.

VD>Как и очевидно, что сотф не сходится к серверному или мобильному.


это самый большие ниши на сегодняшний день.

I>>Прикинь, как круто — на каждый мелкий бажок создаешь инсталяционный пекадж, инсталируешь, запускаешь, ждёшь, прогоняешь всю цепочку и все это для того, что бы выяснить ,что в путях потерялся один из компонетов.


VD>Это все вещи не связанные с наличием или отсутствием репла.


Это так кажется.
Re[9]: Swift
От: Mamut Швеция http://dmitriid.com
Дата: 04.06.14 04:28
Оценка:
VD>Мы пишем довольно большой проект на Немерле. И не один. Репл у нас был еще 6 лет назад. По мере развития компилятора его поломали. Но так как на практике от него нет толку, его никто не восстанавливает.

VD>Это реальность. А то что ты там себе придумал — это твоя виртуальная реальность.



Виртуальная реальность — это называть полтора проекта, которые пишут пять людей, реальностью и истиной, которая распространяется на всех.


dmitriid.comGitHubLinkedIn
Re[11]: Разовью мысль
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.06.14 06:38
Оценка: 1 (1)
Здравствуйте, Mamut, Вы писали:

M>Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования.


Самое смешное что ты не умеешь читать. Я отвечал исключительно на твою реплику о том, что нужно написать кучу обвязки. Так вот, это не так — достаточно написать один единственный метод и пометить его атрибутом [Test].
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[12]: Разовью мысль
От: Mamut Швеция http://dmitriid.com
Дата: 04.06.14 07:39
Оценка:
M>>Самое смешное, никто нигде не говорит, что REPL заменяет средства отладки или средства для удобного юнит-тестирования.

AVK>Самое смешное что ты не умеешь читать. Я отвечал исключительно на твою реплику о том, что нужно написать кучу обвязки. Так вот, это не так — достаточно написать один единственный метод и пометить его атрибутом [Test].


Действительно, ведь все абсолютно упирается в юнит тесты, и все можно решить юнит-тестами


dmitriid.comGitHubLinkedIn
Re[3]: Swift
От: Klapaucius  
Дата: 04.06.14 08:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>90е и 2000 это Java и C#, в которых еще более примитивный switch


Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.

I>Да, не такой, как в Хаскеле


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

I>Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.


Тут неявное предположение, что если кто-то с чем-то имеет дело постоянно — он и дальше хотел бы продолжать иметь.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[7]: Swift
От: Klapaucius  
Дата: 04.06.14 08:56
Оценка: +4
Здравствуйте, Cyberax, Вы писали:

C>Ну то есть, как замена удобному отладчику.


Нет, это не замена отладчику, это скорее замена всяким приседаниям с "созданием файликов".

РЕПЛ можно использовать совместно с отладчиком — и тогда окружение на брейкпойнте можно "инспектировать" и обрабатывать результат прямо определенной на месте функцией на этом же самом языке.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Swift
От: Klapaucius  
Дата: 04.06.14 09:00
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>В Немерле репл сдох за ненадобностью.


Nemerlish, насколько я помню, был с самыми зачаточным функционалом, так что пользы от него было немного и не удивительно, что он оказался никому не нужен. Нормальный доделанный РЕПЛ инструмент более серьезный, в нем доступен язык полностью, т.е. можно любые декларации делать, автокомплит есть, интеграция с отладчиком и т.д.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[4]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 10:18
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

I>>90е и 2000 это Java и C#, в которых еще более примитивный switch


K>Я имел в виду, что в 70-е уже "неплоский" изобрели. А на Java и C# чего равняться — в них (языках, не реализациях) фич, изобретенных после 1968-го раз два и обчелся.


Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?

K>Да, и не такой как в остальных языках с паттерн матчингом. Вообще, тяжело навскидку вспомнить, где бы он был такой же страшный. Даже в скале получше, а там заявка на самый страшный ПМ серьезная.


Нет задачи дать внятный ПМ тем, у кого он и так есть.

Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.

I>>Для 90% разрабов, которые только и имеют дело с сишным синтаксисом, это очень круто.


K>Тут неявное предположение, что если кто-то с чем-то имеет дело постоянно — он и дальше хотел бы продолжать иметь.


Тут неявно указание на популярность сишного синтаксиса за последние 40 лет.

Есть факт — от императивного программирования отказа быть в принципе не может, в силу ряда причин, в частности слишком низком перформансе функциональных языков в низкоуровневых алгоритмах

И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.
Re[5]: Swift
От: Klapaucius  
Дата: 04.06.14 11:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?


Нет, не смущает. Эти языки востребованы не из-за фич языков, а фич инфраструктуры вообще и реализаций в частности, этих языков, которых как раз достаточно и вложить столько труда в инфраструктуру какого-то другого, более продвинутого языка просто никто не может себе позволить.
Там где требования к качеству реализации низкие (в случае всяких питонов-рубей) языки выглядят совсем иначе и с перечисленными "самыми востребованными" имеют мало общего. Короче говоря, был бы для JVM только интеркол — писали бы на интерколе, просто текучка кадров и заполняемость психлечебниц слегка подскочила бы.

I>Нет задачи дать внятный ПМ тем, у кого он и так есть.

I>Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.

Непонятно только, зачем давать "хоть какой-то", если можно нормальный дать?

I>Есть факт — от императивного программирования отказа быть в принципе не может, в силу ряда причин, в частности слишком низком перформансе функциональных языков в низкоуровневых алгоритмах


Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.

Это по другому нужно сформулировать: синтаксис в ФЯ лекгковесен для (и, следовательно, поощряет использование) лямбд, карринга и полиморфизма, все это связано с издержками в смысле перформанса. В сишном синтаксисе за все это обычно дают по рукам на ранних подступах, средствами карательного синтаксиса.
Поэтому вполне можно обосновать громоздкий синтаксис для лямбд, f(a,b,c) синтаксис и страшные аннотации параметрического полиморфизма. Но какая польза от убогого паттерн-матчинга? Компилятор паттерн-матчинга, как правило, дает код лучше того, который бы средний программист написал разбирая какую-то сложную структуру. Зачем за него наказывать?

I>И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.


Для меня ужасы сишного синтаксиса — это, в первую очередь, адские типы ссылок на функции/массивов, префиксные аннотации типов и параметры типов с елочками и монструозные свитчи, которые как раз совсем не в духе общей тенденции сишного синтаксиса не злоупотреблять большим кол-вом ключевых слов на строку кода. Ничего этого для императивного программирования не нужно.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: Swift
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.06.14 13:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:

I>>Тебя не смущает, что самые популярные и востребованые языки, это те, в которых никаких особенных фич то и нет ?


K>Нет, не смущает. Эти языки востребованы не из-за фич языков, а фич инфраструктуры вообще и реализаций в частности, этих языков, которых как раз достаточно и вложить столько труда в инфраструктуру какого-то другого, более продвинутого языка просто никто не может себе позволить.


Ты плохо прочёл — в этих языках фич практически нет. Отсюда следствие — отсутствие фич не является препятствием, ни разу.

K>Там где требования к качеству реализации низкие (в случае всяких питонов-рубей) языки выглядят совсем иначе и с перечисленными "самыми востребованными" имеют мало общего. Короче говоря, был бы для JVM только интеркол — писали бы на интерколе, просто текучка кадров и заполняемость психлечебниц слегка подскочила бы.


Это голословно. Хорошо бы увидеть какие то жосткие данные на тему "в областях где цена ошибки высока (== цене бизнеса, цене жизни и тд) используется XXX"

Итого, от тебя требуется раскрыть XXX. Лично я сомневаюсь, что там будет доминировать пейтоны-руби-хаскели. Там даже эрланг не будет доминировать, хотя он там точно есть.

I>>Есть другая задача — дать хоть какой то ПМ тем, у кого ничего нет.


K>Непонятно только, зачем давать "хоть какой-то", если можно нормальный дать?


Уже наверное 50 лет дают и никак дать не могут. Функциональщина хронически не лезет в мейнстрим, ну никак.

K>Да нет, парформанс лапшевого низкоуровневого кода обычно нормальный (если компилировать LLVM/JVM/CLR, а не какими-нибудь студенческими кодогенераторами), проблема в том, что идиоматический код тормозит и многие даже проблемой это не считают, а значит в этом направлении не работают.


1 низкоуровневые алгоритмы, если они не на си или не на оптимизированых шаблонах С++ сосут не нагибаясь. Разница в перформансе-потреблении памяти минимум в разы. отсюда ясно, почему обработку изображений никто в своём уме не пишет на функциональных языках.
2 идиоматический код еще сильнее усугубляет проблемы

K>Это по другому нужно сформулировать: синтаксис в ФЯ лекгковесен для (и, следовательно, поощряет использование) лямбд, карринга и полиморфизма, все это связано с издержками в смысле перформанса. В сишном синтаксисе за все это обычно дают по рукам на ранних подступах, средствами карательного синтаксиса.


Сишный синтаксис очень хорош для структур данных, ООП и подобных вещей. Скажем, для описания данных лучше чем JSON не придумаешь.

K>Поэтому вполне можно обосновать громоздкий синтаксис для лямбд, f(a,b,c) синтаксис и страшные аннотации параметрического полиморфизма. Но какая польза от убогого паттерн-матчинга? Компилятор паттерн-матчинга, как правило, дает код лучше того, который бы средний программист написал разбирая какую-то сложную структуру. Зачем за него наказывать?


Убогий паттерн матчинг на порядок лучше его отсутствия.

I>>И вот пока что для императивного программирования сишный синтаксис самый сбалансированый. Скажем, идейка выравнивать код отступами интересная, но её массы как то не принимают.


K>Для меня ужасы сишного синтаксиса — это, в первую очередь, адские типы ссылок на функции/массивов, префиксные аннотации типов и параметры типов с елочками и монструозные свитчи, которые как раз совсем не в духе общей тенденции сишного синтаксиса не злоупотреблять большим кол-вом ключевых слов на строку кода. Ничего этого для императивного программирования не нужно.


"монструозные свитчи" это из за отстутствия даже убогого ПМ. Адские типы ссылок на функции-массивы из за слабого полиморфизма.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.