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

Всем привет! С недавних пор я абитуриент и хочу поступить на программиста в колледж.
Я понимаю что в колледже кроме корочки я больше особо ничего не получу
И я хотел бы услышать совет от более опытных людей на каком языке программирования стоит сосредоточиться и учить его
Я знаю про питона/с++/visualc++/паскаль абс но я не знаю какой стоит учить.
Хочу услышать совет, Заранее спасибо!

0

Сообщение от Shamil1 К буму САПР привело появление персоналок и терминалов с графическим интерфейсом.

Персоналки появились в конце 70-х а не в начале 90-х

0

Сообщение от Fulcrum_013 Персоналки появились в конце 70-х а не в начале 90-х

К буму САПР привело не появление первого в мире персонального компьютера, а широкое распространение (доступность) персоналок. В России персональные компьютеры более-менее массово стали продаваться только в конце 80-ых. И использовались они в основном не для работы, а для отмывки бюджетных денег и получения отката с продавцов.
(Отдельные экземпляры, которые привозили и продавали иностранные студенты, не в счёт. Самодельные синклеры и их советские промышленные аналоги тоже не учитываем из-за слишком малой вычислительной мощности.)

0

Сообщение от Shamil1 К буму САПР привело не появление первого в мире персонального компьютера, а широкое распространение (доступность) персоналок.

Ну вот за буграми они широкое распространение получили в начале 80-х. При этом в КБ где САПР наиболее ввостребован графических теминаллов и т.д. было достаточно и в 70-е. А революция в САПР произошла ближе к середине 90-х. Конкретно в 93-ем с выходом первой SolidWorks которая имела ООП-архитектуру и за счет этого позволяла делать то что было недоступно раньше.
Фишка ООП именно в упрощении обработки полиморфных данных. В первую очередь в возможности приведения архитектуры в соответсвие с теорией принятия решений, когда решения принимает именно тот объект который обладает для этого достаточной полнотой данных. Именно для этого и нужно совмещение данных с обрабатывающим их кодом в одну сущность. При этом позволяет очень просто перестраивать иерархию объектов моделирующих ту или иную систему на лету.

Добавлено через 8 минут
А поскольку каждая сущность имеет строгое математическое описание, в том числе и строгие критерии возможности продолжения существования, то исчезает и необходимость в GC который проектировался для архаичного ФП, в котором нет никаких критериев времени жизни а соответственно полная каша в этом плане. При этом концепция владения в ООП перевернута на 180 градусов по отношению с ФП - здесь владелец ответственен за удаление, а не препятствует удалению. А соответственно при удалении объектов, задача обработки графа ссылок абсолютно противоположна той, которую решает GC.

0

Сообщение от Fulcrum_013 Ну вот за буграми они широкое распространение получили в начале 80-х.

IBM PC AT появились в 1986 году. Предшественники были скорее микрокомпьютерами (обычно использовали термин "бытовые компьютеры").

Добавлено через 2 минуты

Сообщение от Fulcrum_013 При этом концепция владения в ООП перевернута на 180 градусов по отношению с ФП

В ООП нет никакой "концепции владения".

0

Сообщение от Shamil1 IBM PC AT появились в 1986 году. Предшественники были скорее микрокомпьютерами (обычно использовали термин "бытовые компьютеры").

До них были PC XT а до них просто PC. Которые отличались разве что мощностью CPU и прочего бортового оборудования. Но графический адаптер имели все.

0

Сообщение от Fulcrum_013 в соответсвие с теорией принятия решений, когда решения принимает именно тот объект который обладает для этого достаточной полнотой данных

Одним из первых этапов является поиск информации. Источники информации никаких решений не принимают. Так что теорию принятия решений Вы не к месту упомянули.

0

Сообщение от Shamil1 В ООП нет никакой "концепции владения".

Есть отношение композиция которое соответствует именно владению или слабому владению объектом в зависимости от ситуации.

Добавлено через 1 минуту

Сообщение от Shamil1 Источники информации никаких решений не принимают.

А объекты в ООП не пассивные хранилища информации. Это именно активные сущности принимающие решения. В том числе и решения о том каким именно образом обрабатывать хранимую ими информацию.

0

Сообщение от Fulcrum_013 Есть отношение композиция которое соответствует именно владению или слабому владению объектом в зависимости от ситуации.

Композиция и ООП ортогональны. Возможно, ООП без композиции, возможна композиция без ООП.

Сообщение от Fulcrum_013 А объекты в ООП не пассивные хранилища информации. Это именно активные сущности принимающие решения.

Это зависит от замысла архитектора.

Сообщение от Fulcrum_013 В том числе и решения о том каким именно образом обрабатывать хранимую ими информацию.

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

0

Сообщение от Shamil1 Композиция и ООП ортогональны.

Вообще то в ООП существуют два типа взаимосвязей - композиция и агрегация. А то что они существуют где то еще это уже дело десятое.

