История изменений

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Просто потому что нет разницы для нашей вселенной «повторить бесконечное число раз» или «повторить число раз большее числа этих повторов умещающихся во времени жизни вселенной» или даже «повторить большее число раз чем умещается во времени жизни вычислительной системы». Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: если ты недостаточно опытен то 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это был экспериментальный язык. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные. По этой причине я думаю ленивость хаскеля нужно рассматривать как недостаток.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Просто потому что нет разницы для нашей вселенной «повторить бесконечное число раз» или «повторить число раз большее числа этих повторов умещающихся во времени жизни вселенной» или даже «повторить большее число раз чем умещается во времени жизни вычислительной системы». Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: если ты недостаточно опытен то 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это был экспериментальный язык. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные. По этой причине я думаю ленивость хаскеля нужно рассматривать как недостаток.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Просто потому что нет разницы для нашей вселенной «повторить бесконечное число раз» или «повторить число раз большее числа этих повторов умещающихся во времени жизни вселенной» или даже «повторить большее число раз чем умещается во времени жизни вычислительной системы». Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это был экспериментальный язык. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные. По этой причине я думаю ленивость хаскеля нужно рассматривать как недостаток.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это был экспериментальный язык. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные. По этой причине я думаю ленивость хаскеля нужно рассматривать как недостаток.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это был экспериментальный язык. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные. По этой причине я рассматриваю это как недостаток.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это был экспериментальный язык. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

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

И да, возвращаясь к теме ленивости, ещё раз: она просто не оттуда. Хаскель не был практическим языком, это бы эксперимент. И они решили «а пусть всё будет ленивым». И да, это было очень круто, поглядеть как это будет. Ну так вот, теперь мы знаем - ленивость нужна только там где нужна. А в остальных случаях удобнее если вычисления энергичные.

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчк или опытного таки надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

Хотя производительность труда вероятно выше на хаскеле (моя гипотеза).

Любой полный по Тьюрингу язык подходит для любой задачи :)

Хочется упомянуть что слышал в лекциях Москвина (в интернете) мысль, которая так проста что даже обидно стало когда я её услышал (потому что сам недотумкал), так что вот: в промежутке между тьюринг-неполными ЯП (но пакман-полными по меткому выраженю Бреди, который автор Idris) и тьюринг-полными ИНТЕРЕСНЫХ ПРОГРАММ НЕТ. Т.е. по сути нет никакой разницы с т.з. практических возможностей между языками которые ТП и неТП. Живите теперь с этим.

а графические приложения не особо хорошо. получается громоздко и не очень наглядно.

Ну, смотря с чем сравнивать. Скажем в ООП много что получается громоздко и ненаглядно да ещё и чётри как запутано из-за наследования. И это не просто трудно, а очень трудно сопровождать, особенно если написано не слишком опытным человеком (среднего опыта явно недостаточно). Но большинство оопшников ничего, делают это. Так что надуманная проблема, по моему.

По моему, настоящая проблема - это порог вхождения. Штука в том что с ООП может работать и опытный и малоопытный человек: он просто городит иерархию классов, которая компилируется и вроде бы работает. Но как только это доходит до использования, вот тут и выясняется опытный был разработчки или опытного надо искать.

А с ФП типизированным вроде хаскеля ситуация такая: 1) ты его хрен напишешь 2) оно не скомпилируется. Ну и многие просто убегают обратно в ООП, потому что «там бы уже работало» (хотя это большой вопрос что бы у него там работало).

Хотя производительность труда вероятно выше на хаскеле (моя гипотеза).