Есть сложность реализации, и сложность самой задачи. Улучшая язык можно уменьшить сложность реализации, но сложность самой задачи никуда не девается. Если ты задачу решить сам не можешь, то и программу написать не сможешь, какой бы не был язык. Технологии развиваются стремительно, а вот мозги программистов остаются такими же. Так что человеческий фактор тут является ограничением.
Я вот сейчас очень хочу пошутить про создание колодца, но что-то все что приходит в голову какое-то не смешное или банальное. Давайте так притворимся, что я тут пошутил офигенную шутку про создание колодца.
Ты не все слайды выложил. Вот так выглядит визуальный quicksort полностью (так как пикабу банит blogspot'овские адреса то см. VPL QuickSort Figure A4 Paradigm Comparison Rust vs Microsoft VPL в гугле):
Это все правильно, но уровень абстракции все время будет расти и расти. То что сейчас делают ручками, рано или поздно приведется в нормальный вид, и будет стандартной библиотекой. И так далее и так далее и так далее.
Подход будет меняться из-за уровня абстракции, поэтому одни ошибки будут уходить, другие придут.
Ты уже сейчас можешь писать на высокоуровневом языке, где будет куча синтаксического сахара и высокоуровневых библиотек. И у тебя будет практически только бизнес-логика, а все остальное делать framework'и и библиотеки.
"A glue language is a programming language (usually an interpreted scripting language) that is designed or suited for writing glue code – code to connect software components."
Чего все гонят на паскаль - искренне не понимаю. я эмбедщик, соответсвенно пишу на generic C (и негодую, когда его именуют С++). C - шикарный язык. Вы на нем все и всегда напишете. Именно все. И иногда всегда. но порой, когда у вас стоит тривиальная задача С Вам не нужен. Вам нужен python. или rexx. или %languagename%. Я могу обосновать обе позиции, я свободно пишу и на C и на Pascal. Я понимаю разницу в результате компиляции и нет, меня не останавливает мнимая невозможность работать с любой переменной как с указателем в паскале. Мне кажется, приверженцы С это придумали. Потому что если бы знали - не позорились бы. Вопрос исключительно в задаче. некоторые проще кодить именно в С. Некоторые - в pascal. отдельные задачи вообще явно требуют отказаться от структурных языков. Что меня возмущает - мои коллеги по цеху превозносят С как абсолютное решение. НЕТ АБСОЛЮТНО идеального языка. Есть хреновый кодер. А норм программисту вообще похер на чем писать, лишь бы он знал язык и главное - ПОНИМАЛ под какую платформу и ЧТО он пишет. Иногда и ASM отличный вариант.
Вот здравая мысль... Все зависит от уровня абстракции - к примеру, нахер нужен человеку, который пишет код для железа, в котором он использует разностные уравнения для цифровых фильтров java script. Также на СИ будет глупо писать прикладнику, который обрабатывает дикие потоки данных или базы данных.
Простите, я недопонял две вещи: первая - что означает подобие ассемблера ? если нужна реализация на аппаратном уровне - то это не подобие, а прямое управление. Ну вот хоть из штанов выскочи - все равно это прямое управление аппаратными ресурсами. в отношении ассемблерных вставок - я их использую только когда нет возможности использовать язык, да и то, глядя в .lnk дописываю в коде что-то типа : //это точный тайминг. не трогать, посчитан для кристалла 12 Mhz. Ладно, я немного выпил сегодня, если есть желание - завтра продолжим, сейчас я немного не в фокусе, простите.
Разве с регистрами контроллера нельзя работать на СИ? Те же яйца, только на нормальном языке. Я ассемблерные вставки видел только если в случае человек хотел сократить написанный код, или просто который привык писать на асме, так сказать привет из 90-х, начала 2000-х.
Ну как нельзя ? можно и нужно, иначе нахер С вообще сдался ! У многих новичков ощущение, что типа С это типа "ну надо", но тру программисты понимают, что С это всего лишь первый и наиболее близкий шаг абстракции от аппаратной платформы. Да, включив в инклуды хренову тучу ненужного мы получим нечто близкое к тому же паскалю. С по сути первый шаг абстракции, который не просто предполагает, а фактически обязывает понимать принципы работы с памятью, указателями, стеком и прочими чисто аппаратными вещами. По этому меня немерянно веселят парни, бодро использующие С как один из примерно десятка языков, которые на нем кодят типичную прикладнуху. Но кичатся этим так, будто лечат людей от рака.
Я и не спорю) просто я увидел разговор про ассемблерные вставки, удивился на счет "я их использую только когда нет возможности использовать язык" и привел в пример си, в котором тоже самое можно сделать.
С ASM ты можешь очень хорошо управлять ресурсами, особенно, когда у тебя их уж очень ограниченное количество. В системном программирование без С никуда вообще.
ну говорил же - эмбедщик. иногда очень влом, но порой asm единственный вариант (в основном точные тайминги или очень тесно по коду). В отношении С даже не знаю, стоит ли комментировать. Лично я считаю, что программист без способности свободно писать на С просто профессионально не состоялся.
Спасибо за солидарность, но давайте все-же не будем обижать кодеров. Разумеется никто от них не ждет идентификации кода и платформы, да, у них случается не понимать совершенно элементарные принципы организации кода, да они иногда рожают чудовищные конструкции, не понимают суть ООП, при том что используют его. Но они порой вырастают в программистов. И знаете, обычно эти 10% пришедших и кодеров очень хорошие программисты. Мне просто повезло - я начинал с Д3-28, потом PDP-11, сильно позднее 8086, я 72 года и писать с ориентацией на вычислительную мощность у меня воспитана вынужденной необходимостью. Я не знаю (и знать не хочу), насколько трудно современным программерам, часть из них вообще полностью абстрагирована от платформы. Их мысли исключительно в интерфейсой части, ну может еще интеграция с СУБД. Мне кажется, что пора жестко и бескомпромиссно начинать делить нас. Мы все программисты, но порой я с коллегами, работающими в сфере WEB технологий вообще не нахожу что обсудить. Очень уж разные у нас задачи и навыки..
Конечно читал. Это любому эмбедщику близко, полезно и это полностью отражает суть профессии. Но скажу честно - мне до героя того повествования очень далеко. Я всегда беру кристалл с запасом по памяти и мощности. Я просто не рискнул бы со своим опытом брать кристалл впритирку. А рассказ классный, согласен с Вами.
Извини, но можешь ли ты конкретно сказать к каким же типам задач лучше всего применять Pascal. Есть распространенные, всеми признанные языки программирования: C,C++,C#,Java,JS,Python,Bash,Haskell(в последнее время он стал сильно популярным). Зная все эти языки, можно решить большинство типов задач. Если мы к этому списку добавим Pascal, то как мне кажется количество решабельных типов задач не увеличится. Если это не так, то мне интересно узнать почему.
в процессе моделирования совершенно неважно какой именно язык применяет программист. мне случалось строить модель в экселе. а на выходе у меня был КИХ фильтр для AVR, с целочисленной арифметикой., все уложил примероно в 2к. и это еще с реализацией аппаратной части для TLC549. были (и есть задачи, которые я моделирую в паскале) Ну нравится мне. компиляется шустрее, практически я использую паскаль, для начальной реализации клиента или мастера. мне так удобнее. Ну более дружелюбный язык, проще среда разработки. ну и для диагностики лично мне больше подходит. Сейчас скажут - типа я паскалист, а на С ушел по необходимости. не стану оспаривать. у меня есть личные интимные причины программировать и на С и на pascal параллельно.
ну а отвечая прямо - есть совершенно определенный круг задач, где конструкция типа s:=s+st+';' Значительно более очевидна варианту с кучей strcat() и strcpy(). изложенное не означает, что типа паскаль крутой, а С отстой. во всех случаях, для аппаратной платформы я использую С. но я в любом случае делаю все "руками". <string.h> в моих проектах никогда не появлялась. Но это аппаратная часть. А в отношении программной диагностической я считаю вольным делать все что пожелаю там мне С нахер не нужен.
Во многих языках с объектно-ориентированной семантикой, оператор "+" используется для конкатенации строк, зачем брать паскаль? Такое ощущение, что ты просто не знаешь других языков кроме паскаля и си, отчего и проблемы, ибо си процедурный. Посмотри на что-нибудь новое (Go например) и перестань пинать труп придуманный вообще-то для обучения, а не реальной разработки.
Новые языки действительно не изучал, часть того, что перечислена (haskell, go) даже не слышал. для моих задач вполне хватает связки c python pascal (bash/sed/прочие nix утилиты)
А у нас в колледже 3 года паскаль учили.. хорошо хоть на 4й профессора привели..за год .NET и openGL почти весь освоили и кучу мультимедиа прог.. В нете досих пор не нахожу скриптов лучше чем его самописные. Жди чуда)
Смысл учить всегда есть, тут вопрос приоритетов. Как показывает мне сейчас практика - основа это С и JS, питон на всякий случай. Как выучил, дальше легко все языки даются, только синтаксис позубрить пару недель и готово. А вопрос использования конкретного языка сильно от будущего места работы зависит, я например 1 раз о Галактике слышал и то не помню где.
Возьмите любой современный мейнстримовый язык и можете убедится, что он состоит из элементов придуманных 20-30 лет назад, а то и больше. Просто тогда они были непопулярны, потому что компьютеры были медленными, дорогими и было мало памяти. Принципы вычислимости тем более не меняются.
Ну вот это маловероятно. Сложно представить, что что-то заменит, скажем, ассемблер. Да и вообще, сейчас, скажем, такой объем программ на плюсах или джаве, что полностью от них избавиться - нахлебаться проблем с совместимостью потом. Жизненный цикл продукта, все дела. Хотя, технологии развиваются непредсказуемо, зарекаться не стоит
И много ли в наше время вручную пишут на ассемблере? У джавы тоже своя ниша, на десктопе ее почти нет. С++ тоже отмирает, новых проектов на нем мало начинают, если только геймдев, да и там уже оставляют его только в движке, а выше lua, python или свой язык.
С++ отмирает? Любое более-менее ресурсоёмкое приложение использует хотя бы библиотеки на С++, а таких приложений становится с каждым годом все больше и больше.
Библиотек на С гораздо больше, чем на С++. Но это не новый код. Плюс компьютеры становятся быстрее, значит потребность писать части на С/С++ все меньше.
Почему не новый код? Часто нужно реализовать новый алгоритм так, чтобы работал он гораздо быстрее, вот и приходится писать на С/С++ библиотеку, чтобы сэкономить драгоценные секунды времени.
"компьютеры становятся быстрее, значит потребность писать части на С/С++ все меньше" Так думают разрабы, но я в корне не согласен с этим, так как вместо хорошо оптимизированных и летающих приложений получается нечто, жрущее гигабайты лишней памяти и процессоры-секунды лишнего времени. То, что у всех сейчас мощные компьютеры, не повод забыть про максимальную оптимизацию кода.
Раньше время компьютера стоило гораздо дороже времени программиста, а сейчас наоборот. Дешевле купить более быстрый компьютер. Раньше, если вы помните, в программах на С были вставки на ассемблере для быстроты, а потом компиляторы стали генерировать более быстрый код под новые процессоры и все перестали страдать этой фигней. И если вы возьмете профайлер то вы легко можете заметить, что большинство тормозов находится в небольших узких местах кода, и только их имеет смысл оптимизировать. Насчет гигабайтов - в идеале программа должна использовать всю свободную память, если она от этого будет работать быстрее. Память это ресурс и он должен работать, вы же за нее заплатили, зачем вам свободная память простаивающая впустую?
Есть области, где время работы компьютера стоит дороже, чем время работы программиста, например, рынки бумаг или динамический анализ данных - потерянные микросекунды в этих областях очень важны. Да и заказчик, скорее всего, выберет приложение, которое будет жрать не все ресурсы сервера, но оставлять ресурсы для работы других программ.
Какой браузер вы выберите - тот, при котором можно ещё запустить скайп, медиаплеер и кучу других программ, или тот, который будет начисто вешать систему, пока загружает страницу?
И знаете, когда графический движок, разработанный в соседнем отделе обрабатывал кинематографическую графику лиц быстрее, чем какой-нибудь условный Unity обрабатывает средненькую графику, то задумываешься о том, что можно было Unity оптимизировать получше.
Я часто писал приложения, которые начисто вешали систему, а система была обычным виндоус 7. Думаю, в состоятельности этой системы мало кто сомневается.
Ну про Unity ничего сказать по факту не могу, моя область - это анализ данных.
Суперпуперязык может генерировать код на этих языках. Как например библиотека fftw, написанная на С, но не вручную, а программой на ocaml. При этом она оказалась быстрее всех реализаций, написанных вручную. Также и компилятор для современного процессора генерирует код, работающий быстрее написанного вручную.
