|
2.4, Аноним (-), 11:34, 08/01/2018 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +27 +/– |
> форматно-несвободным синтаксисом
Лет зе cpач бегинс. Приведу абсолютно новый аргумент против питоновского синтаксиса.
Вы, уважаемые питонолюбители, считаете, что ваши глаза вам будут служить вечно. Если вы, не дай Бог, ослепнете, то на питоне вы писать уже не сможете. Зато сможете на любом другом норм си-подобном языке. Прямо сейчас слепым питоно-программистам приходится выслушивать на синтезаторе речи все эти "пробел пробел пробел пробел", чтобы понять, относится ли стейтмент к прошлому ифу. На си-подобном языке начало и конец ифа явным образом обозначаются фигурными скобками, и нет нужды запоминать, сколько же там пробелов должно быть в текущем блоке.
| |
|
|
|
5.128, Аноним (-), 11:57, 09/01/2018 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –1 +/– |
А если так:
if(cond1){
if(cond2){
if (cond3){
op1
}else{
if (cond4){
op2
}else{
op3
}
}
}
}
Такое, что на питоне, что на любом "скобочном" языке читать голосом тяжело
вот только на питоне есть возможность многие подобные вещи сокращать в однострочники
но с другой стороны, я не уверен, что сложный генератор списков с фильтрацией и пред-обработкой значений вообще возможно воспринять на слух.... есть у меня пара таких в "загашнике", так я их визуально по пол часа воспринять пытаюсь, несмотря на то, что сам их когда-то написал...
| |
|
|
|
4.141, Очередной аноним (?), 14:43, 10/01/2018 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> if (0 != x) puts("and where the fuck { and } here?")
Т.е. по Вашему мнению в данной ситуации слепой программист считает только (и исключительно) фигурные скобки? Круглые скобки, кавычки, точки-с-запятой и т.п. он игнорирует? Ваш пример на многие порядки проще ситуации, когда для каждой последующей строки надо подсчитывать кол-во пробелов чтобы отследить конец блока. Строковый литерал начался? Окей, замечательно! Ждем закрывающей кавычки или последовательности, экранирующей кавычку (чтобы ее не посчитать закрывающей) и на скобки/семиколоны/арифметическиеоперации/т.п. внимания не обращаем. И приведенный пример будет встречаться в коде значительно реже, чем монотонная необходимость считать пробелы КАЖДОЙ строки.
| |
|
3.90, kai3341 (ok), 21:19, 08/01/2018 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> Вы, уважаемые питонолюбители, считаете, что ваши глаза вам будут служить вечно. Если вы, не дай Бог, ослепнете, то на питоне вы писать уже не сможете. Зато сможете на любом другом норм си-подобном языке. Прямо сейчас слепым питоно-программистам приходится выслушивать на синтезаторе речи все эти "пробел пробел пробел пробел", чтобы понять, относится ли стейтмент к прошлому ифу. На си-подобном языке начало и конец ифа явным образом обозначаются фигурными скобками, и нет нужды запоминать, сколько же там пробелов должно быть в текущем блоке.
from __future__ import braces
Теперь проваливайте.
| |
|
|
|
|
5.65, Аноним (-), 18:14, 08/01/2018 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| –1 +/– |
> Среди этой троицы питон - единственный интерпретируемый, JS в ноде и джава - JIT-компилируемые, что, естественно, даёт прирост
Как JS, так в ноде, а не в рино или джеррискрипт.
Как питон, так почему-то не в PyPy.
| |
|
|
3.129, Аноним (-), 12:02, 09/01/2018 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> Проблема питона не в синтаксисе, амв непомерной лагучести. Приложения на питоне обычно
> невероятно медлительны, в отличие от таковых на джаве и ноде.
я использую питон в основном для обработки данных. и там скорость языка особой роли не играет - гораздо больше времени тратится на i/o, чем на какую-то логику. на питоне написать такой обработчик мне гораздо проще, чем на "родной" Java, а скорость работы будет сопоставима.
Если же нужна максимально быстрая числодробилка, то пилить ее на питоне настолько же глупо, как и на Java или NodeJS
| |
|
|
|
2.18, Аноним (-), 13:11, 08/01/2018 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +6 +/– |
Ну, во-первых, python в либреофисе всегда был и до сих пор никуда не делся, это для справки. А, во-вторых, недостаток питона в том, что он хорош для простых задач, но многие относительно сложные вещи, которые даже на голом С делаются достаточно тривиально, на питоне либо ЧРЕЗВЫЧАЙНО сложны, либо вовсе невозможны. У питона очень плохо с параллелизмом, например - или ты остаешься совсем без параллелизма, или смиряешься с чудовищными накладными расходами на обмен данными между процессами. В итоге такая простая задача, скажем, как умножение двух больших матриц, на сях и ко параллелится чуть ли не пропорционально числу вычислителей, а в питоне - плак-плак.
| |
|
3.19, Аноним (-), 13:25, 08/01/2018 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +3 +/– |
Если что я другой аноним. По поводу параллелизма я с вами не соглашусь. Питон вполне себе c параллелизмом на уровне процессов, и если у вас бутылочно горлышко io то тут уж async/await в помощь. А по поводу чудовещьных накладных расходов, ну может вам не питон нужен? Я сам не фанат питона, мне вообще пофигу питон, руби, пхп, ява, котлин или го. Просто инструменты для определенного круга задач, где то они подходят, где то нет.
| |
|
4.63, Ю.Т. (?), 18:06, 08/01/2018 [^] [^^] [^^^] [ответить] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +1 +/– |
>> В итоге такая простая задача, скажем, как умножение двух больших матриц, на сях
"Простая задача" умножения двух матриц "прекрасно параллелится" не Сями, а средой с передачей сообщений (в качестве таковой в наши дни в 99,9% случаев выступает та или иная реализация MPI). К среде доступ из Сей в первую очередь, да. Но и из фортрана (да? ещё не выбросили?).
> Для серьёзных мат расчётов си непригоден бу-дизигн. "Безумные учёные(tm)" множат свои матрицы
> фортраном, им этот ваш пердолинг с указателями и вечно переполняющимися буферами
> нафиг не упёрся.
Когда-то -- да. Сейчас все классические реализации научных библиотек непременно имеют интерфейс к Си, если сами не переделаны на Си.
| |
|
|
|
3.119, Аноним (-), 09:57, 09/01/2018 [^] [^^] [^^^] [ответить] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +2 +/– |
VBA не возглавляет подобные чарты потому что:
1) VBA работает только внутри MS Excel, CorelDraw и AutoCAD - то есть их используют профессиональные пользователи (экономисты, аналитики, дизайнеры, проектировщики, конструкторы итд). Этим людям некогда сраться на форумах, с английским в этой среде туговато, а о том как встречают в рунете российских "прикладников" - хорошо известно, где пользователей бейсика считают недолюдьми. А вопрошать на StackOverFlow по объектной модели Excel в VBA - не принято.
2) Весь стек VB (включая даже .Net) нужно считать VBA-совместимым.
Добавление Питона в VBA - добавит популярности обоим языкам, синергия...
| |
|
|
1.106, kai3341 (ok), 02:32, 09/01/2018 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
Надо полагать, MySQL теряет баллы потому, что её выпилили из Debian в пользу MariaDB. По идее, на уровне SQL эти обе БД должны быть практически идентичными. Было бы круто, если бы они ещё в SQL умели
Любопытна ситуация с PostgreSQL. Я его тыкал мало, но впечатления пока исключительно приятные.
Видимо, Oracle теряет баллы в связи с ценовой политикой. Ещё мне дико не нравится процесс установки ораклиного клиента: меня удивляет ситуация, что в 2018 году клиент ставится сложнее, чем apt-get install. Для тех, кто не в теме: регаемся на сайте oracle, логинимся, выкачиваем zip-архивы с бинарниками и заголовочниками, отдельно гуглим инструкцию, куда что распаковывать, какие конфиги править. Но deb-пакет можно собрать один раз и более не заморачиваться, так я и сделал. Под Windows то же самое. Ребята повёрнуты к клиенту (_нуж|ным_) местом.
Но в SQL они умеют, работать Oracle исключительно приятно
По поводу MSSQL ситуация двойственная. Дело в том, что к самому серверу претензий нет. А вот freetds ущербен. Как думаете, только на какой платформе работает родной драйвер?
С удивлением отметил, что Firebird очень даже торт. Да, он хоть и тупенький, но в SQL умеет, в отличие от MySQL. В 3.0 оконные функции завезли: теперь заживём :)
| |
|
2.107, ыы (?), 03:19, 09/01/2018 [^] [^^] [^^^] [ответить] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
> меня удивляет ситуация, что в
> 2018 году клиент ставится сложнее, чем apt-get install. Для тех, кто
> не в теме: регаемся на сайте oracle, логинимся, выкачиваем zip-архивы с
> бинарниками и заголовочниками, отдельно гуглим инструкцию, куда что распаковывать, какие
> конфиги править.
Нет ничего удивительного что в 2018 году люди как не читали инструкции по установке так и не читают.
Делают нечто, что кажется им умным и правильным.. удивляются... потом пишут о своих открытиях на форумах..
Для 12-й базы вам сюда: https://docs.oracle.com/database/121/LADBN/#CJABJBAI
Найдите в списке debian.
Для сертифицированных же систем- все ставится элементарно.
| |
|
1.143, Владимир (??), 00:10, 16/01/2018 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +2 +/– |
А где же Tcl ?
http://tclstudy.narod.ru/articles/doubletea.html
А теперь давайте прислушаемся к обоснованному мнению настоящего программиста, первого лауреата премии АСМ Брайана Кернигана (В. W. Kernighan, далее - BWK), автора знаменитого языка программирования С: "Tcl/Tk придает работе магическую продуктивность, за несколько часов можно достигнуть тех же результатов, что за дни или недели при разработке на C или C++ ... . Tk весьма эффективен для большинства приложений, многие элементы интерфейса (виджеты) реализованы настолько хорошо, что остается только удивляться, как подобная работа могла быть выполнена так качественно... Удачным кажется и то, что разделение задач между Тсl и С/С++ осуществляется достаточно легко, надо только знать, какой инструмент лучше справляется с задачей... Расширение системы дополнительным Tcl-кодом, загружаемым напрямую в Tcl-библиотеку приложения, в полном согласии с оригинальной идеей Остирхоута, повышает эффективность программы в целом, упрощает ее структуру и улучшает мобильность... Я не уверен, что Тсl мог бы выжить, как самостоятельный продукт - у него слишком много конкурентов. Но у сочетания Tcl/Tk в Unix-мире нет конкурентов... Система исключительно надежна, очень хорошо документирована... свободно доступна... безукоризненно высокого качества".
| |
|