Добавлено через 2 минуты

Сообщение от Shamil1 Это зависит от замысла архитектора.

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

Добавлено через 4 минуты

Сообщение от Shamil1 Если Вы считаете, что решение об изменении скорости автомобиля на перекрёстке должен принимать светофор, так как он лучше всех знает, какой свет на нём горит...

На самом деле это не важно. Принимает решение тот кто имеет для этого всю полноту данных. Если это светофор то пусть он и меряяет. Если это светофор во взаимодействи с машиной - то пусть они меряют. Важно не это. Важно то что никто кроме того или иного объекта не должен знать формат его данных и то как именно выполнять ту или иную команду по их обработке. Суть как раз в том что при обработке полиморфных данных всю полноту информации может иметь только хранилище оных данных, а соответственно только перенос активной части, осуществляющей непосредственную обработку, в само хранилище приводит систему в соответствие с теорией принятия решений.

0

Fulcrum_013, всё, отвечать не будете?

0

Сообщение от Usaga Но если такие члены есть, то деструктор генерируется, так ведь?

Он как бы есть для галочки но его вызов просто выбрасывается оптимизатором.

Сообщение от Usaga И где здесь аналогия с Dispose()?

Прямая. И деструктор и Dispose занимаются деинициализацией экземпляра класса.

Добавлено через 1 минуту

Сообщение от Usaga Инстанс - структура в памяти представляющая из себя объект.

Правильно.

Сообщение от Usaga Dispose() её вообще никак не трогает.

Вот как раз ее Dispose и деинициализирует. Т.е. высвобождает владеемые ресурсы и т.д. точно так же как деструктор. А не трогает он сам буфер опять же точно так же как деструктор.

0

Сообщение от Fulcrum_013 Он как бы есть для галочки но его вызов просто выбрасывается оптимизатором.

Так вообще нет или есть? Вы уже определитесь в своих показаниях.

Сообщение от Fulcrum_013 Прямая. И деструктор и Dispose занимаются деинициализацией экземпляра класса.

Нет. В Dispose() произвольная логика. Данного метода может и не быть вовсе. Ибо с деинициализацией данный метод не связан.

Сообщение от Fulcrum_013 Вот как раз ее Dispose и деинициализирует. Т.е. высвобождает владеемые ресурсы и т.д. точно так же как деструктор. А не трогает он сам буфер опять же точно так же как деструктор.

Вы назвали метод Dispose ответственным за уничтожение объекта. А теперь получается, что уничтожением он и не занимается. Вы уж определитесь.

0

Сообщение от Usaga Так вообще нет или есть? Вы уже определитесь в своих показаниях.

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

Сообщение от Usaga Нет. В Dispose() произвольная логика. Данного метода может и не быть вовсе. Ибо с деинициализацией данный метод не связан.

А с чем он тогда по вашему вообще связан и что вы в таком случае подразумеваете под деинициализацией?

Добавлено через 1 минуту

Сообщение от Usaga Вы назвали метод Dispose ответственным за уничтожение объекта. А теперь получается, что уничтожением он и не занимается. Вы уж определитесь.

Вот как рза логическим уничтожением объекта он и занимается. Или вы настолько тупы что не можите понять чем логическое уничтожение отличается от уничтожения буфера занимаемого объектом?

0

Сообщение от Fulcrum_013 Вообще то в ООП существуют два типа взаимосвязей - композиция и агрегация.

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

Сообщение от Fulcrum_013 Это зависит от методологии разработки. При этом ООП использует именно активные сущности, самостоятельно обрабатывающие хранимые данные по командам поступающим через интерфейс. При этом как именно обрабатывать ту или иную команду знает только сам объект и никто другой этого знать не должен. Иначе смысла в этом нет никакого.

Вы сейчас описываете один из вариантов использования ООП. Существуют другие. А от того варианта, который Вы описываете, отказались 15 лет тому назад, так как он нарушает почти все принципы SOLID.

0

Сообщение от Shamil1 Есть ещё третий - наследование.

Это взаимосвязь между классами но никак ни между объектами.

Добавлено через 4 минуты

Сообщение от Shamil1 Композиция - почти всегда плохо. Агрегация - обычно хорошо для "инфраструктурных" классов и плохо для классов предметной области.

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

Добавлено через 1 минуту

Сообщение от Shamil1 Вы сейчас описываете один из вариантов использования ООП. Существуют другие. А от того варианта, который Вы описываете, отказались 15 лет тому назад, так как он нарушает почти все принципы SOLID.

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

0

Сообщение от Shamil1 IBM PC AT появились в 1986 году

В 84ом.

0

Сообщение от Fulcrum_013 А с чем он тогда по вашему вообще связан и что вы в таком случае подразумеваете под деинициализацией?

