LINUX.ORG.RU
ФорумTalks

Если бы языки программирования были автомобилями

 ,


0

2

Старая шутка на новый лад.

C: Формула-1 образца 1972-го года. Все еще очень быстро ездит, но в неумелых руках становится орудием самоубийства.
C++: КАМАЗ. Может везти большой груз, но выпускает ужасный выхлоп и часто ломается.
Java: китайский бортовой грузовик-воровайка. Дешевый, доступный, но не такой быстрый, как бы хотелось, требует периодического ремонта. За неимением лучшего используется для разгрузки бревен на ближайшей пилораме.
Pascal: ВАЗ-2106. Воспоминания о нем вызывают ностальгию.
Perl: УАЗ 90-х годов. Все еще на ходу, но большинство предпочитает что-то более комфортное.
Python: Toyota Corolla. Автоматическая трансмиссия, 6 подушек безопасности. Не поедет, пока не пристегнетесь. На нем вы ездите на работу и в ближайший супермаркет. Иногда вам хочется чего-то более экстремального.

Кто хочет продолжить?



Последнее исправление: hedgehog_alex (всего исправлений: 8)
Ответ на: комментарий от Iron_Bug

при этом в шарпе каждому пассажиру во время поездки выдаётся три литра кока-колы и килограмм попкорна. даже если вы не хотите, вам придётся это съесть.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Первое чтобы смачивать появляющуюся ржавчину, а второе подкладывать под шины для упразднения пробуксовки )))

Deleted
()
Последнее исправление: ifelse (всего исправлений: 1)
Ответ на: комментарий от IMAM

зачем в Сях сериализация? бинарные данные же есть. присвоил указатель - и вперёд, с песней.

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 4)
Ответ на: комментарий от Iron_Bug

присвоил указатель - и вперёд, с песней.

Сериализация применяется для кластерных систем например - для переноса дампов классов на другую физическую машину.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

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

пример «сериализации» на С - hibernation у ноутов. слил память на винт, потом восстановил.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

Можно и так конечно. Внутри библиотеки для сериализации так и устроены в принципе. Но в частности это уже писание велосипеда получается. Ведь встроенные в библиотеке механизмы отслеживают сами синхронизацию данных ещё например, учёт нескольких компьютеров в кластере. Да много чего.

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

в библиотеке, а не в языке. это не средство языка. это всего лишь частное решение, более-менее подходящее к какому-то кругу задач (обычно неэффективное, из-за своей универсальности). в языке ничего такого не нужно. он просто даёт манёвренность и позволяет писать что угодно, сообразно своим хотелкам. можно ипользовать готовые вещи, если не смущает потеря производительности. можно заточить под свои нужды.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

Правильно?

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Повторюсь в более простой формулировке.

Я прав что Си не умеет в объекты, а Си++ умеет в объекты?

Или я какие-то непонятные слова написал ранее?

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

не надо подменять факты. это не «более простая», а принципиально _другая_ формулировка. уметь и быть - это разные вещи. уметь - это включение подмножества, а быть - это равенство. например, java - это ООП. там без ООП нельзя ничего в принципе, это основа этого языка. а плюсы - это не ООП. да, он умеет в ООП искаропки. более того, у него есть тьюриногово-полный мета-язык шаблонов. который тоже умеет в ООП. но при этом я не утверждала, что ООП нельзя в С. можно, и даже есть готовые библиотеки. просто вот как-то не нужно обычно.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Что за много букоф?

Какие подмены?

Видать празднег в разгаре у тебя там :) Ну ладно.

Я спросил простой вопрос притом 2 раза один и тот же...

Если так всё грустно - можно тогда твоё виденье основных отличий C от C++?

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

это не многабукаф. это лаконичное объяснение для тех, кто путает плюсы с ООП-языками. это не одно и то же.

и какой такой праздник? сегодня нет никаких праздников, просто воскресенье - выходной из новогодних каникул.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)

1 образца 1972-го года. Все еще очень быстро ездит, но в неумелых руках становится орудием самоубийства.

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

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

Pascal - трехколесный велосипед. Многие с него начинали, хотя есть редкие товарищи превратившие свои велосипеды в дорожные трициклы.

Python - кореец. Ну плохо управляется, ну едет не как спорткар, но для автоматизации подсобного хозяйства сгодится, можно их встретить и в такси, и как машину фирмы, «для наших мест самое то» (с). И всё-таки это иномарка!

Java - это платформа, на её основе делают в основном грузовики и вахтовые автобусы. Такая штука много где пройдет, и в unix, и в linux не побоится, и по винде прокатит с ветерком. Комьюинит очень большое, среди предложений построенных на Java можно найти почти все, от инкассаторского грузовика до ассенизаторской машины.

.NET - конкурирующая платформа, только проходимость хуже, но по винде вроде едет хорошо и говорят комфорт выше. В linux на таком ехать только после подготовки, но комфорт сразу поубавится. Хотя фирма богатая, обещают повысить проходимость по нашим пенатам, но не верю, т.к. свои решения они продают вместе со своими дорогами.

C - мотоцикл. Позволяет быстро добраться, пока остальные будут стоять в stop the world пробках, да и вообще много чего позволяет делать не по правилам ;) Но в общем это опасный транспорт, не для всех, да и как сделать на основе мотоцикла грузовик? В лучшем случае получится «Муравей».

Выбирайте транспорт исходя из ваших потребностей и возможностей! Всех с пазниками!

Aber ★★★★★
()
Ответ на: комментарий от Serg_HIS

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

С++ - надстройка над С, с огромным множеством более или менее удачных расширений.

Тоесть библиотек или что такое расширения?

А мы раньше вроде выяснили, что библиотек никак не входят в спецификацию языка - это всего лишь библиотеки. Правильно?

Тоесть С++ как языка нет?

Serg_HIS
()
Ответ на: комментарий от Serg_HIS

в какие ещё политики? при чём тут это? я профессионально программирую на С/С++ уже более 20 лет.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Serg_HIS

я не говорила про библиотеки. в С есть все библиотеки, с помощью которых можно писать что угодно. я говорила про языки, так как вопрос был не про библиотеки, а про языки программирования.

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

почему у меня несколько негативное отношение к ООП? я могу объяснить. потому что это такая школьная тема...

Браво!

hedgehog_alex
() автор топика
Ответ на: комментарий от hedgehog_alex

Никто и не говорил что вычисление например одного квадратного уравнения нужно делать через наследование и писать гипер инетрфейс графический для этого, спинконтролами выбирать входные значения и упоротся в невообразимую мутатень закрасив фон интерфейса переливающимися случайными фигурами с реповой музыкой. Можно ещё навесить исотрию решений да? И сказать ну и нафига? Графический интерфейс не нужен никогда! Звук не нужен! Никаких спинконтролов никогда и нигде!

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

А в каждую дырку суёт себе и другим только неопытная школота.

А уверен, что те кто боятся ООП как кот пылесоса, просто не поняли как этим пользоваться и не делали ничего относительно большого, многопоточного и многопользовательского. Тоесть просто не опытны и не поняли где это применять.

То что ооп тормозит по сравнению с не ооп - это тоже от не понимания в головах такая хрень.

Serg_HIS
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.