Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten predictions (2004)

sites.google.com

Post reply on HN
Print view View original

221–230 of 324 posts

Re: Ten predictions (2004)

#221

Post by pg »

justin_vanw wrote: post #172

Lisp will never be popular. Everyone likes to kiss the ass of Lisp, and talk about how transformative and powerful it is, then they go and write a bunch of Python or Ruby or Lua or Perl or anything other than Lisp, because infix is just much much more readable. When was the last time you went to a math class and the professor wasn't using infix notation? Even the Common Lisp Hyperspec has to resort to infix notation…

The mistake here is the "everyone." I agree that infix is easier for some math, but otherwise I genuinely prefer prefix, and I'm not the only one.

So the question now is, are those of us who have no problem with prefix notation merely a random minority of the population, like people who are left-handed, or are we a minority like say the minority who are good at math, or the minority who used the Internet in 1995?

I'm not saying for sure we are. Even after all these years, I still can't say for sure whether ordinary programmers will ever be able to deal with prefix notation. But I also don't feel it's safe to dismiss the possibility.

Re: Ten predictions (2004)

#222

Post by pg »

justin_vanw wrote: post #191
rntz wrote: post #189

Earlier quoted context omitted.

Maybe I'm missing something, but I don't see any infix notation on the linked page.

(car x) == (first x) (car nil) => NIL Shouldn't they say, for example: (eq (car x) (first x)) Sure, it's the same, both imply a test for equality or in this case an assertion of equality. However, '==' is not part of this language and there is reason to use it other than the alternative is less obvious and clear.

No, you're confusing expressions with metanotation.

Using infix metanotation to describe Lisp semantics is a convention that goes back to McCarthy.

Re: Ten predictions (2004)

#223

Post by bcoates »

justin_vanw wrote: post #191
rntz wrote: post #189

Earlier quoted context omitted.

Maybe I'm missing something, but I don't see any infix notation on the linked page.

(car x) == (first x) (car nil) => NIL Shouldn't they say, for example: (eq (car x) (first x)) Sure, it's the same, both imply a test for equality or in this case an assertion of equality. However, '==' is not part of this language and there is reason to use it other than the alternative is less obvious and clear.

It's pretty universal to use syntax that's outside the domain of the language being described to describe a language in it's specification, otherwise your head would explode trying to distinguish the example from the rule.

The C++ standard uses tables for the equivalent purpose, not C++ declarations, like at §23.2.1 in C++11. Does this mean that C++ should move from header files to an RDBMS?

Re: Ten predictions (2004)

#224

Post by ricardobeat »

ghshephard wrote: post #38
friendly_chap wrote: post #29

1. XML databases will surpass relational databases in popularity by 2011. We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. 2. Someone will make a lot of money by hosting open-source web applications. Github is cool but with all the cheapskate web devs (no offense, I am one of them) I don't think it is _that_ profitable. 3. Multi-threaded programming will fall out of favor by 2012. Not really.…

"6. A new internet community-hangout will appear. One that you and I will frequent. This is such a vague prediction does not even worth mentioning." This is one he nailed - Facebook.

I thought of Reddit. People don't really "hang out" on facebook, and it's more about friends and family, not communities.

Re: Ten predictions (2004)

#225

Post by T-hawk »

friendly_chap wrote: post #29

1. XML databases will surpass relational databases in popularity by 2011. We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. 2. Someone will make a lot of money by hosting open-source web applications. Github is cool but with all the cheapskate web devs (no offense, I am one of them) I don't think it is _that_ profitable. 3. Multi-threaded programming will fall out of favor by 2012. Not really.…

> 3. Multi-threaded programming will fall out of favor by 2012. Not really. We are already in the multicore age, and it will only get moreticore.

What that prediction missed was that Moore's Law finally broke down for single-threaded performance. Single cores got only about 3x faster from 2004 to today, rather than continuing the historical trend with four more doublings. Moore's Law is alive and well but now requires parallel architecture to exploit. But you can't blame an armchair pundit for missing this one. The 3 GHz clock speed barrier was hardly something a layman could have predicted; it's an artifact of extremely sophisticated manufacturing processes and infinitesimally detailed subatomic physics. A layman couldn't have said whether the physical limits of clock speed would be reached at 1 GHz or 100 GHz and in 2005 or 2025.

> 6. A new internet community-hangout will appear. One that you and I will frequent.

This succeeded way more than anyone thought. More than "you and I", our moms and grandparents even hang out there. It is Facebook.

Re: Ten predictions (2004)

#226

Post by martinced »

justin_vanw wrote: post #211
moron4hire wrote: post #203

Earlier quoted context omitted.

That's an interesting point about infix and postfix calculators but no prefix calculators. Though I wouldn't go so far to say there aren't any, I feel pretty sure I've seen one before--though don't care enough to go looking--they do seem pretty rare. I wonder what lisp/scheme/whatever-I-need-to-say-to-get-you-to-stop-being-pedantic would look like with post-fix evaluation.

