C, Basic, Pascal - как проблемы в будущем.
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
C, Basic, Pascal - как проблемы в будущем. - 2009-01-09 19:30:49.750000
|
|
|
xfizer
Сообщений: 39
Оценки: 0
Присоединился: 2009-01-08 21:46:14.423333
|
В последнее время я начал больше замечать тем про выбор языков программирования.
Ну и действительно, Basic - язык сильно привязанный к Windows? речи о его
переносимости и быть тут не может.
Порой мне кажется что мелкомягкие готовят выпустить систему, которая не будет
поддерживать многие языки программирования, включая уже существующие Visual C++
или Delphi… Но это является сдествием того, что многие, даже подавляющее
колличество программистов останутся не у дел?
Но тогда какой выход? Какой язык надо выучить, и оттачивать навыки использования
несколько лет, а порой и пол жизни, что-бы не работать разносчиком пищи, или же
официантом?
Например мне 16, я, знаю язык Pascal. Но пока что плохо различаю способности языков С, С++,
С#. Какой из них выбрать не в ущерб себе. С# намертво привязан к платформе .Net,
но это опять же, поделка от мелкомягких, а я не очень им доверяю, кинут и все.
Я хочу быть программистом, как быть?
Какие у вас есть убеждения?
Что думаете по этому поводу?
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-09 19:31:12.806666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: xfizer
В последнее время я начал больше замечать тем про выбор языков программирования.
Ну и действительно, Basic - язык сильно привязанный к Windows? речи о его
переносимости и быть тут не может.
http://gambas.sourceforge.net/
quote:
ORIGINAL: xfizer
Порой мне кажется что мелкомягкие готовят выпустить систему, которая не будеть
поддерживать многие языки программирования, включая уже существующие Visual C++
или Delphi…
ты себе это как вообще представляешь?
quote:
ORIGINAL: xfizer
Но это является сдествием того, что многие, даже подавляющее
колличество программистов останутся не у дел?
следствием или причиной? впрочем, ни тем ни тем оно не является
quote:
ORIGINAL: xfizer
Но тогда какой выход? Какой язык надо выучить, и оттачивать навыки использования
несколько лет, а порой и пол жизни, что-бы не работать разносчиком пищи, или же
официантом?
"оттачивать навыки использования полжизни" можно только в случае перенесённой черепно-мозговой травмы. или врождённого убожества мысли
любой программист должен уметь пользоваться двумя вещами - указателями и рекурсией; соответственно должен знать C и LISP
кроме базового вычислителя (машина Тьюринга, машина Чёрча, etc) между различными ЯП не такая уж и большая разница
quote:
ORIGINAL: xfizer
Например мне 16, я, знаю язык Pascal(ну и чуть-чуть ассемблер(MASM)). Но пока что плохо раличаю языки С, С++,
С#. Какой из них выбрать не в ущерб себе.
а зачем ты ограничиваешь свой выбор именно этими языками?
quote:
ORIGINAL: xfizer
С# намертво привязан к платформе .Net,
C# - язык с открытой и стандартизованной спецификацией. см. Mono, Gtk#
quote:
ORIGINAL: xfizer
Я хочу быть программистом, как быть?
Какие у вас есть убеждения?
Что думаете по этому поводу?
http://www.htdp.org/
http://mitpress.mit.edu/sicp/full-text/book/book.html
http://www.ozon.ru/context/detail/id/3249412/
http://www.ozon.ru/context/detail/id/1335648/
http://www.ozon.ru/context/detail/id/2527041/
http://www.ozon.ru/context/detail/id/2527036/
http://www.ozon.ru/context/detail/id/2429691/
http://www.ozon.ru/context/detail/id/3829076/
http://www.ozon.ru/context/detail/id/2355879/
это базовый набор, по освоению которого без работы ты не останешься
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-09 21:14:48.066666
|
|
|
xfizer
Сообщений: 39
Оценки: 0
Присоединился: 2009-01-08 21:46:14.423333
|
quote:
ORIGINAL: xfizer
Порой мне кажется что мелкомягкие готовят выпустить систему, которая не будеть
поддерживать многие языки программирования, включая уже существующие Visual C++
или Delphi…
ты себе это как вообще представляешь?
———————————————————
Читал когда-то новость, якобы мелкософт выпустит новую ОС, по-моему cloud, там было написанно, мол у нее не буде совместимости с предыдущими версиями ОС семейства windows…
———————————————————
quote:
ORIGINAL: xfizer
Например мне 16, я, знаю язык Pascal(ну и чуть-чуть ассемблер(MASM)). Но пока что плохо раличаю языки С, С++,
С#. Какой из них выбрать не в ущерб себе.
а зачем ты ограничиваешь свой выбор именно этими языками?
———————————————————
Вообще я считал, что С наиболее приемлемый язык, он кросс платформенный, я думаю у него "отличное будущее" так сказать…
А какие ЯП вы предлагаете, и в чем их достоинства?
———————————————————
Спасибо за исчепывающий ответ, за литературу тоже.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 01:57:21.450000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: xfizer
Читал когда-то новость, якобы мелкософт выпустит новую ОС, по-моему cloud, там было написанно, мол у нее не буде совместимости с предыдущими версиями ОС семейства windows…
и какое это имеет отношение к ЯП? исключительно вопрос реализации, причём прежде всего - стандартной библиотеки
quote:
ORIGINAL: xfizer
Вообще я считал, что С наиболее приемлемый язык, он кросс платформенный, я думаю у него "отличное будущее" так сказать…
C не кроссплатформенный, он переносимый. переносимый ассемблер, у которого очень немного жизнеспособных конкурентов; из интересных рекомендую посмотреть на Cyclone и BitC:
http://cyclone.thelanguage.org/
http://www.bitc-lang.org/
у D тоже неплохая поддержка низкоуровневого программирования, однако сам язык существенно сложней:
http://www.digitalmars.com/d/index.html
quote:
ORIGINAL: xfizer
А какие ЯП вы предлагаете, и в чем их достоинства?
для чего? если для обучения, то Scheme. ссылки на HTDP и SICP я там выше давал
а в общем случае зависит от задачи. универсальных ЯП нет, есть только ЯП общего назначения
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 15:05:41.770000
|
|
|
NightmareZz
Сообщений: 1087
Оценки: 0
Присоединился: 2006-10-15 11:16:16.833333
|
quote:
ORIGINAL: Denaturat
quote:
ORIGINAL: xfizer
Читал когда-то новость, якобы мелкософт выпустит новую ОС, по-моему cloud, там было написанно, мол у нее не буде совместимости с предыдущими версиями ОС семейства windows…
и какое это имеет отношение к ЯП? исключительно вопрос реализации, причём прежде всего - стандартной библиотеки
Такое, что ЯП не существует в неком астрале, не взаимодействуя с реальным миром. ЯП не некая абстракция, а реально существующая вещь (в виде компилятора, редактора, IDE, библиотек). И, если вдруг появится ось, не совместимая с уже существующими, то прийдётся это всё заново переделывать.
quote:
ORIGINAL: Denaturat
quote:
ORIGINAL: xfizer
Вообще я считал, что С наиболее приемлемый язык, он кросс платформенный, я думаю у него "отличное будущее" так сказать…
C не кроссплатформенный, он переносимый. переносимый ассемблер, у которого очень немного жизнеспособных конкурентов; из интересных рекомендую посмотреть на Cyclone и BitC:
Что значит "не кроссплатформенный"? Реализации на разных платформах есть? Значит кроссплатформенный.
Про "переносимый ассемблер" пургу нести не надо.
quote:
ORIGINAL: Denaturat
quote:
ORIGINAL: xfizer
А какие ЯП вы предлагаете, и в чем их достоинства?
для чего? если для обучения, то Scheme. ссылки на HTDP и SICP я там выше давал
а в общем случае зависит от задачи. универсальных ЯП нет, есть только ЯП общего назначения
Ну вот сам и пиши на Схеме.
Я не спорю, что язык хороший…… для расширения сознания и придания гибкости уму. Но на практике - нифига не применимый (во всяком случае, пока не будет нормальной реализации, IDE к нему, кучи библотек, поддержки со стороны крупных software-контор).
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 15:15:47.490000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: NightmareZz
Такое, что ЯП не существует в неком астрале, не взаимодействуя с реальным миром. ЯП не некая абстракция, а реально существующая вещь (в виде компилятора, редактора, IDE, библиотек). И, если вдруг появится ось, не совместимая с уже существующими, то прийдётся это всё заново переделывать.
тебе ещё здесь написать, что хороший ЯП от IDE зависеть не должен? а сменить компилятору кодогенератор (с учётом наличия различных реализаций BURS) как бы не проблема. портирование библиотек необходимо только в случае их платформо-зависимости: скажем, boost портировать практически не придётся,- на систему он мало завязан
и опять же, какое отношение наличие софта/библиотек имеет к применимости ЯП в системе? или портирование библиотек - неразрешимая задача? или никогда раньше этого не происходило? или это не происходит вообще постоянно?
и напоследок - ты правда считаешь бизнес-отдел M$ кретинами, не учитывающими влияние legacy?
quote:
ORIGINAL: NightmareZz
Что значит "не кроссплатформенный"? Реализации на разных платформах есть? Значит кроссплатформенный.
код на C99, который без изменений можно скомпилировать в многопоточный сокет-сервер на Win32, Linux и, скажем, vxWorks - в студию. наличие компиляторов под различные платформы - это переносимость, но не кроссплатформенность - ибо исходники для каждой платформы будут свои. уровень абстракции не тот, чтобы говорить о кросс-платформенности
quote:
ORIGINAL: NightmareZz
Про "переносимый ассемблер" пургу нести не надо.
а по существу есть что возразить? нет? свободен
quote:
ORIGINAL: NightmareZz
Ну вот сам и пиши на Схеме.
ты читать умеешь? я написал для обучения. хотя писать на схеме, должен заметить, куда приятней чем, скажем, на Java. а писать компиляторы схемы под необходимую платформу - вообще удовольствие
quote:
ORIGINAL: NightmareZz
Я не спорю, что язык хороший…… для расширения сознания и придания гибкости уму. Но на практике - нифига не применимый (во всяком случае, пока не будет нормальной реализации, IDE к нему, кучи библотек, поддержки со стороны крупных software-контор).
ты пришёл расписаться в собственной некомпетентности? жаль, я считал тебя умнее
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 15:29:09.493333
|
|
|
NightmareZz
Сообщений: 1087
Оценки: 0
Присоединился: 2006-10-15 11:16:16.833333
|
quote:
ORIGINAL: Denaturat
тебе ещё здесь написать, что хороший ЯП от IDE зависеть не должен?
Кто тебе такую глупость то сказал? Может ещё и обоснуешь?
quote:
ORIGINAL: Denaturat
а сменить компилятору кодогенератор (с учётом наличия различных реализаций BURS) как бы не проблема.
Да ну? Так вот просто. Взял и портировал. Mono вон сколько времени мусолят. Видать, потому что легко, да?
quote:
ORIGINAL: Denaturat
портирование библиотек необходимо только в случае их платформо-зависимости: скажем, boost портировать практически не придётся,- на систему он мало завязан
Портировать библиотеки, завязанные, например, на WinAPI легко портировать под MacOS?
quote:
ORIGINAL: Denaturat
и опять же, какое отношение наличие софта/библиотек имеет к применимости ЯП в системе? или портирование библиотек - неразрешимая задача? или никогда раньше этого не происходило? или это не происходит вообще постоянно?
Задача то разрешимая, только требующая вложений. Иногда больших. Иногда очень.
quote:
ORIGINAL: Denaturat
и напоследок - ты правда считаешь бизнес-отдел M$ кретинами, не учитывающими влияние legacy?
Я где-то такое разве писал? Нет. Значит неправда.
quote:
ORIGINAL: Denaturat
код на C99, который без изменений можно скомпилировать в многопоточный сокет-сервер на Win32, Linux и, скажем, vxWorks - в студию.
А что ещё сделать? Мож тебе ось на нём написать, чтобы ты убедился? Плати - напишу.
quote:
ORIGINAL: Denaturat
наличие компиляторов под различные платформы - это переносимость, но не кроссплатформенность - ибо исходники для каждой платформы будут свои. уровень абстракции не тот, чтобы говорить о кросс-платформенности
Определение кроссплатформенности в студию. (В твоём понимании). Потом сравним его с общепринятым.
quote:
ORIGINAL: Denaturat
а по существу есть что возразить? нет? свободен
Лолшто? Сама встала и вышла. Оно мне ещё приказывать будет.
quote:
ORIGINAL: Denaturat
ты читать умеешь? я написал для обучения. хотя писать на схеме, должен заметить, куда приятней чем, скажем, на Java. а писать компиляторы схемы под необходимую платформу - вообще удовольствие
Много на схеме уже понаписывал? Покажешь народу?
quote:
ORIGINAL: Denaturat
ты пришёл расписаться в собственной некомпетентности? жаль, я считал тебя умнее
Да мне как-то до одного места, что ты там считаешь ;)
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 15:42:22.386666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: NightmareZz
Кто тебе такую глупость то сказал? Может ещё и обоснуешь?
это очевидная мысль для любого сколько-нибудь вменяемого инженера. хорошему инструменту костыли не нужны. примеры таких инструментов я тебе уже привёл
quote:
ORIGINAL: NightmareZz
Да ну? Так вот просто. Взял и портировал. Mono вон сколько времени мусолят. Видать, потому что легко, да?
а ты на исходники кодогенератора GCC посмотри, да? ничего в глаза не бросается?
и - да, несложно. я тебе там BURS не просто так упомянул, почитал бы хоть - для общего развития
quote:
ORIGINAL: NightmareZz
Портировать библиотеки, завязанные, например, на WinAPI легко портировать под MacOS?
с учётом формальной POSIX-совместимости обоих систем - процесс ресурсоёмкий, но не сложный
quote:
ORIGINAL: NightmareZz
Задача то разрешимая, только требующая вложений. Иногда больших. Иногда очень.
и что? любая интересная задача требует вложений. иногда больших. иногда очень. но если задача выбрана хорошо, то эти вложения окупаются. в случае с M$ я не склонен считать, что они не стремятся заработать денег
quote:
ORIGINAL: NightmareZz
А что ещё сделать? Мож тебе ось на нём написать, чтобы ты убедился? Плати - напишу.
извини, ты идиот? я даю тебе простой и показательный пример. на кроссплатформенном языке код для многопоточного сокет-сервера будет один для всех платформ. на C это невозможно. в этом, ядрёна вошь, и заключается разница между переносимым и кросс-платформенным ЯП. уровень абстракции
quote:
ORIGINAL: NightmareZz
Определение кроссплатформенности в студию. (В твоём понимании). Потом сравним его с общепринятым.
один и тот же исходный код без изменений должен компилироваться на различных платформах для хотя бы 90% востребованых задач
quote:
ORIGINAL: NightmareZz
Много на схеме уже понаписывал? Покажешь народу?
да что ты, что ты. я вообще начинающий, пару месяцев за компом. учусь только
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 16:24:47.986666
|
|
|
Popobawa
Сообщений: 6
Оценки: 0
Присоединился: 2008-11-09 00:05:16.450000
|
quote:
ORIGINAL: NightmareZz
Такое, что ЯП не существует в неком астрале, не взаимодействуя с реальным миром.
Опять путаем ЯП и его реализацию? Да я смотрю ты – быдло.
quote:
ORIGINAL: NightmareZz
редактора, IDE, библиотек). И, если вдруг появится ось, не совместимая с уже существующими, то прийдётся это всё заново переделывать.
Так и пишем, кросс-компиляцию не осилил.
quote:
ORIGINAL: NightmareZz
Что значит "не кроссплатформенный"? Реализации на разных платформах есть? Значит кроссплатформенный.
Про "переносимый ассемблер" пургу нести не надо.
Пургу тут несёшь ты. Марш в википедию! Cross-platform Portability
quote:
ORIGINAL: NightmareZz
Ну вот сам и пиши на Схеме.
Пишу (хотя больше на CL).
quote:
ORIGINAL: NightmareZz
Но на практике - нифига не применимый (во всяком случае, пока не будет нормальной реализации
Чем mz-scheme не нормальный? Или любой из ещё десятков? Как раз для схемы реализаций как собак нерезаных. Пернул в лужу и доволен?
quote:
ORIGINAL: NightmareZz
IDE к нему,
Быдло без IDE не может? по опыту – Emacs + SLIME хватает за глаза.
quote:
ORIGINAL: NightmareZz
кучи библотек,
Чего не хватает? И что мешает использовать библиотеки, написанные на других языках? А, ну да, быдло же о FFI не знает…
quote:
ORIGINAL: NightmareZz
поддержки со стороны крупных software-контор).
Раб не может без господина?
Ты толст и уныл, как и всё быдло.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 20:10:43.686666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
ЯП при изучении программирования вторичен. Только нужно выбрать такой, чтоб не отвлекал второстепенными деталями и демонстрировал основные аспекты построения программ (от него зависящие).
Рекомендую книжки (правда, в 16 лет, возможно, будет сложно читать):
Н. Вирт Систематическое программирование. Введение;
Д. Грис Наука программирования.
Имею мнение, что каждый приличный программист должен быть знаком с обсуждаемыми там вопросами. К тому же, раз знаешь Паскаль, дополнительных трудностей не возникнет - повествование в книгах идет на паскале. Главное, научишься циклы писать. :D
Насчет языка. Паскаль устарел 30 лет назад. Но у него есть достойные потомки - Модула-2 и Оберон. Оберон - объективно самый лучший язык, на основе которого можно изучать программирование, как "в малом" (алгоритмизация), так и "в большом" (архитектура программ).
Да, и главное: Информатика-21. Важный момент: О дисциплине программирования.
Для контуженных Си-языками:
Сравнение эффективности программ на Компонентном Паскале и на C ,
Как возник проект Информатика-21 и там по ссылкам тоже много интересного.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-10 21:57:45.646666
|
|
|
xfizer
Сообщений: 39
Оценки: 0
Присоединился: 2009-01-08 21:46:14.423333
|
Спасибо за ценную информацию, сейчас попробую все переварить(я про Информатика-21, О дисциплине программирования. ) Завтра попробую отписаться, по-моему у меня масса вопросов будет…
Всем спасибо за внимание. В том числе, Denaturat, NightmareZz, Popobawa, linuxoid.
Тема получилась объемная, надеюсь она будет еще больше. В моем возрасте, каждое ваше мнение - огромная ценность.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 13:56:26.966666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
ЯП при изучении программирования вторичен. Только нужно выбрать такой, чтоб не отвлекал второстепенными деталями и демонстрировал основные аспекты построения программ (от него зависящие).
рекурсию, например. и свойство замыкания
нефиг врать, ну
quote:
ORIGINAL: linuxoid
Оберон - объективно самый лучший язык, на основе которого можно изучать программирование, как "в малом" (алгоритмизация), так и "в большом" (архитектура программ).
субъективно, твою ж дивизию, субъективно. оберон не поможет тебе ни с ФП, ни с теорией типов, ни с метапрограммированием
quote:
ORIGINAL: linuxoid
Для контуженных Си-языками:
…от контуженных Pacal-языками
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 15:33:39.300000
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
quote:
рекурсию, например. и свойство замыкания
нефиг врать, ну
Ничего не понял.
quote:
субъективно, твою ж дивизию, субъективно. оберон не поможет тебе ни с ФП, ни с теорией типов
Ну и зачем начинать обучение с ФП? Оно эффективно в специфических задачах, никак не универсально. Недостаток в том, что ФЯ долеки и от компьютера и от человека - со всеми вытекающими (надеюсь, понял меня :)). Если я все же не прав, что вполне допускаю, то поправь и объясни, если не трудно.
quote:
ни с метапрограммированием
[смеется]
Не знаешь ты, похоже, ни языка, ни оберон-систем. ;) Уж извиняй.
quote:
…от контуженных Pacal-языками
Ну сделай милость, проведи разбор полетов. Поведай нам, дорогой друг, где Истина и где контуженность.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 15:48:29.103333
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
http://www.inr.ac.ru/~info21/qna.htm:
quote:
…
Но во всяком случае можно выяснить, в каком отношении стоят Оберон/Компонентный Паскаль к ФЯ. Вот суть:
Когда мы пишем a := b + c*d, то не озабачиваемся тем, где будет храниться промежуточный результат умножения c*d. Чистые ФЯ распространяют этот принцип на всю программу, т.е. оставляют (скрытое) присваивание лишь в одном месте — при назначении фактических параметров. Все остальные прелести ФЯ — либо вторичны к этому (например, возможность параллельного вычисления разных фактических аргументов, гарантированно "развязанных" по памяти), либо, строго говоря, не специфичны для ФЯ (как автоматическое распознавание типов, которое, кстати говоря, иногда приводит к тяжелейшим ошибкам; здесь как раз полезна избыточность, вводимая явным описанием типов переменных, — не говоря про большое упрощение компилятора со всеми вытекающими долгосрочными последствиями).
Можно пояснить и так. Строгая статическая типизация Оберонов — это запрет программисту решать, какие данные можно записать в ячейку памяти по такому-то адресу. Запрет следующего уровня, вводимый чистыми ФЯ, — это запрет программисту вообще выбирать ячейку, в которую будет записан результат. (Впрочем, некорректные присваивания в императивных языках имеют аналог и в ФЯ: если у функции, например, два целых параметра, то программист запросто может их перепутать.) Запрет "ручного" управления динамической памятью в Обероне, например, есть запрет ровно той же категории. В эту же сторону работают и настоящая модульность с упрятыванием глобальных переменных. Поэтому можно говорить о синтетической, императивно-функциональной природе Оберона, хотя и с подчеркиванием императивного аспекта (что согласуется с реальными механизмами работы реального "железа").
Но и практически применяемые ФЯ — вынуждены быть синтетическими, с переменными и присваиваниями: состояние окошка на экране, в котором меняется текст при нажатии клавиш — это не что иное как переменная, в которой меняется хранимое значение после каждого нажатия, и избежать этого понятия в такой ситуации невозможно. А введение переменных тянет за собой весь хвост соответствующих проблем. За что же боролись?
Локализуйте присваивания в фабричных функциях в Обероне, собранных в отдельные модули, запретите их во всех других местах, и вот вам ФЯ с полностью динамическими списками без принципиальных изъятий. Контролировать наличие в тексте модуля комбинации литер := не труднее, чем контролировать наличие комбинации литер SYSTEM в списке импорта.
Что касается автоматического распараллеливания, то это такого же уровня проблема, как автоматический синтез или верификация программ: обсуждать автоматическое распараллеливание умножений в a*b+c*d — неинтересно, а в реальных случаях все равно нужно сначала хорошо распараллелить алгоритм головой. Но тогда вся остальная организация распараллеливания в том же Обероне — отнюдь не квантовая гравитация.
Остаются, конечно, различия в "духе синтаксиса" между паскалеобразными языками и ФЯ. Но такие вещи вряд ли возможно оценивать объективно.
Вывод такой, что при обучении профессиональных программистов, несомненно, полезно в качестве обязательного второго взять какой-нибудь ФЯ (тот же Haskell; и еще марковский язык в качестве третьего — заметим попутно, что подавлюящее большинство профессиональных программистов затруднятся ответить, что такое "марковские языки").
…
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 18:16:54.643333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
Ничего не понял.
вот то-то и оно что не понял. если бы понимал - не писал бы чушь
quote:
ORIGINAL: linuxoid
Ну и зачем начинать обучение с ФП? Оно эффективно в специфических задачах, никак не универсально. Недостаток в том, что ФЯ долеки и от компьютера и от человека - со всеми вытекающими (надеюсь, понял меня :)). Если я все же не прав, что вполне допускаю, то поправь и объясни, если не трудно.
затем, что ФП ближе всего к математической (а значит - универсальной) записи задачи; хорошо поставленная задача отображается в исходники того же Haskell практически 1:1, в то время как на алголоподобных языках (включая и твой любимый Оберон) необходимо произвести мысленную трасляцию предметной области на область решений. термин таксономия области решений тебе ни о чём не говорит?
и - да, для того чтобы осилить деструктивное присваивание, нужно сломать мозг. бедным студизиусам вроде тебя его ломают, и после этого решать задачи просто они уже не могут. то, что АТД - это набор конструкторов и селекторов, а race conditions в параллельном программировании совсем не обязательны, такой поломанный мозг осилить уже не в состоянии. потому и пишут про "неприменимость", и упоённо решают очередную double-locking problem
и что значит не универсально? ни один ЯП не универсален, равно как и ни одна парадигма
quote:
ORIGINAL: linuxoid
Не знаешь ты, похоже, ни языка, ни оберон-систем. ;) Уж извиняй.
дать тебе для сравнения задачку на метапрограммирование и решение на CL? уверяю тебя, ты будешь сильно разочарован
quote:
ORIGINAL: linuxoid
Ну сделай милость, проведи разбор полетов. Поведай нам, дорогой друг, где Истина и где контуженность.
истина в том, что для вынесения подобных вердиктов следует иметь несколько больший уровень знаний, чем есть у тебя
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 18:18:26.743333
|
|
|
NightmareZz
Сообщений: 1087
Оценки: 0
Присоединился: 2006-10-15 11:16:16.833333
|
quote:
ORIGINAL: Denaturat
истина в том, что для вынесения подобных вердиктов следует иметь несколько больший уровень знаний, чем есть у тебя
Гений наш, а не пойти б тебе в пезду?
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 18:20:26.396666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
автор приведённой цитаты - идиот, кстати
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 18:23:28.273333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: NightmareZz
Гений наш, а не пойти б тебе в пезду?
о, а вот и наш физик, который пишет системы имитационного моделирования на Delphi и C#
и считает себя очень-очень умным при этом
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 19:01:27.066666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
Дружище Денатурат!
quote:
вот то-то и оно что не понял. если бы понимал - не писал бы чушь
Ты бы ту фразу с контекстом согласовал для начала. Вот поэтому и непонятно.
Остальное.
А если задачу нецелесообразно формулировать строго математически? Реальные, прикладные задачи не всегда хорошо формализуемы. Да и предметная область как правило ортогональна инструментальным средствам - необходимо строить слои абстракций, для любых ЯП.
Чему меня учат и какие задачи я решаю, тебе из погреба, конечно, виднее.
Кстати, есть эффективное системное, инструментальное или прикладное ПО на ФЯ? (это не подкол, просто мне такие проги не знакомы)
И последнее. Прежде чем вести дискуссию в таком тоне, представляй, что перед тобой Коля Валуев - дискуссия и попродуктивней будет, и поприятнее.
Да, насчет автора цитаты. Ненужно оскорблять незнакомого человека. Скорей всего он, все же, поумнее тебя будет, а так же поопытнее. Не надо самоуверенности.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 19:05:28.896666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
в твою сторону это был не наезд, не воспринимай в штыки
а об умственных способностях автора цитаты я сужу без перехода на личности - достаточно просто почитать что он пишет; это вообще хороший подход - говорить по существу независимо от
развёрнутый коммент напишу позже
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 19:08:50.510000
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
OK.
[в предвкушении потирает руки]
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-12 23:11:58.160000
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
Ммм, а вот это уже интересно. Выскажу своё маленькое мнение. Говорить, что лучше - Оберон или какой-либо из ФЯ, просто глупо. В Оксфорде (или в каком-то таком же крупной университете, точно не помню) первым языком изучают Хаскелл, вторым - Оберон. В MIT делают что-то подобное - Си и Лисп. Вряд ли можно говорить, что на каком-то императивном языке можно удобно писать в функциональном стиле, равно как и наоборот. Вирт сам в одной из последних своих статей писал, что хорошим стилем программирования сейчас должен стать функциональный. Но под функциональным он понимал отсутствие побочных эффектов у процедур. По сути, это действительно делает Оберон ближе к функциональным языкам, хотя и не предусматривает отказа от оператора присваивания. Но это не делает его функциональным языком: те достоинства, которые info21 (забыл, как его настоящее имя) приводит как несущественные, на самом деле значитиельно упрощают и ускоряют разработку, а те ухитрения, которые предлагаются для превращения Оберона в ФЯ выглядят грубыми и надуманными, а главное бессмысленными. Оберон - императивный, и переделывать его не вижу смысла.
Но и функциональные языки не идеальны. В целом задача гораздо проще формулируется через функцианальную парадигму: не нужно перекладывать задачу на переменные, циклы и т.д. В то же время, для ряда задач чистая функциональщина ну никак не подходит. Например, в Хаскелле для решения таких вопросов ввели заумное понятие монад, в то время, как в императивных языках это банальнейшие задачи. Модули в Хаскелле - вроде бы развитые, вроде бы даже довольно удобные, но они не могут хранить состояния, а значит программист опять лишается кучи возможностей (а как раз в Обероне, как в языке преимущественно модульного программирования, эти возможности реализуются просто и эффективно). Плюс функциональной парадигмы в более простой формулировке для большинства задач и более короткой записи (автоматический вывод типов, рекурсивная запись всегда короче итеративной и др.). Плюс чистой функциональной парадигмы только технический (распаралелливание и всё такое).
Так что сравнивать Оберон и ФЯ всё-таки некорректно - и у тех, и у других есть свои плюсы. Сейчас для большинства задач я предпочитаю функциональные языки, т.к. их преимущества мне нужны чаще, хотя это и не значит, что они лучше.
P. S. В Обероне метапрограммирование действительно поставлено неплохо, но сравнивать его с метапрограммирование м CL, с языком символьного программирования… Ну это всё равно, что сравнивать кухонный нож и пилу для отпиливания веток - пила для того и предназначена, в то время как нож просто даёт такую возможность, хотя и требует больших усилий.
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-13 13:53:25.390000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
Так вы про что? О том, какие языки нужно знать, чтобы зарабатывать денег, или о том, какие языки удобнее программисту? Если первое, то надо поискать в инете статистику – я никогда не искал, натыкался исключительно случайно, год назад самым популярным языком для зарабатывания денег была жаба.
Если же второе, то это сильно субъективно. Кто-то привязывается к IDE, как Найт. Мне плевать, я пользую emacs для всех языков, на которых пишу. И вообще я не знаю языка, который бы устроил меня в любой ситуации. Последнее время ограничиваюсь списком: C, lisp, ruby, bash. Ещё б найти время и разобраться как макросы в OpenOffice на ruby писать, и переписать весь мой VBA хлам из MSO… Тогда б я мог публично посрать на бейсик :)
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-13 14:25:11.196666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
Мы про то, на основе какого языка изучать программирование. Из императивных - оберон, однозначно (тут моя позиция тверда и непреклонна :D). Из функциональных - Денатурат яростно рекомендует Схему :D.
P. S. Но круче… Круче всех Рефал с Прологом!!! %)
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-13 14:41:46.660000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
P. S. Но круче… Круче всех Рефал с Прологом!!! %)
я бы на твоём месте смайлик тут не ставил: во-первых, паттерн-матчинг Рефала - пример для подражания, как надо проектировать ЯП; во-вторых, Prolog для dataflow-программирования в сложных системах - самое милое дело
впрочем, никто не мешает встроить свой Prolog в Haskell, или написать рефалоподобный паттерн-матчинг для CL. другое дело, что и в C#, и в Обероне сделать это будет очень и очень сложно
впрочем, можешь попытаться опровергнуть эту мысль, решив любую из поставленных задач :)
|
|
|
|
|
RE: C, Basic, Pascal - как проблемы в будущем. - 2009-01-13 14:45:02.560000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
Мы про то, на основе какого языка изучать программирование. Из императивных - оберон, однозначно (тут моя позиция тверда и непреклонна :D). Из функциональных - Денатурат яростно рекомендует Схему :D.
кстати в такой постановке я с тобой почти соглашусь. хотя для императивных я бы предложил два равноценных варианта - Оберон и Python
а про Scheme это не я придумал, это умные дяди из MIT. почему именно так - читай здесь:
http://en.wikipedia.org/wiki/Lambda_Papers
ссылка на сами статьи битая, но нагуглить не проблема
|
|
|
|
|
|
