Why do people use and celebrate Python when Lisp is both faster and more expressive?

Why do people use and celebrate Python when Lisp is both faster and more expressive?

Other urls found in this thread:

randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/
twitter.com/SFWRedditGifs

Because Python is easier.

I must say Python is really really slow.

But I can write scripts really really fast.

Diversity of libraries available is a big win.

Quite a few people in related fields (scientists) can pick up Python and apply their domain specific knowledge to build shit in a simple to understand language.

I've pulled useful scripts from github for basic tasks on Linux, and I can actually straight read the code, as python reads like pseudo code (I actually don't work with python in my day-to-day job)

>836.27
>53.26
Holy shit man. What happened? You'd think that Python, being around longer than Racket lisp and based more around an imperative language hosted in C, would have been much more optimized but that's just not the case. Yikes.

Python is not designed to be fast. In non performance critical operations python is better. Use right tools for the right job

Network effect explains a lot of it.
Another reason is that putting in work up front is a thing that humans don't like.

So if you want to learn lisp, you have to put in some work to figure out how things work there. But if you want to learn python, then it looks a lot more like how you'd expect things to look, so you get started faster.

It doesn't matter that numApples = 1 + 3 is a retarded notation at all. Because people have spent years in school learning it already.
But (defvar *num-apples* (+ 1 2) on the other hand is alien and strange. It doesn't look how it is supposed to look.

It's like Linux. It doesn't matter if it's better or not, or it makes more sense or not, because you have already used Windows for 10 years. So Windows makes more inherent sense to you because you have already learned it at school.

So you have to compare Windows with 10 years experience to Linux with 0 experience.

same thing with programming languages, laundry detergents, how you cook your food... everything.

Why is Python better than Lisp for non-performance critical applications?

I can think of good reasons to prefer, say, sbcl:

> More expressive language (macros, better lambdas)
> More language tools available (again, macros, language, libraries like quicklisp and quickproject)
> It's easier to do the right thing

The second the project is no longer a small hack, python stops being the right choice.

The programming-at-large features of Lisp blow Python out of the water.

Consider making a project.
In CL, you'd use Quickproject to get a standard setup, define your imports with quicklisp, and you're done.

As your project has a higher complexity, extending the language (which is simple and safe in CL and even more safe with Scheme, but I'm not a Schemer), you get small and consistent gains in sustained velocity.

For those of you who haven't drunk the agile cool aid, sustained velocity is your ability to make changes as time passes. This is why you should refactor, write clean code, etc.

With lisp, there is no problem having a call that looks like this:

(create-user-from-file
:file "~/person.csv"
:filetype :csv
:locale :france)


And all of these arguments will be checked at compile time.

Meanwhile in Python you have to use strings.
User.fromFile("~/user.csv", "csv", "france")


No compile time checking of any of this stuff.

Python is neat for small tools. Emphasis on small. It stops being faster to write once the project gets large. It's not about non-performance critical code. It's about small non-performance critical programs.
Like scripts.

Right tool for the job.

This is what i meant but you said it better.

Because most everyone can read python code without wanting to gouge their eyes out. It has its place, and its a very important place, in software development and collaboration, but there are very real limitations of the language

I can't believe fucking php beats it in most tests

WTF went wrong?

Python vs Java who win?

>58968223
>python
>around longer than racket

Python is a really slow language by design

Objects are actually dictionaries so accessing a member or method is equivalent to a dictionary lookup. This is used to allow adding and removing members and methods to objects after and during their creation. It also allows metaclasses to exist.

Same thing with scopes. A scope is basically a dictionary in which all variables and functions are referenced. This is why accessing local variables is faster than accessing global variables. The global-scope dictionary is much larger than a function-scope dictionary so lookups are faster.

Also calling functions implemented in C from python is slow. Arguments have to be translated from python objects to C variables and then the outputted variables have to be converted back to python objects.

)

It has, python 1991, PLT scheme 1994.

You can't optimize semantics that broken that well.
Here, PyPy and Cython fall short as well.
You have to use special constructs to make them fast in non-trivial scenarios.

partially see

I actually prefer Lisp's infix-style notation. It's easy and consistent to read and I no longer have to remember any language's particular precedence rules. It also maps really well to the "mental stack" I developed while working with a lot of nested expressions in calculus, so it's easier for me to keep a lisp expression in my head. I guess it's not for everyone though. Racket Lisp does have infix operators and functions though.

I love lisp but to be honest I have a hard time finding anything worth doing with it. I guess it's "too much power" for me, I'm usually the kind of guy that does quick perl scripts, and rely a lot on regexps.

python is a good language for the pragmatic programmer. lisp is a good language for the fizzbuzz programmer

This. Lisp is actually quite complicated, python reads almost like english, and it's procedular ways map closer to how the computer is doing things (that is to say: sequentially).
On the other hand, python does have a lot of repeated code.

Ultimately though, there is no best language, and a lot of people (particularly #SmugLispWeenies) often like to forget that it's up to the programmer to write good or bad code, and the language is just a means of expression. That is to say, lispers put way too much emphasis on the language.

Macros are a horrible language feature for 99.99% of programmers. I do not want to work on something with macros written by Mr. Johnny down the hall.

Because it's about what people can do, but more importantly have done with it. Python, despite being pretty terrible has been used to do a lot of things (and as a result has a bunch of libraries to do things also). I agree with you though OP, Lisp is a better language and it's my favorite (sharing a seat with C), however people are not aware of it because there aren't enough "amazing" things that have been done with it that a lot of people know about so more people don't look at it and that decreases the opportunity for amazing things to attract people (the "network" effect another user described). I'd like to challenge the Lisp community though. If you want more people to look, have more projects that are amazing (and share them and why they are only possible (or a lot easier) in lisp). People aren't just going to be convinced about it just because you can do what other languages do. At the same time, perhaps from a business perspective that's a bad idea. For those people, it's better that their competitors don't use something like Lisp so there's something to be said for promoting it or hiding it. This is especially given that Lisp can be adapted to pretty much every application you can think of if you're willing to get down and write an implementation (ex. on embedded hardware) since the syntax is so minimal. Personally I hope it gets more widespread and I have my own ideas about how I can use it to do things no other languages can do easily. For the early promoters though (assuming it would ever go big), showing through excellent programs is probably the way to go, not showing that it's a better language.

This, too many macros are a code smell

The problem is, some Lisp dialects didn't even have a standardized import statement. That shows how high interop and working with other devs is valued.

lisp is for jobless loners it doesn't need such things

quick question what IDE does everyone use for Python on windows? need one

OK, somebody has to say it:

Why don't people use Ruby, when it is easerand more readable than Python, has Perl's funkiness, allows to easily include C or C++ libraries, has the best web frameworks and is almost a LISP?

>randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/

The Python license is awesome. Read it.

Lisp macros are a different beast than C macros.

This is true, and is historical.
When Common Lisp was standardized, lisp machines still existed. At least MacLisp and ZetaLisp were being actively used.
Moreover, CL was standardized precisely to address the necessity for a common language that would ease porting projects from one dialect to another.
In this setting, lisp was not some program you ran on top of an operating system, lisp was THE system. So most of the features were actually system-dependent, and the language that was to be common just defined an overall set of semantics that represented the core of the language, rather than interoperability with the rest of the world. Such interoperability was actually taken for granted as it was an essential part of lisp systems and it was system-dependent.

Fast forward 20 years, this is now a problem, a real problem, for now lisp is just a process running on top of a UNIX system, yet nobody seems to want to touch the standard, for one thing, I suspect the real reason is that there isn't really a strong motivation for such an undertaking, Lisp simply doesn't have a fraction of the share it used to have.
But lispers like to defend the language and say "it can all be solved wiht the language as it is!" even though the language lacks important features, I mean things as important as essential as multithreading, networking, OS interaction. And often lispers like to critique some weaknesses present in other languages (lack of portability, #ifdefs all over the place), which are indeed a problem with common lisp as well (#+ read-macros all over the place).

Lisp is nice, but it is very easy to get driven away by the vocal part of the culture of common lisp, I mean those guys that go around preaching the word of lisp, and telling everybody their language sucks.
And I'm thinking it really all started with Paul Graham and his "beating the averages", now everybody wants to jump on the wagon and just feel smug about using a language just for the sake of it.

Clojure solves a lot of those problems.

Too bad a lot of LISP guys are overly devensive when it comes to a language running on top of the *gasp* JavaVM..

You don't use Python because it's fast, you use it because it's pretty.

I guess Lisp is pretty too in a floor model kind of way.

Racket's honestly my favorite language for scriping now. It works consistently cross-platform (macOS/OSX, *nix, Windows). Modules make it really easy to interact with other scripts or large-scale programs. The "gradual typing" approach makes it very easy to make more stable projects safer. REPL makes the actual act of scripting much easier too, it's great with the integrated debugger and UI.

REEE!

Python is not at all close to how computers do things. You can easily write procedural code in Lisp, Lisp is not a purely functional language. I don't even get why you would make that statement. Python being procedural obviously doesn't make it "faster" than Lisp. There's no evidence that being procedural is what makes Python easier to learn than Lisp instead of an insistence on infix notation. On top of that, it's a totally false equivalence because it's just as easy to write procedural code in Lisp languages as it is in Python.

(except
(that :you
((end up)
nesting
(a lot)
of (things))
in a (single (statement))))

Even with the indentation, it's harder to follow because you have to consider the expression as a whole, while in python you
do_one_thing()
and_the_next()
and_so_on()

so you just read it sequentially and is thus easier to follow.
And I never said a word about speed, not even anything remotely related to speed, I wasn't even thinking about speed. Neither did I say anything at all about infix notation, not even crossed my mind. Why do you reply with unrelated concepts? Do you really need to hold to something I didn't even mention to validate your point? That looks like a sign of a weak argument.
Or perhaps you should have actually read my reply before trying to imply that I was saying it makes it faster, I said it maps better to how a computer does things because a computer is sequential by nature, while in lisp you don't do things strictly sequentially, but as I said, as nested applications.
Now, since you're so concerned about speed, then why do you care at all about lisp and python? You should be in a C thread.

My point ultimately is that python gets a lot more use because indeed it relates better to the sequential nature of computers and it is easier on the eyes precisely for that reason.

But that's wrong. There's nothing stopping you from doing things like that in Lisp. It hasn't even been idiomatic to nest everything in a single expression since the 1980's or something.

>Python's ways map closer to how the computer is doing things
>python gets a lot more use because indeed it relates better to the sequential nature of computers
"How computers do things" is not at all with objects-as-dictionaries with metaclasses at run-time.