Выбор языка программирования

[bin]

Maslov в сообщении #520027 писал(а):

Вы уверены, что Ваше интуитивное представление совпадает, например, с моим? :)

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

Maslov в сообщении #520027 писал(а):

В Паскале есть указатели -- не самая простая концепция для понимания непрофессионалом.

ИМХО достаточно простая. Я за 1/2 лекции объяснял так, что понимали

Maslov в сообщении #520027 писал(а):

Кроме того, я думаю, имеет смысл различать краткость описания языка и простоту написания программ на этом языке.

Согласен. Можно предложить много критериев.

Maslov в сообщении #520027 писал(а):

Бессмысленно говорить о "наилучшем" языке, до тех пор пока не определен класс задач, которые с помощью этого языка предполагается решать.

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

Maslov в сообщении #520027 писал(а):

Вы считаете, основная проблема в "ненадежности" языка? На мой взгляд, главная причина -- кривые или криво реализованные протоколы обмена и алгоритмы управления; ну и, конечно, постоянно растущая сложность задач.

"Кривые или криво реализованные протоколы и алгоритмы" - это та же проблема надежности, только другими словами. Кривые протоколы и алгоритмы - это плохая теоретическая проработка, т.е. ненадежная. А если протокол/алгоритм надежный, то его кривая реализация очень часто происходит от неоднозначностей в языке. Сложность задач - отдельная тема, но ИМХО задачи усложняются медленнее, чем прибавляется возможностей (по быстродействию, по памяти, по технологиям отладки и т.д.).

[arseniiv]

(Оффтоп)

bin в сообщении #520383 писал(а):

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

[nestoklon]

Maslov в сообщении #520185 писал(а):

Программу на Питоне легче запустить, но труднее отлаживать и модифицировать (из-за отсутствия строгой типизации)

Самый смех в том, что в питоне как раз строгая типизация.

[Maslov]

nestoklon в сообщении #520407 писал(а):

Самый смех в том, что в питоне как раз строгая типизация.

Разные авторы вкладывают в понятие "строгая типизация" разный смысл. Гвидо ван Россум (создатель и главные идеолог Питона) относит Питон к языкам с runtime-типизацией, противопоставляя такой тип типизации как строгой (сильной), так и слабой. Вот здесь можно почитать подробнее: Strong versus Weak Typing.

Цитата:

Summary
Python creator Guido van Rossum talks with Bill Venners about the robustness of systems built with strongly and weakly typed languages, the value of testing, and whether he'd fly on an all-Python plane.
...
Weak typing is not really a fair description of what's going on in Python. It's really runtime typing because every object is labeled with a type.
...
In a strongly typed language, when you change to a different data structure, you will likely have to change the argument and return types of many methods that just pass these things on. You may also have to change the number of arguments, because suddenly you pass the information as two or three parts instead of one. In Python, if you change the type of something, most likely pieces of code that only pass that something around and don't use it directly don't have to change at all.

[Maslov]

bin в сообщении #520383 писал(а):

ИМХО достаточно простая. Я за 1/2 лекции объяснял так, что понимали

Ну что ж, Вашим слушателям повезло с преподавателем. Тем не менее, на мой взгляд, человеку, не имеющему представления об архитектуре процессора, понять идею указателей не очень просто.

bin в сообщении #520383 писал(а):

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

На Java и C# не решается задача написания драйвера, работающего в режиме ядра, на C и Паскале "сильно хуже" решаются задачи написания web-приложений. Отнесем эти языки к специализированным?

bin в сообщении #520383 писал(а):

"Кривые или криво реализованные протоколы и алгоритмы" - это та же проблема надежности, только другими словами. Кривые протоколы и алгоритмы - это плохая теоретическая проработка, т.е. ненадежная

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

bin в сообщении #520383 писал(а):

А если протокол/алгоритм надежный, то его кривая реализация очень часто происходит от неоднозначностей в языке.

А еще чаще она происходит от недостатка у разработчиков знаний и опыта, а также от ошибок в организации процесса (например, в недооценки сроков или необходимого бюджета, недостаточном тестировании и т. п.).

[nestoklon]

Maslov в сообщении #520446 писал(а):

Разные авторы вкладывают в понятие "строгая типизация" разный смысл.

На данный момент насколько мне известно принято различать строгую/нестрогую и отдельно статическую/динамическую типизацию. Питон -- типичнейший язык со строгой и динамической типизацией.

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

[Maslov]

nestoklon в сообщении #520536 писал(а):

я первый раз вижу мнение о том что питон плохо подходит для "отлаживания и модификации"

Я этого не писал. "Труднее" не означает "плохо подходит".

nestoklon в сообщении #520536 писал(а):

простота отлаживания и модификации считается одним из его главных достоинств

Я написал, почему, на мой взгляд, отладка и модификация программ на скриптовых языках сложнее, чем на языках со статической типизацией:

Maslov в сообщении #520200 писал(а):

Программы на скриптовых языках с динамической типизацией проще откомпилировать, но труднее заставить работать правильно: большинство ошибок, связанных с неправильной типизацией, "строгие" языки выловят на стадии компиляции, а динамические -- только на стадии выполнения. Чем больше информации о наших данных мы сообщим компилятору, тем больше наших ошибок он сможет найти.
Примерно та же ситуация с модификацией уже написанных программ и с попытками разобраться в функционировании кода, полученного со стороны (или просто написанного несколько месяцев назад :)): глядя на функцию на Delphi, Java, C++ или C# можно, по крайней мере, понять, что за данные она принимает на входе и что выдает на выходе; для скриптовых языков эта информация недоступна.

В чем, по Вашему мнению, заключаются преимущества Питона с точки зрения простоты отладки и модификации по сравнению с такими языками, как Java или C#?