Представляет из себя рекомендацию по подходу к высвобождению неуправляемых ресурсов или иных ресурсов. О том, что эта рекомендация - часть процесса уничтожения - речи не было и нет. Это вы придумали.

Сообщение от Fulcrum_013 Вот как рза логическим уничтожением объекта он и занимается. Или вы настолько тупы что не можите понять чем логическое уничтожение отличается от уничтожения буфера занимаемого объектом?

Высвобождение ресурса не является логическим уничтожением или тем более уничтожением физическим.

0

Сообщение от Usaga Представляет из себя рекомендацию по подходу к высвобождению неуправляемых ресурсов или иных ресурсов. О том, что эта рекомендация - часть процесса уничтожения - речи не было и нет. Это вы придумали.

НУ в током случае деструктор тоже рекомендации по высвобождению ресурсов . Не надо передергивать. Именно для принудительной деинициализации объекта Dispose и предназначен и используется он точно так же и точно там же где и деструктор в паскале. И название для него выбрали то же самое как и для функции деинициализации объекта с удалением буфера в дельфе.

Добавлено через 1 минуту

Сообщение от Usaga Высвобождение ресурса не является логическим уничтожением или тем более уничтожением физическим.

Только вот логическое уничтожение требует высвобождения всех владеемых ресурсов. Т.е. приведения объекта в состояние когда его буфер можно безопасно перезаписать. Именно этим и занимается Dispose.

0

Сообщение от Fulcrum_013 НУ в током случае деструктор тоже рекомендации по высвобождению ресурсов . Не надо передергивать. Именно для принудительной деинициализации объекта Dispose и предназначен и используется он точно так же и точно там же где и деструктор в паскале. И название для него выбрали то же самое как и для функции деинициализации объекта с удалением буфера в дельфе.

Т.е. теперь Dispose это аналог деструктора не в С++, а уже в паскале? Показания меняются?

Сообщение от Fulcrum_013 Только вот логическое уничтожение требует высвобождения всех владеемых ресурсов. Т.е. приведения объекта в состояние когда его буфер можно безопасно перезаписать. Именно этим и занимается Dispose.

Нет, не занимается. Внешние ресурсы к "буферу" объекта никакого отношения не имеют. Здоровенный, напичканный полями и свойствами объект прекрасно уничтожается без Dispose.

0

Сообщение от Usaga Т.е. теперь Dispose это аналог деструктора не в С++, а уже в паскале? Показания меняются?

Почему же меняются. Сразу говорилось - аналог паскалевского. Его таки папик объектного паскаля изобретал. и там есть кое какая разница с плюсовым. Вы хоть отличия то паскалевского от плюсового знаете ну кроме автоматики вызова которая к смаому деструктору коий обычный метод не относится?

Добавлено через 4 минуты

Сообщение от Usaga ет, не занимается. Внешние ресурсы к "буферу" объекта никакого отношения не имеют. Здоровенный, напичканный полями и свойствами объект прекрасно уничтожается без Dispose.

Толко вовремя он этого не делает. Вот Dispose и прикрутили чтоы в ручную это делать вовремя. Т.е. вынесли туда функционал финализатора и таким образом поимели возможность вызывать фактически финализатор вовремя но вручную. Т.е самый обычный деструктор ручного вызова. Один в один с паскалевским. Так что не надо ля-ля

Добавлено через 14 минут

Сообщение от Usaga Внешние ресурсы к "буферу" объекта никакого отношения не имеют

Учите матчасть. Что будет с ресурсами если их не высвободить а идентификаторы потерять?Правильно утекут. Так что не пытайтесь так категорично отрицать очевидные факты. [censored]

Добавлено через 4 минуты

Сообщение от Usaga Здоровенный, напичканный полями и свойствами объект прекрасно уничтожается без Dispose.

Ну и тривальным (реально не существующим и не вызываемым/не выполняющим никаких действий) деструктором такой же объект уничтожается прекрасно. Все зависит от владения им ресурсов и наличия взаимосвязей которые нужно разорвать при принудительной деинициализации. Нужно высвобождение/разрыв взаимосвязей - нужен нетривиальный деструктор/финализатор (а в случае IDisposable Dispose которому делегируется функционал финализатора чтобы он был доступен для ручного вызова вовремя). Не нужен - деструктор/финализатор тривиальный соответсвенно и Dispose пустой.

Добавлено через 3 часа 33 минуты

Сообщение от Usaga Внешние ресурсы к "буферу" объекта никакого отношения не имеют.

Типа хендлы/идентификаторы ресурсов ни разу не в буфере хранятся? Ну и как вы будите их высвобождать если перепишете буфер другими данными - т.е. потеряете значения этих идентификаторов. Не пытайтесь отрицать элементарнийшие факты которые есть абсолютной тру. У вас от этого только надпись быдлокодер на лбу ярче светится начинает и не более тог.

0