Hacker Newsnew | comments | show | ask | jobs | submit | hkolek's commentslogin

Please, for the love of god, stop with fearmongering about overpopulation already. It's pure nonsense.

http://www.worldometers.info/world-population/#growthrate

"The latest United Nations projections indicate that world population will nearly stabilize at just above 10 billion persons after 2062." [1]

Also recommended: The documentary "Population Boom" by Werner Boote [2][3]

[1] http://esa.un.org/unpd/wpp/Documentation/publications.htm

[2] http://www.imdb.com/title/tt3107706/?ref_=fn_al_tt_1

[3] (German) http://www.populationboom.at/

-----


Could you please point out what part of that supports the idea that a leveling off of the population would be possible without contraceptives?

Both of the replies I've received so far appear to completely misunderstand what I'm saying. I'm not saying the population will grow without limit no matter what. I'm saying that contraceptives are vital to avoiding that. Which is not at all contradicted by the fact that our world appears to be headed for zero population growth, because our world contains readily available contraceptives.

Do people not read, or what?

-----


> Both of the replies I've received so far appear to completely misunderstand what I'm saying. I'm not saying the population will grow without limit no matter what.

Point taken. I'm sorry, and you're right, I don't disagree with anything you actually said.

-----


That's not true. I was one of the idiots who bought it on release day but I eventually got a (Steam credit) refund after a lot of back and forth. And there were several other people on the Egosoft forums who got a refund as well.

-----


Interesting. I think you're on to something here. The wikia stuff seems to have been created in August 2013. The subreddit /r/cicada appears to be 11 month old, but the article implies that Eriksson discovered it in the beginning of 2012. And it's virtually empty. Hmmm...

Edit: oh well, nevermind. A google search between 1/1/2010 and 1/1/2012 returns plenty of stuff, for example a discussion [1] on the xkcd forums from January 2012.

[1] http://forums.xkcd.com/viewtopic.php?f=2&t=79579

-----


> but most of the carcinogens should be in both

Hm, I don't think so. While it's true that inhaling burned plant material is never a good thing, there is no evidence so far that smoking cannabis causes cancer. Search for Dr. Donald Tashkin who has done extensive studies on this subject. Afaik tobacco smoke is also radioactive due to phosphate fertilizer [1][2] so I assume this is also a major factor leading to its carcinogenic properties.

[1] http://www.epa.gov/radiation/sources/tobacco.html

[2] http://www.nuc.berkeley.edu/forum/218/radioactive-tobacco.20...

-----


Here comes the radioactive, GMO cannibis! With paraquat!

-----


> a world population that continues to grow by leaps and bounds

not so much: http://www.worldometers.info/world-population/#growthrate

-----


The article is conflating stuff and is just FUD. You don't need certs to apply asymmetric cryptography.

As I understand it, the NSA could insert itself as a so-called "Men in the Middle" (aka MITM Attack). See this SO question for a far better explanation than I could provide: http://stackoverflow.com/questions/14907581/ssl-and-man-in-t...

-----


I agree, but I'm wondering what you think is missing or broken in Clojure to prevent it from being a Lisp? Sure, it sits on top of the Java type system and one major thing I can think of that is lacking is the condition system (although, isn't this a only Common Lisp thing?). I don't think it has to be Lisp all the way down to be a Lisp dialect, if that's what you're getting at.

-----


http://karma-engineering.com/lab/wiki/Clojure but, this is only quick review.

It is possible, for example, to go through some books, especially "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code, and make explicit commentaries on all the subtle differences, but I'm not going to perform such a tedious task for free.)

-----


I am familiar with this line of reasoning and I have read the Joy of Clojure. I can't say that I agree though. The article you linked is just opinion and doesn't back up its arguments at all. Afaict, it really boils down to "it's not CL" and "it's not built on cons cells". I agree that the fact that Clojure sits on top of the Java type system is a bit of a mess but it's a language to get shit done and not satisfy some purists.

> "The Joy Of Clojure" which contains 20 line of marketing slogans for 1 line of code

