ffinder
> > Чистота функций к делу не относится. Совсем.
> не соглашусь. без аргументов, но не соглашусь.
Я очень плотно изучал вопрос.
К выводу типов сама семантика кода отношения не имеет.
ffinder
> вы не находите такое положение вещей абсурдным?
Я нахожу, что я опять ввязался в разговор с человеком, который на языках с выводом типов ничего не писал.
На практике для того чтобы читать код типы переменных знать не надо.
Это я говорю как человек не один метр кода, написавший на языках с выводом типов.
ffinder
> конкретизирую, что я имел в виду: не отказ от читаемого представления, а отказ
> от набора по буквам, и ультраагрессивная диагностика на самом раннем этапе - вводе.
Ты современные IDE то видел? Так даже интеграция немерле умеет. Хоть и пишут ее в свободное от работы время. А что IDE для C# и Java творят...
0iStalker
> Пиктограммы, графы/блоксхемы ?
ну не нужно выдумывать. где я хоть раз сказал про графическое представление?
возможно я неясно выразил свою мысль, попробую еще раз:
пишем код на клавиатуре
работает автокомплит, причем очень-очень агрессивный, до такой степени, что не дает вводить несуществующие имена переменных, методов, функций, нарушать вложенность скобочных выражений, пропускать аргументы функций и так далее
сразу же парсим введенную строку и если ошибка всё-таки проскочила - немедленно показываем сообщение об ошибке.
chucheloid
> Ты современные IDE то видел? Так даже интеграция немерле умеет.
я же предложил тебе ознакомиться с набором текста на спектруме.
так - не умеет. ты доказываешь неправильно понятое тобой утверждение.
посмотри видео на ютубе - потом спорь, а не наоборот.
chucheloid
> На практике для того чтобы читать код типы переменных знать не надо.
простите, но ЛОЛШТО?
это то есть как не надо? вот допустим переменная а, и вы совершенно не знаете её тип.
может быть это [Int], а может (Float, String), а может и вовсе QuadTreeNode
innuendo
> этот компактные код работает динамический, что не маловажно
И что тут такого сверхважного?
Мне вот все кажется, что если бы не ненужность указывать типы, то популярности динамике даже в скриптах не отгрести. А пока что скрипты - это именно вотчина динамики.
В других же случаях..
Тип в случае входных данных - так все равно как-то надо "сырые" данные проверить на корректность и превратить во вполне конкретный тип. Или пожаловаться на неверный ввод.
Ненужность наследования за счет утиной типизации?
Прототипное ООП? Так это, как по мне, не очень. Все равно есть границы, которые требуют каких-то гарантий. И неплохо бы выражать средствами языка, какие требования предъявляются к данным.
Grey304
> > этот компактные код работает динамический, что не маловажно
> И что тут такого сверхважного?
что такое динамическое ООП знаете ?
ffinder
> я же предложил тебе ознакомиться с набором текста на спектруме.
Как думаешь, почему этого нет в современных ИДЕ?
Думаешь, авторы IDEA не могут такое сделать?
А может просто по тому, что код с ошибками это естественное состояние программы в момент правок?
У меня периодически в программе бывают сотни ошибок компиляции, когда я что-то рефакторю.
Ибо изменилась логика. Изменились сигнатуры функций. И весь проект развалился. И никакой автокомплит тут не поможет.
Да и как делать вес этот суперагрессивный автокомплит если я например хочу сигнатуру функции поменять?.
ffinder
> простите, но ЛОЛШТО?
ЛОЛТО.
Надо имена переменным нормальные давать. Тогда и тип не нужен. Из имени все ясно.
innuendo
> что такое динамическое ООП знаете ?
Расшифруйте. Вот про прототипное ООП знаю. Только не вкуриваю, в чем убойная соль добавления в существующий объект нового метода.
Изменение библиотечного? Так это похоже на прелоставление костылей для кривых библиотек.
Изменение своего? Так можно предоставить механизмы, позволяющие настраивать поведение объектов. Если очень хочется, то и в язык встроить. И динамика тут не причем.
Grey304
> Расшифруйте.
> Только не вкуриваю, в чем убойная соль добавления в существующий объект нового
> метода.
в объект не добавляются, добовляются в класс :)
соль в том, что вы не останавливайте программу - так понятно ?
> Так можно предоставить механизмы, позволяющие настраивать поведение объектов.
> Если очень хочется, то и в язык встроить
вот как раз те же smalltalk, clos имеют такие возможности
chucheloid
> У меня периодически в программе бывают сотни ошибок компиляции, когда я что-то
> рефакторю.
именно сотни? или как в плюсах одна опечатка порождает десятка два "ошибок", потому что компилер не унимается после первой обнаруженной и продолжает обрабатывать неконсистетный код дальше?
chucheloid
> Изменились сигнатуры функций. И весь проект развалился.
ну, в моем будущем языке функция это атом (имя) и кортеж с типами параметров. перегрузка функций (ad hoc полиморфизм) конечно же будут.
так что создаем новую функцию с другими параметрами и она никак не ломает код, а потом потихоньку заменяем старые вызовы на новые.
если учесть что единицей компиляции обработки будет именно функция (как строка кода с номером в древних бейсиках) - то такой проблемы не будет существовать вовсе.
chucheloid
> Надо имена переменным нормальные давать. Тогда и тип не нужен. Из имени все
> ясно.
венгерская нотация снова в деле? ну уж нет, хватит.
innuendo
>соль в том, что вы не останавливайте программу
да, вот разработку "на лету" я бы очень хотел реализовать. прямо таки моя мечта.
ffinder
> да, вот разработку "на лету" я бы очень хотел реализовать. прямо таки моя
> мечта.
изучите то, что уже есть :)
ffinder
> именно сотни? или как в плюсах одна опечатка порождает десятка два "ошибок",
> потому что компилер не унимается после первой обнаруженной и продолжает
> обрабатывать неконсистетный код дальше?
Именно сотни. Если изменить сигнатуры нескольких функций и/или типов весь проект ошибками покроется.
ffinder
> так что создаем новую функцию с другими параметрами и она никак не ломает код,
> а потом потихоньку заменяем старые вызовы на новые.
Ахринеть дайте две.
Те вместо того чтобы спокойно переделать 5-10 функций так как мне надо.
После чего просто прощёлкать по ошибкам компиляции и исправить код.
Я должен создать новые функции.
После чего руками найти все места, где они используется. Типа я помню. Ага, конечно.
После того как руками все найду и исправлю, должен буду удалить старые функции.
Это же работу в несколько раз замедлит.
И все ради чего?
Ради того чтобы ленивый разработчик компилятора не надорвался делая восстановление после ошибок?
Много мата поскипано.
ffinder
> венгерская нотация снова в деле? ну уж нет, хватит.
Зачем? Просто нормальные имена, которые говорят, зачем переменная используется.
chucheloid
> После чего просто прощёлкать по ошибкам компиляции и исправить код.
error-driven programming?
chucheloid
> Я должен создать новые функции.
ну, годная IDE должна давать возможность в два-три нажатия клавиш создавать или даже копировать функции.
> После чего руками найти все места, где они используется. Типа я помню. Ага, конечно.
годная IDE может найти все использования функций, в языке, где явно задаются типы аргументов:)
> После того как руками все найду и исправлю, должен буду удалить старые функции.
удалить старые тоже должно быть два-три нажатия.
проблема нынешних IDE - средненько-плохие браузеры структуры проекта, потому и надо искать руками.
PS: идеальная IDE может пойти дальше. меняем тип - нам говорят, что мол от этого определения зависят вот такие, и дальше список функций вот в таких вот модулях.
и держать список поломанного, чтобы можно было по нему прыгать и исправлять.
т.е. разногласия у нас в том моменте, что "в нормальном состоянии код поломан"
думаю, что если сохранять только атомарные консистентные состояния кода на уровне IDE - всем будет легче.
с сугубо текстовым представлением кода этого достичь тяжело, т.к. код можно править (вернее ломать) даже в блокноте.
Вывод типов это хорошо.
chucheloid +1
laMer007
> Lisp, если уметь им пользоваться, может быть весьма не плох в этой области.
неплох, но не более.
все наследники ML будут поудобнее - т.к. есть ADT и pattern matching.
в немерле к тому же есть возможность генерить синтаксический сахар не хуже чем в лиспах.
иннуенда в своем репертуаре..
ffinder
> ну, годная IDE должна давать возможность в два-три нажатия клавиш создавать или
> даже копировать функции.
Так они и позволяют.
Берешь текст и копируешь.
> годная IDE может найти все использования функций, в языке, где явно задаются
> типы аргументов:)
Давно современные ИДЕ смотрел? Поставь IDEA и посмотри, что она может.
Только эта функциональность не для этого нужна.
> идеальная IDE может пойти дальше. меняем тип - нам говорят, что мол от этого
> определения зависят вот такие, и дальше список функций вот в таких вот
> модулях.
> и держать список поломанного, чтобы можно было по нему прыгать и исправлять.
Это, блин, список ошибок компиляции.
Все есть.
> думаю, что если сохранять только атомарные консистентные состояния кода на
> уровне IDE - всем будет легче.
Не будет.
> с сугубо текстовым представлением кода этого достичь тяжело
Я занимаюсь созданием алгоритмов парсинга ибо существующие говно до такой степени что промышленные компиляторы полностью руками пишут.
Так что я в теме по уши. И там все не так страшно как ты тут вещаешь.
А если вести разговор про ошибки типизации, то с ними вообще никаких проблем нет.
Там все просто как не учить уроки.
Тема в архиве.