Name: Anonymous 2014-06-29 19:50
What's bad about Python?
}])]}})
at the end of a line looks truly awful. It's really common to stack these on the same line in Javascript or really any C-syntax with lamdbas/closures. Gross.It's full of BS as far as I can tell. I'm no fan of Python but I've skimmed it and it seems to be flamebait.can you elaborate on that?
You're probably choosing it for its community, documentation, readability, and/or rich library ecosystem.These are subjective categories and irrelevant to the good language design. But yes, Python's community is good, if you consider "good" being a drooling linux-tard or a google shill.
not doing anything where GC is a bad idea.For most interactive applications GC is a bad thing, because there is no guarantee that your app wont stop for the next few minutes to collect the shit. Haters gonna hate of course, but that is no hate, just a distaste for a tool that hits my finger and get me lose my job.
your app wont stop for the next few minutes to collect the shitGC never takes minutes in interactive applications, GC-hater. GC pauses matter ONLY on mission-critical embedded platforms, like a microwave.
codingfaggot, go back to your industry and keep ruining everything.
application
optimizeFuck off burger-lover, the compiler is the one who has to do the optimisations
If you need an extension language for your C application,I'd rather write my own DSL ``in Lisp'' for that purpose. Hell, I could come up with a better Lua that has a ``lightweight'' interpreter and isn't painfully slow in about 3 days.
with LuaJIT for speeds that Python can only dream ofThere's PyPy too. That's not a valid point.
Hell, I could come up with a better Lua that has a ``lightweight'' interpreter and isn't painfully slow in about 3 days.
have prototype based oowhat kind of fucked up world do you live where that's a good idea, nigger
Third, I don't believe in recursion as the basis of all programming.
Third, I don't believe in recursion as the basis of all programming.
Third, I don't believe in recursion as the basis of all programming.
unfortunately Python's compiler cannot reliably determine whether any particular call is actually reference the current function, even if it appears to have the same name.
derp = []
for x in [1,2,3,4]:
derp.append (lambda: x + 1)
print (derp[0]())
(funcall (car (mapcar (lambda (x)
(lambda ()
(1+ x)))
'(1 2 3 4))))
funcall
car, mapcar
(define (caar x) (car (car x)))
(define (cadr x) (car (cdr x)))
(define (cdar x) (cdr (car x)))
(define (cddr x) (cdr (cdr x)))
(define (caaar x) (car (caar x)))
(define (caadr x) (car (cadr x)))
(define (cadar x) (car (cdar x)))
(define (caddr x) (car (cddr x)))
(define (cdaar x) (cdr (caar x)))
(define (cdadr x) (cdr (cadr x)))
(define (cddar x) (cdr (cdar x)))
(define (cdddr x) (cdr (cddr x)))
(define (caaaar x) (car (caaar x)))
(define (caaadr x) (car (caadr x)))
(define (caadar x) (car (cadar x)))
(define (caaddr x) (car (caddr x)))
(define (cadaar x) (car (cdaar x)))
(define (cadadr x) (car (cdadr x)))
(define (caddar x) (car (cddar x)))
(define (cadddr x) (car (cdddr x)))
(define (cdaaar x) (cdr (caaar x)))
(define (cdaadr x) (cdr (caadr x)))
(define (cdadar x) (cdr (cadar x)))
(define (cdaddr x) (cdr (caddr x)))
(define (cddaar x) (cdr (cdaar x)))
(define (cddadr x) (cdr (cdadr x)))
(define (cdddar x) (cdr (cddar x)))
(define (cddddr x) (cdr (cdddr x)))
(define (caaaaar x) (car (caaaar x)))
(define (caaaadr x) (car (caaadr x)))
(define (caaadar x) (car (caadar x)))
(define (caaaddr x) (car (caaddr x)))
(define (caadaar x) (car (cadaar x)))
(define (caadadr x) (car (cadadr x)))
(define (caaddar x) (car (caddar x)))
(define (caadddr x) (car (cadddr x)))
(define (cadaaar x) (car (cdaaar x)))
(define (cadaadr x) (car (cdaadr x)))
(define (cadadar x) (car (cdadar x)))
(define (cadaddr x) (car (cdaddr x)))
(define (caddaar x) (car (cddaar x)))
(define (caddadr x) (car (cddadr x)))
(define (cadddar x) (car (cdddar x)))
(define (caddddr x) (car (cddddr x)))
(define (cdaaaar x) (cdr (caaaar x)))
(define (cdaaadr x) (cdr (caaadr x)))
(define (cdaadar x) (cdr (caadar x)))
(define (cdaaddr x) (cdr (caaddr x)))
(define (cdadaar x) (cdr (cadaar x)))
(define (cdadadr x) (cdr (cadadr x)))
(define (cdaddar x) (cdr (caddar x)))
(define (cdadddr x) (cdr (cadddr x)))
(define (cddaaar x) (cdr (cdaaar x)))
(define (cddaadr x) (cdr (cdaadr x)))
(define (cddadar x) (cdr (cdadar x)))
(define (cddaddr x) (cdr (cdaddr x)))
(define (cdddaar x) (cdr (cddaar x)))
(define (cdddadr x) (cdr (cddadr x)))
(define (cddddar x) (cdr (cdddar x)))
(define (cdddddr x) (cdr (cddddr x)))
#(1 2 3) ;; instead of '(1 2 3)
(vector 1 2 3) ;; instead of (list 1 2 3)
funcall
, that has to do with parsing rules and the separate namespaces for functions and values. Your lambda expression has to be evaluated as a value instead of a function name, so it can't be in head position, but if it's not in head position you can't call it as a function. That's the problem funcall
solves. I know it's ugly, but it's in the standard.first
function is not generic, so you have to access elements like so:(elt #(1 2 3) 0) ;; get the first element
Also, linked lists suck. They are slow and inefficient and horribleLOOK AT MY LINKED LIST!!!!
#define car(x) (*(x))
#define cdr(x) ((x) + 1)
No it can'tWell, too bad then (for you)
(car (car (cdr (car foo))))
which is at least as good as (head (head (tail (head foo))))
. The rules for reading /c[ad]+r/
are as exactly simple as the rules for reading the long-form expressions. (list-get 'hthttthhh the-list-of-lists-of-lists-of-fuck-you)
(get elmIndx list)
and if you want a list with the elements from x to y you do (take x y list)
CL-USER> (funcall
(car
(loop
for x in (list 1 2 3 4)
collect
(let ((x x))
(lambda ()
(+ 1 x))))))
2