> but I'm not going to perform such a tedious task for free

Well, obviously there's no point in discussing this further and we have to agree to disagree. Have a nice day anyway.

-----


Let's make it simple.) There is classic homework code in two different dialects of Lisp:

  (define (cross xs ys)
      (cond ((or (null? xs) (null? ys)) '())
            ((atom? xs) (cons (list xs (car ys)) (cross xs (cdr ys))))
            (else (append (cross (car xs) ys) (cross (cdr xs) ys)))))

  (defun cross (xs ys)
      (cond ((or (null xs) (null ys)) nil)
            ((atom xs) (cons (list xs (car ys)) (cross xs (cdr ys))))
            (t (append (cross (car xs) ys) (cross (cdr xs) ys)))))
Could you, please, provide the equivalent code in Clojure?

-----


Well, you could do it this way:

    (defn cross2 [xs ys]
     (cond (or (and (sequential? xs) (empty? xs)) (empty? ys)) '()
           (not (sequential? xs)) (cons (list xs (first ys)) (cross2 xs (rest ys)))
           true (concat (cross2 (first xs) ys) (cross2 (rest xs) ys))))
which is pretty much exactly homologous, allowing for the detail that you can't ask if an atom is empty? in Clojure, cond (Arc-like) takes alternating conditions and consequents rather than condition-consequent pairs, and the spellings of the list operations no longer refer to IBM 709 machine instructions. Also, it works on any kind of sequences, not just lists, with of course a punishing performance overhead on sequences whose `rest` operation is slow.

But I would argue that this interface is poorly designed, since you can say (cross2 '(a b c) '(1 2 3)) or (cross2 'a '(1 2 3)) but not (cross2 '(a b c) '1), and worse, (cross2 '(a (b c) d) '(1 2 3)) implicitly flattens the (b c) into individual items, which is probably a latent bug rather than desired behavior. So I would argue for writing it in this form instead:

    (defn sc [x ys]  ; scalar cross
          (if (empty? ys) '() 
              (cons (list x (first ys)) (sc x (rest ys)))))

    (defn cross [xs ys]
          (if (or (empty? xs) (empty? ys)) '()
              (concat (sc (first xs) ys) (cross (rest xs) ys))))
which avoids those irregularities and makes the code easier to understand by removing misleading false symmetries.

Except really, if this isn't a homework problem, I think you should write it like this in any of these three Lisps:

    (defn cross [xs ys]
          (map (fn [x] (map (fn [y] (list x y)) ys)) xs))

-----


With the last two lines you won.) My point was that to make correct translation one must use (recur ...) which will mess everything up.

One more subtle thing: your solution produces (((a 1) (a 2)) ((b 1) (b 2)) ((c 1) (c 2))) while the contract was to produce "list of all possible pairs".

-----


Oh, that extra nesting was stupid of me! Thank you. It should have been

   (defn cross [xs ys]
          (mapcat (fn [x] (map (fn [y] (list x y)) ys)) xs))
and maybe in CL one would prefer

   (defun cross (xs ys) 
          (loop for x in xs
                appending (loop for y in ys
                                collect (list x y))))
which of course has no equivalent in Clojure, Scheme, or really any other language I can think of.

I'm not sure I agree on (recur...). You would need to use (recur...) if you were translating tail-recursive code that iterated over something other than a data structure and didn't produce new live objects on every iteration. But the code you gave wasn't tail-recursive, and what it iterated over was a data structure, and every iteration produced live objects that can't be garbage-collected. Even if you rewrote it to be tail-recursive, it wouldn't run out of stack for reasonably-sized output lists anyway; and for unreasonably-sized output lists, it would be likely to run out of heap for the output before it ran out of stack. I'm interested to hear if you manage to get it to stack-overflow. (It seems likely to be possible, but perhaps a bit of a challenge.)

Regardless, I don't think it's reasonable to claim that languages that don't have tail-call elimination — which I suspect you may be on the point of doing — aren't Lisps. Many popular Lisps have had TCE, but many more Lisps haven't, and the CL standard doesn't require it.