I think it would be not that much better than prefix. Infix is easier to read, because it is just more natural to parse. An expression like: sin(1 + (5 + x + y) / (n + k)) is just really easy to understand (sin (+ 1 (/ (+ 5 x y) (+ n k))) is inscrutable, at least to me. The second thing is, intermediate variables makes code much more readable, but lisp strongly discourages this. The only way to create a lexical varia…

I know it's not real code but I honestly find the second example way easier to read. It's indeed very common to use a 'let' like that and I don't see what's wrong with a "two spaces" indent (between your 'let' and the next 'if'). If you're talking about the indent after the 'let*' then, if anything, I think it makes the scope just so much more obvious.

So YMMV.

Re: Ten predictions (2004)

#227

Post by martinced »

stiff wrote: post #170
moron4hire wrote: post #99

On the Lisp thing, looking around the programming world in 2004, you didn't see proliferation of functional concepts like you do today. In those days, "functional" meant Lisp, at least popularly. I think the big lesson of Lisp has been disseminated, though, and that is that it is more productive to write code-that-writes-code. But I also think we learned a broader lesson that it's better to not pigeon-hole people dow…

Being a "Lisp" is a very broad category and I always wondered about people calling Lisp a functional language. I would love to see a list of things that are today considered functional that originated in Lisp, I think there is not that many of them in the end. However, there is a ton of things that have nothing to do with being functional that originated or got popularized by Lisp: garbage collection, lists as the fu…

..."I always wondered about people calling Lisp a functional language"

Even more interesting: why do people call a family of language a language? elisp, for example, certainly doesn't put the emphasis on FP. But Clojure does (although you can use Clojure in a non-functional way).

But it's not that much of a surprise: nowadays talks about FP are everywhere, so programmers who think they understand FP use the term for everything.

For example you can have Excel spreadsheet having cells which shall always update themselves automatically from the network: like a cell containing the current date. Or a cell containing the current exchange rate between this and that currency.

Yet recently on HN in every single thread about Excel you had armies of retards explaining that "Excel was the ultimate functional programming language".

People are really that retarded. Even on HN. And it's frankly sad.

:(

Re: Ten predictions (2004)

#228

Post by banachtarski »

mseebach wrote: post #69
friendly_chap wrote: post #29

1. XML databases will surpass relational databases in popularity by 2011. We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. 2. Someone will make a lot of money by hosting open-source web applications. Github is cool but with all the cheapskate web devs (no offense, I am one of them) I don't think it is _that_ profitable. 3. Multi-threaded programming will fall out of favor by 2012. Not really.…

3: He explicitly mentions message passing and multi-process as opposed to multi-threaded, and that's dead on right. F#, Clojure, Scala, Erlang and Node are all approaches to concurrency that doesn't involve the developer dealing with threads.

+1. I thought that prediction was the most impressive one on the list.

Re: Ten predictions (2004)

#229

Post by htp »

justin_vanw wrote: post #211
moron4hire wrote: post #203

Earlier quoted context omitted.

That's an interesting point about infix and postfix calculators but no prefix calculators. Though I wouldn't go so far to say there aren't any, I feel pretty sure I've seen one before--though don't care enough to go looking--they do seem pretty rare. I wonder what lisp/scheme/whatever-I-need-to-say-to-get-you-to-stop-being-pedantic would look like with post-fix evaluation.

I think it would be not that much better than prefix. Infix is easier to read, because it is just more natural to parse. An expression like: sin(1 + (5 + x + y) / (n + k)) is just really easy to understand (sin (+ 1 (/ (+ 5 x y) (+ n k))) is inscrutable, at least to me. The second thing is, intermediate variables makes code much more readable, but lisp strongly discourages this. The only way to create a lexical varia…

I personally have trouble quickly parsing expressions like sin(1 + (5 + x + y) / (n + k)), but do really well with things like:

    (sin (+ 1 (/ (+ 5 x y)
                 (+ n k))))
Similarly, your Lisp could be reformatted to something like:

    (define (qualifies-for-free-shipping item-price weight shipping-factor category)
        (let* ((item-cost (* item-price TAX-RATE))
               (shipping-cost (+ (* weight shipping-factor) 2))
               (total-price (+ item-cost shipping-cost)))
         (cond ((in category FREE-SHIPPING-CATEGORIES) #t)
               ((>= item-cost 80) #t)
               ((and (>= total-price 100) (in category ELECTRONICS-CATEGORIES)) #t)
               (else #f))))
I think you’re trying to use Lisp as if it were Python, and that’s going to make things more difficult for you than they need to be.

(A lot of my college classmates ran into trouble in a class where we programmed in Scheme [since renamed to Racket] because they tried to use it like Java, the standard curriculum language. If/when they grokked Scheme, they became just as proficient in it as they were in Java, but until they did they spent a lot of time effectively complaining about how Scheme wasn’t Java.)

Re: Ten predictions (2004)

#230

Post by amatix »

hcarvalhoalves wrote: post #218
edu222 wrote: post #152

Earlier quoted context omitted.

Have you tried Django's ORM? From what I understand its not perfect, but for the most part it really rocks.

I've been working with Django for 5 years, and I would say Django's ORM is pretty pedestrian, when not downright painful. It fails at simple things like allowing you to GROUP BY without falling back to SQL.

That used to be the case, it's much better now: see QuerySet.annotate() and QuerySet.aggregate()
Post reply on HN