[bin]

Maslov в сообщении #520480 писал(а):

на C и Паскале "сильно хуже" решаются задачи написания web-приложений.

На Delphi (=ОО Паскаль) задачи написания web-приложений хорошо решаются.

Maslov в сообщении #520480 писал(а):

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

Да, другими средствами. Хороший язык программирования - необходимое, но недостаточное условие успешного проекта.

Maslov в сообщении #520480 писал(а):

А еще чаще она происходит от недостатка у разработчиков знаний и опыта, а также от ошибок в организации процесса (например, в недооценки сроков или необходимого бюджета, недостаточное тестирование и т. п.).

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

[nestoklon]

Maslov в сообщении #520555 писал(а):

В чем, по Вашему мнению, заключаются преимущества Питона с точки зрения простоты отладки и модификации по сравнению с такими языками, как Java или C#?

По моему мнению, с этой точки зрения у него нет недостатков. Вы точно так же узнаете об ошибке типизации, только чуть позже. Учитывая что этап компиляции просто пропускается, это "позже" реально может быть даже "раньше".
Для маньяков и по-настоящему критичных приложений (хотя питон для этого не самый лучший выбор) есть некоторое количество анализаторов кода. Вот например.

Maslov в сообщении #520555 писал(а):

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

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

[Maslov]

nestoklon в сообщении #520565 писал(а):

Вы точно так же узнаете об ошибке типизации, только чуть позже. Учитывая что этап компиляции просто пропускается, это "позже" реально может быть даже "раньше".

Чуть позже это произойдет только для простых программ или программ со 100-процентным покрытием автоматическими тестами; в других случаях это может произойти существенно позже.

Идея о том, что ошибки, выявляемые на стадии компиляции, существенно дешевле ошибок, выявляемых на стадии выполнения -- это в программной инженерии почти аксиома.

[nestoklon]

Maslov в сообщении #520577 писал(а):

Идея о том, что ошибки, выявляемые на стадии компиляции, существенно дешевле ошибок, выявляемых на стадии выполнения -- это в программной инженерии почти аксиома.

Ну так и используйте анализаторы кода для критических задач. Целиком перекладывать задачу типизации на человека вовсе не обязательно. Лет 20 назад вариантов не было. Теперь есть.
Ну и не стоит конечно писать операционные системы на питоне.

[Maslov]

bin в сообщении #520563 писал(а):

На Delphi (=ОО Паскаль) задачи написания web-приложений хорошо решаются.

Хорошо по сравнению с чем?
Для Delphi есть какие-нибудь развитые фрейворки типа JSP, ASP.NET, Zend, RoR, Django?
Чтобы сейчас писать веб-приложение на C или Delphi, надо фанатом быть (или работать в условиях очень жестких ограничений на выбор программных средств).

[Nimza]

Maslov в сообщении #520480 писал(а):

Ну что ж, Вашим слушателям повезло с преподавателем. Тем не менее, на мой взгляд, человеку, не имеющему представления об архитектуре процессора, понять идею указателей не очень просто.

А почему нельзя разбить курс, скажем, на две части и вкрапить между частями архитектуру ЭВМ и ассемблер? У нас например (если я ничего не путаю), сначала рассказывают паскаль без указателей, потом архитектуру и ассемблер, а потом С по полной программе и т.д. По-моему, неплохой вариант.

[Maslov]

Nimza в сообщении #521581 писал(а):

А почему нельзя разбить курс, скажем, на две части и вкрапить между частями архитектуру ЭВМ и ассемблер?

Исходный вопрос был не о построении курса преподавания/изучения программирования, а о том

Alec в сообщении #476729 писал(а):

какой из языков программирования наиболее прост для программирования непрофессионалами

Не думаю, что Паскаль-С-Ассемблер является в таком контексте правильным выбором.

[bin]

Maslov в сообщении #521377 писал(а):

bin в сообщении #520563 писал(а):

На Delphi (=ОО Паскаль) задачи написания web-приложений хорошо решаются.

Хорошо по сравнению с чем?
Для Delphi есть какие-нибудь развитые фрейворки типа JSP, ASP.NET, Zend, RoR, Django?
Чтобы сейчас писать веб-приложение на C или Delphi, надо фанатом быть (или работать в условиях очень жестких ограничений на выбор программных средств).

В настоящее время я не занимаюсь разработкой web-приложений и сужу по общему спросу на разработку таких приложений средствами Delphi, а так же по публикациям. И того и другого в избытке, а, значит, если и есть что-то лучше, то Delphi не сильно хуже

В целом же ИМХО Инет и WWW очень заметно регрессируют. Я не в восторге от нынешних фрейворков и еще боле не в восторге от того, как их используют, но это другая тема.

-- Пт дек 30, 2011 22:13:47 --

Nimza в сообщении #521581 писал(а):

Maslov в сообщении #520480 писал(а):

Ну что ж, Вашим слушателям повезло с преподавателем. Тем не менее, на мой взгляд, человеку, не имеющему представления об архитектуре процессора, понять идею указателей не очень просто.

А почему нельзя разбить курс, скажем, на две части и вкрапить между частями архитектуру ЭВМ и ассемблер? У нас например (если я ничего не путаю), сначала рассказывают паскаль без указателей, потом архитектуру и ассемблер, а потом С по полной программе и т.д. По-моему, неплохой вариант.

ИМХО можно, но только для того, чтобы понять идею указателей не надо в деталях изучать архитектуру (достаточно очень поверхностного представления на школьном уровне). См., нпр., зарекомендовавший себя учебник П.Грогоно, Программирование на языке Паскаль, М.:Мир, 1982.