-----


> ... which of course has no equivalent in Clojure, Scheme, or really any other language I can think of.

Python, for example: def cross(xs, ys): return [[x, y] for y in ys for x in xs]

LOOP in disguise :) (at least to my (very possibly faulty) understanding.)

-----


A number of languages have listcomps that can do this, and which are actually more useful for this than CL's LOOP macro, but the thing I meant to point at was the APPENDING bit. I guess (loop for x in xs append (loop for y in (f x) collect y)) is awfully similar to [y for x in xs for y in f(x)], though.

-----


Including Clojure for those who might not know:

    (defn cross [xs ys]
      (for [x xs, y ys]
        [x y]))

-----


> http://karma-engineering.com/lab/wiki/Clojure but, this is only quick review.

This definition seems to exclude Common Lisp from being a Lisp. That might be a defensible position, but it does call into question how your definition of "Lisp" is useful to you. It also seems to exclude languages like Dylan, which are commonly regarded as Lisps by people far cleverer than me.

-----


Every other Lisp happens to have TCO, so if you try to port other Lisp programs to Clojure you generally get stack overflows.

-----


But afaik TCO is only a requirement for Scheme implementations, not for e.g. Common Lisp (i.e. you don't need to implement TCO to satisfy the Common Lisp standard). I don't see how the lack of TCO prevents it from being a valid Lisp dialect.

-----


Do you need to implement the common lisp standard to be "a lisp"? What is a lisp?

-----


Exactly my point. I was just using CL as example because I think it would be hard to argue that it is not a Lisp yet the standard doesn't guarantee TCO.

> What is a lisp?

It's a very good question. I think PG sums it up quite nicely in "Revenge of the Nerds" [1]. Although, now that I'm thinking about it, I'm not quite sure there's any point in classifying something as a Lisp or not...

[1] http://www.paulgraham.com/icad.html

-----


Emacs lisp doesn't guarantee TCO (and in practice does not perform it at all), and yet few people claim that it is not a dialect of lisp.

-----


Without TCO you have stack overflows, and without proper numeric tower you have integer overflows. Roughly speaking, one of the aspect of why it isn't Lisp is underlying Java stuff.

-----


I think we have already established that TCO is not necessary to be a Lisp (CL, Emacs Lisp). While it's true that Clojure doesn't have a proper numeric tower it does have bignum support and arbitrary precision math operators which will not overflow. But either way, imo this is not a defining feature of a Lisp dialect.

-----


In fact, all non-toy Lisp implementation provide TCO - http://0branch.com/notes/tco-cl.html because, it seems, it's a natural feature of a Lisp system (Scheme just requires it).

Again, Lisp could be defined as a limited set of conventions/features. As long as some other features, such as CLOS added there is no problem, but if some features are broken, then it is not Lisp anymore. It is just doesn't walk like a duck.

Let's say that Clojure was developed with a "put everything useful together" or Ruby-approach, if you wish, which is very popular for scripting languages, while development of Scheme and other Lisp dialects was founded on "put only what is absolutely essential, and done right".

The first approach "stuff anything in" you could see almost everywhere. The second approach "research first, and do the best" is unpopular for the obvious reasons and could be rarely seen only in masterpieces, such as Gambit-C, nginx, old-school marvels such as Informix.

So, in my opinion, Clojure is much closer to Ruby than to Lisp (let's not be deceived by parentheses) - it is a scripting language (to quickly put everything together with variety of clever special syntax and fancy data-structures without much thinking about implementation details). This is, of course, most productive approach to coding - this is why people love scripting languages so much.

-----


Your manner of dismissing LISPs without TCO allows you is something of a No True Scotsman argument, enabling you to proclaim counter examples toys by merit of their being counter examples. Yes, most lisps have it. I don't think anyone denies emacs-lisp or AutoLISP were Lisps due to their lacking it.

Your suggestion of "let's say ..." is based in what appears to be complete lack of familiarity with all of the languages involved. Providing useful libraries doesn't preclude having done things right. Supplying a bare minimum of libraries does not preclude having made them miserable. There are plenty of awkward moments in using Common Lisp libraries that have made this plain to me.

Your suggestion that "research first, and do the best" is unpopular for "obvious reasons" is just hand-waving. The "obvious reasons" that are left unstated here are that "research first and do the best" languages general suck, hard. They suck because they sit in toy environments for years while the "release early and iterate" languages flourish under constant adaptation to real world usage. Both will have warts. The latter will be worth using.

Suggesting that "Clojure is closer to Ruby that Lisp" is just silly. What lisp? Scheme and Common Lisp, both definitely Lisps, are easily as different from each other as Clojure is from either. Ruby's insane class monkey patching is closer to the type of advice you find in Common Lisp than the immutable datatypes and carefully conceived concurrency primitives found in Clojure. Common Lisps many different name classes are a horror found in few modern languages. There's nothing in Clojure's "clever special syntax" that many developers did not toy with using reader macros and other abominations. Your suggestion that the olders lisps data structures, usually cobbled together with a pattern of lists and a prayer, are somehow more thought through than Clojures is both ignorance and meanness combined. Yes, Common Lisp had many builtin and library added datatypes. No, it didn't stop alists and structure built from underlying alists from being its fondest love.

As for classifying Ruby and Clojure as "scripting" languages, please define "scripting" language. It's a meaningless term for nearly anything other than `bash`.

-----


One of the correct, but subtle analogies with Ruby is that in times prior to 1.8.x there was nothing, but reference implementation. For the question "define what is Ruby?" the answer was "this MRI".

The differences between, say, Scheme and CL are few and subtle - #' and funcall syntax, behavior of nil, etc. all the foundational special forms and general function application rule are the same.

Of course, CL is a much bigger language, but all its features never broke the basis on which everything is founded - a few special forms, list structure, general evaluation rule with exceptions only for these special forms, each of which follow its own rules.

Most of CL's features are macros and libraries, so they do enrich the base language, without breaking it up.

-----


Clojure currently needs to be implemented and extended in another language: Java. The Clojure compiler is written in Java. The runtime is written in C. Its core is written in Java.

https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

Most Common Lisp implementations have their compiler written Common Lisp. The language is implemented and extended in Common Lisp.

-----


FWIW, in the case of Solar City he consistently emphasizes in his interviews that he has to basically "just show up at board meetings and hear the good news" and that most of the credit goes to the guys in charge there. But anyway, I'm deeply impressed by this guy, especially since he is not only CEO but also Chief Designer at SpaceX and Product Architect at Tesla.

-----


what a crock of shit. THC levels are not rising.

http://science.howstuffworks.com/marijuana5.htm

http://www.420magazine.com/forums/cannabis-facts-information...

also watch http://www.imdb.com/title/tt1039647/

> Smoking cannabis is a double whammy, because tobacco

What? You can smoke cannabis without tobacco.

-----


> what a crock of shit.

calm down, it's a common suggestion that THC levels are rising and rather than just repeating it I asked if it is, in fact true. A simple "no" is better.

Your first link does not support your point as strongly as you seem to think. Your second link is obviously a joke - no one would present such an obviously biased source with so many cherry picked reports seriously.

-----


I think he means the git talk at google [1] where he defines a few things at the start, among them "wrong, stupid: people who disagree with linus" and states that therefore, during the talk, by definition everyone who disagrees with him is stupid and butt-ugly.

[1] http://www.youtube.com/watch?feature=player_detailpage&v=4Xp...

-----


Which is the exact opposite of doing it in person though, it's being all cute and funny about it. Actually doing that in person would look and feel radically different.

-----


i'm 100% certain linus is not being cute, or funny. he means it when he says certain people are stupid.

-----


Compared to the stuff he types into his keyboard it's still lame, and being cute and funny in comparison.

Also, stupid is relative anyway. Who isn't stupid? Is Linus actually that stupid that he thinks he isn't stupid? And if he is, what kind of weight does he think this insult carries out of his mouth? Stuff gets tricky real quick like that.

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: